Файл: Лекции по программной инженерии.pdf

ВУЗ: Не указан

Категория: Лекция

Дисциплина: Программная инженерия

Добавлен: 25.10.2018

Просмотров: 6987

Скачиваний: 27

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

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

 

Характеристики и технико-экономические показатели программного 
средства.
 
 
 
Труднее всего обосновать технико-экономические показатели разработки 
комплекса  программ  в  начале  проекта,  когда  еще  не  сформировались 
достаточно  четкие  представления  о  функциях  и  свойствах  ПС, 
подлежащего разработке. На базе этих оценок желательно сделать общий 
вывод,  стоит  ли  заниматься  данным  проектом  в  дальнейшем  и  на  каких 
условиях следует заключить контракт на его выполнение. Когда разработ-
ка  программного  проекта  близится  к  завершению,  с  целью  уточненного 
оценивания ТЭП следует учитывать некоторые дополнительные аспекты и 
спецификации. Однако общую смету, время работы над проектом и объем 
необходимых трудозатрат необходимо оценивать как можно раньше. При 
этом  целесообразно  поэтапно  рассматривать  ряд факторов,  влияющих на 
технико-экономические  показатели  разработки  ПС,  представленные  в 
таблице  №1,  которые  в  данном  разделе  используются  как  основа  для 
последовательности их изложения. 
 
При оценке стоимости проекта и количества времени, требуемого для его 
выполнения,  предстоит  выполнить  два  основных  этапа.  Первый  этап 
состоит  в  оценивании  размера  -  масштаба  проекта,  на  втором  этапе 
представление об этих размерах наряду с информацией о других факторах 
среды  разработки  используется  для  оценивания  трудозатрат  и, 
соответственно, стоимости и продолжительности работ. 
 
 

Оценка  технико-экономических  показателей  программных  средств. 
 

 

Основными ресурсами у разработчиков при создании сложных комплексов 
программ  являются:  допустимые  трудозатраты  на  разработку  ПС  с 
требуемым  качеством;  время  -  длительность  полного  цикла  создания 


background image

программного  продукта;  необходимое  и  доступное  число  специалистов 
соответствующей квалификации. Потребность в этих ресурсах в наибольшей 
степени  зависит  от  размера  -  масштаба  и  сложности  разрабатываемого  ПС. 
Когда впервые рассматривается масштаб нового проекта ПС, интуитивные и 
экспертные  оценки  его  трудоемкости  могут  отличаться  от  конечного 
значения примерно в полтора раза в ту или другую сторону. Рисунок 1 иллю-
стрирует  достоверность,  с  которой  могут  быть  получены  оценки 
трудоемкости или стоимости ПС, представленные в виде функции этапа ЖЦ 
(горизонтальная ось), или уровень знаний о предполагаемой работе над ПС. 
Такая  достоверность  оценок  обусловлена  уровнем  неопределенности  на 
данном  этапе  знаний  о  конечном  содержании  и  возможном  размере 
программного продукта. Хотя на рис.1 представлена симметричная картина, 
общая тенденция состоит в том, что на начальных этапах оценки затрат чаще 
всего 

занижаются. 

 
 
Эта  неопределенность  уменьшается  по  мере  детализации  и  углубления 
содержания  и  функций  проекта,  как  только  фиксируются  конкретные 
принципы  функционирования  и  концепция  ПС.  На  этом  этапе  оценка 
достоверности 

размера 

уменьшается 

приблизительно 

до 

40%. 

 

 

 

Рис.1 
 
 
Это  вполне  объяснимо,  поскольку  еще  не  уточнены  структура  и  многие 
детали  проекта.  Эти  вопросы  могут  быть  разрешены  во  время  разработки 
структуры и спецификаций требований к ПС и тогда можно оценить размер 
ПС с точностью до 15 -20%. После завершения разработки и подтверждения 
проектных  спецификаций  при  детальном  проектировании  комплекса  про-


background image

грамм  может  быть  определена  структура  внутренних  данных  и  функции 
программных  компонентов.  На  этом  этапе  оценка  размера  и  трудоемкости 
проекта  может  составить  около  10%.  Неопределенности  оценок  могут  быть 
обусловлены:  особенностями  конкретных  алгоритмов,  управления  их 
работой, обработки ошибок, инициализации и завершения сеансов работы и 
т.д. Эти уточнения размеров ПС и компонентов могут быть решены к концу 
детального проектирования, однако при этом сохраняется неопределенность 
оценки  размера  комплекса  программ  и  его  трудоемкости  порядка  5  -  10%, 
связанная с тем, насколько хорошо программисты понимают спецификации, 
в  соответствии  с  которыми  они  должны  кодировать  программу.  Основной 
вывод,  вытекающий  из  рис.1,  состоит  в  необходимости  быть  последова-
тельным при определении исходных данных при оценке ТЭП для различных 
компонентов 

