В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 82
Текст из файла (страница 82)
Пример структуры работ проекта, построенной на основе декомпозиции задач.Обе составляющие содержания проекта, конечно же, требуют подтверждения узаинтересованных лиц. Только после определения этих двух элементов можно проводитьобоснованное планирование работ и ресурсов для их выполнения, определение конфигурацийпроекта, необходимых для его выполнения инструментов и технологий и возможных рисков.293Пропуски в структуре работ выливаются в неожиданные работы и возрастание затрат как времени,так и денег на проект в целом.При разработке структуры работ можно взять за основу набор задач, полученныхдекомпозицией целей и задач проекта в целом, или набор промежуточных результатов(deliverables), предаваемых заказчику, который позволит постепенно получить необходимыеитоговые результаты.
Пример структуры задач для гипотетического проекта разработки ПОуправления радаром аэропорта, построенный первым способом, показан на Рис. 83. Аналогичныйпример, построенный вторым способом, показан на Рис. 84.Управление качеством тоже становится возможным, когда выявляются все результаты,которые нужно получить в ходе проекта, и все работы, которые необходимо выполнить. Оновключает выделение ключевых показателей качества для всех результатов, окончательных ипромежуточных, а также выполняемых работ.
Должны быть определены используемые метрикикачества, целевые значения, которые должны быть достигнуты по этим метрикам в ходе проекта,техники, которые позволят обеспечить достижение этих показателей, способы проверки того, чтоони достигнуты, а также процедуры устранения обнаруженных дефектов.Проект разработки системыуправления радаромДоговорПрототипПроектПродуктРаботающая системаТребованияПроектированиеРеализацияУстановкаПланПроектнаядокументацияПользовательскаядокументацияИспытанияКонтроль качестваТестированиеМатериалы дляобученияАнализ проблемБаза запросовРазработкаИспытанияАнализ результатовРисунок 84.
Пример структуры работ проекта, построенной на основе поставляемых результатов.Метрики ПООдна из базовых задач управления ресурсами — адекватная оценка затрат ресурсов наотдельные выполняемые в проекте работы. Такая оценка дает возможность планирования работпроекта и затрат на их проведение. При оценке ресурсоемкости работ основную роль играютвыбранные метрики, с помощью которых измеряется сложность или трудоемкость работ, а такжетребующееся на их выполнение время.При выборе метрик нужно четко определить, что именно мы хотим измерить, и постаратьсянайти измеримый показатель, как можно более близкий к этому. Типичные ошибки состоят как втом, что ничего не измеряется, так и в том, что измеряются вещи, слабо связанные с тем, чтохотелось бы оценивать, лишь бы что-нибудь измерять и заносить в отчеты стройные ряды чисел.Например, измерение времени, проводимого служащим на рабочем месте в качестве мерыинтенсивности его труда и вклада в процветание организации, не вполне адекватно: человекможет занять себя на работе и другими вещами.
Соответственно, введение административных мерпо поощрению «много работающих» и наказанию «мало работающих» только на основании такихизмерений может иметь «неожиданные» последствия — показатели «хорошей работы» будутрасти, а реальная работа не станет выполняться быстрее или лучше.На настоящий момент не существует достаточно адекватных и одновременно простых виспользовании метрик трудоемкости разработки ПО, которые можно было бы оценивать досоздания этого ПО и применять для планирования его разработки. Скорее всего, они и не будут294найдены.
В этой ситуации используются разнообразные эмпирические подходы, комбинирующиепростые в использовании метрики со сложными, но более адекватными.Одна из первых идей, которая приходит в голову при оценке трудоемкости и времениразработки ПО, — оценить сначала сложность или размер программы, а потом умножитьполученную оценку на производительность исполнителей. Похоже, однако, что природаразработки программ такова, что ее трудоемкость слабо связана с размерами результата(например, приводимая ниже модель COCOMO, описанная ниже, выражает эту связь в достаточносложном виде).
Часто оказывается, что оценить сразу трудоемкость по аналогии с имеющимсяпримерами можно точнее, чем оценив сначала размер. Тем не менее, метрики размера исложности ПО часто используются для оценки трудоемкости разработки.Самой простой и наиболее широко используемой метрикой является размер программы встроках ее кода (lines of code, LOC). Ее основное достоинство — понятность и простотавычисления. Ее недостатки — не очень хорошая адекватность в качестве метрики трудоемкостиразработки программы, зависимость от используемых языков и технологий и трудностьпредварительной оценки размера ПО. Практика показывает, что качественная программа частоимеет несколько меньший объем, чем программа с теми же функциями, но менее удобная длясопровождения или совершающая больше ошибок. В то же время на разработку первойпрограммы может уйти в два-три раза больше усилий.С другой стороны, производительность разных разработчиков очень сильно отличается, нообычно руководители групп и организаций примерно представляют себе среднее значение погруппе или организации.
В терминах строк кода она обычно лежит в пределах от 5000 до 50000строк хорошо отлаженного кода без учета комментариев за 1 человеко-год.Более хитрой метрикой сложности программы являются функциональные точки (functionalpoints, FP) [4,5]. Количество функциональных точек в программной системе вычисляетсяпримерно следующим образом.ввод данныхСистемавывод данныхПользовательзапросвнешние файлывнутренние файлыРисунок 85.
Схема рассмотрения системы при оценке ее сложности в функциональных точках.•Выделяются обращения к системе с целью ввода данных, с целью получения каких-то ужеимеющихся в ней данных (отчеты), и с запросами, в ходе которых данные вводятся всистему, перерабатываются и выдаются какие-то результаты. Дополнительно определяютсягруппы взаимосвязанных данных (называемые файлами) внутри системы и аналогичныегруппы, лежащие вне ее, но используемые в ее работе.• Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале«низкая»-«средняя»-«высокая»).• Итоговая сложность программной системы вычисляется как сумма сложностей выявленныхотдельных представителей этих пяти категорий.
Сложность ввода, вывода, запроса илигруппы данных вычисляется умножением оценки сложности составляющих данных навесовой коэффициент, который можно найти в стандартах [4,5] или определить на основесобственного опыта. Обычно весовые коэффициенты групп данных больше, чемкоэффициенты для вводов, выводов или запросов.Количество строк кода, приходящихся на одну функциональную точку, зависит отиспользуемых технологий и языка программирования и меняется от 300 для программирования наассемблере до 5-10 для компонентных технологий на базе языков высокого уровня.295Другие исходные элементы используются при подсчете так называемых объектных точек [6].В этом случае рассматриваются экраны, формы и отчеты, присутствующие в системе, классы, атакже модули, написанные на необъектных языках.
Сложность каждого из таких элементовоценивается отдельно, после чего их сложности складываются, тоже с разными весовымикоэффициентами для разных категорий элементов.Обе эти метрики хорошо применимы к так называемым информационным системам, т.е.системам, основные функции которых связаны с накоплением и хранением больших объемовданных, а также с предоставлением доступа и интерактивной обработкой запросов к ней. Оценка втаких терминах компилятора, системы обмена сообщениями или автоматизированной системынавигации корабля будет менее адекватной.Наиболее известным методом оценки трудоемкости и времени проекта, основанным набольшом количестве данных из проведенных ранее проектов, является конструктивная модельстоимости версии II (Constructive Cost Model II, COCOMO II) [7-9].В рамках этой модели оценки трудоемкости проекта и времени, требующегося на еговыполнение, определяются тремя разными способами на разных этапах проекта.• На самых ранних этапах, когда примерно известны только общие требования, апроектирование еще не начиналось, используется модель состава приложения (ApplicationComposition Model).
В ее рамках трудоемкость проекта оценивается в человеко-месяцах поформуле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 = (размер нового кода в тыс.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
