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

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

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

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

Добавлен: 25.10.2018

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

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

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

и  различные  посредники,  организационные  и  торговые  структуры,  а  также 
исполнители проекта. 

В  начале  проектирования  ПС  всегда  возникает  задача  оценивания 

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

 

создание  и  весь  жизненный  цикл  комплекса  программ  и/или  базы 

данных  ориентируется  разработчиком  на  массовое  тиражирование  и 
распространение  на  рынке,  для  заранее  не  известных  покупателей-
пользователей  в  различных  сферах  применения,  при  этом  отсутствует 
приоритетный внешний потребитель-заказчик, который определяет и диктует 
основные требования, а также финансирует проект; 

 

разработка  проекта  ПС  и/или  БД  предполагается  поставщиком 

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

Первый сценарий базируется на маркетинговых исследованиях рынка 

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

фактором 

конкурентоспособности 

ПС 

является 

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

Для  удовлетворения  потребностей  пользователей,  необходимы  их 

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


background image

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

Потенциальные  покупатели-пользователи  перед  приобретением  ПС 

обычно  оценивают  конкурентоспособность  новой  продукции  на  рынке  по 
величине отношения

 

возможной  экономической  эффективности  (ценности)  применения 

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

 

к стоимости (цене), которую требуется заплатить пользователям при 

приобретении  и  эксплуатации  данного  комплекса  программ  или  базы 
данных. 

При  выборе  предполагаемого  продукта  и  поставщика,  покупатель 

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

вариантов 

реализации 

ПС 

ведется 

по 

показателю 

эффективность/стоимость  для  пользователей,  с  учетом  прогнозов 
конкурентоспособности и возможностей распространения на рынке. 

Такие  проекты  чаще  относительно  не  велики  по  объему  и  срокам 

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

Второй  сценарий  предполагает  наличие  определенного  заказчика-

потребителя  проекта  ПС,  который  определяет  основные  технические  и 
экономические 

требования 

и 

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

Он 

выбирает 

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


background image

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

Однако  для  заказчика  и  разработчика  перед  заключением  контракта 

необходим достаточно достоверный системный анализ, прогнозированием 
технико-экономическое  обоснование  (ТЭО)  требуемых  ресурсов  по 
трудоемкости, 

стоимости, 

срокам 

и 

другим 

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

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

Жизненный  цикл  ПС  можно  разделить  на  две  части,  существенно 

различающиеся 

экономическими 

особенностями 

процессов, 

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

зависят 

от 

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

объекта, 

технологии 

и 

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

Многие молодые программисты - "художники" лихо утверждают, что 

они могут "писать" программы со скоростью тысяч строк в неделю. Однако 
такие  программы  способны  решать  относительно  небольшие,  автономные 
задачи с неизвестным и, как правило, низким качеством, не поддерживаются 
полноценной документацией и не соответствуют требованиям стандартов на 
программный  продукт.  Исследования  последних  десятилетий  показали,  что 
при разработке крупномасштабных комплексов программ  реальная средняя 
производительность  
разработчиков  почти  на  два  порядка  ниже  таких 
оценок  и  измеряется  только  несколькими  десятками  строк  в  неделю.  При 
этом  средняя  стоимость  разработки  одной  строки  полностью  новой 
программы высокого качества, составляет свыше 10$ и достигает 100$. При 
таком  анализе,  естественно,  должен  учитываться  весь  цикл  разработки, 
начиная  от  подготовки  технического  задания,  до  завершения  успешных 
квалификационных испытаний,  а  также  весь  коллектив  участников  проекта, 


background image

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

Ориентирами  для  оценивания  необходимых  ресурсов  трудоемкости, 

длительности и числа специалистов по крупным этапам работ, при создании 
сложных  ПС  высокого  качества,  могут  служить  данные,  опубликованные  в 
[5,6].  В  табл.  1  представлен  вариант,  относительного  распределения  затрат 
ресурсов  по  этапам  работ  для  сложных  встроенных  ПС  реального  времени, 
который  можно  использовать  как  базу  для  приближенных  оценок. 
Соотношение  затрат  по  этапам  в  процентах  достаточно  инвариантно  для 
различных по объему и сложности проектов и для ориентировочных оценок 
может  быть  пересчитано  в  реальные  значения  с  учетом  размера  ПС, 
доступных ресурсов и средней производительности труда в фирме. 

Максимум  трудоемкости  и  числа  специалистов  приходится  на  этапы 

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

 

Относительная трудоемкость, длительность и число специалистов при 

разработке сложных программных средств 

Табл. 2. 

Этапы жизненного 
цикла 

Относительная 
трудоемкость 
этапа работ (%) 

Относительная 
длительность 
этапа работ (%) 

Относительное 
число 
специалистов  на 
этапе (%) 

1. Анализ 
требований к 
программам и 
планирование 

22 

25 

2. Архитектурное 

16 

22 

40 


background image

проектирование 
программного 
средства 
3. Детальное 
проектирование 
программного 
средства 

26 

18 

60 

4. Кодирование и 
тестирование 
программных 
компонентов 

28 

18 

100 

5. Интеграция, 
квалификационное 
тестирование и 
испытания 
программного 
средства 

22 

20 

70 

 

 

 

Вторая  часть  ЖЦ,  отражающая  эксплуатацию,  сопровождение, 

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

Вследствие этого в широких пределах могут изменяться трудоемкость 

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

СТАНДАРТЫ, РЕГЛАМЕНТИРУЮЩИЕ КАЧЕСТВО ПРОГРАММНЫХ