программного 

продукта 

и 

этапов 

проектирования. 

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

важнейших 

факторов 

и 

характеристик 

проекта. 

 
 


background image

 
 

Рис.2 
 
 
При 

оценках 

ТЭП 

 

целесообразно 

учитывать: 

 
-  цели  оценивания  ТЭП  должны  быть  согласованы  с  потребностями  в 
информации,  способствующей  принятию  решений  на  соответствующем 
этапе 

проекта 

ПС; 

 
 
-  достоверность  оценок  ТЭП  должны  быть  сбалансированы  для  различных 
компонентов  системы  и  величина  уровня  неопределенности  для  каждого 
компонента  должна  быть  примерно  одинаковой,  если  в  процессе  принятия 
решения 

все 

компоненты 

имеют 

одинаковый 

вес; 

 
- следует возвращаться к предшествующим целям оценивания и изменять их, 
когда  это  необходимо  для  ответственных  бюджетных  решений, 
принимаемых  на  ранних  этапах  и  влияющих  на  следующие  этапы. 
 
 
Измерение  размера,  оценка  и  составление  графика  разработки  сложным 
образом  переплетаются  в  процессе  планирования  проекта.  На  самом  деле 
довольно  сложно  создать  реальный  график  (учитывающий  обязанности 
исполнителей, их зависимости, перекрытие действий, а также дату поставки 


background image

продукта)  без  информации  об  объеме  трудозатрат,  требуемых  для 
выполнения каждой задачи (например, определения нагрузки сотрудников на 
месяц).  Достаточно  трудно  оценить  объем  трудозатрат,  необходимых  для 
выполнения  задачи,  без  достоверной информации относительно  ее размера. 
Таким образом, измерение размера (сложности) предшествует оценке ТЭП, а 
эта  оценка,  в  свою  очередь,  предшествует  составлению  графика  работ. 
Каждое из этих важных действий проекта может быть выполнено с помощью 
различных  методик.  Недостаточно  достоверные  оценки  влекут  проблемы 
взаимодействия  разработчика  с  заказчиком  и  увеличивают  степень  риска 
проекта. 
 
 
В индустрии ПС часто обращаются к использованию метрики LОС, единицы 
измерения,  хорошо  знакомой  практикам  в  области  разработки  ПС.  Они 
находят  ее  комфортной  и  простой  в  применении.  Какая  бы  технология  не 
использовалась, оценка размера будущего продукта является весьма важной, 
поскольку  она  является  частью  одной  наиболее  важной  задачи  проекта: 
установка  реальных  ожиданий.  Нереальные  ожидания,  основанные  на 
неточных  оценках,  представляют  собой  одну  из  частых  причин  провала 
проектов.  
Зачастую  причина  кроется  не  в  недостаточной  производи-
тельности  команды  проекта,  а  в  неточном  предвидении  уровня  этой 
производительности  и  размера  проекта.  Точное  оценивание  ТЭП 
обеспечивает  улучшенный  контроль  над  проектом  и  является  жизненно 
важным  в  деле  проектного  менеджмента.  Для  обеспечения  точного 
оценивания  в  первую  очередь  следует  иметь  представление  относительно 
размера продуцируемого ПС. Эта величина должна определяться на ранних 
стадиях  цикла  разработки  и  выражаться  в  единицах,  которые  являются 
достаточно 

простыми. 

 
 
Исходные  данные  реальных  завершенных  разработок  для  оценивания  ТЭП, 
собираются, накапливаются и обрабатываются, с начала 70-х годов в разных 
отечественных  организациях  и  за  рубежом.  Они  позволили  получать  и 
прогнозировать  основные  обобщенные  технико-экономические  показатели 
процессов  разработки  ПС.  При  этом  компоненты  операционных  систем, 
драйверы,  средства  контроля  и  тестирования,  а  также  повторно 
используемые компоненты обычно не учитывались при оценке размера вновь 
созданных  комплексов  программ  и  трудоемкости  их  полной  разработки. 
Поэтому  технико-экономические  показатели  проектов  этого  периода  можно 
отнести к полностью оригинальным разработкам комплексов программ. При 
этом  обычно  рассматривался  полный  технологический  процесс  разработки 
ПС  от  начала  подготовки  технического  задания  (ТЗ)  до  завершения 
испытаний  базовой  версии  ПС.  Учитывались  все  категории  специалистов, 
участвующих  в  создании  программ  и  обеспечивающих  разработку,  а  также 
все  виды  работ,  связанные  с  созданием  программного  продукта  на