В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 83
Текст из файла (страница 83)
строк) + RSize, гдеRSize = (размер переиспользуемого кода в тыс. строк) * (100 – AT)/100 *(AA + 0.4*DM + 0.3*CM + 0.3*IM + SU)/100 AT — процент автоматически генерируемого кода; AA — фактор трудоемкости перевода компонентов в повторно используемые, от 0до 8; DM — процент модифицируемых для переиспользования проектных моделей; CM — процент модифицируемого для переиспользования кода; IM — процент затрат на интеграцию и тестирование повторно используемыхкомпонентов; SU — фактор понятности переиспользуемого кода, от 10 для простого, хорошоструктурированного, до 50 для сложного и непонятного; равен 0, если CM = DM = 0.o Все коэффициенты, кроме Kreq и MP, имеют те же значения, что и в предыдущей модели.o Коэффициент Kreq вычисляется как (1 + (процент кода, выброшенного из-за изменений втребованиях)/100).o Коэффициент MP является произведением 17-ти коэффициентов затрат, имеющихзначения от 1 до 6: надежность продукта; сложность продукта; размер базы данных разрабатываемого приложения; требуемый уровень повторного использования; требуемый уровень документированности; уровень производительности по времени; уровень требований к занимаемой оперативной памяти; изменчивость платформы; возможности аналитика проекта; возможности программистов; опыт работы команды в данной предметной области; опыт работы команды с используемыми платформами; опыт работы команды с используемыми языками и инструментами;297 уровень текучести персонала в команде; возможности используемых инструментов; возможности общения между членами команды; фактор сжатия графика проекта.Для тех, кто уже отчаялся понять все хитросплетения этой модели, скажем, что имеютсяпрограммные инструменты, автоматизирующие расчеты по ее формулам.Управление ресурсамиВ данном разделе рассматриваются вопросы управления ресурсами проекта, исключаяспецифические аспекты, касающиеся только персонала.Одной из основных задач управления ресурсами является планирование проекта на основеимеющихся ресурсов и оценок ресурсоемкости отдельных работ, а также доработка планов привозникновении изменений в ходе проекта, связанных с неожиданными работами, изменениемоценок или изменением доступных ресурсов.При разработке графика проекта нужно выполнить следующие действия.• Уточнить имеющуюся структуру работ проекта для того, чтобы использовать ее в рамкахвыбранного процесса разработки.
Например, структура работ может соответствоватьнабору функций, которые должны иметься в результирующем продукте. Использованиепроцесса XP может потребовать составить план поставок не в соответствии с наборамипоставляемых функций, а в соответствии с понедельным планом поставок. В этом случаетяжело предвидеть наборы функций, которые будет иметь очередная поставляемая версияпродукта, но можно спланировать еженедельные поставки, их обкатку у пользователей,анализ результатов и доработки по его итогам.• Установить зависимости между отдельными работами, присутствующими в уточненнойструктуре работ проекта. Зависимости могут иметь разный характер: финиш-старт (работаможет быть начата только после конца другой), старт-старт (работа может быть начататолько с началом другой), старт-финиш и финиш-финиш. Если вы встречаете болеесложную зависимость типа «работу можно начать, только если сделана некоторая частьдругой», это признак того, что работы декомпозированы недостаточно детально и нужноразбить вторую работу на части.Вставив фиктивные работы, не требующие ресурсов и времени, можно все зависимостипривести к виду финиш-старт.T1T2T3T4T6T7T8T9T10T5T11T12T13T14T15T16T17Рисунок 86.
Пример сетевой диаграммы проекта.•Оценив время выполнения и трудоемкость каждой из работ, можно построить сетевуюдиаграмму проекта, пример которой приведен на Рис. 86. Расшифровка названий работ, ихтрудоемкости и время выполнения приведены ниже, в Таблице 13.298КодНазваниеT1T2T3T4T5T6T7T8T9T10T11T12T13T14T15T16T17Формулировка целей и содержания проектаСбор и анализ требованийРазработка архитектурыПервичное планированиеРазработка маркетинговых документовРеализация прототипаДетальное проектированиеИспытания прототипаАнализ результатов испытаний и изменения проектаДетальное планированиеРазработка и отладка пользовательского интерфейсаРазработка пользовательской документацииРеализацияТестированиеДоработка по результатам тестированияРазвертываниеОбучение пользователейТрудоемкость, ч⋅мес0.63.06.00.60.33.06.00.61.01.03.02.08.04.04.01.52.0Время, мес0.31.02.00.30.31.02.00.30.30.31.01.02.01.01.00.50.5Таблица 13.
Работы проекта, сетевая диаграмма которого показана на Рис. 86.Если связи между работами в сетевой диаграмме превратить в вершины, а вершины-работыв связи (и добавить две новых вершины — начало и конец проекта), то получится такназываемая PERT-диаграмма (PERT — program evaluation and review technique, техникаоценки и обзора программ).
PERT-диаграмма, соответствующая приведенной ранеесетевой, показана на Рис. 87. Часто различий между этими двумя видами диаграмм неделают, называя обе и сетевыми, и PERT-диаграммами.T6T1T2T3T8T4T7T5T16T9T10T11T14T13T12T15T17Рисунок 87. PERT-диаграмма для рассматриваемого примера проекта.Сетевые и PERT-диаграммы используются для планирования продолжительности проектаи выделения критических путей — последовательностей работ от начала до концапроекта, сумма длительностей которых максимальна среди таких последовательностей. Впримере, представленном на Рис. 87 критических путей несколько — работы, лежащие наних, изображены жирными стрелками.
Выполнить проект быстрее, чем за время,требующееся для прохождения по критическому пути, нельзя. Поэтому критические путииспользуют для планирования основных поставок в ходе проекта. В нашем примередлительность проекта не может быть меньше, чем 10.7 месяцев. Кроме того, любаязадержка в одной из работ, попавшей на критический путь, обязательно вызовет задержкупроекта в целом, значит, такие работы требуют повышенного внимания во время проекта.Оценка длительности и трудоемкости работ в виде одного числа чаще всего неудобна иможет привести к неправильным выводам.
На практике используют несколько оценок —максимальную, минимальную, иногда еще и наиболее вероятную. С их помощью можнопополнить набор критических путей и получить более полную информацию о критическихработах в проекте, уточнив планы.299Рисунок 88. Диаграмма Ганта для рассматриваемого примера проекта.Расписание работ удобно изображать с помощью диаграмм Ганта (Gantt chart). Этадиаграмма показывает и связи между работами, и их длительность во времени. ДиаграммаГанта для рассмотренного примера показана на Рис. 88.На этой диаграмме также показаны 4 выделенных группы работ: начало, проектирование,реализация и передача в использование.•Все оценки и планы, сделанные только на основе продолжительностей выполненияотдельных работ, действительны, если у нас имеется достаточно других ресурсов, вчастости — персонала.На следующем шаге (после вынесения предварительной оценки трудоемкости ипродолжительности работ) нужно привязать их к имеющемуся в проекте персоналу идругим ресурсам (оборудованию, материалам и пр.).
При этом может оказаться, чтонекоторые независимые работы не могут проводиться одновременно, поскольку для этогоне хватает ресурсов.Рисунок 89. График рассматриваемого проекта, построенный с учетом доступных ресурсов.Допустим, что в нашем примере, как первичное планирование, так и разработкамаркетинговых документов требуют полной вовлеченности менеджера проекта. При этомвторая работа может быть начата только после окончания первой. В разработкепользовательского интерфейса могут быть задействованы аналитик, проектировщикинтерфейсов и программист.
При ограниченности команды проекта это потребуетувеличить время на выполнение работы по реализации. Итоговая картина послеперепланирования рассматриваемого проекта для команды из менеджера, аналитикатестировщика, архитектора, трех программистов, один из которых также является300•проектировщиком пользовательского интерфейса, и еще одного тестировщика, способногописать техническую документацию, показана на Рис. 89. Она отличается от предыдущейизменениями, удлинившими проект на 0.5 месяца.Естественно, после учета доступных ресурсов критические пути проекта могут измениться.Кроме того, риски, связанные с непредвиденными ситуациями, неаккуратной оценкойвозможностей персонала или технологий и пр., требуют наличия определенных временныхи ресурсных резервов при планировании проектов.В ходе самого проекта необходимо тщательно следить за выполнением запланированныхработ в срок, за доступностью ресурсов, отслеживать проблемы, способные привести ксрыву графика, а также неучтенные при первоначальном планировании факторы.
Реальныедлительности и трудоемкости работ могут отличаться от оценочных, что потребуетпостроения новых, уточненных планов проекта. Грамотная отработка изменений в планах ирасписаниях — ничуть не менее важная задача, чем их первоначальное составление. Вчастности, чем быстрее менеджер проекта проинформирует о возможных или необходимыхизменениях заказчика, спонсора и других лиц, тем более он может рассчитывать на ихпонимание и помощь в решении проблем проекта.Специфика управления персоналомВ силу того, что на поведение человека оказывают влияние многочисленные факторы, включаяпсихологические и социальные, люди, работающие в проекте, не могут рассматриваться какобычные ресурсы. Люди склонны по-своему оценивать всю информацию, ставшую им доступнойразными путями, преломлять ее через призму своего личного, уникального опыта и характера, ипоступать, на первый взгляд, нерационально. Человеку чаще всего недостаточно слов «Вот задача,вот зарплата, — давай, работай!», чтобы начать делать то, что от него хотел бы руководительпроекта.Перечислить все особенности управления персоналом достаточно трудно.
Ниже приведенсписок лишь некоторых из них, тех с которыми весьма часто приходится сталкиваться напрактике.• Производительность.Одной из наиболее специфических черт управления персоналом при разработке ПОявляются особенности производительности людей. Разработка программ остается вбольшой степени творческой деятельностью, требует зачастую очень специальных знанийи умений, глубокого понимания вопросов организации информации и аккуратногопланирования работы, поэтому нельзя ожидать от людей, участвующих в ней, каких-тосредних показателей производительности. Опыт и многочисленные эксперименты [10,11]показывают, что производительность отдельных разработчиков в терминах объема икачества создаваемых ими программ за единицу времени может различаться до 10 раз, иэтот разрыв можно наблюдать и в рамках одной организации, и в одной команде.На производительность человека, занимающегося обдумыванием вопросов организацииПО, большое влияние оказывает окружение.
Эта работа, с одной стороны, требуетпогружения, и разработчику необходимо достаточно много времени проводить вуединении, вдали от шума и суеты. С другой стороны, иногда требуется консультацияэксперта, мнение руководителя или просто информация от других сотрудников по какомуто вопросу. Тишина, когда это нужно, и общение, когда оно необходимо, в правильномсочетании позволяют очень быстро продвигаться в решении трудных задач. А любая другаяих комбинация — шум на рабочем месте и отсутствие возможности вовремяпосоветоваться со специалистом — часто катастрофически сказывается напроизводительности такого труда.Определение индивидуальной производительности труда является одним из краеугольныхкамней управления персоналом в большинстве проектов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
