Методологические основы

Выбор состава и оценку факторов, влияющих на ТЭП конкретного проекта ПС, предварительно целесообразно проводить по шагам при ка­либровании модели COCOMO II на основе совокупности 22 факторов из таблицы 5.8. Первоначально должна производиться оценка коэффициен­тов влияния пяти групп факторов — F (j ). В выражениях (5.4), (5.5) значения М (i) отражают коэффициенты влияния /-ых факторов на трудо­емкость разработки ПС, которые первоначально (все п ) считаются равны­ми единице. Предварительный расчет трудоемкости и длительности раз­работки ПС при М ( i) = 1 может служить уточненным ориентиром, так как он базируется на более точном значении размера проекта комплекса программ и более адекватных значениях основных коэффициентов, чем в методике 2.

Выбирать и учитывать следует те факторы, коэффициенты влияния которых на трудоемкость в конкретном проекте имеют достаточную вели­чину, сбалансированную с точностью определения размера комплекса про­грамм или превышают ее. Эти факторы можно разделить на две группы, которые существенно различаются по степени влияния на трудоемкость разработки ПС. В первую группу — F (j) следует включать, кроме разме­ра и доли повторно используемых компонентов, совокупность факторов, которые способны изменять трудоемкость в несколько (до 3—5) раз:

• 
  новизну проекта комплекса программ;
  
• 
  необходимую степень согласованности проекта с требованиями технического задания;
  
• 
  наличие управления рисками и архитектурой проекта;
  
• 
  уровень обобщенной слаженности и организованности коллектив­ной разработки проекта;
  
• 
  уровень обеспечения и оснащения технологии разработки по оцен­ке СММ.
  

• 
  Вторую группу — М (i) следует выбирать из совокупности перечис­ленных в таблице 5.8 семнадцати факторов, таких, которые в конкретном проекте могут повлиять на изменение трудоемкости разработки на 10— 20%, соизмеримое с точностью оценок размера ПС:
  

• 
  требования надежности ПС;
  
• 
  требования степени соответствия документации программному про­дукту;
  
• 
  тематическая квалификация специалистов;
  
• 
  технологическая квалификация проектировщиков и программистов;
  
• 
  стабильность состава коллектива разработчиков;
  
• 
  ограничения ресурсов объектной ЭВМ реального времени;
  
• 
  стабильность требований заказчика к задачам и функциям ПС.
  

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

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

• 
  ЛЕКЦИЯ 6
  РАЗРАБОТКА ТРЕБОВАНИЙ
  К ПРОГРАММНЫМ СРЕДСТВАМ
  

1. 
   Организация разработки требований
   к сложным программным средствам
   

• 
  Проекты программных средств различаются по уровню сложности, масштабу и необходимому качеству. Они имеют различное назначение, содержание и относятся к разным областям применения. Поэтому суще­ствует потребность в четко организованном процессе, методах формали­зации и управления требованиями к конкретным программным продук­там. Чаще всего проблемами, с которыми встретились не достигшие своих целей проекты программных продуктов, являются: недостаток инфор­мации от пользователя или заказчика о функциях проекта, неполные, некорректные требования, а также многочисленные изменения тре­бований и спецификаций. Это происходит потому, что зачастую разра­ботчики и заказчики считают, что «даже если мы не очень точно знаем, чего хотим достичь, лучше быстрее приступить к реализации проекта, так как мы и так выбились из графика и нам некогда размышлять. Мы можем уточнить требования позднее». Подобный подход приводит к хаотичес­ким, неупорядоченным действиям при разработке ПС, когда никто не знает, что на самом деле хочет заказчик и пользователь и как в действи­тельности функционирует созданная на данный момент система и/или программный продукт.
  
•