Справочник от Автор24
Программирование

Конспект лекции
«Экономика программной инженерии заказных программных продуктов»

Справочник / Лекторий Справочник / Лекционные и методические материалы по программированию / Экономика программной инженерии заказных программных продуктов

Выбери формат для чтения

pdf

Конспект лекции по дисциплине «Экономика программной инженерии заказных программных продуктов», pdf

Файл загружается

Файл загружается

Благодарим за ожидание, осталось немного.

Конспект лекции по дисциплине «Экономика программной инженерии заказных программных продуктов». pdf

txt

Конспект лекции по дисциплине «Экономика программной инженерии заказных программных продуктов», текстовый формат

ИНСТИТУТ СИСТеМНОГО ПР ОГРАММИР ОВАНИЯ РАН В.В. Липаев Экономика программной инженерии заказных программных продуктов Учебное пособие МОСКВА — 2014 УДК 330.46:004.4(075.8) ББК 65.39:32.973.26-018.2я73 Л61 Дополнение к учебному пособию «Программная инженерия сложных заказных программных продуктов» Л61 Липаев В.В. Экономика программной инженерии заказных программных продуктов: Учебное пособие. ― М.: МАКС Пресс, 2014. ― 148 с. ISBN 978-5-317-04799-3 В учебном пособии представлены основы экономики производства сложных программных продуктов высокого качества, которые базируются на традиционных принципах и методах экономики разработки сложных технических систем. Создание таких программных продуктов, связанных с большими затратами, определяет необходимость строгого планирования, формализации и стандартизации производственных процессов, а также экономического контроля и сопровождения, подобных при производстве других крупных промышленных изделий. Для конкретизации рассматриваемых задач и процессов изложены основы экономики программной инженерии промышленного производства программных продуктов. Представлены факторы, определяющие экономику технологии создания компонентов и комплексов программ, основные современные методы прогнозирования их трудоемкости, длительности и числа необходимых специалистов для проектирования и производства программных продуктов высокого качества с учетом их характеристик и ограниченных ресурсов. УДК 330.46:004.4(075.8) ББК 65.39:32.973.26-018.2я73 ISBN 978-5-317-04799-3 © Липаев В.В., 2014 © Институт системного программирования РАН, 2014 Оглавление Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Глава 1. Основы экономики индустриального производства заказных программных продуктов . . . . . . . . . . . . . . . . . . . . . . . 5 9 9 Задачи анализа современной экономики программной инженерии Задачи создания и организации экономически эффективного проектирования и производства программных продуктов . . . . . . 17 Задачи подготовки и обучения специалистов для экономически эффективного проектирования и производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Глава 2. Экономические характеристики для оценивания производства программных продуктов . . . . . . . . . . . . . . . . . . . . 32 Статистические исследования экономики производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Характеристики трудоемкости производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Характеристики длительности производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Вспомогательные характеристики производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 41 45 50 Глава 3. Основные факторы, определяющие экономические характеристики производства программных продуктов . . . . . . 55 Основные факторы, определяющие сложность производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Единицы измерения сложности и размера программ для экономического анализа их производства . . . . . . . . . . . . . . . . Масштаб — размер комплексов программ по числу строк текста и объему занятой памяти компьютера . . . . . . . . . . . . . . . . . 55 61 65 Глава 4. Характеристики качества программных продуктов, влияющие на экономику их производства . . . . . . . . . . . . . . . . . 71 Влияние качества программных продуктов на экономические характеристики производства . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Стандартизированные характеристики качества сложных программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Глава 5. Модели прогнозирования экономических характеристик производства программных продуктов . . . . . . . 84 Методы прогнозирования экономических характеристик производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . Экспертное прогнозирование экономических характеристик производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . Простейшие модели прогнозирования экономических характеристик производства программных продуктов . . . . . . . . . 84 89 93 Глава 6. Модель прогнозирования экономических характеристик производства программных продуктов СОСОМО II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Основные компоненты модели СОСОМО II . . . . . . . . . . . . . . . . . 100 Влияние масштабных факторов производства программных продуктов СОСОМО II при прогнозировании экономических характеристик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Требуемые характеристики программных продуктов . . . . . . . . . . 110 Влияние свойств специалистов при прогнозировании экономических характеристик производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 ГЛАВА 7. Влияние технологической среды производства при прогнозировании экономических характеристик . . . . . . . 126 Влияние аппаратной вычислительной среды при прогнозировании экономических характеристик производства программных продуктов . . . . . . . . . . . . . . . . . . . . . . 132 Глава 8. Учебные примеры прогнозирования экономических характеристик по модели СОСОМО II . . . . . . . . . . . . . . . . . . . . 137 Обобщенные графики основных экономических характеристик производства программных продуктов по параметрам, представленным в таблице 8.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Литература . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Приложение. Перечень основных стандартов, регламентирующих проектирование и производство заказных программных продуктов . . . . . . . . . . . . . . . . . . . . . . . 146 4 Введение При подготовке контракта на производство заказного программного продукта заказчику и менеджерам необходимо оценивать не только требования к функциональным характеристикам программного продукта, но и ресурсы — экономические характеристики, которые способны удовлетворить договаривающиеся стороны. Для небольших, относительно простых проектов программных продуктов во многих случаях достаточно достоверными могут быть интуитивные оценки требуемых экономических ресурсов, выполняемые опытными руководителями, реализовавшими несколько аналогичных проектов. Однако интуитивные оценки руководителями размеров и сложности крупных программных проектов, как правило, отличаются большими ошибками при планировании необходимых ресурсов и экономических характеристик. Начиная разработку крупного проекта, руководители, прежде всего, должны решить задачу — целесообразно ли его создание и оценить, какова будет возможная эффективность применения готового продукта, оправдаются ли затраты на их разработку и использование. Поэтому такие проекты должны начинаться с прогнозирования, анализа и технико-экономического обоснования (ТЭО) предстоящего жизненного цикла предполагаемого программного продукта. Однако менеджеры и разработчики комплексов программ, как правило, не знают даже основ экономики промышленного производства сложной продукции, а экономисты современного технического производства не представляют экономическую сущность и свойства объектов разработки — программных продуктов, особенности экономики технологических процессов — их проектирования, производства и применения. Задача экономического прогнозирования проектов в программной инженерии заключается, прежде всего, в разработке, освоении и использовании достаточно точных методов для оценивания экономических характеристик производства сложных программных продуктов. Накоплен и опубликован значительный объем полезных методических и статистических данных об экономических характеристиках создания программных комплексов разных классов. Наиболее полные исследования, обобщения и экономические характеристики реализованных проектов отражены 5 в американских книгах и в отечественных работах. Изучение и освоение этих данных совместно с результатами других авторов позволили заложить основы экономики производства сложных программных продуктов, методик прогнозирования необходимых ресурсов для разработки комплексов программ, их достоверного экономического планирования и формирования производственных процессов с учетом затрат ресурсов. Этим проблемам значительное внимание уделяется в программной инженерии при изложении практических методов производства сложных программных продуктов. Цель экономического обоснования проектов комплексов программ состоит в помощи заказчикам и руководителям их производства определять: ●● целесообразно ли проводить или продолжать работы над конкретным проектом программного продукта для детализации требований, функций и экономических характеристик или следует его прекратить вследствие недостаточных ресурсов специалистов, времени или большой трудоемкости производства; ●● при наличии достаточных ресурсов следует ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта и производства программного продукта для поставки заказчику или на рынок; ●● достаточно ли полно и корректно формализованы требования заказчика к проекту, на основе которых проводились оценки экономических характеристик, или их следует откорректировать и выполнить повторный анализ с уточненными исходными данными; ●● есть ли возможность применить готовые, повторно используемые компоненты, в каком относительном количестве от всего комплекса программ, и рентабельно ли их применять в конкретном проекте или весь проект целесообразно разрабатывать как полностью новый. Интуитивные оценки требуемых экономических ресурсов, выполняемые даже опытными руководителями, реализовавшими несколько аналогичных проектов больших размеров, сложности, трудоемкости и сроков создания конкретных программных проектов, как правило, отличаются существенными недостатками и ошибками вследствие того, что человек в основном 6 оптимистичен, многим руководителям проект комплекса программ представляется меньше по размеру, более простым и дешевым, что ведет к первоначальным недооценкам его сложности и к конфликтным ситуациям между заказчиками и разработчиками. Следствием этого являются большие ошибки и катастрофы при планировании экономических характеристик — сроков, трудоемкости и стоимости создания программных продуктов. Это приводит к значительному запаздыванию завершения разработок и превышению предполагавшихся затрат ресурсов. Вследствие пренебрежения тщательным экономическим обоснованием по некоторым исследованиям до 15% проектов сложных программных комплексов не доходит до завершения, а почти половина проектов не укладывается в выделенные ресурсы, бюджет и сроки, не обеспечивает требуемые характеристики качества. Типичны ситуации, когда отставание сроков внедрения больших промышленных систем управления и обработки информации полностью зависит от неготовности для них программных продуктов. Массовое создание сложных и дорогих программных продуктов промышленными методами и большими коллективами специалистов (в основном для военных систем) вызвало необходимость их достоверного экономического прогнозирования и анализа, четкой организации производства, планирования работ по затратам, этапам и срокам реализации. Для решения этих задач еще в 80-е годы начала формироваться новая область знания и инженерная дисциплина — экономика создания сложных программных продуктов. Необходимо было специалистам освоить анализ и оценивание конкретных факторов, влияющих на экономические характеристики проектов программных продуктов вследствие реально существующих и потенциально возможных воздействий и ограничений ресурсов проектов комплексов программ. Это привело к появлению новой области экономической науки и практики — экономики программной инженерии заказных программных продуктов как части экономики в промышленности и вычислительной технике в составе общей экономики некоторых предприятий. Развитие этой области экономики связано с большими профессиональными и психологическими трудностями, типичными для новых разделов современной науки и техники, появляющимися на стыке различных областей методов и знаний. Широкий спектр 7 технических характеристик таких объектов, ряд количественных и качественных факторов и невысокая достоверность оценки их значений определяют значительную трудность при попытке описать и измерить свойства и качество, создаваемых или используемых сложных программных продуктов, для их экономической оценки и прогнозирования необходимых ресурсов при их создании. Однако часто разработчики не в состоянии привести заказчику или руководителю проекта достаточно обоснованные доказательства нереальности выполнения выдвигаемых требований к продукту при предложенных ограниченных значениях бюджета и сроков. Руководители конкретных проектов обычно не в состоянии достаточно обоснованно определять, сколько времени и затрат труда потребуется на каждый этап проекта системы, и не могут оценить, насколько успешно выполняется план производства. Это, как правило, означает, что проект системы с самого начала выходит из-под экономического контроля и возможна катастрофа с реализацией и завершением проекта всей системы в требуемый срок с заданным бюджетом и качеством. Для развития «экономики программной инженерии» требуются обобщения и освоения накопленного опыта и опубликованных данных в этой новой области экономики. Для квалифицированного прогнозирования и отслеживания экономики на различных этапах производства сложных комплексов программ необходимо обучение специалистов новой экономической профессии по специальной программе в составе общей квалификации «программная инженерия». Такие специалисты — экономисты должны входить в состав проектных коллективов или предприятий, создающих сложные программные продукты. При изложении производственных процессов, которые являются основой для определения экономических характеристик программных продуктов, ниже активно используются международные стандарты их жизненного цикла. Данный учебник следует рассматривать как экономическое дополнение к учебному пособию «Программная инженерия сложных заказных программных продуктов». Его полезно использовать при обучении экономике совместно с проектированием и производством конкретных сложных программных продуктов высокого качества. 8 Глава 1 Основы экономики индустриального производства заказных программных продуктов Задачи анализа современной экономики программной инженерии Накоплен и опубликован значительный объем полезных методических и статистических данных об экономических характеристиках создания программных комплексов разных классов. Наиболее полные исследования, обобщения и экономические характеристики реализованных проектов отражены в двух книгах Б. Боэма. В учебнике автором приведены также некоторые результаты собственных оригинальных исследований. Анализ этих данных совместно с результатами других авторов позволил заложить основы экономики производства сложных заказных программных продуктов, методик прогнозирования необходимых ресурсов для разработки комплексов программ, их достоверного экономического планирования и формирования производственных процессов. Новизна и отсутствие твердо установленной терминологии в данной области привели к необходимости интерпретации некоторых использованных характеристик и терминов. Сложные комплексы программ являются компонентами систем, реализующими обычно их основные, функциональные свойства и создающими предпосылки для последующего развития и изменений их жизненного цикла (ЖЦ). Производство программных продуктов, методология управления и изменения программ зависит от многих факторов, от экономических ресурсов, квалификации специалистов, технических, организационных и договорных требований и сложности проектов. При экономическом анализе жизненного цикла сложных программных комплексов целесообразно выделять два крупных этапа: анализ факторов, 9 влияющих на экономику производства конкретных программных продуктов, и прогнозирование их экономических характеристик. Множество текущих состояний и модификаций компонентов в жизненном цикле сложных комплексов программ менеджерам необходимо упорядочивать, контролировать их развитие и реализацию участниками проекта. Организованное, контролируемое и методичное отслеживание динамики проектирования и производства, а также изменений в жизненном цикле программ и данных, их разработка при строгом учете и контроле ресурсов является базовой проблемой эффективного, поступательного развития каждого крупного комплекса программ и системы методами программной инженерии. Основным способом совершенствования производства программных продуктов и повышения квалификации специалистов в этой области многие менеджеры считают накопление и распространение опыта наиболее успешных разработчиков, который выражается в быстром продвижении проектов. Однако, повышая квалификацию только отдельных разработчиков, невозможно решать современные проблемы производства сложных программных продуктов. Производительность индивидуального труда наиболее квалифицированных и продуктивных разработчиков может во много раз превышать производительность менее способных, в то время как численность последних в такое же число раз превышает численность первых. Кроме того, опыт наиболее продуктивных специалистов не может быть применен коллективами специалистов в промышленных масштабах, поскольку ориентирован на людей с исключительными способностями. Для удовлетворения требований к производству сложных программных продуктов должны быть исключены надежды на расточительное использование таланта уникальных, высококвалифицированных разработчиков, в том числе для выполнения рутинных повторяющихся процессов, чтобы они могли больше времени тратить на постановку, формализацию и организацию производства коллективами сложных программ. Реализация крупных программных проектов встречается со сложными проблемами, тем не менее быстро возрастает как общий объем производства программных продуктов, так и сложность отдельных проектов. Однако многие предприятия, 10 занимающиеся производством программных продуктов, не уделяют должного внимания экономике и эффективному применению современных методов организации, автоматизации и обеспечения всего жизненного цикла программных комплексов. Эти проблемы и их компоненты в разной степени могут отражаться на экономических характеристиках, качестве и конкурентоспособности программных продуктов, на них целесообразно обращать внимание и по возможности решать заказчикам, руководителям и разработчикам сложных программных проектов. Начиная разработку крупного проекта, руководители, прежде всего, должны решить задачу целесообразно ли его создание и оценить, какова будет возможная эффективность применения готового продукта, оправдаются ли затраты на разработку и использование. Поэтому такие проекты традиционно должны начинаться с анализа и экономического обоснования предстоящего жизненного цикла и эффективности использования предполагаемого программного продукта — рис. 1.1. Экономическое обоснование проектов на начальном этапе их производства должно содержать оценки экономических рисков реализации поставленных целей, обеспечивать возможность планирования и выполнения жизненного цикла продукта или указывать на недопустимо высокий риск его реализации и целесообразность прекращения проектирования и производства. Задача экономического анализа проектов в программной инженерии заключается, прежде всего, в разработке, освоении и использовании методов для оценивания экономических характеристик производства сложных программных продуктов. Цель экономического обоснования проектов комплексов программ состоит в помощи их руководителям определять: • целесообразно ли проводить или продолжать работы над конкретным проектом программного продукта для детализации требований, функций и экономических характеристик или следует его прекратить вследствие недостаточных ресурсов специалистов, времени или возможной трудоемкости производства; • при наличии достаточных ресурсов следует ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта и производства программного продукта для поставки заказчику или на рынок; 11 • достаточно ли полно и корректно формализованы тре- бования к проекту, на основе которых проводились оценки экономических характеристик, или их следует откорректировать и выполнить повторный анализ с уточненными исходными данными; • есть ли возможность применить готовые, повторно используемые компоненты, в каком относительном количестве от всего комплекса программ и рентабельно ли их применять в конкретном проекте или весь проект целесообразно разрабатывать как полностью новый. За последние несколько лет ряд исследований и работ по сбору и обобщению экономических данных о производстве программных продуктов заложили основы для методов и моделей оценивания затрат, которые обладают удовлетворительной точностью. Современная экономическая модель оценки их производства считается хорошей, если с ее помощью можно оценить затраты на программные комплексы с точностью около 20%, при условии использования модели, на которые она ориентирована. Имеющиеся модели не всегда столь точны, как хотелось бы, но могут весьма существенно помочь при экономическом анализе и обосновании решений создания сложных программных продуктов. Для сбора и обобщения экономических характеристик о производстве программных продуктов необходимо детально исследовать требуемые ресурсы для современных процессов создания и использования комплексов программ различных классов и назначения. Скоординированное применение методов, стандартов и инструментальных средств в процессах производства, развития и применения комплексов программ позволяет исключать многие виды дефектов или значительно ослаблять их влияние. Тем самым экономические характеристики производства и уровень достигаемого качества становится предсказуемым и управляемым, непосредственно зависящим от ресурсов, выделяемых на их достижение, а главное, от системы качества и эффективности технологий, используемых на всех этапах жизненного цикла. Основными целями упорядочивания, регламентирования планирования, этапов и процессов производства программных комплексов являются: • снижение трудоемкости, длительности, стоимости и улучшение всех характеристик программных продуктов; 12 • повышение качества разрабатываемых и/или применяе- мых компонентов и программных комплексов в целом при их производстве, сопровождении и эксплуатации; • обеспечение возможности расширять комплексы программ по набору прикладных функций, совершенствовать и масштабировать их в зависимости от изменения решаемых задач, внешней среды и потребностей заказчика; • обеспечение переносимости прикладных программ и данных между разными аппаратными и операционными платформами и повторного использования программных компонентов в различных проектах. Одна из важнейших задач состоит в том, чтобы увязать четкими экономическими категориями взаимодействие разных специалистов и предприятий в типовой производственной цепочке: заказчик — проектировщик — производитель — пользователь. Для этого объект — программный продукт и все процессы взаимодействия в такой цепочке должны быть связаны системой экономических и технических характеристик, в той или иной степени использующих основные экономические показатели — реальные затраты ресурсов: финансов, труда и времени специалистов на конечный продукт. Это позволит создавать теоретические и практические основы современной экономики производства сложных программных продуктов. Крупные заказные программные продукты являются одними из наиболее сложных объектов, создаваемых человеком, и в процессе их производства — творчество специалистов как поиск новых методов, альтернативных решений и способов осуществления заданных требований, а также формирование и декомпозиция этих требований составляют значительную часть всех трудозатрат. Индустриализация производства комплексов программ позволяет автоматизировать многие не творческие, технические и рутинные операции и этапы, а также облегчать творческие процессы за счет селекции, обработки и отображения информации, необходимой для принятия творческих решений. Следствием этого должно являться значительное сокращение доли затрат на творческий труд в непосредственных затратах на разработку комплексов программ. 13 Задачи и основные особенности экономики проектирования и производства программных продуктов включают: ¡¡ задачи анализа современной экономики проектирования и производства сложных программных продуктов: • экономические характеристики предприятий при проектировании и производстве программных продуктов; • классификация экономических характеристик производства и факторов, влияющих на экономику программных продуктов; • сбор и обобщение экономических характеристик производства реальных программных продуктов; • анализ планирования и достоверность прогнозирования экономических характеристик программных продуктов; • оценивание и выбор квалифицированных специалистов — подрядчиков для производства программных продуктов; ¡¡ задачи создания и организации экономически эффективного проектирования и производства сложных программных продуктов: • создание и освоение методов и технологий экономического обоснования производства программных продуктов; • формирование требований, эффективных экономических и технологических решений производства программных продуктов; • обеспечение экономических характеристик, предсказуемого и управляемого уровня качества программного продукта; • отслеживание изменений экономических характеристик комплексов программ с учетом затрат ресурсов; • обеспечение и удостоверение требуемых функций и качества готового программного продукта в процессе испытаний; ¡¡ задачи подготовки и обучения специалистов для экономически эффективного проектирования и производства программных продуктов: • подготовку специалистов, ответственных за оценивание экономических характеристик процессов производства; • формирование «команды» квалифицированных специалистов для экономически эффективного производства программного продукта; • выделять и обучать специалистов, ответственных за анализ и прогнозирование экономических характеристик производства; • организацию структуры коллективов для экономически эффективного производства программных продуктов; • обучение и подготовку руководителей и специалистов по экономике производства сложных программных продуктов. Рис. 1.1 14 В программной инженерии неуклонно повышаются размеры и сложность создаваемых продуктов, что вызывает возрастание затрат творческого труда на единицу размера новых программ. В перспективе, несмотря на автоматизацию и повышение инструментальной оснащенности технологии производства комплексов программ, доля творческого труда при создании полностью новых крупных программных продуктов возрастает. Даже при сокращении суммарных затрат на разработку программных компонентов за счет автоматизации нетворческого труда все более определяющей для экономических характеристик создания программных продуктов становится доля затрат на творческий труд и возрастают требования к творческим способностям при отборе и обучении специалистов. По мере повышения квалификации коллективов и автоматизации творческой части труда следует ожидать асимптотического приближения проектов к предельным значениям относительных экономических характеристик новых разработок. Эти значения определяются интеллектуальными возможностями человека по интенсивности принятия творческих решений. Им соответствуют наличие предельных значений производительности труда и длительности разработки сложных комплексов программ. Для их оценки необходимо изучение и экстраполяция прецедентов и экспериментальных данных реальных разработок программных продуктов с наилучшими экономическими характеристиками с учетом возрастания квалификации специалистов и уровня автоматизации производства. Вряд ли можно ожидать в ближайшие годы радикального повышения производительности труда при создании полностью новых, крупных программных продуктов. Еще более консервативна длительность таких разработок. Ограниченность ресурсов при создании крупных программных продуктов приводит к целесообразности решения задач планирования, упорядочения и применения экономически эффективных методов автоматизации обеспечения ЖЦ комплексов программ с целью достижения требуемого качества и достоверного его определения. Для каждого крупного проекта, выполняющего ответственные функции, необходимо прогнозировать требующиеся ресурсы, разрабатывать и применять комплексную систему качества, специальные планы и Программу, методологию и инструментальные 15 средства, обеспечивающие требуемые качество, надежность и безопасность функционирования программного продукта. Для этого следует применять современные методы и стандарты при подготовке промышленных технологий, методик производства и испытания конкретных продуктов, однозначно отражающих степень удовлетворения исходных требований заказчика и пользователей, а также для сравнения характеристик продуктов разных поставщиков и выявления среди них предпочтительных. Задачи выбора квалифицированных и надежных специалистов-подрядчиков, способных создавать сложные программные продукты и базы данных требуемого качества в разумные сроки с учетом ограничений на используемые ресурсы, стоят остро для многих заказчиков и пользователей современных сложных вычислительных систем. Для их решения поставщикам комплексов программ, кроме программистов-кодировщиков, необходимо иметь системных аналитиков, архитекторов и топ-менеджеров проектов, а также специалистов по комплексированию, испытаниям и обеспечению качества современных сложных программных продуктов. Они должны знать передовые индустриальные методы, технологии и международные стандарты, поддерживающие и регламентирующие жизненный цикл комплексов программ, а также инструментальные системы обеспечения качества, верификации, тестирования и сертификации программных продуктов. Для этого требуется, прежде всего, системотехническая квалификация специалистов предприятий, берущихся за производство сложных заказных программных продуктов высокого качества. Число больших ошибок оценивания экономических характеристик на начальных этапах разработки можно значительно сокращать при относительно небольших усилиях, применяя, в частности, формализованные методики их экспертной оценки. Тем самым такие проекты с самого начала могут выполняться с учетом более достоверной оценки необходимых экономических и других факторов. Большую часть негативных последствий можно избежать, используя существующие, достаточно точные методы оценивания и прогнозирования экономических характеристик, а также управление проектами для их успешного завершения. Внимание должно быть сосредоточено на концептуальной основе анализа и распределения труда в процессе разработки комплексов 16 программ на факторах, определяющих реальные трудозатраты и другие экономические характеристики, а также на исследовании их в реализованных современных разработках. Задачи создания и организации экономически эффективного проектирования и производства программных продуктов Задачи рационального сочетания целей, стратегий действий, конкретных процедур и доступных ресурсов необходимо решать для достижения основной цели — получения программного продукта с заданными функциональными характеристиками и качеством. Базой эффективного управления проектом программного комплекса является план, в котором задачи исполнителей частных работ должны быть согласованы с выделяемыми для них ресурсами, а также между собой, по результатам и срокам их достижения. Планирование программных проектов должно обеспечивать компромисс между требующимися характеристиками создаваемой системы и ограниченными ресурсами, необходимыми на ее разработку и применение. По мере уточнения исходных требований к объекту разработки, внешней среде применения и ресурсам, в процессе системного анализа и проектирования возрастает достоверность планирования, которое должно проходить этапы: ●● обследование объектов и среды проектирования для предварительной формализации целей, назначения и задач проекта; ●● первичное прогнозирование возможных характеристик и требований к программному продукту на базе обобщения данных ранее реализованных подобных прототипов и создание концепции проекта; ●● подготовка предварительного плана выполнения этапов и частных работ с учетом допустимых затрат ресурсов на их реализацию; ●● управление детализацией и реализацией плана производства, его оперативной корректировкой и перераспределением 17 ресурсов в соответствии с особенностями развития компонентов программного комплекса; ●● обобщение и накопление результатов планирования и управления конкретным проектом для использования этих данных в качестве прототипов при производстве программных продуктов. На каждом этапе должены проводиться поиск эффективных технических и экономических решений реализации проекта, исследование и сопоставление альтернативных действий, которые должны приводить к достижению поставленных целей производства программного продукта. В результате процессы планирования проекта и его выполнения обычно развиваются параллельно. Уже при первичном прогнозировании развития проекта должны оцениваться альтернативные характеристики объекта и среды разработки и выбираться наиболее подходящие для производства в соответствии с поставленными целями и имеющимися ресурсами. Сравнение альтернатив следует проводить по величине достигаемого эффекта проекта в зависимости от затрат на его достижение (желательно, по показателю «эффективность/стоимость»). Программные комплексы все больше встраиваются в различные заказные технические системы. Работа с такими проектами требует от программных специалистов широкого взгляда на общие технические и экономические задачи проектирования сложных систем. Менеджерам и аналитикам программных проектов необходимо участвовать в выработке требований для всей системы, а также понимать прикладную область применения продукта еще до начала обдумывания функций компонентов и их интерфейсов, требованиям которых должен будет отвечать программный продукт. Для сокращения затрат необходимы новые технологии, методы создания и управления сложными проектами программных систем. Коренные отличия между методами и инструментарием индивидуального, «художественного» программирования небольших программ и технологией планомерного, регламентированного производства крупных программных продуктов приводят к тому, что последние медленно осваиваются и входят в практику слаженной работы больших коллективов специалистов. Эти обстоятельства отражаются на существенном отставании от мирового уровня 18 по конкурентоспособности, количеству и качеству отечественных заказных программных продуктов. Каждая производственная технология должна быть достаточно зрелой, чтобы быть развернутой в промышленных масштабах, их интеграция включает: ●● разработку архитектур — структур для производства продуктов на основе общих архитектурных стилей; ●● разработку инструментов на базе выбранного языка для поддержки производства продуктов посредством адаптации, конфигурирования и сборки структурных компонентов; ●● использование инструментов проектирования для вовлечения заказчиков и быстрой реакции на изменения требований за счет инкрементного построения программ с сохранением их работоспособности при внесении изменений. Неопределенность применяемых понятий, требований и характеристик качества присуща крупным, наукоемким проектам комплексов программ, однако многочисленные спекуляции разработчиков на их значениях приучила заказчиков не доверять рекламируемым достоинствам производства программных продуктов. Во многих случаях контракты и предварительные планы на создание сложных программных комплексов и баз данных подготавливаются и экономически оцениваются на основе неформализованных представлений заказчиков и разработчиков о требуемых функциях и характеристиках качества систем. Многочисленные провалы проектов выявили необходимость формализации методов взаимодействия и обеспечения взаимопонимания разработчиков с заказчиком или потенциальными пользователями создаваемого продукта с самого начала проекта с целью конкретизации его функций и уточнения требований к качеству. Ошибки, обусловленные неопределенностью или некорректностью технических заданий и спецификаций требований, могут и должны быть выявлены на ранних стадиях проектирования, что способствует его ускорению и повышению качества. Возрастание сложности и ответственности современных задач, решаемых сложными системами, а также возможного ущерба от недостаточного качества комплексов программ значительно повысило актуальность проблемы освоения методов стандартизированного описания требований, оценивания экономических характеристик и качества на различных этапах 19 их жизненного цикла. Выявилась необходимость систематизации реальных характеристик качества программных продуктов, применения стандартов для выбора из них необходимой номенклатуры и требуемых решений для конкретных комплексов программ. Обещания разработчиков в контрактах с заказчиками создать высококачественные продукты в согласованные сроки во многих случаях не выполняются как вследствие различий в понимании требуемого качества, так и вследствие неумения оценить экономические ресурсы, необходимые для достижения заданного качества программ. Стратегической задачей в жизненном цикле современных технических систем стало обеспечение и совершенствование качества производства сложных программных продуктов при реальных ограничениях на использование доступных экономических ресурсов производства. Широкое многообразие классов и видов программ, обусловленное различными функциями систем, предопределяет формальные трудности, связанные с методами и процедурами доказательства соответствия поставляемых продуктов условиям контрактов и требованиям потребителей. По мере расширения применения и увеличения сложности программных продуктов выделились области, в которых ошибки или недостаточное качество программ или данных могут нанести ущерб, значительно превышающий положительный эффект от их использования. В этих критических случаях недопустимы аномалии и дефекты функционирования программных продуктов при любых искажениях исходных данных, сбоях и частичных отказах аппаратуры и других нештатных ситуациях. Задачи формирования требований к характеристикам и качеству программного продукта включают анализ свойств, характеризующих его функционирование с учетом технологических и экономических ресурсных возможностей производства. При этом под качеством функционирования понимается совокупность свойств, обусловливающих пригодность продукта обеспечивать надежное, безопасное и своевременное представление требуемой информации потребителю для ее дальнейшего использования по назначению. В соответствии с принципиальными особенностями программного продукта при проектировании должны выбираться номенклатура и значения требований к характеристикам 20 качества, необходимым для его эффективного применения пользователями, которые впоследствии отражаются в технической документации и в спецификации требований на конечный продукт. Каждый критерий качества может использоваться, если определена его метрика и может быть указан способ ее оценивания и сопоставления с требующимся значением. Для конкретных видов программных продуктов доминирующие критерии качества выделяются и определяются при проектировании систем их функциональным назначением и требованиями технического задания. Качество изменяется в течение жизненного цикла комплекса программ, то есть его требуемое и реальное значение вначале ЖЦ почти всегда отличается от фактически достигнутого при завершении производства и качества поставляемой пользователям версии продукта. На практике важно оценивать качество программ не только в завершенном виде, но и в процессах их проектирования, производства и сопровождения. Кроме того, оценки показателей качества могут быть субъективными и отражать различные точки зрения и потребности разных специалистов. Чтобы эффективно управлять качеством на каждом этапе ЖЦ, необходимо уметь определять и примирять эти различные представления требуемого качества и его изменения. Задача удостоверения достигнутого качества функционирования сложных программных продуктов и методов обеспечения их жизненного цикла базируется на сертификации аттестованными проблемно-ориентированными испытательными лабораториями. Глубокая взаимосвязь качества разработанных комплексов программ с качеством технологии их создания и с затратами на разработку становится особенно существенной при необходимости получения конечного продукта с предельно высокими значениями показателей качества. Непрерывный рост требований к качеству стимулировал создание и активное применение международных стандартов и регламентированных технологий, автоматизирующих процессы их жизненного цикла, начиная с инициирования проекта. Задача анализа экономической эффективности выполнения проекта требует использования сведений, определяющих показатели выполнения применяемых процессов и средств производства. Такие сведения и уроки следует собирать, пока особенности 21 реализации проекта свежи в памяти его разработчиков. Их необходимо применять в процессах производства программных продуктов после завершения основных и промежуточных этапов выполнения проекта, когда они могут оказать влияние на текущее состояние производства и качество программного продукта. Это особенно важно для крупных, продолжительных проектов производства версий программных продуктов. Менеджер проекта должен в самом его начале уведомить коллектив о своем намерении отслеживать все производственные процессы и их экономические характеристики, а также дать им ряд указаний относительно тех сведений, которые будут собираться для анализа. Выполнять анализ весьма важно, поскольку именно здесь уроки могут быть обобщены и переданы по наследству для сохранения в архиве предприятия и дальнейшего совершенствования производственных процессов. Каждое предприятие, занимающееся разработкой заказных программных продуктов, должно создавать архив компонентов и характеристик производственных процессов, который позволяет находить образцы настраиваемых процессов, поддерживать журналы регистрации усовершенствований и изучать уроки, извлеченные из предыдущих проектов. Задачи подготовки и обучения специалистов для экономически эффективного проектирования и производства программных продуктов В жизненном цикле сложных комплексов программ для обеспечения их высокого качества целесообразно выделять специалистов, ответственных за анализ, оценивание и прогнозирование экономических характеристик производства, за соблюдение промышленной технологии создания и совершенствование программных продуктов, за измерение и контроль затрат, качества комплексов программ в целом и их компонентов. Задача состоит в том, чтобы научить специалистов анализу и оцениванию конкретных экономических факторов, влияющих на характеристики функционирования программных продуктов со стороны реально существующих и потенциально возможных негативных воздействий 22 и ограничений ресурсов проектов. Необходима подготовка и воспитание квалифицированных специалистов в области экономики и производства сложных программных комплексов, их обучение методам и современной программистской культуре промышленного создания сложных высококачественных программных продуктов (см. рис. 1.1). В учебнике рассматриваются большие проекты комплексов программ, создаваемые крупными коллективами специалистов. В таких проектах на чистое творчество, искусство и научные исследования отдельных специалистов, преобладающие в небольших индивидуальных разработках, накладывается множество технических работ, характерных для индустриального проектирования и производства программных продуктов. Вследствие этого значительно нивелируются индивидуальные особенности и квалификация отдельных специалистов, и появляется возможность оценивать усредненную производительности труда и другие экономические характеристики крупных коллективов. Программный специалист — это член команды, поэтому должен обладать навыками общения и межличностных отношений, а также уметь планировать не только свою работу, но и координировать ее с работой других специалистов. Анализируемые ниже процессы обычно ограничены временем от этапа оформления требований технического задания на разработку до этапа завершения испытаний опытного образца первой версии программного продукта, соответствующего требованиям заказчика. Задачи выбора, организации структуры и состава коллектива специалистов привели к появлению новых требований к обучению и к дифференциации специалистов по программной инженерии, обеспечивающих основные этапы жизненного цикла комплексов программ. Этим специалистам недостаточно навыков процедурного программирования небольших модулей и компонентов, а необходимы глубокие знания системотехники, технологии и стандартов проектирования, методов обеспечения и контроля качества сложных комплексов программ в определенной области их применения. Эти специалисты должны владеть новой интеллектуальной профессией, обеспечивающей высокое качество программных продуктов, а также испытания и удостоверение реального достигнутого качества на каждом этапе разработки 23 и совершенствования программ. Производство крупных программных продуктов различных классов, разделение труда специалистов по квалификации при разработке программ и данных, структура и организация коллективов, а также экономика таких разработок стали важнейшей частью задачи выбора и обучения коллективов специалистов для обеспечения всего ЖЦ сложных программных продуктов. В жизненном цикле сложных комплексов программ участвуют специалисты различной квалификации и степени ответственности за результаты своей деятельности: ●● заказчики определяют и несут ответственность за требования к функциям и характеристикам качества программного продукта, за финансирование, доступные, адекватные ресурсы для обеспечения его жизненного цикла; ●● разработчики должны гарантировать и отвечать за выполнение требований заказчиков программного продукта с учетом выделенных ресурсов; ●● пользователи имеют право применять программный продукт и адаптировать его к особенностям использования и внешней среды только в пределах, определенных эксплуатационной документацией, созданной разработчиками. Для организации эффективной структуры коллектива разработчиков программных комплексов следует научиться учитывать конкретные цели специалистов, участвующих в проекте, их психологическую совместимость, способность к дружной коллективной работе, опыт взаимодействия в составе определенного коллектива, а также другие объективные и субъективные свойства участников проекта. При этом большое значение могут иметь личная мотивация и психологические особенности поведения разных специалистов при комплексной работе над сложным проектом. Эти характеристики могут быть обобщены в качественный показатель влияния сложности взаимодействия специалистов в коллективе, которому могут быть сопоставлены оценки возможного изменения экономической эффективности производства программного продукта. Наилучшим обычно считается непрерывное корректное взаимодействие организованных специалистов с большим опытом работы в конкретном коллективе при согласованности их целей, планов и методов работы. В остальных случаях в той или иной 24 степени (даже в 3–5 раз) может возрастать трудоемкость производства продукта, что нельзя не учитывать при обосновании крупных проектов. Уровень квалификации заказчика и определенность требований технического задания на производство продукта может сильно влиять на суммарные затраты и длительность создания комплекса программ. Первоначальное, техническое задание зачастую оказывается недостаточно квалифицированным и подвергается в дальнейшем многократным изменениям. Изменения технического задания заказчиком и объем переделок непосредственно отражаются на эффективной производительности труда специалистов производства. Особенно сильно низкая достоверность технического задания может влиять на попытки заказчика форсировать сроки разработки. Этому же может способствовать различие между заказчиком и разработчиком в квалификации, уровне понимания целей разработки и необходимых затрат на реализацию требований. Даже при испытаниях заказчик зачастую обнаруживает, что решаются не совсем те задачи и не совсем так, как ему нужно, вследствие чего может быть необходима большая переработка готовых программ. Даже квалифицированные заказчики вынуждены иногда корректировать техническое задание на любых этапах разработки, что может влиять на снижение экономической эффективности производства на 10–20%. Представители заказчика, участвующие в проекте, должны обучаться формализации автоматизируемых функций систем и технологических процессов, для которых предназначены соответствующие программные продукты, и иметь представление об экономически эффективных путях их реализации. В каждом проекте программного продукта должен быть лидер — руководитель. Лидер должен иметь талант и квалификацию, а также быть обучен решать следующие задачи: ●● руководить процессом выявления, конкретизации и формирования требований заказчика продукта; ●● осуществлять проверку спецификаций требований к программному комплексу, чтобы удостовериться, что они соответствуют реальной концепции заказчика, представленной детальными функциями; ●● вести переговоры с заказчиком, пользователями и разработчиками, определять и поддерживать равновесие между 25 тем, чего хочет заказчик, и тем, что может создать коллектив разработчиков за бюджет, ресурсы и время, выделенные заказчиком для реализации продукта; ●● рассматривать конфликтующие пожелания, поступающие от различных участников проекта и находить компромиссы, необходимые для определения набора функций и характеристик, представляющих наибольшую ценность для максимального числа участников и проекта в целом. При производстве сложных комплексов программ большими коллективами значительно повышается роль квалификации менеджеров — руководителей реализации проекта, что непосредственно отражается на производительности труда всего коллектива. Из-за различной квалификации руководителей проектов суммарные затраты на разработку могут изменяться в несколько раз, как в лучшую, так и в худшую сторону. Некоторые методы организации структуры коллектива и процессов производства позволяют сокращать негативное влияние этого человеческого фактора. Разработчики должны иметь в своем составе квалифицированных менеджеров, проблемно-ориентированных системных архитекторов, способных переводить не всегда полные и корректные функциональные требования заказчика в конкретные спецификации и технические требования к комплексам программ и к их компонентам. Специалисты по проектированию сложных комплексов программ (системные архитекторы) должны иметь, прежде всего, хорошую подготовку по системному анализу алгоритмов и комплексов программ в определенной проблемной области, по методам оценки экономической и технической эффективности проектов, организации и планированию крупных разработок компонентов программ и баз данных. Им необходима высокая квалификация по архитектурному построению, комплексному тестированию и испытаниям компонентов и комплексов программ определенных классов, умение организовать коллектив для решения общей целевой задачи системы. Это позволит на ранних этапах исключать или сокращать дефекты, обусловленные различием представления целей и задач проектов, а также их характеристик качества. Для создания высококачественных комплексов программ, прежде всего, необходимо обучение специалистов процессам 26 организации взаимодействия представителей заказчика и разработчиков проекта. Взгляды и требования заказчика в основном отражаются на функциональных и потребительских характеристиках программного продукта. Устремления разработчиков направлены на способы их реализации с требуемым качеством. Эти различия исходных интересов и точек зрения на проект приводят к тому, что некоторые неформализованные представления тех и других имеют зоны неоднозначности и взаимного непонимания, что может приводить к конфликтам. Организация четкого взаимодействия и сокращение этих зон требует определенных мероприятий и контактов по обмену знаниями в процессе проведения совещаний, взаимному повышению квалификации и обучению. Следует активно привлекать заказчиков к совещаниям по управлению требованиями и масштабом проекта, чтобы обеспечить как качество, так и своевременность производства программного продукта. Необходимы указания и согласия заказчиков при принятии основных изменений и решений, и только они могут реально определить, как, развивая функции, получить полезный комплекс программ высокого качества, выполненный в срок и в пределах бюджета. Для определения проекта и целей заказчика может понадобиться вести с ним переговоры об объеме работ для команды. Во время переговоров с заказчиком о техническом задании и требованиях разработчикам необходимо учитывать неизбежные издержки при производстве комплекса (непредвиденные технологические и экономические риски, изменения требований, задержки при приобретении закупаемых компонентов, непредвиденный уход членов команды), которые могут приводить к существенному нарушению графика реализации продукта. Специалистам команды следует научиться пониманию требований заказчиков, поскольку именно они добиваются успеха при применении программного продукта (см. рис. 1.1). Для производства сложных программных продуктов наиболее часто применяются две схемы организации коллективов, которые должны осваиваться при обучении специалистами: • для выполнения каждого крупного проекта формирование жесткой организационной структуры целостного коллектива с полным составом необходимых специалистов под единым, централизованным руководством лидера проекта; 27 • выделение руководителя (главного конструктора) и не- большой группы интеграторов, по заданиям которых выполняются частные работы узкими специалистами по компонентам, не входящими организационно в единый коллектив для реализации конкретного крупного проекта. Первая схема предпочтительна, когда предприятие реализует небольшое число особенно крупных проектов-заказов и имеет возможность для каждого из них комплектовать полноценную, организационно замкнутую, «команду». Она полностью реализует проект и несет ответственность за его качество. Однако при этом возможны простои отдельных специалистов из-за несинхронного ожидания технических заданий или результатов на последовательных этапах разработки компонентов другими специалистами. Вторая схема может иметь преимущества для предприятия при большом числе относительно небольших проектов, близких по содержанию и функциональному назначению компонентов. В этом случае большинство специалистов одновременно участвуют в нескольких заказах по локальным заданиям лидеров и интеграторов различных проектов и может использоваться более полно. Однако задачи интеграторов, их взаимодействие с поставщиками компонентов, руководство и контроль качества при этом усложняются и требуют более высокой квалификации. В обеих схемах для реализации мероприятий по планированию и управлению жизненным циклом концептуально целостных, крупных продуктов и обеспечения их качества необходимы организационные действия системных архитекторов, направленные на подбор и обучение коллектива специалистов разных категорий и специализаций. Принципиальной задачей улучшения экономических характеристик при производстве сложных комплексов программ является исключение творчества на тех этапах, где возможны типовые, стандартные решения и использование апробированных заготовок программных компонентов, не требующие при их применении высококвалифицированного творческого труда. Основой этого является применение унифицированной технологии, готовых, испытанных программных компонентов и стандартизированной архитектуры определенных классов комплексов программ. Использование готовых апробированных модулей может почти исключать творческий труд по их программированию, автономной 28 отладке и документированию. На этих этапах творческие усилия необходимы для отбора и контроля готовых компонентов, а также для разработки новых, отсутствующих среди апробированных. Однако практически полностью сохраняется творческий труд при системном анализе, при комплексировании компонентов и их комплексной отладке, а также во время испытания программного продукта в целом на соответствие требованиям заказчика. Крупные проекты, как правило, требуют координированной работы больших коллективов или ряда команд. Возрастание сложности производства снижает возможность человека решать задачи интуитивно по мере их возникновения. Чтобы добиться успеха в большом проекте, необходима четкая координация действий членов «команды», которая должна работать по общей утвержденной методологии, чтобы решить проблему реализации требований и качества программного продукта экономически эффективно организованной командой. Одним из наиболее важных факторов является то, что члены команды имеют различные талант, профессиональные навыки и квалификацию. При выборе заказчиком надежного поставщика-разработчика продукта необходима оценка тематической и технологической квалификации возможного коллектива специалистов, а также его способности экономно реализовать проект с заданными требованиями и качеством. Тематическую квалификацию специалистов в области создания сложных комплексов программ определенного функционального назначения приближенно можно характеризовать средней продолжительностью работы в данной проблемной области основной части команды, непосредственно участвующей в разработке алгоритмов, спецификаций требований, программ и баз данных. Технологическая квалификация коллектива характеризуется опытом и длительностью работы с регламентированными технологиями, инструментальными комплексами автоматизации программной инженерии, языками проектирования, программирования и тестирования комплексов программ. По мере накопления эксплуатируемых программных продуктов и их компонентов все большее число специалистов переходит из области непосредственного программирования и тестирования новых программ в область системного проектирования, управления конфигурацией и создания новых версий программного продукта 29 на базе повторно используемых компонентов (см. рис. 1.1). По некоторым оценкам, непосредственным программированием новых компонентов в мире занято только около 15–20% специалистов, участвующих в создании программных продуктов. При организации сопровождения и модернизации крупных программных продуктов следует учитывать важные психологические факторы, усложняющие отбор, обучение и деятельность менеджеров и квалифицированных специалистов в этой области: • эта деятельность требует высокой квалификации, больших творческих и умственных затрат, связанных, прежде всего, с необходимостью одновременного, широкого охвата и анализа множества компонентов и их взаимосвязей, находящихся в различных состояниях завершенности модификаций или устранения дефектов; • корректируемые компоненты зачастую разрабатывались в прошлом: в разное время, различными специалистами, в различном стиле, с неодинаковой и не полной документацией. Это усложняет освоение их содержания при внесении изменений и устранении дефектов; • сложная, творческая сторона работ при сопровождении вуалируется тем, что приходится овладевать и анализировать программы, разработанные ранее другими специалистами, которые зачастую может оказаться проще не корректировать, а разработать заново; • комплексы программ, прошедшие широкие испытания и эксплуатацию у заказчиков, гарантируют достигнутое качество результатов функционирования, и любые в них изменения имеют высокий риск внесения дополнительных ошибок и ухудшения этого качества, что усложняет коренные модификации; • выполняемые работы требуют особой, скоординированной тщательности корректировок и четкого регламентированного взаимодействия ряда специалистов, различающихся квалификацией и уровнем ответственности; • процессы и результаты сопровождения не отличаются наглядностью и внешним эффектом, проявлением их размера и сложности, вследствие чего не престижны среди рядовых программистов и недооцениваются руководителями крупных проектов. 30 Перечисленные выше специализации и квалификации персонала, участвующего в крупных проектах программных продуктов, требуют соответствующей их подготовки, отбора и обучения, которые являются самостоятельной, важной проблемой развития экономики заказной программной инженерии. Должны быть разработаны и документированы планы, требования и цели обучения, а также разработаны учебники и руководства, включая материалы, используемые для обучения. Персонал, ответственный за выполнение конкретных задач, если это необходимо, должен быть аттестован на основе соответствующего образования, подготовки и/или опыта работы. При обучении внимание следует акцентировать на комплексе международных стандартов программной инженерии, которые непосредственно обеспечивают экономически эффективный жизненный цикл сложных высококачественных программных продуктов и баз данных. Необходимо обучение специалистов современной программистской культуре и дисциплине промышленного создания высококачественных программных продуктов. 31 Глава 2 Экономические характеристики для оценивания производства программных продуктов Статистические исследования экономики производства программных продуктов При промышленном проектировании и производстве любой продукции применяются следующие основные экономические характеристики для оценивания производственных процессов и изделий: ●● стоимость — финансовые затраты на создание одного экземпляра или комплекта полноценного продукта, полностью удовлетворяющего требования пользователей; ●● затраты труда — трудоемкость коллектива специалистов, участвующих в создании готового продукта, соответствующего требованиям пользователей; ●● длительность — время, затраченное специалистом или коллективом на проектирование и производство продукта, удовлетворяющего пользователей; ●● число специалистов разной квалификации, участвующих в создании продукта соответствующего требованиям заказчика. Экономический анализ производства программного продукта в денежном выражении имеет ряд существенных особенностей, которые ограничили его применение при оценке и прогнозировании экономики таких проектов по следующим причинам: ●● предприятия, создающие комплексы программ, имеют значительные различия в уровне заработной платы специалистов, что не всегда адекватно отражается на их производительности труда и финансовых затратах; 32 ●● каждое предприятие имеет накладные расходы и налоги, которые могут значительно различаться и никак не влияют на трудоемкость и длительность непосредственного производства программного продукта; ●● весьма различны оснащенности предприятий технологиями и средствами вычислительной техники, а также затраты на их приобретение и эксплуатацию, которые многократно используются для разных проектов; ●● из общих затрат на аппаратуру и эксплуатацию технологических компьютеров и отладочных стендов сложно выделить долю, которую необходимо включать в стоимость производства конкретного программного продукта. Тем не менее при заключении контрактов на производство продуктов и для оценки интегральных экономических характеристик комплексов программ приходится применять величины затрат в денежном выражении. Для этого вырабатываются соглашения (калькуляции) между заказчиком и разработчиком по преодолению перечисленных трудностей при анализе стоимости производства программных продуктов. Суммарные затраты интеллектуального труда специалистов на производство программного продукта — трудоемкость, является основным интегральным экономическим показателем каждого программного проекта. Эти затраты подлежат оценке и минимизации при условии обеспечения заданных функциональных характеристик программного продукта и его качества. На совокупную трудоемкость при создании программного продукта влияет ряд факторов, при определении которых на практике используются различные единицы. Трудоемкость характеризуется временем производительного труда определенного числа специалистов, необходимого для создания программного продукта, его компонентов или выполнения определенного этапа работ в жизненном цикле. Такой подход привел к активному использованию единиц трудоемкости: человеко-день, человеко-месяц, человеко-год (при этом человеко-год предполагается состоящим в среднем из 250 рабочих человеко-дней с учетом выходных и праздничных дней). Подобные единицы трудоемкости позволяют сопоставлять затраты в разных организациях и даже в разных странах на аналогичные по размеру комплексы программ 33 и не зависят от особенностей валюты, налогов и подобных экономических факторов при оценке стоимости. Эти единицы трудоемкости достаточно прочно вошли в практику планирования и оценки процессов производства, вследствие чего являются базовыми в данном учебнике. Длительность производства программного продукта зависит от многих факторов, и прежде всего от его сложности. Технологический процесс создания любых комплексов программ включает ряд базовых этапов, которые обязательно приходится реализовать независимо от затрат. Каждый этап требует некоторого времени, что приводит для конкретных комплексов программ к относительно небольшим (по сравнению с затратами труда) вариациям суммарной длительности производства. Если разработка ведется на достаточно высоком технологическом уровне, то цикл производства сложного программного продукта принципиально трудно сокращать без ущерба для его качества. Число необходимых специалистов и особенности их квалификации неравномерно распределяются по этапам жизненного цикла комплекса программ. На начальные этапы системного проектирования и завершающие этапы испытаний программного продукта требуется относительно небольшое число, но наиболее высококвалифицированных специалистов. На средних этапах разработки и тестирования программных модулей и компонентов в проекте участвует наибольшее число специалистов относительно невысокой квалификации. Однако для оценок и прогнозирования экономических характеристик широко применяется среднее число специалистов. Ему соответствует средняя производительность труда коллектива при производстве полностью нового сложного комплекса программ, которая может служить ориентиром для сравнения эффективности труда при создании различных программных продуктов. Эта характеристика, конечно, различается для различных классов, размеров и других параметров комплексов программ, однако диапазон этих различий не столь велик, как изменения размера, требований к качеству и других параметров. Экономические характеристики производства реальных завершенных проектов программных продуктов 34 собираются, накапливаются и обрабатываются с начала 80-х годов в разных отечественных организациях и за рубежом. Они позволили прогнозировать основные характеристики процессов производства сложных программных продуктов. Учитывались все категории специалистов, участвующих в создании программного продукта и обеспечивающих процессы разработки, а также все виды работ, связанных непосредственно с проектированием и производством программного продукта на выделенном интервале времени. Наиболее важен анализ и учет факторов на начальных этапах производства, когда прогнозируются первичные совокупные затраты на создание комплекса программ. На этих этапах неопределенность оценки характеристик и факторов проекта наибольшая, однако применение прогнозируемых характеристик позволяет избегать крупных ошибок при оценке затрат, которые делаются экспертами без детального анализа влияния ряда важных факторов. Только на базе серьезных статистических исследований экономических характеристик жизненного цикла и практического маркетинга программных продуктов возможны были обобщения и создание теоретических и практических основ экономики производства сложных программных продуктов. Эти задачи требовали для своего решения выполнения крупных, комплексных научно-исследовательских работ. Специалистам важно было исследовать и сформулировать методы экономического анализа, оценивания и прогнозирования необходимых ресурсов для проектов комплексов программ. Тем самым следовало определить базовый фундамент всей экономики производства программных продуктов. Внимание было сосредоточено на концептуальной основе распределения затрат труда в процессе производства программных продуктов, на факторах, определяющих реальные трудозатраты и другие экономические показатели, а также на исследовании таких характеристик в реализованных проектах — рис. 2.1. 35 Экономические характеристики для оценивания производства программных продуктов включают: ¡¡ статистические исследования экономики производства программных продуктов: ●● свойства и особенности основных экономических характеристик производства программных продуктов; ●● организацию и методики статистических исследований экономических характеристик программных продуктов; ●● основные составляющие затрат на производство программного продукта; ●● анализ влияния факторов на экономические характеристики производства программных продуктов; ●● примеры экономических характеристик производства программных продуктов; ¡¡ характеристики трудоемкости производства программных продуктов: ●● определение целей при оценивании трудоемкости производства комплексов программ; ●● факторы, которые целесообразно учитывать при оценке трудоемкости производства программных продуктов; ●● учет предела производительности, доступной разработчику-одиночке, строк новых программ в год; ¡¡ характеристики длительности разработки программных продуктов: ●● особенности фиксирования времени начала и окончания производства программного продукта; ●● определение границ возможного сокращения длительностей производства программных продуктов; ●● определение границ нерационально больших длительностей производства комплексов программ; ¡¡ вспомогательные характеристики производства программных продуктов: ●● среднюю производительность труда коллектива при производстве сложного комплекса программ; ●● оценки требуемого среднего числа специалистов для производства конкретного программного продукта. Рис. 2.1 36 Прежде всего, необходимо было изучение реальных экономических характеристик проектирования и производства современных сложных программных продуктов. Оценки экономических характеристик проектирования и производства сложных комплексов программ далее базируются на двух типах экспериментальных статистических исходных данных. Первый тип основных исходных данных получается анализом и обобщением реальной экономики, результатов трудоемкости и длительности процессов создания предшествующих завершенных сложных комплексов программ. На базе этих данных строятся математические модели для прогнозирования обобщенных экономических характеристик новых проектов с учетом их конкретных факторов. Эти данные путем декомпозиции позволяют определять необходимое число различных специалистов для создания компонентов и сложных комплексов программ, а также их среднюю производительность труда в единицу времени. Второй тип исходных данных получается регистрированием, анализом, обобщением и усреднением индивидуальной производительности труда конкретных специалистов при создании компонентов и комплексов программ. Практически для оценок реальных экономических характеристик проектов часто используется стоимость (например, в долларах) разработки одной строки текста программы. Суммирование этих данных модулей и компонентов позволяет обобщать и прогнозировать экономические характеристики сложных комплексов программ в зависимости от их размеров и характеристик. В некоторых случаях ориентиром затрат (стоимости) на создание особенно сложных программных продуктов реального времени (миллионы строк текста) высокого качества, надежности и безопасности применения может служить соизмеримая с ними стоимость аппаратуры, на которых они функционируют (например, бортовых вычислительных систем в авиации). При этом каждая строка текста программ в таких сертифицированных комплексах может превышать сотни долларов, а средняя производительность труда специалистов в высококвалифицированных коллективах составлять только около одной строки программы в день. Рассматривались преимущественно средние и крупные проекты, создаваемые большими коллективами специалистов. В таких проектах на чистое творчество и научные исследования отдельных специалистов (преобладающие в небольших индивидуальных 37 разработках) накладывается множество технических работ, характерных для индустриального проектирования и производства программных продуктов. Вследствие этого значительно нивелировались индивидуальные особенности и квалификация отдельных специалистов, и появлялась возможность оценивать усредненные характеристики производительности труда и другие экономические характеристики производства в больших коллективах. Анализируемые интервалы времени производственных процессов были ограничены: в основном от этапа оформления требований технического задания на разработку проекта и до этапа завершения испытаний программного продукта, соответствующего требованиям заказчика. Тем самым только попутно рассматривались процессы сопровождения, тиражирования, документирования, внедрения и применения программных продуктов. Процессы формирования рыночной стоимости программных продуктов и маркетинговые исследования в области экономики создания, распространения и продажи массовых промышленных программных средств в те годы обычно не учитывались. Индустриальное, коллективное создание сложных программных продуктов необходимо было структурировать, планировать и поэтапно регламентировать с учетом заданных ограничений сроков и стоимости проектов. Однако обычно у специалистов отсутствовали количественные оценки экономических характеристик на основе статистических данных реально созданных программных продуктов. Задача состояла в том, чтобы детально исследовать реальные экономические показатели достаточно представительного набора завершенных проектов комплексов программ и создать на этой статистической базе методики прогнозирования трудоемкости, длительности и числа необходимых специалистов по этапам работ и интегрально по программным продуктам разных классов и размеров. Наиболее подробно основные закономерности и влияние различных факторов на экономические характеристики процессов производства сложных программных продуктов начались в 80-е годы исследоваться за рубежом. В 1981 году на основе исследования процессов разработки 63 проектов в США была опубликована модель прогнозирования экономических характеристик под названием КОМОСТ. В последующем эта модель была развита, 38 детализирована и опубликована как СОСОМО, а в 2000 году под названием СОСОМО II. В этой модели на основе анализа более 160 реальных проектов разработки программных продуктов различной сложности уточнены рейтинги влияния выделенных факторов на основные экономические характеристики производства. Однако методика сбора статистических данных и детальные характеристики анализировавшихся программных продуктов не опубликованы. Обобщенные данные этих работ ниже используются и рекомендуются как базовые для прогнозирования затрат при создании сложных программных продуктов. Методическим примером статистических исследований экономических характеристик программных продуктов являются данные, полученные в России в НИР ПРОМЕТЕЙ. С этой целью были разработаны методические указания и анкета, разосланные в ряд предприятий для сбора сведений о каждой завершенной промышленной разработке программного продукта. В анкетах предлагалось регистрировать: ●● технические (не функциональные) характеристики и размер объекта разработки; ●● трудовые и временные ресурсы, непосредственно затраченные на проектирование и производство программного продукта; ●● программную, инструментальную оснащенность производства средствами автоматизации технологии; ●● аппаратурную оснащенность производства комплекса программ средствами вычислительной техники. При этом фиксировались основные составляющие затрат на производство программного продукта: ●● трудоемкость и длительность непосредственной разработки программного продукта; ●● среднее число специалистов, участвовавших в проекте; ●● затраты на программные, инструментальные системы автоматизации разработки программного продукта; ●● затраты на технологическую аппаратуру компьютеров, используемую в процессе разработки комплекса программ. При расчете производительности труда разработчиков учитывался труд только на непосредственное производство функциональных компонентов комплекса программ, а при расчете 39 стоимости разработки в целом и одной команды — все перечисленные составляющие затрат. Относительно небольшие затраты на системы автоматизации производства комплексов программ не учитывались, так как были обусловлены многократным применением одних и тех же инструментальных средств для создания различных проектов. Представленные примеры экономических характеристик производства комплексов программ наиболее систематично были собраны, обработаны и проанализированы от поступивших с 30 предприятий оборонной промышленности. Они отражали данные о 171 программном продукте двух классов общим объемом свыше 16 млн. команд. Из них выборки по классам комплексов программ (см. главу 3) составлялись для: ●● класса систем реального времени (СРВ) — 142 проекта, объемом около 10,5 млн. команд; ●● класса административных систем (АС) — 29 разработок объемом около 1,5 млн. команд. Таким образом, выборки данных о комплексах программ классов СРВ и АС были достаточно представительными для достоверных статистических выводов по основным экономическим характеристикам их разработки. Характеристиками проектов являлись как абсолютные экономические показатели (размер, трудоемкость и длительность разработки), так и относительные (производительность труда разработчиков, стоимость разработки одной команды программного продукта). Относительные экономические характеристики позволили сопоставить различные разработки программных продуктов и коллективы разработчиков предприятий по эффективности их труда. За меру производительности труда разработчиков принималось отношение размера поставляемого программного продукта в командах нового исходного текста программ (без учета заимствования из предшествовавших проектов) к трудозатратам на его разработку в человеко-днях. Учитывался только размер программного продукта, прошедшего испытания и переданного на эксплуатацию потребителю без компонентов и версий, разработанных, но не вошедших в окончательный программный продукт. В число специалистов-разработчиков включались основные категории специалистов: руководители разработки, аналитики, системотехники, 40 программисты, тестировщики, а также технический персонал, занятый оформлением текущей и итоговой документации. В результате обработки фактических статистических данных были получены примеры зависимости экономических характеристик от основных факторов, выявлено изменение их во времени, роль применения различных языков программирования, методов доступа к компьютерам, определена реальная обеспеченность разработчиков дисплеями и машинным временем. По классу СРВ в 1986 году производительность труда специалистов в среднем возросла до 2,6 команд на человека в день по сравнению с 1,6 в 1980 году. Производительность труда отечественных специалистов в то время оказалась близка к доступным аналогичным данным специалистов за рубежом. Важнейшей экономической характеристикой производства программных продуктов является ее продолжительность. В 1985 году средняя длительность разработки сложного комплекса программ была: в классе СРВ — 4 года, в классе АС — 2,7 года. Выявлено, что наиболее эффективным направлением для улучшения экономических характеристик производства являлось применение готовых программных компонентов. Заимствование 50% готовых программных компонентов (от общего размера) позволило сокращать длительность разработки в среднем на 25%, а при заимствовании в 80% — в два раза. Однако реальные экономические характеристики производства программных продуктов публикуются очень скупо и оперативно не обобщаются, по-видимому, они считаются коммерческой тайной предприятий, которым не выгодно раскрывать фактические недостатки и неэффективность своих производств. Характеристики трудоемкости производства программных продуктов Обеспечение функциональной пригодности является основной целью при использовании финансовых, трудовых, вычислительных и других ресурсов в жизненном цикле комплексов программ. Однако это не значит, что затраты на решение этой основной 41 задачи всегда являются доминирующими по величине затрат. Необходимость выполнения ряда требований к остальным, конструктивным характеристикам качества (например, надежности) часто приводит к тому, что использование ресурсов на их реализацию может превышать базовые затраты на обеспечение только функциональной пригодности. В то же время затраты на выполнение этих требований всегда направлены на повышение и совершенствование функциональной пригодности. Поэтому обычно трудно четко выделить и количественно оценить все виды затрат, используемых только на реализацию функциональной пригодности. В любом программном комплексе можно выделить компоненты, в которых сосредоточены функциональные алгоритмы и программы, предназначенные для решения основных целевых задач. В некоторые из них органически входят компоненты для повышения качества решения функциональных задач или они построены с учетом требований высокого качества результатов основных функций. При анализе затраты ресурсов в жизненном цикле комплексов программ целесообразно разделить на две части: ●● затраты на создание программных компонентов, обеспечивающих базовые свойства функциональной пригодности комплекса программ для его применения по прямому назначению пользователями, в соответствии с требованиями контракта и технического задания; ●● составляющие дополнительных затрат, обеспечивающие требуемые конструктивные характеристики качества для улучшения функциональной пригодности продукта в соответствии с целями и сферой его применения. Кроме того, следует учитывать совокупность затрат ресурсов на технологию, инструментарий автоматизации производства и систему качества, обеспечивающие жизненный цикл. Эти составляющие затрат зависят не только от характеристик проектируемого комплекса, но и от интенсивности применения технологических средств. Основным ресурсом при производстве сложных комплексов программ являются допустимые трудозатраты на производство программного продукта с требуемым качеством, а также необходимое и доступное число специалистов соответствующей квалификации. Потребность в этих ресурсах в наибольшей степени зависит 42 от размера — масштаба и сложности разрабатываемого продукта (см. главу 3). Когда впервые рассматривается масштаб нового проекта, интуитивные и экспертные оценки его трудоемкости могут отличаться от конечного значения примерно в полтора — два раза в ту или другую сторону. Эта неопределенность уменьшается по мере детализации и углубления содержания и функций проекта, как только фиксируются конкретные принципы функционирования и концепция комплекса программ. На этом этапе оценка достоверности размера и трудоемкости уменьшается приблизительно до 40%. Это вполне объяснимо, поскольку еще не уточнены структура и многие детали продукта. Эти вопросы могут быть разрешены во время разработки структуры и спецификаций требований к комплексу программ и тогда можно оценить его размер с точностью до 15–20%. После завершения разработки и подтверждения проектных спецификаций при детальном проектировании комплекса программ может быть определена структура внутренних данных и функции программных компонентов. На этом этапе ошибки оценки размера и трудоемкости проекта могут составить около 10%. Неопределенности оценок трудоемкости могут быть обусловлены: особенностями конкретных алгоритмов, управления их функционированием; обработкой ошибок; инициализацией и завершением сеансов решения задач. Уточнения размеров комплекса и компонентов могут быть решены к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса программ и его трудоемкости порядка 5–10%, связанная с тем, насколько хорошо специалисты понимают спецификации требований к компонентам, в соответствии с которыми они должны создавать их программы. На начальных этапах производства для прогнозирования его трудоемкости и суммарных затрат необходимо применять рациональные гипотезы об особенностях жизненного цикла конкретного комплекса программ. Даже приблизительный учет распределения вероятных затрат на этапах жизненного цикла позволяет более эффективно использовать экономические ресурсы при создании программного продукта. При этом условия, обеспечивающие минимум суммарных затрат на всем жизненном цикле, могут приводить к необходимости принципиального изменения предполагаемого процесса производства программ, при котором достигается 43 минимум только на интервале производства первой версии продукта. В связи с этим последующий анализ суммарных затрат на разработку может проводиться в двух постановках задачи: автономно на интервале производства первой версии программного продукта без учета последующего его использования и развития, и комплексно с учетом влияния затрат на его эксплуатацию и сопровождение, что должно оговариваться в каждом случае. По мере выполнения проекта экономические оценки комплекса программ необходимо пересматривать и изменять, когда это становится выгодным или необходимым. Можно начинать с определения оценок трудоемкости в соответствии с точностью спецификаций требований с учетом минимума факторов, но при дальнейшем анализе уточнять оценки с точностью до деталей функционирования и с учетом влияния совокупности важнейших факторов и характеристик проекта. Специалисты при производстве программ различаются квалификацией и степенью участия в непосредственной разработке программного продукта. Встречаются особо талантливые программисты, способные создавать очень быстро программные компоненты высокого качества. Однако при любых способностях есть предел, доступный разработчику-одиночке, и он редко превышает 10 тыс. строк новых программ в год. Кроме того, даже в этом случае такому программисту необходима помощь при составлении тестов, оформлении документации, испытаниях и ряде других работ, обеспечивающих превращение программы в программный продукт. При разработке сложных комплексов программ пишут и отлаживают программы модулей и компонентов только около половины общего числа лиц, затраты на которых необходимо учитывать при экономическом анализе. Остальные специалисты осуществляют руководство проектом, проводят системный анализ, исследуют алгоритмы, оформляют документацию, выполняют вспомогательные технические работы. Их труд направлен либо полностью на создание определенного комплекса программ, либо распределяется между несколькими проектами. Если специально не оговаривается, то далее учитывается трудоемкость на программный продукт всех категорий специалистов в соответствии с их долей участия в создании конкретных программ определенного проекта. 44 В ряде исследований трудоемкости размер базы данных либо совсем не учитывается, либо включается в объем программного продукта. В статистической теории сложности программ показано, что для программных модулей и относительно небольших групп программ может быть большая корреляция между числом имен переменных и числом операторов в программе. Однако для сложных комплексов эта корреляция невелика, что определяет целесообразность разделять анализ таких комплексов программ на два типа. Первый тип — осуществляет преимущественно логическую обработку относительно небольшого потока данных, а второй тип — программы административных и информационно-поисковых систем при наличии больших баз данных и относительно простой их логической обработке. Хотя размеры баз данных для сложных заказных комплексов программ по числу типов имен переменных изменяются в очень широких пределах от 103 до 108, их непосредственное влияние на трудоемкость разработки строки текста в программе даже при числе переменных, в десятки раз превышающем размер программы, может оцениваться на уровне 10%. Степень этого влияния трудно формализовать, так как большую роль играет структура базы данных и ее функциональное назначение. Характеристики длительности производства программных продуктов Для учета затрат времени коллектива специалистов на конкретный комплекс программ особенно сложно фиксировать начало разработки. Дело в том, что системный анализ зачастую входит в научно-исследовательские работы, финансируемые, планируемые и учитываемые независимо от начала производства конкретного программного проекта. В ряде случаев первичная разработка концепции комплекса программ является обобщением опыта создания и эксплуатации ранее разработанных, унаследованных программ. Системный анализ, исследования и моделирование алгоритмов иногда в последующем реализуются в нескольких комплексах программ, и весьма трудно оценить долю экономических затрат исследовательских работ, которую следует отнести 45 к каждому конкретному проекту. Перечисленные обстоятельства привели к тому, что затраты на системный анализ и предварительные исследования могут различаться на один — два порядка и обычно не включаются в совокупные экономические затраты на производство конкретного программного продукта, что соответствует практике выделения и отдельного учета финансирования на научно-исследовательские работы в промышленности. При последующем изложении началом разработки считается создание технического задания или спецификации требований, согласуемых с заказчиком и будущими пользователями продукта. Окончанием разработки для прекращения учета затрат при оценке трудоемкости и длительности конкретного производства продукта далее принимается момент завершения межведомственных или государственных испытаний программного продукта и оформления акта соответствующей комиссией заказчика. Однако при анализе реальных проектов эта граница оказывается тоже размытой, как и начальная, хотя и в меньшей степени. Это обусловлено разнообразием видов испытаний, возможностью проведения испытаний по отдельным функциональным задачам, различием методов формализации передачи продукта на эксплуатацию. Ряд факторов и неопределенность достигаемого качества программ приводят к тому, что влияние затрат на длительность разработки имеет размытую характеристику. При изменении размеров сложных комплексов и трудоемкости в широком диапазоне длительность разработки может изменяться мало по сравнению с величиной затрат. Для каждого размера комплекса программ при заданном качестве существует область невозможного сокращения длительности производства, которую не удается преодолеть при увеличении затрат труда — рис. 2.2. Для планирования разработки комплекса программ и регулярного управления этим процессом необходимы частные экономические характеристики в зависимости от различных факторов. Такие показатели могут формироваться: по этапам разработки, на единицу продукции, как относительные затраты на достижение заданной характеристики качества программ или как составляющие суммарных затрат в жизненном цикле комплекса программ. Длительность производства программных продуктов является важнейшей экономической характеристикой, поскольку 46 часто она определяет общие сроки производства систем, а значит, длительность реализации идей и методов в различных областях автоматизации. Диапазону размеров современных программных продуктов в три–четыре порядка (до 10 млн. строк) соответствуют приблизительно такие же диапазоны относительного изменения трудоемкостей и стоимостей их производства. Рис. 2.2 Однако принципиально нерентабельно производство даже очень сложных программных продуктов более 3–5 лет. С другой стороны, комплексы программ даже в несколько тысяч строк по полному технологическому циклу с испытаниями и документацией как продукции редко создаются за время, меньшее, чем полгода–год. Таким образом, вариация длительностей производства программных продуктов много меньше, чем вариация их трудоемкостей, и не превышает десятикратный диапазон. Практически длительность производства программных продуктов ограничена сверху и снизу и одним из основных факторов, определяющим эти границы, является размер комплексов программ. Относительный «консерватизм» значений длительностей по сравнению с трудоемкостью определяется объективной необходимостью создавать программные продукты в рациональные сроки. Любые программные продукты должны поступать на эксплуатацию до того, как в них пропадет необходимость. Их цели, концептуальная основа и алгоритмы не должны устареть 47 за время проектирования и производства. Отсюда появляется верхний предел допустимых длительностей производства. Этот верхний предел не может иметь единственное значение для любых классов и размеров программных продуктов. Однако недопустима его вариация в том же диапазоне, что размера и трудоемкости программного продукта. Поэтому на практике по мере возрастания размеров комплексов программ увеличиваются коллективы специалистов-разработчиков, что обеспечивает основной прирост необходимой трудоемкости. Чем крупнее создаваемый комплекс программ, тем большие усилия обычно прилагаются для автоматизации и совершенствования технологии производства. Это также способствует замедлению роста длительностей разработки, однако по мере увеличения сложности программ длительность их производства все же заметно возрастает. Стремление ограничивать длительность производства программных продуктов приводит к объективному формированию верхнего предела, за которым распространяется зона «нерациональных» длительностей, зависящих от размера и трудоемкости комплекса программ (см. рис. 2.2). Даже для довольно сложных программных продуктов, имеющих размер свыше 500 тыс. строк, вряд ли допустима длительность разработки более 3 лет. Большие длительности, иногда имеющиеся на практике, обусловлены в основном низкой квалификацией разработчиков и заказчиков, недостаточной автоматизацией технологии, малым коллективом специалистов и рядом других, преимущественно организационных и технологических причин. Аналогичные ситуации чаще встречаются при относительно небольших проектах (50–100 тыс. строк), когда у руководителей и коллектива мал опыт их проведения, следствием чего является избыточный «оптимизм» в начале разработки, а также пренебрежение технологией и организацией работ. Границу снизу определяют естественный технологический процесс коллективного производства и необходимость выполнения ряда скоординированных работ на последовательных этапах, которые обеспечивают получение продукта требуемого качества. Подготовка текстов программ, их тестирование, комплексирование, документирование и испытания могут проводиться только последовательно, и каждый этап требует определенного времени. 48 Попытки форсировать отдельные этапы работ, как правило, приводят к увеличению продолжительности других этапов. Подключение дополнительных специалистов увеличивает затраты на разработку и только в небольших пределах дает сокращение сроков. В некоторых случаях увеличение числа специалистов может давать обратный эффект — длительность производства увеличивается вместе с увеличением трудоемкости вследствие роста затрат на взаимодействие специалистов. Под воздействием перечисленных факторов формируется объективный минимум длительностей — граница снизу области «невозможного», зависящая в первую очередь от размеров разрабатываемых комплексов. Нижняя граница длительностей еще более «консервативна», чем верхняя. Изменение этой границы возможно в небольших пределах только за счет совершенствования технологии, повышения программной и аппаратурной оснащенности разработки, а также роста коллективной квалификации разработчиков и заказчиков. Практическая граница «нерациональных» длительностей имеет значения, приблизительно вдвое большие, чем значения границы «невозможных» длительностей, при том же размере программного продукта. Это означает, что даже большие усилия по автоматизации и организации производства комплексов программ приводят к сокращению длительностей только в 2–3 раза, в тo время как трудоемкость уменьшается значительно больше. По результатам реальных проектов может быть оценена средняя или наиболее вероятная, длительность производства программных продуктов определенного класса и размера при заданных условиях. Конкретное распределение длительностей можно оценивать на основе исходных данных, имеющихся в базе данных экономических характеристик завершенных разработок предприятия, и от метода их усреднения. Для конкретного планирования длительностей производства программных продуктов определенных классов необходимо для каждого предприятия исследовать и обобщать экономические характеристики реальных разработок, однородных по технологии и другим условиям. Такие обобщения при конкретных условиях производства позволяют получить опорные значения длительностей для некоторых размеров программ. 49 Вспомогательные характеристики производства программных продуктов Экономические характеристики производства на единицу размера программной продукции можно оценивать с использованием унифицированной единицы измерения — оператора (команды) на строку текста программы (LOС). Усредненные затраты труда всех категорий специалистов, участвующих в производстве программного продукта определенного размера, позволяют оценить среднюю производительность труда при его проектировании и производстве. В качестве единицы измерения этого показателя ниже используются число операторов ассемблера в месяц на человека или число строк текста программы в месяц на человека для комплексов программ на языках высокого уровня. При этом следует подчеркнуть интегральный характер всех величин, используемых при расчете этой характеристики. Этот показатель особенно важен при сопоставлении экономических характеристик производства продуктов различных классов и размеров, а также для оценки эффективности технологий и средств автоматизации разработки программ. Средние трудозатраты на создание каждой команды (оператора) в комплексе программ соответствуют обратной величине производительности труда при разработке, измеренной в операторах или числе строк программы на один человеко-месяц. Часто при оценке производительности труда разработчиков программ учитываются трудозатраты только непосредственных участников процесса проектирования и производства без трудозатрат на эксплуатацию технологических компьютеров и отчислений на амортизацию вычислительной техники. Эти затраты могут быть весьма значительными, однако их не всегда удобно выражать трудоемкостью на строку текста или команду. Поэтому в качестве экономической характеристики на единицу продукции, с учетом всех видов затрат, иногда применяется стоимость одного оператора или строки текста программы в завершенном производством и испытанном программном продукте, представленная в денежном выражении (руб. или долл. на команду или строку текста программы). 50 Экономические характеристики этапов производства программного продукта целесообразно оценивать аддитивными экономическими показателями. Такими характеристиками могут служить суммарные трудозатраты на выполнение этапа работ при планировании и создании комплекса программ определенного размера и класса или поэтапные трудозатраты на одну интегральную команду — строку текста программы. Эти характеристики позволяют выявлять наиболее трудоемкие этапы и помогают рациональнее распределять затраты по этапам работ. В поэтапных затратах целесообразно выделять совокупные затраты на средства автоматизации разработки, что позволяет выявлять эффективные компоненты технологии и инструментальных средств с учетом стоимости их приобретения и эксплуатации. Во многих случаях важны не столько экономические затраты на создание программного продукта, сколько длительность разработки. Локальное ускорение отдельных этапов разработки (особенно начальных) может приводить к значительному увеличению длительности других этапов и к общему возрастанию длительности производства. Поэтому совершенствование технологии и средств автоматизации производства сопряжено с перераспределением затрат и длительностей этапов работ с целью сокращения общей длительности разработки проекта, в некоторых случаях даже за счет увеличения суммарных затрат. Этапы жизненного цикла комплексов программ существенно различаются между собой степенью определенности и прогнозируемости их характеристик. Соответственно изменяются возможности подготовки и достоверность планов проведения работ. В процессе разработки сложных программных комплексов уточняются и детализируются их спецификации требований, функции, структура и характеристики компонентов. Поэтому на начальных этапах, особенно принципиально новых продуктов, трудно спланировать точно все последующие этапы. В результате планирование проводится итерационно в соответствии с последовательным повышением достоверности и точности сведений о характеристиках продукта и среды производства. Производство сложных заказных программных продуктов, особенно на начальных и завершающих этапах, характеризуется высокой долей творческого труда. Поэтому трудоемкость 51 и длительность отдельных операций и частных работ существенно зависят от индивидуальных особенностей и квалификации их исполнителей и характеристик конкретного проекта. Вследствие этого отсутствует достоверная пооперационная статистика разработки комплексов программ, и пока невозможно создать типовые нормативы на большинство частных операций при их создании. Отсюда принципиальной особенностью планирования разработки комплексов программ должно являться активное участие руководителей и заказчиков проекта в составлении планов на базе исследованных характеристик прототипов завершенных разработок и их личного опыта. Такие планы должны иметь разумные ограничения в детализации работ на уровне, обеспечивающем необходимую управляемость всего процесса производства. В процессе производства, после использования прототипов для прогнозирования и планирования очередного проекта происходит его реализация, данные которого могут быть использованы в качестве расширения состава прототипов для последующих проектов. Тем самым может быть создана последовательно уточняющаяся база данных, позволяющая повышать достоверность прогнозирования и планирования производства программных продуктов определенного класса. При разработке программных модулей и компонентов отдельными специалистами или небольшими группами производительность труда при написании одних и тех же текстов автономных программ может различаться в десяток раз в зависимости от их таланта и трудоспособности и достигать тысячи строк за человеко-месяц. Однако достаточно полное тестирование, документирование, комплексирование и интегрирование в крупные программные продукты приводят к снижению интегральной производительности до величин в несколько сотен строк текста за человеко-месяц. Для примера крупных проектов класса СРВ в 80-е годы приводятся величины 100–150 строк на человеко-месяц в отечественных проектах. В те же годы эта величина в США приближалась к 100. При диапазоне изменения размеров программ СРВ на четыре порядка средняя производительность труда обычно изменяется только в два раза, что в ряде случаев существенно облегчает упрощенные оценки и прогнозирование экономических характеристик. Совершенствование технологии, квалификации 52 специалистов и инструментальных средств автоматизации разработки позволили в те годы повысить среднюю производительность труда при создании полностью новых оригинальных программных продуктов СРВ в несколько раз, по экспертным оценкам до величин 300–500 строк на человеко-месяц. При производстве комплексов программ необходимо учитывать, что экономические, временные, вычислительные и другие ресурсы на весь ЖЦ комплекса всегда ограниченны и используемые затраты для улучшения каждой характеристики должны учитывать эти ограничения. Для рационального распределения этих ресурсов необходимо знать, как отражается изменение затрат на улучшении каждой характеристики качества программного продукта. Эта корреляция затрат ресурсов и значений каждой характеристики качества зависит от назначения, а также от ряда свойств и других особенностей комплекса программ, что усложняет учет влияния таких связей. Тем не менее выявлены основные тенденции такого взаимодействия, которые могут служить ориентирами при выборе и установлении требований к определенным характеристикам качества программных продуктов. Характеристики ошибок при разработке комплексов программ значительно влияют на затраты при их создании. Поэтому целесообразны оценки относительных и абсолютных трудозатрат на выявление и устранение дефектов и ошибок. Общие тенденции состоят в быстром росте затрат на выявление каждой ошибки по последовательным этапам производства комплексов программ. Поэтому экономически целесообразно в максимальной степени выявлять ошибки на начальных этапах ЖЦ комплексов программ. Это, естественно, приводит к увеличению затрат и длительности этих этапов, однако способствует минимизации суммарных затрат и длительности производства программного продукта в целом. Невыявленные ошибки непосредственно связаны с достигаемой корректностью, безопасностью и надежностью функционирования программных продуктов. Изучение характеристик ошибок при разработке реальных комплексов программ позволило создать ряд математических моделей, обеспечивающих возможность прогнозирования длительности разработки и затрат, необходимых для достижения определенной безопасности и надежности 53 программного продукта. Анализ и обобщение характеристик выявленных и устраненных ошибок в процессе разработки позволяет контролировать и прогнозировать качество комплексов программ при аналогичных разработках. Стремление заказчиков резко ускорить разработку, снизить затраты или нерационально увеличить производительность специалистов всегда сопряжено со снижением качества. Имеющиеся попытки введения заказчиками и менеджерами нормативов на экономические характеристики производства для разработчиков либо не способствуют выполнению их управляющей и регламентирующей роли (если они занижены), либо приводят к снижению качества программ (если они завышены). Поэтому приводимые далее экономические характеристики следует использовать с учетом всех условий, для которых они получены, и нецелесообразно применять в качестве нормативов при конкретных проектах. Они могут служить только ориентирами для оценки и обоснования экономических характеристик проектирования и производства аналогичных программных продуктов. 54 Глава 3 Основные факторы, определяющие экономические характеристики производства программных продуктов Основные факторы, определяющие сложность производства программных продуктов Экономические характеристики производства программных продуктов зависят, прежде всего, от сложности алгоритмов, размера комплекса программ и базы данных, которые определяют затраты труда и длительность полного цикла их производства. Основные затраты при проектировании и производстве программных комплексов приходятся на овеществленный, преимущественно интеллектуальный труд специалистов различных категорий. Труднее всего прогнозировать экономические характеристики производства программного продукта в начале проекта, когда еще не сформировались достаточно четкие представления о функциях, свойствах, алгоритмах и размере программного комплекса, подлежащего разработке. На базе этих оценок желательно делать общий вывод, стоит ли заниматься данным проектом в дальнейшем, и на каких условиях следует заключить контракт с заказчиком на его выполнение. Когда разработка программного продукта близится к завершению, с целью уточнения экономических характеристик целесообразно учитывать некоторые дополнительные аспекты и спецификации. Однако общую экономическую смету, время работы над проектом и необходимые трудозатраты необходимо оценивать как можно раньше. При этом целесообразно поэтапно рассматривать ряд факторов, влияющих на экономические характеристики производства программного продукта — рис. 3.1. К основной группе факторов, отражающихся на экономических характеристиках производства программного продукта, относятся: 55 ●● масштаб — размер комплекса программ, выраженный числом строк текста или количеством программных модулей и компонентов в комплексе; ●● количество обрабатываемых переменных или объем памяти, используемой для размещения программ и базы данных; ●● трудоемкость разработки комплекса программ; ●● длительность разработки комплекса программ; ●● число специалистов, участвующих в создании программного продукта. Сложность и размер – основные факторы, определяющие экономические характеристики производства программных продуктов, включают: ¡¡ основные факторы, определяющие сложность производства программных продуктов: ●● обобщенные характеристики размеров комплексов программ в соответствии со стандартом ISO 12182; ●● концептуальные требования при формировании архитектуры, компонентов и их связей в комплексах программ; ¡¡ единицы измерения сложности и размера комплексов программ для экономического анализа их производства: ●● сложность проектирования и производства, а также сложность функционирования и применения продукта; ●● тексты программ, которые анализируются человеком, и тексты, которые размещаются для исполнения в компьютере; ●● обобщенные характеристики сложности компонентов и комплексов программ; ●● временная, информационная и программная сложность комплексов программ; ¡¡ масштаб – размер комплексов программ по числу строк текста и объему занятой памяти компьютера: ●● размер программы – сложность, основной ориентир трудоемкости производства программного продукта; ●● память, занятая программами в компьютере – программная сложность, ориентир размера комплекса программ; ●● оценки размера комплекса программ в строках текста программного кода (LOС). Рис. 3.1 56 Некоторые из перечисленных факторов коррелированы между собой, причем определяющими обычно являются размер комплекса программ и объем базы данных. Остальные характеристики можно рассматривать как производные, вторичные, однако они могут представлять самостоятельный интерес при анализе и прогнозировании экономических характеристик производства программного продукта. Анализ предварительных экономических характеристик проекта должен начинаться с прогнозирования возможного размера комплекса программ, с учетом того, что его достоверность может быть недостаточной и обусловлена следующими факторами: ●● проблема проектирования может быть недостаточно хорошо понята разработчиками и/или заказчиками из-за того, что некоторые производственные факторы были упущены или искажены из-за предвзятого к ним отношения; ●● недостаток либо полное отсутствие прототипов не позволили создать базу данных для экономических оценок и их прогнозирования; ●● проектирующее предприятие не располагает стандартами и методиками, с помощью которых можно выполнять производство и экономический прогноз размера проекта (либо в случае наличия стандартов их никто не придерживается); ●● менеджеры проектов полагают, что необходимо фиксировать требования к сложности и размеру программного продукта в начале проекта, заказчики же зачастую считают, что не стоит тратить время на разработку спецификации требований, оценки размеров и экономических характеристик продукта; ●● могут потребоваться дополнительные компоненты в комплексе программ (для интерфейсов системы, аппаратного обеспечения и внешней среды), что отражается на размерах программного продукта; ●● имеет место недостаточно четкое представление об ограничениях ресурсов на уровне системы и возможностях совершенствования создаваемого программного продукта. Для конкретизации основной области дальнейшего анализа экономики производства целесообразно выделить и классифицировать обобщенные характеристики комплекса программ 57 в соответствии со стандартом ISO 12182. В стандарте выделены три группы видов характеристик: внутренние виды; виды среды и виды данных. Для каждого вида представлен перечень классов, из которых рекомендуется выбирать подходящие характеристики для отражения особенностей конкретной системы или описания достаточно широкой сферы анализа и применения комплекса программ. Из общего числа видов далее целесообразно учитывать следующие: ●● базовые функции комплексов программ — заказные системы управления объектами или процессами в реальном времени; ●● прикладная область системы — характеристики оборудования и аппаратуры управления процессами и объектами; информационные, административные или обучающие системы; ●● режимы эксплуатации — обработка данных в пакетном режиме или в реальном времени; ●● масштаб, размер комплекса программ — средний или большой; ●● представление данных — предметное, формализованные описания объектов или процессов; ●● критичность программного продукта — средняя или высокая, должна быть предотвращена возможность больших экономических потерь, повреждения дорогой собственности или угроза человеческой жизни; ●● класс пользователей — технические процессы, внешние системы, средства и объекты, обучающиеся или квалифицированные специалисты; ●● стабильность программного продукта — маловероятное или дискретное внесение изменений в процессе регламентированного сопровождения; ●● характер использования программного продукта — заказной для конкретного применения в определенной системе или для массового распространения на рынке среди предприятий и пользователей; ●● требуемые динамические характеристики: время отклика — быстрое (секунды или минуты); производительность — большая или средняя; 58 ●● требования безопасности и надежности — произвольные, высокие или критические; ●● требования к использованию вычислительных ресурсов — не критические или высокие, почти полное использование ресурсов по основному функциональному назначению. Имеющаяся статистика экономических характеристик производства программных продуктов различных классов позволила выявить основные факторы, от которых они зависят (см. рис. 3.1). Изучены тенденции их изменения от важнейших параметров. Для учета классов заказных комплексов программ, с позиции экономики их производства, проведено ранжирование экспериментальных данных, и выделены два достаточно различающихся базовых класса при одном и том же размере. Характеризующиеся: максимальной трудоемкостью производства — встроенные программные продукты сложных систем реального времени (СРВ) и средней трудоемкостью разработки — программные средства административных, обучающих, информационных и поисковых систем (АС). Все остальные классы комплексов программ могут быть упорядочены между выделенными классами, и для них изменения трудоемкости обычно оцениваются относительно максимальной, для программных продуктов реального времени. Экспериментальные оценки трудоемкости имеют значительную дисперсию, которая обусловлена рядом трудно учитываемых факторов. Малые комплексы программ при производстве небольшими коллективами специалистов характеризуются высокими коэффициентами вариации значений трудоемкости вследствие особой роли индивидуальной квалификации участвующих специалистов. Трудоемкость разработки сложных программных продуктов размером свыше 100 тыс. строк отражается более стабильными значениями, что обусловлено усреднением творческих возможностей специалистов и условий их труда в больших коллективах, а также возрастанием роли руководящего и вспомогательного персонала. Встроенный класс программных продуктов реального времени (СРВ) отличается жесткими ограничениями на характеристики и ресурсы компьютеров, реализующих программы, и правилами использования интерфейсов. Такие продукты обычно практически полностью используют ресурсы вычислительных машин по памяти и производительности, снабжаются подробной документацией, 59 эксплуатируются и поэтапно модернизируются как промышленная продукция многие годы и даже десятилетия. Эти комплексы программ непосредственно определяют степень автоматизации производства в промышленности, качество управления военными и техническими объектами и системами. Такие программные продукты должны функционировать при тесной взаимосвязи аппаратуры, программ и вычислительных процессов, а также тщательно оцениваться и контролироваться экономистами производства. Встроенный программный комплекс, как правило, планируется при недостаточной исходной информации об условиях и требованиях заказчика для его производства. После завершения предварительного проектирования рациональной стратегией создания встроенного программного продукта является привлечение группы специалистов для параллельного выполнения детального проектирования, кодирования и автономного тестирования полного набора компонентов. Класс производства программных продуктов для административных, обучающих и информационных систем (АС) по экономическим характеристикам занимает промежуточное положение между распространенным и встроенным классом. Эти комплексы программ не полностью используют ресурсы вычислительных систем, могут тиражироваться и передаваться пользователям как законченные программные продукты. Их эксплуатация обычно превышает длительность разработки, однако в ходе эксплуатации они непрерывно развиваются. В производстве, модификации и эксплуатации таких продуктов участвуют большие коллективы специалистов, труд которых должен организовываться, планироваться и анализироваться на уровне отдельных команд. Такой может быть система обработки сообщений с весьма строгим соблюдением интерфейсов, например, налагаемых терминальными, организационными или административными требованиями системы и пользователей. При анализе экономики производства сложных заказных комплексов программ, при формировании их архитектуры, выборе компонентов и их связей целесообразно применять и учитывать ряд концептуальных требований: ●● архитектура программных продуктов должна соответствовать текущим и перспективным целям и стратегическим, функциональным задачам создаваемой системы; 60 ●● в структуре и компонентах следует предусматривать обеспечение максимально возможной сохранности инвестиций в аппаратные и программные продукты, а также в базы данных для длительного развития, сопровождения и модернизации системы и программного продукта; ●● для обеспечения перспективы развития систем следует предусматривать возможность интеграции гетерогенных вычислительных компонентов и мобильность комплексов программ на различные аппаратные и операционные платформы; ●● архитектура комплекса программ должна быть достаточно гибкой и допускать относительно простое, без коренных, структурных изменений развитие и наращивание функций и ресурсов системы, в соответствии с расширением сфер и задач ее применения; ●● необходимо обеспечивать эффективное использование ресурсов системы и минимизировать интегральные затраты на обработку данных в типовых режимах ее функционирования с учетом текущих эксплуатационных затрат и капитальных вложений в создание программного продукта; ●● следует обеспечить комфортный, максимально упрощенный доступ конечных пользователей к управлению и результатам функционирования системы на основе современных графических средств и наглядных пользовательских интерфейсов. Описанные особенности классов комплексов программ определили концентрацию в учебнике на наиболее сложной для анализа экономике производства программных продуктов первого класса, а также на некоторых комплексах второго класса. Единицы измерения сложности и размера программ для экономического анализа их производства Выбор и применение единиц измерения сложности и размера компонентов и комплексов программ одна из задач при анализе и прогнозировании характеристик экономики производства и затрат на их создание. Этому способствует неоднозначность 61 учитываемых этапов разработки комплексов программ и категорий специалистов, трудозатраты которых заметно влияют на экономические характеристики. При одних и тех же процессах измерения продуктов производства и затрат на их создание методики определения количественных значений основных экономических характеристик пока не стандартизированы, что вносит дополнительную дисперсию в их значения, приводимые в различных проектах и исследованиях. В результате могут делаться различные и даже принципиально неверные выводы, например об очень высокой эффективности некоторых частных технологических методов или инструментальных систем автоматизации этапов производства. Для уменьшения этих неопределенностей и сокращения возможных методических ошибок в экономике производства необходимо определить основные понятия и единицы измерения: сложности, размера или масштаба комплексов программ, трудозатрат на их разработку, производительности труда специалистов и некоторых других экономических характеристик. Весьма расплывчатое понятие сложность комплексов программ значительно конкретизируется и становится измеряемым, когда устанавливается связь этого понятия с конкретными ресурсами, необходимыми для решения соответствующей задачи. Если хотя бы один из ресурсов, необходимых для решения, велик или оказывается на пределе, доступном для использования, то такую задачу вряд ли посчитают простой. Сложность задачи может быть велика по одному используемому ограниченному ресурсу и невелика из-за малого использования остальных ресурсов. Например, программа, простая по количеству модулей и длине, может оказаться сложной по объему вычислений или по числу и структуре обрабатываемых данных, и наоборот. При разработке комплексов программ основными экономическими лимитирующими ресурсами обычно являются: допустимые трудозатраты специалистов; ограничения на сроки разработки; параметры компьютера, технология и инструментарий проектирования и производства. Для этапа эксплуатации комплексов программ основными определяющими ресурсами может становиться память и производительность реализующего компьютера, а в качестве ограничений могут выступать время счета типовых задач, доступный объем памяти базы данных. Показатели 62 сложности программного продукта можно рассматривать с позиций статической и динамической и делить их на две группы: сложность проектирования и производства программного продукта: статическая сложность, когда реализуются его назначение, функции и характеристики, а также вносятся и устраняются основные дефекты и ошибки. Кроме того, выделяется сложность функционирования и применения программного продукта для получения результатов: динамическая сложность, когда реализуется его функциональное назначение и качество, а также могут проявляться дефекты и ошибки. Размер или масштаб комплексов программ в настоящее время приводится в проектах в различных единицах, что может изменять их численные значения для одних и тех же комплексов в несколько раз. В качестве таких единиц чаще всего используются численные значения: строк текста программы на языке программирования, предложений на ассемблере, число символов в тексте программы, байт или команд в объектном коде после трансляции. Каждая из этих единиц измерения имеет некоторые преимущества при определенных целях исследования и применения. Однако при сравнительном экономическом анализе различных проектов применение в каждом из них отличающихся единиц для характеристики объекта производства приводит к дополнительному разбросу численных значений размеров и к несопоставимости экономических затрат. Влияние единиц измерения размера программ на экономику производства можно значительно уменьшить, если учитывать их принципиальные особенности и разделить на две группы единиц измерения: ●● группу, характеризующую размер исходных текстов программ, которые разрабатываются и анализируются человеком, отражающую сложность и трудоемкость создания комплекса программ и его компонентов; ●● группу, отражающую размер программ и данных, размещаемых в реализующем (объектном) компьютере, и характеризующую его объем памяти и производительность, необходимые для функционирования и исполнения программного продукта при его применении. Эти две группы единиц отражают размер программ с разных позиций и должны использоваться в зависимости от целей анализа. 63 Хотя между ними есть корреляция, но в общем случае размеры программ, измеренные различными группами единиц, зачастую оказываются практически несопоставимыми по экономическим характеристикам из-за наличия между ними промежуточного звена — преобразователя (транслятора) с различными, не полностью определенными характеристиками. Это обусловлено особенностями трансляторов, которые преобразуют исходные тексты программ, разработанные человеком — программистом, в разделы памяти реализующего компьютера, заполненного командами, константами или выделенные под данные, а также особенностями языков программирования, структуры и содержания машинных команд. Сложность создания и экономические характеристики комплексов программ целесообразно анализировать на базе трех наиболее специфических компонентов: ●● сложность совокупности программных модулей и компонентов характеризуется конструктивной структурой компонентов программы и может быть оценена с позиции сложности внутренней структуры и преобразования переменных в каждом модуле, а также интегрально по некоторым внешним статистическим характеристикам размеров модулей и компонентов; ●● сложность структуры программного комплекса или крупных функциональных компонентов и связей между модулями по передачам управления и по обмену информацией определяется глубиной взаимодействия модулей и регулярностью структуры межмодульных связей; ●● сложность структуры и совокупности данных определяется количеством и структурой переменных в базе данных, регулярностью их размещения в массивах, а также сложностью доступа к этим данным. Динамическая группа показателей сложности характеризует программные продукты на этапе эксплуатации законченных функционирующих систем. Эти показатели объединяются понятиями «вычислительная сложность применения комплексов программ» и «сложность подготовки и анализа результатов». Вычислительная сложность непосредственно связана с ресурсами вычислительной системы, необходимыми для нормального функционирования программного продукта и получения совокупности 64 законченных результатов, может быть представлена следующими тремя компонентами: ●● временная сложность отражает необходимую длительность исполнения программного продукта или время обработки компьютером определенной, типовой совокупности исходных данных для получения требуемых результатов; ●● информационную сложность можно представить как объем базы данных, обрабатываемых комплексом программ, или как емкость памяти, используемой для накопления и хранения информации при исполнении и применении программного продукта; ●● программная сложность характеризуется размером программы или объемом памяти компьютера, необходимой для размещения и функционирования программного продукта. В системах реального времени временная сложность непосредственно отражается временем отклика (ожидания выходных результатов) на некоторые исходные данные. Пропускная способность комплекса программ при его исполнении конкретным компьютером характеризует динамику обработки исходных данных и сложность исполнения программного продукта в реальном масштабе времени. Масштаб — размер комплексов программ по числу строк текста и объему занятой памяти компьютера Трудоемкость проектирования и производства программных продуктов непосредственно зависит от размера — масштаба комплексов программ, выраженного числом: операторов на ассемблере или строк на языке программирования высокого уровня. Реальное изменение ркзмера создаваемых в настоящее время сложных программных продуктов от 104 до 108 строк (LOC) определяет диапазон трудоемкости разработки таких программ от человеко-года до десятков тысяч человеко-лет. Размер исходных текстов программ, прежде всего, отражается на трудоемкости и длительности их разработки, что позволяет оценивать относительные характеристики производительности труда специалистов — разработчиков. 65 По большому числу проектов подтверждена высокая корреляция между размером текста комплекса программ и трудоемкостью (с коэффициентом) его производства. Однако исходные тексты могут содержать конструкции, которые не исполняются при рабочем функционировании программ: комментарии разных уровней, указания, заголовки и дополнительные описания, требующие определенного труда для подготовки. Для сближения понятий и значений размера программ по обеим (разрабатываемым и исполняемым) группам характеристик целесообразно эти неисполняемые части программы предварительно не учитывать. Основной труд специалистов вкладывается в разработку текста программ, поэтому желательно, чтобы выбранная единица измерения размера была бы в наибольшей степени адекватна (пропорциональна) трудоемкости разработки. При этом должна учитываться не только трудоемкость непосредственной подготовки текста и разработки компонентов программы, но отражаться трудоемкость их интеграции и комплексного создания всего сложного продукта. Кроме того, единица измерения размера должна быть наглядной и просто измеряемой. Расчет показателей производительности труда с учетом полного размера комплекса, в том числе ранее отработанных и испытанных программ, в этом случае неправомерен, так как не учитывается труд, затраченный ранее на готовые компоненты, используемые при сборке. Возможный выход для уменьшения неадекватности численных оценок производительности труда состоит в учете размера и затрат на комплексирование только вновь разработанных программ. В этом случае затраты на комплексирование уже ранее отлаженных программ учитываются только в полной трудоемкости производства программного продукта. При анализе трудоемкости разработки программ, кроме затрат на создание текста программных компонентов на языке программирования, необходимо учитывать затраты: на разработку тестов для их тестирования, на комментарии к программам, на интерфейсы различных видов, на документацию. В результате сложность создания программ (непосредственный труд) значительно превышает затраты труда с учетом только размера текста. Масштаб — размер текста программ может использоваться как исходный ориентир для оценки сложности производства компонентов программного продукта. Пересчет величины размера компонента 66 к величине сложности его производства позволяет более корректно сопоставлять экономические характеристики производства в различных проектах, коллективах и у отдельных специалистов. В пределах одного целостного сложного комплекса программ сравнение специалистов по величине масштаба — размера разработанных компонентов может быть удобным и достаточным для первичной оценки производительности труда отдельных специалистов. Память для программ, размещаемых в компьютере для исполнения — программная сложность, также может служить ориентиром при оценке размера комплекса программ. Он влияет на характеристики и стоимость используемых машин, которая зависит от объема памяти и производительности компьютера, что особенно важно учитывать в системах реального времени (например, бортовых). Число команд, занятых программой в реализующем компьютере, соответствует числу исполняемых операторов в исходном тексте программы. Современные затраты на реализацию программных продуктов в различных компьютерах изменяются приблизительно в таком же широком диапазоне, как и трудоемкость их разработки (на четыре порядка). За рубежом чаще всего размер комплекса программ определяется в терминах строк текста программного кода на языке программирования (Lines of code — LOС) (см. рис. 3.1). Единицы измерения размера программ, используемые специалистами при создании и анализе текстов, а также для экономического анализа процессов их производства, должны учитывать следующие особенности программ: ●● новый код текстов программ, разработанный полностью для нового проекта, который не включает фрагменты и процедуры ранее написанного и испытанного кода на языке программирования; ●● модифицированный код программных компонентов, разработанный для предыдущих проектов, который пригоден для использования в новом проекте, после адаптации и внесения умеренного объема изменений; ●● повторно используемый код компонентов, разработанный для предыдущих проектов, который полностью пригоден для нового программного продукта без внесения изменений. Код, повторно используемый в полном объеме, должен иметь полную идентичную документацию, идентичные тестовые 67 процедуры и текст на языке программирования, а также копию с целью поддержки библиотеки менеджмента производства. Если изменяется лишь одна строка исполняемого кода, то подвергается изменению тестовый код и документация. Первый этап при экономической оценке размера программных комплексов, которые могут повторно использовать код, заключается в отделении нового кода от модифицируемых компонентов. Это необходимо по той причине, что модифицируемые компоненты практически никогда не могут быть использованы непосредственно, для выполнения их интеграции в комплекс и требуются некоторые изменения, в результате чего возрастает размер компонентов и трудозатрат, требуемых для реализации подобных изменений. Если компонент в целом не был изменен, он может повторно использоваться полностью. Если компонент был изменен (пусть в одном комментарии или выполняемом операторе), он является модифицируемым. Целесообразно отделять модификации, предназначенные для корректировки дефектов, от направленных на изменение и расширение функций. После завершения оценки размера разработанного программного комплекса повторно используемый компонент целесообразно преобразовать в эквивалентный новый код. Обычно определяется множитель преобразования с целью экономического отражения количества трудозатрат, сэкономленных при повторном использовании модулей или компонентов. При внедрении повторно используемых компонентов может экономиться до 70% трудозатрат по сравнению с внедрением новых компонентов. При использовании модифицируемых программ экономия может составлять около 40%. Оценку размера комплекса и компонентов программ и производственных трудозатрат приходится выполнять неоднократно во время жизненного цикла, причем после каждого оценивания повышается уровень доверия к полученным результатам. Точность экономического прогнозирования значительно повышается поэтапно: после формулирования начальных требований заказчика, проведения анализа требований, после завершения разработки детального проекта. Квалифицированный менеджер проекта обязан оценивать (повторно) размеры комплекса программ, используя результаты оценивания в качестве выходных экономических критериев для каждого этапа. К ним относятся числа: 68 ●● строк текста программы на используемом языке программирования высокого уровня; ●● строки кода в терминах Lines of code — LOС. Число строк программы на языках высокого уровня (ЯВУ) в значительной степени зависит от конкретных особенностей используемого языка. Языки программирования высокого уровня ориентированы на определенные классы задач. Благодаря этому проблемно-ориентированные языки позволяют получать компактные тексты соответствующих классов программ. Однако применение их для других классов программных продуктов приводит к расширению текста и не всегда рационально. ЯВУ значительно различаются степенью обобщенного описания содержания алгоритмов вследствие их проблемной ориентации, применения разных структур операторов, операндов и процедур, что может приводить к различию (в несколько раз) числа строк текста по сути одних и тех же программ. Число строк текста на ЯВУ характеризует сложность программы для ее разработчика, однако оно не отражает функциональную (потенциальную) сложность, которая значительно выше за счет применения процедур и комментариев. Эти факторы приводят к тому, что размеры одинаковых программ на различных ЯВУ трудно сопоставлять неунифицированными единицами. Для такой унификации желательно выделять базовый, широко применяемый язык программирования (например, Си, Ада) и определять коэффициенты пересчета числа строк при разработке комплексов программ на других ЯВУ с учетом классов программ. Для обобщения экономических характеристик производства программных продуктов необходимо обеспечивать расчет числа строк на ЯВУ и определение среднестатистических коэффициентов для их приведения (без учета расширения вследствие трансляции) к числу операторов того же компьютера, для которого разработаны программы на ЯВУ (коэффициента сжатия текстов на ЯВУ относительно текста, например, на Си). Или определение коэффициентов расширения трансляторов с ЯВУ при получении программ в объектном коде реализующего компьютера, как отношения числа команд в объектном коде реализующего компьютера, эквивалентного числу операторов на Си, к числу строк на ЯВУ в тексте программ (полное расширение транслированного текста в объектном коде реализующего компьютера относительно текста на ЯВУ). 69 Преимущества использования LOС в качестве единиц измерения размера программ: ●● позволяют выполнять сопоставление методов измерения размеров программ и производительности в различных группах разработчиков одного проекта комплекса программ; ●● непосредственно связаны с размером конечного программного продукта; ●● единицы LOC могут применяться на промежуточных этапах до завершения проекта; ●● оценка размеров компонентов производится с точки зрения разработчика — физического размера созданного программного продукта, количества написанных и отлаженных строк кода всех компонентов; ●● совершенствование программ и размер их расширения может быть сопоставлен с реальным размером компонентов в ходе доработок. Недостатки, связанные с применением LOC при оценке размера программ: ●● единицы измерения LOС затруднительны в применении при прогнозировании размера комплекса программ на ранних стадиях его жизненного цикла; ●● исходные инструкции могут различаться в зависимости от типов языков программирования, методов проектирования, стиля и способностей программистов; ●● генераторы кода, не имеющие эффективную оптимизацию, создают чрезмерный размер программного кода, в результате чего искажаются показатели LOС. При коллективном производстве сложных программных продуктов индивидуальные характеристики специалистов нивелируются, многие из них не участвуют в непосредственном программировании (аналитики-спецификаторы, тестировщики, документаторы), в результате чего расчет функциональности и ее применение в экономике производства сложных программных продуктов теряет смысл. В таких проектах целесообразнее пользоваться для учета размера компонентов и комплексов программ традиционной величиной числа строк LOС. Поэтому далее в учебнике все экономические оценки трудоемкости, длительности и производительности базируются на величине LOС. 70 Глава 4 Характеристики качества программных продуктов, влияющие на экономику их производства Влияние качества программных продуктов на экономические характеристики производства На экономические характеристики производства программных продуктов значительно влияют основные требования к их характеристикам качества. Подробный состав требований к характеристикам сложных программных продуктов регламентирован в международных стандартах ISO 9126 и ISO 25000. В них рассмотрено около двадцати видов и значений основных характеристик и ряд их атрибутов качества, однако ниже при анализе выделены доминирующие и их количество несколько сокращено. Стандартизированные в этих документах характеристики качества целесообразно использовать при экономическом обосновании производства сложных программных продуктов, к которым предъявляются высокие требования к качеству функционирования и применения. Высшие приоритеты в конкретных проектах, естественно, должны присваиваться свойствам и атрибутам качества, необходимым для достижения стратегических целей, отражающих назначение и функции применения программного продукта. Для их реализации следует выделять достаточные ресурсы. Все остальные стандартизированные характеристики программного продукта должны способствовать обеспечению тактических целей реализации выбранных конструктивных требований качества при доступных ресурсах. Поэтому им могут быть присвоены более низкие приоритеты и на выполнение соответствующих требований могут выделяться меньшие ресурсы, что, в частности, может отражаться на не полной реализации некоторых формализованных 71 заказчиком требований качества вследствие ограниченности ресурсов. Стандартами рекомендуется, чтобы было обеспечено измерение каждой характеристики качества при испытаниях с точностью и определенностью, достаточной для сравнений с требованиями технических заданий и спецификаций, и чтобы измерения были объективны и воспроизводимы. Системная эффективность целевого применения программных продуктов определяется степенью и качеством удовлетворения потребностей определенных лиц — заказчиков и/или пользователей. В стандартах эта эффективность отражается основной, обобщенной характеристикой качества — функциональной пригодностью программного продукта. В связи с тем, что ее абсолютную величину обычно трудно измерить непосредственно и количественно, то по ряду показателей необходима и возможна качественная оценка свойств и достоинств основных функций продукта при применении. Выбор требований к характеристикам качества программного продукта, естественно, должен начинаться с определения и формирования требований к его функциональной пригодности. Это наиболее ответственная, стратегическая задача начальных этапов проектирования и всего последующего производства. Решение задачи должно быть направлено на обеспечение требуемой высокой функциональной пригодности продукта путем сбалансированного установления остальных характеристик качества в условиях ограниченных ресурсов. Излишне высокие требования к отдельным атрибутам качества, требующие для реализации больших экономических, трудовых и вычислительных ресурсов, целесообразно снижать, если они слабо влияют на основные, функциональные характеристики. Ориентирами могут служить диапазоны изменения характеристик, границы количественных или качественных шкал которых сверху и снизу могут быть выбраны на основе следующих принципов: ●● предельные значения характеристик качества должны быть ограничены сверху допустимыми или рациональными затратами ресурсов на их достижение при производстве и совершенствовании программного продукта; ●● наибольшие допустимые затраты ресурсов, например труда и времени для реализации характеристик качества, должны 72 обеспечивать функциональную пригодность применения программного продукта на достаточно высоком уровне; ●● допустимые низшие значения отдельных характеристик качества могут соответствовать значениям, при которых заметно начинает снижаться функциональная пригодность при применении программного продукта; ●● ограниченные значения отдельных характеристик качества не должны негативно отражаться на возможных высоких значениях других основных приоритетных характеристик. Функциональная пригодность — это набор и описания атрибутов, определяющих назначение, основные, необходимые и достаточные функции программного продукта, удовлетворяющие потребителей, заданные техническим заданием и спецификациями требований заказчика или потенциального пользователя — рис. 4.1. Данная характеристика определяется тем, какие функции и задачи должен решать продукт для удовлетворения потребностей пользователей, в то время как другие, конструктивные характеристики главным образом связаны с тем, как и при каких условиях заданные функции могут выполняться с требуемым качеством. Атрибуты функциональной пригодности можно характеризовать в основном свойствами, категориями и качественным описанием функций проблемно-ориентированной сферы применения, для которых зачастую трудно определить численные меры и шкалы. В процессе производства комплекса программ атрибуты функциональной пригодности должны конкретизироваться в спецификациях требований к комплексу программ в целом и к его компонентам с учетом экономических ограничений и доступных ресурсов. Атрибутами этой характеристики качества могут быть функциональная полнота решения заданного комплекса задач, степень покрытия функциональных требований спецификациями и их стабильность при совершенствовании версий продукта, количество, достоверность и полнота реализуемых требований заказчиков. На последовательных этапах жизненного цикла функции промежуточных продуктов (спецификаций компонентов, модулей, текстов программ) должны конкретизироваться и оцениваться в отдельных, частных документах на соответствие исходным требованиям к комплексу программ. Такими атрибутами могут быть: функциональная адекватность программного продукта 73 документам и декларированным требованиям, утвержденным заказчиком; степень покрытия тестами исходных требований к продукту и компонентам; полнота и законченность реализации этих требований; точность выполнения требований детальных спецификаций на функциональные компоненты. ¡¡ ¡¡ ¡¡ ¡¡ ¡¡ Характеристики качества программных продуктов, влияющие на экономику их производства, включают: стандартизированные характеристики качества сложных программных продуктов; функциональную пригодность программного продукта: ●● цели; ●● назначение; ●● задачи; ●● основные функции; функциональные характеристики качества программных продуктов: ●● корректность; ●● способность к взаимодействию; ●● защищенность – безопасность; количественные характеристики качества программных продуктов: ●● Надежность: ●● завершенность; ●● устойчивость; ●● восстанавливаемость; ●● доступность – готовность; ●● Эффективность: ●● временная эффективность; ●● используемость ресурсов компьютера; качественные характеристики программных продуктов: ●● Практичность: ●● простота использования; ●● изучаемость; ●● Сопровождаемость: ●● изменяемость; ●● тестируемость; ●● Мобильность: ●● адаптируемость; ●● простота инсталляции; ●● замещаемость. Рис. 4.1 74 Функциональная пригодность определяется качеством взаимосвязей и трассируемости последовательных формулировок содержания и реализации основных фрагментов стандартизированных требований технического задания на программный продукт, определяющих, что: ●● описание целей программного продукта корректно переработано в подробное описание его назначения и внешней среды применения; ●● назначение продукта полностью и корректно детализировано в требованиях к его функциям и компонентам; ●● реализация требований к функциям программного продукта обеспечена достоверным и адекватным составом и содержанием исходной информации от объектов внешней среды и пользователей; ●● реализация функций программного продукта способна определять всю требуемую и достаточно корректную информацию для пользователей и объектов внешней среды. Функции программного продукта реализуются в определенной аппаратной, операционной и пользовательской внешней среде системы, характеристики которых существенно влияют на функциональную пригодность. Для выполнения требуемых функций необходима адекватная исходная информация от объектов внешней среды, содержание которой должно полностью обеспечивать реализацию декларированных функций. Полнота формализации номенклатуры, структуры и качества входной информации для выполнения требуемых функций является одной из важных составляющих при определении функциональной пригодности программного продукта в соответствующей внешней среде. Цель и функции программного продукта реализуются тогда, когда выходная информация достигает потребителей — объектов системы или операторов-пользователей, с требуемым содержанием и качеством, достаточным для обеспечения ее эффективного применения. Степень покрытия всей выходной информацией требований: целей, назначения и функций продукта для пользователей, следует рассматривать как основную меру качества функциональной пригодности. В ряде систем особое значение для функциональной пригодности программного продукта имеет организация 75 информационного обеспечения и базы данных. При этом должны быть определены: ●● назначение базы данных и состав информации в ней; ●● совместимость программного продукта с другими системами по источникам и потребителям информации базы данных; ●● организация сбора, передачи, контроля и корректировки информации базы данных; ●● интенсивность и объемы потоков информации для базы данных. Улучшение каждой вспомогательной — конструктивной характеристики качества программного продукта, требует некоторых дополнительных экономических ресурсов (трудоемкости, финансов, времени), которые отражаются на основной характеристике — на функциональной пригодности. Эти конструктивные характеристики имеют значение для программного продукта постольку, поскольку они обеспечивают требуемое качество реализации основного его назначения и функций. При выборе конкретных конструктивных характеристик качества следует учитывать затраты ресурсов на их достижение и на результирующее повышение функциональной пригодности, желательно в сопоставимых экономических единицах, в тех же мерах и масштабах. Такое, даже приблизительное, качественное сравнение эффекта и затрат позволяет избегать при производстве многих не рентабельных завышений требований к отдельным конструктивным характеристикам качества, которые не достаточно адекватно отражаются на улучшении функций продукта. Стандартизированные характеристики качества сложных программных продуктов В зависимости от назначения и размера программного продукта (см. главу 2) почти каждая из его характеристик качества может стать доминирующей или даже почти полностью определяющей функциональную пригодность программного продукта (см. ISO 9126 и ISO 25000). В наибольшей степени функциональная пригодность во многих случаях, например в системах 76 реального времени, зависит от корректности и надежности программного продукта. Правильность — корректность это способность программного продукта обеспечивать правильные или приемлемые результаты в соответствии с требованиями заказчика и пользователей. Эталонами для выбора требований к корректности при проектировании могут быть верифицированные и взаимоувязанные требования к функциям комплекса, компонентов и модулей программ, а также правила их структурного построения, организация взаимодействия и интерфейсов. Эти требования при разработке должны быть прослежены сверху вниз до модулей и использоваться как эталоны при установлении необходимой корректности соответствующих компонентов. Требования к характеристике корректность могут представляться в виде описания двух основных свойств, которым должны соответствовать все программные компоненты и комплекс в целом. Первое требование состоит в выполнении определенной степени (%) прослеживаемости сверху вниз реализации требований технического задания и спецификации на программный продукт при последовательной детализации и верификации описаний программных компонентов вплоть до текстов и объектного кода программ. Второе требование заключается в выборе степени и стратегии покрытия тестами структуры и функций программных компонентов, совокупности маршрутов исполнения модулей и всего комплекса программ для процесса верификации и тестирования, достаточного для функционирования программного продукта с требуемым качеством результатов, при реальных ограничениях экономических ресурсов на тестирование. Способность к взаимодействию — состоит в свойстве комплекса программ и его компонентов взаимодействовать с множеством определенных компонентов внутренней и внешней среды. При выборе и установлении при производстве способности программных и информационных компонентов к взаимодействию ее можно оценивать объемом технологических изменений в комплексе программ, которые необходимо выполнять при дополнении или исключении некоторой функции или компонента, когда отсутствуют изменения операционной, аппаратной или пользовательской среды. С этим показателем связана корректность 77 и унифицированность межмодульных интерфейсов, которые определяются двумя видами связей: по управлению и по информации. При этом важно учитывать возможность повторного использования апробированных компонентов и переноса их на различные платформы. Защищенность — безопасность тесно связана с особенностями функциональной пригодности каждого программного продукта реального времени. Разработка и формирование требований к свойствам функциональной безопасности должны осуществляться на основе потребностей эффективной реализации назначения и функций продукта при различных реальных угрозах. В процессе проектирования должны быть выявлены потенциальные предумышленные и случайные угрозы функционированию и установлен необходимый уровень безопасности данного программного продукта. Эффективная система защиты информации и программных продуктов подразумевает наличие совокупности организационных и технических мероприятий, направленных на предупреждение различных угроз безопасности, их выявление, локализацию и ликвидацию. Создание такой системы защиты предусматривает планирование и реализацию целенаправленной политики комплексного обеспечения функциональной безопасности. Их реализация в критических системах может требовать значительных ресурсов памяти и производительности вычислительных средств. Из-за их ограниченности и других факторов априори невозможно обеспечить отсутствие проявления дефектов производства и абсолютную защиту крупных программных продуктов, вследствие чего безопасность их функционирования в системах имеет всегда конечное, ограниченное значение. Наиболее полно степень безопасности системы характеризуется величиной предотвращенного ущерба — риска, возможного при проявлении дестабилизирующих факторов и реализации конкретных угроз безопасности применения продукта пользователями, а также средним временем между возможными проявлениями угроз, нарушающих безопасность. С этой позиции затраты экономических ресурсов разработчиками и заказчиками на обеспечение безопасности должны быть соизмеримыми с возможным ущербом у пользователей от ее нарушения. Поэтому реализации угроз в ряде случаев целесообразно характеризовать 78 интервалами времени между их проявлениями, нарушающими безопасность применения системы, или наработкой на отказы, отражающиеся на безопасности. Это сближает понятия и характеристики степени функциональной безопасности с показателями надежности систем. Различие состоит в том, что в показателях надежности учитываются все реализации отказов, а в характеристиках безопасности следует регистрировать только те катастрофические отказы, которые отражаются на проявлении значительных рисков и нарушении безопасности. При проектировании комплексов программ целесообразно разделять вычислительные ресурсы, необходимые для непосредственного решения основных, функциональных задач, и ресурсы, требующиеся для защиты и безопасного функционирования. Соотношение между этими видами ресурсов в реальных крупных продуктах зависит от сложности и состава решаемых функциональных задач, степени их критичности и требований к безопасности всей системы. Реальные ограничения ресурсов, используемых в процессах производства, ограниченная квалификация специалистов, изменения внешней среды и требований заказчика объективно приводят к отклонениям процессов и реализации плана от предполагавшегося. В процессе формирования технического задания следует формулировать основные положения методологии и план последовательного повышения безопасности путем наращивания комплекса средств защиты, поэтапных испытаний компонентов и определения ресурсов, допустимых для продолжения работ на следующих этапах. Две группы стандартизированных характеристик качества программных продуктов — Надежность и Эффективность в наибольшей степени доступны количественным измерениям. Надежность: свойства программного продукта обеспечивать достаточно низкую вероятность потери работоспособности — отказа в процессе его функционирования в реальном времени. Основные атрибуты надежности могут быть объективно измерены и сопоставлены с требованиями. Применением программно-аппаратных механизмов автоматического рестарта эта наработка при проявлении отказов может быть значительно повышена, так как при некоторых отказах возможно их автоматическое обнаружение и оперативное восстановление работоспособности, вследствие чего значения 79 устойчивости и наработки на отказ возрастают, что требует ресурсов. Допустимая длительность прерывания оперативной работы пользователей системы для полного восстановления нормального ее функционирования обычно может составлять несколько секунд или минут. Надежность программных продуктов наиболее полно характеризуется устойчивостью или способностью к безотказному функционированию, а также восстанавливаемостью работоспособного состояния после произошедших сбоев или отказов. Завершенность: свойство программного продукта не попадать в состояния отказов вследствие ошибок и дефектов в программах и данных. Завершенность можно характеризовать наработкой (длительностью) на отказ (при отсутствии автоматического восстановления — рестарта), измеряемой обычно часами времени. Устойчивость к дефектам и ошибкам: свойство программного продукта автоматически поддерживать заданный уровень качества функционирования при проявлениях дефектов и ошибок или нарушениях установленного интерфейса. Эффективное, оперативное устранение проявления дефектов, ошибок и некорректного взаимодействия с операционной и внешней средой определяет характеристику — устойчивость программного продукта. Восстанавливаемость: свойство программного продукта в случае отказа возобновлять требуемый уровень качества функционирования, а также поврежденные программы и данные. Основными показателями качества процесса восстановления являются его длительность (минуты, секунды) и вероятностные характеристики при определенных затратах. Доступность или готовность: свойство программного продукта быть в состоянии выполнять требуемую функцию в данный момент времени при заданных условиях использования. Для определения этой величины измеряется относительное время работоспособного состояния комплекса программ между последовательными отказами. Обобщение характеристик отказов и восстановления производится в критерии коэффициент готовности. Нижняя граница допустимой надежности обычно отражается значениями, при которых резко уменьшается функциональная пригодность, и использование данного типа программного продукта становится неудобным, опасным или нерентабельным. Примером таких наихудших, предельных величин для многих классов 80 программных продуктов могут быть наработка на отказ менее десяти часов, коэффициент готовности ниже 0,9 и время восстановления более десяти минут. С другой стороны, наилучшие значения этих атрибутов практически ограничены теми ресурсами, которые могут быть выделены для их достижения при производстве и эксплуатации. Эффективность: в стандарте ISO 9126 отражена двумя характеристиками — временной эффективностью и используемостью ресурсов компьютеров, которые рекомендуется описывать в основном количественными атрибутами, характеризующими динамику функционирования программного продукта. В этой стандартизированной характеристике отражается только частная, конструктивная эффективность использования ресурсов компьютеров. Ее не следует смешивать с системной эффективностью, функциональной пригодностью программного продукта при применении в конкретной системе. Основные требования к атрибутам характеристики эффективности использования вычислительных ресурсов программным продуктом сосредоточены на наиболее критичных показателях производительности и длительности решения функциональных задач. Используемость ресурсов памяти и производительности вычислительных средств может устанавливаться исходя, с одной стороны, из экономической целесообразности применения наиболее дешевой, с минимальными ресурсами компьютера, загрузка которой будет в среднем не ниже 0,5. С другой стороны, высокая загрузка (выше 0,9) может приводить к задержке или даже потере заданий при случайном, кратковременном повышении их интенсивностей, что может негативно отражаться на применимости и рисках программного продукта. Временная эффективность: свойства программного продукта, характеризующие требуемые времена отклика и обработки заданий, а также производительность решения задач с учетом количества используемых вычислительных ресурсов в установленных условиях (стандарт ISO 14756). Временная эффективность программного продукта определяется длительностью выполнения заданных функций и ожидания результатов в средних и/или наихудших случаях, с учетом приоритетов задач. Пропускная способность комплекса программ на конкретном компьютере отражается 81 числом сообщений или заданий на решение определенных задач, обрабатываемых в единицу времени, зависящую от характеристик внешней среды. Используемость ресурсов: степень загрузки доступных вычислительных ресурсов в течение заданного времени при выполнении функций программным продуктом в установленных условиях. Ресурсная экономичность отражается занятостью ресурсов центрального процессора, оперативной, внешней и виртуальной памяти, каналов ввода-вывода, терминалов и каналов сетей связи. Ресурсная экономия влияет не только на стоимость решения функциональных задач, но зачастую, особенно для критических встраиваемых компьютеров реального времени, определяет принципиальную возможность полноценного функционирования конкретного программного продукта в условиях реально ограниченных вычислительных ресурсов. Три группы качественных (конструктивных) характеристик качества программного продукта — Практичность, Сопровождаемость и Мобильность трудно измерять количественно, и они доступны в основном качественным оценкам их свойств (см. рис. 4.1). В некоторых проектах для характеристик Сопровождаемости и Мобильности при проектировании могут доминировать экономические меры трудоемкости (человеко-часы) и длительности (часы) для процедур, обеспечивающих реализацию атрибутов этих характеристик в комплексе программ. Практичность — применимость: свойства программного продукта, отражающие сложность его понимания, изучения и использования для квалифицированных пользователей при применении в заданных условиях. Требования к практичности и ее характеристикам — понятности и простоте использования, зависят от назначения и функций программного продукта и могут формализоваться заказчиками набором свойств, необходимых для обеспечения удобной и комфортной эксплуатации продукта, что требует некоторых ресурсов компьютера и производства. Изучаемость: свойства программного продукта, обеспечивающие удобное освоение его применения достаточно квалифицированными пользователями. Она может определяться трудоемкостью и длительностью подготовки пользователя к полноценной эксплуатации продукта. Атрибуты изучаемости зависят от ресурсов 82 для предварительного обучения и от совершенствования знаний в процессе эксплуатации, от возможностей оперативной помощи и подсказки при использовании программного продукта, а также от полноты, доступности и удобства использования руководств и инструкций по эксплуатации. Изучаемость можно отражать трудоемкостью и продолжительностью изучения пользователями соответствующей квалификации, методов и инструкций применения программного продукта для полноценной эксплуатации. Сопровождаемость: приспособленность программного продукта к модификации и изменению конфигурации. Модификации могут включать исправления, усовершенствования или адаптацию комплекса программ к изменениям во внешней среде применения, а также в требованиях и функциональных спецификациях заказчика. Трудоемкость модификаций определяется внутренними метриками качества комплекса программ, которые отражаются на внешнем качестве и качестве в использовании, а также на сложности и ресурсов для управления конфигурациями версий программного продукта (см. стандарты ISO 14764 и ISO 15846). Требования к сопровождаемости количественно можно установить для характеристик изменяемости и тестируемости экономическими категориями допустимой трудоемкости и длительности реализации этих задач при некоторых средних условиях, обусловленных необходимостью устранения дефектов и усовершенствованиями функций программного продукта. Для подготовки и выполнения каждого изменения (без учета затрат времени на обнаружение и локализацию дефекта) нужно устанавливать допустимую среднюю продолжительность и суммарную трудоемкость работ специалистов при их реализации. Мобильность: подготовленность программного продукта к переносу из одной аппаратно-операционной среды в другую. Установление требований к мобильности может быть сведено к формализации трудоемкости и длительности процессов: адаптации к новым характеристикам пользователей и внешней среды, инсталляции версий программного продукта в среде пользователей и замены крупных компонентов по требованиям заказчиков или конкретных пользователей. 83 Глава 5 Модели прогнозирования экономических характеристик производства программных продуктов Методы прогнозирования экономических характеристик производства программных продуктов Приступая к разработке комплекса программ, как в любой производственной деятельности, необходимо провести реалистичную оценку исходных данных: возможного масштаба проекта — сложности поставленных целей, функций, ресурсов проекта и выделенного времени. Задача определения и управления масштабом состоит в задании базовых требований, которые включают разбитое на компоненты ограниченное число функций, компонентов и требований, намеченных для реализации в конкретном программном продукте. Базовый уровень масштаба комплекса программ должен обеспечивать приемлемый для заказчика минимум функций и требований к программному продукту и разумную вероятность успеха проекта с точки зрения производственных возможностей коллектива разработчиков. При оценивании масштаба следует определить приоритеты функций для установления состава работ, согласованного между заказчиком и разработчиком, которые обязательно должны быть выполнены. Сокращение масштаба проекта до размеров, адекватных выделенному времени и ресурсам, может привести к конфликтам заказчиков и разработчиков. Для уменьшения вероятности таких конфликтов целесообразно активно привлекать заказчиков к управлению их требованиями и масштабом программного продукта, чтобы обеспечить как качество, так и своевременность его производства. При этом следует учитывать, что именно 84 заказчики несут финансовую ответственность за выполнение обязательств перед внешними клиентами и пользователями; а также комплекс программ, его важнейшие функции и удовлетворяемые требования принадлежат заказчику, а не коллективу разработчиков или поставщику. Прогнозирование масштаба — размера, оценка и составление графика производства сложным образом переплетаются в процессе планирования экономики проекта. Довольно сложно создать реальный график (учитывающий затраты, обязанности исполнителей, а также дату поставки продукта) без информации об объеме трудозатрат, требуемых для выполнения каждой задачи (например, определения загрузки и ожидаемых результатов от сотрудников за месяц). Достаточно трудно оценить объем трудозатрат, необходимых для выполнения задач и функций, без достоверной информации относительно их размера. Таким образом, измерение размера (сложности) предшествует оценке экономических характеристик, а эта оценка, в свою очередь, предшествует составлению графика производства. Недостаточно достоверные оценки функций, размера, экономических характеристик и плана работ могут вызывать негативные проблемы взаимодействия разработчиков с заказчиком и увеличивать степень риска проекта комплекса программ. Какая бы технология ни использовалась, оценка размера будущего продукта является весьма важной задачей, поскольку она является основой реальных экономических характеристик производства. Нереальные ожидания участников проекта, основанные на неточных оценках, представляют собой одну из частых причин провала проектов. Зачастую причина кроется не в недостаточной производительности команды специалистов проекта, а в неточном прогнозировании сложности и размера продукта. Точное прогнозирование экономических характеристик обеспечивает улучшенный контроль над проектом и является жизненно важным в деле проектного менеджмента. Привлечение заказчика помогает менее болезненно решать проблемы управления масштабом проекта и реализуемыми функциями с учетом ограничений ресурсов. Любые дополнительные функции за пределами базовых требований, которые реализует производитель, будут восприняты заказчиком как превзошедшие ожидания. В зависимости от этапа производства сложного 85 комплекса программ и достоверности исходных данных о характеристиках и особенностях проекта целесообразно выбирать и применять методики и сценарии прогнозирования экономических характеристик. При прогнозировании экономических характеристик производства программного продукта менеджерам проекта целесообразно учитывать: ●● цели оценивания экономических характеристик должны быть согласованы с потребностями в информации для принятия решений на соответствующем этапе проектирования и производства комплекса программ; ●● достоверности оценок должны быть сбалансированы для различных компонентов комплекса программ, величина уровня неопределенности для каждого учитываемого фактора и компонента должна быть примерно одинаковой, если в процессе принятия решения все они имеют одинаковый вес; ●● следует возвращаться к предшествующим оценкам экономических характеристик и изменять их, когда это необходимо для ответственных бюджетных решений, принимаемых на последовательных этапах и влияющих на реализацию проекта. С самого начала работы над проектом важно вести постоянный учет данных о его действительной трудоемкости, стоимости и затратах и сравнивать эти данные с прогнозами экономических характеристик проекта. Несовершенство исходных данных (оценки сложности функций, размера, влияния факторов) определяет для руководителя проекта необходимость пересматривать их оценки, учитывая новую информацию, чтобы обеспечить более реальную основу для дальнейшего управления проектом. Вследствие несовершенства методов оценивания будущих функций комплекса программ следует оперативно сравнивать оценки экономических характеристик с действительными значениями, получающимися в процессе производства, и использовать эти результаты для улучшения методов и результатов прогнозирования, идентифицировать эти изменения и выполнять реалистичное обновление прогнозов. Каждая оценка экономических характеристик должна сопровождаться указанием степени ее неопределенности. По мере разработки проекта их необходимо пересматривать и изменять, 86 когда это становится полезным. Экономические решения, принимаемые на ранних этапах, должны влиять преимущественно только на следующий этап прогнозов. Для этого в данной главе последовательно рассмотрены и рекомендуются три базовых метода (рис. 5.1): ●● первичный экономический прогноз при подготовке концепции и технического задания на новый комплекс программ на основе экспертных данных о его размере, средней производительности труда специалистов или стоимости разработки одной строки текста программ — прототипов; ●● прогнозирование основных экономических характеристик при предварительном проектировании на базе расчетных значений трудоемкости и длительности разработки комплекса программ по данным упрощенных моделей КОМОСТ или ПРОМЕТЕЙ с учетом влияния минимума дополнительных факторов; ●● определение возможных экономических характеристик проекта с учетом доступных оценок множества факторов для календарного планирования производства сложного программного продукта с использованием систем прогнозирования СОСОМО или СОСОМО II. Неопределенность прогнозов уменьшается по мере детализации и углубления содержания функций проекта, как только фиксируются конкретные принципы функционирования и концепция комплекса программ. На этапе подготовки концепции оценка достоверности размера продукта по прототипам может составлять приблизительно 40% (см. рис. 5.1). Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти задачи могут быть разрешены во время разработки структуры и спецификаций требований к комплексу программ, и тогда можно оценить будущий его размер с точностью до 15–20%. После завершения разработки и подтверждения проектных спецификаций при предварительном проектировании комплекса программ может быть определена структура внутренних данных и функции программных компонентов. На этом этапе достоверность оценки размера и трудоемкости проекта может составить около 10%, что приводит к целесообразности применять более точные модели и учитывать несколько факторов производства. Эти 87 уточнения размеров комплекса и функций компонентов программ могут быть решены к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса программ и его трудоемкости порядка 5–10%, связанная с тем, насколько хорошо программисты и тестировщики понимают спецификации и алгоритмы, в соответствии с которыми они должны кодировать программы. Поэтому целесообразно последовательно уточнять исходные данные и проводить прогнозирование экономических характеристик для различных компонентов программного продукта и этапов проектирования. В общем случае желательно достигать сбалансированного выбора целей прогнозирования экономических характеристик комплекса программ, который бы давал примерно одинаковую величину влияния уровня неопределенности для всех исходных данных, учитываемых факторов и компонентов продукта. Модели прогнозирования экономических характеристик производства программных продуктов включают: ¡¡ на этапе разработки целей и концепции проекта: ●● экспертные оценки экономических характеристик по прототипам — достоверность оценивания размера продукта 40–50%; ¡¡ на этапе предварительного проектирования: ●● оценивание экономических характеристик в базовой модели КОМОСТ — учитывается один фактор и достоверность оценивания размера продукта — 20–30%; ●● оценивание экономических характеристик в детализированной модели КОМОСТ — учитываются три фактора и достоверность оценивания размера продукта — 10–20%; ¡¡ на этапе детального проектирования: ●● оценивание экономических характеристик в упрощенной, предварительной модели СОСОМО или ПРОМЕТЕЙ — учитываются семь факторов и достоверность оценивания размера продукта — 5–10%; ●● оценивание экономических характеристик в детальной модели СОСОМО II — учитываются двадцать два фактора и достоверность оценивания размера продукта 3–5%. Рис. 5.1 88 Вследствие этого изложение анализа и обоснования прогнозирования экономических характеристик ниже разделено на три крупные части. В данном разделе рассматриваются первичные, базовые оценки трудоемкости, длительности и числа специалистов в зависимости от размера комплекса программ, повторного использования компонентов и небольшого числа факторов. Далее уточняются экономические характеристики и оценивается влияние на них ряда дополнительных факторов: особенностей и качества объектов и среды разработки, квалификации и организации специалистов, технологической, инструментальной и аппаратурной оснащенности проекта с использованием модели СОСОМО II (см. рис. 5.1). По мере проектирования и производства комплекса программ, оценки экономических характеристик необходимо пересматривать и изменять, когда это становится выгодным или необходимым. Экспертное прогнозирование экономических характеристик производства программных продуктов В простейшем методе может быть реализован прогноз экономических характеристик производства программного продукта с учетом экспертной оценки минимального числа факторов. Эта методика может применяться, когда определены цели, масштаб и общие функции комплекса программ в концепции и первичных требованиях с достоверностью около 30–40%. Основная цель такого прогноза экономических характеристик — подготовка обоснованного решения о допустимости развития проекта в область системного анализа, разработки требований и предварительного проектирования. Если оказывается, что прогнозируемые экономические показатели и требуемые ресурсы не могут быть обеспечены для продолжения проектирования и производства, то возможны кардинальные решения: либо изменение некоторых требований к характеристикам программного продукта и выделяемых ресурсов, либо прекращение проектирования данного комплекса программ. 89 Учитывая полноту и достоверность доступных характеристик и требований к проекту должны быть определены цели и возможная достоверность экономического прогнозирования затрат при продолжении проектирования и производства продукта. При первичном экономическом обосновании сложных комплексов программ наибольшее значение имеют ключевые факторы: ●● сложность и размер — масштаб подлежащих разработке полностью новых программных компонентов и всего комплекса (количество строк текста с указанием языка программирования); ●● размер и относительная доля готовых программных компонентов, которые могут быть заимствованы из предшествовавших продуктов и повторно использованы в новом проекте комплекса программ (%); ●● относительные затраты ресурсов на создание программного продукта: труда специалистов (человеко-месяцы), времени или бюджета на единицу размера (на строку текста программ) проектируемого комплекса программ; ●● возможная исходная стоимость разработки одной строки текста в комплексе программ. Эти факторы могут быть прогнозируемы квалифицированными экспертами на основе имеющегося у них опыта реализации предшествовавших подобных проектов, а также с использованием опубликованных данных (оптимистических и/или пессимистических оценок). При наличии необходимых данных важно оценить их достоверность и возможную точность. При наличии перечисленных исходных данных и положительной оценке целесообразности экспертного прогноза экономики проекта может реализовываться методика, состоящая из следующих основных шагов: ●● экспертная оценка размера — масштаба, числа строк предполагаемого текста разрабатываемых программ с учетом размера повторно используемых компонентов и характеристик возможного языка программирования; ●● экспертная оценка возможной средней производительности труда в команде специалистов при разработке комплекса программ и/или стоимости разработки одной строки текста программ продукта; 90 ●● расчет возможной полной трудоемкости и длительности проектирования и производства программного продукта, а также среднего числа специалистов, необходимых для его реализации; ●● обобщение основных экономических характеристик и полной стоимости программного продукта, анализ результатов и экономическое обоснование рентабельности продолжения проектирования и производства комплекса программ. Достоверность прогнозов экономических характеристик зависит, прежде всего, от точности экспертной оценки исходных данных: размера — масштаба комплекса программ, и от достоверности экспертной оценки производительности труда специалистов или стоимости разработки одной строки текста программ. Экспертные прогнозы предполагают использование опыта прошлых разработок и их отличия от новых методов, предусмотренных в конкретных проектах, а также учет индивидуальных возможностей специалистов коллектива разработчиков и/или другие уникальные особенности проекта. Экспертные оценки зависят от компетенции и объективности экспертов, их оптимистичности, пессимистичности, знания существенных особенностей предполагаемого продукта. Оценки одного эксперта трудно проверять и контролировать на достоверность. Из-за индивидуальных особенностей экспертов предпочтительным является прогнозирование экономических характеристик несколькими экспертами и получение средних оценок на совещании группы экспертов для формирования единой оценки. Основными исходными данными для прогнозов являются концепция проекта программного продукта и состав требований к набору их функций и характеристик, которые могут быть детализированы на предполагаемые функциональные компоненты (с учетом приоритетов) комплекса программ. В дальнейшем требования могут детализироваться, формируя упрощенный или более точный уровень абстракции архитектуры комплекса и взаимодействия компонентов. Экспертный прогноз удельных затрат на строку текста программного продукта обычно относится к полному циклу производства сложных комплексов программ, начиная от создания концепции и требований до завершения испытаний и передачи программного продукта заказчику или пользователям. В составе 91 участников проекта учитываются все категории специалистов, обеспечивающие реализацию программного продукта. Несмотря на появление новых методов и инструментальных средств для разработки сложных комплексов программ, средняя производительность при их создании за последние годы оставалась почти неизменной и составляет около 3000 строк кода на одного разработчика продукта в год (порядка 250 строк на человеко-месяц). Уменьшение времени, затрачиваемого на цикл производства крупного продукта, не может быть достигнуто за счет значительного повышения производительности труда только отдельных специалистов — программистов. Она практически не зависит от усовершенствований языков программирования, организационных усилий со стороны менеджеров, от наличия или отсутствия некоторых отдельных видов инструментария и автоматизации производства компонентов и модулей. Однако значительно влияет доля повторно используемых компонентов. При достаточно высоком уровне технологии (см. главу 6, уровни 4–5 — СММI) большое значение имеет возросший размер и сложность состава функциональных задач комплексов программ, а также значительное повышение требуемого качества и ответственности за создаваемые программные продукты. Так как предприятия и разработчики сложных комплексов программ не заинтересованы раскрывать реальную экономику выполненных проектов и производства программных продуктов (они эти данные склонны относить к коммерческой тайне), опубликованные экономические характеристики программных проектов носят отрывочный, не упорядоченный и не всегда достоверный характер. Поэтому такие данные трудно обобщать и использовать для прогнозирования новых проектов. Эти данные можно использовать для прогнозирования полной стоимости программного продукта. Однако при этом необходимы удельные данные стоимости труда одного человеко-месяца специалистов в конкретном предприятии с учетом всех накладных расходов, которые могут различаться в несколько раз. Такие сведения обычно являются коммерческой тайной, и при использовании данного метода для определенного проекта их следует запрашивать у экономических служб конкретного предприятия. Опубликованы ориентиры около 100$ и более стоимости разработки одной строки текста программ 92 реального времени высокого качества (1000$ бортовые комплексы программ системы Шатл), а для административных систем — около 20–50$. Обобщенные экспертные оценки экономических характеристик проектов целесообразно представлять в виде таблиц (желательно) с указанием достоверности оценок результатов расчетов следующих характеристик: ●● полной трудоемкости производства программного продукта — C (человеко-месяцы с указанием учитываемых факторов); ●● полной длительности производства программного продукта — T (месяцы); ●● необходимого среднего числа специалистов — N (человек); ●● средней производительности труда Р специалистов (число строк на человеко-месяц). На основе анализа результатов оценивания рассчитанных характеристик целесообразно выполнить экономическое обоснование перспективы производства программного продукта и определить (см. главу 1): ●● следует ли продолжать работы над конкретным проектом программного продукта; ●● полезно ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта; ●● корректно ли формализованы концепция и требования к программному продукту и возможно ли их совершенствование; ●● есть ли возможность применить готовые повторно используемые компоненты или весь проект целесообразно разрабатывать как полностью новый. Простейшие модели прогнозирования экономических характеристик производства программных продуктов На этапе предварительного проектирования комплекса программ, после утверждения требований и концепции проекта, повышается достоверность данных о функциях, спецификациях, компонентах и структуре разрабатываемого комплекса программ. 93 Это позволяет, прежде всего, более точно оценить размер — масштаб комплекса и возможность использования готовых программных компонентов из других аналогичных проектов. Если достоверность оценки размера достигает 15–20%, то при определении экономических характеристик целесообразно выделять и учитывать факторы, влияние которых на трудоемкость и стоимость достаточно велико и составляет также около 20%. Таких факторов может быть около 3–5, и их число зависит от конкретных характеристик программного продукта и среды его производства. На этом этапе состав и номенклатура учитываемых факторов должны выбираться путем включения в анализ тех, которые могут достаточно сильно влиять на экономику конкретного проекта. Таким образом, методика и сценарии оценки экономических характеристик должны калиброваться по шагам в соответствии с уменьшением неопределенности влияния факторов и исходных данных о размере проекта (см. рис. 5.1). Так как величина и достоверность определения размера комплекса программ ключевой фактор последующего экономического анализа, то целесообразно применять несколько доступных методов для его оценивания. Прежде всего, необходимо использовать, ревизовать и углубить данные экспертной оценки возможного размера продукта, полученные при использовании предыдущей методики, с учетом повышения достоверности характеристик проекта по результатам предварительного проектирования. Конкретизация функций, структуры комплекса программ и состава компонентов проекта позволяет более достоверно определить размеры компонентов комплекса программ и, суммируя их, оценить размер всего комплекса. Кроме того, на этом этапе повышается возможность выбора и использования аналогов данного проекта, так как становятся более определенными задачи, функции и компоненты разрабатываемого комплекса, для которого желательно найти аналоги с известными апробированными характеристиками. Особенно сильно на экономические характеристики влияет использование готовых компонентов из предшествующих разработок. При анализе аналогов могут быть выделены компоненты, пригодные для повторного применения в новом проекте. Это позволяет оценить возможную долю использования готовых компонентов и тем самым определить эквивалентный размер комплекса программ, подлежащий непосредственной разработке. 94 В моделях для первичной оценки экономических характеристик полного цикла производства размер комплекса программ и остальные факторы рекомендуется учитывать поправочными коэффициентами при уточнении интегральных показателей. Для комплексов программ первого и второго классов, характеристики которых приведены в главе 3, исследовалась зависимость трудоемкости производства программного продукта С от его размеров — П. По мере увеличения размера комплекса программ возрастают не только абсолютные, но и относительные затраты на разработку каждой строки текста в программе. Вследствие этого затраты труда при разработке одной строки текста в программах разного размера могут различаться в несколько раз. При производстве комплексов программ большого размера может возрастать сложность разработки по сравнению с программами малого размера, так как в них усложняются взаимосвязи компонентов по информации и управлению, а также становятся более трудоемкими процессы планирования, тестирования и управления компонентами в ходе производства. При увеличении размера комплекса программ наблюдается более быстрый рост сложности их разработки, чем описываемый простой линейной зависимостью. Эксперементально подтверждено, что по мере увеличения размера комплекса возрастает относительная трудоемкость разработки каждой строки в программе. Для аппроксимации зависимости трудоемкости от размера комплекса программ удобно использовать степенную функцию вида: . (5.1) Гипотеза о возрастании трудоемкости разработки с ростом размера комплекса быстрее, чем по линейному закону, справедлива, если показатель степени в полученном уравнении регрессии Е > 1. В ряде работ при анализе статистики трудоемкости реальных проектов определены коэффициенты А и Е, показывающие характер зависимости трудоемкости от размера программного продукта. При производстве крупных программных продуктов большие затраты приходятся на создание технологии, средств автоматизации и унификации производства, на выбор специалистов и предприятия — поставщика компонентов. На практике изредка 95 пользуются упрощенной линейной зависимостью трудозатрат от размера программного продукта (Е = 1). Такое упрощение при недостаточно корректных исходных данных о размере проекта комплекса программ и отсутствии сведений о факторах, влияющих на производство комплекса программ, можно считать допустимым. На рис. 5.2 по уравнению (5.1) построены в логарифмическом масштабе зависимости трудозатрат С от размера П для комплексов программ двух классов. Первый (встроенные — СРВ) и второй (АС) классы программного продукта отчетливо различаются по трудоемкости разработки. Рис. 5.2 Для учета влияния на трудоемкость С минимума основных факторов можно использовать коэффициенты (рейтинги) изменения трудоемкости (КИТ) производства — М (i), учитывающие влияние i-й составляющей совокупных затрат. В них входят факторы процесса непосредственной разработки, факторы программной и аппаратурной оснащенности, а также квалификация специалистов. При этом затраты на разработку можно представить в зависимости от размера комплекса программ П, корректируемого произведением коэффициентов изменения трудоемкости (КИТ — М (i)): . 96 (5.2) Возможные группы и значения коэффициентов М (i)) подробно исследованы и отражены в монографиях. Для детальной модели КОМОСТ рекомендовалось четыре группы характеристик: размер объекта производства; квалификация специалистов; технологическая среда; вычислительная среда. Всего было проанализировано около 20 факторов, для которых подробно рассмотрены изменения соответствующих коэффициентов. Впоследствии при формировании предварительной модели СОСОМО сокращено до семи. Одновременно были изменены исходные выражения для прогнозирования трудоемкости и введены масштабные факторы. В предварительной модели СОСОМО масштабные факторы не учитываются. Таблица 5.1 Состав и содержание факторов упрощенной предварительной модели СОСОМО Символ Содержание групп факторов Требования к объекту разработки М1 Сложность и надежность программного продукта М2 Требование повторного использования компонентов Характеристики коллектива специалистов М4 Квалификация специалистов и стабильность коллектива М5 Опыт работы по тематике и с инструментарием Технологическая среда производства М6 М7 Уровень инструментальной поддержки и необходимость распределения производства Ограничение длительности производства Аппаратурно-вычислительная среда производства М3 Ограничения аппаратной платформы производства и применения продукта После того как выбраны архитектура, этапы разработки предварительного проекта и кодирования возможен ввод уточненного размера комплекса программ в предварительной модели трудоемкости. 97 Таблица 5.2 Коэффициенты изменения трудоемкости производства программных продуктов в упрощенной предварительной модели СОСОМО Факторы Сложность и надежность M1 Требования повторного использования компонентов М2 Квалификация специалистов М4 Опыт работы М5 Инструментальная поддержка М6 Ограничение длительности разработки М7 Аппаратурно-вычислительная среда МЗ Рейтинги оценки номиочень сверх очень высокий низкий нальный высокий высокий низкий 0,60 0,83 1,00 1,33 1,91 2,72 0,95 1,00 1,07 1,15 1,24 1,62 1,26 1,00 0,83 0,63 0,50 1,33 1,12 1,00 0,87 0,74 0,62 1,30 1,10 1,00 0,87 0,73 0,62 1,43 1,14 1,00 1,00 1,00 0,87 1,00 1,29 1,81 2,61 В упрощенной предварительной модели СОСОМО при достаточной достоверности определения масштаба комплекса программ рекомендуется в выражении (5.2) учитывать семь факторов М (i), представленных в таблице 5.1. Для каждого из них в таблице 5.2 приведены значения рейтингов (коэффициентов изменения трудоемкости — КИТ), которые целесообразно использовать при 98 выборе определенного содержания факторов конкретного проекта. Учет этих факторов при прогнозировании экономических характеристик может быть достаточным для проектов комплексов программ на этапе предварительного проектирования. Содержание и комментарии к фактору M1 — сложность и надежность программного продукта, достаточно подробно изложены в главах 2 и 3, которые целесообразно использовать при определении рейтингов прогнозирования экономических характеристик конкретного проекта. Характеристики коллектива специалистов для использования их при оценке рейтингов факторов M4 и M5 подробно анализируются в главе 6. В главе 7 содержатся разделы, посвященные рейтингам факторов M6 и M7 технологической среды производства и фактору M3, ограничений ресурсов аппаратной платформы производства и применения программного продукта. Подобная модель прогнозирования экономических характеристик была создана в проекте ПРОМЕТЕЙ. В модели учитывались тринадцать факторов, скомпонованных в аналогичные четыре группы для комплексов программ реального времени, разрабатывавшихся на ассемблере. При использовании подобных моделей с множеством факторов следует учитывать, что для определения рейтингов при прогнозировании экономических характеристик сложных комплексов программ требуются опыт и интуиция квалифицированных системных аналитиков и экономистов в области программной инженерии. 99 Глава 6 Модель прогнозирования экономических характеристик производства программных продуктов СОСОМО II Основные компоненты модели СОСОМО II Накопленный опыт и обобщение проведенных исследований позволили создать и детализировать наиболее мощную, известную модель COCOMO II. Она достаточно полно отражена таблицей 6.1 и четырьмя основными группами факторов, определяющими экономические характеристики при проектировании и производстве программных продуктов: ●● факторы, отражающие требования к характеристикам создаваемого комплекса программ как объекта проектирования и производства; ●● факторы, определяющие организацию и квалификацию коллектива для производства программного продукта и его обеспечение квалифицированными специалистами; ●● факторы, характеризующие технологическую среду и оснащенность инструментальными средствами автоматизации процесса производства программного продукта; ●● факторы, отражающие оснащенность процесса производства программного продукта аппаратурными вычислительными средствами, на которых реализуется программный продукт и базируются инструментальные системы автоматизации разработки. При использовании выражений (6.1) для прогнозирования экономических характеристик конкретных проектов следует выбирать набор факторов (калибровать модель), имеющих значения коэффициентов изменения трудоемкости (КИТ) F (j) в соответствии с характеристиками конкретного проекта. Для выбора значений M (i) в соответствии с характеристиками конкретного 100 продукта и среды разработки следует использовать таблицы рейтингов трудоемкости для выделенных четырех групп, представленных ниже в таблицах. Таблица 6.1 Состав факторов детальной модели COCOMO II Символ F1 F2 F3 F4 F5 Содержание фактора Масштабные факторы Новизна проекта Согласованность с требованиями и интерфейсами Управление рисками и архитектурой проекта Слаженность работы коллектива Технологическая зрелость обеспечения разработки Определяется сумма рейтингов F (j) для расчетов трудоемкости и длительности M1 M2 M3 M4 M5 Факторы, влияющие на затраты производства Требования и характеристики объекта Надежность функционирования Размер базы данных Сложность функций и структуры Требование повторного использования компонентов Полнота и соответствие документации проекта M9 M10 M11 M12 M13 M14 Характеристики коллектива специалистов Квалификация аналитиков Квалификация программистов Стабильность коллектива Опыт работы по тематике проекта Опыт работы в инструментальной среде Опыт работы с языками программирования M15 M16 M17 Технологическая среда производства Уровень инструментальной поддержки проекта Необходимость распределенной разработки проекта Ограничения длительности производства продукта M6 M7 M8 Аппаратурно-вычислительная среда производства Ограниченность времени исполнения программ Ограниченность доступной оперативной памяти Изменчивость виртуальной среды разработки проекта Определяется произведение рейтингов М (i) для расчетов трудоемкости и длительности 101 Для прогнозирования трудоемкости производства программных продуктов (человеко-месяцы) в модели СОСОМО II предложены выражения, уточняющие и детализирующие зависимость: , (6.1) где . В детальной модели СОСОМО II на трудоемкость производства программного продукта учитывается влияние 22 фактора — таблица 6.1. Из них пять — масштабные факторы, характеризуются суммой F (j) в значении степени влияния размера комплекса программ E. В уравнении оценки трудозатрат в детальной модели СОСОМО II варьируются и применяются факторы масштабирования F (j) с целью обобщения воздействия основных параметров при прогнозировании производства программных продуктов. Произведение множителей M (i) — 17 факторов, непосредственно влияет на изменение трудоемкости производства в выражении (6.1). Совокупность 22 факторов этой модели представляется достаточно полной при оценивании экономических характеристик производства комплекса программ. Из 17 факторов детальной модели СОСОМО II в этих таблицах исключен только фактор М16 вследствие неопределенности способов его оценки. Номинальными (средними) в выражениях принимаются значения M (i) = 1,00, при которых соответствующий фактор не влияет на трудоемкость производства программного продукта. Для прогнозирования длительности производства программных продуктов в модели СОСОМО II более детально рассмотрены исходные данные на основе анализа трудоемкости его производства. Зависимость длительности производства от ее трудоемкости практически одинаковая для двух классов комплексов программ (СРВ и АС). При этом рекомендуется учитывать те же наборы факторов, которые применяются при 102 прогнозировании трудоемкости непосредственного производства программного продукта С: , (6.2) где: . Максимальные величины каждого из КИТ производства программных продуктов экспериментально оценены при предположении, что остальные параметры зафиксированы. В действительности многие факторы взаимно коррелированны. Так, например, высокой сложности комплекса программ обычно сопутствует требование высокой безопасности и надежности функционирования, а также длительная эксплуатация. Ряд факторов отражается одновременно на нескольких КИТ. Воздействие в процессе производства на такие факторы и субъективное стремление специалистов на сокращение определенных видов затрат в некоторых случаях, может оказываться нерентабельным с позиции снижения полных затрат на производство программного продукта. Например, стремление уменьшить затраты в период производства без учета последующего использования продукта, его компонентов и всего жизненного цикла может оказаться мало полезным, а в некоторых случаях привести к значительному увеличению совокупных затрат. При создании многих сложных программных продуктов затраты исчисляются сотнями человеко-лет, что определяет особую актуальность возможно точного учета некоторых факторов, способствующих снижению прогнозируемых затрат при таких масштабах производства и применения. Поэтому зачастую необходим системный анализ и тщательное распределение ресурсов на этапы производства конкретных комплексов программ путем выбора КИТ (калибровки модели) с учетом всего их жизненного цикла. Большую роль в повышении экономической эффективности производства программных продуктов играет повторное 103 использование готовых программных компонентов из других проектов. При этом необходимо учитывать дополнительные затраты для обеспечения возможности повторного использования компонентов вместо разработки компонентов заново каждый раз и сокращение интегральных затрат на производство продукта при их применении. В выражениях (6.1) и (6.2) СОСОМО II предусмотрен учет затрат на подготовку компонентов для возможности их многократного применения в составе требований к характеристикам программных продуктов (см. фактор М4 в таблицах 6.5 и 6.6). Влияние масштабных факторов производства программных продуктов СОСОМО II при прогнозировании экономических характеристик В предыдущем разделе описаны наиболее значительные интегральные факторы модели СОСОМО II, влияющие на трудоемкость программных продуктов. Из них 5 масштабных факторов прогнозирования F (j) могут существенно изменять трудоемкость и стоимость производства. Остальные 17 факторов M (i) объединены в четыре группы модели СОСОМО II. Каждый из них может влиять на экономические характеристики производства сложных программных продуктов на уровне 5–10%. Разделы данной главы посвящены комментированию факторов из этих групп, при этом предполагается, что для основных факторов имеются их описания, представленные ниже. Рекомендуется выбирать и учитывать те факторы, коэффициенты влияния которых на трудоемкость в конкретном проекте имеют достаточно большую величину, коррелированную с точностью определения размера комплекса программ или превышают ее. В группу — F (j) следует включать, совокупность факторов из таблицы 6.1, которые способны значительно изменять трудоемкость: ●● новизну проекта комплекса программ; ●● необходимую степень согласованности проекта с требованиями технического задания; ●● наличие управления рисками и архитектурой проекта; 104 ●● уровень обобщенной квалификации, слаженности и организованности коллектива разработки проекта; ●● уровень обеспечения и оснащения технологии производства по оценке зрелости модели СММI. Новизну проекта F1 рекомендуется учитывать при прогнозировании по величине формализации целей и функций программного продукта, наличия у специалистов опыта аналогичных разработок, а также необходимости создания новых архитектуры, компонентов, алгоритмов обработки данных. Влияние этого фактора в выражении (6.4) может превышать коэффициент 6 и достаточно подробно комментирован в таблице 6.6, что позволяет корректно выбирать значения рейтингов в таблице 6.7, адекватные конкретному проекту. При этом в крайних значениях рейтингов предполагается, что полностью отсутствовало проектирование и производство подобного программного продукта или такие продукты были освоены для серийного производства. Согласованность (жесткость выполнения требований) F2 проекта программного продукта определена как степень обеспечения соответствия заданным требованиям и спецификациям заказчика к компонентам, к внутренним и внешним интерфейсам, ко всему комплексу программ в процессе его проектирования и производства. В первом предельном случае считается, что все требования должны быть выполнены обязательно полностью, а в другом крайнем варианте рейтингов эти требования могут рассматриваться только как необязательные пожелания. Для учета этого фактора предложены рейтинги соответствующих коэффициентов (до 5) изменения трудоемкости разработки (см. таблицу 6.7). Наличие управления рисками F3 и архитектурой проекта трудно формализовать содержательно и адекватными значениями рейтингов. Поэтому далее в учебнике этот фактор не рассматривается. В модели СОСОМО II значительное внимание уделено влиянию организации и взаимодействия коллектива квалифицированных разработчиков F4 на трудоемкость создания сложных программных продуктов. Этот фактор подробно иллюстрируется его составляющими в таблице 6.3. В составе организационных характеристик коллектива рекомендуется учитывать согласованность целей специалистов, участвующих в проекте, их психологическую совместимость и способность к дружной коллективной работе, наличие 105 опыта работы в данном коллективе и другие объективные и субъективные свойства участников проекта. При этом большое значение могут иметь личная мотивация и психологические особенности поведения специалистов при комплексной работе над проектированием и производством сложного программного продукта. Эти характеристики обобщены в показатель влияния коллективности — сложности взаимодействия специалистов F4 в коллективе, которому сопоставлены рейтинги изменения трудоемкости производства продукта (строка в таблице 6.1). Наилучшим считается непрерывное корректное взаимодействие организованной «команды» специалистов с большим опытом работы в данном коллективе при полной согласованности их целей, планов и методов работы. Таблица 6.2 Характеристики и влияние коллективизма разработчиков программных продуктов на трудоемкость их производства Коллективизм Значения характеристик номиочень низкий высокий нальный высокий НезнаМинимальОтноси- ЗначичительПолная ная тельная тельная ная очень низкий Согласованность целей коллектива Способность членов коллектива адаптиро- Малая ваться к целям других Опыт работы в составе данно- Нет го коллектива Степень доверия и Нет взаимодействия в коллективе Некоторое Обобщенная взаимодейколлективность ствие в колработ лективе Обобщенный коэффициент 5,48 влияния коллективности F4 106 НезнаОтносичительтельная ная Малый Значительная Полная Незначи- ЗначиБольшой тельный тельный В некоВ малой торой степени степени Значительная Сложное взаимодействие Зачастую коллективная работа Высокая Непрерывстепень ное взаимовзаимодействие действия 4,38 3,29 2,19 Большая 1,10 В остальных случаях может отсутствовать глубокое взаимодействие отдельных специалистов, вследствие чего возрастать (даже в несколько раз) трудоемкость производства продукта. В модели СОСОМО II для оценивания экономических характеристик при проектировании и производстве рекомендуется учитывать уровень методологии производства и обеспечения качества сложных программных комплексов F5 на основе системы и модели оценки зрелости СММI, применяемых технологических процессов. Она основана на формализации и использовании пяти уровней зрелости технологий поддержки всего ЖЦ комплекса программ, которые также определяют потенциально возможные экономические характеристики и качество создаваемых на предприятии программных продуктов (рис. 6.1). Чем выше уровень зрелости, тем выше статус предприятия среди поставщиков, доверие к его продукции, ее конкурентоспособность, а также возможное качество продуктов. Тем самым при прогнозировании экономических характеристик и выборе требований качества продукта можно в соответствующей степени доверять поставщику и предприятию разработчика, что оно сможет реализовать согласованные требования заказчика. Эти уровни зрелости характеризуются: степенью формализации; адекватностью измерения и документирования процессов производства и программных продуктов; широтой применения стандартов и инструментальных средств автоматизации работ; наличием и полнотой реализации функций системой обеспечения качества технологических процессов и их результатов. Методология обеспечения качества программных продуктов поддержана рядом методических документов, а также формализована международными стандартами. Качество процессов производства зависит от технологической среды, в которой они выполняются. Зрелость процессов — это степень их управляемости, возможности поэтапной количественной оценки затрат и качества, контролируемости и эффективности результатов. Модель зрелости предприятия представляет собой методический материал, определяющий правила создания и применения системы управления проектированием и производством, повышения культуры и качества комплексов программ. 107 Рекомендуется ограничиваться четырьмя (2–5-й) основными уровнями: ●● 2-й уровень — формализует базовые процессы управления проектами: ●● 3-й уровень — содержит стандартизацию основных процессов технологии: ●● 4-й уровень — определяет количественное и качественное управление процессами: ●● 5-й уровень — оптимизационный, непрерывное совершенствование процессов технологии проектов. Рекомендуется на каждом более высоком уровне зрелости применять все процессы предыдущих нижних уровней. В обоих вариантах модели каждый выделенный выше базовый процесс комментируется подробными рекомендациями для его практической реализации, которые содержат унифицированные по структуре описания. Реальное использование рекомендуемых процессов производства предполагает их документирование, поэтапный контроль экономических характеристик и качества. На предприятиях, достигших высокого уровня зрелости, процессы производства должны принимать статус стандарта, фиксироваться в организационных структурах и определять производственную тактику и стратегию корпоративной культуры производства и системы обеспечения качества программных продуктов. При экономическом обосновании программных проектов, для достижения устойчивых результатов в процессе развития технологии и организации управления жизненным циклом комплексов программ рекомендуется использовать эволюционный путь, который позволяет совершенствовать, постепенно снижать затраты и повышать качество процессов производства и продуктов. Методология СММI рекомендует большой комплекс процессов, который предприятие должно выполнять для приобретения, поставки, производства, использования и сопровождения крупных комплексов программ, и виды деятельности, характеризующие степень технологической зрелости этих процессов. В модели СОСОМО II приводятся количественные рекомендации коэффициентов влияния уровней зрелости СММI на трудоемкость реализации сложных программных продуктов. Рейтингам технологической зрелости производства в детальной модели 108 СОСОМО II сопоставлены уровни СММI, для каждого из которых приводятся коэффициенты изменения трудоемкости разработки (почти до 8). Применение совершенных технологий и инструментальных средств высшего уровня зрелости может снизить трудоемкость производства сложных программных продуктов более чем в 5 раз по сравнению с наиболее широко применяемыми технологиями второго — третьего уровня зрелости СММI. Независимую оценку уровня СММI на предприятии и выбранной технологии производства можно использовать как ориентир при прогнозировании и экономическом обосновании производства предполагаемого продукта. Факторы четырех групп коэффициентов M (i) рекомендуется выбирать из совокупности перечисленных в таблице 6.1, которые в конкретном проекте могут повлиять на изменение трудоемкости производства на 10–20%, соизмеримое с точностью оценок размера комплекса программ. Анализ, выбор и оценивание коэффициентов влияния М (i) оправданы, когда совместное влияние совокупности этих дополнительных факторов может заметно изменить оценки трудоемкости. Таблица 6.3 Масштабные факторы требований к объектам разработки Характеристики факторов очень сверх очень номинизкий высокий низкий нальный высокий высокий ЗначиПолно- Во В основПолноНовизна Частично тельно стью многом ном изстью изпроекта F1 новый известновый новый вестный вестный ный СогласоСтрогая ДопуПри согла- скаются ЗначиОтноси- Незначиванность необходис требова- сован- компро- тельная тельная тельная мости ниями F2 ность миссы НекоСлож- Зачастую Высокая НепреАктивное торое ное вза- коллек- степень рывное Коллективвзаимовзаиимодей- тивная взаимо- взаимоность F4 действие модействие работа действия действие ствие Зрелость CMMI CMMI CMMI CMMI CMMI CMMI производ- УроУровень Уровень 2 Уровень 3 Уровень 4 Уровень 5 ства F5 вень 1 1 Факторы 109 Таблица 6.4 Рейтинги масштабных факторов объектов разработки Факторы Новизна проекта F1 Согласованность требований F2 Коллективность F4 Зрелость производства F5 Рейтинг факторов очень номиочень сверх высокий низкий нальный высокий высокий низкий 6,20 4,96 3,72 2,48 1,24 0,00 5,07 4,05 3,04 2,03 1,01 0,00 5,48 4,38 3,29 2,19 1,10 0,00 7,8 6,24 4,68 3,12 1,56 0,00 Таких факторов практически может быть выделено до 10 из 17, влияние каждого целесообразно рассматривать и учитывать при оценках, если он способен изменить трудоемкости разработки конкретного проекта на 5–10%. Ниже представлены четыре раздела в соответствии с группами факторов M (i). В модели СОСОМО II поддерживаются вероятностные диапазоны оценок рейтингов, представляющие одно стандартное отклонение из средних оценок. Реально для различных конкретных проектов с учетом их особенностей используется только около половины факторов, приведенных в таблице 6.2. Требуемые характеристики программных продуктов Среди характеристик объекта разработки, кроме его размера и доли, повторно используемых компонентов, наибольшее влияние на экономические характеристики могут оказывать требуемая надежность М1 и сложность М3 функций комплекса программ. Содержание и возможные значения этих факторов описаны в таблицах 6.2–6.3. Особое влияние на экономические 110 характеристики некоторых критических программных продуктов могут оказывать высокие требования надежности и документированности программного продукта. Они могут увеличивать трудоемкость их производства более чем на 20%, а в некоторых критических системах даже в два раза. Таблица 6.5 Требуемые характеристики программных продуктов Уровень требований номиочень сверх очень низкий высокий нальный высокий высокий низкий Неболь- Средний Высокий Требуемая Малые шие воз- возмож- финанРиск для надежность неудобможные ный совый жизни M1 ства потери ущерб ущерб Сложность функций Очень Очень Особенно Низкая Обычная Высокая комплекса низкая высокая высокая МЗ БД100 < 100 < Размер баБД/КП > 10 < БД/ байт/ БД/КП < БД/КП < зы данных 1000 SLOC КП < 100 1000 1000 М2 КП < 10 В предеТребуемое лах сеВ преДля В преповторное мейства делах любого Нет Низкое делах использовапродукта продукта продук- фирмы ние М4 тов Полные Отдель- технолоДоку- Эксплугические ные ФрагСоответменты атацитехноло- и эксствие доку- менты этапов онные гические плуатаментации докуи компо- докумендокумен- ционные ментов М5 нентов ты ты документы Характеристики 111 Таблица 6.6 Рейтинги характеристик программных продуктов Характеристика Требования надежности M1 Сложность комплекса МЗ Размер базы данных М2 Повторное использование М4 Соответствие документации M5 Уровень оценки очень номиочень сверх высокий низкий высокий высокий низкий нальный 0,82 0,92 1,00 1,10 1,26 0,73 0,87 1,00 1,17 1,34 0,90 1,00 1,14 1,28 0,95 1,00 1,07 1,15 0,91 1,00 1,11 1,23 0,81 1,74 1,24 Влияние затрат на обеспечение требований повторного использования программных компонентов М4 достаточно ясно комментируется в таблицах. Фактор размер базы данных М2 наиболее неопределенный и трудно измеряемый. Поэтому он приводится в таблицах, так как представлен в описании СОСОМО II без дополнительных комментариев. Он отражается соотношением объема памяти, занятой информацией базы данных (БД), к величине памяти используемой комплексом программ (КП). Соответствие программного продукта документации М5 анализируется в таблице 6.5 и рейтингов влияния на трудоемкость производства в таблице 6.6 может быть вполне достаточным для учета значений этого фактора. 112 Влияние свойств специалистов при прогнозировании экономических характеристик производства программных продуктов Важнейшим фактором при экономическом прогнозировании, отражающим производство программных продуктов, являются люди — специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности и повышение ответственности за качество привели к появлению новых требований к специалистам, обеспечивающим все этапы жизненного цикла комплексов программ. Структура коллектива разработчиков обычно в значительной степени отражает структуру разрабатываемого комплекса программ. Особенно это заметно при создании продуктов размером порядка 105–107 строк текста. При этом распределение функциональных программ локализуется по соответствующим группам специалистов с целью минимизации связей и взаимодействия как между группами разработчиков, так и между создаваемыми ими компонентами комплексов программ. Влияние затрат на обеспечение требований повторного использования программных компонентов М4 достаточно ясно комментируется в таблицах. Фактор размер базы данных М2 наиболее неопределенный и трудно измеряемый. Поэтому он приводится в таблицах, так как представлен в описании СОСОМО II без дополнительных комментариев. Он отражается соотношением объема памяти, занятой информацией базы данных (БД), к величине памяти, используемой комплексом программ (КП). Соответствие программного продукта документации М5 анализируется в таблице 6.5 и рейтингов влияния на трудоемкость производства в таблице 6.6, может быть вполне достаточным для учета значений этого фактора. Поэтому трудно ожидать, что некий способ организации производства и команды специалистов будет во всех случаях предпочтительнее, чем альтернативные практические варианты. Влияние затрат на обеспечение требований повторного использования программных компонентов М4 достаточно ясно комментируется 113 в таблицах. Фактор размер базы данных М2 наиболее неопределенный и трудно измеряемый. Поэтому он приводится в таблицах, так как представлен в описании СОСОМО II без дополнительных комментариев. Он отражается соотношением объема памяти, занятой информацией базы данных (БД), к величине памяти используемой комплексом программ (КП). Соответствие программного продукта документации М5 анализируется в таблице 6.5 и рейтингов влияния на трудоемкость производства в таблице 6.6, может быть вполне достаточным для учета значений этого фактора. В модели СОСОМО II изложены экспертные оценки для учета влияния квалификации и характеристик различных специалистов на экономические характеристики производства программных продуктов. Таблица 6.7 Характеристики разработчиков программного продукта Значение характеристики Характеристика очень очень низкая номинальная высокая высокая низкая Квалификация 15% 35% 55% 75% 90% аналитиков М9 Квалификация программистов 15% 35% 55% 75% 90% М10 Тематический 2 мес. 6 мес. 1 год 3 года 6 лет опыт М12 Инструментальный опыт М13 2 мес. 6 мес. 1 год 3 года 6 лет Опыт работы с языками М14 2 мес. 6 мес. 1 год 3 года 6 лет Стабильность коллектива М11 48% 24% 12% 6% 3% 114 Таблица 6.8 Рейтинги характеристик разработчиков программного продукта Рейтинги характеристик Характеристика очень очень низкий номинальный высокий высокий низкий Квалификация 1,42 1,19 1,00 0,85 0,71 аналитиков М9 Квалификация программистов 1,34 1,15 1,00 0,88 0,76 М10 Тематический 1,22 1,10 1,00 0,88 0,81 опыт M12 Инструментальный опыт М13 1,19 1,09 1,00 0,91 0,85 Опыт работы с языками М14 1,20 1,09 1,00 0,91 0,84 Стабильность коллектива М11 1,29 1,12 1,00 0,90 0,81 Аналогичные оценки особенностей специалистов и их влияния на экономические характеристики базируются на отечественном опыте создания крупных программных продуктов. Эти характеристики сводятся в основном к длительности и опыту работы в определенной области и к экспертной оценке (%) квалификации специалистов. Выбор и использование их значений при прогнозировании экономических характеристик требует высокой квалификации экспертов — руководителей и детального знания особенностей среды производства реального продукта. Для обеспечения возможности их использования при прогнозировании трудоемкости и длительности разработки сложных комплексов программ в модели СОСОМО II представлены соответствующие относительные рейтинги категорий специалистов — таблица 6.7. При применении этих рейтингов следует учитывать, что некоторые из них взаимосвязаны, и целесообразно анализировать их корреляцию, возможность объединения или исключения при оценке экономических характеристик реальных проектов. 115 Среди множества характеристик коллектива разработчиков наибольшее влияние на трудоемкость могут оказывать тематическая и технологическая квалификация специалистов, которые в таблицах 6.4–6.5 представлены совокупностью из шести факторов. Совместно эти факторы могут изменять трудоемкость производства программных продуктов на 30–40%. Кроме того, в модели СОСОМО II выделен и обобщен на основе пяти характеристик коэффициент — комплексная коллективность участников проекта (см. таблицу 6.1), влияние которого может достигать пятикратного изменения трудоемкости. Разработчики должны иметь в своем составе квалифицированных, проблемно-ориентированных аналитиков и системных архитекторов — М9, способных переводить функциональные требования и общие пожелания заказчика в конкретные спецификации и технические требования к комплексу программ и его компонентам. Уровень квалификации аналитиков в СОСОМО II предлагается оценивать в процентах от высшей квалификации, что может снизить трудоемкость производства почти на 30% от номинальной, которой соответствует средний рейтинг 1,00 (так же как для всех факторов М (i)). Трудоемкость творческой части затрат на производство программных продуктов в основном определяет человеческий фактор — квалификация и организация коллектива специалистов. Следствием этого является большой разброс трудоемкости, производительности труда и длительности создания аналогичных программных продуктов разными коллективами. Коллективы с наилучшими экономическими характеристиками могут служить ориентирами достижимых в ближайшие годы значений экономических характеристик для соответствующих классов программных продуктов. Однако неуклонно повышается размер и сложность комплексов программ, что вызывает возрастание затрат творческого труда на единицу размера продукта. Затраты и труд при реализации крупного продукта в экономике производства традиционно принято распределять по двум категориям специалистов: разрабатывающим компоненты и комплекс в целом и обеспечивающим производственную технологию и качество программного продукта. Организационное разделение специалистов, осуществляющих производство программного 116 продукта (первая категория), и специалистов-технологов, контролирующих и управляющих его качеством в процессе производства (вторая категория), должно обеспечивать эффективное достижение заданных характеристик, а также независимый, достоверный контроль экономики и качества результатов производства. Специалисты первой категории непосредственно создают компоненты и комплекс программ в целом с заданными показателями качества (см. таблицу 6.7 — М10, М13, М14). В процессе производства их функции заключаются в тщательном соблюдении принятой в предприятии технологии и в формировании всех предписанных руководствами исходных и отчетных документов. При этом предполагается, что выбранная технология способна обеспечить необходимые значения конструктивных показателей качества компонентов и комплекса. Достижение заданных функциональных характеристик гарантируется тематической квалификацией М12 соответствующих специалистов и регулярным контролем этих характеристик в процессе производства. Система стандартизированного документирования частных работ должна обеспечить объективное отражение качества компонентов и процессов их создания на всех этапах ЖЦ комплекса программ. Разделение труда специалистов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалификации и областям деятельности: ●● спецификаторы и аналитики М9 подготавливают требования и описания функций соответствующих компонентов с уровнем детализации, достаточным для корректной разработки программистами текстов программных компонентов и их интерфейсов; ●● разработчики программных компонентов — программисты М10 создают компоненты, удовлетворяющие спецификациям требований, реализуют возможности компонентов продукта, отслеживают и исправляют ошибки, при производстве сложных программных компонентов, что требует детального знания высокоуровневых языков программирования, визуального программирования, сетевых технологий и проектирования баз данных — М13, М14; ●● системные интеграторы сложных проблемно-ориентированных комплексов программ работают над продуктом 117 в значительной степени отличными от программистов методами, на разных языках производства, используют различные средства автоматизации производства и имеют на выходе различные результаты: крупные функциональные компоненты и комплексы программ; ●● тестировщики обеспечивают проверку функциональных спецификаций требований, пользовательских интерфейсов, разрабатывают стратегию, планы и выполняют тестирование на соответствие требованиям для выявления и устранения дефектов и ошибок каждого компонента и всего комплекса программ; ●● управляющие сопровождением и конфигурацией отвечают за снижение затрат на модификацию и сопровождение программного продукта, обеспечение максимальной эффективности взаимодействия компонентов и производство версий программного продукта, принимают участие в обсуждениях интерфейсов и архитектуры программного продукта; ●● документаторы объектов и процессов жизненного цикла комплекса программ обеспечивают подготовку и издание сводных технологических и эксплуатационных документов на программный продукт в соответствии с требованиями стандартов. Однако в модели СОСОМО II в составе «команды» специалистов для производства сложного программного продукта не учитываются такие важнейшие квалификации как: ●● тестировщики компонентов и комплексов программ; ●● системные интеграторы компонентов сложных комплексов программ; ●● управляющие сопровождением и конфигурацией комплексов программ. При оценке трудоемкости производства комплекса программ влияние этих факторов можно учитывать, увеличивая, например, характеристики (изменяя рейтинги): программистов (с тестировщиками), аналитиков (с интеграторами), инструментальный опыт (с сопровождением), а также стабильность коллектива. Успех и качество при разработке сложных программных продуктов все больше зависят от слаженности работы и профессионализма коллектива специалистов на всех этапах и уровнях 118 производства продуктов — от стабильности коллектива М11 (таблицы 6.7 и 6.8). Особенно важна не столько индивидуальная характеристика каждого специалиста, а прежде всего интегральный показатель квалификации «команды», реализующей некоторую, достаточно крупную функциональную задачу или весь проект комплекса программ. Тематическая квалификация и опыт — М12 специалистов в конкретной прикладной области, для которой разрабатывается программный продукт, приближенно может оцениваться продолжительностью работы по данной тематике. При низкой тематической квалификации допускаются наиболее грубые системные ошибки, требующие больших затрат для доработки программ. Имеются примеры, когда из-за таких ошибок, допущенных на этапе системного анализа, приходилось в процессе производства изменять до 70–90% программ. Целесообразность использования в качестве показателя квалификации значений длительности работы в определенной прикладной области или специализации подтверждается достаточно высокой ее корреляцией с коэффициентом изменения трудоемкости. При этом квалификация системных аналитиков и непосредственных разработчиков программ в конкретной прикладной области особенно важна не столько как индивидуальная характеристика каждого специалиста, а прежде всего как интегральный показатель «команды», реализующей достаточно крупную функциональную задачу. Приводимые в разных работах оценки показывают, что при изменении опыта работы в данной области от 1 до 10 лет производительность труда может повышаться в 1,5–2 раза, что отражается величиной рейтингов М12. Технологическая квалификация — М13 программистов в использовании инструментальной системы автоматизации производства программных компонентов отражает опыт применения методов, средств и всего технологического процесса при создании данного типа программных модулей и компонентов. Этот опыт можно характеризовать длительностью работы с конкретной инструментальной системой автоматизации или ее версиями, базирующимися на единых технологических концепциях, опыте и длительности работы с регламентированными технологиями, инструментальными комплексами автоматизации разработки, 119 языками проектирования, программирования и тестирования программ. Особое значение имеет коллективный опыт организации и выполнения сложных проектов на базе современных автоматизированных технологий и инструментальных средств программной инженерии. Опыт применения конкретного комплекса автоматизации, языков проектирования и программирования может являться существенным фактором при выборе технологии для создания новых компонентов и обеспечении качества программных продуктов (см. рейтинги в таблице 6.8). Квалификация специалистов существенно зависит от стабильности состава и психологического климата в коллективе, их способности к сотрудничеству и дружной совместной работе над единым проектом (см. F4 в таблице 6.1 и М11 в таблицах 6.7 и 6.8). В данном факторе годы работы с конкретной технологической системой отражают не только опыт работы с инструментами, но и слаженность коллектива при проведении больших комплексных работ. Нарушение технологии, задержка при разработке отдельных модулей или групп программ может приводить к большим дополнительным затратам и значительной задержке производства продукта в целом. Это вызывает простои групп специалистов, соответствующее увеличение совокупных затрат и снижение производительности труда. Однако чаще всего коллективы специалистов имеют уже некоторый технологический опыт, и дальнейшее повышение их квалификации может дать относительно немного 10–20% производительности. Небольшое влияние этого фактора обусловлено также нивелирующим влиянием трудозатрат вспомогательного и руководящего персонала, которые практически не зависят от технологической квалификации и инструментального опыта. Программистская квалификация специалистов — М10, М14 и опыт работы с языками программирования из приведенных факторов квалификации относительно слабо отражается на производительности труда при сложном программном проекте. В данном факторе учитывается освоенность не только языка непосредственного программирования, но и всех компонентов средств, используемых при создании программ (спецификаций, диалога, тестирования компонентов и их комплексирования). После двух– трех лет работы проявляются индивидуальные особенности конкретных специалистов, их творческие способности, тщательность 120 в работе, рациональность использования средств автоматизации. При производстве сложных комплексов после первых лет работы возрастание программистской квалификации может повысить общую производительность труда на 5–10%. Совокупность перечисленных видов квалификации можно предcтавить как обобщенный человеческий фактор «команды» при экономическом прогнозировании и в процессе производства сложных программных продуктов. На эту величину влияет еще множество трудно учитываемых условий. Сложность психологических экспериментов с регистрацией всех основных условий производства приводит к большому разбросу результатов. В некоторых случаях этот фактор изменял совокупные затраты даже в 2–5 раз. Вследствие этого некоторые специалисты в основном на опыте разработки относительно простых небольших программ утверждают, что при производстве комплексов программ только человеческий фактор программистов определяет длительность и трудоемкость разработки. Отсюда делается вывод о принципиальной невозможности планирования и прогнозирования процессов и экономики производства программных продуктов. В действительности при крупных разработках человеческий фактор в коллективах значительно усредняется. Тем не менее достаточно часто по этой причине возможен разброс производительности труда в 2–3 раза при производстве крупных практически аналогичных продуктов. Специалисты второй категории — технологи, создающие, обслуживающие и сопровождающие технологический инструментарий, который применяется специалистами первой категории, обеспечивают применение системы качества предприятия, контролируют и инспектируют процессы производства для минимизации затрат. Основные задачи второй категории специалистов должны быть сосредоточены на контроле экономических характеристик процессов и результатов выполнения работ и на принятии организационных и технологических мер для достижения необходимого качества, обеспечивающего выполнение всех требований технического задания на программный продукт с учетом производственной экономики. Технологи должны выбирать, приобретать и осваивать экономически наиболее эффективный инструментарий для 121 проектов, реализуемых конкретным предприятием с учетом особенностей создаваемых комплексов программ требуемого качества и рентабельности технологических средств. Они должны разрабатывать регламентированный технологический процесс и систему качества, поддерживающие весь ЖЦ комплексов программ и обучать разработчиков квалифицированному применению соответствующих инструментальных средств и технологий. Специалисты, управляющие обеспечением качества программных продуктов, должны владеть стандартами и методиками предприятия, поддерживающими регистрацию, контроль, документирование и воздействия на показатели качества и экономические характеристики на всех этапах производства комплекса программ. Они должны обеспечивать эксплуатацию системы качества проекта, выявление всех отклонений от заданных показателей качества продуктов и процессов, а также от предписанной технологии. В результате должны приниматься меры либо по устранению отклонений, либо по корректировке требований, если устранение отклонений требует больших ресурсов. Для планирования и управления жизненным циклом концептуально целостных, крупных программных продуктов и обеспечения их качества в пределах допустимых затрат необходимы организационные действия менеджеров, направленные на подбор и обучение коллектива специалистов разных категорий и специализаций. Перечисленные выше специализации и квалификации персонала, участвующего в крупных проектах, требуют соответствующей их подготовки, отбора и обучения, которые являются самостоятельной, важной проблемой в экономике производства программных продуктов. Обучение представляет собой сложный процесс, требует организации и сопровождения обучаемого персонала. Должны быть разработаны и документированы планы, требования и цели обучения, а также разработаны материалы, используемые для обучения. Может быть необходимым включение в подготовку, ознакомление со специфической (проблемно-ориентированной) областью, в которой будет работать данный программный продукт, и повышение квалификации в этой области. По мере повышения квалификации коллектива и автоматизации творческой части труда следует ожидать асимптотического приближения к потенциальным значениям интегральных 122 экономических характеристик производства новых программных продуктов. Эти предельные значения определяются возможностями человека по интенсивности принятия творческих решений. При экономическом прогнозировании проектов сложных комплексов программ рассчитать такие характеристики вряд ли возможно, и реальным путем их оценки являются изучение и экстраполяция экспериментальных данных реальных разработок программных продуктов с учетом возрастания квалификации специалистов и уровня автоматизации. Эти факторы способствуют эволюционному, относительно медленному, приближению к предельным экномическим характеристикам производства новых крупных продуктов. Предельные значения производительности труда, по-видимому, в два–три раза выше, чем современные значения для наилучших коллективов при среднем уровне автоматизации разработки и квалификации специалистов. Вряд ли можно ожидать в ближайшие годы повышения производительности труда на порядок для полностью новых, сложных программных продуктов. Еще более консервативна длительность разработки. Принципиальным путем улучшения экономических характеристик при производстве сложных программных продуктов является сокращение творчества на тех этапах, где возможны типовые стандартные решения и заготовки, не требующие при их многократном применении высококвалифицированного творческого труда. Представленные в данном разделе факторы и экономические оценки являются усредненными и относятся к большим коллективам специалистов при производстве сложных программных продуктов. При этом целесообразно учитывать распределение затрат по этапам производства и необходимую численность занятых в коллективе специалистов —% от средней (см. таблицу 6.1 для новых сложных комплексов программ реального времени). На этапах предварительного и детального проектирования в коллективе может быть занято около половины специалистов (соответствующих категорий от среднего числа). В программировании и тестировании компонентов число участвующих специалистов превышает средние значения приблизительно в полтора раза, а затем при интеграции компонентов, испытаниях и документировании комплексов программ соответствует среднему уровню. Эти оценки учитывают все категории специалистов, включая 123 руководителей и вспомогательный персонал, которые не прикасаются к программам. Для оценки и учета сокращения трудоемкости и длительности производства за счет повторного использования готовых компонентов в модели СОСОМО II рекомендуются соответствующие дополнительные выражения и процедуры. При прогнозировании экономических характеристик предлагается в качестве дополнительных данных учитывать долю (%) затрат на программный продукт, которая может быть сокращена за счет применения модифицируемых и/или полностью готовых ПИК. В модели СОСОМО II рекомендуется разработка специальным образом калиброванной версии коэффициентов в формулах (6.1) и (6.2), которая должна отражать применяемые технологические процессы, особенности и возможности производства программного продукта. При калибровке модели СОСОМО II предлагаются следующие последовательные процедуры для конкретного проекта: ●● устанавливаются значения и сумма рейтингов масштабных факторов F (j), при которой производится первичное оценивание экономических характеристик; ●● выбирается набор, значения и оценивается произведение рейтингов факторов M (i), оказывающих наибольшее влияние на прогнозируемую трудоемкость производства программного продукта, которые сравниваются с предыдущей оценкой; ●● для каждого набора рейтингов выбранных факторов производится расчет и анализ трудоемкости (6.1) и длительности (6.2) для конкретного проекта комплекса программ. Кроме того, модель СОСОМО II изначально представляет трудозатраты по сумме всех этапов производства (от этапа планирования концепции до этапа поставки программного продукта). Проблемы сопровождения, переноса и повторного использования компонентов трудно описывать в рамках одной и той же модели. Эти действия могут быть также оценены с помощью дополнений к базовой модели. В модели не учитываются накладные расходы; расходы на командировки и другие побочные расходы при оценках стоимости. При прогнозировании экономических характеристик производства программных продуктов для систем реального времени необходимо учитывать затраты на создание моделей внешней 124 среды, которые могут по величине быть сопоставимыми с затратами на основной программный продукт. Системная интеграция и инструментальная поддержка динамического тестирования и испытаний программного продукта реального времени на соответствие требованиям составляют отдельную специфическую задачу, которая не входила в состав целей СОСОМО II и не учитывалась. Приведенные недостатки и трудности применения модели СОСОМО II для прогнозирования экономических характеристик производства сложных программных продуктов в значительной степени могут быть скомпенсированы при приобретении квалификации и накоплении опыта специалистами экономических оценок в конкретной прикладной области. Рекомендуемые формулы и таблицы рейтингов целесообразно использовать как базовые для развития инструментария прогнозирования, и по мере накопления опыта на конкретном предприятии уточнять коэффициенты в выражениях (6.1) и (6.2), а также создавать уточненную базу исходных рейтингов и выполненных прогнозов конкретных продуктов. Необходимость выполнения при производстве определенной совокупности этапов и операций в заданной технологической последовательности остается более или менее постоянной при различных воздействиях на процессы разработки. Исключением является применение повторно используемых компонентов (ПИК), при котором значительно сокращаются этапы программирования и автономного тестрования модулей и компонентов программ, а также длительность других этапов. Поэтому зависимость сроков T от доли ПИК оказывается нелинейной. Оценка требуемого среднего числа специалистов для конкретного комплекса программ предварительно может быть рассчитана путем деления величины трудоемкости производства (6.1) на длительность его производства (6.2): N = C/T. Средняя производительность труда коллектива специалистов при разработке нового сложного комплекса программ Р = П/C, конечно, различается для различных классов, размеров и других параметров комплексов программ, однако диапазон этих различий не столь велик как изменения размера, требований к качеству и других базовых факторов. 125 ГЛАВА 7 Влияние технологической среды производства при прогнозировании экономических характеристик Инструментальные системы — М15, поддерживающие производство, могут быть описаны качественными характеристиками и рейтингами, изменяющими трудоемкость в пределах приблизительно 20% от средней– номинальной. Уровень технологии и комплекса инструментальных средств особенно сильно влияет на экономику крупных программных продуктов. Поэтому затраты на их реализацию и применение целесообразно учитывать конкретно с использованием функций и характеристик проекта. Рейтинги инструментальной поддержки коррелированы с уровнями зрелости технологий производства программ СММI — F5 и комментированы в главе 6. Для приближенной оценки влияния на трудоемкость инструментальных характеристик производства в модели СОСОМО II выделен показатель и соответствующий набор рейтингов (таблицы 7.1. и 7.2): Таблица 7.1 Характеристики процессов производства программных продуктов Характеристики Инструментальная поддержка M15 Содержание характеристик номиочень низкое высокое нальное высокое Простые Базовые КомОтдельные интегри- интегри- плексные простые рованные рованные интегриинструинструинструрованные менты менты менты системы очень низкое Затраты на технологию и программные средства автоматизации производства обычно являются весьма весомыми при использовании высокоэффективных автоматизированных технологий и инструментов. При экономическом обосновании 126 проекта следует учитывать, что размер и сложность создаваемого продукта значительно влияют на выбор инструментальных средств и уровня автоматизации технологии, а также на долю этих затрат в общих затратах на производство. Встречаются ситуации, при которых затраты на технологию достигают 50% общих затрат на производство. Такие затраты могут быть оправданы повышением производительности труда, сокращением сроков разработки и последующим снижением затрат на множество версий программного продукта. Однако чаще эта группа затрат при создании первой версии сложного программного продукта находится в пределах 20–30% от суммарных затрат. В первом приближении степень автоматизации производства комплексов программ отражается размером программных средств, используемых в технологических системах. Этот показатель соответствует сложности систем автоматизации производства программ и пропорционален затратам на их приобретение или создание и эксплуатацию. Таблица 7.2 Рейтинги процессов производства программных продуктов Характеристики Инструментальная поддержка М15 Рейтинги характеристик очень низкий низкий номиочень высокий нальный высокий 1,17 1,09 1,00 0,90 0,78 1,43 1,14 1,00 1,00 1,00 Стремление уменьшить технологические затраты в период производства без учета последующего использования программного продукта, его компонентов и всего жизненного цикла может оказаться малополезным, а в некоторых случаях привести к значительному увеличению совокупных затрат. При применении сложных программных продуктов эти затраты могут исчисляться сотнями человеко-лет, что определяет особую актуальность их снижения. Поэтому необходим системный анализ распределения 127 и использования технологических ресурсов на разработку комплексов программ с учетом всего их жизненного цикла, включая сопровождение и возможный перенос на другие платформы. В ряде случаев технология и средства автоматизации создаются для производства многих программных продуктов. При этом затраты на их создание входят в стоимость каждой версии продукта только некоторой долей. Величина этой доли зависит от широты применения данного средства, т. е. от общего числа экземпляров технологической системы, использованных за цикл жизни технологии или за некоторый нормативный срок. При производстве каждого продукта эта доля увеличивается на величину, обусловленную затратами на внедрение и освоение технологии и на величину, связанную с ее эксплуатацией. Таким образом, затраты на технологическое обеспечение производства программного продукта можно представить следующими составляющими: ●● долей суммарных затрат на приобретение или создание технологии и системы автоматизации производства программ; ●● однократными затратами на внедрение и освоение технологии и средств автоматизации, а также на подготовку версии технологической системы, адаптированной к конкретным условиям применения для разработки данного программного продукта; ●● затратами на эксплуатацию средств автоматизации в течение всего календарного времени производства или ЖЦ данного программного продукта; ●● на создание технологии и инструментальных средств для испытаний и оценивания достигнутых значений характеристик качества программного продукта. Стремление использовать апробированные технологии и инструментальные системы приводит к тому, что в этих случаях первую составляющую иногда можно игнорировать. Некоторые средства автоматизации используются в готовой версии и не адаптируются к конкретным условиям применения, тогда доминирующей становится последняя составляющая. Минимизации этих затрат способствует массовое применение типовых технологий с высоким уровнем автоматизации. 128 Уровень автоматизации, качество технологии и инструментальных средств, используемых для поддержки всего жизненного цикла комплекса программ, обычно сильно коррелирован с достигаемым качеством производства комплекса, а также с качеством средств автоматизации для оценивания этого качества. Оценивание качества технологической базы производства позволяет прогнозировать возможное качество программного продукта и ориентировать заказчика и пользователей при выборе разработчика и поставщика для определенного проекта с требуемыми характеристиками качества. Очевидно, что низкий уровень технологии и средств производства программ не может обеспечить их высокое качество и достоверное его оценивание. Поэтому определение уровня зрелости технологической поддержки процессов жизненного цикла, организационного и инструментального обеспечения качества, непосредственно связано с выбором и оцениванием реальных или возможных характеристик качества конкретного программного продукта. При производстве комплексов программ для систем реального времени большие затраты могут потребоваться для обеспечения тестирования, отладки и испытаний продукта, которые отдельно не учитываются моделью СОСОМО II. Приведенные в главе 6 (таблица 6.1) распределения трудоемкости и длительности по этапам работ получены экспериментально, когда относительно мало внимания уделялось организации проектирования, автоматизации начальных этапов разработки, применению спецификации требований и использованию отладки в реальном времени. Поэтому основные усилия сосредоточивались на процессах программирования и автономной отладки компонентов. На этих этапах выявлялась основная масса ошибок, хотя при использовании программного продукта и сопровождении также обнаруживалось некоторое их количество. Впоследствии центр тяжести процессов производства сложных комплексов программ сдвинулся к начальным этапам, и внимание было акцентировано на предотвращение ошибок, прежде всего путем тщательного системного проектирования из готовых программных компонентов, а также на комплексной отладке и испытаниях в реальном времени. Вследствие этого распределения во времени анализируемых экономических характеристик деформировались, их размеры сдвинулись в сторону начальных и конечных этапов. 129 Этапы комплексной отладки, испытаний и модификации комплексов программ имеют много общего, в основе которого лежит широкое применение их тестирования для обнаружения ошибок и удостоверения функциональной корректности программного продукта. Разработка детерминированных тестов при отладке модулей и некоторых групп программ в большинстве случаев производится вручную. Однако их доля может составлять заметную часть общих затрат на тестирование компонентов. Достаточно автономными и локализуемыми обычно являются затраты на стохастические тесты и динамические тесты в реальном времени, используемые при комплексной отладке и испытаниях продукта. Для этого необходимы методы и средства автоматизации, обеспечивающие генерацию динамических тестов для проверки функциональных групп программ и программного продукта в целом в реальном времени. Значительная доля от совокупных затрат на производство программного продукта реального времени может приходиться на создание и эксплуатацию средств обеспечения динамического тестировании и испытаний, которая может быть соизмеримой и даже превышать затраты на непосредственную разработку программного продукта. Сложность программного продукта зачастую адекватна сложности внешней среды и/или системы, являющейся источником обрабатываемой информации и потребителем обработанных данных, получаемых при функционировании программного продукта. Только для очень небольших программ можно вручную разработать достаточно полные наборы тестов для отладки, отражающие реальные условия их эксплуатации. Для средних и больших комплексов программ необходим принципиально иной подход, заключающийся в создании и применении автоматизированных, динамических моделей внешней среды, в качестве источников тестовых данных в реальном времени, при тестировании программного продукта на соответствие требованиям заказчика. Затраты на них необходимо учитывать при экономическом прогнозировании и обосновании таких проектов. Имитировать динамические тесты особенно сложно для комплексов программ, функционирующих в реальном времени, когда данные, отражающие внешнюю среду, должны поступать синхронно также в реальном времени. Анализ эффективности 130 подобной имитации динамической внешней среды при производстве целесообразно разделить на две части: оценка факторов, определяющих эффективность программных средств динамической имитации тестов, и оценка экономического выигрыша при моделировании внешней среды на компьютере по сравнению с натурными экспериментами. Программная имитация динамической внешней среды на компьютере позволяет: ●● расширять диапазоны характеристик имитируемых объектов за пределы реально существующих или доступных источников данных и генерировать динамические потоки информации, отражающие перспективные характеристики создаваемых систем; ●● создавать тестовые данные, соответствующие критическим или опасным ситуациям функционирования объектов внешней среды, которые невозможно или рискованно реализовать при натурных экспериментах; ●● обеспечивать высокую повторяемость имитируемых данных при заданных условиях их генерации и возможность прекращения или приостановки реального времени имитации на любых фазах моделирования внешней среды; ●● проводить длительное непрерывное генерирование имитируемых данных для определения безопасности и надежности функционирования программного продукта в широком диапазоне условий, что зачастую невозможно при использовании реальных объектов внешней среды. При ограничении сроков до уровня 75% от номинальных, сокращению трудоемкости может сопутствовать значительное снижение качества и увеличение рисков реализации проекта. Предполагается, что руководство проекта заранее знает о требуемом уменьшении или возможном увеличении сроков производства и в состоянии вести планирование и управление проектом наиболее выгодным способом с точки зрения минимизации трудоемкости или стоимости. Для уменьшения сроков разработки есть ряд путей, с помощью которых руководство может добиваться некоторого ускорения разработки за счет увеличения трудоемкости и стоимости продукта: ●● обеспечить детальное структурирование комплекса программ на модули и спецификации интерфейсов для 131 обеспечения максимального параллелизма работы специалистов — программистов и тестировщиков; ●● приобрести технологические, инструментальные средства для более быстрого кодирования, контроля, тестирования компонентов, и обучить разработчиков их использованию; ●● обеспечить дополнительную подготовку программистов и тестировщиков к работе в тематической области функций программного продукта; ●● привлечь дополнительный вспомогательный персонал; ●● отложить на время некоторое не существенное документирование программного продукта. Тем не менее есть предел сокращению сроков производства от номинальных с помощью увеличения числа специалистов и приобретения дополнительного оборудования. При максимально возможном сокращении сроков разработки до 75% от оптимальных затраты возрастают на 30–40%. Влияние аппаратной вычислительной среды при прогнозировании экономических характеристик производства программных продуктов В некоторых комплексах программ реального времени (СРВ) на увеличение трудоемкости разработки (до 50%) может оказать ограничение вычислительных ресурсов оперативной памяти — М7 и производительности объектного компьютера– М6, на котором должен функционировать программный продукт (таблицы 7.3 и 7.4).При таких ограничениях ресурсов резко усложняется проектирование и производство продукта и приходится адаптировать размеры алгоритмов и программ с целью не нарушить ограничения вычислительных ресурсов. Это привело к необходимости разрабатывать методы эффективного использования программами аппаратных ресурсов компьютера. На практике наибольшие технические трудности обычно вызывают ограничения производительности М6 реализующего компьютера, для преодоления которых приходится не столько экономить программные ресурсы и сокращать размеры программного 132 продукта, сколько искать пути увеличения производительности компьютера ЭВМ и эффективности их использования. Таблица 7.3 Ограничения вычислительной среды реализации программных продуктов Характеристики низкое Содержание характеристик номиочень высокое нальное высокое сверх высокое Ограничения времени исполнения М6 < 50% 70% 85% 95% Ограничения по оперативной памяти М7 < 50% 70% 85% 95% Изменчивость Каждые Каждые среды произ- 12 ме- 6–0,5 меводства М8 сяцев сяца Каждые 2–0,25 Месяца Каждые 0,5–0,1 месяца Таблица 7.4 Рейтинги ограничений вычислительной среды реализации программных продуктов Характеристики Ограничения времени исполнения М6 Ограничения по оперативной памяти М7 Изменчивость среды производства M8 Рейтинги характеристик номиочень низкий высокий нальный высокий 0,87 сверх высокий 1,00 1,11 1,29 1,63 1,00 1,05 1,17 1,46 1,00 1,15 1,30 При этом существенным ограничивающим фактором являются реальное время, в течение которого компьютер может быть предоставлен для решения данной задачи, или то время, в пределах 133 которого целесообразно получить результаты (время отклика) для их практического использования. Таким образом, уже на стадии формулирования требований к программному продукту в некоторых проектах (например, бортовые системы) следует сопоставлять доступную производительность компьютера с необходимыми затратами времени для решения требуемого набора задач или с допустимой длительностью ожидания результатов (временем отклика). Поэтому весьма актуальной для систем реального времени является проблема эффективного распределения ограниченной производительности компьютера для решения комплекса функциональных задач и поиск методов рациональной организации вычислительного процесса при применении программного продукта. Быстрый рост количества решаемых задач, их сложности и требуемой производительности вычислительных средств стимулировал поиск различных путей удовлетворения потребностей программных продуктов в ресурсах для решения таких задач. Мировая практика развития вычислительной техники показала, что потребность в вычислительных ресурсах для решения некоторых задач растет быстрее, чем доступные реальные характеристики компьютеров. Технические трудности улучшения характеристик процессоров и памяти непосредственно за счет увеличения быстродействия элементной базы вычислительных систем привели к созданию многомашинных и многопроцессорных комплексов. В таких компьютерах проблема эффективного распределения и использования ресурсов еще больше усложняется, так как необходимо оперативно распределять производительность (в принципе различных) вычислительных процессоров для решения всей заданной совокупности задач. Так как задачи могут быть взаимосвязаны последовательностью решения или обрабатываемой информацией, возникала необходимость эффективного использования памяти и производительности вычислительных систем при параллельном решении совокупности взаимодействующих задач. В последние годы стали возможными ситуации, когда в современных компьютерах реального времени может быть создан такой избыток производительности и памяти, что нет необходимости в детальном выборе и применении методов рационального 134 и экономного использования вычислительных ресурсов при экономическом прогнозировании и обосновании таких проектов. Однако применение более дешевых и простых компьютеров может позволить те же задачи решать при меньших аппаратурных затратах, особенно это актуально для мобильных компьютеров реального времени (например, бортовых систем). При ограничениях ресурсов вследствие требований минимизации весов и габаритов специализированных, реализующих компьютеров в авиационных, ракетных и космических системах их экономное использование остается актуальным и следует учитывать при проектировании и производстве соответствующих программных продуктов. Влияние ограничения объема памяти реализующего компьютера ВМ — М7 в модели СОСОМО II определяется долей от фактического размера доступной оперативной памяти, которая может использоваться для размещения программного продукта и данных при решении совокупности задач с приемлемой для практики точностью и надежностью. Ограничения этого фактора реально меньше влияют на экономические характеристики производства программных продуктов, так как технически легче преодолеваются при конструировании компьютера. Изменчивость среды разработки — М8 (технологических средств) может быть вызвана изменением и расширением функций программного продукта, модернизациями для устранения ошибок, частота которых вызывает смену версий программного продукта и соответствующие дополнительные затраты на инструментальную среду производства. Номинальной в модели СОСОМО II принята стабильность вычислительной среды, когда изменения происходят в среднем каждые 3 месяца. При более частых изменениях среды (каждую неделю) трудоемкость может возрастать на 30% (см. табл. 7.3). При производстве крупных комплексов программ и ограниченных ресурсах реализующих компьютеров реального времени кроме этих машин могут быть необходимы дополнительные технологические и моделирующие внешнюю среду компьютеры. В полном жизненном цикле комплексов программ для систем реального времени в этом случае следует прогнозировать затраты на компьютеры для реализации программного 135 продукта, автоматизации его разработки — на технологического компьютера и для имитации внешней среды — на моделирующего компьютера. Соотношение между этими затратами зависит от уровня автоматизации производства комплекса программ. При низких уровнях автоматизации все функции разработки решаются на реализующем компьютере. По мере возрастания автоматизации повышается доля использования технологических компьютеров, а затем и моделирующих, имитирующих внешнюю среду. При создании особо сложных программных продуктов реального времени с применением высокоавтоматизированных технологий (уровни СММI — 4–5) суммарные затраты на применение реализующего, технологического и моделирующего могут становиться соизмеримыми. 136 Глава 8 Учебные примеры прогнозирования экономических характеристик по модели СОСОМО II Ниже представлены и анализируются учебные варианты прогнозов экономических характеристик программных продуктов, рассчитанные по формулам (6.1) и (6.2). Их можно рассчитать вручную или с использованием программного пакета ПЛАПС-2, созданного Н. Липкиным. Пакет разработан на базе тех же формул модели СОСОМО II и предназначен для удобного массового прогнозирования экономических характеристик производства проектов сложных программных продуктов. При использовании пакета возможно варьирование различных факторов и характеристик проекта, а результаты отражаются в окне «Экономические характеристики». В них содержатся значения прогнозов трудоемкости и длительности реализации проекта, а также производительности труда и оценка числа специалистов, необходимых для производства прогнозируемого комплекса программ. Параметры модели логически сгруппированы и расположены на различных вкладках модели. Представленные в таблице 8.1 примеры вариантов могут использоваться в учебном процессе как иллюстрации и ориентиры при прогнозах необходимых затрат на крупные программные продукты. Модель СОСОМО II позволяет определять и уточнять некоторые исходные данные для экономического прогнозирования производства конкретного программного продукта. При этом обычно значения ряда факторов являются фиксированными в силу объективных условий производства на конкретном предприятии. В отдельных случаях для выбора наилучшей стратегии реализации проекта может быть полезным варьирование нескольких вариантов характеристик факторов перед детальным проектированием производства конкретного комплекса программ. В процессе обучения рекомендуется задавать различные варианты исходных данных. В крайнем случае на основе оценок ограниченных ресурсов 137 может быть сделано достаточно достоверное обоснование прекращения разработки предполагавшегося программного продукта. Таблица 8.1 Варианты прогнозирования экономических характеристик Характеристики исходных данных Варианты 1 2 3 4 5 Новизна проекта F1 Новый Новый Средняя Средняя Средняя Соответствие требованиям F2 Полное Полное Среднее Среднее Высокое Коллективность производства F4 Среднее Высокая Средняя Среднее Высокая Зрелость производства F5 Уровень 2 Уровень 4 Уровень 3 Уровень 3 Уровень 3 Номинальные Надежность, документы, огр. ресурс. Надежность, документы, огр. ресурс. Надежность, документы, огр. ресурс. Нет Нет 50% 80% Факторы производства М Номинальные Повторное исНет пользование Ниже представлены основные экономические характеристики программных продуктов размером от 50 до 1000 слов KLOC (миллион строк программ). Модель СОСОМО II и перечень факторов, представленных в таблице 8.1 — четыре масштабных фактора (кроме управления рисками) и еще семнадцать факторов — М из этой таблицы. Для каждого варианта в зависимости от размеров прогнозируемых комплексов программ представлены графики трудоемкости — рис. 8.1, длительности производства — рис. 8.2 и число необходимых специалистов — рис. 8.3. Первые два варианта иллюстрируют влияние на прогнозируемые трудоемкость, 138 длительность и количество специалистов, уровня зрелости СММI (2 или 4) и организации коллектива (свободная или жестко планируемая), повышаются по уровню квалификации, слаженности коллектива специалистов и их оснащенности технологией и инструментальными средствами. Варианты 3–5 отражают различную долю (%) повторного использования компонентов в высоконадежных программных продуктах реального времени при ограниченных ресурсах компьютеров (бортовые системы). Вариант 1 — отличается тем, что должен быть создан совершенно новый программный продукт средней сложности и надежности, однако коллектив имеет невысокую квалификацию и слаженность, относительно слабо оснащен технологией и инструментарием (2 уровень СММI). В результате экономические характеристики близки к наиболее низким по производительности труда, требуется наибольшая трудоемкость и число специалистов. Вариант 2 — предполагается, что должен создаваться почти такой же, как в предыдущем варианте, совершенно новый программный продукт высокой сложности и надежности в соответствии с жесткими требованиями заказчика. Разработка продукта предстоит стабильному коллективу специалистов высокой квалификации и слаженности, имеющему значительный опыт создания подобных проектов. Процесс производства поддержан современным инструментарием и технологией на уровне 4 СММI. Остальные факторы имеют, в основном, номинальные значения. Этот вариант может считаться наилучшим по трудоемкости и производительности труда и требует меньшего числа специалистов по сравнению с предыдущим вариантом. При этом трудоемкость сокращается в полтора раза, а длительность производства программного продукта только на 15%. Вариант 3 — должен быть создан в соответствии с требованиями заказчика на не совсем новый программный продукт реального времени средней сложности и надежности, компоненты которого допускают повторное использование в аналогичных проектах и их версиях. Производство продукта предстоит коллективу специалистов средней квалификации и слаженности, имеющему опыт создания подобных проектов. Процесс производства поддержан современным инструментарием и технологией на уровне 3 СММI. При надежном функционировании программного продукта в реальном времени должны эффективно использоваться 139 вычислительные ресурсы реализующего компьютера на уровне 90% по оперативной памяти и производительности. Вариант 4 — в основном подобен по характеристикам факторов варианту 3, но базируется на применении 50% готовых программных компонентов, что отразилось на значительном сокращении экономических характеристик. В наибольшей степени это отразилось на снижении трудоемкости и числа специалистов (почти в два раза), и относительно меньше (только на 10%) сократились длительность производства и производительность труда. Вариант 5 — отличается от предыдущего более высоким уровнем повторного использования компонентов — 80%. Это отразилось на значительном снижении трудоемкости и необходимого числа специалистов (на 70%), а также на повышении производительности труда, при относительно небольшом сокращении длительности производства (только на 30%). Характерными особенностями представленных графиков 1 и 3 является практически линейная зависимость трудоемкости производства и числа необходимых специалистов от предполагаемого размера программного продукта. Однако длительность производства комплексов программ (рис.8. 2) отражается нелинейными кривыми с постепенным ограничением их величины. Представленные прогнозы могут служить ориентирами при анализе реальных условий производства программных продуктов. Уменьшение затрат труда в последние годы объективно обусловлено усовершенствованием технологий и инструментария при производстве программных продуктов. Средняя производительность труда для новых относительно небольших комплексов программ при высоком качестве технологий повышается более чем в два раза, а затем несколько сокращается по мере учета возрастания их размера. При обобщении рассчитанных экономических характеристик на практике некоторые значения могут не удовлетворить специалистов, ведущих прогнозирование. Поэтому в методиках прогнозирования должна допускаться возможность пересчета получаемых прогнозных значений на основе уточненных значений некоторых факторов. Например, на базе учтенных при прогнозе факторов производительность труда может оказаться отличающейся от реальной, характерной для данного предприятия, определявшейся по реализованным предшествующим разработкам. Для того чтобы учесть это 140 различие, должна быть предусмотрена возможность ввода реальной производительности специалистов данного предприятия и пересчета всех остальных экономических характеристик. При этом индивидуальная производительность труда отдельных специалистов коллектива может существенно отличаться от «усредненной», заложенной в модель по статистике предыдущих разработок различного размера. Кроме того, на практике могут существовать ограничения реальной численности коллектива, выделяемого для данного проекта комплекса программ, или допустимой (директивной) длительности производства. Для учета таких ограничений должна быть предусмотрена возможность пересчета экономических характеристик при дополнительно откорректированных значениях некоторых факторов. Достоверность рассчитанных значений основных экономических характеристик целесообразно проверять путем сопоставления с показателями аналогов, созданных на том же предприятии, наиболее близких к прогнозируемому продукту. Полная стоимость и длительность разработки обычно подлежат согласованию с заказчиком. В процессе согласования уточняются сценарии проектирования и производства, и возможно изменение не только влияния некоторых факторов, но и требований технического задания на объект и характеристики продукта. Это особенно необходимо, если превышаются допустимые заказчиком значения стоимости или длительности разработки. Согласованные с заказчиком прогнозируемые экономические характеристики позволяют фиксировать базовый сценарий и план производства продукта, проводить предварительные расчеты распределений трудоемкости и длительности по этапам производства и по специалистам. По этим данным может проводиться детальное календарное планирование и контролирование работ всего проекта. Для расчета распределения трудоемкости, длительности и числа специалистов по этапам работ желательно использовать аналогичные характеристики проектов подобного прототипа. Представленные выражения, таблицы факторов и рейтингов целесообразно использовать как ориентиры и методическую базу для прогнозирования экономических характеристик производства сложных программных продуктов, которые необходимо уточнять и развивать на основе анализа реальных характеристик и опыта выполненных проектов программных продуктов. 141 Обобщенные графики основных экономических характеристик производства программных продуктов по параметрам, представленным в таблице 8.1 Подобные графики могут служить ориентирами при подготовке концепции, первичного замысла и оценке необходимых ресурсов крупного заказного проекта. Рис. 8.1. Зависимость трудоемкости разработки от размера программного продукта Рис. 8.2. Зависимость длительности разработки от размера программного продукта 142 Рис. 8.3. Зависимость количества специалистов от размера программного продукта 143 Литература 1. Боэм Б. У. Инженерное проектирование программного обеспечения. Пер. с англ./Под ред. А. А. Красилова. — М.: Радио и связь. 1985. (Barry W. Boehm. Software Engineering Economics. Prentice-Hall. 1981). 2. Брауде Э. Д. Технология разработки программного обеспечения. Пер. с англ. — М.: ПИТЕР. 2004. 3. Вигерс К. И. Разработка требований к программному обеспечению. Пер. с англ. — М.: Русская редакция. 2004. 4. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения. Пер. с англ. — СПб.: БХВ-Петербург. 2005. 5. Гринфилд Д., Шорт К. Фабрика разработки программ. Пер. с англ. — М.: Диалектика. 2007. 6. Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. Пер. с англ. — М.: Лори. 2003. 7. Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. Пер. с англ. — М.: Вильямс. 2002. 8. Коберн А. Современные методы описания требований к системам. Пер. с англ. — М.: Лори. 2002. 9. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Пер. с англ. — М.: Вильямс. 2002. 10. Липаев В. В., Потапов А. И. Оценка затрат на разработку программных средств. — М.: Финансы и статистика. 1988. 11. Липаев В. В. Технико-экономическое обоснование проектов сложных программных средств. — М.: СИНТЕГ. 2004. 12. Липаев В. В. Тестирование компонентов и комплексов программ: Учебник. — М.: СИНТЕГ. 2010. 13. Липаев В. В. Программная инженерия. Методологические основы: Учебник. — М.: ТЕИС. 2006. 14. Липаев В. В. Человеческие факторы в программной инженерии: рекомендации и требования к профессиональной квалификации специалистов: Учебник. — М.: СИНТЕГ. 2009. 15. Рекомендации по преподаванию программной инженерии и информатики в университетах. Пер. с англ. — М.: ИНТУИТ. 2007. 144 16. Трубачев А. П., Долинин М. Ю., Кобзарь М. Т. и др. Оценка безопасности информационных технологий. Общие критерии. Пер. с англ. Под ред. В. А. Галатенко. — М.: СИП РИА, 2001. 17. Тэллес М., Хсих Ю. Наука отладки. Пер. с англ. — М.: Кудиц-образ. 2003. 18. Уайт Б. А. Управление конфигурацией программных средств. Практическое руководство по Rational ClearCase. Пер. с англ. — М.: ДМК Пресс. 2002. 19. Мазер Г. Я., Мхитарян Н. А. Экономика машиностроения. — М.: Изд. МГОУ. 2008. 20. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/ IEC TR 15504 — CMM). — М.: Книга и бизнес. 2001. 21. Соммервилл И. Инженерия программного обеспечения. 6-е издание. Пер. с англ. — М.: Вильямс. 2002. 22. Фатрелл Р. Т., Шафер Д. Ф., Шафер Л. И. Управление программными проектами: достижение оптимального качества при минимальных затратах. Пер. с англ. — М.: Вильямс. 2003. 23. Boehm B. W. et al. Software cost estimation with COCOMO II. Prentice Hall PTR. New Jersey. 2000. 24. Jones C. Applied software measurement, assuring productivity and quality. McGraw-Hill. NY. 1996. 25. Londeix B. Cost estimation for software development. Cornwall: Addison-Wesley. 1987. 26. Mutafelija B., Stromberg H. Systematic process improvement using ISO 9001:2000 and CMMI. SEI. 2003. 145 Приложение Перечень основных стандартов, регламентирующих проектирование и производство заказных программных продуктов 1. ISO 12207:2008. Процессы жизненного цикла программных средств. 2. ISO 16326:1999. (ГОСТ Р — 2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами. 3. CMMI — Capability Maturity Model Integration for Product and Procеss Development — Интегрированная модель оценивания зрелости продуктов и процессов разработки программных средств. 4. ISO 15288:2002. Системная инженерия Процессы жизненного цикла систем. 5. ISO 19760:2003. Системная инженерия. Руководство по применению стандарта ISO 15288. 6. ГОСТ Р 51904–2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию. 7. ISO 9000:2000. (ГОСТ Р — 2001). Система менеджмента (административного управления) качества. Основы и словарь. 8. ISO 9001:2000. (ГОСТ Р — 2001). Система менеджмента (административного управления) качества. Требования. 9. ISO 9004:2000. (ГОСТ Р — 2001). Система менеджмента (административного управления) качества. Руководство по улучшению деятельности. 10. ISO 12182:1998. (ГОСТ Р– 2002). ИТ. Классификация программных средств. 11. ISO 14598–1–6:1998–2000. Оценивание программного продукта. Ч.1. Общий обзор. Ч. 2. Планирование и управление. Ч. 3. Процессы для разработчиков. Ч. 4. Процессы для покупателей. Ч. 5. Процессы для оценщиков. Ч. 6. Документирование и оценивание модулей. 146 12. ISO 9126–1–4: 2002. ИТ. ТО. Качество программных средств: Ч. 1. Модель качества. Ч. 2. Внешние метрики. Ч. 3. Внутренние метрики. Ч. 4. Метрики качества в использовании. 13. ISO 25000:2005 ТО. — Руководство для применения новой серии стандартов по качеству программных средств на базе обобщения стандартов ISO 9126:1–4: 2002 и ISO 14598:1–6:1998–2000. 14. ISO 15939: 2002 — Процесс измерения программных средств. 15. ISO 15408–1–3. 1999. (ГОСТ Р — 2002). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Ч. 1. Введение и общая модель. Ч. 2. Защита функциональных требований. Ч. 3. Защита требований к качеству. 16. ISO 14756: 1999. ИТ. Измерение и оценивание производительности программных средств компьютерных вычислительных систем. 17. ISO 12119:1994. (ГОСТ Р — 2000). ИТ. Требования к качеству и тестирование. 18. ISO 14764: 1999. (ГОСТ Р — 2002). ИТ. Сопровождение программных средств. 19. ISO 15846:1998. ТО. Процессы жизненного цикла программных средств. Конфигурационное управление программными средствами. 20. ISO 16085: 2004 — Характеристики процессов управления рисками при разработке, применении и сопровождении программных средств. 21. ISO 6592:2000 ОИ — Руководство по документации для вычислительных систем. 22. ISO 15910:1999 (ГОСТ Р — 2002) ИТ. Пользовательская документация программных средств. 23. ISO 18019:2004 ИТ. Руководство по разработке пользовательской документации на прикладные программные средства для офисов, бизнеса и профессиональных применений. 24. ГОСТ Р 51901–2002. Управление надежностью. Анализ риска технологических систем. 25. DO-178 B–1995. Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения. 147 Учебное издание ЛИПАЕВ Владимир Васильевич Экономика программной инженерии заказных программных продуктов Учебное пособие Дополнение к учебному пособию «Программная инженерия сложных заказных программных продуктов» Подготовка оригинал-макета: Издательство «МАКС Пресс» Главный редактор: Е.М. Бугачева Корректор: Н.А. Балашова Компьютерная верстка: Е.П. Крынина Электронное издание Изд. № 173. Издательство ООО “МАКС Пресс”. Лицензия ИД N 00510 от 01.12.99 г. 119992, ГСП-2, Москва, Ленинские горы, МГУ им. М.В. Ломоносова, 2-й учебный корпус, 527 к. Тел. 8(495)939-3890/91. Тел./Факс 8(495)939-3891.

Рекомендованные лекции

Смотреть все
Информационные технологии

Введение в экономику программной инженерии

Лекция 1. Введение в экономику программной инженерии Для небольших относительно простых проектов программных комплексов во многих случаях достаточно д...

Экономика

Экономика программной инженерии

МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «МИРЭА – Российский технологический университе...

Автор лекции

Кириллина Ю.В.

Авторы

Управление проектами

Управление программными проектами

Конспект лекций по дисциплине «Управление программными проектами» Составитель: д.т.н., профессор Никонов А.В. План лекционных занятий: Тема 1. Введени...

Автор лекции

Никонов А. В.

Авторы

Управление проектами

Управление программными проектами

Лекции по управлению программными проектами 1 Содержание Отзыв на книгу .................................................................................

Информационные технологии

Лекции по управлению программными проектами

С.АРХИПЕНКОВ Лекции по управлению программными проектами 2009 Содержание Стоимость Время МОСКВА 2009 МОСКВА С. Архипенков Лекции по управлению програм...

Автор лекции

Архипенков С.

Авторы

Информационные технологии

Управление программными проектами

С.АРХИПЕНКОВ Лекции по управлению программными проектами 2009 Содержание Стоимость Время МОСКВА 2009 МОСКВА С. Архипенков Лекции по управлению програм...

Автор лекции

С. Архипенков

Авторы

Информационные технологии

Управление программными проектами

С.АРХИПЕНКОВ Лекции по управлению программными проектами 2009 Содержание Стоимость Время МОСКВА 2009 МОСКВА С. Архипенков Лекции по управлению програм...

Автор лекции

С. Архипенков

Авторы

Инновационный менеджмент

Реинжиниринг бизнес-процессов

Министерство образования и науки Российской Федерации Федеральное агентство по образованию РФ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И ...

Автор лекции

Силич В.А., Силич М.П.

Авторы

Метрология

Требования к измерительным и испытательным лабораториям

Лекция 8. Требования к измерительным и испытательным лабораториям В Российской Федерации с 1 июля 2007г. введен в действие ГОСТ Р ИСО/МЭК 17025-2006 (...

Программирование

Программная инженерия

ЛЕКЦИИ по дисциплине «Программная инженерия» ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ Программная инженерия (промышленное программирование) обычно ассоциирует...

Смотреть все