Lecture16 (1133573), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Скорее всего, они и не будутнайдены. В этой ситуации используются разнообразные эмпирические подходы, комбинирующиепростые в использовании метрики со сложными, но более адекватными.Одна из первых идей, которая приходит в голову при оценке трудоемкости и времениразработки ПО, — оценить сначала сложность или размер программы, а потом умножитьполученную оценку на производительность исполнителей.

Похоже, однако, что природаразработки программ такова, что ее трудоемкость слабо связана с размерами результата(например, приводимая ниже модель COCOMO, описанная ниже, выражает эту связь в достаточносложном виде). Часто оказывается, что оценить сразу трудоемкость по аналогии с имеющимсяпримерами можно точнее, чем оценив сначала размер. Тем не менее, метрики размера исложности ПО часто используются для оценки трудоемкости разработки.Самой простой и наиболее широко используемой метрикой является размер программы встроках ее кода (lines of code, LOC).

Ее основное достоинство — понятность и простотавычисления. Ее недостатки — не очень хорошая адекватность в качестве метрики трудоемкостиразработки программы, зависимость от используемых языков и технологий и трудностьпредварительной оценки размера ПО. Практика показывает, что качественная программа частоимеет несколько меньший объем, чем программа с теми же функциями, но менее удобная длясопровождения или совершающая больше ошибок. В то же время на разработку первойпрограммы может уйти в два-три раза больше усилий.С другой стороны, производительность разных разработчиков очень сильно отличается, нообычно руководители групп и организаций примерно представляют себе среднее значение погруппе или организации.

В терминах строк кода она обычно лежит в пределах от 5000 до 50000строк хорошо отлаженного кода без учета комментариев за 1 человеко-год.Более хитрой метрикой сложности программы являются функциональные точки (functionalpoints, FP) [4,5]. Количество функциональных точек в программной системе вычисляетсяпримерно следующим образом.ввод данныхСистемавывод данныхПользовательзапросвнешние файлывнутренние файлыРисунок 85. Схема рассмотрения системы при оценке ее сложности в функциональных точках.•Выделяются обращения к системе с целью ввода данных, с целью получения каких-то ужеимеющихся в ней данных (отчеты), и с запросами, в ходе которых данные вводятся всистему, перерабатываются и выдаются какие-то результаты.

Дополнительно определяютсягруппы взаимосвязанных данных (называемые файлами) внутри системы и аналогичныегруппы, лежащие вне ее, но используемые в ее работе.• Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале«низкая»-«средняя»-«высокая»).• Итоговая сложность программной системы вычисляется как сумма сложностей выявленныхотдельных представителей этих пяти категорий. Сложность ввода, вывода, запроса илигруппы данных вычисляется умножением оценки сложности составляющих данных навесовой коэффициент, который можно найти в стандартах [4,5] или определить на основесобственного опыта. Обычно весовые коэффициенты групп данных больше, чемкоэффициенты для вводов, выводов или запросов.Количество строк кода, приходящихся на одну функциональную точку, зависит отиспользуемых технологий и языка программирования и меняется от 300 для программирования наассемблере до 5-10 для компонентных технологий на базе языков высокого уровня.Другие исходные элементы используются при подсчете так называемых объектных точек [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).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:ƒ надежность продукта;ƒ сложность продукта;ƒ размер базы данных разрабатываемого приложения;ƒ требуемый уровень повторного использования;ƒ требуемый уровень документированности;ƒ уровень производительности по времени;ƒ уровень требований к занимаемой оперативной памяти;ƒ изменчивость платформы;ƒ возможности аналитика проекта;ƒ возможности программистов;ƒ опыт работы команды в данной предметной области;ƒ опыт работы команды с используемыми платформами;ƒ опыт работы команды с используемыми языками и инструментами;ƒ уровень текучести персонала в команде;ƒ возможности используемых инструментов;ƒ возможности общения между членами команды;ƒ фактор сжатия графика проекта.Для тех, кто уже отчаялся понять все хитросплетения этой модели, скажем, что имеютсяпрограммные инструменты, автоматизирующие расчеты по ее формулам.Управление ресурсамиВ данном разделе рассматриваются вопросы управления ресурсами проекта, исключаяспецифические аспекты, касающиеся только персонала.Одной из основных задач управления ресурсами является планирование проекта на основеимеющихся ресурсов и оценок ресурсоемкости отдельных работ, а также доработка планов привозникновении изменений в ходе проекта, связанных с неожиданными работами, изменениемоценок или изменением доступных ресурсов.При разработке графика проекта нужно выполнить следующие действия.• Уточнить имеющуюся структуру работ проекта для того, чтобы использовать ее в рамкахвыбранного процесса разработки.

Например, структура работ может соответствоватьнабору функций, которые должны иметься в результирующем продукте. Использованиепроцесса XP может потребовать составить план поставок не в соответствии с наборамипоставляемых функций, а в соответствии с понедельным планом поставок. В этом случаетяжело предвидеть наборы функций, которые будет иметь очередная поставляемая версияпродукта, но можно спланировать еженедельные поставки, их обкатку у пользователей,анализ результатов и доработки по его итогам.• Установить зависимости между отдельными работами, присутствующими в уточненнойструктуре работ проекта. Зависимости могут иметь разный характер: финиш-старт (работаможет быть начата только после конца другой), старт-старт (работа может быть начататолько с началом другой), старт-финиш и финиш-финиш. Если вы встречаете болеесложную зависимость типа «работу можно начать, только если сделана некоторая частьдругой», это признак того, что работы декомпозированы недостаточно детально и нужноразбить вторую работу на части.Вставив фиктивные работы, не требующие ресурсов и времени, можно все зависимостипривести к виду финиш-старт.T1T2T3T4T6T7T8T9T10T5T11T12T13T14T15T16T17Рисунок 86.

Характеристики

Список файлов лекций