В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 83
Текст из файла (страница 83)
В ее рамках трудоемкость проекта оценивается в человеко-месяцах поформулеEffort = A*Size.o Size представляет собой оценку размера в терминах экранов, форм, отчетов,компонентов и модулей будущей системы. Каждый такой элемент оценивается скоэффициентом от 1 до 10 в зависимости от своей сложности.o Коэффициент A учитывает возможное переиспользование части компонентов ипроизводительность разработки, зависящую от опытности команды и используемыхинструментов и оцениваемую числом от 4 до 50.A = (100 - (процент переиспользования))/производительность.• На следующих этапах, когда требования уже в основном известны и начинается разработкаархитектуры ПО, используется модель этапа предварительного проектирования (EarlyDesign Model) и следующие формулы.Для трудоемкости (в человеко-месяцах):Effort = A*(Size)B*ME + (трудозатраты на автоматически генерируемый код)Для времени (в месяцах):Time = T*EffortS(0.28+0.2*(B-1.01))*Sced.o Коэффициент A считается равным 2.45, а T считается равным 3.67.o Size — оценка размера ПО в тысячах строк кода.o B — фактор процесса разработки, который вычисляется по формуле:B = 0.91 + 0.01*Σi=1..5Wi,где факторы Wi принимают значения от 0 до 5: W1 — предсказуемость проекта для данной организации, от полностью знакомого (0)до совсем непредсказуемого (5); W2 — гибкость процесса разработки, от полностью определяемого командой привыполнении общих целей проекта (0) до полностью фиксированного и строгого (5); W3 — степень удаления рисков, от полной (0) до небольшой (5), оставляющей около80% рисков; W4 — сплоченность команды проекта, от безукоризненного взаимодействия (0) добольших трудностей при взаимодействии (5); W5 — зрелость процессов в организации, от 0 до 5 в виде взвешенного количестваположительных ответов на вопросы о поддержке ключевых областей процесса вмодели CMM (Лекция 2).296•o ME — произведение семи коэффициентов затрат, каждый из которых лежит в интервалеот 1 до 6: возможности персонала; надежность и сложность продукта; требуемый уровень повторного использования; сложность платформы; опытность персонала; использование инструментов; плотность графика проекта.o EffortS обозначает оценку трудоемкости без учета плотности графика, а Sced —требуемое сжатие времени выполнения проекта.После того, как разработана архитектура ПО, оценки должны выполняться сиспользованием постархитектурной модели (Post-Architecture Model).Формула для трудоемкости (в человеко-месяцах):Effort = A*(Kreq*Size)B*MP + (трудозатраты на автоматически генерируемый код)Для времени — та же формула, что и в предыдущей модели (в месяцах):Time = T*EffortS(0.28+0.2*(B-1.01))*Sced.o Size = (размер нового кода в тыс.
строк) + 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 месяца.Естественно, после учета доступных ресурсов критические пути проекта могут измениться.Кроме того, риски, связанные с непредвиденными ситуациями, неаккуратной оценкойвозможностей персонала или технологий и пр., требуют наличия определенных временныхи ресурсных резервов при планировании проектов.В ходе самого проекта необходимо тщательно следить за выполнением запланированныхработ в срок, за доступностью ресурсов, отслеживать проблемы, способные привести ксрыву графика, а также неучтенные при первоначальном планировании факторы.
Реальныедлительности и трудоемкости работ могут отличаться от оценочных, что потребуетпостроения новых, уточненных планов проекта. Грамотная отработка изменений в планах ирасписаниях — ничуть не менее важная задача, чем их первоначальное составление. Вчастности, чем быстрее менеджер проекта проинформирует о возможных или необходимыхизменениях заказчика, спонсора и других лиц, тем более он может рассчитывать на ихпонимание и помощь в решении проблем проекта.Специфика управления персоналомВ силу того, что на поведение человека оказывают влияние многочисленные факторы, включаяпсихологические и социальные, люди, работающие в проекте, не могут рассматриваться какобычные ресурсы. Люди склонны по-своему оценивать всю информацию, ставшую им доступнойразными путями, преломлять ее через призму своего личного, уникального опыта и характера, ипоступать, на первый взгляд, нерационально.