/
Автор: Липаев В.В.
Теги: компьютерные технологии оргсвязь экономика экономический анализ издательство синтег серия управление качеством
ISBN: 5-89638-082-8
Год: 2004
Текст
Управление качеством
в.в. ЛИПАЕВ
ТЕХНИКО¬
ЭКОНОМИЧЕСКОЕ
ОБОСНОВАНИЕ
ПРОЕКТОВ
СЛОЖНЫХ
ПРОГРАММНЫХ
СРЕДСТВ
СИНТЕГ
Москва - 2004
Серия «Управление качеством»
Институт системного программирования
Российской академии наук
В.В. .ГТИПА ЕВ
ТЕХНИКО¬
ЭКОНОМИЧЕСКОЕ
ОБОСНОВАНИЕ
ПРОЕКТОВ
СЛОЖНЫХ
ПРОГРАММНЫХ
СРЕДСТВ
СИНТЕГ®
Москва - 2004
УДК 681.324.067
ББК 32.988
Л61
Липаев В.В.
Л61 Технико-экономическое обоснование проектов сложных
программных средств. - М.: СИНТЕГ, 2004. - 284 с.
(Серия «Управление качеством»).
ISBN 5-89638-082-8
Рассматриваются цели и задачи технико-экономического анализа и
обоснования проектов программных средств (ПС), прогнозирование ис¬
пользования ограниченных ресурсов при создании крупных комплексов
программ. Проанализированы характеристики программных объектов и
факторы, определяющие технико-экономические показатели (ТЭП) при
разработке ПС. Представлены методы оценки затрат на разработку полно¬
стью новых комплексов программ и с применением повторно используе¬
мых компонентов. Проанализирован ряд дополнительных факторов, вли¬
яющих на затраты при разработке сложных ПС: требования к объектам
разработки и к их характеристикам качества; характеристики специали¬
стов; технологическая среда разработки. Изложены три практические ме¬
тодики технико-экономического обоснования проектов ПС: на базе экс¬
пертной оценки производительности труда и стоимости строки текста про¬
грамм; на основе предварительного расчета трудоемкости и длительности
разработки программ и необходимого числа специалистов; с учетом ком¬
плекса дополнительных факторов, влияющих на затраты при разработке
программ.
Книга предназначена для заказчиков, руководителей и менеджеров
крупномасштабных проектов программных средств, к которым предъявля¬
ются высокие требования к качеству функционирования и ограничены дос¬
тупные ресурсы разработки. Она может быть полезна системным аналити¬
кам, исполнителям научных проектов и опытно-конструкторских работ,
студентам и аспирантам, связанным с созданием программных продуктов.
ББК 32.988
ISBN 5-89638-082-8
© В.В. Липаев, автор, 2004
© В.Л. Гуревич, серия, 2004
© ООО «НПО СИНТЕГ», оформление, 2004
Оглавление
3
ОГЛАВЛЕНИЕ
Введение 5
Глава 1. Основы технико-экономического обоснования
жизненного цикла проектов программных
средств 13
1.1. Цели и задачи технико-экономического анализа и
обоснования проектов программных средств 13
1.2. Прогнозирование технико-экономических харак¬
теристик программных средств 24
1.3. Состав затрат в жизненном цикле сложных про¬
граммных средств 33
1.4. Риски при технико-экономическом обосновании
проектов программных средств 55
Глава 2. Основные факторы, определяющие технико¬
экономические показатели в жизненном цикле
программных средств 71
2.1. Особенности объектов, определяющие технико¬
экономические показатели в жизненном цикле
программных средств 71
2.2. Особенности измерения масштаба - размера объ¬
ектов при технико-экономическом обосновании
проектов программных средств 89
Глава 3. Базовые характеристики затрат на разработку
программных средств 109
У 3.1. Оценка трудоемкости и длительности разработки
полностью новых программных средств 109
\/ 3.2. Оценка затрат на разработку программных средств
на базе повторного использования готовых про¬
/ граммных компонентов 129
V 3.3. Распределение затрат на разработку программных
средств по этапам работ 149
4
Технико-экономическое обоснование проектов.
Глава 4. Факторы, влияющие на затраты при разработ¬
ке сложных программных средств 159
4.1. Концепция уточнения прогнозов затрат под влия¬
нием различных факторов при разработке про¬
граммных средств 159
4.2. Влияние требований к характеристикам программ¬
ных средств на затраты при их разработке 168
4.3. Влияние характеристик специалистов на затраты
при разработке программных средств 187
4.4. Влияние технологической среды на затраты при
разработке программных средств 203
4.5. Влияние аппаратной вычислительной среды на
затраты при реализации программных средств 220
Глава 5. Методики технико-экономического обоснова-
s— ния проектов сложных программных средств 227
\ 5.1. Методика первичного, экспертного технико-
\| 1 экономического обоснования разработки про-
V храммных средств 227
5.2. Методика технико-экономического обоснования
разработки программных средств на базе модели
СОСОМО 11.2000 241
5.3. Методика технико-экономического обоснования
разработки программных средств на базе отечест¬
венной модели ПЛАПС 251
Приложения
П1. Перечень основных стандартов в области технико¬
экономического обоснования проектов сложных
программных средств 258
П2. Примеры прогнозирования технико-экономиче¬
ских показателей разработки программных средств
на основе моделей СОСОМО 261
Литература 266
Об авторе 270
Информация о книгах В.В. Липаева 272
Книги издательства СИНТЕГ 279
Введение
5
ВВЕДЕНИЕ
Приступая к разработке крупных проектов, руководители, пре¬
жде всего, пытаются понять целесообразно ли их создание и оценить
какова будет возможная эффективность применения готового про¬
дукта, оправдаются ли затраты на его разработку и использование.
Поэтому такие проекты традиционно начинаются с анализа и разра¬
ботки технико-экономического обоснования (ТЭО) предстоящего
жизненного цикла проекта и эксплуатации предполагаемого продук¬
та. Заказчику проекта необходимо оценить реальную потребность в
его создании и возможную конкурентоспособность, а потенциаль¬
ному разработчику-поставщику создаваемого продукта, провести
г оценку реализуемости проекта в условиях и ресурсах, предлагаемых
заказчиком/Должен быть) подготовлен согласованный между закаЗ^
'чиком и разработчиком первичный документ, в котором (определе¬
ны цели и задачи проекта, предполагаемые характеристики продукта i
и необходимые ресурсы для его реализац^иГэти данные должны
быть предварительно сбалансированы и обеспечивать реализацию
целей проекта при выделенных ресурсах с минимальным допусти¬
мым риском. Однако масштабы целей и функций сложных проектов
имеют устойчивую тенденцию изменяться и увеличиваться по мере
развития, а первоначально выделяемые ресурсы не удовлетворять их
реализацию. Технико-экономическое обоснование проектов на на¬
чальном этапе их развития должно содержать оценки рисков реали¬
зации поставленных целей, обеспечивать возможность планирова¬
ния и выполнения жизненного цикла (ЖЦ) продукта или указывать
на недопустимо высокий риск его реализации и целесообразность
прекращения разработки.
Массовое создание сложных программных средств (ПС)
промышленными методами и большими коллективами специали¬
стов вызвало необходимость их четкой организации, планирования
работ по затратам, этапам и срокам реализации. Совокупные за-
6
Технико-экономическое обоснование проектов..
траты в мире на такие разработки составляют миллиарды, а для
отдельных проектов — миллионы долларов в год, поэтому требу¬
ется тщательный анализ эффективности создания и использова¬
ния ПС. Для решения этих задач формируется новая область
знания и научная дисциплина - экономика жизненного цикла
программных средств как часть экономики промышленности и вы¬
числительной техники в общей экономике государств и пред¬
приятий.
Развитие этой области экономики связано с большими трудно¬
стями, типичными для новых разделов науки и техники, появ¬
ляющихся на стыке различных областей знания. В данном слу¬
чае особенности состоят в том, что руководители и разработчики
комплексов программ, как правило, не знают даже основ эконо¬
мики разработки и производства сложной продукции, а эконо¬
мисты не представляют сущность объектов разработки - про¬
граммных средств, а также особенностей их создания, техноло¬
гического процесса и применения.[объективно положение ослож^]
нено трудностью измерения характеристик таких объектовТ^Пиро-
кий спектр количественных и качественных показателей, которые с
/■различных сторон характеризуют содержание этих объектов, и
I невысокая достоверность оценки их значений, определяют значи¬
тельную дисперсию при попытке описать и измерить свойства соз¬
даваемых или используемых ПС. .—
^^Особенности развития методов и процессов технико¬
экономического обоснования проектов ПС обусловлены, в част¬
ности, сложностью, и, в ряде случаев, неопределенностью харак¬
теристик предполагаемого продукта, технологических этапов и
процессов разработки, производства и применения пpoгpaJvlм)для
ЭВМ. При разработке комплексов программ сложно переплета¬
ются содержание, этапы и распределение работ, возможен ряд
возвратов на более ранние технологические этапы в процессе
создания компонентов ПС, они имеют не совсем определенные
границы начала и завершения. Специалисты в коллективе могут на
некотором интервале времени решать несколько производствен¬
ных задач и заменять друг друга. Положение усугубляется трудно-
стью[поэтапного определения качества компонентов и его прогно¬
зирования в процессе разработки, что непосредственно отражается
Введение
7
на технико-экономических показателях (ТЭП) проекта в целой?)
Следствием этого являются большие ошибки при планированииJ
сроков, трудоемкости и стоимости создания ПС,) ЗлАстихийность
при создании крупных комплексов программ£в большинстве
случаев приводит к значительному запаздыванию разработок и",
превышению предполагавшихся затрат. Практика ппгпудних ч?т--
показывает, что вследствие пренебрежения тщательным техни¬
ко-экономическим обоснованием, до 15% проектов сложных про- ,
граммных комплексов не доходит до завершения, а почти половина |
проектов не укладывается в выделенные бюджет и сроки и не. обео 1
печивает требуемые характеристики качества^Типичны ситуации,
когда отставание сроков внедрения промышленных систем управ¬
ления и обработки информации полностью зависит от неготов¬
ности программ для них.
ГДля небольших относительно простых проектов ПС, во многих
случаях достаточно достоверными могут быть интуитивные оценки
требуемых ресурсов/выполняемые опытными руководителями,Jpea-
лизовавшими несколько ^алогичных проектов. При начале проек¬
тировании крупных ПС,/требующих заведомо больших экономиче¬
ских, трудовых и временных затрат, необходима хотя бы прибли¬
женная, формализованная их оценка по определенной методике. \
Интуитивные оценки руководителями и исполнителями - размер
ров, сложности и трудоемкости конкретных программных проектов,
как правило, отличаются существенными недостатками'.
- человек, в основном оптимистичен, и каждому хочется,
чтобы проект ПС было меньше по размеру и более простым, что ве¬
дет к первоначальным недооценкам его сложности и к конфликтным
ситуациям при разработке;
- человек обычно не полностью использует предыдущий
опыт о сложности функций аналогичных ПС и, особенно, о боль¬
шом размере вспомогательных компонентов комплексов программ,
которые также должны быть разработаны;
- отдельные специалисты, как правило, не знакомы со всем
объемом проекта и пожеланиями пользователей, что приводит к не¬
дооценке второстепенных функций и компонентов ПС, к отсутствию
реалистичного применению накопленных знаний при оценивании
размера и сложности проекта.
8
Технико-экономическое обоснование проектов.
Эти обстоятельства приводят к большим ошибкам оценивали)
ТЭП на начальных этапах разработки, которые можно значительш
сократить при относительно небольших усилиях, применяя, в ча
стности, формализованные методики экспертной оценки основны?
технико-экономических характеристик проектов комплексов про
грамм. Тем самым проекты сложных ПС с самого начала могли бь
выполняться с учетом более достоверной оценки необходимых ре
сурсов. Следствием недостатков или отсутствия технико
экономическим обоснованием проектов новых ПС являются ост
рые конфликты между заказчиками и разработчиками.(Част1
разработчики ПС не в состоянии привести заказчику или руково
дителю проекта достаточно обоснованные доказательства не ре
альности выполнения выдвигаемых требований и предложенны?
ограниченных бюджета и сроков^Это приводит к оптимистиче
ской переоценке выгод новой программной разработки, к недо
оценке роли других конкурирующих предложений при заключе
нии контрактов на разработку, и вследствие этого - к неизбеж
ным перерасходам средств и к снижению качества ПС. Руководи
тели конкретных проектов обычно не в состоянии достаточно обос
нованно определять, сколько времени и затрат труда потребуете
на каждый этап и работу программной части проекта системы
Вследствие этого, они не могут оценить, насколько успешно вы
полняется имеющийся план разработки ПС. Это, как правило
означает, что программная часть проекта системы с самого на¬
чала выходит из-под контроля и возможна катастрофа с реализа
цией и завершением проекта всей системы в требуемый срок с
заданным качеством.
г^^Большую часть этих негативных последствий можно избежать
'используя существующие, достаточно точные методы оцениванш
и прогнозирования затрат, а также управления проектами ПС
для их успешного завершения. Эти последствия объясняются мно
гими причинами, из которых наиболее важными, являются следую
щие:
- исходные тексты программных компонентов различны и пс
отдельности не определяют сложность и размер конечного продук
та;
- разработка сложных ПС требует творчества и сотрудничест¬
ва разных специалистов, индивидуальное и групповое поведение
Введение
9
которых, как правило, трудно предсказать;
- в области экономики жизненного цикла ПС накоплен отн<>\
сительно небольшой опыт количественных оценок, и его трудней
увеличивать, проводя и не обобщая разрозненные эксперименты.
За последние несколько лет ряд исследований и работ по сбору
и обобщению экономических дачных о ЖЦ ПС заложили основы
для методов и моделей оценивания затрат, которые обладают удов¬
летворительной точностью. Современная экономическая модель
оценки разработки ПС считается хорошей, если с ее помощью мож¬
но оценить затраты на программную разработку с точностью 20 % в
70% случаев, при условии использования модели, в классе проектов,
на которые она ориентирована. Имеющиеся модели не всегда столь
точны, как хотелось бы, но могут весьма существенно помочь в тех¬
нико-экономическом анализе и обосновании решений при создании
сложных ПС. Необходимы дальнейшие, активные исследования на I
разных уровнях детализации, начиная от экономики и планирования '
создания программных средств в масштабах страны или предпри¬
ятия и кончая экономикой выполнения частных операций отдель¬
ными специалистами при разработке или производстве кон-j
кретных ПС. Одна из важнейших задач состоит в том, чтобы увя¬
зать четкими экономическими категориями взаимодействие разных
специалистов и предприятий в типовой производственной цепочке:
заказчик - разработчик - изготовитель - пользователь.!Дпя этого объ-/
ект потребления - программное средство и все процессы взаимо-1
действия в цепочке должны быть связаны системой экономических \
и технических характеристик, в той или иной степени, исполь- \
зующих основные экономические показатели - реальные за- ]
траты ресурсов: финансов, труда и времени специалистов I
на конечный продукт^ /
Для решения этой задачи необходимо детально исследовать
требуемые ресурсы современных процессов создания и исполь¬
зования программ различных классов и назначения - встроен¬
ных, коммерческих, административных, учебных, уникальных и
Др. Только на базе серьезных статистических исследований техни¬
ко-экономических показателей жизненного цикла и практическо¬
го маркетинга ПС возможны обобщения и создание теоретиче¬
ских и практических основ экономики ПС. Перечисленные вы-
10
Технико-экономическое обоснование проектов..
ше проблемы и задачи требуют для своего решения выполнения
крупных, комплексных научно-исследовательских работ, многие
H3jcoxqpbix еще не поставлены и далеки от разрешения.
J Цель книги состоит в представлении специалистам совре-
Iменных методов технико-экономического анализа, оценивания и
прогнозирования необходимых ресурсов для проектов разработ¬
ки комплексов программ. Тем самым выделен очень важный, ба-
''зовый раздел из всей экономики программных средств. Такое вы¬
деление определялось тем, что без подобных базовых исследо¬
ваний вряд ли возможно последующее серьезное развитие эко¬
номики в этой отрасли, а также кругом интересов автора и наличи¬
ем собственных исследований в данной области|Внимание сосре¬
доточено на концептуальной основе распределения затрат труда в
процессе разработки программ, на факторах, определяющих ре¬
альные трудозатраты и другие технико-экономические пока¬
затели, а также на исследовании таких характеристик в реали¬
зованных современных разработках ПС.
В книге рассматриваются преимущественно средние и круп¬
ные проекты ПС, создаваемые коллективами специалистов. В
таких проектах на чистое творчество, искусство и научные ис¬
следования отдельных специалистов, преобладающие в небольших
индивидуальных разработках, накладывается множество работ,
характерных для индустриального проектирования и производ¬
ства программных продуктов. Вследствие этого значительно ни¬
велируются индивидуальные особенности отдельных специали¬
стов, и появляется возможность оценивать усредненные характе¬
ристики производительности труда и другие ТЭП в крупных кол¬
лективах. .Анализируемые в книге процессы ограничены в основ¬
ном от этапа оформления требований технического задания на
разработку ПС и до этапа завершения испытаний опытного об¬
разца программного продукта соответствующего требованиям
заказчика. Тем самым только попутно рассматриваются про¬
цессы сопровождения, тиражирования, производства, внедрения
и применения ПС. Процессы формирования рыночной стоимости
программных продуктов и маркетинговые исследования в облас¬
ти экономики создания, распространения и продажи массовых
промышленных программных средств в книге практически не учи¬
тываются и не рассматриваются.
Введение
11
Интерес к экономике программных средств отражается в бы¬
стром росте числа публикаций, посвященных различным аспек¬
там этой проблемы. В результате накоплен определенный объем
полезных методических и статистических данных о разных
классах и видах ПС. Наиболее полные исследования, обобщения и
экономические характеристики реализованных проектов отраже¬
ны в двух книгах Б. Боэма [2,30]. В предлагаемой книге авто¬
ром приведен ряд результатов собственных оригинальных ис¬
следований [13]. Анализ этих данных совместно с результатами
других авторов позволил создать^методики прогнозирования
необходимых ресурсов для разработки ПС, их достоверного
планирования и формирования технологических процессов. (Но¬
визна и отсутствие твердо установленной терминологии в данной
области привело к необходимости подробной интерпретации не¬
которых использованных показателей и терминов.
Ограниченность ресурсов при создании крупных ПС приводит
к целесообразности тщательного планирования, упорядочения и
применения экономичных и эффективных методов автоматиза¬
ции обеспечения ЖЦ ПС с целью достижения требуемого качества
и достоверного его определения. Для каждого крупномасштабного
проекта ПС, выполняющего ответственные функции, рекомендуется
прогнозировать требующиеся ресурсы, разрабатывать и применять
комплексную систему качества, специальные планы и Программу,
методологию и инструментальные средства, обеспечивающие тре¬
буемые качество, надежность и безопасность функционирования
комплексов программ. Изложенные в книге методы и стандарты мо¬
гут быть полезны при подготовке промышленных технологий, мето¬
дик разработки и испытания конкретных ПС, однозначно отражаю¬
щих степень удовлетворения исходных требований заказчика и
пользователей, а также для сравнения ПС разных поставщиков и вы¬
явления среди них предпочтительных.
В жизненном цикле сложных ПС для обеспечения их высокого
качества целесообразно выделять специалистов, ответственных
за анализ и прогнозирование экономических характеристик про¬
екта, за соблюдение промышленной технологии создания и совер¬
шенствование программ, за измерение и контроль затрат, качества
ПС в целом и их компонентов. Необходимо научить специалистов
анализу и оцениванию конкретных факторов, влияющих на характе¬
12
Технико-экономическое обоснование проектов.
ристики функционирования программных продуктов со стороны
реально существующих и потенциально возможных негативных
воздействий и ограничений ресурсов проектов ПС. Предлагаемая
книга ориентирована на подготовку и воспитание квалифицирован¬
ных специалистов в-области индустрии крупномасштабных про¬
граммных средств, ца их обучение методам и современной про¬
граммистской культуре промышленного создания крупных высоко¬
качественных проектов ПС.
Творческий анализ и применение изложенного материала
может послужит стимулом для углубленного исследования про¬
блемы неширокого внедрения современных методов технико¬
экономического обоснования реальных проектов ПС.! В даль¬
нейшем это должно привести к созданию новой областй^кономи-
ческой науки - экономики жизненного цикла программных
средств. '[Ее основной задачей будет прогнозирование, эффею
тивное распределение ресурсов и экономное использование бы¬
стро возрастающих капиталовложений на комплексы программ
различного назначения.
Предлагаемая книга является головной в серии, отражающей
современные методы и стандарты, обеспечивающие жизненный
цикл сложных программных средств высокого качества. Эта серия
охватывают системное проектирование [17], выбор, оценивание и
обеспечение высоких характеристик качества [16, 18], проблемы
функциональной безопасности [19], конфигурационного управления
и документирования [15] комплексов программ. Перечисленные
книги предназначены для специалистов, реализующих различные
этапы жизненного цикла крупномасштабных ПС, создающих и при¬
меняющих компоненты и системы в этой области. Автор надеется,
что публикация серии будет способствовать сокращению количества
провальных проектов, при которых нарушаются бюджет и сроки
реализации, отсутствуют требуемые функции и недостаточно каче¬
ство функционирования ПС.
fjiaea 1. Основы технико-экономического анализа..
13
Глава 1
ОСНОВЫ ТЕХНИКО-ЭКОНОМИЧЕСКОГО
АНАЛИЗА И ОБОСНОВАНИЯ ПРОЕКТОВ
СЛОЖНЫХ ПРОГРАММНЫХ СРЕДСТВ
1.1. Цели и задачи технико-экономического анализа и
обоснования проектов программных средств
^ 'Целью процесса разработки ПС является создание комплексов
1 программ заданного качества в условиях ограниченных ресурсов.
[Для достижения этой цели используются современные технологийjhJ1
/средства автоматизации разработки ПС различных классов. \В про¬
цессе разработки выделяются и реализуются частные, иногда проти¬
воречивые подцели, которые способствуют достижению основной
цели разработки. Анализ этих подцелей и факторов, влияющих на их
реализацию, позволяет создавать базу для эффективного управления
процессами разработки и обеспечения всего ЖЦ сложных ПС и их
оценки.
Технико-экономический анализ разработки комплексов про¬
грамм состоит в выборе и прогнозировании наиболее адекватных
экономических и функциональных критериев для обобщенного опи¬
сания эффективности, стоимости создания и использования ком¬
плексов программ в зависимости от их назначения, области приме¬
нения и других факторов. [Применение программных средств как"|
продукции существенно повысило актуальность технико- (
экономического обоснования и прогнозирования их характеристик
и процессов создания^ Для получения обобщенных, конструктивных
результатов ниже основной целью считается разработка сложных
программных средств различных классов независимо от конкретных
14
Технико-экономическое обоснование проектов.
областей, в которых применяются системы, используемые для
управления и обработки информации.
Ниже предполагается, что основной целью создания ПС являет¬
ся повышение эффективности производства промышленных изделий
или управления объектами и системами, в которых применяются
^крупные комплексы программ^Гакими системамгГ/могут быть}сред-
ства автоматизированного управления прокатными станами, самоле¬
тами или электростанциями,[информационно-справочные системы
административного управления, системы автоматизации проектиро¬
вания и обучения и т.пТв ряде случаев программы невозможно или
очень трудно характеризовать непосредственной экономической
эффективностьюТ}Примером могут служить ПС в системах управле¬
ния воздушным движением или космическими аппаратами, а также
в системах военного назначения или автоматизации научного экспе¬
римента.^ таких случаях при анализе программ невозможно опре¬
делять изменение прямой эффективности систем в зависимости от
затрат и целесообразно из анализа исключать характеристики пол¬
ной экономической эффективности и сопутствующие ей функцио¬
нальные критерии качества [8, 37]. Тогда исследование эффективно¬
сти ПС можно проводить, минимизируя затраты на разработку в
предположении, что полностью обеспечены заданные функциональ¬
ные характеристики, j
Обеспечение жизненного цикла любых изделий не может быть
бесплатным, оно требует определенных затрат ресурсов, которые
обычно тем больше, чем выше требуемое их качество.(Многие про¬
екты информационных систем терпели неудачу из-за отсутствия у
разработчиков и заказчиков при подготовке контракта четкого пред¬
ставления о реальных трудовых, временных и иных ресурсах, необ¬
ходимых для их реализаций?]Ьущественными факторами, влияющи¬
ми на трудоемкость, длительность реализации и качество ПС и БД,
оказывают ограничения ресурсов, доступных для обеспечения их
жизненного цикла, а также возможная экономическая эффектив¬
ность применения.ЦЭбщее понятие - доступные ресурсы разработки
включает реальные финансовые, кадровые и аппаратурные ограни¬
чения, в условиях которых предстоит создание и развитие комплекса
программ^Эти факторы влияют на рентабельность процессов разра¬
ботки, которые сдедует учитывать и оптимизировать при создании и
применении ПС|Поэтому одной из основных задач^ри обеспечении
fjiaea 1. Основы технико-экономического анализа.
15
)К1Д ПС|является технико-экономический анализ и обоснование
необходимых ресурсов для создания проекта IJQ^ соответствии с
требованиями контракта [21, 27, 48]. В ряде случаев этому помогает
опыт и экономические характеристики ранее выполненных проектов
фирмы, но некоторые проекты могут не иметь прецедентов, и тогда
приходится использовать обобщенный опыт и имеющуюся стати¬
стику в этой области.
При планировании ЖЦ программных средств, часто имеется
определенный заказчик-потребитель, который способен задать ос¬
новные цели, характеристики и обеспечить ресурсы для реализации
проекта. Однако иногда ^инициатором разработки ПС является раз¬
работчик-поставщик, который самостоятельно принимает все реше¬
ния о проектировании за счет собственных ресурсов и предполагает
возместить затраты путем реализации программного продукта на
рынке. Таким образом, [при технико-экономическом анализе и
обосновании проектов ПС возможны два сценария:
- создание и весь жизненный цикл комплекса программ и/или
базы данных ориентируется на массовое тиражирование и распро¬
странение их на рынке, среди заранее не известных пользователей в
различных сферах и внешней среде применения; при этом отсутст¬
вует конкретный внешний потребитель-заказчик, который определя¬
ет и диктует основные требования к ПС и финансирует проект;
- разработка проекта ПС и/или БД предполагается для кон¬
кретного потребителя-заказчика с определенным, относительно не¬
большим тиражом и с известной областью и внешней средой приме-
ненияД
ГЗти сценарии принципиально различаются методами техни¬
ко-экономического анализа и обоснования их характеристик. Пер¬
вый сценарий базируется на маркетинговых исследованиях рынка
программных продуктов и на стремлении поставщика занять на
рынке достаточно выгодное место. Для этого ему необходимо опре¬
делить наличие на рынке всей гаммы близких по назначению и
Функциям ПС, оценить их эффективность, стоимость и применяе¬
мость, а также возможную конкурентоспособность предполагае¬
мого к разработке программного продукта для потенциальных поль¬
зователей и их возможное числоДСледует оценить рентабельность
затрат на создание и обеспечение всего ЖЦ нового ПС, выявить
факторы, функциональные, экономические и конструктивные пока¬
16
Технико-экономическое обоснование проектов.
затели качества, которые способны привлечь достаточное число по¬
купателей и оправдать затраты на предстоящую разработку. Для
этого разработчикам необходимо произвести оценки возможной
конкурентоспособности предполагаемой продукции на рынке по
величине соотношения [5, 7, 34]:
I - возможной эффективности (ценности, достоинств) после¬
дующего применения ПС и способности удовлетворить потребности
пользователей при его использовании;
- к стоимости (цене, затратам), которую готов заплатить
пользователь при приобретении и эксплуатации данного комплекса
программ или базы данных.
При выборе поставщика и продукции покупатель стремится
максимизировать это соотношение как за счет поиска ПС с наи¬
большими эффективностью и качеством, так и за счет минимальной
стоимости покупаемого продукта. В этом сценарии при организации
проектирования вся ответственность за цели, функции и показатели
качества проекта ложатся на его руководителей и особую роль
должны играть специалисты по маркетинговому анализу предпола¬
гаемого распространения продукта на рынке. Они должны оценить
конъюнктуру и риск успешного продвижения создаваемого продук¬
та на рынок, сроки и график выполнения этапов жизненного цикла,
достаточность ресурсов для реализации проекта и перспективы эко¬
номической эффективности, длительного развития, модификаций и
распространения версий ПС.
Такие проекты обычно относительно не велики по объему и
срокам реализации первой версии, однако могут предполагать дли¬
тельный ЖЦ и множество модификаций для адаптации к нуждам
пользователей. Отбраковка вариантов реализации новых ПС при
этом ведется по показателю эффективность/стоимость, с динамиче¬
ским учетом их реальной конкурентоспособности на рынке. Это:
сценарий технико-экономического обоснования проектов ПС требу¬
ет специфических маркетинговых исследований рынка аналогичных
программных продуктов, их цены и показателей качества, что выхо¬
дит за рамки данной книги. Однако при этом должны обязательно
учитываться затраты ресурсов на непосредственную разработку и
обеспечение ЖЦ ПС, что анализируется при втором сценарии.
1 Второй сценарий предполагает наличие определенного заказ-
цика-потребителя конкретного проекта ПС и/или БД, который опре
fjiaea 1. Основы технико-экономического анализа.
17
деляет основные технические и экономические требованиями вы¬
бирает конкурентоспособного поставщика-разработчика, которого
оценивает невозможность реализовать проект с необходимым каче¬
ством с учетом ограничения требуемых бюджета, сроков и других
ресурсов^При этом результаты разработки не обязательно подлежат
широкому тиражированию, могут не поступают на рынок, марке¬
тинговые исследования для таких проектов являются второстепен¬
ными и предварительно могут не проводиться. Однако для заказчика
и разработчика при заключении контрактафзеобходимо достаточно
достоверное прогнозирование требований к программному продукту
и технико-экономическое обоснование требуемых ресурсов по тру¬
доемкости, стоимости, срокам и другим показателямГраказчик заин¬
тересован в получении ПС высокого качества при минимальных за¬
тратах. а разработчик желает получить максимальную оплату за соз¬
данный продукт и достаточные ресурсы на его реализацию. Проти¬
воположность интересов поставщика и потребителя при оценке
стоимости и других ресурсов проекта, требует поиска компромисса,
при котором разработчик ПС не продешевит, а заказчик не перепла¬
тит за конкретные выполненные работы и весь проект. Поэтому оба
партнера заинтересованы в достоверном технико-экономическом
прогнозировании и обосновании проекта ПС. Ниже/дсновное вни¬
мание сосредоточено на, технико-экономическом анализе и обос¬
новании процесса разработки^ всего жизненного циклаШС^иу-
тях минимизации затрат и на повышении эффективности автомати¬
зации применяемых технологийГ|При таком анализе должны учиты¬
ваться следующие цели.
Jr г, * ■ '
Первая цель состоит в прогнозировании реальных затрат на
. работку определенного проекта компонентов и ПС в целом с уче¬
том их сложности и требуемого качества. Для этого должна быть
изучена существующая практика разработки программ, и/или обоб¬
щены ТЭП современных проектов ПС. Такие обобщения должны
выявить трудоемкость (стоимость) и производительность труда при
разработке реальных программ определенных классов и назначения,
а также основные факторы, влияющие на эти показатели при созда¬
нии конкретных ПС. Кроме того, необходимо определить длитель¬
ность всего процесса разработки программ и его отдельных этапов.
Для этого должны быть разработаны и внедрены методики сбора
первичных технико-экономических данных и их обработки, по за¬
18
Технико-экономическое обоснование проектов.
вершенным или находящимся в процессе разработки проектам ПС.)В
результате могут быть получены современные значения основных
ТЭП создания программ разных классов.
Вторая цель - создание методов и методик прогнозирования
затрат и длительности разработки комплексов программ. Мето¬
дики должны учитывать полученные значения ТЭП, основные ха¬
рактеристики создаваемых ПС, а также технологию, оснащенность и
организацию их разработки. Получаемые прогнозы позволят эффек¬
тивно планировать разработки, управлять созданием программ и
осуществлять проекты ПС в соответствии с заданными требования¬
ми, сроками и затратами на основе анализа аналогов - прототипов.
Третьей целью анализа является обоснование и создание ме¬
тодов и средств снижения совокупных затрат и сроков разработ¬
ки сложных ПС. При этом возникают задачи:
- эффективного распределения общих трудовых ресурсов, ис¬
пользуемых при разработке программ;
- развития и повышения экономической эффективности техно¬
логий, применяемых для создания ПС различных классов;
- рационального повышения уровня комплексной автоматиза¬
ции технологий разработки ПС;
- выбора методов и инструментальных средств, в наибольшей
степени способствующих снижению длительности создания и сово¬
купных затрат на ПС, а также повышению их качества.
Четвертой целью технико-экономического исследования про¬
цессов разработки программ является создание методических и
нормативных документов, как основы промышленной разработки
аналогичных программных продуктов. Наличие нормативов может
коренным образом изменить характер разработки ПС и приблизить
его к отрасли современного регламентированного промышленного
проектирования. В результате появится возможность управления
затратами на разработку, количеством и качеством создаваемых ПС
и их компонентов на различных этапах.
V В качестве основного критерия эффективности новой техники и
ПС, в частности, широко применяется критерий экономии совокуп¬
ных затрат общественного труда [5, 36, 48], которая получается в
^результате внедрения этой техник^Однако во многих случаях соз¬
данная техника способствует повышению качества изделий или яв¬
ляется принципиально новой продукцией, что затрудняет ее оценку
f* 19 I
fjiaaci 1. Основы технико-экономического анализа...
pio критерию непосредственной экономической эффективностц! По- \
этому широко применяется критерий минимальных приведенных \
затрат, которые требуются при создании и эксплуатации анализи- J
руемых изделий.) Приведенные затраты включают затраты на проек- [
тирование, изготовление и эксплуатацию изделий по всему жизнен»"*"
ному циклу или пересчитанные к годовому интервалу времени) Этот
критерий может поддерживаться (детализироваться) рядом локаль¬
ных критериев: повышением производительности труда, экономией
материальных и производственных ресурсов при вы пол нении, цаст-^
ных работ, улучшением использования оборудования и т.^гт]Крите¬
рий минимальных приведенных затрат применим, если различные
технические решения сопоставимы по функциям, достигаемым це¬
лям и качеству продукции. Однако этот критерий непосредственно
не учитывает возможные различия назначения, функциональных и
технических характеристик создаваемых и эксплуатируемых систем.
Обычно предполагается, что для каждого изделия зафиксирован эф¬
фект от его создания и использования и необходимо выявить все ос¬
новные факторы, способствующие минимизации совокупных за¬
трат на всем жизненном цикле.
На практике классы систем при анализе обычно имеют ряд
близких по значимости целей применения, и соответствующих им
характеристик качества. В результате эффективность технологиче¬
ских решений приходится оценивать одновременно по нескольким
показателям. Для этого стремятся сформулировать обобщенную ска¬
лярную функцию эффекта и затрат или строится нормированный
вектор показателей качества. Для многокритериальной, векторной
оптимизации решений разработан ряд методов, использование кото¬
рых зависит от конкретных особенностей анализируемых изделий.
Кроме того, широко применяется последовательный анализ по от¬
дельным показателям качества с учетом их приоритета (см. п. 1.4).
Во многих случаях эффективность сложной новой техники и ПС
в процессе проектирования приходится прогнозировать в условиях
неопределенности целей, различных факторов и характеристик [33,
42]. Обычно недостаточно известны перспективы внедрения и экс¬
плуатации объектов разработки - новых программных продуктов.
Трудно формализуемыми и оцениваемыми являются размеры (мас¬
штабы) и структура систем, взаимодействие основных подсистем,
Дели, функции и критерии оценки эффективности их функциониро-
20
Технико-экономическое обоснование проектов.
вания. Значительные неопределенности содержатся также в технико¬
экономических характеристиках технологий, а также инструмен¬
тальных средств автоматизации проектирования и изготовления ПС.
В результате экономический анализ и прогнозы могут иметь значи¬
тельный разброс оцениваемых показателей.
Программно-целевое планирование и промышленная разработ¬
ка ПС как продукции целесообразны только для определенных клас¬
сов комплексов программ. С этой позиции программы для вычисли¬
тельных машин можно разделить на три класса, которые впоследст¬
вии рассмотрены подробнее (см. п. 2.1) [2, 13]:
- к первому классу относятся программы автоматического или
автоматизированного управления, непосредственно входящие,
встроенные в системы управления, функционирующие в реальном
масштабе времени;
- второй класс представляется сложными ПС: информационно¬
справочных систем обработки информации организационного и ад¬
министративного направления, систем автоматизации проектирова¬
ния, которые функционируют вне жесткого реального масштаба
времени;
- к третьему классу относятся программы, разрабатываемые
для решения частных инженерных и научно-исследовательских за¬
дач, которые характеризуются относительно малым использованием
ресурсов вычислительных систем и кратковременной эксплуатацией.
Перечисленные классы ПС различаются не только содержанием
решаемых задач, но и их сложностью. Обычно задача числится
простой, если невелики все ресурсы, необходимые для ее решения.
Например, программа, небольшая по длине, может оказаться слож¬
ной по количеству обрабатываемых типов переменных или по до¬
пустимому ожиданию получения результатов. С этой позиции про¬
граммы третьего класса обычно бывают относительно простыми
или, в крайнем случае, средней сложности. Программы второго и
первого классов чаще относятся к диапазону от средней сложности
до сверхсложных - уникальных. При этом для программ первого
класса уровень сложности определяется преимущественно их разме¬
ром (длиной) и допустимым ожиданием результатов (отклика) в ре¬
альном масштабе времени. Для оценки сложности программ второго
класса, кроме их большого размера, часто имеет значение число ти¬
пов обрабатываемых данных. В последующих разделах книги ос-
Глава 1. Основы технико-экономического анализа.
21
новпое внимание уделяется ПС первого и второго классов, отно¬
сящихся к категории сложных.
Важнейшей особенностью программ первого и второго классов
является их отчуждаемость от первичных разработчиков. В от¬
личие от программ для решения многих научных и инженерных за¬
дач, которые не оформляются документацией, делающей их позна¬
ваемыми и доступными для использования различными специали¬
стами, эти ПС имеют все основные особенности изделий и представ¬
ляют собой оформленный программный продукт. После завершения
их разработки и испытаний они отчуждаются от их создателей и мо¬
гут эксплуатироваться, эпизодически модернизироваться и коррек¬
тироваться зачастую не теми специалистами, которые их первона¬
чально разработали. Это обусловливает необходимость проектиро¬
вать такие программы с соблюдением определенных стандартов,
правил структурного построения, а также оформлять на такие про¬
граммы полную техническую документацию, позволяющую экс¬
плуатировать, сопровождать и развивать ПС различными квалифи¬
цированными специалистами.
Достаточно обычными стали комплексы программ объемом 100
- 500 и более тыс. строк текста. Возникла проблема декомпозиции
ПС на компоненты меньшего размера и сложности, а также упоря¬
доченного структурно-иерархического построения таких программ.
Известные методы снижения суммарной сложности систем путем
декомпозиции, структурирования, локализации функций и упроще¬
ния компонентов нашли дальнейшее развитие при создании совре¬
менных методов разработки сложных ПС. Такие сложные програм¬
мы в разумные сроки (1-5 лет) могут быть созданы только органи¬
зованными коллективами специалистов под единым руководством.
Размеры коллективов разработчиков и их структура в значительной
степени диктуются структурой, функциональными задачами и ха¬
рактеристиками программ. Коллективность разработки ПС при¬
вела к необходимости строгого планирования и формализации про¬
цесса разработки аналогично процессу проектирования других
сложных промышленных изделий.
Программы первого и частично второго классов обычно дли¬
тельно функционируют во многих экземплярах системы. Это приво¬
дит к необходимости эффективного использования ограниченных
22
Технико-экономическое обоснование проектов..
вычислительных ресурсов, памяти и производительности реали¬
зующих (объектных) ЭВМ идя функциональных программ, которые
предназначены для решения основных задач по обработке информа¬
ции или управлению. Технологические программы, используемые
для автоматизации процесса проектирования, нецелесообразно
иметь в каждом экземпляре ЭВМ, и их стремятся разместить в от¬
дельных технологических ЭВМ. Необходимость экономии ресурсов
реализующей ЭВМ зачастую ограничивает применение алгоритми¬
ческих языков высокого уровня и трансляторов, приводящих к зна¬
чительному расширению объектного кода программ. Эффективность
использования памяти и производительности непосредственно от¬
ражается на возможности и рентабельности применения ЭВМ в ряде
областей (например, в бортовых системах средств вооружения).
Включение комплексов программ в контур управления произ¬
водством или динамическими объектами приводит к необходимости
обеспечения ими высокого качества решения задач, безопасности и
надежности их функционирования не ниже, чем у аппаратных
компонентов соответствующих систем. Поэтому программы должны
тщательно отлаживаться и проходить контрольные испытания для
определения уровня отлаженное™, безопасности и надежности их
функционирования. Выявилась необходимость высококачественной
отработки программ на технологических ЭВМ перед их вводом в
реализующую ЭВМ. Отладка программ на технологических ЭВМ
позволяет в ряде случаев значительно сокращать сроки разработки и
проводить ее независимо от разработки реализующей ЭВМ, для ко¬
торой предназначен комплекс программ. Комплексное использова¬
ние универсальных ЭВМ в качестве технологических и моделирую¬
щих позволяет успешно решать задачу создания надежных отлажен¬
ных программ для систем реального времени.
‘ С позиции технико-экономического анализа жизненный цикл
ПС можно разделить на две части, существенно различающиеся
особенностями процессов, технико-экономическими характеристи¬
ками и влияющими на них факторами. В первой части ЖЦ произ¬
водятся системный анализ, проектирование, разработка, тестирова¬
ние и испытания первой базовой версии ПС. Номенклатура работ, их
трудоемкость, длительность и другие характеристики на этих этапах
ЖЦ существенно зависят от создаваемого объекта, требуемых пока¬
зателей качества, внешней и технологической среды разработки.
fjiaea 1. Основы технико-экономического анализа.
23
Изучение подобных зависимостей для различных ПС позволяет про¬
гнозировать состав и основные технико-экономические_показатели,
планы и графики работ для вновь создаваемых nC.jHa этой части
ЖМПС сосредоточено основное содержание книги.
I Вторая часть ЖЦ, отражающая эксплуатацию и сопровожде¬
ние ПС, относительно слабо связана с характеристиками объекта и
среды разработки. Программы первого и второго классов характери¬
зуются длителыюй непрерывной эксплуатацией, продолжитель¬
ность которой обычно значительно превышает длительность разра¬
ботки первой версии. После того как программы созданы и испыта¬
ны, в ряде случаев они становятся недоступными для разработчиков
и эксплуатируются неизменными до внедрения очередной версии
при модернизации системы. Жизненный цикл таких ПС может со¬
ставлять десяток лет, в течение которых необходимо обеспечить их
сопровождение. В процессе сопровождения программы могут под¬
вергаться эпизодическим корректировкам, которые должны регист¬
рироваться, накапливаться и передаваться пользователям экземпля¬
ров системы. Необходимо обеспечить адекватность документации
каждой версии эксплуатируемого ПС в любой момент времени.
I Номенклатура работ на этих этапах более или менее стабильна,
а их трудоемкость и длительность могут сильно варьироваться и за¬
висят от массовости и других факторов распространения и примене¬
ния ПС^Успех ПС у пользователей и на рынке, а также процесс раз¬
вития версий трудно предсказать, и он не связан непосредственно с
техническими параметрами комплексов программ. Определяющими
становятся потребительские характеристики и качество ПС, а их
технико-экономические особенности с позиции разработчиков отхо¬
дят на второй план (см. выше, первый сценарий). Вследствие этого в
широких пределах изменяются трудоемкость и необходимое число
специалистов, поддерживающих эти этапы. Это затрудняет обобще¬
ние ТЭП различных проектов и прогнозирование на их основе ана¬
логичных характеристик новой разработки. Поэтому планы работ на
этих этапах имеют характер общих взаимосвязей работ, которые
требуют ручного распределения во времени индивидуально для ка¬
ждого проекта. В результате планирование трудоемкости, длитель¬
ности и числа специалистов для этих этапов приходится произво¬
дить итерационно на базе накопления опыта и анализа развития
конкретных типов и версий ПС.
24
Технико-экономическое обоснование проектов.
1.2. Прогнозирование технико-экономических характеристик
программных средств
Целью рассматриваемых прогнозов является оценка трудоем¬
кости и длительности разработки комплексов программ, а также
распределения затрат по составляющим и этапам работ. Прогнозы
предназначены для планирования процесса разработки конкретных
ПС, оценки их стоимости, длительности и других ТЭП на началь¬
ных этапах проекта в технических заданиях и контрактах. Результа¬
ты прогнозов должны обеспечивать возможность согласовывать
заказчику и разработчику сроки и стоимость создания ПС.
Объектом прогноза по времени являются совокупные затраты
и их основные составляющие, а также длительность и другие ТЭП
разработки сложных комплексов программ гарантированного каче¬
ства коллективами специалистов. Достоверность первичных прогно¬
зов трудоемкости и стоимости на этапах концепции и системного
анализа может составлять 30 - 50%, а уточненные оценки на этапе
структурного проектирования, могут улучшаться до 20%. Жела¬
тельно, точность прогнозов при детальном проектировании дово¬
дить до 10%, однако более точные оценки пока вряд ли возможны,
вследствие ограниченного опыта их проведения и малой статистики
ТЭП завершенных разработок.
Глубина прогнозов соответствует длительности полного цик¬
ла разработки сложных ПС, которая может варьироваться в пре¬
делах 1 - 5 лет. При этом, как правило, объект и технология раз¬
работки, а также средства ее автоматизации определяются перед
началом разработки и в дальнейшем практически не изменяются.
Вследствие этого вновь появляющиеся технологии практически
неприменимы для уже начатых разработок. Для прогнозирова¬
ния всегда используется более или менее представительная база
данных ТЭП ранее завершенных разработок. Технология и осна¬
щенность инструментальными средствами автоматизации этих
разработок соответствует некоторому уровню, характерному для
времени их начала. Чем больше данных привлекается для полу¬
чения обобщенных значений ТЭП, тем больше в их составе будсч
результатов работ, завершенных несколько лет назад.
Глава 1. Основы технико-экономического анализа.
25
В теории прогнозирования выделяются три класса методов
[36]:
- экспертных оценок - индивидуальных и групповых;
- экстраполяции и расчета по аналогам-прототипам;
- моделирования - логические, математические и информа¬
ционные модели оцениваемых характеристик систем или процес¬
сов.
Эти методы могут быть связаны и при создании конкретных ме¬
тодик прогнозирования в той или иной степени используются их
сочетания. В зависимости от объектов, целей и глубины прогноза по
времени изменяется доминирующий класс используемых методов.
Поэтому, прежде всего, необходимо сформулировать особенности
прогнозирования ТЭП комплексов программ, рассматриваемых в
книге.
Для прогнозирования процессов и технико-экономических
характеристик ПС используются исходные данные двух типов:
характеристики самого прогнозируемого объекта или процесса, для
которого необходимо спланировать жизненный цикл, и характери¬
стики аналогов-прототипов, в некоторой степени подобных плани¬
руемому, о которых известны технико-экономические показатели
уже завершенных аналогичных процессов. Совместная, корректная
обработка исходных данных этих двух типов позволяет получать
новые, прогнозируемые характеристики процессов и ТЭП предпола¬
гаемого жизненного цикла ПС.
Исходные данные первого типа отражают характеристики
конкретного создаваемого объекта или процесса, доступные методы
и средства автоматизации труда при их создании. Эти данные по¬
следовательно детализируются и уточняются в процессе проектиро¬
вания ПС, что, в частности, позволяет уточнять выбор компонентов
аналогичных объектов и их характеристик для описания исходных
Данных второго типа. Этому обычно сопутствует уточнение техно¬
логической среды разработки. В результате у руководителей и ис¬
полнителей проекта ПС появляется возможность формализовать и
Уточнять исходные данные об объекте, процессах и среде разработ¬
ки. Наибольшее влияние на планирование разработок ПС оказыва¬
ют: класс ПС, его размер, связь с реальным масштабом времени и
степень использования готовых апробированных компонентов.
26
Технико-экономическое обоснование проектов.
Второй тип исходных данных для обоснования и планирова¬
ния жизненного цикла ПС составляют обобщенный опыт проекти¬
рования и технико-экономические характеристики прототипов ПС.
Для достоверного планирования и прогнозирования необходимы
накопление, изучение и обобщение конкретных данных о процессах,
использованных ресурсах завершенных разработок ПС в различных
аспектах. Целесообразно, чтобы такие данные регистрировались и
обрабатывались по единой методике в течение всего ЖЦ любых ПС
для формирования представительной базы характеристик предшест¬
вующих разработок на предприятии или в отрасли.
В общем случае для оценки, прогнозирования и обоснования техни¬
ко-экономической эффективности разработки нового комплекса про¬
грамм необходимы исходные данные:
- обобщенные характеристики использованных ресурсов и
технико-экономические показатели завершенных разработок - про¬
тотипов ПС, а также оценки влияния на них различных факторов
объекта и среды разработки;
- реализованные планы и обобщенные перечни выполненных
работ, реальные графики проведенных ранее оценок и разработок
различных ПС;
- цели и содержание частных работ в процессе создания пре¬
дыдущих, сложных комплексов программ и требования к их выпол¬
нению для обеспечения необходимого качества ПС в целом;
- структура и содержание документов, являвшихся результа¬
том выполнения ранее отдельных работ.
Наиболее успешно используются обобщенные ТЭП при более
или менее однородных условиях разработки, которые достаточно
близки к условиям прогнозируемого проекта. Такие ТЭП и факторы,
их определяющие, изучены в процессе обработки значительного
статистического материала реальных отечественных и зарубежных
разработок [2, 13]. Исходные данные о графиках реализации част¬
ных работ при создании прототипов ПС содержатся в некоторых
публикациях об опыте планирования и использования планов работ
при создании ПС различных классов и назначения. Подобные пе¬
речни могут использоваться в качестве проектов предварительных
планов работ по созданию конкретных ПС. Их целесообразно адап¬
тировать в процессе подготовки рабочих планов путем детального
учета конкретных особенностей нового проекта ПС.
fnoea 1. Основы технико-экономического анализа.
27
В настоящее время проявилась необходимость широкого обоб¬
щения накопленных данных и опыта прогнозирования ТЭП различ¬
ных классов ПС. Унификация методик оценки ТЭП, единиц изме¬
рения показателей и методов прогнозирования позволит прибли¬
зиться к созданию нормативной базы, и значительно повысить ши¬
рот)' использования научных прогнозов процессов разработки ПС.
Хотя результаты исследований ТЭП и применения прогнозирования
пока относительно невелики, тем не менее, они способны резко по¬
высить достоверность прогнозов трудоемкости и длительно¬
сти создания ПС по сравнению с экспертными оценками или ин¬
туитивными и директивными решениями заказчиков и руководите¬
лей работ.
Таким образом, возникает дилемма: либо использовать для про¬
гнозирования в качестве исходных, значения ТЭП нескольких самых
последних завершенных разработок, либо привлекать большее число
данных, в том числе в значительной степени устаревших разработок.
В первом случае точность исходных данных обусловлена малой ве¬
личиной выборки, а во втором - влиянием старых разработок, вы¬
полненных при других технологиях и средствах автоматизации. В
обоих случаях необходимо оценивать величину временного интер¬
вала запаздывания опорных данных для прогнозирования, относи¬
тельно начала новой разработки ПС. В первом случае это запазды¬
вание может составлять 3-5 и более лет, а во втором - может быть в
1,5-2 раза больше. Анализ факторов и условий, при которых осуще¬
ствлены ранее выполненные разработки, позволяет уточнять и пере¬
считывать их ТЭП на время начала прогнозируемого проекта. В ре¬
зультате повышается точность оценок для новой разработки. Следо¬
вательно, глубина прогноза и глубина используемых результатов
предшествующих разработок являются важными факторами, влияю¬
щими на достоверность оценок.
Методы прогнозирования ниже базируются на экстраполяции
ТЭП аналогичных завершенных разработок с учетом особенностей
конкретного прогнозируемого объекта. Возможно использование
отдельных отобранных аналогов ПС, наиболее близких к прогнози¬
руемому, или обобщенных характеристик ряда аналогичных завер¬
шенных проектов. Экспертные прогнозы ниже рассматриваются с
Учетом достоверности их результатов, трудностей формализации и
28
Технико-экономическое обоснование проектов.
реальной возможности применения более точных методов. На прак¬
тике планирование разработки многих сложных ПС пока базируется
на экспертных оценках, что часто приводит к значительным ошиб¬
кам.
Методы экспертной оценки [8, 24,27] заключаются в кон¬
сультации с одним или несколькими экспертами, которые проводят
оценку стоимости и других ТЭП нового проекта ПС, используя
свой опыт, интуицию и знание содержания проекта. Эти методы,
несмотря на свои недостатки, удачно дополняют более точные мо¬
дели. Из достоинств экспертных оценок следует отметить возмож¬
ность использования опыта прошлых разработок и их отличия от
новых методов, архитектуры ЭВМ, областей применения, преду¬
смотренных в конкретных проектах. Эксперт может учесть также
индивидуальные возможности коллектива и взаимодействие разра¬
ботчиков или другие уникальные стороны проекта.
К недостаткам экспертной оценки следует отнести ее зависи¬
мость от компетенции и объективности эксперта, который может
оказаться пристрастным, оптимистичным, пессимистичным или
незнакомым с существенными аспектами проекта. Трудно выбрать
золотую середину между быстро полученной оценкой одного экс¬
перта - своевременной, эффективной, но трудно проверяемой и
разумно объяснимой, и строгой, хорошо документированной оцен¬
кой в методе группового согласия - тщательно обоснованной и
проанализированной, но требующей более длительной проработки,
а также трудно повторяемой через некоторое время, особенно когда
спецификации проекта отчасти изменены. Из-за множества различ¬
ных, индивидуальных особенностей экспертов - оптимизма, пес¬
симизма, желания добиться успеха, политических соображений,
предпочтительным является метод оценивания несколькими экс¬
пертами. Существует много путей объединения индивидуальных
оценок в единую - обобщенную. Один путь состоит в получении
средних или срединных оценок. Это быстрый метод, но он может
выдавать не очень точный результат из-за возможности выбросов
значений отдельных оценок. Другой метод состоит в проведении
совещания группы экспертов для формирования единой оценки.
Этот метод имеет общее преимущество отсеивания оценок, связан¬
ных с неосведомленностью, но обладает двумя недостатками. Во-
Глава 1. Основы технико-экономического анализа.
29
первых, одна группа экспертов может повлиять на оценки другой
группы своим красноречием и напористостью. Во-вторых, группа
экспертов может попасть под влияние авторитетной личности или
политической ситуации. Метод «Дельфи» позволяет частично из¬
бежать указанных недостатков.
Ограничения при прогнозировании определяются, прежде все¬
го, имеющимися обработанными данными, которые могут быть ис¬
пользованы в качестве исходных аналогов или обобщенных характе¬
ристик. Одним из основных допущений в книге является предпо¬
ложение о фиксированном и достаточном качестве создававшихся и
создаваемых ПС. Дополнительные затраты на обеспечение повы¬
шенного качества программ учитываются при анализе сложных
ПС СРВ (см. п.4.2). Анализ проводится для ПС в целом или для
крупных этапов работ, и не ставится задача определения нор¬
мативов на конкретные операции при выполнении работ отдель¬
ными специалистами. Предполагается, что разработка ПС про¬
водится при использовании регламентированной технологии
и контроле ее выполнения. При отсутствии такой технологии
прогнозирование ТЭП разработок сложных ПС практически не¬
возможно. В этом случае трудоемкость и длительность разра¬
ботки может возрастать в несколько раз по сравнению с оптими¬
стическими экспертными оценками.
Прогнозирование ТЭП нового ПС в свою очередь требует
некоторых затрат. Они составляют обычно не более 1% общих
затрат на проект, однако всегда эффективны и могут в ряде слу¬
чаев обеспечивать снижение совокупных затрат на разработку на
десятки процентов. Для повышения достоверности прогнозов це¬
лесообразны технико-экономическое сопровождение процесса
разработки ПС и последовательное поэтапное прогнозирование
сроков завершения работ и соответствующих затрат. Управление
процессом разработки ПС на базе фактических затрат на компо¬
ненты и этапы разработки и последовательно уточняемая досто¬
верность прогноза ТЭП позволяют не только снижать затраты на
Данный проект ПС, но и создавать базу аналогов и обобщенных
Данных для достоверного прогнозирования последующих проек¬
тов.
Исходные данные ТЭП и объекта разработки могут разли¬
чаться по полноте и достоверности, особенно в зависимости от
30
Технико-экономическое обоснование проектов..
условий и этапов разработки, что позволяет их разделить на сле¬
дующие группы.
- одиночные аналоги завершенных разработок ПС, харак¬
теристики которых, технология и условия создания достаточно
близки к подобным показателям вновь разрабатываемого ком¬
плекса программ;
- обобщенные ТЭП нескольких в значительной степени по¬
добных разработок ПС, выполненных на одном и том же предпри¬
ятии, при использовании одинаковой технологии и системы авто¬
матизации коллективами специалистов, близкими по квалифика¬
ции;
- обобщенные ТЭП ряда родственных предприятий, соз¬
дающих близкие по классу ПС, с применением собственных тех¬
нологий и систем автоматизации.
Однако большой разброс производительности труда и дру¬
гих ТЭП разных коллективов (см. п. 3.1), а также более или
менее случайный набор усредняемых показателей приводят к
тому, что такую группу данных в большинстве случаев трудно
использовать для прогнозирования ТЭП конкретных новых разра¬
боток. Поэтому ниже предполагается, что обобщенные характери¬
стики ТЭП получены при более или менее однородных условиях
разработки, которые достаточно близки к условиям прогнози¬
руемого проекта. Эти однородные условия наиболее полно со¬
блюдаются в пределах предприятия, однако не исключена возмож¬
ность использования выборочных данных других организаций.
На достоверность прогнозов ТЭП влияет не только точность
сведений о предшествующих разработках, но и достоверность ха¬
рактеристик объекта и условий прогнозируемой разработки. С
учетом этого целесообразно выделить три вида прогнозов технико¬
экономических характеристик разработок ПС:
- первичные оценки трудоемкости и длительности разра¬
ботки при наличии минимально необходимых сведений об объекте
и условиях разработки;
- уточненные оценки полных ТЭП процесса разработки
ПС на базе обобщенных характеристик предшествующих разрабо¬
ток и уточненного сценария объекта и условий разработки;
- текущие прогнозы основных ТЭП на промежуточных
этапах процесса разработки ПС с учетом влияния зарегистриро¬
fjiaea 1. Основы технико-экономического анализа..
31
ванных и обобщенных предшествовавших данных на текущий
момент времени об объекте и условиях разработки и последова¬
тельно уточняющегося прогноза на период до завершения разра¬
ботки.
Последний вид прогнозов предполагает мониторинг и тех¬
нико-экономическое сопровождение процесса разработки. Оно
обеспечивает возможность оперативного перераспределения ре¬
сурсов и управления всей разработкой с целью минимизации за¬
трат или длительности создания ПС. Последовательно уточняю¬
щееся прогнозирование и использование ТЭП в процессе разра¬
ботки является одной из компонентов технологии и должно обес¬
печиваться соответствующими средствами автоматизации. Эти
средства служат для автоматизированной регистрации текущих
затрат на разработку компонентов в различных разрезах и их
обобщения в соответствии с целями прогнозирования и управле¬
ния разработкой. Реализация таких автоматизированных средств
возможна только при достаточных ресурсах используемых ЭВМ и
высоких уровнях (четвертый - пятый) автоматизации технологии
разработки особо сложных ПС (см. п. 4.4). Тесная взаимосвязь
этого вида прогнозирования с технологией разработки и ее авто¬
матизацией приводит к необходимости рассматривать их совме¬
стно, что выходит за пределы основной темы книги.
На этапе создания концепции и системного анализа фор¬
мируются цели разработки проекта ПС, выбираются методы и
алгоритмы решения основных, функциональных задач, а также
формулируются предварительные критерии качества создаваемых
программ. При этом, естественно, встает вопрос о затратах, ко¬
торые потребуются для достижения целей, и о возможности их
минимизации. Опыт и интуиция руководителей разработки позво¬
ляют получить первичные экспертные оценки, принятие которых
За достоверные, приводит зачастую к сложным конфликтам меж¬
ДУ заказчиком и разработчиком. Целенаправленная и методич-
чая экспертная оценка затрат уменьшает величину ошибки, одна¬
ко, обычно она остается все-таки довольно большой. Для обеспе¬
чения рациональной достоверности первичное прогнозирование
Целесообразно проводить путем экстраполяции на базе накоплен-
НЬ|х конкретных данных об отдельных аналогичных предшест¬
вУющих разработках или с использованием обобщенных ТЭП со¬
32
Технико-экономическое обоснование проектов.
вокупности подобных разработок, проведенных на данном пред¬
приятии.
До завершения разработки технического задания на ПС мо¬
гут быть сформулированы только приближенные исходные дан¬
ные, отражающие объект разработки и условия его создания.
Тем не менее, экспертный опрос ведущих специалистов позволяет
составить первичный сценарий или модель объекта и условий
разработки. В этом сценарии фиксируются: класс создаваемого
ПС, предполагаемый его размер, основные особенности техноло¬
гии и оснащенности средствами автоматизации разработки. Да¬
же качественная классификация и описание характеристик сцена¬
рия разработки значительно увеличивает точность прогнозов.
Достаточно достоверное прогнозирование затрат и дли¬
тельности разработки программ возможно только при применении
жестко регламентированной технологии для создания ПС. В этом
случае процесс разработки структурируется на четкие этапы, ко¬
торые характеризуются определенной долей в общих затратах и
сроках. Первый этап системного проектирования, как уже отмеча¬
лось, имеет экспертный характер, может значительно различаться
по трудоемкости в разных проектах. После разработки техниче
ского задания в процессе структурного проектирования и рас¬
пределения ресурсов ЭВМ размер - масштаб программ и ис¬
пользуемой памяти для реализации ПС определяется с точно¬
стью 20-30%, что позволяет значительно повысить достоверность
прогнозирования общих затрат и их составляющих. После выбора
технологии, средств автоматизации разработки и технологических
ЭВМ появляется возможность достоверно учесть эти исходные
данные для подготовки уточненного сценария разработки. Реги¬
страция этих данных может служить дополнительным ориенти¬
ром для оценки полных затрат на разработку. Таким образом,
перед началом наиболее трудоемких этапов создания сложного IIC
могут быть получены достаточно полные исходные данные, кото¬
рые позволяют планировать эти этапы, а также прогнозировать
затраты и длительность их выполнения [2, 13, 40].
Подбор в предшествующих разработках достаточно точною
одиночного аналога для прогноза начатой разработки обычно ма¬
ловероятен вследствие ограниченной базы данных завершенных
fjiaaa 1. Основы технико-экономического анапиза.
33
на предприятии разработок и естественного отставания этих
данных от прогресса в технологии создания программ и характе¬
ристиках ЭВМ. Поэтому уточненные прогнозы целесообразно
осуществлять на основе обобщенных данных совокупности иссле¬
дованных разработок и оценок влияния различных факторов
(см. гл. 3). В этом случае исходные данные могут подготавли¬
ваться в виде двух-трех сценариев разработки с выделением наи¬
более важных и второстепенных факторов. Группа основных ис¬
ходных данных используется для получения прогноза при базовом
сценарии, а второстепенные факторы позволяют уточнять оценки
этого сценария или рассматривать альтернативные варианты (см.
гл. 4).
1.3. Состав затрат в жизненном цикле сложных
программных средств
Затраты в жизненном цикле ПС определяются не только
этапами разработки, но и этапами эксплуатации и сопровож¬
дения. Затраты на этих этапах могут значительно превышать
затраты при разработке и характеризуются своими особыми
закономерностями. Однако эффективность процесса разработки ПС
невозможно определять без учета эффективности последующей
эксплуатации, а для долго используемых программ - без оценга t
эффективности их сопровождения. Ряд факторов влияет на затраты
при разработке сложных ПС не только непосредственно, но и через '
возможное изменение затрат в дальнейшем при сопровождении или
эксплуатации.
Каждый из этапов: разработка, сопровождение и эксплуатация -
может быть достаточно длительным. В пределах этапов различные
группы затрат могут быть неодновременными и разделяться интер¬
валами времени, исчисляемыми годами. Однако, разновременность
затрат трудно учитывать в общем виде, и при существующих
методиках, имеется некоторая условность при оценке влиянии
времени на эквивалентные затраты. Поэтому в данном разделе неод-
иовременность групп затрат не учитывается и предполагается, что
вбсолютная величина и влияние затрат со временем не изменяются.
34
Технико-экономическое обоснование проектов.
Необходимость учета в процессе разработки ПС затрат на всем
жизненном цикле можно наглядно показать на следующих
примерах. Так, при решении комбинаторных задач (например,
математического программирования) очень быстрый рост затрат
машинного времени на решение задач в зависимости от их размер¬
ности привел к невозможности точного их решения при большом
числе переменных путем прямого перебора вариантов. В этом
случае высокие затраты при эксплуатации программ вызвали необ¬
ходимость создания принципиально иных методов их решения, и
значительного повышения затрат при разработке ПС.
\ Системы управления объектами или технологическими процес¬
сами в реальном времени развиваются путем последовательного
расширения и обновления технических средств, являющихся источ¬
никами информации и объектами управления. Соответственно
модернизируются программы управления и обработки инфор¬
мации. Подобные модернизации программ являются основой их
сопровождения в жизненном цикле. Эффективность и минимизация
затрат на сопровождение зависят от структуры и методов разработки
данного ПС. Тщательное системное и структурное проектирование
программ, обеспечение конфигурационного управления, сопряжены
с дополнительными затратами в процессе разработки, однако
позволяют значительно снизить затраты при сопровождении и
суммарные затраты на весь жизненный цикл ПС.]
В ряде случаев, некоторые факторы проектов влияют на
несколько составляющих затрат на этапах жизненного цикла ПС.
изменяя их в различных направлениях. Кроме того, разработку,
эксплуатацию и сопровождение одного и того же ПС зачастую
осуществляют разные коллективы, имеющие различные, иногда
противоречивые интересы. Это значительно затрудняет оптимиза¬
цию совокупных затрат на всем жизненном цикле ПС.^При
разработке конкретных ПС не всегда полностью учитывается
возможность снизить затраты при последующем сопровождении и
эксплуатации. Необходимость выполнять ограниченные сроки
создания ПС иногда приводит к значительному ухудшению егп
эксплуатационных характеристик. Коллективы, осуществляющие
эксплуатацию ПС, могут воздействовать на разработчиков обычно
только после того, как разработка завершена и начаты эксплуатация
и сопровождение. Поэтому для сложных ПС одна-две первые версии
fjiciaa 1. Основы технико-экономического анализа.
35
являются в ряде случаев продолжением разработки и адаптацией
характеристик ПС к конкретным особенностям эксплуатации. Таким
образом, границы между разработкой и сопровождением размыва¬
ются, и начальный период эксплуатации не всегда может быть четко
зафиксирован. Это привело к появлению понятия опытная эксплу¬
атация ПС [6, 48]. Однако £ниже предполагается, что интервал
разработки является фиксированным во времени и завершается
приемкой заказчиком программного продукта. -v
Обычно критерии качества продукции используются в совокуп¬
ности, с разных сторон отражающей основные характеристики
функционирования объекта. Тем не менее во многих случаях/доми¬
нирует экономический эффект, который наиболее просто и обоб¬
щенно принято описывать суммарным доходом Э от использовании
продукта (в данном случае комплекса программ) в течение его
жизненного цикла, продолжительностью 1Ж . Этот доход в первом
приближении можно представить [13, 27] как разность между
полной идеальной эффективностью программ Э0 , и суммарными
потерями и затратами С£, снижающими предельный доход за весь
жизненный цикл (рис. 1.1):
Э — Эд— Cz .
(1.1)
К
36
Технико-экономическое обоснование проектов.
■ В качестве идеальной эффективности Э0 ниже рассматрива-
' ется совокупный доход (эффект) от использования программного
| продукта за весь жизненный цикл, который можно получить, если 1
i бы он не требовал затрат на создание, производство и эксплуатацию.
\ а также ПС функционировало на реализующей ЭВМ без каких-либо :
jjjOTepb и искажений^ В этом показателе сосредоточиваются основ¬
ные, функциональные критерии качества, отражающие назначение. |
область применения и качественные характеристики выполняемых ,
функций комплексом программ. Необходимой идеальной эффектов- |
ности ПС, можно добиться выбором методов управления и обработ- |
ки информации, обеспечивающих экстремальные значения функ- j
циональных критериев качества. Функции ПС реализуются в соот j
ветствии с заданными требованиями, полнота и качество их выпол¬
нения всегда зависят от затрат, которые выделяются на разработку.
Абсолютное значение идеальной эффективности не полностью [
отражает экономический эффект, так как не учитывает затраты, при |
которых достигается заданная эффективность^ Процесс создания и |
использования программ более полно характеризует, величина |
экономической эффективности с учетом совокупных затрат, при J
которых она достигнута. Этот показатель позволяет анализировать j
прирост эффективности на единицу затрат и ограничивать качество
программ при недопустимо больших затратах на их улучшение (см.
рис. 1.1 ).j Для этого эффективность их использования и затраты
необходимо определять в одинаковых или в сопоставимых единицах
измерения, а также иметь функциональные зависимости, связываю
щие затраты и эффективность.
Ниже предполагается, что при любых затратах на разработку
всегда достигаются заданная идеальная эффективность Э0 последу -
ющего применения ПС в процессе его эксплуатации и необходимые
показатели качества функционирования. Это предположение позво¬
ляет в дальнейшем исключить из анализа идеальную эффектив¬
ность применения программных средств Э0 ^сосредоточить внима¬
ние на эффективности процесса их разработки^Дополнительным
обоснованием такого допущения может служйть то, что многие
виды программ невозможно или очень трудно характеризовав’
доходом от их функционирования или непосредственной экономи¬
ческой эффективностью во всем жизненном цикле. В таких случая'
при анализе качества программ невозможно определять изменение
fjiava 1. Основы технико-экономического анализа.
37
экономической эффективности в зависимости от затрат и тем более
целесообразно из анализа исключать характеристики идеальной
экономической эффективности Э0 и сопутствующие ей функцио¬
нальные критерии качества ПС. Тогда исследования эффективности
процесса создания программного продукта можно проводить, мини¬
мизируя затраты С£ в предположении, что обеспечены заданные
функциональные характеристики программ.
Снижение эффективности Э на величину Сг происходит прежде
вс вследствие затрат на разработку, производство, сопровожде¬
ние и э и составляющие тесно связаны
получить высокие эксплуатационные характеристики и обеспечить
эффективное сопровождение. Кроме того, эффективность ПС может
снижаться вследствие потерь различного вида в процессе эксплуата¬
ции программ. Потери эффективности могут происходить в резуль¬
тате сбоев и отказов ЭВМ, неполной отлаженности программ, огра¬
ниченных ресурсов объектных машин по памяти и производитель¬
ности, неэффективной организации вычислительного процесса и т.д.
’ В соответствии с этапами жизненного цикла ПС основные
затраты СЕ , снижающие идеальную эффективность за цикл жизни
t„, можно представить следующими составляющими (см. рис.1.1):
СР — совокупные затраты на разработку программ и обеспе¬
чение решения заданных функциональных задач, в том числе на
технологическое обеспечение и аппаратуру ЭВМ при разработке
ПС, в течение времени tP;
Сс — затраты на сопровождение ПС за время tc, включающие
затраты на хранение и контроль их состояния, проведение модерни¬
заций и исправление ошибок, тиражирование версий и т. д.;
Сэ — затраты на эксплуатацию программ и аппаратные
средства ЭВМ, реализующих ПС, а также совокупные потери эф¬
фективности за время t э , вследствие ограниченных характеристик
ЭВМ и не идеальности программ.
В результате совокупную, реальную эффективность функцио¬
нирования ПС за весь жизненный цикл длительностью tM можно
представить в виде:
между
разработки обычно стремятся
Э = Э0 -СР-Сс-Сэ.
(1.2)
38
Технико-экономическое обоснование проектов.
В зависимости от назначения и области использования
программ экономическую эффективность целесообразно анализиро¬
вать интегрально за весь период жизни, либо дифференциально за
единицу времени (месяц, год).^Для совместного анализа составляю¬
щих, определяющих эффективность, необходимо унифицировать
методы временного анализа и единицы измерения составляющих
затрат. При последующем изложении [затраты рассматриваются на
длительности цикла жизни илр на соответствующих интервалах
времени: разработки, эксплуатации и сопровождения.I
Как уже отмечалось, разработка сложного ПС требует во много
раз больших затрат, чем производство каждого экземпляра при
массовом тиражировании. Поэтому далее производство опытного
образца программ не выделяется в самостоятельный этап, а рассмат¬
ривается совместно с процессом разработки ПС. Производство
серийных образцов программного продукта включается в этап
эксплуатации. Экономическая эффективность разработки и распре¬
деление ресурсов на ее выполнение могут значительно изменяться в
зависимости от того, является ПС уникальным или будет изготовлен
в сотнях экземпляров. Это обстоятельство привело к целесо¬
образности оценки затрат на разработку ПС не только в абсолютных
значениях для опытного образца, но и в относительных величинах
доли затрат на программы в каждом экземпляре реализующей ЭВМ
при серийном производстве систем.
j При выделении составляющих затрат на разработку
программ целесообразно учитывать их относительный вес в суммар
ных затратах/и возможность локализации групп специалистов, опре¬
деляющих величину этих затрат., Разработка программ является
областью с малой материало- и энергоемкостью, и основные затраты
связаны с непосредственным или овеществленным трудом специа¬
листов различных категорий. Поэтому для измерения затрат наибо¬
лее универсальной единицей стала трудоемкость в человеко-месяцах
или человеко-годах. При этом учитываются все категории специа¬
листов, участвующих непосредственно или косвенно в создании
данного ПС.
Затраты на непосредственную разработку комплекса
программ - Ср являются важнейшей составляющей в жизненном
цикле ПС (рис. 1,2).^Однако эти затраты не всегда являются домини¬
рующими по величине.
Состав затрат в жизненном цикле программных средств
Глава
1. Основы технико-экономического анализа... 39
и
а
Рм
Su
* С
■ »
о ■
и
Е
I Р
s £
3 Е
11
И
■в- в
ж V
£ *
1 3
о в
2 *
* g
5 =
S в
л s
п
*х ■
2 s.
Is
А §
1
I !
I
11:
а о
? I
*
S'
40
Технико-экономическое обоснование проектов.
I Для относительно небольших I1C, с малым жизненным циклом,
/доля этих затрат может достигать 70 - 90%/ Для сложных ПС,
предназначенных для длительного массового использования, и
разрабатываемых на базе высокоавтоматизированной технологии,
доля этой группы затрат составляет только 20 - 30% всех затрат на
этапе разработки. Тем не менее,jjCp является по смыслу наиболее
существенной составляющей, определяющей непосредственное
создание функциональной части программных средств [13]. —
Абсолютная величина Ср , так же как и длительность разработ¬
ки, зависит от многих факторов, которые могут изменять их в раз
личных направлениях. Наибольшее влияние на них оказываез
.размер ПС^соторый из всех параметров изменяется в самом широ¬
ком диапазоне и_в современных разработках варьируется на три
четыре порядка. Поэтому при оценке непосредственных затрат и
длительности полного цикла разработки сложных ПС, размер
программ используется в качестве базового доминирующего па¬
раметра. Остальные факторы можно отражать поправочными коэф
фициентами при уточнении интегральных показателей.^Непосреда -
венные затраты на разработку можно представить как частное oi
размера ПС и производительности труда, корректируемое произве¬
дением коэффициентов изменения трудоемкости (КИТ) (см. п. ЗА).
При этом следует учитывать, что коэффициенты могут иметь между
собой сильную положительную или отрицательную корреляции',
которая значительно изменяет их произведение. Детальный анализ
Ср и соответствующих КИТ проводится в главе 3.
Затраты на изготовление опытного образца ПС как
продукции определяются необходимостью обеспечить отчужде¬
ние всего комплекса программ от его первичных непосредственных
разработчиков. Удельный вес этих затрат редко превышает 20% и
обычно находится в пределах 10 - 15% общих затрат на разработку
Возрастание этой группы затрат происходит, если ПС предстой i |
длительный жизненный цикл и массовое тиражирование. Для изго¬
товления ПС как продукции необходимо: изготовить и оформи п>
опытный образец на носителях данных как промышленное изделие:
разработать комплект документации, обеспечивающей квалифици¬
рованную эксплуатацию ПС и его развитие в жизненном цикле.
fjiaea 1. Основы технико-экономического анализа.
41
Затраты на изготовление носителей программ опытного образца
ПС, пригодного для серийного тиражирования и применения раз¬
личными пользователями, зависят практически только от типа носи¬
телей программ, чаще всего магнитных или лазерных дисков. В эту
составляющую входят затраты на копирование и сборку программ¬
ных компонентов, на контроль и оформление носителей, включаю¬
щее маркировку и приемку техническим контролем полного комп¬
лекта образца программного средства. При разработке сложных ПС
эти затраты, находятся на уровне процента и при оценке полных
затрач не всегда учитываются отдельно.
, Как уже отмечалось выше, базовые затраты на разработку ос¬
новных функций программных средств следует измерять по пол¬
ному циклу создания сложного ПС от подготовки контракта и тех¬
нического задания до завершения успешных испытаний и приемки
заказчиком с учетом всех основных и вспомогательных работ. Эти
интегральные затраты в наибольшей степени определяются разме¬
ром и сложностью комплекса программ и его базы данных, а также
долей использования готовых программных компонентов. Хотя эти
характеристики не выделены в составе утвержденных стандартами и
только условно их можно отнести к качеству ПС, их значительное
влияние на затраты при разработке комплексов программ приводит
к необходимости их учета при анализе всей совокупности характе¬
ристик качества программного продукта (см. гл. 4). Остальные фак¬
торы, отражающие дополнительные затраты на удовлетворение
требований к характеристикам качества, можно учитывать попра¬
вочными коэффициентами при уточнении интегральных затрат на
функциональную пригодность. Для учета влияния различных фак¬
торов удобно пользоваться коэффициентами (рейтингами) измене¬
ния трудоемкости (КИТ), учитывающими зависимость каждой со¬
ставляющей совокупных затрат от значений требований к соответст¬
вующей характеристике качества [2, 13, 30].
Имеющийся опыт показывает, что кроме размера ПС и повтор¬
ного использования компонентов, большинство факторов может из¬
менять трудоемкость процессов разработки программ на десятки
процентов и не более чем в 1,5-2 раза. Приводимые ниже эксперт¬
ные оценки этих коэффициентов, относятся к разработке полностью
Нового, крупномасштабного ПС, первоначально без повторного ис¬
пользования готовых программных компонентов. Эти оценки могут
42 Технико-экономическое обоснование проектов.
1
служить ориентирами, которые должны напоминать разработчи¬
кам, что каждое повышение требований к качеству ПС реализуемо
за счет дополнительных ресурсов, которые могут быть соизмери¬
мыми или даже превышать затраты на решение основных, функцио¬
нальных задач.
Основные составляющие дополнительных затрат, обеспечи¬
вающие требуемые характеристики качества ПС целесообразно
структурировать в соответствии с их номенклатурой в стандарте
ISO 9126 (см. гл. 4 и Приложение 1). Однако желательно эти затраты
связывать с процессами ЖЦ ПС. Важнейшее значение имеет уста¬
новление и формализация исходных требований к характеристикам
качества ПС. Поэтому целесообразно выделять затраты на сис¬
темный анализ, концепцию и проектирование требований ко
всему комплексу характеристик и их атрибуты качества на начапь-
ных этапах проекта ПС (см. рис. 1.2). На этих этапах неопределен¬
ность оценки влияния факторов наибольшая, тем не менее даже
приблизительный их учет позволяет избегать грубых ошибок (в не
сколько раз) при оценке затрат на разработку, которые делаются
экспертами зачастую без детального анализа влияния различных
факторов на требуемое качество ПС. Подобный анализ может быть
базой для рационального, первичного распределения ограниченных
ресурсов разработки и для управления их использованием по мере
развития проекта. Учет возможного изменения затрат в зависимости
от основных параметров проекта способствует упорядочению про¬
цесса разработки ПС и концентрации усилий на тех факторах и за¬
тратах, которые могут дать максимальный эффект в повышении ка¬
чества, при конкретных условиях создания программ и реальных
ограничениях ресурсов.
После проведения системного проектирования, а также предва¬
рительного распределения ресурсов, возможна ошибка в оценке со¬
вокупных затрат на разработку ПС с требуемым качеством, прибли¬
зительно в полтора-два раза. Разработка архитектуры комплекса
программ на основе прототипов и подготовка к программированию
готовых апробированных алгоритмов позволяет ее уменьшить до 20¬
30%. Такую достоверность можно получить, конечно, только при
подробном анализе и оценке влияния важнейших факторов и требо¬
ваний к качеству конкретного ПС.
fjiaea 1- Основы технико-экономического анализа.
43
В современных проектах ПС большую или меньшую долю со¬
ставляют готовые апробированные компоненты из других подоб¬
ных разработок - прототипы и/или покупные пакеты прикладных
программ. Это позволяет значительно ускорять работы и сокращать
затраты на создание сложных комплексов программ. Перед разра¬
ботчиками проекта ПС зачастую возникает дилемма: разрабатывать
ли весь комплекс программ полностью из новых компонентов или
использовать, адаптировать и приспосабливать готовые компонен¬
ты, какие и в каком количестве. В результате при первичном эконо¬
мическом анализе затрат на создание ПС с требуемыми характери¬
стиками качества, целесообразно рассматривать два альтернатив¬
ных варианта затрат на разработку архитектуры и компонен¬
тов ПС'.
- полностью нового ПС, для которого отсутствуют или не¬
доступны подходящие готовые компоненты - прототипы и/или их
заведомо нерентабельно использовать;
- программного средства на базе комплексирования набора
готовых программных компонентов и информации баз данных, для
которого почти не требуется создания новых компонентов.
Затраты для повторного использования и переноса программ и
данных на иные аппаратные и операционные платформы включают
адаптируемость, установку и замещаемость программ, которые це¬
лесообразно оценивать количественно', совокупными затратами
(стоимостью, трудоемкостью и длительностью) на реализацию про¬
цедур переноса программ и данных. Оценки мобильности зависят не
только от внутренних субхарактеристик ПС, но также от организа¬
ции, технологии и документирования реализации жизненного цикла
и процессов переноса комплексов программ и их компонентов. Ре¬
сурсы требуются в той или иной степени для двух этапов процессов
переноса программ и данных на иные платформы или в аналогич¬
ные проекты [4, 14, 45]:
- при создании потенциально переносимых ПС и БД, когда
свойства эффективной мобильности предусматриваются при их пер-
в°начальной разработке, учитываются возможные платформы и об¬
ласти повторного использования таких программ и данных;
■ при непосредственной реализации (с соответствующими за¬
катами) процессов переноса ПС и БД, в различной степени подго-
т°вленных при проектировании для переноса на иные платформы
44
Технико-экономическое обоснование проектов.
и/или для повторного использования компонентов на той же плат¬
форме в аналогичном проекте.
При оценивании затрат первого этапа следует учитывать, что к
настоящему времени накоплен большой объем прикладных про¬
грамм и информации в базах данных, при создании которых не учи¬
тывалась возможность их последующего переноса на иные платфор¬
мы - так называемые «унаследованные» системы. Более того, в ряде
случаев из-за ограниченных ресурсов вычислительных средств при
реализации крупных функциональных задач, программы и данные в
таких системах в максимальной степени адаптировались при разра¬
ботке к особенностям и параметрам ЭВМ для эффективного исполь¬
зования их ресурсов. В зависимости от степени совместимости меж
ду аппаратными и операционными платформами соответствующих
ЭВМ возможны различные условия мобильности - полной или час¬
тичной несовместимости платформ, программных интерфейсов, язы¬
ков программирования или диалектов одного языка и других пара¬
метров.
При повторном использовании и переносе программ и данных
свойства системы практически всегда изменяются, что следует учи¬
тывать при системном анализе целесообразности и эффективности
переноса, а также могут быть необходимы тестирование, испытания
и сертификация получаемых ПС в новой среде. Кроме того, любой
перенос связан с затратами, которые требуются для:
- системного анализа рентабельности переноса на иную или
ту же платформу и оценки технико-экономических показателей этого
процесса;
- реализации самого процесса переноса и интеграции с опе¬
рационной и внешней средой на новой аппаратной платформе или в
существующей среде;
- испытаний и необходимой проверки функционирования ПС
в новом окружении или на новой платформе;
- корректировки или дополнения эксплуатационной и техно¬
логической документации.
При создании ПС трудно предусмотреть все возможные особен¬
ности и различия платформ и внешней среды, для которых деклари¬
руется возможность повторного использования конкретных компо¬
нентов и программных средств. Эти особенности и возможное рнс'
fjiaeu 1. Основы технико-экономического анализа.
45
прение свойств окружающих прикладных программ и данных мо-
jyr преподносить неприятные сюрпризы нестыковки, для ликви¬
дации которых потребуются дополнительные ресурсы. Требования
^обильности компонентов ПС приводят к необходимости их проек¬
тирования как автономных комплектующих изделий. Это реализует¬
ся за счет стандартизации их построения и организации интерфей¬
сов, унификации структуры базы данных и гарантии качества функ¬
ционирования. В результате подготавливается возможность создания
новых ПС из набора готовых программных модулей или функцио¬
нальных групп программ, ранее использованных и испытанных в
другом сочетании при решении несколько иных функциональных
задач. Однако в любом комплексе программ вряд ли возможно и
нужно повторно использовать все 100% готовых программных мо¬
дулей. При сборке нового ПС из комплектующих компонентов, мо¬
жет потребоваться доработка некоторых из них, или создание специ¬
альных программ, для организации их взаимодействия.
В ряде случаев может быть целесообразна настройка (адапта¬
ция) готовых компонентов на новые условия применения. При
больших изменениях условий применения, эффективной может ока¬
заться сборка нового ПС с частичным использованием апробирован¬
ных компонентов и с разработкой небольшой части программных
модулей, обеспечивающих новые функции, интерфейсы и условия
применения ПС. При этом относительное снижение затрат пропор¬
ционально доле использования готовых комплектующих компонен¬
тов и степени их пригодности для использования в новом ПС. В
пределе при построении нового ПС на 80 - 90% из готовых компо¬
нентов, суммарные затраты могут сокращаться в 3 - 5 раз. В этом
случае, кроме 10 - 20% затрат на создание новых программных
компонентов, необходимы ресурсы на комплексирование нового
ПС, его квалификационное тестирования, испытания и доку¬
ментирование.
Практически всегда необходимо время и трудоемкость на сис¬
темный анализ, и оценивание целесообразности разработки ком-
г,лекса программ из готовых компонентов с учетом стоимости
"Риобретения и адаптации переносимых программ. Интегрирование
компонентов в новой операционной среде, тестирование и испыта¬
НИя в комплексе с унаследованными программами, также почти все¬
46
Технико-экономическое обоснование проектов...
гда требует времени и других ресурсов. Некоторые, казалось бы.
второстепенные, детали и факторы несовместимости готовых, пере¬
носимых программ и новой платформы могут заметно отражаться на
трудоемкости проекта. Особенно тщательно их следует анализиро¬
вать в унаследованных системах, в которых относительно мелкие
детали взаимодействия новых и старых программ могут существен¬
но влиять на дополнительные затраты и экономические характери¬
стики проекта.
Затраты на обеспечение корректности комплекса программ
зависят от полноты прослеживания реализации требований к Г 1C
сверху вниз, в требованиях к компонентам вплоть до объектного
кода программ и от степени их покрытия тестами. Эти затраты вхо¬
дят непосредственно в процесс разработки и зависят от объема и
детальности процессов верификации и тестирования. Для слож¬
ных ПС при требовании их высокой корректности, они могут со¬
ставлять до 30% от затрат на обеспечение первичной, функциональ¬
ной пригодности. Для относительно простых комплексов программ
эта величина в среднем не превышает 20%. Эти затраты приходятся
на верификацию и тестирование программных компонентов, что
должно обеспечивать корректность, безопасность и надежность ПС
в целом. Хотя характеристики и их атрибуты принципиально разли¬
чаются, затраты на их реализацию полностью разделить невозмож¬
но. Поэтому оценивание и выделение ресурсов на решение этих за¬
дач целесообразно анализировать совместно (см. рис. 1.2).
Затраты на квалификационное тестирование и испытания
ПС в целом обычно могут быть достаточно четко выделены из ос¬
тальных затрат, так как в этих процессах непосредственно участву¬
ют заказчик и пользователи. Величина этих затрат, без учета ресур¬
сов, необходимых для имитации внешней среды, может составлять
около 10% от общих затрат на разработку. При этом практически
невозможно разделять затраты на оценивание отдельных стандарти¬
зированных характеристик и их атрибутов.
Затраты на обеспечение безопасности и надежности функ¬
ционирования Г1С определяются требуемым уровнем защищенности
и сложностью (размером) программ для ее реализации. При наличии
особенно высоких требований к безопасности критических ПС эти
затраты могут даже в 2 - 3 раза превышать затраты на решение ба¬
зовых, функциональных задач. Для типовых административных сис¬
рлава l- Основы технико-экономического анализа.
47
тем трудоемкость создания программных средств защиты обычно
составляет 20 — 40% затрат на решение основных, функциональных
задач. В более простых случаях, доля таких затрат может снижаться
до 5 - 10%. Затраты на обеспечение высокой надежности ПС близ¬
ки к затратам на обеспечение безопасности, и в составе разработки
ПС могут достигать 2-3 кратного увеличения затрат, при требова¬
ниях наработки на отказ в десятки тысяч часов, а для минимального
обеспечения автоматического рестарта в ординарных системах со¬
ставляют порядка 10 - 20%. Однако практически, в любых системах
должен присутствовать минимум программных компонентов, обес¬
печивающих надежность и защиту от преднамеренных и случайных
угроз.
Затраты на создание достаточно полного комплекта докумен¬
тации практически пропорциональны размеру комплекса программ.
Удельные затраты на документацию зависят от класса, назначения и
широты применения программ, что трудно учесть в достаточно
общем виде. Эти затраты сопутствуют в некоторой степени всем
этапам разработки, однако, оформление эксплуатационных докумен¬
тов обычно локализуется в специальном этапе работ. Затраты на
разработку комплекта эксплуатационной документации для слож¬
ных ПС на уровне продукции, подлежащей длительному сопровож¬
дению, обычно определяются затратами на объем текста документов
ориентировочно 5-10 страниц на тысячу строк программы на
ассемблере.
В технологической документации, обеспечивающей конфигу¬
рационное управление и многолетнее сопровождение, необходимы
тексты программ и описания алгоритмов. Это приводит к увели¬
чению объема документации на порядок, т.е. может составлять
около 100 страниц совокупности документов на тысячу строк
программы. Статистический анализ объема документации для ПС
Различных классов дал [15, 27] широкий разброс числа страниц на
еДиницу объема программ. Однако выявились некоторые средние
Характеристики, которые близки к указанным выше. Подтверждена
наиболее высокая документированность тиражируемых программ
Реального времени, особенно в тех случаях, когда необходима
вЫсокая безопасность и надежность функционирования ПС (до 200
Страниц на тысячу строк).
48
Технико-экономическое обоснование проектов.
При оценках реально предполагать средний объем технологи¬
ческой документации — 50 — 100 страниц на тысячу строк. При этом
затраты на документацию остаются практически пропорциональ¬
ными размеру ПС. Эта часть документации не подлежит массовому
тиражированию и поставке каждому пользователю, что позволяем
несколько снижать удельные затраты на ее подготовку. Однако
необходимость ее тщательной отработки и высокого соответствия
текущей версии программного продукта приводит к большим
затратам, как при первичном изготовлении технологических доку¬
ментов, так и при их модификации в процессе последующего
сопровождения ПС.
Разработка документации на программы является творческим
процессом, что значительно усложняет оценку его удельной трудо¬
емкости на страницу. Кроме того, ряд документов (спецификации,
тесты, тексты программ) разрабатывается в процессе создания ПС и
их трудно выделить как самостоятельные работы. Только около
половины работ можно достаточно четко регламентировать (редак¬
тирование, печать, нормоконтроль, утверждение и т.д.). Эти обстоя¬
тельства привели к большому различию суммарных удельных затра!
на страницу документов.
Затраты на имитацию внешней среды и на генерацию тес¬
тов для обеспечения качества программных средств могут быть од¬
ной из существенных составляющих при создании крупномасштаб¬
ных ПС. В ряде случаев, они соизмеримы с затратами на создание
основных функций комплексов программ, что определяется прин¬
ципиальным соответствием сложности необходимых наборов тес¬
тов и тестового покрытия программ, и сложности функций, реа¬
лизуемых испытываемым ПС. Создание представительных совою п-
ностей тестов возможно путем использования реальных объектов
внешней среды или с помощью программных имитаторов, адекван
ных этим объектам по результатам функционирования и генерир>е'-
мой информации. При этом возникает проблема - какой метод и ко¬
гда выгодней по затратам на генерацию тестов и по обеспечению
необходимой степени покрытия тестами испытываемых ПС (сМ
п.4.4).
Имитаторы тестов необходимы не только для оценивания Д01-'
тигнутых характеристик качества комплексов программ, но так*1
для их комплексной отладки, квалификационного тестирования. i|1
fjiaeu 1. Основы технико-экономического анализа.
49
питаний и при создания версий. Поэтому затраты на программные
рмитаторы и их экономическую эффективность целесообразно рас¬
сматривать в проекте с учетом всего комплекса задач, которые они
способны и должны решать в ЖЦ ПС. Анализ эффективности про¬
граммной имитации внешней среды при разработке и определении
качества ПС целесообразно разделять на две части: оценка факто¬
ров, определяющих эффективность средств имитации тестов, и
оценка экономического выигрыша при моделировании внешней
среды на ЭВМ по сравнению с натурными экспериментами в реаль¬
ных системах [8, 26, 46].
Факторы, определяющие эффективность программной ими¬
тации внешней среды на ЭВМ при разработке ПС, могут оцени¬
ваться в основном по их воздействию на качество создаваемых про¬
грамм. Это влияние трудно непосредственно измерить, однако каче¬
ственный анализ показывает, что автоматизированная имитация тес¬
тов может значительно изменять не только достигаемые характери¬
стики качества разрабатываемого ПС, но также трудоемкость и дли¬
тельность его создания. Программная имитация внешней среды на
ЭВМ может обеспечивать широкие наборы тестов и достаточно
полные тестовые покрытия ПС и компонентов при испытаниях, в
том числе за пределами характеристик реально существующих или
дфступных источников тестов, а также соответствующие критиче¬
ским или опасным ситуациям функционирования объектов внешней
среды. Для каждого параметра, отражающего внешнюю среду, от¬
ношение диапазона или числа тестов, возможных при программной
имитации на ЭВМ по сравнению с натурными экспериментами, мо¬
жет служить оценкой величины, возрастания достоверности опреде¬
ления характеристик качества ПС.
Некоторые значения тестов не только трудно создать при на¬
турных экспериментах, но они являются маловероятными в реаль¬
ных условиях. Однако такие, даже маловероятные ситуации и зна¬
чения тестов могут быть критическими и/или особо важными для
Функционирования всей системы, для которой разрабатывается ПС.
Выбор и имитация подобных ситуаций позволяют отрабатывать и
°Ценивать качество ПС в критических маловероятных ситуациях,
к°торые невозможно или опасно создавать на реальных объектах, но
без их выполнения некоторые ПС не допустимо эксплуатировать в
критических системах управления и обработки информации.
50 Технико-экономическое обоснование проектов..
Экономическую эффективность программной имитации i
внешней среды на ЭВМ по сравнению с натурными экспериментами I
целесообразно оценивать при одинаковых объемах тестовых данных |
для испытаний и определения качества ПС. Показателем экономиче
ской эффективности имитации может служить соотношение за¬
трат на проведение натурных экспериментов и затрат на про¬
граммную имитацию той же совокупности тестовых и эталонных
данных. Затраты ресурсов на натурные эксперименты для генерации
тестов при проведении разработки, испытаний и определения каче
ства пропорциональны реальному времени функционирования про¬
веряемого ПС и затратам на применение привлекаемых средств ре¬
альной внешней среды. Они включают стоимость эксплуатации ре¬
ального объекта, создающего тесты в единицу времени (например,
затраты на функционирование административной системы, прокат¬
ного стана или системы управления воздушным движением и всех
управляемых ею объектов). Таким образом, затраты на натурные
эксперименты для оценивания характеристик ПС определяются ис¬
пользованием всей реальной внешней среды, в которой предстоит в
дальнейшем функционировать программам, а также затратами на
средства измерения характеристик этой среды и проверяемого ПС в
процессе разработки, испытаний и определения качества.
Затраты на программную имитацию тестовых данных оп¬
ределяются ресурсами необходимыми на проектирование и эксплуа¬
тацию сложных комплексов программ для этих целей. Имитацион¬
ные стенды практически всегда являются уникальными и достаточ¬
но полно используют ресурсы моделирующей ЭВМ. В ряде случаев
эти комплексы программ могут иметь объем порядка 104 - 106 строк
текста и должны создаваться с применением современных техноло¬
гических систем. Затраты на эксплуатацию программ имитации в
основном определяются длительностью проведения тестирования,
испытаний и/или измерения характеристик качества ПС. Значения
этого времени соответствуют реальному времени генерации тесто¬
вых данных и тестирования программ. Затраты на эксплуатант0
ЭВМ, используемую в моделирующем имитационном стенда
(МИС), включают: первичные затраты на закупку и установку обо¬
рудования, необходимого для имитации тестовых данных, стои¬
мость имитирующей ЭВМ и устройств сопряжения имитационно'0
стенда с ЭВМ, на которой функционируют тестируемые программ'*1
fjiaea 1. Основы технико-экономического анализа.
51
Даже приближенные оценки при системном анализе соотноше¬
ния этих затрат в большинстве случаев показывают высокую рен¬
табельность программных имитаторов внешней среды, особен¬
но для квалификационного тестирования и оценивания характери¬
стик качества крупномасштабных ПС реального времени. Например,
при тестировании ПС для управления воздушным движением, при¬
менение имитационных стендов, по крайней мере, на порядок сни¬
жает затраты по сравнению с натурными экспериментами и исполь¬
зованием реальных объектов (самолетов), а для управления косми¬
ческими аппаратами или атомными электростанциями это соотно¬
шение может быть значительно больше (— 10 — 100). При создании и
определении качества административных систем с полной загруз¬
кой, имитация способна заменить сложную организацию функцио¬
нирования по определенной программе большого коллектива опера¬
торов банка, налоговой инспекции или таможенного органа.
Затраты на сопровождение ПС можно оценивать потребно¬
стью трудовых и временных ресурсов для его обеспечения и для
реализации. Эти затраты состоят из двух связанных частей: затрат
на реализацию соответствующих характеристик качества, обеспе¬
чивающих эффективное сопровождение программных продуктов, и
затрат при использовании этих характеристик в процессе эксплуа¬
тации комплекса программ. Обычно совершенствование качества и
повышение затрат на реализацию характеристик способствует сни¬
жению затрат при их эксплуатации. Последние трудно оценить ап¬
риори, так как они зависят от внешней среды и активности приме¬
нения конкретного ПС, а не от его свойств и требуемого качества.
(По некоторым оценкам количество специалистов, участвующих в
сопровождении на расширении функциональности и улучшении ка¬
чества ПС (~ 40%) и на устранении дефектов (~ 15%), что превышает
количество специалистов занятых созданием новых программ
М5%) [27].
Возможные затраты на развитие и совершенствование качества
комплекса программ зависят не только от внутренних свойств про¬
грамм, но также от запросов и потребностей пользователей на но-
8ь,е функции и от готовности заказчика и разработчика удовлетво¬
рить эти потребности. Величина этих затрат определяется рыночной
конъюнктурой для данного программного продукта и коммерческой
52
Технико-экономическое обоснование проектов.
целесообразностью его модификации и развития. По объему пред¬
полагаемых изменений, а также вновь вводимых в очередную вер¬
сию компонентов с учетом сложности и новизны их разработки мо¬
гут быть оценены затраты на их создание [26, 41, 48].
Стоимость и длительность сопровождения компонентов или
комплекса программ может определяться контрактом между заказ¬
чиком и поставщиком по прецедентам аналогичных проектов с уче¬
том изменяющейся конъюнктуры. Затраты на обеспечение и реали¬
зацию сопровождения программ определяются длительностью цик¬
ла жизни комплекса программ; его мобильностью, уровнем автома¬
тизации технологии разработки и тиражом программ. Для их оцени¬
вания, прежде всего, необходимо выделять основные виды затра!
при сопровождении конкретного комплекса программ и наиболее
существенные факторы, которые на них влияют. Такой анализ мо¬
жет дать ориентиры для прогнозирования общих затрат на со¬
провождение и для оценивания этой характеристики в конкретных
проектах ПС. При этом важно учитывать соотношение затрат на
разработку и на сопровождение в течение цикла жизни всего тира¬
жа ПС.
Уникальное, заказное ПС, основная часть жизненного цикла ко¬
торого приходится на разработку, может создаваться почти без уче¬
та последующих затрат на сопровождение. Однако многократно мо¬
дернизируемые и широко тиражируемые ПС требуют больших за¬
трат на сопровождение. Вследствие длительного срока сопровожде¬
ния и эксплуатации (в ряде случаев до 10 лет), а также большого
числа версий, содержащих результаты модернизаций, совокупные
затраты на сопровождение в некоторых случаях значительно пре¬
вышают затраты на первичную разработку программ. Эти затраты
распределяются по всему интервалу времени сопровождения, вслед¬
ствие чего при подготовке каждой версии затраты обычно меньше,
чем на первичную разработку Г1С. Длительное сопровождение ино¬
гда вызывает неоднократную смену специалистов, осуществляют^
сопровождение. При таких заменах появляются значительные за¬
траты на обучение новой группы сопровождения, что вызывас
рост общих затрат. Сокращение затрат на сопровождение возможно
за счет некоторого увеличения затрат при разработке ПС, так что
при рациональном проектировании в сумме затраты могут бьпь
уменьшены иногда весьма заметно.
fjiaea 1. Основы технико-экономического анализа.
53
При системном анализе затраты на сопровождение можно счи¬
тать аддитивными и включающими составляющие:
- затраты на обнаружение и устранение ошибок и дефектов в
каждой версии ПС;
- затраты на доработку и совершенствование программ, фор¬
мирование и испытание новых модернизированных версий ПС;
- затраты на конфигурационное управление, тиражирование
каждой новой версии и ее внедрение в эксплуатируемых и новых
системах.
Доля каждой составляющей в общих затратах на сопровожде¬
ние может значительно изменяться в зависимости от особенностей
сферы применения и жизненного цикла конкретного ПС. Для дол¬
гоживущих (~10 лет), тиражируемых (1000 - 100000 экземпляров)
ПС доминирующими обычно являются затраты на модернизацию и
доработку версий программ. Затраты на модернизацию зависят от
*тиража косвенно, вследствие расширения условий применения кон¬
кретного ПС и увеличения потока запросов пользователей на разви¬
тие программ. Так же косвенно влияет тираж на запросы для устра¬
нения выявленных ошибок.
Затраты на обнаружение и устранение дефектов и ошибок
в программе определяются двумя факторами: затратами на обнару¬
жение каждой ошибки и затратами на устранение выявленных оши¬
бок при формировании очередной версии. Чем меньше ошибок в
программе, тем труднее они обнаруживаются, т.е. тем выше затраты
на выявление каждой ошибки. Затраты на устранение ошибок и кор¬
ректировку программ пропорциональны числу дефектов, выявлен¬
ных между очередными версиями. При сопровождении непрерывно
Требуются затраты для контроля состояния версий программ и обес¬
печения их сохранности. По опыту работ, широко тиражируемый
комплекс программ объемом ~105 строк, может требовать непре¬
рывных усилий коллектива в составе десятка и более специалистов
Для устранения ошибок, корректировок версий и документации [11,
26].
Затраты на совершенствование и модернизацию программ
близки по содержанию (но не по величине) к затратам на их первич¬
ную разработку. Модернизация обычно производится поэтапно. Для
каждой новой эталонной версии изменяется (разрабатывается) толь¬
ко некоторая часть от всего объема ПС. Эта часть при вводе очеред¬
54
Технико-экономическое обоснование проектов.
ной версии может составлять 10 - 20% от объема всего комплекса
[11]. Сложность связей в ПС приводит к тому, что удельные затраты
на изменяемые программы, при модернизации каждой версии могут
быть в 2 - 3 раза больше, чем затраты на создание программ такого
же объема при первичном проектировании. Эта величина зависит от
того, насколько при системном проектировании путем стандартиза¬
ции архитектуры и интерфейсов, предусматривались перспективы
совершенствования ПС. Для выполнения этих работ иногда исполь¬
зуется коллектив специалистов, осуществивших первичную разра¬
ботку. Такая организация наиболее характерна для уникальных, за¬
казных ПС. В этих случаях первичную разработку и модернизацию
трудно разделить. Для широко тиражируемых ПС, на сопровожде¬
ние часто выделяется специальный коллектив, не проводивший пер¬
вичную разработку. В этих случаях этапы разработки и сопровожде¬
ния, а также сопутствующие им затраты можно разделить более чет¬
ко.
Затраты на конфигурационное управление и тиражирова¬
ние каждой новой версии включают совокупные затраты на произ¬
водство экземпляров ПС, их инсталляцию в объектных ЭВМ и ос¬
воение для нормальной эксплуатации. Затраты на тиражирование
версий при сопровождении практически пропорциональны произве¬
дению числа версий и их тиража. Вследствие этого даже относи¬
тельно малые затраты на каждый экземпляр при внедрении новой
версии могут приобретать большое значение в жизненном цикле
всей серии версий ПС.
Обычно наиболее важным для реализации проекта ПС и зави¬
сящим от большинства его особенностей и факторов является тру¬
доемкость, непосредственно определяющая стоимость созда¬
ваемого комплекса программ. Значения длительности разработки и
числа специалистов взаимосвязаны и в некоторых пределах могут
размениваться. Поэтому оценки этих показателей затрат можно
варьировать, и при недостаточном числе специалистов естественно
возрастает длительность разработки, хотя трудоемкость может ос¬
таться практически неизменной. Многократное применение одних и
тех же апробированных компонентов и/или многократная адаптация
ПС к различным условиям применения является одним из перспек¬
тивных методов повышения качества и снижения затрат тру¬
fjiaea 1. Основы технико-экономического анализа.
55
да специалистов в жизненном цикле крупномасштабных комплек¬
сов программ.
На рис. 1.2 отражены затраты на технологию, инструменталь¬
ные средства автоматизации разработки и ЖЦ ПС, а также затраты
на аппаратуру вычислительных систем, необходимую при обеспече¬
нии жизненного цикла комплексов программ. Эти затраты только
обозначены в данном разделе, а их описания и оценки отнесены в
главу 4.
1,4. Риски при технико-экономическом обосновании проектов
программных средств
К понятию риски относятся события и их величины, отражаю¬
щие потери, убытки или ущерб от процессов или продуктов, вы¬
званные неправильными или неточными решениями при проектиро¬
вании требований, технико-экономическом обосновании проектов
ПС, а также при последующих этапах разработки, реализации и все¬
го жизненного цикла комплексов программ. Риски проявляются как
негативные последствия функционирования ПС (дефекты функцио¬
нальной пригодности системы), в результате отклонений характе¬
ристик объектов или процессов, от заданных требований заказчи¬
ка, согласованных с разработчиками. Результирующий ущерб в со¬
вокупности зависит от величины и вероятности проявления каждого
из них.
Риски могут быть обусловлены нарушениями технологий или
ограничениями при использовании ресурсов, выделенных на разра¬
ботку ПС. Исследования процессов разработки проектов ПС показа¬
ли, что во многих случаях стоимость и длительность их реализации
значительно превышали предполагаемые, а характеристики качества
не соответствовали требуемым, что наносило ущерб заказчикам,
пользователям и разработчикам. Эти потери - ущерб проектов, мог¬
ли бы быть значительно сокращены своевременным анализом, про¬
гнозированием и корректированием рисков возможного нарушения
требований контрактов, технических заданий и спецификаций на
характеристики, выделяемые ресурсы и технологию создания ком¬
плексов программ [27, 33, 37].
На начальных этапах разработки концепции и требований,
Предварительного и детального проектирования ПС наиболее вели¬
56
Технико-экономическое обоснование проектов.
ки риски при оценивании технико-экономических показателей и
возможного качества результатов проекта. По мере уточнения
размера - масштаба и развития проекта комплекса программ эти
риски уменьшаются, однако обычно их влияние остается сущест¬
венным в процессе всего жизненного цикла ПС. Последствия оши¬
бок технико-экономического обоснования определяют значитель¬
ную долю всех рисков качества проектов ПС, могут катастрофиче
ски отражаться на всех этапах разработки и полностью определять
реализуемость проекта. В тоже время интегральные затраты пи
начальных этапах составляют малую часть (несколько процентов)
от всех затрат на разработку проекта сложного ПС. Таким образом,
эти этапы характеризуются наибольшей эффективностью затрат на
анализ и снижение рисков и большим влиянием на все последующи»,
процессы создания ПС.
При технико-экономическом обосновании проектов ПС прямые
риски, обусловлены ошибками прогнозируемых экономических ха
рактеристик, вследствие чего возможен ущерб заказчику при завы¬
шении стоимости проекта относительно реально необходимой,
или ущерб разработчикам, если стоимость оценена недостаточ¬
ной для его успешной реализации. Эти риски могут уменьшаться
при последовательном уточнении размера ПС на этапах формирова¬
ния требований, предварительного и детального проектирования,
однако они не учитывают реальное влияние на процесс разработки и
конечный программный продукт. Поэтому риски первичного ТЭС)
целесообразно оценивать по его последующему влиянию на сте¬
пень реализации требований заказчика в конечном программном
продукте (рис. 1.3).
При разработке ПС после предварительного проектирования
первичные оценки технико-экономических показателей отходят на
второй план и определяющими становятся непосредственные риски
функций и характеристик комплекса программ и контрмеры, кою
рые необходимы для их реализации в соответствии с требованиями
заказчика. На эти риски непосредственно влияют используемые
предварительные оценки технико-экономических показателей и со¬
ответствующие им ресурсы для разработки, которые также характе¬
ризуются некоторыми рисками и возможными контрмерами для и'
снижения.
fjicuict 1. Основы технико-экономического анализа... 57
о о
isle
в1Ц
U Е О С
° *£
сч
s
з 8
в о.
S в
О CJ
2 2
* £
«3
Рис. 1.3
58
Технико-экономическое обоснование проектов.
Совместное влияние на реализацию требований заказчика к
проекту ПС, рисков характеристик программ и ресурсов для их реа¬
лизации должно быть сбалансировано путем допустимого изме¬
нения тех и других видов рисков. В крайнем случае, если инте¬
гральный риск остается недопустимо большим, возможна по согла¬
сованию с заказчиком, корректировка требований или выделяемых
ресурсов (см. рис. 1.3).
На этапах системного и предварительного проектирования Г1С
заказчик совместно с разработчиком подготавливает исходные тре¬
бования к характеристикам проекта комплекса программ и ограни¬
чения для ресурсов, которые могут быть использованы для его реа¬
лизации и применения. Эти требования и ограничения могут не пол¬
ностью выполняться на последующих этапах ЖЦ ПС, что приводи!
к ущербу у заказчиков и пользователей. Причинами такого ущерба
могут быть ошибки при технико-экономическом обосновании
проекта, а также завышенные заказчиком требования к характери¬
стикам ПС, которые не могут быть реализованы при выделенных
ресурсах, или недостаточное качество технологии и квалификация
специалистов - разработчиков, исполняющих проект.
Риски в ЖЦ ПС могут быть обусловлены недостатками дея
тельности различных лиц, участвующих в создании или применении
программного продукта. Основными источниками рисков ПС, кото¬
рые могут приводить к ущербу при его разработке и применении,
являются:
- заказчики программного продукта, которые могут задать
некорректные или нереализуемые разработчиками требования к не¬
му, а также ограничивают выделенные и доступные для проекта ре¬
сурсы и технологию;
- разработчики проекта ПС и специалисты, обеспечивающие
реализацию его ЖЦ, которые могут допустить ошибки при технико¬
экономическом обосновании проекта, не выполнить согласованные с
заказчиком требования к качеству комплекса программ и/или пре¬
высить допустимое использование ресурсов, что может отражаться
на величине и проявлении рисков на последующих технологически'
этапах.
Косвенными источниками и причинами рисков могут быть так¬
же пользователи, некомпетентно применяющие программный про¬
дукт с отклонениями от требований документации по функцион&яь-
Глава 1. Основы технико-экономического анализа.
59
ной пригодности или с недопустимым использованием ресурсов
при эксплуатации ПС.
Для обеспечения требуемого качества ПС необходима органи¬
зация контрмер процесса управления рисками под руководством
менеджера управления рисками - координатора взаимодействия
заказчика и разработчиков, прежде всего, при технико-экономи¬
ческом обосновании проекта. Это лицо должно быть уполномочено,
принимать решения о допустимости применения системы и ПС с
прогнозируемыми или достигнутыми, конкретными уровнями рис¬
ков и/или о необходимости их снижения, путем применения необхо¬
димых контрмер. Задача менеджера рисков состоит в выявлении и
идентификации источников рисков, противоречий требований ха¬
рактеристик и ресурсов для их реализации и в предложении заказчи¬
ку и разработчикам рациональных и возможных контрмер, обес¬
печивающих сокращение рисков до допустимых пределов.
При проектировании и технико-экономическом обосновании
ЖЦ комплексов программ, анализ и управление рисками является
частью общей проблемы сокращения рисков в системах. Эти работы
состоят в выявлении возможных негативных отклонений характери¬
стик комплекса программ и систем от требований контракта, техни¬
ческого задания и спецификаций, а также в создании базы для при¬
нятия мер по минимизации таких отклонений, с учетом ограничен¬
ных ресурсов на их реализацию и других факторов. При этом для
каждого или группы рисков следует определять характеристики, по¬
зволяющие контролировать их состояние и/или величину, а также
способные отражать фиксируемые изменения рисков по результатам
выполненных работ.
Ущерб вследствие ошибок технико-экономического обосно¬
вания проекта программного средства может проявляться двумя ви¬
дами рисков: недостатками достигнутых характеристик качества
ПС, и рисков от ограниченности доступных и используемых ресур¬
сов в последующем жизненном цикле ПС. В жизненном цикле ПС
важнейшим риском является ущерб при невыполнении комплексом
пРограмм, формализованных в требованиях заказчика, назначения и
Функций главной характеристики качества - функциональной пра¬
здности. На эту характеристику в той или иной мере влияют все,
^андартизированные в ISO 9126 (Приложение 1) конструктивные
Характеристики качества ПС (рис. 1.4).
60
Технико-экономическое обоснование проектов.
Рис. 1.4
fjiaea 1. Основы технико-экономического анализа..
61
Характеристики качества, определяющие функциональную при¬
родность сложных ПС, требуют для реализации каждой из них раз¬
умных видов ресурсов и величин затрат. Все виды рисков процес¬
сов и продуктов ЖЦ ПС должны учитывать, прежде всего, их сте¬
пень влияния на этот основной вид риска. Предъявление заказчиком
необоснованных требований к характеристикам качества, проявле¬
ния в них конфликтов и внутренних противоречий в содержании
функций и компонентов, при реально доступных ресурсах и воз¬
можных условиях внешней среды применения ПС, могут также вы¬
зывать ущерб в ЖЦ. В зависимости от назначения, функций, кри¬
тичности и требований к системе и ПС, может потребоваться либо
полная ликвидация определенных или всех рисков, либо сокращение
некоторых из них до допустимых пределов, либо игнорирование не¬
которых и сохранения на достигнутом уровне ущерба вследствие
нарушения требований заказчика.
Риски доступных и используемых ресурсов в ЖЦ ПС могут
включать (см. рис. 1.4):
- экономические риски — превышение разработчиком обосно¬
ванных, допустимых по контракту размеров стоимости, трудоемко¬
сти и эксплуатационных затрат на программные компоненты и ПС в
целом, которые могут также отражаться на их функциональной при¬
годности и других характеристиках качества;
- плановые риски - нарушение разработчиком допустимых
временных затрат в графиках работ, сроков реализации этапов и
проекта в целом, а также распределений задач по подрядчикам, под¬
разделениям и специалистам, что может также увеличивать риски
характеристик ПС;
- кадровые риски - недостаточная квалификация специали¬
стов, отражающаяся на качестве разработки, совершенствования
и/или применения ПС;
- технические риски - недостаточность вычислительных ре¬
сурсов, несогласованность ресурсов внутренней и внешней среды
Для реализации функций ПС, что может иметь как самостоятельное
значение, так и влияние на качество;
- технологические риски - недостаточное качество инстру¬
Ментария для автоматизации всего ЖЦ ПС и технологических про¬
весов, предназначенных для обеспечения гарантированного качест¬
Ва конечного программного продукта.
62
Технико-экономическое обоснование проектов.
Для управления рисками с целью минимизации и выделения,
наиболее опасных из них, необходимо иметь возможность сопостав¬
ления степени и вероятности проявления (частости), как рисков ха¬
рактеристик комплекса программ, так и рисков ресурсов. Для каж¬
дого проекта ПС эти виды рисков могут различно влиять на инте¬
гральный ущерб - риск в ЖЦ ПС, отражающийся общим ущербом
для системы. Применяемые методы оценивания и анализа величин и
вероятности рисков должны позволять определять приоритеты ви¬
дов рисков с целью выделения соответствующей доли ресурсов на
контрмеры для сбалансированного сокращения негативных послед¬
ствий различных видов рисков.
При начальном технико-экономическом обосновании и форми¬
ровании требований к характеристикам комплекса программ прак¬
тически невозможно достоверно предусмотреть сбалансированное
выделение каждого вида ресурса для полной реализации каждой
требуемой характеристики качества. Кроме того, требования заказ¬
чика к характеристикам качества всегда субъективны и не стабиль¬
ны, что также отражается на изменении рисков при разработке и мо¬
дификациях ПС [24, 26]. При этом некоторые характеристики в ре¬
альном проекте ПС могут приобретать значения более высокие, чем
действительно требуются, на что нерационально расходуются ре¬
сурсы, а другие - не удовлетворять требованиям контракта и техни¬
ческого задания. Для разрешения этого противоречия основное зна¬
чение имеет деятельность менеджера рисков или координационного
совета, которые должны быть способны прогнозировать, проводин,
поэтапный анализ, контроль, оценивание и мониторинг возможных
и реальных отклонений от требуемых характеристик и используе¬
мых ресурсов, управление контрмерами и последовательное из¬
менение их для сокращения и минимизации интегрального риска
всей системы.
Так же, как при технико-экономическом обосновании и разра¬
ботке требований к ПС для учета влияния рисков на функциональ¬
ную пригодность и другие характеристики качества целесообразно
ранжировать риски относительными величинами - приоритетами.
Величины и вероятности проявления этих рисков, а также ресурсы
для их сокращения желательно оценивать соизмеримыми экономи¬
ческими, стоимостными категориями или унифицированными отно¬
сительными количественными величинами - приоритетами, (напри¬
fflCiaci 1. Основы технико-экономического анализа.
63
мер, по шкале от 1 до 10) или качественными показателями (катаст¬
рофический, критический, допустимый - высокий, средний, низкий).
Подобные рейтинги рисков с оценкой их вероятностей особенно не¬
обходимы для оценивания и сбалансированного прогнозирования и
минимизации интегральных рисков посредством различных контр¬
мер в проектах ПС. Интегральный риск проекта можно оценивать
как результат обобщения всех видов рисков с учетом их относи¬
тельного влияния на функциональную пригодность и другие важ¬
нейшие характеристики систе.ны и ПС. Такой риск может оцени¬
ваться, например, суммой приоритетов рисков характеристик каче¬
ства ПС, а также суммой приоритетов рисков из-за недостаточных
ресурсов проекта. Такие, даже экспертные, качественные оценки
позволяют прогнозировать и выявлять наиболее крупные и опасные
риски, их долю в интегральном риске проекта ПС, а также рента¬
бельность их снижения [42].
Для сокращения интегрального риска до допустимого значения
при технико-экономическом обосновании возможно изменение
требований к отдельным характеристикам или используемым ре¬
сурсам в последующих технологических процессах ЖЦ ПС. При
этом для обеспечения требуемой функциональной пригодности и
минимального интегрального риска разработчиками возможна сле¬
дующая первая стратегия применения контрмер (сплошные линии
на рис. 1.4):
- изменение соотношения между достигаемыми характеристи¬
ками ПС в пределах согласованных требований, прогнозируемых в
техническом задании и в первоначальной спецификации;
- изменение соотношения между используемыми ресурсами в
пределах исходных ограничений на их применение.
Таким образом, при управлении рисками по первой стратегии
необходимо обеспечить соответствие достигнутых характеристик
качества требованиям, которые были первоначально установлены в
процессе их разработки. Для этого, могут быть перераспределены
имеющиеся ресурсы с целью реализации требуемых отдельных ха¬
рактеристик, и тем самым, в частности, уменьшены риски, с наи¬
большими значениями. Однако если при первой стратегии не обес¬
печивается допустимый минимальный интегральный риск и требуе¬
мая функциональная пригодность, то по согласованию с заказчи¬
64
Технико-экономическое обоснование проектов.
ком, разработчикам приходится применять вторую, дополнитель
ную стратегию контрмер (пунктирные линии на рис. 1.4):
- пересмотр и изменение исходных требований к совокупно¬
сти характеристик качества ПС и уменьшение за счет этого резуль
тирующих значений рисков;
- пересмотр и изменение некоторых требуемых и используе¬
мых ресурсов и технологии для получения допустимых рисков.
При этой стратегии технико-экономического обоснования эф¬
фект может быть достигнут пересмотром и снижением требований
к характеристикам качества, имеющим наибольшие риски или уве¬
личением отдельных доступных ресурсов и совершенствованием
технологии, отражающихся на необходимом сокращении этих рис¬
ков. Если интегральные риски обусловлены недостаточной величи¬
ной одного из видов ресурса, то приходится перераспределять дос¬
тупные ресурсы или искать заказчику способы увеличения некото¬
рого ресурса. В результате изменения характеристик качества ПС и
ресурсов, выделяемых на этапы их жизненного цикла, должны быть
достигнуты сбалансированные значения их рисков и минимизирован
интегральный риск комплекса программ и системы. В соответствие
с их значениями следует откорректировать и утвердить обновлен¬
ные, экономически и функционально оправданные, требования к
характеристикам качества, используемым ресурсам и технологии
проекта ПС. При обеих стратегиях наиболее стабильными должны
быть требования к функциональной пригодности, изменения ко¬
торых допустимы при исчерпании возможностей сокращения инте¬
гральных рисков за счет других факторов и контрмер.
Управление рисками в ЖЦ ПС регламентировано международ¬
ными стандартами ISO 12207 и ISO 15504 (Приложение 1), кото¬
рые целесообразно использовать при разработке комплексов про¬
грамм. В стандарте ISO 15504 - содержится специальный раздел
МАН.4. Процесс управления рисками, назначением которого явля¬
ется регламентирование и планирование процессов выявления и
устранения совокупности различных рисков на протяжении всего
жизненного цикла ПС [20]. В результате такого стандартизировав'
ного процесса, менеджером по управлению рисками должны быть
определены: возможные источники рисков в исходных требования4
к проекту, а также к характеристикам качества; проанализированы 11
определены сбалансированные приоритеты. На этом основано*1
fjiaea I. Основы технико-экономического анализа.
65
должны выделяться ресурсы на сокращение рисков; определены ра¬
циональные стратегии управления, методы и средства уменьшения
рисков в ЖЦ ПС; сокращены до допустимых пределов риски харак¬
теристик качества ПС. Поэтапное, иерархическое снижение инте¬
грального риска проекта ПС при использовании выбранной страте¬
ги может потребовать ее корректировки в зависимости от дости¬
гаемого эффекта и требуемых затрат на сокращение определенных
рисков. Для решения этих задач стандартом рекомендуются по¬
следовательные процедуры.
- выявление и идентификация, относящихся к проекту рисков,
как в исходном состоянии и требованиях к проекту, так и на после¬
довательных этапах его выполнения: по характеристикам качества,
графикам, трудоемкости, ресурсам и техническим рискам;
- анализ вероятности проявления, причин, взаимозависимости
видов и последствий рисков, чтобы сбалансировать и распределить
их приоритеты, на основании которых будут отводиться ресурсы на
различные контрмеры для снижения этих рисков;
- определение целесообразной стратегии и области управления
каждым видом риска или их наборами в проекте в соответствии с
политикой на предприятии, а также со степенью влияния, вероятно¬
стью и типами рисков, которые должны выявляться и которыми сле¬
дует управлять;
- для каждого вида риска (или набора рисков) определение
метрики, отражающей изменения в состоянии рисков в зависимости
от деятельности по их устранению, которые должны характеризо¬
вать изменения в вероятности проявления, влиянии, последствиях и
временных рамках рисков;
- реализовать разработанные стратегии управления рисками,
аттестовать результаты и успешность стратегии в контрольных точ¬
ках ЖЦ проекта;
- если не достигнут, ожидаемый успех деятельности по изме¬
нению или устранению последствий рисков, применять меры для
коррекции или сокращения влияния наибольших рисков, которые, в
частности, могут включать разработку и реализацию новых откор¬
ректированных требований к ПС или изменение существующих
Стратегий и ресурсов для устранения рисков (см. рис. 1.4).
Анализ рисков характеристик качества сложных ПС должен
с°провождать весь их жизненный цикл. Для этого необходимо кон¬
66
Технико-экономическое обоснование проектов.
тролировать области возможного возникновения рисков, оценивать
вероятности их проявления, виды и степень влияния угроз, которые
следует минимизировать как можно раньше по мере их возникнове
ния и обнаружения. Основной эффект по снижению рисков характе¬
ристик качества должен достигаться на начальных этапах разрабоь
ки, когда возможно предотвращение или сокращение многих из них
с минимальными затратами времени и других ресурсов. Для этого в
технологическом процессе разработки необходимо использовать
методы, которые включают'.
- выделение и идентификацию атрибутов функциональной
пригодности, требуемых для конкретного проекта системы и ПС;
- определение ценности (приоритета) каждой требуемой ха¬
рактеристики и атрибута качества для реализации необходимой
функциональной пригодности системы и ПС;
- систематизацию, документирование и оценивание эффектив¬
ности доступных методов, средств и ресурсов контрмер для сокра¬
щения рисков функциональной пригодности и выделенных характе¬
ристик качества ПС;
- определение приоритетов характеристик качества, компо¬
нентов и этапов ЖЦ проекта ПС, которые имеют потенциальные
технические, стоимостные или плановые риски;
- оценивание вероятности каждого вида угроз качеству, по¬
тенциальной величины и вероятности их возможного негативною
воздействия на каждую характеристику функциональной пригодно¬
сти системы и ПС;
- оценивание уязвимости каждой характеристики качества и
затрат ресурсов для восстановления требуемой функциональной
пригодности системы и ПС при проявлении рисков;
- планирование и разработку решений по контрмерам для
обеспечения допустимого уровня интегрального риска функцио¬
нальной пригодности и других характеристик качества системы, в
том числе возможно за счет изменения требований к системе и ПС и
доступных ресурсов;
- оценку вероятностей по сокращению рисков характеристик
качества до допустимых пределов при реализации процессов разра¬
ботки и всего ЖЦ программного средства с учетом доступных PL'
сурсов.
fjiciea l. Основы технико-экономического анализа.
67
Изложенная в стандарте методология оценивания и сбалансиро¬
ванного снижения рисков, при технико-экономическом обосновании
проектов сложных комплексов программ встречается со значитель¬
ными трудностями при стремлении ее применить полностью к ком¬
плексной оптимизации рисков обеспечения качества и ресурсов про¬
ектов. Выше предполагалось, что требуемые и реализуемые значе¬
ния качества и ресурсов характеризуются относительными величи¬
нами - приоритетами, которые оцениваются квалифицированными
экспертами [27]. Такие оценки субъективны и не всегда способны
отразить реальные физические параметры и их взаимосвязь, которые
в конкретном проекте способны снизить его интегральный риск до
допустимого предела. Поэтому на практике при анализе рисков це¬
лесообразно его сузить путем выделения важнейших факторов.
В ряде случаев процессы анализа и сокращения рисков могут
быть значительно упрощены [42]. Для этого целесообразно выделять
и контролировать только отдельные (2 - 3), наибольшие по величине
и по вероятности риски отклонения от требований, и минимизиро¬
вать возможный в результате ущерб для функциональной пригодно¬
сти в ЖЦ системы и ПС. При этом могут иметь решающее значение
для проекта риски трудоемкости и длительности реализации не¬
которых этапов создания проекта. Подобный упрощенный анализ
полезен на начальных этапах проектирования систем и может давать
значительный экономический эффект для последующего совершен¬
ствования всего ЖЦ проектов ПС.
Общие методы анализа рисков в сложных технологических
системах, регламентированные стандартом ГОСТ Р 51901 (При¬
ложение 1), могут быть полезны при технико-экономическом обос¬
новании и разработке проектов сложных комплексов программ. Ос¬
новной задачей стандарта является обоснование решений, касаю¬
щихся риска реализации проектов и технологий систем. Для выра¬
ботки плана анализа рисков проекта должна быть определена и до¬
кументально установлена концепция применения анализа рисков,
которая включает следующие этапы:
- формулировку задач анализа риска, основанных на иденти¬
фицированных потенциальных опасностях для функционирования
системы;
- определение критериев работоспособности и/или отказа сис¬
Темы;
68
Технико-экономическое обоснование проектов.
- описание исследуемой системы, условий и характеристик
внешней среды применения;
- определение рабочих условий и состояний системы, на кото¬
рые распространяется анализ риска и соответствующие ограниче¬
ния;
- описание используемых предположений и ограничивающих
условий при проведении анализа рисков;
- разработка решений, которые могут быть приняты, описание
требуемых выходных данных, полученных по результатам исследо¬
ваний и от лиц, принимающих решения.
Задача по определению области анализа риска должна преду¬
сматривать детальное ознакомление с анализируемой системой. Од¬
на из целей ознакомления - это определение возможных источников
и методов использования информации. Для решения поставленной
задачи должны быть идентифицированы опасности, являющиеся
причиной риска, а также пути, по которым эти опасности могут рас¬
пространяться и реализовываться в проекте. Предварительную
оценку значения идентифицированных опасностей необходимо вы¬
полнять, основываясь на анализе последствий и изучении их основ¬
ных причин. Предварительная оценка значения идентифицирован¬
ных опасностей определяет выбор последующих действий:
- принятие немедленных контрмер мер с целью исключения
или уменьшения опасностей;
- прекращение анализа, поскольку опасности или их последст¬
вия являются несущественными;
- переход к детальному анализу и систематическому оценива¬
нию риска.
В процессе оценки величины риска для выбора критическою
уровня рисков в стандарте рекомендуется исследовать началь¬
ные события или обстоятельства, последовательность потенциально
опасных событий, любые смягчающие факторы и характеристики, а
также природу и частоту возможных негативных последствий иден¬
тифицированных опасностей. Методы, используемые для оценки
величины риска, обычно являются количественными, несмотря на
то, что степень детализации при подготовке исходной информации
зависит от конкретного применения. Однако полный количестве'1'
ный анализ не всегда возможен из-за недостатка информации 0
системе, подвергающейся анализу, отсутствия или недостатка да11'
fjiaea 1. Основы технико-экономического анализа..
69
Hbix о характеристиках отказов, влиянии человеческого фактора и т.
А При таких обстоятельствах может оказаться эффективным срав¬
нительное количественное или качественное ранжирование риска
(присвоение приоритетов) специалистами, хорошо информирован¬
иями в данной области.
Анализ частот в стандарте рекомендуется для оценки вероят¬
ности каждого типа негативного события, идентифицированного на
стадии выявления опасности. Для оценки частот происходящих со¬
бытий обычно применяются следующие методы:
- использование имеющихся статистических данных и пре¬
дысторий;
- получение частот негативных событий на основе аналитиче¬
ских или имитационных методов;
- использование мнений экспертов.
Данные эксплуатации используются с целью определения час¬
тоты, с которой негативные события происходили в прошлом, и, ис¬
ходя из этого, прогнозирование частоты, с которой они произойдут в
будущем. В том случае, когда статистические данные недоступны
или не соответствуют требованиям к системе, можно получать час¬
тоты событий посредством анализа структуры и содержания систе¬
мы и ее аварийных состояний. При проведении анализа частот могут
использоваться методы имитационного моделирования отказов.
Существует ряд методов для сопоставления экспертного мнения,
которые исключают двусмысленность оценок, помогают при поста¬
новке соответствующих вопросов.
Анализ последствий в стандарте предлагается использовать
для оценки ущерба вероятного воздействия, которое вызывается не¬
гативным событием и должен:
- Анализ последствий должен предусматривать определение
основываться на возможных реальных негативных событиях;
- описывать любые последствия, являющиеся результатом та¬
Ки* негативных событий;
- учитывать существующие контрмеры, направленные на
смягчение последствий, наряду со всеми соответствующими усло¬
Виями, оказывающими влияние на последствия;
- устанавливать критерии, используемые для полной иденти¬
фикации последствий;
' рассматривать и учитывать как немедленные последствия,
70
Технико-экономическое обоснование проектов.
так и те, которые могут проявиться по прошествии определенного
времени, если это не противоречит сфере распространения исследо¬
ваний;
- рассматривать и учитывать вторичные, негативные послед¬
ствия, распространяющиеся на смежные системы или внешнюю
среду.
результатов и ущерба в случае наступления негативных собы¬
тий. Модели последствий требуются для прогнозирования размеров
аварий, катастроф и других негативных явлений в различных анали¬
зируемых системах. Знание механизмов, происходящих с ними по¬
следующих процессов, должно давать возможность прогнозиро¬
вать соответствующие негативные процессы заранее. Разрабо¬
тан ряд методов оценки такого рода явлений, диапазон которых про¬
стирается от упрощенных аналитических подходов до очень слож¬
ных компьютерных моделей [8, 33, 35].
f^ctea 2. Основные факторы, определяющие ТЭП..
71
Глава 2
ОСНОВНЫЕ ФАКТОРЫ, ОПРЕДЕЛЯЮЩИЕ ТЕХНИКО¬
ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ В ЖИЗНЕННОМ ЦИКЛЕ
ПРОГРАММНЫХ СРЕДСТВ
2.1. Особенности объектов, определяющие технико¬
экономические показатели в жизненном цикле
программных средств
Труднее всего обосновать технико-экономические показа¬
тели разработки комплекса программ в начале проекта, когда
еще не сформировались достаточно четкие представления о
функциях и свойствах ПС, подлежащего разработке. На базе
этих оценок желательно сделать общий вывод, стоит ли зани¬
маться данным проектом в дальнейшем и на каких условиях
следует заключить контракт на его выполнение. Когда разработ¬
ка программного проекта близится к завершению, с целью уточ¬
ненного оценивания ТЭП следует учитывать некоторые допол¬
нительные аспекты и спецификации. Однако общую смету, вре¬
мя работы над проектом и объем необходимых трудозатрат не¬
обходимо оценивать как можно раньше. При этом целесообраз¬
но поэтапно рассматривать ряд факторов, влияющих на техни¬
ко-экономические показатели разработки ПС, представленные
На рис. 2.1, которые в данном разделе используются как основа
Для последовательности их изложения.
При оценке стоимости проекта и количества времени, требуе¬
мо для его выполнения, предстоит выполнить два основных эта¬
Па Первый этап состоит в оценивании размера - масштаба проек-
на втором этапе представление об этих размерах наряду с инфор¬
мацией о других факторах среды разработки используется для оце-
"чваиия трудозатрат и, соответственно, стоимости и продол-
)ICUlfie:ibitocmu работ.
72
Технико-экономическое обоснование проектов.
Классы и характеристики
программных средств по стандарту
ISO 12182
Три базовых класса комплексов
программ для анализа технико¬
экономических показателей
Концептуальные требования к
рассматриваемым классам
программных средств
Функциональная пригодность - основа
определения техпико-экономических
показателей программных средств
Характеристики сложности
программных средств при анализе
технико-экономических показателей
Описания единиц размера - масштаба и
качества компонентов и комплексов
программ
Единицы измерения трудоемкости
разработки компонентов и комплексов
программ
Единицы измерения длительности
разработки комплекса программ -
начала и окончания проекта
Технико-экономические показатели
на единицу размера
программной продукции
Технико-экономические показатели
на этап разработки
программного средства
Числа ошибок в комплексе программ в
зависимости от длительности
разработки
Рис. 2.1
fjtaea 2. Основные факторы, определяющие ТЭП.
73
Уточнение размеров создаваемого ПС должно предшествовать
этапам проектирования и кодирования программ, выполняемым с
целью реализации требований на практике. Путем оценивания ТЭП
можно спрогнозировать общий объем ресурсов, который необходим
для выполнения данного проекта. При этом должны учитываться за¬
траты времени, количество специалистов, бюджетные и другие огра¬
ничения.
Для конкретизации основной области дальнейшего анализа и
технико-экономического обоснования проектов целесообразно вы¬
делить и классифицировать обобщенные характеристики и атри¬
буты, рассматриваемых комплексов программ в соответствии со
|рандартом ISO 12182 - (см. Приложение 1). В стандарте выделены
три группы видов характеристик: внутренние виды; виды среды и
виды данных. Для каждого вида представлен перечень классов, из
которых рекомендуется выбирать подходящие характеристики для
отражения особенностей конкретной системы или достаточно широ¬
кой сферы анализа и применения ПС. Из общего числа трех видов,
]6-ти классов и около ста типов характеристик ПС вследствие уп¬
рощения далее будут преимущественно учитываться следующие:
- функции прикладных ПС - системы управления объектами
или процессами; САПР, организационные, административные и
обучающие системы;
- прикладная область системы - оборудование и аппаратура
управления процессами и объектами; САПР, информационные, ад¬
министративные и обучающие системы;
- режим эксплуатации - обработка данных в режиме реального
времени;
- масштаб, размер ПС - средний или большой;
- представление данных - предметное, формализованные опи¬
сания объектов или процессов;
- критичность ПС - высокая, должна быть предотвращена
в°зможность больших экономических потерь, повреждения дорогой
собственности или угроза человеческой жизни;
- класс пользователей - технические процессы, средства и
°бъекты, обучающиеся и квалифицированные специалисты;
- стабильность ПС - маловероятное или дискретное внесение
вменений в процессе регламентированного сопровождения;
74
Технико-экономическое обоснование проектов.
- готовность программного продукта — заказное, для конкре i -
ного применения в системе, или для массового распространения на
рынке и среди предприятий;
- требуемые рабочие характеристики: время отклика - бы¬
строе (секунды или минуты); производительность - большая или
средняя;
- требования безопасности и надежности - высокие и критиче¬
ские;
- вычислительная система и среда - микропроцессорное
управление или сложные системы реального времени;
- требования к вычислительным ресурсам - высокие, почти
полное использование ресурсов по основному функциональном}
назначению.
Имеющаяся статистика технико-экономических показателей
разработки ПС различных классов позволила выявить основные
факторы, от которых они зависят. Изучены тенденции изменения
ТЭП от важнейших параметров. Доказано, что трудоемкость разра¬
ботки ПС почти линейно зависит от масштаба - размера создавае¬
мых программ. Для учета классов ПС с позиции их ТЭП проведено
ранжирование экспериментальных данных и выделены три доста¬
точно различающихся базовых класса (см. рис. 2.1) при одном и
том же размере, характеризующиеся [2, 13,40]:
- максимальной трудоемкостью - встроенные ПС сложных
систем реального времени (СРВ);
- средней трудоемкостью - полунезависимые ПС администра¬
тивных, обучающих и инфорационно-поисковых систем (ИГ1С);
- минимальной трудоемкостью создания - распространенные
ПС, практически независимые от реального времени, аппаратуры
систем и внешней среды пакеты прикладных программ (ППП).
Все остальные классы ПС могут быть упорядочены между вы¬
деленными классами, и для них получены оценки изменения трудо¬
емкости относительно максимальной для ПС реального времени
Экспериментальные оценки трудоемкости имеют значительную
дисперсию, которая обусловлена рядом трудно учитываемых факто¬
ров. Малые разработки при небольших коллективах специалистов
характеризуется большими коэффициентами вариации значений
трудоемкости вследствие высокой роли индивидуальной способно¬
fjiaea 2. Основные факторы, определяющие ТЭП.
75
сти специалистов. Трудоемкость разработки сложных ПС размером
порядка 100 тыс. строк описывается более стабильными значениями,
что обусловлено усреднением творческих возможностей специали¬
стов и условий их труда в больших коллективах, а также возраста¬
нием роли руководящего и вспомогательного персонала. В этой об¬
ласти объемов статистические данные лучше аппроксимируются
эмпирическими зависимостями с учетом основных факторов.
Встроенный класс программных средств реального времени
(СРВ) отличается от других жесткими ограничениями на характе¬
ристики ЭВМ и правила использования интерфейсов. Такие ПС
обычно практически полностью используют ресурсы вычислитель¬
ных машин по памяти и производительности, снабжаются подроб¬
ной документацией, эксплуатируются и поэтапно модернизируются
как промышленные изделия многие годы и даже десятилетия. Эти
комплексы программ непосредственно определяют степень автома¬
тизации производства в промышленности, качество управления тех¬
ническими объектами и системами. Такие ПС должны работать при
тесной взаимосвязи аппаратуры, программ, руководств и вычисли¬
тельных процессов. Примерами являются системы резервирования
авиабилетов, системы управления динамическими объектами и воз¬
душным движением. Как правило, затраты на изменение частей
комплекса программ настолько высоки, что иногда гораздо выгод¬
нее оставлять характеристики комплекса неизменными. Следствием
является стабильность программ этого класса. Комплексы программ
требуют больших затрат труда на установление соответствия ПС
своим спецификациям (более высокие затраты на верификацию и
подтверждение) и на обеспечение контроля правильности измене¬
ний (более высокие затраты на испытания и управление конфигу¬
рацией). Все эти факторы приводят к уменьшению производитель¬
ности труда, а также к увеличению отрицательного влияния на неё
масштаба для больших проектов.
По сравнению с распространенным, встроенный проект, как
правило, планируется при меньшем объеме исходной информации
°б условиях и требованиях при его реализации. После завершения
предварительного проектирования рациональной стратегией осуще¬
ствления встроенного проекта является привлечение большой
гРуппы специалистов для параллельного выполнения детального
Проектирования, кодирования и автономной отладки компонентов.
76
Технико-экономическое обоснование проектов.
За раннее завершение проекта ПС встроенного типа обычно
поощряют в большей степени, что часто обусловливается графиком
разработки и необходимостью достаточно быстрого ввода в строй
всей системы. Для встроенных проектов указанная стратегия
приводит к большим затратам труда, чем в проектах другого класса,
реализуемых в такие же общие сроки, а также к значительно
большим затратам на фазе комплексирования и испытаний. Эю
объясняется необходимостью более тщательного соблюдения и
верификации программных требований и спецификаций интерфей¬
сов. Встроенный проект требует относительно меньших затрат труда
на фазе кодирования и автономной отладки, но существенно
больших сроков выполнения как на фазе планирования и анализа
требований, так и на фазе проектирования. Это объясняется необхо¬
димостью более детальных, тщательно подтвержденных специфи¬
каций требований к проекту.
Полунезависимый класс программной разработки (ИПС) для
административных, обучающих и информационных систем, занима¬
ет промежуточное положение (по трудоемкости) между распростра¬
ненным и встроенным классами. Эти ПС не полностью используют
ресурсы вычислительных систем, могут тиражироваться и переда¬
ваться пользователям как законченный программный продукт. Их
эксплуатация обычно превышает длительность разработки, однако в
ходе эксплуатации они непрерывно развиваются. В создании и экс¬
плуатации таких ПС участвуют большие коллективы специалистов,
труд которых должен организовываться, планироваться и анализи¬
роваться на уровне отдельных бригад. Типичным примером полу¬
независимого проекта может быть система обработки сообщений с
весьма строгим соблюдением правил интерфейса например, нала¬
гаемых терминальными, организационными или административ¬
ными требованиями системы.
Распространенный класс (ППП) характеризуется тем, что 11(-
для решения научных и инженерных задач разрабатываются
относительно небольшой группой специалистов в хорошо знакомы*
условиях своей фирмы. Длительность разработки таких программ
обычно больше, чем длительность использования, и они практиче¬
ски недоступны для применения никому, кроме авторов. Процесс и
технологию создания таких программ трудно регламентировать
какими-либо стандартами и нормативами, так как, по существу, ир°'
fjiaea 2. Основные факторы, определяющие ТЭП.
77
Граммы имеют экспериментальный и научно-исследовательский ха¬
рактер, не предполагают тиражирования и промышленного внедре¬
нИя. Гак же, как любые другие виды научной работы, разработку
■таких программ вряд ли целесообразно оценивать по объему разра¬
ботки и производства, по производительности труда или средним
срокам создания программ. Большинство связанных с проектом
специалистов обладают большим опытом работы с аналогичными по
функциям комплексами программ в условиях своей организации и
хорошо понимают, как и каким образом разрабатываемая система
будет способствовать достижению целей фирмы. Это означает, что
большинство участников проекта могут с пользой участвовать на
начальных стадиях разработки, не создавая при этом больших
накладных расходов на обмен информацией о сущности проекта и
деятельности других участников. С увеличением размера проекта
потери производительности труда, вызываемые накладными расхо¬
дами на обмен информацией между исполнителями, возрастают
сравнительно немного.
На проекты распространенного класса налагаются относитель¬
но менее жесткие ограничения на соответствие ПС требованиям и
спецификациям интерфейса. Если возникает ситуация, при которой
достижение такого соответствия привело бы к большим переработ¬
кам проекта, то бригада разработчиков может, как правило, догово¬
риться об изменении спецификаций, облегчающем обновление
изделия или адаптацию для пользователя. Это еще одна причина
более высокой производительности труда и меньшего отрицатель¬
ного влияния масштаба для распространенного класса проектов.
При создании сложных, распределенных систем и комплексов
программ первого и второго классов, формировании их архитекту¬
ры, выборе компонентов и их связей целесообразно учитывать ряд
современных концептуальных требований:
- архитектура системы должна соответствовать текущим и
Перспективным целям и стратегическим, функциональным задачам,
Издаваемой системы;
- в структуре и компонентах следует предусматривать обеспе¬
Чение максимально возможной сохранности инвестиций в аппа-
Рзтные и программные средства, а также в базы данных при
Отельном развитии, сопровождении и модернизации системы;
78
Технико-экономическое обоснование проектов.
- для обеспечения перспективы развития системы следует
предусматривать возможность интеграции гетерогенных вычисли¬
тельных компонентов и мобильность ПС на различные аппаратные и
операционные платформы на основе концепции и стандартов
Открытых систем;
- архитектура информационной системы должна быть
достаточно гибкой и допускать относительно простое, без коренных
структурных изменений, развитие и наращивание функций и ресур¬
сов системы в соответствии с расширением сфер и задач ее
применения;
- необходимо обеспечить эффективное использование ресур¬
сов системы и минимизировать интегральные затраты на обработке
данных в типовых режимах ее функционирования с учетом текущих
эксплуатационных затрат и капитальных вложений в создание ПС;
- следует обеспечить комфортный, максимально упрощенный
доступ конечных пользователей к управлению и результатам
функционирования системы на основе современных графических
средств и наглядных пользовательских интерфейсов.
Описанные особенности классов ПС определили концентрацию
материала книги на анализе прежде всего наиболее сложных для
разработки программах первого класса, а также на некоторых
группах ПС второго класса. Программы третьего класса практи¬
чески не рассматриваются, прежде всего, вследствие их непромыш¬
ленной разработки и несоответствия требованиям программных
продуктов, отчуждаемых от разработчиков.
Обеспечение функциональной пригодности является основ¬
ной целью при использовании финансовых, трудовых, вычислитель¬
ных и других ресурсов в жизненном цикле ПС (см. рис. 2.1). Однако
это не значит, что затраты на решение этой основной задачи всегда
являются доминирующими по величине. Необходимость выполне¬
ния ряда требований к остальным, конструктивным характеристи¬
кам качества, часто приводит к тому, что использование ресурсов на
их реализацию может превышать базовые затраты на обеспечение
функциональной пригодности. В то же время, затраты на выполне¬
ние этих требований, всегда направлены на повышение и совершен¬
ствование функциональной пригодности.
fjiaea 2. Основные факторы, определяющие ТЭП.
79
Поэтому обычно трудно четко выделить и количественно оце¬
нить все виды затраты, используемые только на реализацию функ¬
циональной пригодности.
В любом программном средстве можно выделить компоненты,
р которых сосредоточены функциональные алгоритмы и программы,
предназначенные для решения основных целевых задач ПС. В неко¬
торые из них органически входят компоненты для повышения каче¬
ства решения функциональных задач или они построены с учетом
требований высокого качества результатов основных функций. Для
анализа затраты ресурсов в жизненном цикле ПС целесообразно
разделить на две части (см. п. 4.2):
- затраты на создание программных компонентов, обеспечи¬
вающих базовые свойства функциональной пригодности комплек¬
са программ для его применения по прямому назначению пользова¬
телями, в соответствии с требованиями контракта и технического
задания;
- основные составляющие дополнительных затрат, обеспе¬
чивающие требуемые конструктивные характеристики качества для
улучшения функциональной пригодности ПС в соответствии с це¬
лями и сферой его применения.
Кроме того, следует учитывать совокупность затрат ресурсов на
технологию, инструментарий автоматизации разработки и систему
качества, обеспечивающие жизненный цикл ПС. Эти составляющие
затрат зависят не только от характеристик проектируемого ПС, но и
от интенсивности применения технологических средств.
Затраты на обеспечение функциональной пригодности зави¬
сят, в первом приближении, от сложности алгоритмов, объема ком¬
плекса программ и баз данных, которые определяют затраты труда и
Длительность полного цикла их разработки. Основные затраты идут
па овеществленный, преимущественно, интеллектуальный труд спе¬
циалистов различных категорий (см. п. 3.1). Поэтому для их измере¬
ния наиболее универсальной единицей стали трудозатраты специа-
Дистов в человеко-днях или человеко-месяцах, которые обычно дос¬
таточно просто могут преобразовываться в стоимость процесса раз¬
работки на конкретной фирме.
Понятие и характеристики сложности программ (см. рис.
^■1) активно исследуется последнее десятилетие и предложен ряд
Указателей для ее измерения. Наибольшее внимание исследова¬
80
Технико-экономическое обоснование проектов.
телей привлекала статистическая мера сложности [28] и мера
структурной сложности программ [39, 44]. Для относительно
небольших программ эти методы позволяют улучшим,
достоверность измерения сложности программ и адекватность этом,
показателя трудоемкости их создания. Однако для ПС средней и
высокой сложности ряд факторов затрудняет подобные оценки. Н
крупных ПС реализуются всегда разнообразные задачи различной
сложности. При наличии особо сложной функциональной задачи,
возрастание затрат на ее реализацию обычно нивелируется рядом
других типовых и более простых задач. Поэтому пока не проявились
преимущества этих мер сложности и они не нашли широкого
практического применения.
Весьма расплывчатое понятие сложность комплексов про¬
грамм значительно конкретизируется и становится измеримым,
когда устанавливается связь этого понятия с конкретными ре¬
сурсами, необходимыми для решения соответствующей задачи.
Если хотя бы один из ресурсов, необходимых для решения, велик
или оказывается на пределе, доступном для использования, то
такую задачу вряд ли назовут простой. Сложность задачи может
быть велика по одному используемому ограниченному ресурсу и
невелика из-за малого использования остальных ресурсов. Па-
пример, программа, простая по количеству модулей и длине, мо¬
жет оказаться сложной по объему вычислений или по числу и
структуре обрабатываемых данных, и наоборот.
При разработке программ основным лимитирующим ресурсом
обычно являются допустимые трудозатраты специалистов, а также
ограничения на сроки разработки, параметры ЭВМ, техноло¬
гию проектирования и т.д. Для этапа эксплуатации комплек¬
сов программ основными определяющими ресурсами становят¬
ся память и производительность реализующей ЭВМ, а в каче¬
стве ограничений могут выступать время счета типовых задач,
доступный объем память базы данных. Следовательно, показа¬
тели сложности можно разделить на две большие группы:
- сложность создания комплекса программ для примене¬
ния - статическая сложность, когда реализуются его функции *'
вносятся основные дефекты и ошибки;
fjia<ia 2. Основные факторы, определяющие ТЭП.
81
- сложность функционирования программ и получения
результатов - динамическая сложность, когда проявляются де¬
фекты и ошибки, отражающиеся на функциональном назначении
у, качестве ПС.
К группе факторов, влияющих на сложность разработки
комплексов программ, относятся:
- величина - размер программы, выраженная числом строк
текста, функциональных точек или количеством программных
модулей в комплексе (см. п.2.2);
- количество обрабатываемых переменных или объем
памяти, используемой для размещения базы данных;
- трудоемкость разработки комплекса программ;
- длительность разработки;
- число специалистов, участвующих в создании комплекса
программ.
Некоторые из перечисленных параметров коррелированны
между собой, причем, определяющими обычно являются раз¬
мер программы и объем базы данных. Остальные характеристики
можно рассматривать как вторичные, однако они могут представ¬
лять самостоятельный интерес при анализе сложности и прогно¬
зировании вероятного числа дефектов и ошибок в программе.
Сложность создания комплексов программ целесообразно
анализировать на базе трех наиболее специфических компо¬
нентов:
- сложность программных модулей характеризуется
конструктивной сложностью создания оформленного компонента
программы и может быть оценена с позиции сложности внутрен¬
ней структуры и преобразования переменных в каждом модуле,
а также интегрально по некоторым внешним статистическим ха¬
рактеристикам размеров модулей;
- сложность структуры комплекса или компонентов и
связей между модулями по передачам управления и по обмену
информацией определяется глубиной взаимодействия модулей и
Регулярностью структуры межмодульных связей;
- сложность структуры данных определяется количест¬
вом и структурой глобальных и обменных переменных в базе дан-
ИЬ1х. регулярностью их размещения в массивах, а также сложно¬
стью доступа к этим данным.
82
Технико-экономическое обоснование проектов.
Вторая группа показателей сложности характеризует ком¬
плексы программ на этапе эксплуатации как законченных функ¬
ционирующих систем. Эти показатели объединяются понятиями
вычислительная сложность комплексов программ и слож¬
ность подготовки и анализа результатов. Вычислительная слож¬
ность непосредственно связана с ресурсами вычислительной сис¬
темы, необходимыми для функционирования и получения сово
купности законченных результатов, и может быть представлена
тремя компонентами:
- временная сложность отражает необходимую длитель¬
ность исполнения комплекса программ или время обработки па
ЭВМ определенной совокупности исходных данных до получе¬
ния требуемых результатов;
- программная сложность характеризуется размером
программы или объемом памяти ЭВМ, необходимой для разме¬
щения программного комплекса;
- информационную сложность можно представить как
объем базы данных, обрабатываемых комплексом программ,
или как емкость памяти, используемой для накопления и хране¬
ния информации при исполнении программ.
В системах реального времени временная сложность непо¬
средственно отражается временем отклика (ожидания выходных
результатов) на некоторые исходные данные. Пропускная спо¬
собность комплекса программ при его исполнении на кон¬
кретной ЭВМ характеризует динамику обработки исходных
данных, и сложность исполнения программ в реальном масштабе
времени.
Наиболее сильно на ТЭП в жизненном цикле ПС влияют мас¬
штаб - размер комплексов программ (см. п. 2.2 и гл. 3), а также
требования к их качеству (см. п. 4.2). Качество ПС характеризуется
многими показателями, состав которых зависит от класса и конкрет¬
ного назначения комплекса программ [18]. Ниже предполагается,
что всегда ПС соответствует заданному функциональному назначе¬
нию и основным требованиям заказчика к его качеству. По мере по¬
вышения требований к качеству затраты на разработку ПС увеличи¬
ваются все более высокими темпами. Одновременно расширяется
диапазон неопределенности достигаемого качества при некоторый
затратах. В зоне высокого качества программ возрастают трудное и1
fjiaea 2. Основные факторы, определяющие ТЭП.
83
измерения этих характеристик, что может приводить к необходимо¬
сти изменения затрат в несколько раз в зависимости от применяе¬
мых методов оценки качества ПС. В результате для сложных и
сверхсложных ПС всегда есть риск проявления не устраненных
ошибок и недостаточной достоверности оценок качества (см. п. 1.4).
1 Совокупная трудоемкость при создании программ имеет ряд
составляющих, при определении которых на практике используют¬
ся различные единицы (см. рис. 2.1.). Трудоемкость характеризует¬
ся временем производительного труда определенного числа специа¬
листов, необходимого для создания некоторого ПС, его компонентов
или выполнения определенного этапа работ. Такой подход привел к
|цстивному использованию единиц трудоемкости: человеко-день,
человеко-месяц, человеко-год. При этом человеко-год, предполага¬
ется состоящим в среднем из 250 рабочих человеко-дней (с учетом
выходных и праздничных дней). Подобные единицы трудоемкости
позволяют сопоставлять затраты в разных организациях и даже в
разных странах на аналогичные программы и не зависят от особен¬
ностей валюты при оценке стоимости. Несмотря на яркую критику
«мифического человеко-месяца» [3], пока не предложено разумной
альтернативы для экономического анализа проектов ПС, и эти еди¬
ницы трудоемкости достаточно прочно вошли в практику планиро¬
вания и оценки процессов разработки ПС, вследствие чего являются
базовыми в данной книге.
Специалисты при создании программ различаются квалифи¬
кацией и степенью участия в непосредственной разработке ком¬
плексов программ (см. п. 4.3). Встречаются особо талантливые про¬
граммисты, способные создавать очень быстро программы высокого
качества. Однако при любых способностях есть предел, доступный
разработчику - одиночке, и он редко превышает 10 тыс. строк в год.
Кроме того, даже в этом случае такому программисту необходима
помощь при составлении тестов, оформлении документации, испы¬
таниях и ряде других работ, обеспечивающих превращение про¬
граммы в программный продукт. При разработке сложных ПС пи-
Uiyi и отлаживают программы только около половины общего числа
лиц, затраты на которых необходимо учитывать при технико¬
экономическом анализе (см. п. 3.3). Остальные специалисты осуще-
^ляют руководство проектом, проводят системный анализ, иссле-
4Ук>т алгоритмы, оформляют документацию, выполняют вспомога¬
84
Технико-экономическое обоснование проектов.
тельные технические работы. Их трудозатраты направлены либо
полностью на создание определенного ПС, либо распределяются
между несколькими проектами. Если специально не оговаривается
то далее учитываются в затратах на комплекс программ все катего¬
рии специалистов в соответствии с их долей участия в создании
конкретных программ определенного проекта.
Для учета затрат времени коллектива специалистов на конкре i -
ный комплекс программ (см. рис. 2.1) особенно трудно зафиксиро¬
вать начало разработки. Дело в том, что системный анализ зачас¬
тую входит в научно-исследовательские работы, финансируемые,
планируемые и учитываемые независимо от конкретного программ¬
ного проекта. В ряде случаев первичная разработка концепций 11C
является обобщением опыта создания и эксплуатации ранее разра¬
ботанных, унаследованных программ. Системный анализ, исследо¬
вания и моделирование алгоритмов иногда в последующем реали¬
зуются в нескольких ПС, и весьма трудно оценить долю затрат ис¬
следовательских работ, которую следует отнести к каждому кон¬
кретному проекту. Перечисленные обстоятельства привели к тому,
что затраты на системный анализ и предварительные исследования
могут различаться на один-два порядка и обычно не включаются в
совокупные затраты на создание ПС, что соответствует практике
выделения и отдельного учета затрат на научно-исследовательские
работы в промышленности. При последующем изложении началом
разработки считается создание технического задания или специфи¬
кации требований, согласуемых с заказчиком или будущими пользо¬
вателями ПС (см. п. 1.2).
Окончанием разработки для прекращения учета затрат при
оценке ТЭП конкретного проекта далее принимается момент завер¬
шения межведомственных или государственных испытаний ПС и
оформления акта соответствующей комиссии заказчика. Однако при
анализе реальных проектов эта граница оказывается тоже размытой-
как и начальная, хотя и в меньшей степени. Это обусловлено разно¬
образием видов испытаний, возможностью проведения испытании
Г1С по отдельным функциональным задачам, различием способов
формализации передачи программ на эксплуатацию. Границы эта¬
пов разработки в данной книге рассматриваются в соответствии с пч
описанием в п. 1.3 и уточняются по мере необходимости в соотве’1'
ствующих разделах.
fjiaea 2. Основные факторы, определяющие ТЭП.
85
Суммарные затраты на создание комплекса программ, яв¬
ляются основным интегральным экономическим показателем каж¬
дой разработки. Эти затраты подлежат оценке и минимизации при
условии обеспечения заданных функциональных характеристик ПС
и его качества. Полный анализ и оптимизацию суммарных затрат на
проект целесообразно проводить на всем жизненном цикле про¬
грамм. При этом, в ряде случаев, желательно учитывать затраты на
сопровождение и на эксплуатацию ПС. Эти виды затрат характери¬
зуются значительной неопределенностью из-за сложности прогно¬
зирования длительности жизненного цикла, тиража ПС, степени
развития программ и затрат на сопровождение (см. п. 1.3).
На начальных этапах разработки для прогнозирования ее тру¬
доемкости и суммарных затрат необходимо применять рациональ¬
ные гипотезы об особенностях жизненного цикла конкретного ПС.
Даже приблизительный учет распределения вероятных затрат на
этапах жизненного цикла позволяет более эффективно использовать
экономические ресурсы при создании ПС. При этом условия, обес¬
печивающие минимум суммарных затрат на всем жизненном цикле
ПС, могут приводить к необходимости принципиального изменения
предполагаемого процесса разработки программ, при котором дос¬
тигается минимум только на интервале создания ПС. В связи с этим
последующий анализ суммарных затрат на разработку ПС прово¬
дится в двух постановках задачи: автономно на интервале разра¬
ботки программ без учета последующего использования комплекса
программ и комплексно с учетом влияния затрат на эксплуатацию и
сопровождение программ, что оговаривается в каждом случае.
Длительность разработки комплекса программ зависит от
многих факторов и, прежде всего, от сложности ПС. Следует отме¬
тить консервативность этой характеристики при создании крупных
ПС (см. п. 3.1). Технологический процесс создания любых программ
включает ряд этапов, которые обязательно приходится реализовать
независимо от затрат. Каждый этап требует некоторого времени, что
пРиводит для конкретных ПС к относительно небольшим (по срав-
I НецИю с затратами труда) вариациям суммарной длительности раз-
| Работки. Если разработка ведется на достаточно высоком техноло¬
ГиЧеском уровне, то цикл разработки сложного ПС принципиально
'РУДно сокращать без ущерба для качества программ. Поэтому даже
при увеличении затрат труда в несколько раз длительность разра-
86
Технико-экономическое обоснование проектов.
ботки имеет тенденцию уменьшаться только на проценты.
В то же время множество факторов и неопределенность дости¬
гаемого качества программ приводят к тому, что влияние затрат ца
длительность разработки имеет размытую характеристику. При из¬
менении размеров сложных ПС и трудоемкости в широком диапазо¬
не длительность разработки изменяется мало по сравнению с затра¬
тами. Для каждого размера ПС при заданном качестве существуем
«область невозможного сокращения длительности разработки», ко¬
торую не удается преодолеть при любом увеличении затрат труда
Для планирования разработки ПС и регулярного управления этим
процессом необходимы частные экономические показатели в зави¬
симости от различных факторов. Такие показатели могут формиро¬
ваться: по этапам разработки, на единицу продукции, как относи¬
тельные затраты на достижение заданной характеристики качества
программ или как составляющие суммарных затрат в жизненном
цикле программ.
Технико-экономические показатели на единицу размера про¬
граммной продукции можно оценивать с использованием унифици¬
рованной единицы измерения - оператора (команды) на ассемблере
или на строку текста программы (LOC) (см. рис. 2.1 и п. 2.2). Усред¬
ненные затраты труда всех категорий специалистов, участвующих в
создании ПС определенного размера, позволяют оценить среднюю
производительность труда при разработке программ. В качестве
единицы измерения этого показателя ниже используются число опе¬
раторов ассемблера в месяц на человека или число строк текста
программы в месяц на человека для ПС на языках высокого уровня.
При этом следует подчеркнуть интегральный характер всех величин,
используемых при расчете этой характеристики. Этот показатель
особенно важен при сопоставлении экономических характеристик
ПС различных классов и размеров, а также для оценки эффективно¬
сти технологий и средств автоматизации разработки программ
Средние трудозатраты на создание каждой команды (оператора)
в ПС соответствуют обратной величине производительности труда
при разработке, измеренной в операторах на один человеко-месян
Часто при оценке производительности труда разработчиков
программ учитываются трудозатраты только непосредственных уча¬
стников процесса проектирования без трудозатрат на эксплуатации'
ЭВМ и отчислений на амортизацию вычислительной техники. ЭД1
рдава 2. Основные факторы, определяющие ТЭП.
87
затраты могут быть весьма значительными, однако их не всегда
удобно выражать трудоемкостью на команду. Поэтому в качестве
экономического показателя на единицу продукции с учетом всех
вцдов затрат иногда применяется стоимость одного оператора
или строки текста в завершенном разработкой и испытанном про¬
граммном продукте, представленная в денежном выражении (руб.
л л и долл. на команду или строку текста).
Технико-экономический анализ разработки ПС в денежном вы¬
ражении имеет ряд существенных трудностей, которые ограничили
его применение при оценке проектов по следующим причинам:
- предприятия и фирмы, создающие ПС, имеют значитель¬
ные различия в уровне заработной платы специалистов, что не все¬
гда прямо отражается на их производительности труда;
- каждое предприятие имеет накладные расходы и налоги,
которые могут значительно различаться и никак не влияют на тру¬
доемкость и длительность непосредственной разработки ПС;
- весьма различны оснащенность предприятий технологиями
и средствами вычислительной техники, а также затраты на их при¬
обретение и эксплуатацию;
- из общих затрат на аппаратуру и эксплуатацию технологи¬
ческих ЭВМ и отладочных стендов сложно выделить долю, которую
необходимо включить в стоимость разработки конкретного ПС.
Тем не менее, для заключения контрактов на разработку ПС и
для оценки интегральных затрат на проекты комплексов программ
приходится применять величины затрат в денежном выражении [27,
35]. Для этого вырабатываются соглашения между заказчиком и раз¬
работчиком по преодолению перечисленных выше трудностей. Ни¬
же приведены некоторые характеристики разработки программ и
влияние ряда факторов на стоимость создания ПС (см. гл. 4).
Технико-экономические показатели на этап разработки
Программного средства целесообразно оценивать аддитивными эко¬
номическими показателями (см. рис. 2.1). Такими ТЭП, могут слу¬
жить суммарные трудозатраты на выполнение этапа работ при пла¬
нировании и создании ПС определенного размера и класса или по¬
Этапные трудозатраты на одну команду - строку текста. Эти харак¬
Теристики позволяют выявить наиболее трудоемкие этапы и помо¬
гают рационально распределять затраты по этапам работ. В поэтап¬
ных затратах целесообразно выделять совокупные затраты на сред¬
88
Технико-экономическое обоснование проектов.
ства автоматизации разработки, что позволяет выявлять эффектив- I
ные технологии и средства с учетом стоимости их приобретения и
эксплуатации (см. п. 3.3).
Во многих случаях важны не столько затраты на создание 1|р
сколько длительность разработки. Локальное ускорение отдельных
этапов разработки (особенно начальных) может приводить к значи¬
тельному увеличению длительности других этапов и к общему воз¬
растанию длительности проектирования. Поэтому совершенствова¬
ние технологии и средств автоматизации проектирования сопряжено
с перераспределением затрат и длительностей этапов работ с целью
сокращения общей длительности разработки проекта, в некоторых
случаях даже за счет увеличения суммарных затрат.
Характеристики ошибок при разработке программ значи¬
тельно влияют на затраты при создании программ (см. рис. 2.1). По¬
этому целесообразны оценки относительных и абсолютных трудоза¬
трат на устранение ошибок [11, 26]. Общие тенденции состоят в бы¬
стром росте затрат на выявление каждой ошибки по последователь¬
ным этапам разработки программ. Поэтому экономически целесооб¬
разно в максимальной степени выявлять ошибки на начальных эта¬
пах ЖЦ ПС. Это, естественно, приводит к увеличению затрат и дли¬
тельности этих этапов, однако способствует минимизации суммар¬
ных затрат и длительности разработки проекта в целом.
Характеристики ошибок непосредственно связаны с достигае¬
мыми корректностью, безопасностью и надежностью функциониро¬
вания программ. Изучение характеристик ошибок при разработке
реальных программ позволило создать ряд математических моделей,
обеспечивающих возможность прогнозирования длительности раз¬
работки и затрат, необходимых для достижения определенной безо¬
пасности и надежности программ [39, 47]. Анализ и обобщение ха¬
рактеристик выявленных и устраненных ошибок в процессе разра¬
ботки позволяет контролировать и прогнозировать качество пр°'
грамм при аналогичных разработках.
Стремление заказчиков резко ускорить разработку, снизить за¬
траты или нерационально увеличить нормативы для специалиста-
всегда сопряжено со снижением качества в трудно оцениваема'4
пределах. При рассмотрении ТЭП разработки ПС ниже предпо;ки'а'
ется достаточно высокое, однако, не всегда зафиксированное ка1"-’"
ство программ. Имеющиеся попытки введения заказчиками нор4,а'
fjiaea 2. Основные факторы, определяющие ТЭП.
89
тцвов на ТЭП для разработчиков либо не способствуют выполнению
управляющей и регламентирующей роли (если они занижены),
либо приводят к снижению качества программ (если они завышены),
роэтому приводимые далее ТЭП следует использовать с учетом
всех условий, для которых они получены, и нецелесообразно приме¬
нять в качестве нормативов при конкретных разработках. Они могут
рдужить только ориентирами для оценки и обоснования экономи¬
ческих характеристик аналогичных проектов ПС.
2.2. Особенности измерения масштаба - размера объектов
при технико-экономическом обосновании проектов
программных средств
Выбор и применение единиц измерения размера программ
одна из самых сложных задач при анализе и формализации объек¬
тов разработки и затрат на их создание. Этот параметр в современ¬
ной практике, среди всех факторов, влияющих на ТЭП, изменяется в
самом широком диапазоне на три - четыре порядка от 104 до 107
строк текста программ. Поэтому методам его оценивания ниже уде¬
ляется большое внимание.
Неопределенность единиц измерения размера комплексов и
компонентов программ значительно влияет на численные значения
показателей и их разброс в опубликованных работах. Этому также
способствует неоднозначность учитываемых этапов разработки про¬
грамм и категорий специалистов, трудозатраты которых заметно
влияют на ТЭП. При одних и тех же процессах измерения объектов
разработки и затрат на их создание методики определения количест¬
венных значений основных показателей пока не формализованы, что
вносит дополнительную дисперсию в их значения, приводимые в
различных исследованиях. В результате могут делаться различные и
Даже принципиально неверные выводы, например, об очень высокой
эффективности некоторых частных технологических методов или
инструментальных систем автоматизации разработки ПС [3, 27, 30].
Для уменьшения этих неопределенностей и возможных методиче¬
ских ошибок в ТЭП программ необходимо определить основные
понятия и единицы измерения: размера или масштаба программ,
тРУдозатрат на их разработку, производительности труда специали¬
стов и некоторых частных характеристик (см. п. 2.1).
90
Технико-экономическое обоснование проектов.
Оценку размера комплекса программ и трудозатрат приходится
выполнять неоднократно во время жизненного цикла, причем после
каждого оценивания повышается уровень доверия к полученным ре¬
зультатам. Точность оценки значительно повышается после форм\-
лирования начальных требований и спецификаций заказчиков, про¬
ведения анализа требований, после завершения разработки проекта.
Хороший менеджер проекта обязан взять себе за правило оценивал,
(повторно) размеры ПС, используя результата оценивания в качест¬
ве выходных критериев для каждого этапа. Известно, что программи¬
сты весьма плохо справляются с проблемами оценивания результа¬
тов своего труда. К этому выводу приводит факт, что около 15%
программных проектов не доводятся до завершения, так как прогнозы
по поводу предполагаемой производительности разработчиков весьма
далеки от совершенства. Несоответствие производительности изна¬
чально предполагаемым показателям, может иметь две следующие
причины: плохая работа специалистов или некорректная техники
и методы оценки ТЭП. Имеется множество свидетельств плохо вы¬
полненной оценки, однако практически невозможно доказать, что
персонал не трудился усердно над разрешением проблемы, либо не
является в достаточной степени компетентным. Разработчиков зачас¬
тую нельзя призвать к ответственности за такие результаты. Все
начинается с прогнозирования размеров ПС, оценивание и досто¬
верность которых обусловлены следующими факторами:
- проблема может быть недостаточно хорошо понята разра¬
ботчиками и/или заказчиками из-за того, что некоторые факты были
упущены или искажены из-за предвзятого к ним отношения;
- недостаток либо полное отсутствие исторических данных и
прототипов не позволяет создать базу для оценок и прогнозирования в
будущем;
- специалисты-оценщики могут потерпеть неудачу при по¬
пытке описания того, насколько большой может быть система или
комплекс программ, еще до их создания или даже еще до этапа
разработки предварительного проекта;
- проектирующая организация не располагает стандартами-
с помощью которых можно выполнять процесс оценивания (либо в
случае наличия стандартов их никто не придерживается); в резу |Ь'
тате наблюдается недостаток совместимости при осуществлении
процесса оценивания;
fjiaea 2. Основные факторы, определяющие ТЭП.
91
- менеджеры проектов полагают, что было бы неплохо фик¬
сировать требования в начале проекта, заказчики же считают, что
не стоит тратить драгоценное время на разработку спецификации
требований и оценки размеров проекта;
- для достижения желаемой четкости в функционировании
других частей системы (интерфейсов наследованной системы, ап¬
паратного обеспечения и т.д.) могут потребоваться дополнитель¬
ные компоненты ПС, что скажется на размерах программного про¬
дукта; имеет место недостаточно четкое представление об ограни¬
чениях на уровне системы и возможностях совершенствования рас¬
сматриваемого программного продукта.
Исследованию различных единиц измерения, используемых
при оценке размеров ПС, посвящены рассмотрению некоторых
наиболее часто используемых из них. Выбор этих единиц зависит
от конкретного проекта и потребностей организации. За рубежом
чаше всего размер ПС определяется в терминах строк кода (Lines
of code - LOC), функциональных точек и точек свойств [27, 30, 37].
Вне зависимости от того, оценивается ли конечный продукт, как
в)рлучае с применением показателя LOC, либо некоторая его абст¬
ракция или модель, в данном случае оценке подвергаете то, чего
еще нет в природе. Поэтому оценивание размеров ПС представля¬
ет значительные трудности.
Размер или масштаб программ в настоящее время приводит¬
ся в публикациях в различных единицах, что может изменять их
численные значения для одних и тех же программ в несколько раз
[1, 13, 30]. В качестве таких единиц чаще всего используются чис¬
ленные значения: строк текста программы на языке программирова¬
ния, предложений на ассемблере, символов в тексте программы,
байт или команд в объектном коде после трансляции (таблица 2.1).
каждая из этих единиц измерения имеет некоторые преимущества
при определенных целях исследования. Однако при сравнительном
технико-экономическом анализе различных проектов применение в
КаЖдом из них отличающихся единиц для характеристики объекта
Разработки приводит к дополнительному разбросу численных зна-
Чечий размеров и к несопоставимости измеренных технико-
>к°номических показателей.
92
Технико-экономическое обоснование проектов
Таблица 2.1
Среднее число строк текста программы
на языке ассемблер, соответствующее
одной строке на языке программирования
Язык программирования
Ассемблер
Basic Assembler
1
Macro Assembler
1,5
С
2,5
Basic
3
ALGOL
3
COBOL
3
FORTRAN
3
PASCAL
3,5
PL/1
4,5
C++
6
JAVA
6
Ada 95
6,5
APL
10
SMALLTALK
15
Влияние единиц измерения размера программ на ТЭП можно
значительно уменьшить, если учесть их принципиальные особенно¬
сти и разделить, прежде всего, на две группы единиц измерения
[13]:
- группу, характеризующую размер исходных текстов про¬
грамм, которые разрабатываются и анализируются человеком■
отражающую сложность и трудоемкость создания ПС и компонен¬
тов;
- группу, отражающую размер программ, размещаемых «
реализующей (объектной) ЭВМ, и характеризующую объем памяти
и производительность ЭВМ, необходимые для рабочего функциони¬
рования и исполнения комплекса программ.
Эти две группы единиц отражают объем программ, с разных
позиций, и должны использоваться в зависимости от целей анализа
Хотя между ними есть корреляция, но в общем случае размеры пр0'
граммы, измеренные различными группами единиц, оказываю|СЯ
практически несопоставимыми из-за наличия между ними проме*У
fjtaea 2. Основные факторы, определяющие ТЭП.
93
точного звена - преобразователя (транслятора) с различными, не
полностью определенными характеристиками. Это обусловлено
Особенностями трансляторов, которые преобразуют исходные тек¬
сты программ, разработанные человеком - программистом, в разде¬
лы памяти реализующей ЭВМ, заполненные командами, константа¬
ми или выделенные под данные, а также особенностями языков про¬
граммирования, структуры и содержания машинных команд.
Первая группа единиц измерения размера программ, исполь¬
зуемая специалистами, при создании и анализе текстов ПС, а так¬
же для технико-экономического анализа процессов разработки
должна позволять учитывать и различать:
- новый код текстов программ, разработанный полностью
для нового приложения, который не включает фрагменты и проце¬
дуры ранее написанного и испытанного кода;
- модифицируемый код, разработанный для предыдущих
проектов ПС, который становится пригодным для использования в
новым проекте, после внесения умеренного объема изменений;
- повторно используемый код, разработанный для предыду¬
щих ПС, который будет полностью пригодным для новых прило¬
жений без внесения каких-либо изменений;
- наследственный код, разработанный для предыдущих про¬
ектов, использование которого ожидается новым комплексом про¬
грамм.
Код, повторно используемый, в полном объеме, имеет иден¬
тичную документацию, идентичные тестовые процедуры и код, но
лишь одну копию с целью поддержки библиотеки менеджмента
конфигурирования. Даже если изменяется единственная строка
комментария, то тестовый код, документация и прочее должны
поддерживаться и корректироваться в библиотеке управления кон¬
фигурированием. Если изменяется лишь одна строка исполняемого
к°да, то подвергается изменению тестовый код и документация. При
Использовании наследственного кода следует учитывать, что он мо¬
жет быть снабжен документацией плохого качества, могут отсутст¬
вовать тестовый код либо процедуры. Для этого кода может отсут¬
Ствовать тщательно проработанный проект, и он может не отвечать
С1'андартам качества.
Первый этап при оценке систем, которые могут повторно ис-
"°Пьзовать код, заключается в отделении нового кода от модифи¬
94
Технико-экономические обоснование проектов.
цируемого и повторно используемого кода. Это необходимо по той
причине, что модифицируемый и повторно используемый код прак.
тически никогда не может быть использован непосредственно, для
выполнения интеграции этого кода требуются некоторые измене¬
ния, в результате чего возрастает размер кода и объем трудозатрат.
требуемых для реализации подобных изменений. Если компонент ц |
целом не был изменен, он может повторно использоваться. Если
компонент был изменен (пусть даже речь идет об одном коммента- I
рии или выполняемом операторе), он является модифицируемым.
Кроме того, как только модифицируемый код был идентифицирован,
его можно разбить на категории, представляющие тип модифика¬
ции. Целесообразно отделять модификации, предназначенные для
корректировки дефектов, от модификаций, направленных на изме¬
нение и расширение функций.
После завершения оценки общего размера разработанного про¬
граммного кода, повторно используемый код целесообразно преоб¬
разовать в эквивалентный новый код. В ходе процесса преобразо¬
вания ставится цель минимизировать трудозатраты при внедрении
повторно используемого или модифицируемого кода по сравнению
с внедрением нового программного кода. Обычно определяется
множитель преобразования с целью отражения количества трудоза¬
трат, сэкономленных при повторном использовании кода. При вне¬
дрении повторно используемых компонентов ПС может экономия ь-
ся до 70% трудозатрат по сравнению с внедрением нового компо¬
нента. При использовании модифицируемых программ экономия со¬
ставляет примерно 40% (см. п. 3.2).
Размер исходных текстов программ, прежде всего, отражает
трудоемкость и длительность их разработки и позволяет оценивать
относительные характеристики производительности труда специа¬
листов разработчиков. Однако исходные тексты содержат конструк¬
ции, которые не исполняются при рабочем функционировании про¬
грамм: комментарии разных уровней, указания, заголовки и допол¬
нительные описания, требующие для подготовки определенною
труда. Для сближения понятий и значений размера программ по
обеим (разрабатываемым и исполняемым) группам показателей не¬
лесообразно эти неисполняемые части программы не учитывать. Эча
группа единиц измерения размера ПС в той или иной степени отра"
ffliieu 2. Основные факторы, определяющие ТЭП..
95
ясает сложность разработанного текста программ. К ним относятся
числа¬
- символов в исходном тексте программы на любых языках
программирования;
- операторов языка программирования уровня ассемблера;
- строк текста программы на языке программирования высо¬
кого уровня;
- строки кода в терминах Lines of code - LOC;
- функциональных точек.
Основной труд специалистов вкладывается в разработку текста
программ, и желательно, чтобы выбранная единица измерения была
бы в наибольшей степени адекватна трудоемкости разработки.
При этом должна учитываться не только трудоемкость непосредст¬
венной подготовки текста и разработки компонентов программы, но
и|ртражаться трудоемкость комплексного создания всего сложного
ПС. Кроме того, единица измерения размера должна быть наглядной
и просто измеряемой. Расчет показателей производительности труда
с учетом полного размера ПС, в том числе ранее отработанных и
испытанных программ, в этом случае неправомерен, так как не учи¬
тывается труд, затраченный ранее на готовые компоненты, исполь¬
зуемые при сборке. Возможный выход для уменьшения парадок¬
сальности численных оценок производительности труда при сбо¬
рочном программировании состоит в учете размера и затрат на
комплексирование только вновь разработанных программ [18]. В
этом случае затраты на комплексирование уже ранее отлаженных
программ учитываются только в полной трудоемкости разработки.
Число символов в тексте программы достаточно адекватно от-
Р|жает сложность разработки ПС. Действительно, число символов
исполняемой части текста программы, в первом приближении, непо¬
средственно определяет умственные затраты на подготовку и анализ
текста, а также возможное число ошибок в процессе разработки [13].
Число символов в тексте легко и однозначно подсчитывается при
л*обых языках программирования. По мере повышения уровня языка
пРограммирования символы объединяются в группы - лексемы, ка-
/*Дая из которых в совокупности отражает некоторое понятие. Число
сИмволов в каждом таком понятии может варьироваться в широких
пределах и не всегда соответствует сложности и трудоемкости ис¬
пользования данного понятия в тексте программы.
96
Технико-экономическое обоснование проектов
При возрастании уровня языка программирования число сим.
волов, имеющих непосредственное смысловое содержание, убываем
за счет объединения их в группы, отражающие обобщенные понят ия
языка программирования. Это усложняет оценку объема текста ц0
числу символов. Однако многие символы не группируются, а допус¬
тимое группирование обычно ограничено 6-8 символами. Поэтом\
первичная оценка сложности текста на языках высокого уровня мо¬
жет проводиться прямым подсчетом числа символов в тексте. По¬
следующее уточнение сложности текста возможно путем введения
усредненных коэффициентов, отражающих степень объединения
символов в группы. Оценки текстов программ, написанных на языке
ПЛ-1, показывают, что для автономных модулей этот коэффициент
имеет значение в пределах ~ 2 - 3.
Число операторов па ассемблере широко применяется на
практике для оценки размера текста программ. Это определяется
массовостью применения ассемблеров в некоторых областях (до
50% для программ реального масштаба времени [2, 13]). Ассембле¬
ры обеспечивают наилучшее использование ресурсов памяти и про¬
изводительности реализующих ЭВМ и отражают особенности архи¬
тектуры и системы команд каждой машины. Тем не менее, при од¬
ном и том же алгоритме число операторов на ассемблере без учета
макрорасширений относительно мало зависит от особенностей сис¬
тем команд для большинства современных ЭВМ. Макрокоманды
могут значительно изменять размер текста программы. Поэтому це¬
лесообразно оценку размера программ на ассемблере проводить с
учетом раскрытия макрокоманд. При этом условии число операто¬
ров в текстах программ на разных ассемблерах является наиболее
стабильной характеристикой их размера. Подсчет числа операторов
на ассемблере в тексте программы требует установления правил вы¬
деления операторов и немного сложнее, чем подсчет числа симво¬
лов.
Число строк на языках высокого уровня (ЯВУ) в значительно!!
степени зависит от конкретных особенностей языка (см. табл. 2.D-
Языки программирования высокого уровня ориентированы на опрс'
деленные классы задач. Благодаря этому проблемно-ориентирова"'
ные языки позволяют получать компактные тексты соответс i в> i°"
щих классов программ. Однако применение их для других классов
fjiaea 2. Основные факторы, определяющие ТЭП.
97
приводит к расширению текста и не всегда рационально. ЯВУ зна-
чцтельно различаются степенью обобщенного описания содержания
алгоритмов вследствие их проблемной ориентации, применения
разных структур операторов, операндов и процедур, что может при¬
водить к различию (в несколько раз) числа строк текста, по сути,
одних и тех же программ.
Число строк текста программ на ЯВУ характеризует сложность
программы для её разработчика, однако оно не отражает функцио¬
нальную (потенциальную) сложность, которая значительно выше за
счет применения процедур. Это особенно сильно отражается при
комплексной отладке сложных ПС. В совокупности, перечисленные
факторы приводят к тому, что размер одинаковых программ на раз¬
личных ЯВУ трудно приводить к некоторым унифицированным
единицам. Для такой унификации желательно выделить базовый,
широко применяемый язык программирования и определить ко¬
эффициенты пересчета числа строк при разработке ПС на других
ЯВУ с учетом классов программ. Однако пока отсутствует ЯВУ, ко¬
торый мог бы претендовать на роль базового, а также достаточное
число исследованных ПС на этом языке для обобщения их ТЭП (см.
табл. 2.1).
На основе проведенного анализа можно сделать вывод о целе¬
сообразности применения в качестве базовых единиц измерения
размера ПС числа операторов на наиболее распространенном ас¬
семблере. Для обобщения технико-экономических показателей лю¬
бых разработок ПС необходимо обеспечить [27]:
- расчет числа строк на ЯВУ и определение среднестатистиче¬
ских коэффициентов для их приведения (без учета расширения
вследствие трансляции) к числу операторов на ассемблере той же
ЭВМ, для которой разработаны программы на ЯВУ (коэффициента
сжатия текстов на ЯВУ относительно текста на ассемблере);
- определение коэффициентов расширения трансляторов с
ЯВУ при получении программ в объектном коде реализующей ЭВМ
Как отношения числа команд в объектном коде реализующей ЭВМ,
эквивалентного числу операторов соответствующего ассемблера, к
Числу строк на ЯВУ в тексте программ (полное расширение транс¬
лированного текста в объектном коде реализующей ЭВМ относи-
ГеЛьно текста на ЯВУ);
98
Технико-экономическое обоснование проектов
- пересчет числа операторов программ, написанных на ас¬
семблерах для различных типов ЭВМ к числу операторов на базо¬
вом ассемблере (расширение ассемблеров относительно базового).
Разнообразие ЯВУ, ассемблеров и архитектуры реализующих
ЭВМ не позволяет заранее определить перечисленные коэффициен¬
ты для всех условий анализа ТЭП. Поэтому целесообразны только !
варианты таких оценок, которые могут служить ориентирами цри i
анализе ТЭП конкретных разработок ПС, а также методик, для он- (
ределения коэффициентов пересчета единиц измерения размеров
программ (см. табл. 2.1).
При использовании единиц измерения и прогнозировании раз¬
меров ПС по количеству строк кода (Lines of code, LOC) возникает
ряд вопросов. Каким образом можно определить количество строк
кода (LOC) до того, как они фактически будут написаны либо спро¬
ектированы? Как показатель количества строк кода может отражать
величину трудозатрат, если не будет учитываться сложность произ¬
водимого продукта, способности и стиль программиста либо воз¬
можности применяемого языка программирования? Каким образом
разница в количестве строк кода может быть трансформирована в
объем эквивалентной работы? Эти и другие подобные вопросы при¬
водят к тому, что единицы измерения LOC по-прежнему остаются
наиболее широко используемыми [27, 30].
Оценка показателя LOC с помощью экспертных заключений
и восходящего суммирования включает следующие процедуры.
Приведенные ниже рекомендации могут применяться, как для pci и-
страции размера существующих программ, так и с целью оценки
размеров только разрабатываемых программ на уровне требований и
концепции. Требования к иерархии программных продуктов должны
быть разбиты на фактические компоненты ПС. Начало разбиения
определяется уровнем обобщенных подсистем. В дальнейшем раз¬
биение может детализироваться, формируя точный либо упрошен¬
ный уровень абстракции. Наиболее низкий уровень детализации, как
правило, редко формируется ко времени первоначальной оценки ,
размера ПС (обычно эти уровни детализации формируются на более
поздних стадиях проекта). Обычно несколько уровней абстракции
могут определяться на весьма ранних стадиях планирования проеК'
тов. Следует учитывать, что в максимальной степени детапизир0'
fiiaea 2. Основные факторы, определяющие ТЭП.
99
вапная структура ПС может принести пользу на стадии предвари¬
тельных измерений, за которой следует стадия более точных оценок.
Как только структура ПС будет разбита с учетом выделения
самых нижних доступных уровней компонентов, может быть создан
предварительный показатель размера комплекса программ. При
эТом используются процессы измерения и суммирования. Величина
размера каждого компонента может быть получена путем опроса
экспертов, разрабатывавших подобные системы, либо путем исполь¬
зования данных опроса потенциальных разработчиков подобных
систем. В результате становится возможной оценка размеров каждо¬
го компонента на нижних уровнях структуры. После сложения ре¬
зультатов измерений полученный итог будет называться оценкой
размера «снизу-вверх». Улучшенная оценка может быть получена в
том случае, если каждый оценщик произведет оптимистическую,
пессимистическую и реалистическую оценку размеров. Затем фор¬
мируется бета-распределение путем умножения реалистической
оценки размера на 4, добавления оптимистической и пессимистиче¬
ской оценок с последующим делением результата на 6. Подобное
взвешенное среднее значение является удобным в условиях естест¬
венной неопределенности процесса оценивания.
Следует убедиться в том, что каждая учитываемая строка ис¬
ходного кода содержит лишь один оператор (если в одной строке
содержатся два выполняемых оператора, разделяемых точкой с за¬
пятой, то будут учитываться две строки; если же один выполняемый
оператор разбит на две физические строки, он будет учитываться
как один оператор). В языках программирования допускаются все
опции кодирования, но обычно проще определять в строке один вы¬
полняемый оператор, обрабатываемый компилятором либо интер¬
претатором [27]:
- определения данных учитывается лишь один раз;
- не учитываются строки, содержащие комментарии;
- не учитывается отладочный код либо любой другой времен¬
ный код (средства тестирования, инструменты разработки и прото-
гИпирования, а также другие подобные средства);
- учитывается каждая инициализация, вызов либо включение
(иногда называемое директивой компилятора) макроса в качестве
Части исходного кода, повторно используемые операторы исходного
Кода;
100
Технико-экономическое обоснование проектов.
- рекомендуется транслировать строки исходного кода на
ЯВУ, в эквивалентные строки языка ассемблера, что дает возмож¬
ность одновременно выполнять сравнительный анализ для несколь¬
ких проектов.
Большинство менеджеров проектов предпочитают выполнять
трансляцию с языков программирования на базовый язык ассембле¬
ра по той причине, что в этом случае операции сравнения во мног их
проектах могут производиться на идентичной основе.
Преимущества при использовании LOC в качестве единиц
измерения размера ПС:
- позволяют выполнять сопоставление методов измерения
размеров и производительности в различных группах разработчи¬
ков;
- непосредственно связаны с размером конечного продукта;
- единицы LOC могут оцениваться до завершения проекта;
- оценка размеров ПС производится на основе точки зрения
разработчика - физическая оценка созданного программного про¬
дукта (количество написанных и отлаженных строк кода);
- результаты действий по улучшению программ базируются на
оценочной технике - прогнозированный размер может быть сопос¬
тавлен с реальным размером в ходе осуществления пост-проектпого
анализа.
Недостатки, связанные с применением метода LOC:
- единицы измерения LOC затруднительны в применении при
оценке размера ПС на ранних стадиях жизненного цикла разработ¬
ки;
- исходные инструкции могут различаться в зависимости от
типов языков программирования, методов проектирования, стиля и
способностей программиста;
- разработка ПС может быть связана с большими затратами,
которые прямо не зависят от размеров программного кода, такие
затраты как спецификации требований и пользовательские докумен¬
ты не включены в прямые затраты на кодирование;
- при подсчете количества LOC следует различать автомати¬
ческий и вручную созданный код - эта задача является более ело*'
ной, чем простой подсчет, который может быть выполнен на основ'-
fjiaea 2. Основные факторы, определяющие ТЭП.
101
листинга, сгенерированного компилятором, либо с помощью утили-
Tbi, выполняющей подсчет строк программного кода;
- генераторы кода, не имеющие эффективную оптимизацию,
создают чрезмерный объем кода, в результате чего искажаются по¬
казатели LOC.
Использование функциональных точек в качестве единиц
цз.иерения основывается на том, что размер ПС можно оценивать в
терминах количества и сложности функций, реализованных в дан¬
ном программном коде, а не только посредством количества строк
кода [27, 30, 35, 48]. При использовании этого метода измеряются
категории пользовательских бизнес-функций. При этом способ их
определения является более методичным, чем в случае подсчета
строк LOC. Выше применявшийся подход учитывал лишь размер
компонентов и ПС; этот подход учитывает размер и функциональ¬
ные свойства (сложность) компонентов. Метод функциональных
точек позволяет решать следующие задачи:
- оценивать категории сложности пользовательских бизнес-
функций;
- разрешить проблему, связанную с попыткой применения
единиц измерения LOC на ранних стадиях жизненного цикла разра¬
ботки;
- определять и учитывать количество и сложность входных и
выходных данных, запросы к базе данных, файлы либо структуры
данных, а также внешние интерфейсы, связанные с программной
системой.
Процесс применения функциональных точек включает:
- задается перечень категорий элементов: вывод и ввод, про¬
цессы и функции, структуры данных и интерфейсы;
- определяется сложность каждой категории и функции - про¬
стая, средняя, сложная;
- устанавливаются требования для оценки сложности каждой
из категорий;
- подсчитываются функции в каждой категории;
- каждая функция умножается на соответствующий ей пара¬
метр сложности, а затем суммируется с целью получения общего
Количества функциональных точек в компоненте;
- производится преобразование функциональных точек в еди-
НиДы измерения LOC и их суммирование.
102
Технико-экономическое обоснование проектов.
Множитель преобразования основывается на статистических
показателях для комплекса программ и языка программирования,
представляя среднее количество строк кода, применяемых для реа¬
лизации простой функции. Потребность в этом параметре обосно¬
вывается тем, что большинство автоматизированных инструментов,
предназначенных для оценки трудозатрат, а также для составления
графика работ, нуждаются в использовании LOC программ в качест¬
ве входных данных.
Метод функциональных точек обеспечивает способ предвари¬
тельной оценки размера потенциальных компонентов программ ли¬
бо программных комплексов. При этом осуществляется анализ бу¬
дущих функциональных свойств с пользовательской точки зрения
Языки программирования весьма различны с точки зрения их харак¬
теристик, однако существует некое среднее количество выполняе¬
мых операторов, требуемых для реализации одной функциональной
точки. Преобразование функциональных точек в строки LOC может
потребоваться с целью:
- измерения и сравнения производительности при создании
программных компонентов, либо комплексов, которые были напи¬
саны на различных языках программирования;
- использования стандартных единиц измерения для осущест¬
вления ввода данных в инструментальные средства оценки размера
- преобразования размера комплекса программ либо компо¬
нента, написанных на любом языке программирования, в эквива¬
лентный размер в случае взаимодействия с компонентами, написан¬
ными на другом языке программирования.
Некоторые преимущества, проявляющиеся при использовании
функциональных точек в качестве единиц измерения ПС включают:
- метод не зависит от используемого языка программирования,
технологии, а также техники, исключает некоторые корректировки,
выполняемые на заключительной стадии;
- для пользователей эти единицы измерения могут быть более
привычными, при этом облегчается понимание степени влияния из¬
менений функциональных требований в процессе разработки;
- может измеряться и сравниваться уровень производительно¬
сти разработки проектов, написанных на различных языках пр°'
граммирования;
ПС;
') fpaea 2. Основные факторы, определяющие ТЭП... 103
I "
I j, - функциональные точки могут учитываться на ранних этапах
J результаты подсчета функциональных точек могут сравниваться в
конце этапов формирования требований, проведения анализа кон¬
цепции, разработки проекта, а также внедрения, если количество
функциональных точек увеличивается при каждом подсчете, это оз¬
начает, что проект лучше определен, либо размер проекта увеличил¬
ся;
- функциональные точки могут использоваться в системах, в
которых реализован графический пользовательский интерфейс
(GUI), в клиент-серверных системах, а также при объектно-ориенти¬
рованной разработке.
Так же, как и в случае с моделями определения размеров и
оценивания по величине LOC, может выполняться адаптация и
калибровка функциональных моделей для повышения их точности и
адекватности. Могут учитываться способы применения приоритетов
и относительных весов, а также факторы среды, которые в целом
являются изменяемыми.
Недостатки анализа размера ПС методом функциональных
точек состоят в следующем:
- используются субъективные оценки параметров размера и
сложности функциональных точек, вследствие чего возможны кон¬
фликты между заказчиком и разработчиком;
- получаемые результаты зависят от технологии, используе¬
мой для их оценки и реализации;
- многие модели трудозатрат зависят от показателя LOC, по¬
этому приходится преобразовывать количество функциональных
точек в значения LOC;
- требуются дополнительные исследования оценок на базе
LOC, отличные от оценок, основанных на функциональных точках;
- метод эффективно применим после создания спецификаций
компонентов и архитектуры проекта.
Стандартизация методов функциональных точек для изме¬
рения размера программных средств отражена в международном
стандарте ISO 14143:1-5: 1998-2004. В первой части представлена
Концепция методов измерения функциональных точек программных
средств и перечень обязательных требований к стандартизирован¬
ному методу. Назначение этой части облегчить возможность срав-
Иение мер функционального размера разных проектов ПС. В части 2
104
Технико-экономическое обоснование проектов.
изложена схема оценивания выбранного метода измерения функ
ционального размера на соответствие концепции и обязательным
требованиям стандарта, для обеспечения объективности, беспри¬
страстность и повторяемость измерений размера ПС. Схема включа¬
ет требования к составу и квалификации экспертных групп, к вход¬
ным документам для оценивания, к процедурам оценивания и к
оформлению результатов. При выборе метода оценивания размера
(часть 3), должны учитываться класс и функциональная область
применения ПС. Для этого конкретный метод функциональных то¬
чек должен быть верифицирован путем сопоставления результатов
оценивания этим методом и другим, ранее применявшимся, мето¬
дом. В четвертой части приводятся эталонная модель и способы
оценки эффективности методов измерения функционального разме¬
ра для различных классов ПС в различных областях. Разработчики
метода должны иметь возможность проверить его соответствие
функциональные области; оценщики методов располагать эталон¬
ными объектами, по отношению к которым метод может быть при¬
менен и сопоставлен; менеджеры проектов смогут использовать эта¬
лонные данные для контрольного тестирования качества ПС и про¬
изводительности при разработке проекта. Стандарт содержит при¬
меры эталонных требований для двух крупных классов ПС - адми¬
нистративных информационных систем и систем реального време¬
ни. Цель пятой части стандарта - определение функциональных до¬
менов (компонентов текста ПС) для использования при измерении
функционального размера и для классификации требований потре¬
бителя для применения этого метода измерения. Оценщики и экс¬
перты по методам измерения функционального размера обеспечены
руководствами для определения функциональных областей, приме¬
нительно к которым можно определять эффективность используе¬
мых методов.
Вторая группа единиц измерения размера программ (см. стр-
92) отражает ресурсы памяти и производительности объектной-
реализующей ЭВМ, которые необходимы для функционирования
ПС в процессе эксплуатации. Размер программ, размещаемых 11
ЭВМ для исполнения, влияет на характеристики и стоимость ма'
шин, которая зависит от объема памяти и производительности ЭВМ- i
что особенно важно учитывать в системах реального времени. С°'
временные затраты на реализацию ПС в каждой ЭВМ изменяю'1 ^
J
2. Основные факторы, определяющие ТЭП..
105
приблизительно в таком же широком диапазоне, как и трудоемкость
их разработки (на четыре порядка). Массовое тиражирование неко¬
торых ПС (например, в системах реального времени) может допол¬
нительно, на несколько порядков, увеличивать диапазон затрат на
Гализующие ЭВМ.
Естественно, требующийся объем памяти и производительно¬
сти ЭВМ, в некоторой степени, зависит от исходного текста про¬
граммы, однако существенное значение при этом имеет ряд других
факторов. Трудоемкость разработки при этом отходит на второй
план и основную роль играют затраты на производство и эксплуата¬
цию ПС. Для измерения размера программ при реализации ПС на
ЭВМ применяются следующие единицы:
- байты, занятые текстом программ в объектном коде и пере¬
менными базы данных в памяти ЭВМ;
- команды (операции) реализующей ЭВМ, составляющие
текст исполняемой программы в объектном коде;
- слова памяти, обусловленные структурой данной реализую¬
щей ЭВМ, используемые для хранения исполняемых программ и
базы данных при функционировании ПС.
Число байтов оперативной и постоянной памяти реали¬
зующей ЭВМ, занятых при исполнении программы, - наиболее про¬
сто подсчитываемая характеристика размера ПС. Основная слож¬
ность. зачастую, возникает при учете одного и того же физического
объема памяти, используемого последовательно различными масси¬
вами данных и отдельными переменными. Однако число байтов от¬
носительно слабо коррелированно со сложностью и трудоемкостью
разработки, а также с размером исходного текста программ. В этом
значительную роль играет различное соотношение необходимой па¬
мяти команд и данных в зависимости от классов задач. Архитектура
и структура команд реализующих ЭВМ, а также расширение текста
пРограммы в объектном коде при трансляции, дополнительно вы¬
полняют дестабилизирующую роль при применении для анализа
числа байтов.
Число команд, занятых программой в реализующей ЭВМ,
наиболее полно соответствует числу исполняемых операторов на
ассемблере в исходном тексте программы. В различных типах ЭВМ
к°манды занимают различное число байтов или частей слова. Ко¬
манды во многих машинах имеют переменную структуру по числу
106
Технико-экономическое обоснование проектов.
занимаемых байтов в зависимости от кода операции, и могут возни
кать затруднения при выделении команд в машинном слове. Логи¬
ческая сложность команд зависит также от методов использования н
них регистров. Число команд в объектном коде программы, функ¬
ционирующей на ЭВМ, позволяет наиболее просто увязывать затра¬
ты на исполнение и на разработку программ.
Число слов, занятых программой и данными в ЭВМ, имеем
практически те же особенности при измерении объема программ,
что и число байтов. Однако следует учитывать, что реализующие
ЭВМ могут значительно различаться по числу байтов в слове, что
дополнительно затрудняет сопоставление объема различных про¬
грамм при использовании этой единицы измерения и их унифика¬
цию. Для устранения этого препятствия иногда все размеры про¬
грамм приводят к наиболее широко применяемой структуре слов из
4 байтов.
Важная задача при оценивании ТЭП состоит в выборе базо¬
вых унифицируемых единиц измерения исходного текста и испол¬
няемых (объектных) программ, при применении которых имеется
наибольшая корреляция этих видов измеряемых размеров про¬
грамм. Для остальных единиц измерения необходимы методы пере¬
счета к базовым единицам с учетом особенностей языков програм¬
мирования, применяемых трансляторов и архитектуры ЭВМ. Кроме
того, следует определять коэффициенты корреляции с базовыми
единицами измерения при применении остальных единиц. С этих
позиций наиболее адекватной единицей измерения объема программ
является число операторов на машино-ориентированном ассемб¬
лере, которое имеет корреляцию с числом команд в объектном коде
реализующей ЭВМ, близкую к единице. В этом случае при сопос¬
тавлении измеренных объемов программ влияет единственный фак¬
тор - архитектура реализующих ЭВМ. Этот фактор может учиты¬
ваться путем небольших коэффициентов перевода, определяемых
путем анализа особенностей структуры и системы команд ЭВМ. а
также конкретного ассемблера. Для сопоставления численных зна¬
чений объемов программ следует выделять базовый, наиболее ши¬
роко применяемый ассемблер. Однако при анализе единиц измере¬
ния размера программ для оценки ТЭП следует учитывать некото¬
рые парадоксальные ситуации.
fflctea 2. Основные факторы, определяющие ТЭП..
107
Первый парадокс. При применении языков программирования
0ь|сокого уровня оценка размера разработанных программ по числу
команд, байтов или слов реализующей ЭВМ приводит к большим
ошибкам при прогнозировании трудоемкости разработки по этим
данным. Парадокс состоит в том, что чем хуже транслятор с ЯВУ и
чем ниже его оптимизирующие характеристики, тем больше размер
программ в реализующей ЭВМ при одной и той же трудоемкости их
разработки. При таком подсчете объема программ для оценки ТЭП
«выгодно» применять трансляторы с низкой оптимизацией в про¬
цессе трансляции, так как они позволяют создавать больший размер
ПС и показывать более высокую расчетную производительность
труда разработчика. Одновременно увеличиваются ресурсы памяти
и производительности ЭВМ, необходимые для функционирования
Г1С. Различие характеристик трансляторов и их оптимизирующих
свойств значительно уменьшает корреляцию между размером про¬
грамм в объектном коде и трудоемкостью их разработки. Это сни¬
жает достоверность оценки и прогнозирования ТЭП процесса разра¬
ботки. Следовательно, нецелесообразно при оценках ТЭП измере¬
ние размера программ по объектному коду реализующей ЭВМ для
программ, разработанных на ЯВУ.
Второй парадокс. При использовании числа строк исходного
текста программы на ЯВУ для анализа производительности труда
разработчиков необходимо учитывать сжатие анализируемого тек¬
ста при повышении уровня языка. Изменение числа строк в тексте
программы и трудозатрат на его разработку в зависимости от уровня
языка подчиняется разным законам. В частности, число строк про¬
граммы зависит от конкретных правил формирования строк на ЯВУ,
что практически не отражается на трудоемкости. Она не зависит от
того, как упорядочивается текст по вертикали и по горизонтали, и
как операторы объединяются в строки текста. Повышение уровня
языка программирования увеличивает степень обобщенности описа¬
ния алгоритма (за счет исключения машинно-зависимых понятий) и
информационную насыщенность строки текста программы. В ре¬
зультате снижается трудоемкость разработки компонентов и ПС в
Целом. Одновременно по мере повышения проблемной ориентиро¬
ванности и уровня языка при одних и тех же алгоритмах еще быст¬
ра сокращается число строк в тексте программы. Это приводит к
Уменьшению размера программ, созданных каждым специалистом,
108
Технико-экономическое обоснование проектов
более быстрому, чем снижаются трудозатраты на создание тех же
программ. Парадокс состоит в том, что рассчитанная по этим дан¬
ным производительность труда в строках ЯВУ на единицу времени
оказывается тем ниже, чем выше уровень языка программирования
Для разрешения этого парадокса при анализе производительности
целесообразно пересчитывать число строк на ЯВУ в эквивалентное
число операторов на ассемблере. Коэффициенты пересчета для каж¬
дого ЯВУ, могут быть оценены экспериментально, путем пробного
программирования представительной выборки программных моде¬
лей на ассемблере, после того, как они разработаны и отлажены на
соответствующем ЯВУ. В результате такого пересчета производи¬
тельность труда адекватно отражает сложность программы и сниже¬
ние трудозатрат за счет повышения уровня ЯВУ, и не искажается
спецификой конкретного сжатия текста программы за счет языка.
Третий парадокс. Одним из наиболее эффективных методов
повышения производительности труда при разработке сложных ПС
является применение сборочного программирования [13, 27]. При
этом непосредственные затраты идут на создание новых программ¬
ных компонентов и на комплексирование вновь созданных компо¬
нентов с ранее апробированными и подготовленными для сборочно¬
го программирования. Число вновь созданных строк текста про¬
грамм может быть невелико, однако на сборку и комплексирование
нового ПС или его адаптацию к новым условиям применения могут
потребоваться значительные трудозатраты. В результате при умень¬
шении доли вновь разрабатываемых программ в ПС производитель¬
ность труда, рассчитываемая по их размеру в любых единицах, па¬
дает. С этих позиций применение сборочного программирования
представляется невыгодным, когда в действительности за счет сбор¬
ки можно получать сложные ПС с новыми функциями при сравни¬
тельно небольших затратах труда.
fjtaea 3. Базовые характеристики затрат на разработку... 109
Глава 3
БАЗОВЫЕ ХАРАКТЕРИСТИКИ ЗАТРАТ
НА РАЗРАБОТКУ ПРОГРАММНЫХ СРЕДСТВ
3.1. Оценка трудоемкости и длительности разработки
полностью новых программных средств
Основными ресурсами у разработчиков при создании слож¬
ных комплексов программ являются: допустимые трудозатраты
на разработку ПС с требуемым качеством; время — длительность
полного цикла создания программного продукта; необходимое и
доступное число специалистов соответствующей квалификации..
Потребность в этих ресурсах в наибольшей степени зависит от раз-,
мера - масштаба и сложности разрабатываемого ПС, методы и оцен-|
ки которого представлены в п. 2.2гКогда впервые рассматртБаёТсз^
масштаб нового проекта ПС, интуитивные и экспертные оценки
его трудоемкости могут отличаться от конечного значения при¬
мерно в полтора раза в ту или другую сторону. Рисунок 3.1 иллю¬
стрирует достоверность, с которой могут быть получены оценки
трудоемкости или стоимости ПС, представленные в виде функции
этапа ЖЦ (горизонтальная ось), или уровень знаний о предполагае¬
мой работе над ПС. Такая достоверность оценок обусловлена
Уровнем неопределенности на данном этапе знаний о конечном
содержании и возможном размере программного продукта. Хотя
на рис. 3.1 представлена симметричная картина, общая тенден¬
ция состоит в том, что на начальных этапах оценки затрат чаще
всего занижаются.
Эта неопределенность уменьшается по мере детализации
и углубления содержания и функций проекта, как только
Фиксируются конкретные принципы функционирования и концеп¬
Технико-экономическое обоснование проектов.
ция ПС. На этом этапе оценка достоверности размера уменьшаем,
ся приблизительно до 40%.
Достоверное! ь
первичной
экспертной
оценки Т!)П Достоверность
Это вполне объяснимо, поскольку еще не уточнены структу¬
ра и многие детали проекта. Эти вопросы будут могут быть раз¬
решены во время разработки структуры и спецификаций требова¬
ний к ПС и тогда можно оценить размер ПС с точностью до 15 -
20%. После завершения разработки и подтверждения проектных
спецификаций при детальном проектировании комплекса про¬
грамм может быть определена структура внутренних данных и
функции программных компонентов. На этом этапе оценка раз¬
мера и трудоемкости проекта может составить около 10%. Неоп¬
ределенности оценок могут быть обусловлены: особенностями
конкретных алгоритмов, управления их работой, обработки оши¬
бок, инициализации и завершения сеансов работы и т. д. Э'М
уточнения размеров ПС и компонентов могут быть решены к кони>
детального проектирования, однако при этом сохраняется неопрс'
Концепция
н общие
Iребонання
Рис. 3.1
piaea 3. Базовые характеристики затрат иаразработку.
111
деленность оценки размера комплекса программ и его трудоемко¬
сти порядка 5 - 10%, связанная с тем, насколько хорошо про¬
граммисты понимают спецификации, в соответствии с которыми
они должны кодировать программу. Основной вывод, выте¬
кающий из рис. 3.1, состоит в необходимости быть последова¬
тельным при определении исходных данных при оценке ТЭП для
^различных компонентов программного продукта и этапов проек¬
тирования.
В общем случае желательно достигать сбалансированного на¬
бора целей оценивания ТЭП комплекса программ, который бы да¬
вал примерно одинаковую величину уровня неопределенности
для всех исходных данных и компонентов ПС. Вследствие этого
изложение анализа и обоснования ТЭП ниже разделено на две круп¬
ные части. В главе 3 рассматриваются первичные, базовые оценки
трудоемкости, длительности и числа специалистов в зависимости от
размера и повторного использования компонентов и ПС в целом. В
главе 4 уточняются ТЭП и оценивается влияние на эти характеристики
дополнительных факторов: особенностей и качества объектов и среды
разработки, квалификации и организации специалистов, технологиче¬
ской, инструментальной и аппаратурной оснащенности проекта (рис.
3.2). По мере выполнения проекта, оценки ТЭП необходимо пере¬
сматривать и изменять, когда это становится выгодным или не¬
обходимым. Можно начинать с определения оценок трудоемко¬
сти в соответствии с точностью определения размера ПС по дан¬
ным спецификаций требований с учетом минимума факторов
(гл. 3), но при дальнейшем анализе уточнять оценки с точностью
деталей функционирования и с учетом влияния совокупности
важнейших факторов и характеристик проекта (гл.4).
При оценках ТЭП целесообразно учитывать:
- цели оценивания ТЭП должны быть согласованы с по¬
требностями в информации, способствующей принятию решений
на соответствующем этапе проекта ПС;
- достоверность оценок ТЭП должны быть сбалансированы
Для различных компонентов системы и величина уровня неопреде¬
ленности для каждого компонента должна быть примерно оди¬
наковой, если в процессе принятия решения все компоненты
имеют одинаковый вес;
112
Технико-экономическое обоснование проектов.
fjiaea 3. Базовые характеристики затрат на разработку... 113
- следует возвращаться к предшествующим целям оценива¬
ния и изменять их, когда это необходимо для ответственных
бюджетных решений, принимаемых на ранних этапах и влияю¬
щих на следующие этапы.
Измерение размера, оценка и составление графика разработки
сложным образом переплетаются в процессе планирования проекта.
На самом деле довольно сложно создать реальный график (учиты¬
вающий обязанности исполнителей, их зависимости, перекрытие
действий, а также дату поставки продукта) без информации об объ¬
еме трудозатрат, требуемых для выполнения каждой задачи (напри¬
мер, определения нагрузки сотрудников на месяц). Достаточно
трудно оценить объем трудозатрат, необходимых для выполнения
задачи, без достоверной информации относительно ее размера. Та¬
ким образом, измерение размера (сложности) предшествует оценке
ТЭП, а эта оценка, в свою очередь, предшествует составлению гра¬
фика работ. Каждое из этих важных действий проекта может быть
выполнено с помощью различных методик (см. гл. 5). Недостаточно
достоверные оценки влекут проблемы взаимодействия разработчика с
заказчиком и увеличивают степень риска проекта.
В индустрии ПС часто обращаются к использованию метрики
LOC, единицы измерения, хорошо знакомой практикам в области
разработки ПС. Они находят ее комфортной и простой в примене¬
нии. Какая бы технология не использовалась, оценка размера буду¬
щего продукта является весьма важной, поскольку она является ча¬
стью одной наиболее важной задачи проекта: установка реальных
ожиданий. Нереальные ожидания, основанные на неточных оцен¬
ках, представляют собой одну из частых причин провала проек¬
тов. Зачастую причина кроется не в недостаточной производи¬
тельности команды проекта, а в неточном предвидении уровня этой
производительности и размера проекта. Точное оценивание ТЭП
обеспечивает улучшенный контроль над проектом и является жиз¬
ненно важным в деле проектного менеджмента. Для обеспечения
точного оценивания в первую очередь следует иметь представление
относительно размера продуцируемого ПС. Эта величина должна
определяться на ранних стадиях цикла разработки и выражаться в
еДиницах, которые являются достаточно простыми.
Исходные данные реальных завершенных разработок для
°Ценивания ТЭП, собираются, накапливаются и обрабатываются, с
Технико-экономическое обоснование проектов.
начала 70-х годов в разных отечественных организациях и за рубе
жом [2, 13]. Они позволили получать и прогнозировать основные
обобщенные технико-экономические показатели процессов разра¬
ботки ПС. При этом компоненты операционных систем, драйверы
средства контроля и тестирования, а также повторно используемые
компоненты обычно не учитывались при оценке размера вновь соз¬
данных комплексов программ и трудоемкости их полной разработ¬
ки. Поэтому технико-экономические показатели проектов этого пе¬
риода можно отнести к полностью оригинальным разработкам ком¬
плексов программ. При этом обычно рассматривался полный техно¬
логический процесс разработки ПС от начала подготовки техниче¬
ского задания (ТЗ) до завершения испытаний базовой версии IIC.
Учитывались все категории специалистов, участвующих в создании
программ и обеспечивающих разработку, а также все виды работ,
связанные с созданием программного продукта на выделенном ин¬
тервале времени. Теоретические работы и системный анализ до под¬
готовки ТЗ в значениях ТЭП не учитывались.
Наиболее полно и подробно основные закономерности и
влияние факторов на технико-экономические показатели про¬
цессов разработки сложных ПС в 70 - 80 годы, представлены в [2]
для более десяти моделей прогнозирования. В 1981 году на основе
исследования процессов разработки 63 проектов ПС опубликована
модель прогнозирования ТЭП под названием КОМОСТ [2]. В по¬
следующем, эта модель развита, детализирована и опубликована как
СОСОМО, а в 2000 году под названием СОСОМО II [30]. В этой
модели на основе анализа более 160 реальных проектов разработки
комплексов программ различной сложности уточнены рейтинги
влияния выделенных факторов на основные ТЭП. Эти данные ниже
используются и рекомендуются как базовые для прогнозирования
затрат при создании ПС.
Кроме того, в 1988 году опубликованы [13] результаты анализа
ТЭП комплексного проекта ПРОМЕТЕЙ на основе обобщения ре¬
зультатов разработки свыше 250 отечественных проектов сложных
ПС, отдельные фрагменты которых также использованы ниже. И
общем случае для оценки технико-экономических характеристик
новых проектов необходимы исходные данные:
- обобщенные характеристики использованных ресурсов
технико-экономические показатели завершенных разработок - нр°'
fjiaea 3. Базовые характеристики затрат на разработку.
115
•го-типов ПС, а также оценки влияния на их характеристики различ¬
ных факторов объекта и среды разработки;
+ - реализованные и обобщенные перечни выполненных работ и
реальные графики проведенных ранее разработок различных клас¬
сов ПС;
- цели и содержание частных работ в процессе создания слож¬
ных комплексов программ и требования к их выполнению для обес¬
печения необходимого качества ПС в целом;
- структура и содержание документов, являвшихся результа¬
том выполнения частных работ.
Наиболее важен учет и анализ факторов на начальных этапах
разработки, когда прогнозируются первичные совокупные затраты
Ср на создание ПС (см. рис. 2.1). На этих этапах неопределенность
оценки параметров и факторов наибольшая (см. рис. 3.1), тем не
менее применение приводимых характеристик позволяет избегать
наиболее крупных ошибок при оценке затрат, которые делаются экс¬
пертами без детального анализа влияния факторов. Подобный
анализ является базой для рационального распределения ресурсов и
для управления их использованием по мере развития проекта. Учет
и прогнозирование возможного изменения затрат в зависимости от
основных параметров способствует упорядочению процесса разра¬
ботки ПС и концентрации усилий на тех факторах, которые могут
дать максимальный эффект уменьшения затрат в конкретных усло¬
виях создания комплекса программ. После проведения структурного
проектирования и распределения ресурсов ПС возможна ошибка в
оценке затрат на разработку приблизительно в полтора-два раза
меньше, а перед программированием она может уменьшаться до 10
- 15%. Такие достоверности можно получить, конечно, только при
подробном анализе и оценке влияния важнейших факторов.
Этапы жизненного цикла программ существенно различаются
между собой степенью определенности и прогнозируемости их ха¬
рактеристик. Соответственно изменяются возможности подготовки
и достоверность планов проведения работ. В процессе разработки
сложных программных средств уточняются и детализируются их
спецификации требований, функции, структура и характеристики
компонентов. Поэтому на начальных этапах, особенно принципи-
эльно новых проектов, трудно спланировать точно все последующие
Этапы. В результате планирование проводится итерационно в со¬
116
Технико-экономическое обоснование проектов
ответствии с последовательным повышением достоверности и точ¬
ности сведений об объекте и среде разработки.
Разработка сложных ПС, особенно на начальных и завершаю¬
щих этапах, характеризуется высокой долей творческого труда. По¬
этому трудоемкость и длительность отдельных операций и частных
работ существенно зависят от индивидуальных особенностей их ис¬
полнителей и характеристик конкретного проекта. Вследствие этого
отсутствует достоверная пооперационная статистика разра¬
ботки программ, и пока невозможно создать типовые нормативы
на большинство частных операций при создании ПС. Отсюда прин¬
ципиальной особенностью планирования разработки комплексов
программ является активное участие руководителей и заказчиков
проекта в составлении планов на базе исследованных характеристик
прототипов завершенных разработок ПС и их личного опыта. Такие
планы должны иметь разумные ограничения в детализации работ на
уровне, обеспечивающем необходимую управляемость всего про¬
цесса проектирования. В процессах и системах автоматизации пла¬
нирования и управления разработкой ПС целесообразно учиты¬
вать следующие их особенности:
- последовательную, иерархическую детализацию и поэтапное
уточнение планов и прогнозов в соответствии с повышением полно¬
ты и достоверности исходных данных об объекте и среде разработ¬
ки, получаемых в процессе создания ПС;
- использование прототипов технико-экономических показа¬
телей, перечней и графиков частных работ как основных исходных
данных для прогнозирования и планирования разработки новых 11C;
- целесообразность и возможность выбора первичного прото¬
типа перечня работ, достаточно адекватного исходным данным про¬
ектируемого ПС, и возможность его уточнения проектировщиком;
- регистрацию, обобщение и хранение реализованных рабочих
планов и значений ТЭП для их использования в качестве прототипов
при планировании последующих аналогичных разработок.
Таким образом, в процессе планирования после использования
прототипов для прогнозирования и планирования очередной разр®'
ботки происходит ее реализация, данные которой могут быть ис'
пользованы в качестве прототипов для последующих проектов. ТеМ
самым может быть создана последовательно уточняющаяся ба^а
данных, позволяющая повышать достоверность прогнозирования
fjiaea 3. Базовые характеристики затрат на разработку..
117
планирования разработок ПС определенного класса. Внутри этого
цикла может происходить разработка конкретного ПС, для которой
характерно также последовательное уточнение и детализация про¬
гнозов и планов.
В качестве базового варианта целесообразно принять статисти¬
ческие данные ТЭП, перечень работ и документов жизненного цикла
Ьоздания наиболее сложного встроенного комплекса программ ре¬
ального времени (см. п. 2.1) [2, 13, 30, 40]. На основе этих исходных
данных могут быть оценены ТЭП для полного цикла разработки ПС
конкретного вида в более простых случаях путем исключения из
базового варианта работ и документов, в которых отсутствует необ¬
ходимость. По оставшимся работам могут быть оценены ТЭП для
вариантов и выбран из них предпочтительный. Для технико¬
экономического анализа процесса создания программ важнейшей
составляющей являются совокупные трудовые затраты - трудоем¬
кость С на непосредственную разработку ПС.
Трудоемкость разработки программных средств наиболее
сильно зависит от размера — масштаба программ, выраженного
числом операторов на ассемблере или строк на языке программи¬
рования высокого уровня. В п. 2.2 обсуждался вопрос о способах и
единицах измерения размера разрабатываемых программ и обосно¬
вана целесообразность проводить эти оценки в числе операторов
(команд) на языке ассемблера. Реальное изменение создаваемых в
настоящее время сложных ПС от 104 до 107 строк (LOC) определяет
диапазон трудоемкости разработки таких программ от человеко-года
до десятков тысяч человеко-лет. Широкий диапазон изменения раз¬
мера создаваемых программ в наибольшей степени определяет
значения суммарной трудоемкости их разработки. Подтверждена по
большому числу проектов высокая статистическая корреляция [2]
между размером комплексов программ в операторах на ассемблере и
трудоемкостью их разработки. С другой стороны, отсутствуют какие
либо данные о значительном преимуществе других мер размера и
сложности при прогнозировании затрат на разработку сложных и
сверхсложных ПС. Объем программ в числе операторов на ассемб¬
Лере характеризуется простотой и экономичностью определения, а
также удобством для расчетов и прогнозирования.
Опыт подсказывает, что по мере увеличения размера комплекса
пРограмм возрастают не только абсолютные, но и относительные
Технико-экономическое обоснование проектов.
затраты на разработку каждой строки текста в программе. Вследст¬
вие этого затраты труда при разработке одной строки текста ц
программах разного объема могут различаться в несколько раз. Ц
[28] показано, что трудоемкость разработки программного модуля
пропорциональна квадрату размера программы. Модульно-иерархи¬
ческое построение крупных ПС позволяет замедлить квадратичный
рост сложности и соответствующей ей трудоемкости разра-ботки
при увеличении размера программ. Суммарную трудоемкость разра¬
ботки сложного ПС можно представить двумя сомножителями
Первый сомножитель является доминирующим, он прямо пропор¬
ционален размеру программ П и отражает практически линейное
возрастание трудоемкости создания любых программ при увеличе¬
нии их размера.
Однако при увеличении размера программ в ряде случаев на¬
блюдается более быстрый рост их сложности разработки, чем
описываемый простой линейной зависимостью. Логично предполо¬
жить, что по мере увеличения размера ПС возрастает относительная
трудоемкость разработки каждой строки в программе. Это обстоя¬
тельство можно учесть поправочным вторым сомножителем, от¬
ражающим изменение трудоемкости на разработку каждой строки в
программе при увеличении ее размера.
В ряде исследований размер базы данных либо совсем не
учитывается, либо включается в объем ПС. Этому способствует
также развитие теории сложности в направлении преимуществен¬
ного анализа функциональной сложности программ при почти
полном игнорировании сложности данных и их влияния на технико¬
экономические показатели. В статистической теории сложности
программ [28] показано, что для программных модулей и относи¬
тельно небольших групп программ велика корреляция между
числом имен переменных и числом операторов в программе. Одна¬
ко для сложных и сверхсложных ПС эта корреляция меньше, что
определяет необходимость разделения ПС на два типа: на осу¬
ществляющие преимущественно логическую обработку относитель¬
но небольшого потока данных и на информационно-поисковые
системы при наличии больших баз данных и относительно простой
их логической обработке. Для характеристики этих типов програм'1
может использоваться отношение числа имен переменных к числу
строк или операторов текста программ [9, 28]. Для первого типа I К-
fjiaea 3. Базовые характеристики затрат на разработку.
119
это отношение не превышает десяти процентов, а для второго оно
может значительно превышать единицу и достигать десятков и
сотен. Затраты при разработке ПС второго типа оказываются завися¬
щими от размера базы данных, который влияет на сложность
взаимодействия программ с данными.
Хотя размеры базы данных для сложных ПС по числу типов
имен переменных изменяются в очень широких пределах, приблизи¬
тельно от 103 до 108 , их непосредственное влияние на трудо¬
емкость разработки строки в программе даже при числе перемен¬
ных. в десятки раз превышающем размер программы, оценивается
на уровне 10% [2]. При этом степень этого влияния трудно форма¬
лизовать, так как большую роль играет структура базы данных и ее
функциональное назначение. Поэтому далее этот фактор отдельно
не учитывается и только для очень больших и сложных структур баз
данных рекомендуется увеличивать трудоемкость на десяток про¬
центов (см. п. 4.1).
Накопленный опыт создания ПС позволил выделить группы
факторов, влияющих на выбор технологии и на затраты С (см. рис.
3.2) [2, 13, 30]. Абсолютная величина С, так же как и длительность
разработки, зависят от ряда факторов, которые могут изменять их в
различных направлениях. Наибольшее влияние на них оказывает
размер ПС, который из всех параметров изменяется в самом широ¬
ком диапазоне. Поэтому при первичной оценке непосредственных
затрат и длительности полного цикла разработки сложных ПС раз¬
мер программ используется в качестве базового доминирующего
параметра. Остальные факторы можно учитывать поправочными
коэффициентами при уточнении интегральных показателей.
Для совокупностей ПС первого и второго классов, характе¬
ристики которых приведены в п. 2.1, исследовалась зависимость
трудоемкости разработки программ С от их объемов - П. Для аппро¬
ксимации зависимости трудоемкости от размера ПС наиболее часто
использована степенная функция вида:
C = A*lf. (3.1)
При разработке ПС большого размера в значительной степени,
Должна возрастать сложность разработки по сравнению с ПС малого
°бъема, так как в больших программах существенно усложняются
120
Технико-экономическое обоснование проектов.
взаимосвязи компонентов по информации и управлению, а также
становятся более трудоемкими процессы планирования и управле¬
ния проектом в ходе разработки. Выдвинутая гипотеза, о возраста¬
нии трудоемкости разработки с ростом размера ПС быстрее, чем ц0
линейному закону, справедлива, если показатель степени в получен¬
ном уравнении регрессии Е > 1. По методу наименьших квадратов в
ряде работ [2, 13, 30] определены коэффициенты А и Е в уравнениях
степенной регрессии, показывающие характер зависимости трудо.
емкости от размера ПС. В таблице 3.1. представлены значения
коэффициентов регрессии для моделей КОМОСТ, СОСОМО ц
ПРОМЕТЕЙ, для основных классов проектов программных средств
(см. п. 2.1). Выражение (3.1) с использованием этих коэффициентов
и значений П размера ПС в тысячах строк ассемблера рекомен¬
дуется для прогнозирования трудоемкости полной разработки в
человеко-месяцах.
Таблица 3.1
Коэффициенты моделей для оценки трудоемкости разработки
программных средств
Коэффициент
Коэффициент
Модель и тип
Источник
А
Е
программных средств
данных
2,4
1,05
Базовая - КОМОСТ
[2]
Детализированная
модель СОСОМО:
3,6
1,20
- встроенный;
[2]
3,0
1,12
- полунезависимый;
2,4
1,05
- независимый.
СССОМО 11.2000
2,94
1,15
Крупный проект
100 KSLOC
[30]
.
ПРОМЕТЕИ
10,0
1,21
Системы реального
6,1
1,17
времени;
Информационно¬
поисковые системы.
[13]
При разработке крупномасштабных ПС делаются болып>,с
затраты на создание технологии, средств автоматизации и унифик:'"
ции разработки, чем при разработке малых Г1С. Небольшие Не¬
часто разрабатываются неопытными коллективами, которые к том.'
piaea 3. Базовые характеристики затрат на разработку... 121
пренебрегают автоматизацией технологии и применением совре¬
менных методов структурного проектирования комплексов про¬
грамм. Так как малые ПС во многих случаях относятся исторически
к первому временному периоду - 70 - 90-е годы , когда уровень
автоматизации технологии был низок, то и трудоемкость их разра¬
ботки была достаточно высокой. Эти обстоятельства приводят к
тому, что возрастает трудоемкость создания относительно неболь¬
ших ПС, а рост суммарных затрат на разработку крупных ПС
замедляется, что отражается на величине показателя степени Е,
значения которого в некоторых анализируемых выборках иногда
получены меньше единицы.
Если бы представилась возможность получить ТЭП по одно¬
родной выборке ПС разного объема, разработанных по единой
технологии на более или менее одном интервале времени, то,
конечно, трудоемкость возрастала бы при увеличении 77 с коэффи¬
циентом Е > 1. На практике часто пользуются упрощенной линей¬
ной зависимостью трудозатрат от размера ПС (Е = 1). Такое
упрощение при недостаточном объеме статистических данных и
отсутствии сведений по заранее обусловленным (управляемым) зна¬
чениям факторов разработки ПС иногда можно считать допусти¬
мым.
На рис. 3.3 по уравнениям регрессии (3.1) построены в лога¬
рифмическом масштабе зависимости трудозатрат от размера для ПС
двух классов. Первый (встроенные - СРВ) и второй (ИПС) классы
ПС, отчетливо различаются по трудоемкости разработки. Более
высокой точности оценки трудоемкости разработки только по одной
переменной - размеру ПС, по-видимому, невозможно получить, так
как процесс разработки зависит от большого числа факторов (см. гл.
4), которые следует учитывать при оценке трудоемкости. Наиболь¬
шие трудозатраты обычно необходимы для разработки крупномас¬
штабных комплексов программ реального времени, так как данный
класс программ используется в наиболее ответственных автоматизи¬
рованных системах.
Затраты на разработку С и объем программ 77 могут быть свя¬
заны через показатель интегральной средней производительности
*Пруда разработчиков Р.
122
Технико-экономическое обоснование проектов
С г чел. годы
Рис. 3.3
Для учета влияния на С различных факторов удобно пользо¬
ваться коэффициентами (рейтингами) изменения трудоемкости
(КИТ) - M(i, j), учитывающими зависимость /'-го фактора от i-й со¬
ставляющей совокупных затрат. В них входят факторы процесса не¬
посредственной разработки, факторы программной и аппаратурной
оснащенности, а также квалификация специалистов (см. гл. 4). I le-
посредственно затраты на разработку можно представить как част¬
ное от размера ПС и производительности труда Р = 1 / А, корректи¬
руемой произведением коэффициентов изменения трудоемкости
(КИТ - Л/(/',/)):
rf
С = х П M(i,j) =А X if X П M(i,/). (3.2)
Р U Ч
Длительность разработки программных средств является
важнейшим технико-экономическим показателем, поскольку часто
она определяет общие сроки разработки систем, а значит, быстрот)
fjiaea 3. Базовые характеристики затрат на разработку... 123
реализации идей в различных областях автоматизации. В таблице
3.2 за начало разработки ПС принят момент начала создания
технического задания (ТЗ), а за окончание — завершение испытаний
программного продукта в целом или момент предъявления его на
испытания.
Таблица 3.2
Коэффициенты моделей для оценки трудоемкости разработки
программных средств
Коэффициент
Коэффициент
Модель и тип
Источник
G
Н
программных средств
данных
^ 2,5
0,38
Базовая - КОМОСТ
[2]
Детализированная
модель СОСОМО:
2,5
0,32
- встроенный;
[2]
2,5
0,35
- полунезависимый;
2,5
0,38
- независимый.
СССОМО 11.2000
3,67
0,328
Крупный проект
100 KSLOC
[30]
ПРОМЕТЕИ
3,51
0,31
Системы реального
3,78
0,28
времени;
Информационно¬
поисковые системы.
[13]
Диапазону размеров современных ПС в три-четыре порядка (до
10 млн. строк) соответствуют приблизительно такие же диапазоны
изменения трудоемкостей и стоимостей их разработок. Однако,
очевидна принципиальная нерентабельность разработки даже очень
сложных ПС более 5 лет. С другой стороны, программы даже в
несколько тысяч строк по полному технологическому циклу с
испытаниями как продукции редко создаются за время, меньшее,
чем полгода-год. Таким образом, вариация длительностей разрабо¬
ток ПС много меньше, чем вариация их трудоемкостей, и не превы¬
шает десятикратный диапазон. Длительности разработок Т ограни¬
чены сверху и снизу, и одним из основных факторов, определяющих
эти границы, является объем программ - П (гипотетический график
Для сложных ПС реального времени представлен на рис. 3.4).
124
Технико-экономическое обоснование проектов.
Относительный «консерватизм» значений длительностей по
сравнению с трудоемкостью определяется объективной необходи¬
мостью создавать ПС в рациональные сроки.
Т
Область „нерациональных’
длительностей
Рис. 3.4
Любые ПС должны поступать на эксплуатацию до того, как в
них пропадает необходимость. Их цели, концептуальная основа и
алгоритмы не должны устареть за время разработки. Отсюда
появляется верхний предел допустимых длительностей разработки.
Этот верхний предел не может иметь единственное значение для
любых классов и объемов ПС. Однако недопустима его вариация в
том же диапазоне, что и размер. Поэтому на практике по мере
возрастания размеров ПС увеличиваются коллективы специалистов-
разработчиков, что обеспечивает основной прирост необходимой
трудоемкости. Чем крупнее создаваемое ПС, тем большие усилия
обычно прилагаются для автоматизации и совершенствования
технологии разработки. Это также способствует замедлению рое га
длительностей разработки, однако по мере увеличения сложности
программ, длительность их разработки все же заметно возрастает.
Стремление ограничивать длительность реальных разработок
ПС приводит к объективному формированию верхнего предела. 13
которым распространяется зона «нерациональных» длительностей-
зависящих от размера и трудоемкости ПС (см рис. 3.4). Даже ДЛЯ
довольно сложных ПС, имеющих размер свыше 500 тыс. строк, вря1
J
гг
ршва 3. Базовые характеристики затрат на разработку... 125
ли допустима длительность разработки более 3-5 лет. Большие
длительности, иногда имеющиеся на практике, обусловлены в
основном низкой квалификацией разработчиков и заказчиков, не¬
достаточной автоматизацией технологии, малым коллективом спе¬
циалистов и рядом других, преимущественно организационных и
технологических причин. Подобные ситуации чаще встречаются при
относительно небольших разработках (10-50 тыс. строк), когда у
руководителей и коллектива мал опыт их проведения, следствием
чего является избыточный оптимизм в начале разработки, а также
пренебрежение технологией и организацией работ.
Границу снизу определяют естественный технологический
процесс коллективной разработки и необходимость выполнения
ряда взаимоувязанных работ на последовательных этапах, которые
обеспечивают получение ПС требуемого качества. Подготовка
текстов программ, их тестирование, комплексирование, документи¬
рование и испытания могут проводиться только последовательно, и
каждый этап требует определенного времени. Попытки форсировать
отдельные этапы работ, как правило, приводят к увеличению
продолжительности других этапов. Подключение дополнительных
специалистов увеличивает затраты на разработку и только в некото¬
рых пределах дает сокращение сроков. В некоторых случаях увели¬
чение числа специалистов может давать обратный эффект -
Длительность разработки увеличивается вместе с увеличением
затрат.
Под воздействием перечисленных факторов формируется
объективный минимум длительностей - граница снизу области
«невозможного» (см. рис. 3.4), зависящая в первую очередь от объ¬
ема, разрабатываемых ПС. Нижняя граница длительностей еще
более «консервативна», чем верхняя [13]. Изменение этой границы
возможно в небольших пределах только за счет совершенствования
технологии, повышения программной и аппаратурной оснащенности
Разработки, а также роста коллективной квалификации разработ¬
чиков и заказчиков.
Практическая граница «нерациональных» длительностей имеет
качения, приблизительно вдвое большие, чем значения границы
^невозможных» длительностей, при том же объеме ПС. Это
°тначает, что даже большие усилия по автоматизации и организации
126
Технико-экономическое обоснование проектов.
разработки программ приводят к сокращению длительностей только
в 2 - 3 раза, в то время как трудоемкость уменьшается значительно
больше. По результатам реальных разработок может быть оценена
средняя или наиболее вероятная длительность разработок ПС
определенного класса при заданных условиях. Конкретное распре¬
деление длительностей зависит от исходных данных, имеющихся в
базе данных технико-экономических показателей завершенных
разработок, и от метода их усреднения.
Для конкретного планирования длительностей создания ПС оп¬
ределенных классов необходимо для каждого предприятия исследо¬
вать и обобщать технико-экономические показатели реальных разра¬
боток, однородных по технологии и другим условиям. Такие
обобщения при конкретных условиях разработок позволяют полу¬
чить опорные абсолютные значения длительностей для некоторых
размеров ПС. Эти абсолютные значения могут быть использованы
для расчета коэффициентов регрессии с целью прогнозирования
длительностей разработок на базе выявленных закономерностей и
реальных опорных значений для конкретных условий разработки.
Обобщенные данные длительности разработки Т по классам
программ в ряде работ [2, 13, 30] аппроксимировались уравнениями
регрессии по методу наименьших квадратов в зависимости от
размера ПС и от трудоемкости их разработки (таблица 3.2):
Т— G * Сн. (3.3)
Зависимости Т от размера программ 77 значительно разли¬
чаются для классов ПС. Это определяется различием сложности
классов программ, применяемых языков программирования и
единиц измерения объема ПС, следствием чего является различие
значений размера созданных программ при одной и той же
длительности и трудоемкости разработки. Чтобы исключить ошио-
ки, связанные с неопределенностью измерения размера программ
исследована зависимость длительности разработки от ее труд0'
емкости (рис. 3.5). Учитывалась только трудоемкость непосрсде1'
венной разработки программ С без затрат на средства автоматизации
разработки. Обработка тех же, что выше, наборов данных позволила
получить коэффициенты уравнения регрессии представленные в
таблице 3.2. Средние значения длительности разработки классов Ч
лава 3. Базовые характеристики затрат на разработку... 127
актически не различаются в зависимости от трудоемкости
работки программ.
Оценка требуемого среднего числа специалистов для кон-
етного проекта ПС предварительно может быть рассчитана путем
деления оценки величины трудоемкости разработки (3.2) на дли¬
тельность разработки (3.3). Однако рациональное число специали¬
стов, участвующих в проекте ПС распределяется не равномерно по
Ьгапам работ. Поэтому целесообразно определять число и квалифи¬
кацию необходимых специалистов с учетом этапов разработки ком¬
плексов программ. Эти задачи рассмотрены отдельно в п.3.3.
Рис. 3.5
Средняя производительность труда коллектива специалистов
при разработке сложного полностью нового комплекса программ Р в
Сражении (3.2) может служить ориентиром для сравнения эффек¬
тивности труда при создании различных проектов ПС. Эта характе¬
ристика, конечно, различается для различных классов, размеров и
других параметров комплексов программ, однако диапазон этих раз¬
личий не столь велик как изменения размера, требований к качеству
и*ругих параметров. Так при диапазоне изменения размеров про¬
128
Технико-экономическое обоснование проектов
грамм СРВ на четыре порядка средняя производительность труда
изменяется только в два раза, что в ряде случаев существенно облег¬
чает упрощенные оценки и прогнозирование ТЭП (см. п. 5.1).
При разработке программных модулей и компонентов отдель¬
ными специалистами или небольшими группами производитель¬
ность труда при написании одних и тех же текстов автономных про¬
грамм может различаться в десяток раз в зависимости от их таланта
и трудоспособности и достигать тысяч строк за человеко-месяц. Од¬
нако достаточно полное тестирование, документирование, комплек-
сирование и оформление в крупные комплексы программного про¬
дукта, приводят к снижению интегральной производительности до
величин в несколько сотен строк текста за человеко-месяц. Для
крупных проектов класса СРВ 80-е годы в [2] приводятся величины
100 - 150 строк на человеко-месяц, в отечественных проектах в те
же годы [13] эта величина приближалась к 80 - 100. Совершенство¬
вание технологии, квалификации специалистов и инструменталь¬
ных средств автоматизации разработки позволили в последние годы
повысить среднюю производительность труда при создании полно¬
стью новых оригинальных программных продуктов СРВ в несколь¬
ко раз по экспертным оценкам до величин 300 - 500 строк на чело¬
веко-месяц.
При разработке ПС необходимо учитывать, что экономические,
временные, вычислительные и другие ресурсы на разработку и весь
ЖЦ программ всегда ограниченны и используемые затраты для
улучшения каждой характеристики должны учитывать эти ограни¬
чения. Для рационального распределения этих ресурсов необходимо
знать как отражается изменение затрат на улучшении каждой
характеристики качества ПС. Эта взаимосвязь затрат ресурсов и
значений каждой характеристики зависит от назначения, а также от
ряда свойств и других особенностей комплекса программ, что ус¬
ложняет учет влияния таких связей. Тем не менее, выявлены основ¬
ные тенденции такого взаимодействия, которые могут служить ори¬
ентирами при выборе и установлении требований к определенны'1
характеристикам качества в конкретных проектах ПС.
fjiaea 3. Базовые характеристики затрат на разработку... 129
3.2. Оценка затрат на разработку программных средств ра базе
повторного использования готовых программных компонентов
Основные факторы, влияющие на эффективность повтор¬
ного использования готовых компонентов при разработке ком¬
плексов программ. При полностью оригинальной разработке новых
программных компонентов и ПС в целом, повышению производи¬
тельности труда и других ТЭП способствует применение ряда
методов и средств автоматизации труда разработчиков. При этом
каждый метод более или менее одинаково улучшает ТЭП разработ¬
ки ПС и отсутствуют радикальные методы и средства, значительно
превышающие по эффективности все остальные. Только совместное,
комплексное использование в последние годы наиболее эффектив¬
ных методов и средств автоматизации позволило повысить произво¬
дительность труда специалистов и улучшить другие ТЭП в процессе
создания ПС «с нуля», т.е. без использования ранее отработанных
программных компонентов. Однако такое улучшение ТЭП не
беспредельно, и наметились тенденции приближения к некоторым
значениям производительности труда, которые трудно преодолеть,
особенно при коллективном создании крупномасштабных ПС.
Эффективность выделения компонентов для повторного ис¬
пользования зависит от размера создаваемых Г1С и кратности воз¬
можного их применения. При разработке ПС небольшого объема
(тысячи строк исходного текста) поиск и подбор готовых компонен¬
тов для их применения в новом ПС чаще всего не рентабельно.
Таким образом, существует некоторый диапазон размеров ПС
(«докритическая масса»), для которых нецелесообразно искать
готовые компоненты и применять «сборочное программирование»
из таких компонентов. Разработка на базе повторно используемых
компонентов (ПИК) становится особенно рентабельной для
сложных ПС, содержащих сотни или тысячи модулей. Поэтому
ниже анализируются ТЭП только крупных ПС объемом в 100 - 1000
тыс. строк.
Кратность применения компонентов также значительно влияет
на эффективность сборочного программирования. Особенно тща¬
тельную отладку и оформление документации целесообразно прово¬
дить для тех компонентов, которые в перспективе будут использо¬
130
Технико-экономическое обоснование проектов
ваться многократно различными специалистами и в разных проек¬
тах. При анализе ТЭП конкретных разработок ПС трудно предви
деть кратность повторного использования компонентов в будущих
проектах. Поэтому ниже затраты на их создание рассматриваются
отдельно или включены в характеристики первого образца ПС, в
котором они применены.
Любые ПС функционируют в среде ОС ЭВМ и типовых сер¬
висных средств, расширяющих их эксплуатационные возможности
Эти системы в большинстве случаев универсальные и применяются
при создании различных ПС. Поэтому далее многократное примене¬
ние ОС и их дополнительных средств не учитывается. Эффектив¬
ность повторного использования программных компонентов анали¬
зируется в пределах базовых версий ПС, создаваемых для решения
конкретных функциональных задач в соответствии с техническим
заданием.
Быстрый рост масштабов - размеров комплексов программ и
баз данных, решающих единую целевую задачу, потребовал созда¬
ния новых, более эффективных методов разработки сложных
систем. Возникла проблема разработки функционально законченных
ПС и БД и их компонейтов, потенциально готовых к многократном)
применению в различной внешней и операционной среде, а также в
различных сочетаниях их взаимодействия. Методы системного
анализа, описания функциональных и информационных моделей
предметной области, формализации спецификаций, функциональной
декомпозиции программных комплексов и последовательной дета¬
лизации проектов ПС позволили применять готовые решения в
различных формах и сочетаниях. Появились возможности повтор¬
ного использования программ и данных на разных уровнях описа¬
ния, относящихся к разным этапам их жизненного цикла.
Высокие темпы роста основных ресурсов аппаратных средств
ЭВМ и сохраняющаяся потребность в увеличении их использования
со стороны пользователей приводят к необходимости адекватного
совершенствования технологий создания программных средств и баз
данных. Гибкость модификации ПС при развитии, обеспечивается
рядом принципов и правил структурного построения комплексов
программ и компонентов, а также взаимодействия между ними. Эя'И
правила направлены на стандартизацию и унификацию струкш)'
ры и взаимодействия компонентов разного ранга и назначения и
"лава 3. Базовые характеристики затрат па разработку... 131
пределах проблемной области. Некоторая часть принципов и правил
имеет достаточно общий характер и может применяться практичес¬
ки всегда. Другая часть предполагает проблемную ориентирован¬
ность класса ПС, подлежит отработке для эффективного применения
в соответствующей области и отражает [14]:
- стандартизированную структуру ПС или БД определенного
класса;
- унифицированные правила структурного построения про¬
граммных компонентов;
- стандартизированную структуру баз данных, обрабатывае¬
мых программами;
- унифицированные правила структурного построения
информационных модулей, заполняющих базу данных;
- унифицированные правила структурного построения и
организации межмодульного интерфейса программных компонен¬
тов;
- унифицированные правила внешнего интерфейса и взаимо¬
действия компонентов ПС и БД с внешней средой, с операционной
системой и другими типовыми средствами организации вычисли¬
тельного процесса и контроля.
Таким образом, для обеспечения эффективной разработки и
сокращения затрат необходимо формулировать и соблюдать ряд
принципов и правил структурного построения ПС. Эти принципы и
правила могут иметь особенности в различных проблемно¬
ориентированных областях. Однако их формализация и выполнение
обеспечивают значительное снижение трудоемкости и длитель¬
ности разработки ПС, БД и их версий. Потеря гибкости архитек¬
туры ПС, некоторое возрастание ресурсов, необходимых для их
реализации, обычно полностью компенсируются повышением тех¬
нико-экономических показателей процессов разработки ПС.
Унификация всегда требует некоторых ресурсов, которые в
Данном случае, выражается в дополнительной трудоемкости созда¬
ния повторно используемых программ и данных, а также в увеличе¬
нии необходимой памяти и производительности ЭВМ для их реали¬
зации. Сохранение и развитие довольно широкого спектра архитек-
typ ЭВМ, естественно привело к повторному использованию компо¬
зитов не только на однотипных платформах, но и к разработке ПС
и БД, переносимых на различные аппаратные и операционные
132
Технико-экономическое обоснование проектов.
платформы. Таким образом, выделились две технологические про¬
блемы [14]:
- создание программных компонентов и баз данных, которые
рентабельно повторно применять и/или переносить на различные
операционные и аппаратные платформы;
- проблема реализации повторного использования и/или
переноса ПС и БД для создания из них новых систем на иных плат¬
формах.
Увеличение затрат при решении первой проблемы должны
были компенсироваться сокращением затрат при создании комплек¬
сов программ и баз данных на базе готовых компонентов. Освоение
методов и средств решения этих проблем позволило качественно
изменить процессы создания сложных комплексов программ и
резко повысить производительность труда специалистов при их
разработке. Это активизировало в последние годы интерес к пробле¬
ме мобильности программ и данных во всех отраслях применение
вычислительной техники. Создание новых ПС и БД путем переноса
их с других аппаратных и операционных платформ стало особенно
актуальным для современных административных систем государст¬
венного и регионального управления, управления отраслями и
предприятиями, а также банковскими системами и в социальной
сфере.
Поставки и закупки вычислительной техники зачастую произ¬
водятся с позиции только низкой цены без анализа возможности их
взаимодействия в распределенной информационной системе опре¬
деленного функционального назначения и наличия соответствую¬
щих готовых прикладных ПС и БД. В этих областях теперь имеется
широкий спектр типовых компонентов, которые могут быть исполь- j
зованы в различных сочетаниях для решения различных функцио- j
нальных проблемно-ориентированных задач. При их решении требо- I
вания к эффективности использования ресурсов ЭВМ не столь
жесткие как десятки лет назад и могут быть унифицированы интер¬
фейсы между компонентами. Таким образом выявилась необходи¬
мость и сложились благоприятные условия для эффективного
применения современных технологий создания приложений путем |
переноса и повторного использования компонентов ПС и БД 113
различных аппаратных и операционных платформах [14, 29, 48].
piaea 3. Базовые характеристики затрат на разработку.
133
Во многих случаях компоненты, комплексы программ и ин¬
формация БД создавались и разрабатываются без ориентации на
последующее повторное использование и перенос на иную аппа-
шпгную и операционную платформы. Это обусловлено отсутст¬
вием стремления у разработчиков доводить программы и их доку¬
ментацию до уровня завершенных коммерческих продуктов, а также
практическим отсутствием опыта и знаний о современных методах
создания мобильных ПС и БД высокого качества. Подавляющее
большинство международных стандартов, регламентирующих
создание переносимых приложений, не доступны отечественным
специалистам из-за низкой системной и программистской культуры
и отсутствия стремления освоить и использовать современные
зарубежные стандарты. Огромный парк унаследованных ПС и их
компонентов разработан под конкретные платформы и является по¬
тенциально мобильным только в пределах, расширяющихся по па¬
раметрам моделей ЭВМ определенных архитектур.
При анализе и технико-экономическом обосновании рента¬
бельности разработки комплексов программ и данных на базе гото¬
вых компонентов путем их переноса с другой аппаратной или опе¬
рационной платформы в первую очередь необходимо учитывать
[14]:
- степень подобия архитектуры и соотношения основных па¬
раметров ресурсов аппаратных платформ, между которыми предпо¬
лагается перенос готовых компонентов;
- уровень унификации интерфейсов приложений с операцион¬
ными платформами, между которыми предполагается перенос гото¬
вых прикладных программ и данных;
- наличие или отсутствие при разработке исходных программ
н информации баз данных ориентации на будущий перенос и по¬
вторное использование на других платформах.
Различия операционных систем, принципов организации вы¬
числительного процесса и контроля функционирования, а также
Драйверов ввода-вывода могут практически полностью исключить
эффективный автоматизированный перенос соответствующей части
Унаследованных готовых компонентов между разнотипными по ар¬
хитектуре ЭВМ. Важнейшим фактором, влияющим на рентабель¬
ность переноса, является степень унификации интерфейсов при-
-й/жений с операционной и внешней средой и с пользователями.
134
Технико-экономическое обоснование проектов
Применение одних и тех же стандартизированных языков програм.
мирования и аттестованных компиляторов позволяет значительно
сокращать затраты при переносе. Создание современных сложных
ПС целесообразно вести с использованием совокупности междуна¬
родных стандартов Открытых систем, значительная часть которых
обеспечивает мобильность программных средств и информации баз
данных [29, 45, 48].
Различие архитектуры и ресурсов ЭВМ, между которыми
предполагается перенос программ и данных, является важнейшим
фактором, определяющим эффективность повторного использова¬
ния компонентов и ПС. В состав этих параметров входят номенкла¬
тура и специфика реализации операций ЭВМ, структура и особенно¬
сти системы адресации, структура и разрядность памяти, особенно¬
сти реализации системы ввода-вывода и т.д. Значительные трудно¬
сти может вызывать или делать практически не рентабельным пере¬
нос программ и данных, существенное различие производительно¬
сти и памяти рассматриваемых ЭВМ. Особое значение для перено¬
симости ПС и БД имеет специфика реализации взаимодействия с
внешней средой и процедур ввода-вывода в ядре операционных систем
сопоставляемых ЭВМ. Программы, реализующие эти функции
должны отражать специфику конкретной системы ввода-вывода и
особенности источников и потребителей информации. Такая ориен¬
тация программ ввода-вывода может делать их практически не пе¬
реносимыми и требовать выделения в автономные, заново разраба¬
тываемые, автоматизировано непереносимые процедуры.
Языки программирования отражаются на переносимости
программ и данных тем сильнее, чем больше различается архитек¬
тура ЭВМ и чем ниже уровень языка. Повышение уровня языка про¬
граммирования сопряжено с повышением универсальности текстов
программ и уменьшением их машинной зависимости. Одновременно
уменьшается эффективность объектного кода и расширяется испол¬
няемый текст программ, получаемых в результате трансляции. 1;1'
ким образом, за снижение трудоемкости разработки программ путем
переноса на различных языках, приходится расплачиваться увеличе¬
нием памяти для размещения и времени при их исполнении на но¬
вой ЭВМ.
Затраты на проектирование базовой версии ПС в завЧ'
симости от доли ПИК и на сборку из них комплексов программ
fjiaea 3. Базовые характеристики затрат на разработку.
135
непосредственно определить трудно. Для косвенной оценки полной
трудоемкости разработки новой базовой версии ПС, без применения
сборочного программирования, выделим и исключим часть, которая
обусловлена затратами на создание ПИК, примененных готовыми в
данной базовой версии [13]. Эти затраты приходятся, в основном, на
|>гапы программирования и автономной отладки компонентов, а
также частично на остальные этапы. На этих этапах сокращению
затрат способствует также накопленный опыт создания предшест¬
вующих базовых версий. Однако на начальных и конечных этапах
разработки трудно оценить влияние этого опыта и использования
компонентов. Поэтому, далее анализируются в основном этапы про-
|рамммирования и автономной отладки полностью новых ПИК.
. Предположим, что каждый А-й этап (из г этапов) разработки
при полном цикле создания ПС с необходимым комплексом ПИК
характеризуется относительной долей qk от полной трудоемкости С,-
создания /'-й версии ПС. На каждом этапе выделим долю труда,
которую можно отнести к созданию компонентов gk < 1, а осталь¬
ную часть будем считать относящейся к системному анализу, сборке
и комплексированию компонентов. В первом приближении можно
предположить, что gk зависит от доли ПИК Д линейно в некоторых
пределах от 1 до gk в зависимости от этапа разработки.
В этих этапах в различной степени присутствует творческий и
технический труд. Создание ПИК менее творческий процесс, чем их
комплексирование, что желательно было бы учесть при анализе.
Однако экспериментальные оценки доли творческого труда имеются
только для полного процесса разработки ПС без разделения частей,
относящихся к созданию и к сборке ПИК, которая далее не
УЧ|ггывается.
Опыт проектирования предшествующих (/— 1 )-й версии ПС
может достаточно сильно отражаться, на относительной трудоем¬
кости этапов разработки очередной /-й базовой версии ПС. Влияние
этого фактора можно учесть коэффициентом / кк(Д), который также
зависит от доли ПИК (Д) в данной базовой версии. В результате
°тносительное снижение трудоемкости А-го этапа разработки за счет
Повторного использования программных компонентов и опыта
Предшествующих проектов аналогичных ПС можно представить
Произведением /,к{Ц) х gk (Д), оба сомножителя которого зависят от
136
Технико-экономическое обоснование проектов
доли ПИК в данной версии ПС. Для определения коэффициента
изменения трудоемкости при создании /-й базовой версии с
помощью сборочного программирования необходимо учесть рощ,
каждого этапа и долю снижения трудоемкости на этапе за счет ПИК
г
С, = 1<7*Л*СДЬСД) (3.4)
k = 1
Таким образом, для аналитической оценки эффективности
сборочного программирования необходимы характеристики измене¬
ния трудоемкости от этапов разработки и влияния доли ПИК на
трудоемкость этапов. Эти данные только частично получены экспе¬
риментально (см. п. 3.3), а влияние доли ПИК на /,к(Д) и gk(JJ)
приходится оценивать, используя правдоподобные гипотезы и воз¬
можные варианты.
В приведенных оценках значительную роль могут играть пер¬
вичные капиталовложения в создание технологии и аппаратурное
обеспечение средствами вычислительной техники. Эти виды затраз
сосредоточиваются в разработке первой базовой версии Г1С и в
дальнейшем могут не учитываться. В некоторых случаях их можно
распределять как амортизационные расходы по всем базовым
версиям ПС более или менее равномерно.
Оценка изменения трудоемкости разработки ПС за счет
повторного использования компонентов. Рассмотрим оценки из¬
менения трудоемкости (КИТ) С(Д) в зависимости от доли готовых
ПИК Д из полного размера программ в разрабатываемом ПС. Для
этого воспользуемся выражением (3.4). Так как отсутствуют экспе¬
риментальные зависимости /■,* (Д) и gk(/D, то оценки проведем для
простейшего случая Д = 1 или 100% при некоторых частных пред¬
положениях о значениях/,-,*( 1) и gk (1) на этапах разработки [13].
Предельный выигрыш в трудоемкости разработки ПС, собирае¬
мого целиком из ПИК (Д= 100%), можно оценить на основе распре¬
деления затрат по этапам, разработки (таблица 3.3) следуют»*1
образом. Выделим два варианта разработки: при практически
полном отсутствии системной и функциональной преемственное! и
нового ПС с предшествующими разработками и при наличии про'0'
типов - версий, значительно сокращающих начальные этапы прое*'
тирования, а также комплексную отладку. В обоих вариантах ирс4'
полагается, что i-я базовая версия ПС создается из полного набор3
J
fjiaea 3. Базовые характеристики затрат на разработку... 137
г0товых ПИК и отсутствует необходимость разработки дополни¬
тельных программных компонентов.
В первом варианте полное отсутствие преемственности версий
flC приводит к необходимости полного проведения предваритель¬
ного и детального проектирования, отбора и контроля, подлежащих
использованию компонентов, их комплексной отладки и испытаний.
Хаким образом, трудоемкость сокращается только за счет исключе¬
ния этапов программирования и автономной отладки программных
компонентов в процессе рабочего проектирования. Трудоемкость
этих этапов для программ СРВ составляет около 50% от полной
трудоемкости при отсутствии ПИК (см. табл. 3.3).
Таблица 3.3
Распределение затрат по этапам разработки программных средств
реального времени
Этапы
разработки
Трудоем¬
кость,
%
Длитель¬
ность,
%
Численность
специалистов,
% от средней
1. Предварительное про¬
ектирование
8
20
40
2. Детальное проектиро¬
вание
14
20
70
3. Программирование
22
16
140
4. Автономная отладка
компонентов
24
16
150
5. Интеграция и комп¬
лексная отладка
24
20
120
6. Испытания и доку¬
ментирование
8
8
100
Таким образом, суммарная трудоемкость в данном варианте
уменьшается для этих классов ПС соответственно почти в 2 раза
(рис. 3.6).
Во втором варианте предварительное проектирование может
не проводиться и значительно сокращается детальное проектиро¬
вание. Предположим, что суммарная трудоемкость этих этапов так
^е, как этапа комплексной отладки, сокращается вдвое. Тогда на эти
этапы остается около 23% суммарной трудоемкости для СРВ (см.
табл. 3.3).
138
Технико-экономическое обоснование проектов
Учитывая необходимость полных испытаний нового ПС (около
8% трудоемкости), суммарную трудоемкость разработки можно
оценить, в 30% для СРВ (см. рис. 3.6). Таким образом, за счет
повторного использования компонентов в этом варианте трудоем¬
кость уменьшается соответственно в 3 раза.
Рис. 3.6
В процессе совершенствования сборочного программирования
с ПИК возможно некоторое дополнительное снижение затрат при
детальном проектировании и комплексной отладке. Однако итоговое
снижение трудоемкости (или повышение эквивалентной производи¬
тельности труда) при рассмотренных предположениях вряд ли
ревысит пятикратное (С = 0,2). Такое снижение, по-видимому>
максимальное при различии функциональных характеристик вновь
создаваемого ПС. При этом наличие динамической комплексной
отладки ПС для СРВ заметно снижает эффективность сборочного
программирования по сравнению с эффективностью при разработке
ИПС, и является существенным ограничением снижения трудосм"
кости для ПС этого класса.
fjiaea 3. Базовые характеристики затрат на разработку... 139
Применение сборочного программирования возможно и при
глубокой функциональной преемственности последовательно разра¬
батываемых проектов ПС. В этих случаях доля затрат на системный
анализ, техническое проектирование, комплексирование, отладку и
испытания может быть значительно меньше приведенных оценок.
Вследствие этого эффективность сборочного программирования
соответственно повысится. В этих случаях более эффективной
становится разработка набора адаптируемых компонентов и их
настройка на параметры среды применения.
На практике, при создании нового ПС, не всегда имеется
полный набор готовых и пригодных для применения программ¬
ных компонентов. Тогда при сборке версии ПС может потребо¬
ваться доработка отдельных компонентов, их сопряжение в новых
сочетаниях и создание новых программ для решения дополнитель¬
ных задач. Поэтому целесообразно оценить трудоемкость сбороч¬
ного программирования с учетом частичных затрат на новые компо¬
ненты. Относительное снижение трудоемкости разработки в первом
приближении пропорционально доле готовых ПИК. В пределе при
создании базовой версии ПС полностью из многократно применя¬
емых готовых компонент, как показано выше, трудоемкость может
сократиться в 3 - 5 раз. В промежуточных случаях, когда готовые
компоненты используются частично, оценку изменения трудоем¬
кости можно провести по степени сокращения затрат на программ-
мирование и автономную отладку всех необходимых компонентов.
В результате могут быть получены практически линейные зависи¬
мости коэффициентов изменения трудоемкости от доли ПИК для
СРВ (см. рис. 3.6).
Оценка изменения длительности разработки ПС за счет
повторного использования компонентов. Экспериментально уста¬
новлено [2, 13], что длительность разработки ПС труднее подвер¬
нется изменениям при автоматизации разработки или другими ме¬
тодами, чем трудоемкость или производительность труда. Необхо¬
димость выполнения при разработке ПС определенной совокуп¬
ности этапов и операций в заданной технологической последова-
Тольности остается более или менее постоянной при различных воз¬
действиях на процесс разработки. Исключением является примене¬
ние ПИК, при котором значительно сокращаются этапы программ¬
ирования и автономной отладки модулей и групп программ, а также
140
Технико-экономическое обоснование проектов
в той или иной степени длительность других этапов. Рассмотри^
оценки возможного уменьшения относительной длительности разра¬
ботки ПС, при поэтапном сокращении времени в вариантах
аналогичных анализировавшимся при оценке трудоемкости.
В первом варианте наличия полного набора программных
компонентов при оценке можно исключить программирование и
отладку компонентов. В результате длительность разработки про¬
граммных комплексов СРВ уменьшается на 32% (в 1,5 раза) (рис.
3.7). Во втором варианте за счет наличия прототипов и систем¬
ного задела на проектирование, а также на комплексную отладку,
можно ускорить разработку вдвое. Тогда длительность разработки
программ СРВ сократится дополнительно на 30%. В результате пол¬
ная длительность будет определяться половиной времени перечис¬
ленных этапов и полной длительностью испытаний и составит 38%
для СРВ от суммарной длительности разработки без повторного
использования компонентов.
Рис. 3.7
Таким образом, в этом варианте Тр уменьшается соответствен'
но в 2,5 раза. Если необходимо вновь создать некоторую часть
J
fjiaea 3. Базовые характеристики затрат на разработку... 141
программных компонентов, полная длительность разработки может
мало измениться по сравнению с разработкой без ПИК. Это
объясняется тем, что длительность программирования и автономной
отладки компонентов относительно слабо зависит от того, какое их
количество предстоит создать. Поэтому зависимость Т, от доли ПИК
оказывается нелинейной, и заметное сокращение длительности
разработки проявляется только при создании базовой версии ПС
практически полностью из готовых компонентов (см. рис. 3.7).
' Относительное изменение длительностей разработки заметно
меньше при повторном использовании компонентов, чем изменение
трудоемкости. Это обусловлено сравнительно небольшой долей
^атрат времени на разработку ПИК. На этапах программирования и
автономной отладки рост необходимой трудоемкости обеспечи¬
вается в основном увеличением численности специалистов. В то же
время, длительность начальных этапов и комплексной отладки
нельзя практически ускорить, привлекая дополнительных специа¬
листов. Эти этапы значительно сокращаются, только если исполь¬
зовать системный задел и прототипы, а также отработанные методы
и средства при комплексной отладке. Тем не менее, эти обстоя¬
тельства слабее отражаются на изменении длительности, чем на
изменении трудоемкости.
Основными целями создания и применения концепции, ме¬
тодов и стандартов Открытых систем является повышение
общей экономической эффективности разработки и функциониро¬
вания информационных систем, а также логической и технической
совместимости их компонентов, для обеспечения повторного
использования программ и данных. Для достижения этих целей
развиваются и применяются различные проблемно-ориентирован¬
ные технологии и комплексы средств автоматизации ЖЦ программ
и баз данных, базирующиеся на повторном использовании апроби¬
рованных программных компонентов и данных, их эффективном
переносе на различные аппаратные и операционные платформы и
согласованном взаимодействии в распределенных системах. Кон¬
цепция Открытых систем - это совокупность международных
стандартов в области информационных технологий, которая специи-
Фицирует интерфейсы, услуги и поддерживающие форматы для
Достижения взаимодействия и переносимости приложений, данных
и персонала, достаточные для того, чтобы обеспечить [29, 45]:
142
Технико-экономическое обоснование проектов.
- возможность переноса (мобильность) компонентов ц
комплексов программ и данных, разработанных должным образом, с
минимальными изменениями на широкий диапазон информацион¬
ных платформ;
- совместную работу (интероперабельность) с другими при¬
кладными системами на локальных и удаленных платформах;
- взаимодействие с пользователями в стиле, облегчающем
последним переход от системы к системе {мобильность пользова¬
телей).
Открытые системы делают доступным пользователям широкий
круг прикладных ПС и БД, позволяют фирмам сэкономить средства
на документации и переподготовке персонала, а кроме того делают
их независимыми от конкретного поставщика программного и
аппаратного продукта. При этом каждое решение при создании
информационной системы должно обеспечивать интероперабель¬
ность, переносимость, межплатформенную интеграцию и эффектив¬
ное использование ресурсов распределенной обработки. Построение
открытых систем из унифицированных по взаимодействию продук¬
тов стимулирует конкуренцию среди поставщиков как по соотно¬
шению цена/производительность, так и по функциональным воз¬
можностям. Профессионалы в области открытых систем акценти¬
руют усилия на поиске и создании гибкой, способной к наращива¬
нию среды, что базируется на трех направлениях стандарти¬
зации:
- стандартизация аппаратных и операционных платформ;
- стандартизация методов и технологии обеспечения жизнен¬
ного цикла прикладных программных средств и баз данных;
- стандартизация интерфейсов приложений между собой, с
операционной и внешней средой.
Развивающаяся инфраструктура открытых систем базируется
на интеграции компонентов для удовлетворения требований с
использованием стандартов на интерфейсы ПС с операционной и
внешней средой для последующего широкого применения. Весь
процесс создания и развития конкретных открытых систем реали¬
зуется путем преодоления противоречий между требованиями сегод¬
няшнего дня и потенциальными перспективами развития версий ПС
по производительности, гибкости и внедрению инноваций.
fjiaea 3. Базовые характеристики затрат на разработку... 143
Идеология открытых систем существенно отражается на ряде
направлений развития современных ПС. Она базируется на строгом
Соблюдении совокупности протоколов и стандартов де-юре и де¬
-факто. Программные и аппаратные компоненты по этой идеологии,
должны отвечать двум важнейшим требованиям: переносимости и
возможности согласованной, совместной работы с другими удален¬
ными компонентами. Это позволяет обеспечивать совместимость
различных информационных систем и средств передачи данных.
Задача сводится к максимально возможному повторному исполь¬
зованию разработанных и апробированных программных и ин¬
формационных компонентов при расширении ПС, изменении вы¬
числительных аппаратных платформ, их операционных систем и
процессов взаимодействия. Для реализации перечисленных целей с
начала 80-х годов активно развиваются два направления идеологии,
концепции и системы стандартов открытых систем [14, 29,36, 45]:
- открытых вычислительных систем (open computing
systems - OCS), обеспечивающее возможность относительно просто¬
го и эффективного по трудоемкости переноса апробированных
программных средств и информации баз данных на различные типы
аппаратных платформ за счет стандартизации процессов и интер¬
фейсов взаимодействия прикладных программ с операционными
системами ЭВМ;
- взаимосвязи открытых систем (open systems interconnec¬
tion - OSI), унифицирующее структуру, процессы и интерфейсы для
обеспечения совместимости методов и средств обмена данными
между разнотипными удаленными ЭВМ, а также поддерживающее
возможность предварительного выбора типов и ресурсов ЭВМ в
^ответствии с потребностями для решения конкретных прикла¬
дных задач.
В первом направлении основной задачей является транспорти¬
ровка и перенос функций и процедур обработки информации, а
также содержания баз данных между различными платформами,
осуществляющими ее обработку. Подобные обмены функциями,
процедурами и данными имеют неоперативный характер и могут
осуществляться вне реального масштаба времени. Проблемы состо¬
ит преимущественно в обеспечении сохранности апробированного
Функционального ядра текстов программ и информации баз данных
144
Технико-экономическое обоснование проектов.
при их переносе на иные аппаратные и операционные платформы
для снижения трудоемкости создания ПС и БД.
Во втором направлении основную роль играет оперативная
транспортировка данных между компонентами систем в реальном
масштабе времени. Проблема заключается в обеспечении совмести¬
мости различных систем передачи данных и эффективном исполь¬
зовании распределенных вычислительных ресурсов для обработки
информации. Основной экономический эффект в этом случае дости¬
гается за счет сокращения дополнительных преобразований данных
на стыках коммуникационных средств и повышения тем самым
степени полезного использования вычислительных и коммуни¬
кационных ресурсов.
Важнейшими, объединяющими целями развития обоих направ¬
лений открытых систем являются снижение трудоемкости и дли¬
тельности создания, а также повышение качества и функцио¬
нальных возможностей современных информационных систем. В
этих двух направлениях развиваются соответствующие концепции и
методы, которые формализуются и детализируются комплексами
стандартов. Для каждого направление характерно развитие методов
и стандартов, ориентированных преимущественно на его поддержку
и реализацию, а также некоторой общей части для обоих направ¬
лений. Таким образом выявились достаточно автономные части
каждого направления и объединяющая их часть - методы и стан¬
дарты открытых систем.
Технология открытых систем для повторного использования
компонентов и переноса ПС на иные платформы наиболее сильно
отражается на сокращении затрат ресурсов при создании крупных
административных систем обработки информации (класс ИПС). При
этом возможно снижение трудоемкости в 10 - 15 раз, длительности
в 5 - 8 раз и числа специалистов почти вдвое относительно значении
при полной разработке без применения современной технологии
переноса и ПИК. Эффективность переноса программ систем реаль¬
ного времени (СРВ) значительно ниже, чем в предыдущем случае,
вследствие высокой доли затрат на перепрограммирование компо¬
нентов и интерфейсов, а также на постановку и освоение техноло¬
гии на новой платформе. Для этого класса ПС при переносе труД0'
емкость уменьшается в 4 - 5 раз, длительность в 2 - 3 раза, а необ'
fjiaea 3. Базовые характеристики затрат на разработку... 145
родимое число специалистов менее, чем в два раза относительно
полной разработки без ПИК.
Экспериментальные оценки эффективности повторного
использования программных компонентов в реальных проектах
довольно ограничены [14, 45, 48]. Эффективность затрат при полной
сборке ПС в зависимости от доли ПИК зачастую оценивалась путем
анализа эквивалентной производительности труда разработчиков
и длительности создания ПС. При этом учитывалась особенность
рассчитываемой производительности труда, отражаемой термином
«эквивалентная». При сборке версии ПС из готовых программных и
информационных копонентов не всегда учитывались первичные
затраты на их создание. Трудоемкость разработки ПИК включалась
только в первую базовую версию, где они применялись впервые. В
последующих базовых версиях ПС учитывалась трудоемкость рабо¬
чего проектирования, комплексирования и испытания комплекса
программ, а также трудоемкость разработки тех новых программ¬
ных компонентов, которые впервые создавались для данной базовой
версии ПС.
Пример [14]. Доля ПИК от общего числа компонентов в
базовой версии ПС в примере применялась в качестве параметра,
относительно которого определялось изменение производитель¬
ности труда и длительности разработки. Экспериментальные значе¬
ния изменения производительности труда от доли Д (%), исполь¬
зуемых готовых компонентов при разработке серий базовых версий
ПС, оценивались для однотипных встраиваемых ЭВМ в системах
^правления и обработки информации, функционирующих в реаль¬
ном времени. Исследованные комплексы программ были близки по
функциональному назначению и составу задач. В каждом из них
использовалось около 800 разных программных модулей при общем
числе более 2 тыс. модулей. Таким образом, в среднем модули
Использовались трижды, хотя стандартные программы, компоненты
организации контроля вычислительного процесса, а также некото¬
рые функциональные программы применялись почти одинаковыми
во всех проектах. Две первые базовые версии ПС почти не имели
ПИК, а в последующих версиях доля их постепенно возрастала.
Значительный разброс производительности труда обусловлен неко-
т°рыми неучтенными факторами, однако тенденции роста произ¬
водительности труда выявлены достоверно. При использовании 80%
146
Технико-экономическое обоснование проектов
готовых программных модулей эквивалентная производительность
труда возрасла в 2,5 - 3 раза. Следует отметить, что даже при весьма
высокой доле (около 80%) применения готовых программных
модулей трудоемкость разработки снижалась не в 5 раз, как следуе,
из простейшего расчета, а только в 2,5 раза. Это обусловлено
значительным объемом общесистемных работ, которые присущи
созданию любого нового ПС.
От доли повторно используемых модулей зависит и длитель¬
ность разработки ПС. Так, при использовании 80% готовых про-
грамммных модулей длительность разработки снижается в 1,5-2
раза, т.е. существенно, меньше, чем изменяется производительность
труда. Это приблизительно соответствует изменению длительное! и
в зависимости от уменьшения трудоемкости за счет повторного
использования программных компонентов. Даже при весьма высо¬
кой доле ПИК (около 80%) длительность разработки сложных
комплексов программ СРВ высокого качества объемом 150 - 200
тыс. команд составляла около 3 лет.
Особености затрат при повторном использовании инфор¬
мации баз данных. В ряде случаев особое значение имеет не столь¬
ко использование готовых программных компонентов, сколько пе¬
ренос баз данных. Информация о процессах, происходящих во
внешней среде, может иметь большой объем и трудоемкость пер¬
вичного накопления и актуализации, что определяет необходимость
ее тщательного хранения. Возможны ситуации, когда подобные дан¬
ные являются уникальными и невосстанавливаемыми. Однако пер¬
вичные аппаратная или операционная платформы, в которых они
накапливались и обрабатывались, может требовать замены. Форми¬
рование и заполнение информацией баз данных достаточно слож¬
ный и трудоемкий процесс, технико-экономические показатели ко¬
торого сильно зависят от структуры, состава, объема, связности и
других характеристик исходной информации. Для осуществления
переноса данных большого объема необходимы методы и средства
автоматизации, которые обеспечивают достаточную эффективность
этого процесса [9, 48].
Простейший вариант переноса информации БД на иную аппа¬
ратную платформу реализуется, когда на обеих платформах имею'сЯ
апробированные СУБД одного типа и версий. Однако чаще посДе'
fjiaea 3. Базовые характеристики затрат иа разработку..
147
дующий перенос БД не предусматривается при ее первичном
формировании и наполнении данными и возникает после дли¬
тельной эксплуатации (унаследованные системы). Причиной
обычно являются неудовлетворительные показатели качества функ¬
ционирования БД, потребность в дополнительных ресурсах памяти и
производительности ЭВМ, недостаточное время реакции на запросы
данных и т.п. Одновременно должно быть обеспечено сохранение
или повышение качества функционирования БД на новой платфор¬
ме. В общем случае при переносе баз данных можно выделить две
принципиальные проблемы, которые различаются сложностью и
методами решения.
Первая проблема сводится к обеспечению полного достоверно¬
го переноса информации базы данных (ИБД), накопленной в ЭВМ-1,
на ЭВМ-2 с иной архитектурой. Форматы, кодировка, длина слова и
другие особенности записи данных зависят от архитектуры ЭВМ-1 и
типа СУБД и могут требовать преобразования исходных данных для
эффективного их использования после переноса в ЭВМ-2 с иной
СУБД. Затраты и сложность переноса информации базы данных за¬
висят прежде всего от ее характеристик, которые отражают формат¬
ную, лингвистическую и физическую совместимость содержания
переносимой ИБД между рассматриваемыми платформами.
Вторая проблема заключается в обеспечении переноса функ¬
ций и процедур конкретной системы управления базой данных. Для
этого необходимо иметь полные и достоверные сведения о структу¬
ре записей ИБД, их связях, взаимодействии и логике использования
в исходной ЭВМ-1. Если одновременно с информацией БД перено¬
сятся полностью программные средства СУБД, то это обеспечивает
сохранение функций управления данными. Однако может потребо¬
ваться перенос ИБД на иную аппаратную платформу с другим типом
СУБД. В соответствии с этим СУБД имеют особенности компонен¬
тов и операторов, осуществляющих чтение и запись данных, а также
их основную обработку. Перечисленные характеристики могут ока¬
заться совокупностью факторов, существенно ограничивающих эф¬
фективность переноса БД.
Для средних и крупных проектов ПС системный анализ эффек¬
тИвности использования готовых компонентов целесообразно за¬
веРШать оценкой полной трудоемкости и длительности перено¬
с° ПС и БД и их сопоставлением с полной разработкой при ис¬
148
Технико-экономическое обоснование проектов.
пользовании алгоритмического и системного задела. Кроме того,
создаваемые ПС и БД следует оценивать по использованию памяти
и производительности ЭВМ-2. Такую оценку необходимо проводить
с учетом возможного тиража ПС и перспективы длительной его экс¬
плуатации. Ориентация на снижение затрат при использовании и
переносе готовых программ и данных зачастую отражается значи¬
тельными потерями в эффективности эксплуатации ПС вследствие
увеличения объема программ в объектном коде и снижения произ¬
водительности ИС, особенно когда программы длительно использу¬
ются на многих экземплярах ЭВМ в реальном времени. С другой
стороны, может оказаться необходимым учитывать перенос не един¬
ственной версии ПС, а развития множества базовых версий некото¬
рого проблемно-ориентированного класса или совокупности ПС на
целый спектр перспективных ЭВМ различной архитектуры. Тогда
при технико-экономическом анализе следует оценивать полный
объем программ, который надо создать для ЭВМ-2 и последующих
аппаратных платформ.
Таким образом, для первичного вывода о целесообразности исполь¬
зования готовых компонентов и переноса ПС и БД следует решать за¬
дачу сравнения достигаемого эффекта и затрат для методов перено¬
са и повторной разработки компонентов ИС в конкретных условиях с
учетом всех перечисленных факторов. Эти задачи значительно упроща¬
ются при одновременном сокращении затрат, за счет применения идео¬
логии и концепции Открытых компьютерных систем, поддержанных
комплексом международных стандартов и современных версий ОС, как
стандартов де-факто [9, 14,45].
Приведенные оценки показывают, что даже при предваритель¬
ной разработке, потенциально мобильных сложных программных
средств, баз данных и ПИК, затраты на их перенос могут быть весь¬
ма большими. Практически всегда необходимо время и трудоем¬
кость на:
- первичный системный анализ целесообразности переноса:
- поиск, адаптацию и использование готовых компонентов;
- оценку затрат с учетом стоимости приобретения и адаптации
переносимых программ и баз данных;
- интегрирование в новой операционной среде;
- тестирование и испытания компонентов в комплексе с унас¬
ледованными программами.
fnaea 3. Базовые характеристики затрат на разработку... 149
Некоторые, казалось бы второстепенные детали и факторы не¬
совместимости переносимых программ и данных и новой платфор-
Г} мы могут заметно отражаться на трудоемкости переноса. Особенно
[ ^тщательно их следует анализировать в унаследованных информаци-
' 'онных системах, в которых относительно мелкие детали взаимодей¬
ствия новых и старых программ могут существенно влиять на тех¬
нико-экономические показатели проекта. Среди этих показателей
наиболее важным для реализации проекта и зависящим от большин¬
ства его особенностей и факторов является трудоемкость, непосред¬
ственно определяющая стоимость переноса программ. Значения
^длительности и числа специалистов взаимосвязаны и в некоторых
пределах могут размениваться. Поэтому оценки этих показателей
можно варьировать, и при недостаточном числе специалистов есте¬
ственно возрастает длительность проектирования, хотя трудоем¬
кость остается практически неизменной. Пренебрежение технико-
I экономическим анализом проектов ПС на начальных этапах разра¬
ботки неизменно приводит к конфликтам между заказчиками и
разработчиками, к срывам графиков работ и нарушениям условий
контрактов.
3.3. Распределение затрат на разработку программных средств
по этапам работ
Для планирования разработки сложных ПС важно знать и ис¬
пользовать экспериментальные статистические распределения ос¬
новных ТЭП - трудоемкости, длительности и числа специалистов по
этапам работ и по реальному времени реализации компонентов
проектов. Относительные значения распределения этих величин на
интервале реализации крупных проектов несколько различаются в
зависимости от размера и типа комплекса программ, однако наи¬
больший интерес представляют сложные встроенные ПС реального
времени размером порядка 500 тысяч строк. Эти параметры в дан¬
ном разделе используются как базовые.
В ряде работ [2, 13, 27] опубликованы результаты измерения
основных технико-экономических показателей в зависимости от
Этапов создания ПС. В совокупных затратах на создание полностью
Новых ПС доминирует трудоемкость непосредственной разработки
Программных компонентов, которой ниже уделено наибольшее вни-
150
Технико-экономическое обоснование проектов.
мание. Наиболее полно эти данные исследованы и обобщены для
двух классов ПС: для программ встроенных ЭВМ в системах реаль¬
ного времени и для полунезависимых программ информационно¬
поисковых систем (см. п. 2.1). Для этих распределений характерно
наличие максимума в потреблении трудовых ресурсов на средних
этапах разработки - на этапах программирования и автономной от¬
ладки компонентов. Эти этапы полностью заняты разработкой ком¬
понентов, а на остальных этапах к ним относится только часть за¬
трат. После выделения затрат на создание компонентов, остающие¬
ся затраты можно отнести к процессам комплексирования и испыта¬
ний ПС.
Распределение необходимой трудоемкости на разработку
программ сложного ПС реального времени представлено на рис.3.8,
а также в табл. 3.3 [13].
1 2 3 4 5 6
Этапы
Рис. 3.8
Этап технологической подготовки разработки включен в тех¬
ническое проектирование, а документирование объединено с ком¬
плексной отладкой. В распределении (рис.3.8) выделены подмноже¬
лава 3. Базовые характеристики затрат на разработку... 151
ства работ, соответствующие разным категориям специалистов. Все
специалисты разделены на три категории: руководители разработки
и системные аналитики (1); непосредственные разработчики про-
раммных компонентов и специалисты по комплексированию (2);
вспомогательный персонал, обеспечивающий разработку и докумен¬
тирование программ (3). Первая и третья категории специалистов
непосредственно не взаимодействуют с текстом программ при их
отработке, однако их труд является неотъемлемой частью всего про¬
цесса разработки и в крупных проектах составляет около половины
ратрат на каждом этапе. Экспериментальные распределения относи¬
тельного числа занятых специалистов при создании сложных ПС
классов СРВ и ИПС одинакового размера в некоторой степени по¬
добны и положения экстремумов в этих распределениях различают¬
ся относительно мало.
Распределения относительной трудоемкости и длительности по
крупным этапам работ (таблица 3.4) слабо зависят от размеров ПС
^строенных систем.
Таблица 3.4
Распределение трудоемкости, длительности и числа специалистов
по этапам разработки встроенного комплекса программ
объемом 32/512 тысяч строк
I Этапы
L разработки
Трудо¬
емкость,
%
Длитель¬
ность,
%
Среднее число/Доля (%)
специалистов
(для ПС 32 тыс.строк)
Планирование и
Кшализ требований
7/7
20/22
4/24
Проектирование
17/17
26/27
9/54
Программирование
58/55
48/44
22/135
/Интеграция и испы¬
тания
26/29
26/29
18/108
Однако распределение (% от максимума в табл.3.4) и среднее
число специалистов значительно изменяется при увеличении созда¬
ваемого встроенного комплекса программ. При этом относительная
Доля специалистов увеличивается на этапах планирования, проекти¬
рования и испытаний и несколько снижается на этапе программиро¬
вания. В то же время упрощенно прогнозировать необходимое число
специалистов для крупномасштабных ПС (500 тыс. строк) затрудни¬
152
Технико-экономическое обоснование проектов.
тельно, так как при этом особое значение приобретает технология,
организация и инструментальное оснащение коллектива (см. п. 4.3).
Программы класса СРВ имеют приблизительно вдвое большую
трудоемкость, чем класса ИПС, и особенно различаются на завер¬
шающих этапах комплексирования и испытаний. Повышенные за¬
траты и число участвующих специалистов для класса СРВ харак¬
терны на этапах программирования и автономной отладки вследст¬
вие более жестких требований к качеству компонентов. В результате
относительное число специалистов при разработке программ СРВ
снижается на начальных и конечных этапах. Однако вследствие
большой трудоемкости полное число необходимых специалистов
при разработке программ СРВ значительно больше, чем при созда¬
нии ИПС.
На каждом из выделенных крупных этапов работ должны вы¬
полняться, прежде всего, основные, доминирующие работы, опреде¬
ляющие название этапа, но также ряд общих видов работ, присущих
в той или иной мере всем этапам. Такими видами работ являются
(таблица 3.5) [30]:
- анализ и корректировка требований к комплексу программ;
- проектирование функций и структуры компонентов и ПС в
целом;
- программирование компонентов и их взаимодействия;
- планирование и выполнение тестирования компонентов и
ПС;
- верификация и валидация компонентов и комплекса про¬
грамм;
- управление организацией и реализацией комплекса работ
проекта ПС;
- анализ, оценка и управление качеством программных компо¬
нентов и ПС в целом;
- документирование результатов разработки, создание техно¬
логических и эксплуатационных документов.
В каждом из четырех крупных этапов работ, представленных
в столбцах таблицы 3.5, кроме работ, доминирующих для данного
этапа, в меньшей степени должны выполняться ряд вспомогатель¬
ных работ из приведенного выше перечня восьми работ. Кажды11
вид вспомогательных работ требует в среднем 5 - 15% от суммарна*1
трудоемкости, а доминирующие работы составляют в среднем 40 "
Глава 3. Базовые характеристики затрат на разработку... 153
50% (за 100% принята суммарная трудоемкость на каждом из
I четырех основных этапов таблицы 3.5). Однако, на этапе интегриро-
j 1вания и испытаний (четвертый столбец) работы по программирова-
1,’лию, тестированию, верификации в сумме составляю около 70%
В общей трудоемкости этапа. На всех этапах должно осуществляться
|^гправлении организацией работ и качеством компонентов и ПС в
целом, а также документирование процессов и результатов, на что в
совокупности требуется около 20% трудоемкости этапа.
Таблица 3.5
Распределение относительной трудоемкости (%) по видам работ
на этапах разработки встроенного программного средства
объемом 32/512 тысяч строк
^ Этапы
! (виды работ)
Плани¬
рование
Проек¬
тирование
Программ¬
ирование
Интеграция
и испытания
Анализ
требований
46/45
12/12,5
4/4
2,5/5
Проектиро-
? вание
17/17
41/41
8/8
5/5
■ Программиро-
1 вание
4,5/5,6
13/13,5
56/57
37/40
1 Планирование
& тестов
3,5/4
5,5/6
5/5,5
3/3
1 Верификация
и валидация
7/7,5
7/7,5
8/8,5
30/28
: Управление
работами
13,5/12,4
11/10
6,5/6
7,5/7
Оценка качест-
, ва
3,3
2,5/2,5
6,5/6,5
8/8
Документирова¬
ние
5,5/5
7,5/7
5/5,5
7,5/7
Затраты на эти виды работ по разному распределены по этапам.
Трудоемкость анализа требований и проектирования ПС в целом,
Естественно, быстро убывает при приближении к завершающим эта¬
пам проекта. Распределения относительных трудоемкостей и дли¬
тельностей для средних (32 тыс. строк) и крупных проектов (512
тыс. строк) в таблицах 3.4 и 3.5 почти не различаются.
Важно на каждом этапе выделять долю труда, которую можно
отнести к отладке компонентов, их сборке, комплексированию и ис¬
154
Технико-экономическое обоснование проектов.
пытаниям ПС. Из таблицы 3.4 [30] следует, что на программирова¬
ние и автономную отладку программных компонентов СРВ требует¬
ся более половины (55%) трудоемкости и около 45% общей дли¬
тельности разработки, а по другим данным соответственно 46% и
32%. Это заметно меньше, чем те же показатели при разработке
компонентов для ИПС. Однако при комплексной отладке соотноше¬
ние относительных затрат на СРВ и ИПС изменяется на противопо¬
ложное. Возрастание относительных затрат всех видов при ком¬
плексной отладке СРВ обусловлено высокой трудоемкостью стохас¬
тической отладки и отладки в реальном времени для этого класса
ПС. При этом следует учитывать, что абсолютные значения трудо¬
емкости отладки программ СРВ приблизительно в 5 раз выше, чем
программ ИПС. Относительная трудоемкость и длительность при
испытаниях различных классов ПС приблизительно одинаково и
составляет 8 - 10% от совокупных затрат на разработку. Однако аб¬
солютная трудоемкость для испытаний ИПС также приблизительно
в 5 раз меньше, чем программ СРВ. При этом следует учитывать,
что при изменении трудоемкости полной разработки в 5 раз, абсо¬
лютная длительность этого процесса сокращается всего в 1,5 - 1,7
раза. В результате полная длительность отладки и испытаний про¬
грамм ИПС также приблизительно в полтора раза меньше, чем про¬
граммы СРВ того же размера.
Совокупные относительные затраты на автономную и ком¬
плексную отладку, а также на испытания всех классов ПС приблизи¬
тельно одинаковые и составляют по трудоемкости и по длительно¬
сти около 30%. Эти соотношения имеют тенденцию медленно сни¬
жаться за счет развития современных методов, технологии и инст¬
рументальных средств автоматизации начальных этапов проектиро¬
вания (см. п. 4.3). Необходимость проведения комплексирования и
тестирования ПС в реальном времени может привести к меньшим
результатам улучшения ТЭП для класса СРВ при активном внедре¬
нии средств автоматизации разработки.
Распределения технико-экономических показателей исследова¬
лись не только в зависимости от этапов работ, но и в зависимости
от календарного времени с начала разработки. Это время норми¬
ровалось полной длительностью от момента завершения разработки
технического задания до завершения испытаний (Т= 100%). На рис
fjtaea 3. Базовые характеристики затрат на разработку..
155
3.9 представлены обобщенные результаты экспериментальных ис-
| следований [2] распределения доли от среднего числа занятых
специалистов при создании программ классов СРВ (сплошная кри-
W вая) и ИПС (пунктирная кривая).
L Эти распределения можно достаточно хорошо аппроксимиро-
Жвать распределением Рэлея (штрих-пунктир). По методике, бази-
I рующейся на этом распределении, можно рассчитывать в зависимо¬
сти от размера ПС интегральную трудоемкость разработки, сред-
| нюю производительность труда, длительность с начала разработки
'для любого уровня завершенности проекта и другие показатели.
I Число снец-ов
Один из важных недостатков аппроксимации распределением
Рэлея состоит в том, что в начале разработки оно дает число участ¬
ников равное нулю. В действительности наиболее квалифицирован¬
ные системные аналитики участвуют в разработке концепций и тех¬
нического задания до начала официальной разработки ПС, что, в
частности, отражают экспериментальные кривые на рис.3.8. Распре¬
деление числа исполнителей и распределение Рэлея [2] , представ¬
ленные на рис. 3.9, нормированы относительно среднего числа
Исполнителей для ИПС и СРВ проектов размером 512 тыс. строк.
156
Технико-экономическое обоснование проектов
На рисунке отражены сравнительно более пологие изменения
графиков в начале и более высокий максимум для проектов
встроенного типа. Эти особенности более резко выражены для очещ,
больших встроенных проектов, максимум которых приходится на
точку, соответствующую затратам 60% времени разработки.
Эффективность использования ЭВМ по этапам разработки
(рис. 3.10 нижний индекс 4р).
анализ ванне отладка отладка
Рис. 3.10
Применение для автоматизации отладки программ и имитации
внешней среды отдельных специализированных ЭВМ позволяет
повысить эффективность разработки сложных ПС за счет:
- увеличения суммарной производительности и памяти ЭВМ
(аппаратурной оснащенности, используемых для автоматизации раз¬
работки;
- применения ЭВМ, реализующей разрабатываемое ПС, в ус¬
ловиях, максимально приближенных к использованию в реально"
системе, т.е. без дополнительной загрузки технологическими функ'
циями;
- возможности значительного повышения уровня автоматиза¬
ции разработки программ при использовании для технологически*
Глава 3. Базовые характеристики затрат на разработку.
157
задач мощных универсальных ЭВМ с развитой периферией и боль¬
шим объемом внешней памяти (повышение программной оснащен¬
ности); развитых средств имитации внешней среды и возможности
широкого варьирования параметров внешних объектов;
- увеличения суммарного процессорного времени применяе¬
мых ЭВМ и возрастания его доли в общем календарном времени,
используемом для разработки программ вследствие сокращения
ручного труда при автоматизированном выполнении ряда функций
проектирования.
Этапы предварительного и детального проектирования являют¬
ся одними из наиболее творческих и трудно автоматизируемых.
Вследствие этого на этих этапах малы затраты машинного времени
для любых классов ПС. Для класса СРВ затраты наибольшие на эта¬
пе комплексной отладки в реальном времени. Для ПС СРВ по мере
разработки монотонно увеличиваются затраты календарного ма¬
шинного времени реализующей ЭВМ - С4р| на функционирование
программ (рис.3.10). Затраты на применение технологической ЭВМ
- С4р2 после некоторого экстремума могут сокращаться. Максимум
этих затрат обычно приходится на этапы программирования и авто¬
номной отладки наиболее массовых компонентов ПС. В то же время
наибольшие затраты на имитацию внешней среды и генерацию тес¬
тов - С4р3 сосредоточены на этапе завершения комплексной отладки
в реальном времени. В процессе испытаний они могут сокращаться
за счет подключения к системе реальных объектов внешней среды.
Использование реализующей ЭВМ, естественно, возрастает по мере
разработки ПС и сокращения использования технологических
средств. После завершения испытаний затраты на реализующую
ЭВМ становятся доминирующими.
Суммарные затраты на применение всех ЭВМ - С 4р имеют
наибольшие значения на этапах комплексной отладки и испытаний
ПС (жирные линии на рис.3.10). На этих этапах с наибольшей ин¬
тенсивностью используется реализующая ЭВМ и ЭВМ, имитирую¬
щая внешнюю среду. Следует учитывать, что ЭВМ, используемые
Для автоматизации технологии разработки программ, могут иметь
более высокие характеристики, чем реализующие машины и вслед¬
ствие этого более высокие затраты на единицу времени применения.
В результате экстремум затрат на технологическую ЭВМ - С4р2 на
'этапах программирования и автономной отладки может оказаться
158
Технико-экономическое обоснование проектов.
доминирующим во всех суммарных затратах на ЭВМ. В этом случае
на завершающих этапах разработки суммарные затраты на ЭВМ -
С4р могут либо увеличиваться незначительно, либо даже снижаться
вследствие уменьшения интенсивности использования технологиче¬
ской ЭВМ (жирный пунктир на рис.3.10).
Если при разработке ПС процессорное время ЭВМ резко огра¬
ничено и не велико, то тестирование и отладка программ возможны
только при небольшом числе ситуаций. Это ограничение не позво¬
ляет проверить все многообразие вариантов исполнения программ,
что влияет на снижение качества функционирования ПС в целом.
Ограничение процессорного времени ЭВМ не допускает примене¬
ния, ряда эффективных средств автоматизации разработки программ
и имитации внешней среды. В результате возрастает доля неавтома¬
тизированного труда, что при ограниченной длительности создания
ПС непосредственно влияет на его качество. Таким образом, дос¬
тупное процессорное время реализующей, технологической и моде¬
лирующей ЭВМ в совокупности при заданных сроках разработки
определяют достижимые корректность, безопасность и надежность
комплексов программ. Тем самым комплексирование ЭВМ, распре¬
деление по ним вспомогательных функций и доступные вычисли¬
тельные ресурсы в ряде случаев не только определяют экономиче¬
скую эффективность разработки, но и принципиальную возмож¬
ность создания ПС с заданным качеством.
Гдава 4. Факторы, влияющие на затраты при разработке.
159
Глава 4
ФАКТОРЫ, ВЛИЯЮЩИЕ НА ЗАТРАТЫ
ПРИ РАЗРАБОТКЕ СЛОЖНЫХ
ПРОГРАММНЫХ СРЕДСТВ
4.1. Концепция уточнения прогнозов затрат под влиянием
различных факторов при разработке программных средств
Программные средства, прежде всего, должны иметь экономи¬
ческую, техническую, научную или социальную эффективность
применения, которая в проектах должна отражать основную цель их
жизненного цикла в системе. Эта системная эффективность мо¬
жет быть описана количественно или качественно, в виде набора
полезных свойств ПС, их отличий от имеющихся у других комплек¬
сов программ, а также источников возможной эффективности. В ре¬
зультате должна быть формализована цель использования и набор
главных требований заказчика и пользователей при приобретении
ПС, а также предполагаемая его сфера назначения и применения.
Полнота и точность представления этих характеристик ПС может
оцениваться, в основном, экспертно и является исходной для тех¬
нико-экономического обоснования проектов и прослеживания реа¬
лизации всех последующих, производных свойств и атрибутов
Функциональной пригодности.
Основное содержание, размер и требуемое качество, создавае¬
мых ПС практически всегда определяют затраты, связанные с их
Непосредственной разработкой. Влияние этой части затрат определя¬
йся наиболее сложным творческим процессом создания программ,
который зависит от многих факторов. Некоторые из них могут
Изменять эти затраты даже в несколько раз, но в большинстве своем
Изменяют их на десятки процентов. Накопленный опыт создания ПС
160
Технико-экономическое обоснование проектов.
и обобщение проведенных исследований позволили в [2, 13, 30]
выделить четыре основные группы факторов, влияющих на оценки
затрат при непосредственной разработке программ (см. рис. 3.2):
- факторы, отражающие особенности создаваемого комплек-са
программ как объекта разработки, и требования к его
функциональным характеристикам и качеству;
- факторы, определяющие организацию процесса разработ-ки
комплексов программ и его обеспечение квалифицированными
специалистами;
- факторы, характеризующие технологическую среду и
оснащенность инструментальными средствами автоматизации про¬
цесса разработки программ;
- факторы, отражающие оснащенность процесса создания ПС
аппаратурными вычислительными средствами, на которых
реализуются комплексы программ и базируются инструментальные
системы автоматизации разработки.
В представленных четырех группах распределены факторы,
которые наиболее важны при анализе основных затрат на проекты
ПС. В эти группы включены факторы, которые могут изменять про¬
изводительность труда при создании ПС не менее чем на 10% в ту
или иную сторону. В то же время имеющийся опыт показывает, что
отсутствуют отдельные факторы или методы, способные изме¬
нять на порядок или более основные ТЭП процесса разработки
программ. Большинство факторов изменяет экономические характе¬
ристики разработки программ на десятки процентов и не более чем в
1,5 раза. Различные рекламные публикации о создании и внедрении
<<уникального» метода, обеспечившего повышение производитель¬
ности труда специалистов на порядок, практически всегда обуслов¬
лены некорректным измерением эффективности предлагаемого
метода или другими сугубо рекламными причинами.
Основными факторами при оценке технико-экономических по¬
казателей разработки ПС выше рассматривались размер - масштао
программ (п. 3.1) и доля повторного использования готовых про¬
граммных компонентов (п. 3.2). Это может быть достаточным пр11
первичной оценке ТЭП, когда размер программ оценивается экс-
пертно или приближенно по общему набору функций ПС (см 11
5.1). Для более точного технико-экономического обоснован‘1Й
проектов ПС при предварительном и детальном проектиро#11'
Глава 4. Факторы, влияющие на затраты при разработке... 161
ции обычно имеется возможность и целесообразно учитывать влия¬
ние ряда факторов из четырех групп представленных выше на рис.
3.2. Это позволяет повысить достоверность прогнозирования техни¬
ко-экономических показателей ПС до уровня около 5 - 10% (см. рис.
3.1). Для выполнения таких оценок трудоемкости разработки (че¬
ловеко-месяцы) в модели СОСОМО II предложены выражения,
уточняющие зависимости, представленные в главе 3:
п
С = А у- IIе *ПМ (i) , (4.1)
i = 1
5
где: А = 2,94; Е = В + 0,01 х Y.F(j); Я = 0,91.
j= 1
Для прогнозирования длительности (месяцы) разработки ПС
рекомендуются выражения:
T=G*d{, (4.2)
где: G = 3,67;
5
Н = D + 0,02х 0,01 х Y.FQ) =D + 0,02х(£-В); D = 0,28.
j= 1
В детальной модели СОСОМО II влияние на трудоемкость
определяют 22 фактора, из которых пять - масштабные факторы,
карактеризуются множителем FQ) в значении степени размера ПС, а
*17 множителей M(i) непосредственно изменяют трудоемкость раз¬
работки. Максимальные значения и содержание этих множителей
представлено в таблице 4.1. При этом номинальными (средними) в
выражении (4.1) принимаются все M(i) = 1,00, при которых соответ¬
ствующий фактор не влияет на трудоемкость ПС. В модели СОСО¬
' МО II поддерживаются вероятностные диапазоны оценок, представ¬
ляющие одно стандартное отклонение на фоне наиболее благопри¬
ятных оценок. При использовании представленных выражений для
прогнозирования ТЭП конкретных проектов следует выбирать набор
акторов (калибровать модель), имеющих наибольшие значения
коэффициентов изменения трудоемкости (КИТ) F(j) и M(i) в соот-
ствии с характеристиками конкретного проекта и среды разра-
162
Технико-экономическое обоснование проектов.
Таблица 4.]
Состав и максимальные значения факторов детальной модели
СОСОМО II
Фак¬
тор
Сим¬
вол
Макс.
зна¬
чение
Содержание факгора
PREC
FI
1,33
Масштабные факторы
Новизна проекта
FLEX
F2
1,26
Согласованность с требованиями и интерфейсами
RESL
F3
1,39
Управление рисками и архитектурой проекта
TEAM
F4
1,29
Слаженность работы коллектива
РМАТ
F5
1,43
Технологическая зрелость обеспечения
разработки
RELY
Ml
1,54
Факторы, влияющие на затраты разработки
Требовании и характеристики объекта
разработки
Надежность функционирования
DATA
М2
1,42
Размер базы данных
CPI.X
М3
2,38
Сложность функций и структуры
RUSE
M4
1,31
Требование повторного использования
компонентов
DOC’U
M5
1,52
Полнота и соответствие документации проекта
ACAP
M9
2,00
Характеристики коллектива специалистов
Квалификация аналитиков
PCAP
M10
1,76
Квалификация программистов
PCON
Mil
1,51
Стабильность коллектива
APEX
M12
1,51
Опыт работы по тематике проекта
PLEX
M13
1,40
Опыт (заботы в инструментальной среде
LTEX
M14
1,43
Опыт работы с языками программирования
TOOL
M15
1,50
Технологическая среда разработки
Уровень инструментальной поддержки проекта
SITE
M16
1,53
Необходимость распределенной разработки
проекта
SCED
M17
1,43
Ограничения длительности разработки проекта
TIME
M6
1,63
Аппаратурно-вычислительная среда
разработки
Ограниченность времени исполнения программ
STOR
M7
1,46
Ограниченность доступной оперативной памяти
PY'OL
M8
1,49
Изменчивость виртуальной среды разработки
проекта
fjiaea 4. Факторы, влияющие на затраты при разработке.
163
Значения этих коэффициентов и уровни оценок их влияния на
трудоемкость представлены ниже по выделенным группам в табли¬
цах разделов 4.2 - 4.5. Максимальные величины каждого из КИТ
разработки программ экспериментально оценены в [2, 13, 30] при
предположении, что остальные параметры зафиксированы (см. табл.
4.1). В действительности многие факторы взаимно коррелированны.
Так, например, высокой сложности комплекса программ обычно со¬
путствует требование высокой безопасности и надежности функ¬
ционирования и длительная эксплуатация. Ряд факторов влияет од¬
новременно на несколько составляющих. Воздействие в процессе
разработки на такие факторы и субъективный акцент на сокращение
определенных видов затрат в некоторых случаях может оказываться
нерентабельным с позиции снижения полных затрат на создание
комплекса программ. Стремление уменьшить затраты в период раз¬
работки без учета последующего использования ПС, его компонен¬
тов и всего жизненного цикла может оказаться мало полезным, а, в
некоторых случаях, привести к значительному увеличению сово-
|^упных затрат. При создании многих сложных ПС эти затраты ис¬
числяются сотнями человеко-лет, что определяет особую актуаль¬
ность снижения прогнозируемых затрат при таких масштабах разра¬
боток. Поэтому необходим системный анализ распределения и ис¬
пользования ресурсов на разработку конкретных комплексов про¬
грамм путем выбора КИТ (калибровки модели) с учетом всего их
жизненного цикла.
Особенности модели СОСОМО II [30]. Организация-заказчик
может заказать разработку специальным образом калиброванной
версии коэффициентов в формулах (4.1) и (4.2), которая должна бо¬
лее точно отражать применяемые технологические процессы, осо¬
бенности и возможности проекта ПС. При калибровке модели СО¬
СОМО II выполняются следующие процедуры для конкретного про¬
екта:
- устанавливаются значения масштабных факторов F(j)\
- выбирается набор факторов M(i), оказывающих наибольшее
Влияние на прогнозируемую трудоемкость проекта ПС;
- для каждого из выбранных факторов производится оценка
Коэффициента изменения трудоемкости для анализируемого проекта
ПС.
Рекомендуются три различных способа, применяемых для ка¬
164
Технико-экономическое обоснование проектов.
либровки и корректировки коэффициентов изменения трудоемкости
модели СОСОМО II с учетом применения локальных условий. Они
основаны: на различных данных предшествовавших проектов; путем
повторной калибровки уравнений трудозатрат и настройки режима
(повторная калибровка показателей масштабных факторов и коэф¬
фициентов), а также посредством проверки интегральных значений
факторов и ограничений затрат. Предварительная повторная калиб¬
ровка коэффициентов требует наличия базы данных, которая содер¬
жит, как минимум, пять аналогичных предыдущих реализованных
проектов. Для точной повторной калибровки показателей, база дан¬
ных должна включать, как минимум, десять проектов.
Преимущества модели СОСОМО II [27, 30]:
- фактические данные подбираются в соответствии со многи¬
ми реальными проектами комплексов программ, поддерживающих
набор констант СОСОМО II и факторов корректировки, которые
могут соответствовать конкретной организации и проекту;
- применяемый в данном случае процесс является повторяе¬
мым;
- метод позволяет добавлять уникальные факторы для коррек¬
тировки ТЭП, связанные с данной организацией и проектом;
- метод является достаточно универсальным и может поддер¬
живать различные размеры, режимы и уровни качества проектов;
- идеально подходит для проектов, между которыми нет суще¬
ственных отличий относительно размера, сложности или функций
процесса;
- возможна высокая степень достоверности калибровки с опо¬
рой на предыдущий опыт;
- сопровождается обязательной документацией;
- модель проста в применении.
Недостатки модели СОСОМО II:
- все результаты зависят от размера ПС - точность оценки
размера, оказывает определяющее влияние на точность оценки тру
дозатрат, времени разработки, численности специалистов и произ¬
водительности разработчиков;
- игнорируется учет комплекса требований к характеристика^
качества ПС;
Глава 4. Факторы, влияющие на затраты при разработке.
165
- слишком упрощается влияние требований функциональной
безопасности и игнорируются проблемы обеспечения безопасности
ПС;
- существует зависимость между знаниями по факторам затрат
и количеством времени, затраченного на каждом этапе проекта;
- игнорируется изменяемость требований;
- не достаточно учитывается среда разработки ПС;
I - игнорируются уровни взаимодействия специалистов;
- игнорируются многие особенности, связанные с аппаратным
обеспечением проекта.
I Кроме того, модель СОСОМО II изначально представляет тру¬
дозатраты на всех этапах разработки (от этапа планирования до
[этапа реализации продукта). Проблемы сопровождения, повторного
[рабочего процесса, переноса и повторного использования компонен¬
тов не могут четко описываться в рамках одной и той же модели.
Эти действия могут быть также оценены с помощью применяемых
вариаций базовой модели. При использовании модели СОСОМО II
предполагается наличие простого базового уровня трудозатрат, ис¬
пользуемого при управлении конфигурацией и обеспечении качест¬
ва. В этом случае используется примерно 5% общего бюджета (ос¬
новываясь на типичной коммерческой практике, принятой при ис¬
пользовании модели СОСОМО II). Отдельные КИТ могут быть из¬
менены в 2 - 4 раза при разработке ПС с учетом сложности совре¬
менных программных продуктов. В модели СОСОМО II не учиты¬
ваются следующие компоненты:
■ - разработка и спецификация требований, которые не слишком
WacTO применяются в некоторых коммерческих приложениях даже,
несмотря на то, что эта часть выполненной оценки обычно рассмат¬
ривается в качестве области ответственности функций инжиниринга
систем или анализа систем;
- накладные расходы; расходы на командировки и другие по¬
бочные расходы;
- системная интеграция и инструментальная поддержка тести¬
рования.
На ранних стадиях разработки проекта, когда еще практически
ничего не известно о размере проекта и о его разработчиках, не от¬
корректированные функциональные особенности применяются в
качестве входных данных для предварительной модели СОСОМО
166
Технико-экономическое обоснование проектов
II. После того как была выбрана архитектура, этапы разработку
предварительного проекта и кодирования начинаются с ввода пара¬
метра LOC для модели. В то время как показатель размера в уравне¬
нии оценки трудозатрат в первичной модели варьируется в зависи¬
мости от текущего режима разработки, в модели СОСОМО II цри_
меняются факторы упрощенного масштабирования F(j) с целью
обобщения основных параметров и прогнозирования в режиме раз¬
работки (таблицы 4.2 и 4.3).
Таблица 4.2
Состав и максимальные значения факторов предварительной модели
СОСОМО II
Фак¬
тор
Сим¬
вол
Макс.
зна¬
чение
Содержание фактора и его составляющие
РСРХ
Ml
5,55
Требования к объекту разработки
RELY; DATA; CPLX; DOCU
RUSE
М2
1,31
Сложность и надежность программного продукта
RUSE
PERS
M4
4,24
Требование повторного использования
компонентов
Характеристики коллектива специалистов
АС'АР; РСАР; PCON
PREX
M5
2,56
Квалификация специалистов и стабильность
коллектива
APEX; PLEX; LTEX !
PCIL
Мб
2,31
Опыт работы по тематике и с инструментарием
Технологическая среда разработки
TOOL; SITE
SC'ED
М7
1,43
Уровень инструментальной поддержки и
необходимость распределенной разработки ;
SCED
PDIF
М3
1,00
Ограничение длительности разработки
Аппаратурно-вычислительная среда
разработки ,
TIME; STOR; PVOL j
Ограничения аппаратной платформы разработки и
реализации
j
fjiaea 4. Факторы, влияющие на затраты при разработке... 167
i Таблица 4.3
Л Интегральные коэффициенты изменения трудоемкости разработки
^ программных средств в предварительной модели СОСОМО II
ИИ1СГ|>а.|Ы1ЫГ
факторы
Уровень оценки
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень
высокий
Сверх
высокий
Сложность и
надежность
0,81
0,98
1,00
1,30
1,74
2,38
Требовании
повторного
иснодыования
компонентов
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,71
0,62
| Инструмен-
, тальиая
f, поддержка
1,30
1,10
1,00
0,87
0,73
0,62
1 Ограничение
■ Длительности
\ разработки
1,43
1,14
1,00
1,00
1,00
Аппаратурно-
вычислигельная
среда
0,87
1,00
1,29
1,81
2,61
Также оценивается процентное соотношение показателей по¬
зорного использования компонентов и ожидаемой производитель¬
168
Технико-экономическое обоснование проектов.
ности. Из 17 факторов детальной модели СОСОМО II, для предва¬
рительной модели в таблице 4.2 выделены и скомплексированы
семь факторов M(i) по тем же четырем группам. Содержание этих
факторов представлено ниже в таблицах разделов 4.2 - 4.5, а уровни
оценки их влияния на трудоемкость в таблице 4.3. Влияние мас¬
штабных факторов F(j) следует учитывать также как в детальной
модели СОСОМО II.
Кроме моделей СОСОМО в 80-е годы была разработана отече¬
ственная модель прогнозирования затрат на разработку сложных
комплексов программ ПЛАПС (см. п. 5.3). В этой модели учитыва¬
лись так же четыре группы факторов, содержание которых несколь¬
ко отличалось от приведенных выше. Принципиальной особенно¬
стью модели ПЛАПС являлось её расширение в направлении авто¬
матизированного формирования планов всего процесса разработки
сложных ПС в виде диаграмм Ганта. В них отражались значения
трудоемкости, длительности и числа специалистов по этапам разра¬
ботки и набор частных работ для каждого этапа. Содержание этапов
и частных работ было снабжено комментариями и перечнями отчет¬
ных документов (см. п. 5.3).
4.2. Влияние требований к характеристикам программных
средств на затраты при их разработке
При более точной оценке размера комплекса программ с учетом
его структуры и спецификаций, на трудоемкость и длительность
разработки для повышения достоверности прогнозирования ТЭП
целесообразно учитывать ряд функций, свойств и характеристик
оцениваемого объекта. Влияние этих факторов в совокупности для
некоторых проектов ПС может быть весьма существенным, хотя ка¬
ждый из них обычно относительно слабо отражается на трудоемко¬
сти. Такие факторы частично представлены в группе требуемых ха¬
рактеристик ПС и их рейтингов в детальной модели СОСОМО [30]
Более подробно влияние требований к характеристикам сложных
комплексов программ, регламентировано в стандарте ISO 9126.
В стандарте рассмотрено около двадцати характеристик и ря4
их атрибутов, однако ниже при анализе их количество несколько
уменьшено. В данном разделе последовательно рассмотрено ели*1'
ние на технико-экономическое обоснование проектов ПС факт0'
fjiaea 4. Факторы, влияющие на затраты при разработке.
169
ров, выделенных в модели СОСОМО и в стандарте ISO 9126, состав
которых частично перекрывается. Поэтому подробное содержание
характеристик комплексов программ ниже комментируется для наи¬
большего их числа, представленного в стандарте.
В модели СОСОМО выделены и оценены рейтинги, двух наи¬
более значительных интегральных факторов программных продук¬
тов, непосредственно влияющих на трудоемкость разработки - но¬
визна проекта и согласованность требований (таблица 4.4) [30].
Таблица 4.4
Интегральные факторы и коэффициенты новизны и
согласованности требованиям объектов разработки
Интег¬
ральные
факторы
Уровень оценки
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень
высокий
Сверх
высокий
Новизна
проекта
Полностью
новый
Во
многом
новый
Частично
новый
В
основном
известный
Значительно
известный
Полностью
известный
Коэффи¬
циенты
новитиы
6,20
4,96
3,72
2,48
1,24
0,00
Согласо¬
ванность
требованиям
проекта
Строган
согласо¬
ванность
Допуска¬
ются
компро¬
миссы
Значи¬
тельная
Относи¬
тельная
Незначи¬
тельная
При
неоходи¬
мости
Коэффи¬
циенты
согласо¬
ванности
5,07
4,05
3,04
2,03
1,01
0,00
Новизну проекта рекомендуется учитывать степенью форма-
изации целей и функций комплекса программ, наличием опыта
170
Технико-экономическое обоснование проектов
аналогичных разработок, а также необходимостью создания новых
компонентов, алгоритмов и архитектур обработки данных. Согласо¬
ванность (жесткость) проекта определена как необходимость и сте¬
пень обеспечения соответствия заданным требованиям и специфи¬
кациям заказчика к компонентам, внешним интерфейсам и всему
комплексу программ в процессе разработки ПС. Для учета этих фак¬
торов предложены рейтинги интегральных атрибутов и значения
соответствующих коэффициентов изменения трудоемкости разра¬
ботки - таблица 4.4. Эти факторы приводят в ряде случаев к целесо¬
образности применения повторно используемых компонентов и сбо¬
рочного программирования, что подробно рассматривается в разде¬
ле 3.2.
В детальной модели СОСОМО используется перечень харак¬
теристик программных продуктов (таблица 4.5), для которых реко¬
мендуется набор рейтингов относительного влияния на базовые тех¬
нико-экономические показатели процессов разработки ПС (таблица
4.6).
Таблица 4.5
Требуемые характеристики программных средств
Характе¬
ристика
Уровень 1ребований
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень
ВЫСОКИЙ
Сверх
высокий
Требуемая
надежность
Малые
неудобства
Небольшие
потери
Средний
ущерб
Боль¬
шой
ущерб
Катастро¬
фический
ущерб
Риск для
жизни
Соответствие
докумен¬
тации
Фраг¬
менты
докумен¬
тов
Доку¬
менты
этапов н
компо¬
нентов
Эксплуа¬
тационные
доку меты
Отдель¬
ные
техиоло-
гнческне
доку¬
менты
Полные
техноло¬
гические
документы
Требуемое
повторное
IlCIIO.Ib-
шваннс
Мет
Нет
В пределах
проекта
В
пределах
ТИПОВЫХ
продуктов
В пределах
фирмы
Для
любою
продукт*
fjiaea 4. Факторы, влияющие на затраты при разработке..
171
Таблица 4.6
Рейтинги характеристик программных средств
Характеристика
Уровень оценки
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень
высокий
Сверх
высокий
~ Требовании
надежности
0,82
0,92
1,00
1,10
1,26
— Сложность
комплекса
0,73
0,87
1,00
1,17
1,34
1,74
Размер базы
данных
0,90
1,00
1,14
1,28
Соответствие
документации
0,81
0,91
1,00
1,11
1,23
Повторное
использование
0,95
1,00
1,07
1,15
U4
Эти рейтинги при прогнозировании ТЭП могут уменьшать или
увеличивать трудоемкость и длительность разработки ПС относи¬
тельно номинальной, в зависимости от требований или предпола¬
гаемых характеристик комплексов программ. Выделение небольшо¬
го числа учитываемых характеристик значительно упрощает выпол¬
нение оценок затрат и позволяет их проводить более формализова¬
но. Их рекомендуется использовать в качестве коэффициентов из¬
менения трудоемкости (КИТ) в выражении (4.1).
Стандартизированные в ISO 9126 характеристики ПС целе¬
сообразно применять при технико-экономическом обосновании раз¬
работки крупномасштабных программных продуктов, к которым
предъявляются высокие требования к качеству функционирования.
Высшие приоритеты в конкретных проектах, естественно, должны
Присваиваться свойствам и атрибутам, необходимым для достиже¬
ния стратегических целей использования ПС. Все остальные стан¬
дартизированные характеристики ПС, в той или иной степени,
Должны способствовать обеспечению тактических целей выбран¬
172
Технико-экономическое обоснование проектов.
ных конструктивных требований и применения ресурсов. Поэтому
им могут быть присвоены более низкие приоритеты и на выполне¬
ние соответствующих требований заказчика, могут выделяться
меньшие ресурсы, что, в частности, может отражаться на не полной
реализации некоторых установленных заказчиком требований
вследствие ограниченности ресурсов. Стандартами рекомендуется,
чтобы было предусмотрено измерение каждой характеристики с
точностью и определенностью, достаточной для сравнений с требо¬
ваниями технических заданий и спецификаций, и чтобы измерения
были объективны и воспроизводимы.
Системная эффективность целевого применения програлич-
ных продуктов определяется степенью удовлетворения потребно¬
стей определенных лиц - заказчиков и/или пользователей. В стан¬
дартах эта эффективность отражается основной, обобщенной харак¬
теристикой качества - функциональная пригодность программно¬
го продукта. В связи с тем, что ее абсолютную величину обычно
трудно измерить непосредственно и количественно, то по ряду пока¬
зателей необходима и возможна качественная оценка свойств и дос¬
тоинств основных функций ПС при применении.
Улучшение каждой, вспомогательной - конструктивной ха¬
рактеристики качества ПС, также требует некоторых затрат ре¬
сурсов (трудоемкости, финансов, времени), которые в той или иной
степени должны отражаться на основной характеристике - на функ¬
циональной пригодности. Эти конструктивные характеристики
имеют значение для проекта постольку, поскольку они обеспечива¬
ют требуемое качество реализации основного назначения и функций
ПС. При выборе конкретных мер конструктивных характеристик
качества следует учитывать затраты ресурсов на их достижение и на
результирующее повышение функциональной пригодности, жела¬
тельно, в сопоставимых экономических единицах, в тех же мерах и
масштабах. Такое, даже приблизительное, качественное сравнение
эффекта и затрат позволяет избегать многих не рентабельных завы¬
шений требований к отдельным конструктивным характеристикам,
которые не достаточно адекватно отражаются на улучшении функ¬
ций ПС.
Выбор требований к характеристикам ПС, естественно, долм<е>'
начинаться с определения и формирования требований к функЦ'10'
налыюй пригодности ПС. Это наиболее ответственная, стратеги4*'
fjiaea 4. Факторы, влияющие на затраты при разработке.
173
ская задача начальных этапов проектирования и всего последующе¬
го развития жизненного цикла. Решение задачи должно быть на-
I правлено на обеспечение высокой функциональной пригодности ПС
путем сбалансированного улучшения остальных, конструктив¬
ных характеристик качества в условиях ограниченных ресурсов.
Излишне высокие требования к отдельным атрибутам качества, тре¬
бующие для реализации больших дополнительных трудовых и вы¬
числительных ресурсов, целесообразно снижать, если они слабо
Ьлияют на основные, функциональные характеристики. ПС. Ориен¬
тирами могут служить диапазоны изменения конструктивных харак¬
теристик ПС, границы количественных или качественных шкал ко¬
торых сверху и снизу могут быть выбраны на основе следующих
принципов:
- предельные значения характеристик качества, должны быть
ограничены сверху допустимыми или рациональными затратами
(ресурсов на их достижение при разработке и совершенствовании
ПС;
- наибольшие допустимые затраты ресурсов, например труда и
времени для реализации конструктивных характеристик, должны
обеспечивать функциональную пригодность жизненного цикла ПС
на достаточно высоком уровне;
- допустимые наихудшие значения отдельных конструктив¬
ных характеристик качества, могут соответствовать значениям, при
которых заметно начинает снижаться функциональная пригодность
при применении ПС;
- ограниченные значения отдельных конструктивных характе¬
ристик качества, не должны негативно отражаться на возможных
высоких значениях других приоритетных характеристик.
Функциональная пригодность - это набор и описания атри¬
бутов, определяющих назначение, основные, необходимые и дос-
Щпаточные функции ПС, заданные техническим заданием и специ¬
фикациями требований заказчика или потенциального пользователя.
Данная характеристика связана с тем, какие функции и задачи
Должно решать ПС для удовлетворения потребностей пользовате¬
лей, в то время как другие, конструктивные характеристики главным
образом связаны с тем, как и при каких условиях, заданные функ¬
ции могут выполняться с требуемым качеством. Атрибуты функ¬
циональной пригодности можно характеризовать в основном свой¬
174
Технико-экономическое обоснование проекпгоч
ствами, категориями и качественным описанием функций, для кото¬
рых зачастую трудно определить численные меры и шкалы [18].
В процессе проектирования комплекса программ атрибуты
функциональной пригодности должны конкретизироваться в специ¬
фикациях на ПС в целом и на компоненты. Атрибутами этой харак¬
теристики качества могут быть функциональная полнота решения
заданного комплекса задач, степень покрытия функциональных тре¬
бований спецификациями и их стабильность при совершенствова¬
нии ПС, число и достоверность реализуемых требований заказчиков
и т.д. На последовательных этапах ЖЦ, функции промежуточных
продуктов (спецификаций компонентов, модулей, текстов программ
и т.п.) должны оцениваться на соответствие описаниям в отдельных,
частных документах. Такими атрибутами могут быть: функциональ¬
ная адекватность программ документам и декларированным требо¬
ваниям, утвержденным заказчиком; степень покрытия тестами ис¬
ходных требований; полнота и законченность реализации этих тре¬
бований; точность выполнения требований детальных специфика¬
ций на функциональные компоненты ПС [12, 26, 49].
Функциональная пригодность определяется качеством взаимо¬
связи и согласованности последовательных формулировок содержа¬
ния и реализации основных фрагментов в цепочке стандартизиро¬
ванных требований технического задания на ПС: целей - назначе¬
ния - функций - исходной информации - результатов для поль¬
зователей, определяющих что:
- описание целей программного средства корректно перерабо¬
тано в подробное описание его назначения и внешней среды приме¬
нения;
- назначение ПС полностью и корректно детализировано в
требованиях к функциям комплекса программ и его компонентов;
- реализация требований к функциям ПС обеспечена досто¬
верным и адекватным составом и содержанием исходной информа¬
ции от объектов внешней среды и пользователей;
- реализация функций ПС способна подготавливать всю тре¬
буемую и достаточно корректную информацию для пользователей и
объектов внешней среды.
Функции ПС реализуются в определенной аппаратной, опер3'
ционной и пользовательской внешней среде системы, характеристи
ки которых существенно влияют на функциональную пригодное|Ы
fjiaea 4. Факторы, влияющие на затраты при разработке.
175
Для выполнения требуемых функций комплекса программ необхо¬
дима адекватная исходная информация от объектов внешней
череды, содержание которой должно полностью обеспечивать реали¬
зацию декларированных функций. Полнота формализации номенк¬
латуры, структуры и качества входной информации для выполнения
требуемых функций, является одной из важных составляющих при
определении функциональной пригодности ПС в соответствующей
внешней среде.
Цель и функции ПС реализуются тогда, когда выходная ин¬
формация достигает потребителей - объектов или операторов-
пользователей, с требуемым содержанием и качеством, достаточным
для обеспечения ее эффективного применения. Степень покрытия
всей выходной информацией: целей, назначения и функций ПС для
пользователей, следует рассматривать как основную меру качества
функциональной пригодности. Прослеживание и оценивание адек¬
ватности и полноты состава выходной информации снизу вверх к
назначению ПС должны завершать выбор базовых характеристик
качества функциональной пригодности, независимо от сферы при¬
менения системы.
В ряде систем особое значение для функциональной пригодно¬
сти имеет организация информационного обеспечения и базы дан¬
ных. При этом должны быть определены:
- назначение базы данных и состав информации в ней;
- совместимость ПС с другими системами по источникам и
потребителям информации базы данных;
- организация сбора, передачи, контроля и корректировки ин¬
формации базы данных;
- интенсивность и объемы потоков информации базы данных.
В зависимости от назначения ПС (см. п. 2.1) почти каждая из
конструктивных характеристик может стать доминирующей
или даже почти полностью определяющей функциональную при¬
годность ПС. В наибольшей степени функциональная пригодность
60 многих случаях, например, для СРВ зависит от корректности и
Нежности ПС. Значительные трудности при создании ориенти-
Р°в для выбора мер и шкал характеристик качества, проявляются
анализе корректности, способности к взаимодействию и безо¬
Пасности ПС.
176
Технико-экономическое обоснование проектов
Правильность - корректность: это способность ПС обеспечи¬
вать правильные или приемлемые результаты для пользователей
Эталонами для выбора требований к корректности при проектиро¬
вании могут быть: верифицированные и взаимоувязанные требова¬
ния к функциям комплекса, компонентов и модулей программ, а
также правила их структурного построения, организация взаимодей¬
ствия и интерфейсов. Эти требования при разработке должны быть
прослежены сверху вниз до модулей, и использоваться как эталоны
при установлении необходимой корректности соответствующих
компонентов.
Требования к характеристике корректность могут представ¬
ляться в виде описания двух основных свойств, которым должны
соответствовать все программные компоненты и ПС в целом (таб¬
лица 4.7). Первое требование состоит в выполнении определенной
степени (%) прослеживаемости сверху вниз реализации требований
технического задания и спецификации на ПС при последовательной
детализации описаний программных компонентов вплоть до текстов
и объектного кода программ. Второе требование заключается в вы¬
боре степени и стратегии покрытия тестами структуры и функций
программных компонентов, совокупности маршрутов исполнения
модулей и всего комплекса программ для последующего процесса
верификации и тестирования, достаточного для функционирования
ПС с необходимым качеством и точностью результатов, при реаль¬
ных ограничениях ресурсов на тестирование.
Способность к взаимодействию — состоит в свойстве ПС и его
компонентов взаимодействовать с одним или большим числом оп¬
ределенных компонентов внутренней и внешней среды. При выборе
и установлении при проектировании способности программных и
информационных компонентов к взаимодействию, ее можно оцени¬
вать объемом технологических изменений в ПС, которые необходи¬
мо выполнять при дополнении или исключении некоторой функций
или компонента, когда отсутствуют изменения операционной, аппа¬
ратной или пользовательской среды. С этим показателем связана
корректность и унифицированность межмодульных интерфейсов»
которые определяются двумя видами связей: по управлению и п°
информации. При этом важно учитывать возможность повтори01
использования апробированных компонентов и переноса на Pa3J,li^e
ные платформы. Ряд общих понятий, методов и функций, к°тоРь
fjiaact 4. Факторы, влияющие на затраты при разработке.
177
могут рассматриваться как достаточно полная база и набор свойств
компонентов, обеспечивающих высокую способность к взаимодей¬
ствию, обобщены в концепции, методах и стандартах Откры¬
тых систем (см. п. 3.2) [14, 29, 45].
Таблица 4.7
Пример требований к характеристикам функциональных
возможностей для двух типов программных средств
Характеристика
качества
Содержание требований
Требования
по типам ПС
СРВ
И ПС
Корректность
Требуемая прослеживае-
мость соответствии текстов
программ требованиям к
функциям программных
компонентов и ПС в целом
(%).
95
90
Требуемая степень покрытия
тестами структуры про¬
граммных компонентов и
ПС в целом (%)
95
80
Способность к
взаимодействию
Соответствие ПС утвер¬
жденным документам на ин¬
терфейсы: с аппаратной,
операционной и внешней
средой ИС (%)
90
90
Соответствие ПС утвер¬
жденным документам на ин¬
терфейсы с пользователями
(%)
80
90
Защищенность -
безопасность
Соответствие стандартизи¬
рованным категориям за¬
щищенности ПС (%)
60
95
Использование выбранных и
согласованных методов и
средств обеспечения безо¬
пасности ПС (%).
80
95
178
Технико-экономическое обоснование проектор
Защищенность - безопасность тесно связаны с особенностям
функциональной пригодности каждого ПС [19, 25, 33, 48]. Разрабо 4
ка и формирование требований к свойствам безопасности должщ
осуществляться на основе потребностей эффективной реализаций
назначения и функций ПС при различных, реальных угрозах. В цр0
цессе проектирования должны быть выявлены потенциальные цре
думышленные и случайные угрозы функционированию ПС и уСТа
новлен необходимый уровень безопасности данного комплекса цр0.
грамм (см. табл. 4.7).
Эффективная система защиты информации и программных
средств подразумевает наличие совокупности организационных и
технических мероприятий, направленных на предупреждение раз¬
личных угроз безопасности, их выявление, локализацию и ликвида¬
цию. Создание такой системы защиты предусматривает планирова¬
ние и реализацию целенаправленной политики комплексного
обеспечения безопасности. Потенциальная возможность и реаль¬
ные проявления информационных диверсий, а также непредумыш¬
ленных, негативных воздействий [19] заставляет в проектах ПС раз¬
рабатывать специальный раздел анализа, планирования и проекти¬
рования методов и средств для обеспечения безопасности приме¬
нения пользователями всего комплекса функциональных программ в
течение его жизненного цикла. Их реализация в критических ИС,
требует значительных ресурсов памяти и производительности вы¬
числительных систем. Из-за их ограниченности и других факторов
априори невозможно обеспечить отсутствие проявления дефектов
проектирования и абсолютную защиту крупномасштабных ПС,
вследствие чего безопасность их функционирования в ИС имеет
всегда конечное, ограниченное значение.
Наиболее полно степень безопасности системы характери¬
зуется величиной предотвращенного ущерба - риска, возможного
при проявлении дестабилизирующих факторов и реализации кон¬
кретных угроз безопасности применения ПС пользователями, а так¬
же средним временем между возможными проявлениями угроз, на
рушающих безопасность. С этой позиции затраты ресурсов разра"
ботчиками и заказчиками на обеспечение безопасности должн^
быть соизмеримыми с возможным ущербом у пользователей о* ь
нарушения. Поэтому реализации угроз, в ряде случаев, целесооор*
но характеризовать интервалами времени между их проявления^’
fjiaua 4- Факторы, влияющие на затраты при разработке.
179
нарУшающими безопасность применения ИС, или наработкой на
0ткззы, отражающиеся на безопасности. Это сближает понятия и
^^актсристики степени безопасности с показателями надежности
0С. Различие состоит в том, что в показателях надежности учиты-
рдются все реализации отказов, а в характеристиках безопасности
следует регистрировать только те катастрофические отказы, которые
отразились на нарушении безопасности.
При проектировании ПС целесообразно разделять вычисли¬
тельные ресурсы, необходимые для непосредственного решения ос¬
новных. функциональных задач, и ресурсы, требующиеся для защи¬
ты и безопасного функционирования. Соотношение между этими
видами ресурсов в реальных крупномасштабных ПС зависит от
сложности и состава решаемых функциональных задач, степени их
критичности и требований к безопасности всей системы. В различ¬
ных классах ПС ресурсы на обеспечение безопасности могут состав¬
лять от 5-20% до 100-300% от ресурсов, используемых на решение
основных, функциональных задач, т.е. в особых случаях (критиче¬
ские военные системы) могут превышать последние в 2-4 раза. В
административных и организационных ПС средства обеспечения
безопасности обычно используют 10-20% всех видов трудовых, ап¬
паратных и вычислительных ресурсов. Реальные ограничения ре¬
сурсов, используемых в процессе разработки, ограниченная квали¬
фикация специалистов, изменения внешней среды и требований за¬
казчика объективно приводят к отклонениям процессов и реализа¬
ции плана от предполагавшегося. В процессе формирования техни¬
ческого задания следует формулировать основные положения ме¬
тодологии и план последовательного повышения безопасности
Цутем наращивания комплекса средств защиты, поэтапных испыта¬
ли компонентов и определения характеристик, допустимых для
продолжения работ на следующих этапах.
Конструктивные характеристики качества сложных про¬
граммных средств ниже изложены в соответствии со стандартом
^ 9126. Конструктивные характеристики разделены на две груп-
Пь,: количественные и качественные, которые различаются возмож-
1,0стями конкретизацией мер. Две группы стандартизированных ха¬
Рактеристик качества Г1С - Надежность и Эффективность в наи-
■^•Пьщей степени доступны количественным измерениям. Для них в
Лиие 4.8 представлены примеры возможных основных количест¬
180
Технико-экономическое обоснование проектов
венных атрибутов характеристик качества для двух основных клас
сов ПС.
Таблица 4.8
Пример требований к количественным характеристикам
для двух типов программных средств
Характеристики
качества
Мера
Т рсбуемые
значения по
типам ПС
СРВ
ипс
Надежность
Завершенность:
- наработка на отказ при от¬
сутствии рестарта.
Устойчивость:
Часы
100
10
- наработка на отказ при на¬
личии автоматического рес¬
тарта;
Часы
1000
50
- относительные ресурсы на
обеспечение надежности и
рестарта.
Восстанавливаемость:
%
30
10
- длительность восстановле¬
ния.
Доступность-
готовность:
Минуты
0,1
5
- относительное время рабо¬
тоспособного функциони¬
рования.
Эффективность
Временная эффективность:
Вероят¬
ность
0,999
0,99
- время отклика - получения
результатов на типовое за¬
дание;
Секунды
2
10
- пропускная способность -
число типовых заданий, ис¬
полняемых в единицу вре¬
мени.
Используемость ресурсов:
Число в
минуту
100
10
- относительная величина ис¬
пользования ресурсов ЭВМ
при нормальном функцио¬
нировании программного
средства.
Вероят¬
ность
>0,9
>0,8
.
fjiaea 4. Факторы, влияющие на затраты при разработке.
181
Они могут служить ориентирами при выборе и установлении
требуемых значений этих показателей качества в спецификациях ПС
[18].
Надежность: свойства комплекса программ обеспечивать дос-
1таточно низкую вероятность потери работоспособности - отказа, в
процессе функционирования ПС в реальном времени [2, 5, 39, 47].
Основные атрибуты надежности могут быть объективно измерены и
сопоставлены с требованиями (см. табл. 4.5 и 4.6). Требования к
значениям атрибутов субхарактеристики завершенность - допусти¬
мой наработки на отказ за счет отладки, устанавливаются при отсут¬
ствии автоматического рестарта и при наличии администратора,
контролирующего работоспособность ПС. Применением программ¬
но-аппаратных механизмов автоматического рестарта эта наработка
при проявлении отказов, может быть повышена, т.е. при некоторых
Отказах, возможно их автоматическое обнаружение и оперативное
восстановление работоспособности, вследствие чего значения ус¬
тойчивости и наработки на отказ возрастают.
Допустимая длительность прерывания оперативной работы
пользователей ИС для полного восстановления нормального функ¬
ционирования системы обычно может составлять несколько секунд
или минут. Надежность ПС наиболее полно характеризуется устой¬
чивостью или способностью к безотказному функционированию и
Восстанавливаемостью работоспособного состояния после произо¬
шедших сбоев или отказов. В свою очередь устойчивость зависит от
степени покрытия тестами функций и структуры программ, от уров¬
ня не устраненных дефектов и ошибок (завершенность) и от способ¬
ности ПС реагировать на их проявления так, чтобы это не отража¬
лось на показателях надежности.
Завершенность: свойство ПС не попадать в состояния отказов
вследствие ошибок и дефектов в программах и данных. Завершен¬
ность можно характеризовать наработкой (длительностью) на отказ
(при отсутствии автоматического восстановления - рестарта), изме¬
ряемой обычно часами.
Устойчивость к дефектам и ошибкам: свойство ПС автома¬
тически поддерживать заданный уровень качества функционирова¬
ния при проявлениях дефектов и ошибок или нарушениях установ¬
ленного интерфейса. Эффективное, оперативное устранение прояв¬
182
Технико-экономическое обоснование проектов.
ления дефектов, ошибок и некорректного взаимодействия с опера¬
ционной и внешней средой определяют характеристику - устойчи¬
вость комплексов программ.
Восстанавливаемость: свойство ПС в случае отказа возобнов¬
лять требуемый уровень качества функционирования, а также по¬
врежденные программы и данные. Основными показателями про¬
цесса восстановления являются его длительность и вероятностные
характеристики. Перезапуск должен обеспечивать возобновление
нормального функционирования ПС, на что требуются ресурсы
ЭВМ и время, которые можно характеризовать относительной вели¬
чиной (% от общих ресурсов).
Доступность или готовность: свойство ПС быть в состоянии
выполнять требуемую функцию в данный момент времени при за¬
данных условиях использования. Для определения этой величины
измеряется относительное время работоспособного состояния ком¬
плекса программ между последовательными отказами. Обобщение
характеристик отказов и восстановления производится в критерии
коэффициент готовности.
Нижняя граница надежности обычно отражена значениям, при
которых резко уменьшается функциональная пригодность, и исполь¬
зование данного типа ПС становится неудобным, опасным или не¬
рентабельным (см. табл. 4.5). Примером таких наихудших, предель¬
ных величин для многих классов ПС могут быть наработка на отказ
менее десяти часов, коэффициент готовности ниже 0,9 и время вос¬
становления более десяти минут. С другой стороны, наилучшие зна¬
чения этих атрибутов практически ограничены теми ресурсами, ко¬
торые могут быть выделены для их достижения при разработке и
эксплуатации. Вычислительные и программные ресурсы объектной
ЭВМ на непосредственное обеспечение надежности функциониро¬
вания ПС обычно находятся в диапазоне от 10% до 90%, причем по¬
следние значения соответствуют критическим, особо высоконадеж¬
ным системам. Даже для таких критических программных средств
редко наработка на отказ превышает несколько тысяч часов, коэф¬
фициент готовности не выше 0,999, а время восстановления при от¬
казах не меньше нескольких секунд. За счет программно¬
аппаратных механизмов автоматического рестарта наработка при
проявлении отказов, может быть повышена в несколько раз.
fjiaea 4. Факторы, влияющие на затраты при разработке.
183
Эффективность: в стандарте ISO 9126 отражены две субхарак¬
теристики - временная эффективность и используемость ресурсов
ЭВМ, которые рекомендуется описывать, в основном количествен¬
ными, атрибутами, характеризующими динамику функционирова¬
ния компонентов ПС. В этой стандартизированной характеристике
" тражается только частная конструктивная эффективность ис¬
пользования ресурсов ЭВМ, которую не следует смешивать с сис¬
темной эффективностью функциональной пригодности ПС при
применении в конкретной информационной системе.
Основные требования к атрибутам характеристики эффектив¬
ность использования вычислительных ресурсов ПС сосредоточены
| на наиболее критичных показателях производительности и длитель-
j ности решения функциональных задач. Используемость ресурсов
памяти и производительности вычислительных средств могут уста¬
навливаться исходя, с одной стороны, из экономической целесооб¬
разности применения наиболее дешевой, с минимальными ресурса¬
ми ЭВМ, загрузка которой будет в среднем не ниже 0,5. С другой
стороны высокая загрузка (выше 0,9) может приводить к задержке
или даже потере заданий при случайном, кратковременном повыше¬
нии их интенсивностей, что может негативно отражаться на приме¬
нимости ПС (см. п. 4.5).
Временная эффективность-, свойства ПС, характеризующие
требуемые времена отклика и обработки заданий, а также произво¬
дительность решения задач с учетом количества используемых вы¬
числительных ресурсов в установленных условиях (см. ISO 14756).
Эти ресурсы могут включать другие программные продукты, аппа¬
ратные средства, средства телекоммуникации и т.п. Временная эф¬
фективность ПС определяется длительностью выполнения заданных
функций и ожидания результатов в средних и/или наихудших слу¬
чаях, с учетом приоритетов задач. Пропускная способность ком¬
плекса программ на конкретной ЭВМ отражается числом сообщений
Или заданий на решение определенных задач, обрабатываемых в
: единицу времени, зависящую от характеристик внешней среды.
I ■ Используемость ресурсов: степень загрузки доступных вычис¬
лительных ресурсов в течение заданного времени при выполнении
Функций ПС в установленных условиях. Ресурсная экономичность
Отражается занятостью ресурсов центрального процессора, опера¬
тивной, внешней и виртуальной памяти, каналов ввода-вывода, тер¬
184
Технико-экономическое обоснование проектов
миналов и каналов сетей связи. Ресурсная экономия влияет не толь¬
ко на стоимость решения функциональных задач, но, зачастую, осо¬
бенно для критических встраиваемых ЭВМ, определяет принципи¬
альную возможность полноценного функционирования конкретного
ПС в условиях реально ограниченных вычислительных ресурсов
[12, 18, 27].
Три группы конструктивных характеристик качества ПС -
Практичность, Сопровождаемость и Мобильность трудно измерять
количественно, и они доступны в основном качественным оцен¬
кам их свойств. В некоторых проектах для субхарактеристик Со¬
провождаемости и Мобильности при проектировании могут доми¬
нировать технико-экономические меры трудоемкости (человеко¬
часы) и длительности (часы) для процедур, обеспечивающих реали¬
зацию атрибутов этих субхарактеристик. В таблице 4.9 представле¬
ны примеры этих характеристик и их атрибутов для двух классов
ПС. Они могут служить ориентирами при выборе и установлении
требуемых значений этих показателей качества в спецификациях
ПС.
Практичность - применимость: свойства ПС, отражающие
сложность его понимания, изучения и использования, а также при¬
влекательность для квалифицированных пользователей при приме¬
нении в указанных условиях [15]. Требования к практичности и ее
субхарактеристикам - понятности и простоте использования, зави¬
сят от назначения и функций ПС и могут формализоваться заказчи¬
ками набором свойств, необходимых для обеспечения удобной и
комфортной эксплуатации программ (таблица 4.9).
Понятность: свойства ПС, обеспечивающие пользователю по¬
нимание, является ли программа пригодным для его целей, и как ее
можно использовать для конкретных задач и условий применения.
Понятность зависит от качества документации и субъективных впе¬
чатлений от функций и характеристик ПС (см. табл. 4.5). Она долж¬
на обеспечиваться корректностью и полнотой описания исходной и
результирующей информации, а также всех деталей функций ПС
для пользователей.
Простота использования: возможность пользователю удобно
и комфортно эксплуатировать и управлять ПС. Эта субхарактери¬
стика учитывает физические и психологические особенности поль-
fjiaea 4. Факторы, влияющие на затраты при разработке.
85
зователей и отражает уровень контролируемости и комфортности
условий эксплуатации ПС, возможность предотвращения ошибок
пользователей.
Таблица 4.9
Пример требований к качественным характеристикам
для двух типов программного средства
Ха ра ктернсти ки
качества
Мера
Требуемые
значения по
тинам I1C
СРВ
ипс
Практичность
Простота использования:
-
среднее время ввода заданий;
Секунды
2
10
среднее время отклика на за¬
дание.
Изучаемость
Секунды
1
5
■
трудоемкость изучения при¬
менения ПС;
Чел.-часы
50
200
-
продолжительность изучения;
Часы
20
50
объем эксплуатационной до¬
кументации;
Сопровождаемость
Изменяемость:
Страницы
100
1000
■
трудоемкость подготовки из¬
менений;
Чел.-часы
20
10
длительность подготовки из¬
менений. •
Тестируемость:
Часы
10
5
”
трудоемкость тестирования
изменений;
Чел.-часы
40
20
длительность тестирования
изменений.
Мобильность
Адаптируемость:
Часы
10
5
-
трудоемкость адаптации;
Чел.-часы
10
50
■
длительность адаптации.
Простота установки:
Часы
5
10
-
трудоемкость инсталляции;
Чел.-часы
4
10
■
длительность инсталляции.
Замещаемость:
Часы
2
5
■
трудоемкость замены компо¬
нентов;
Чел.-часы
20
50
длительность замены компо¬
нентов.
Часы
10
10
186
Технико-экономическое обоснование проектов
Изучаемость: свойства ПС, обеспечивающие удобное освоение
его применения достаточно квалифицированными пользователями
Она может определяться трудоемкостью и длительностью подготов¬
ки пользователя к полноценной эксплуатации ПС. Атрибуты изу¬
чаемое™ зависят от возможности предварительного обучения и oi
совершенствования знаний в процессе эксплуатации, от возможно¬
стей оперативной помощи и подсказки при использовании ПС, ц
также от полноты, доступности и удобства использования руко¬
водств и инструкций по эксплуатации. Изучаемость можно отражать
трудоемкостью и продолжительностью изучения пользователями
соответствующей квалификации, методов и инструкций применения
ПС для полноценной эксплуатации. Естественно, для создания
учебных пособий необходимы определенные затраты труда и вре¬
мени разработчиков, которые в некоторой степени пропорциональ¬
ны сложности функций ПС.
Сопровождаемость: приспособленность ПС к модификации и
изменению конфигурации. Модификации могут включать исправле¬
ния, усовершенствования или адаптацию ПС к изменениям во
внешней среде применения, а также в требованиях и функциональ¬
ных спецификациях заказчика [4, 41, 48]. Трудоемкость модифика¬
ций определяется внутренними метриками качества комплекса про¬
грамм, которые отражаются на внешнем качестве и качестве в ис¬
пользовании, а также на сложности управления конфигурациями
версий ПС (см. ISO 14764 и ISO 15846).
Требования к сопровождаемости количественно можно устано¬
вить для субхарактеристик изменяемости и тестируемости экономи¬
ческими категориями допустимой трудоемкости и длительности
реализации этих задач при некоторых средних условиях. Требуемые
значения зависят от четкости концепции и архитектуры ПС, от уни¬
фицированности внутренних, внешних и с пользователями интер¬
фейсов, от качества технологической документации, а также от ин¬
струментальной оснащенности поддержки ЖЦ данного ПС. Обоб¬
щенно это отражается на длительности и трудоемкости подготовки
и реализации типовых изменений, обусловленных необходимостью
устранения дефектов и усовершенствованиями функций ПС. Для
подготовки и выполнения каждого изменения (без учета затрат врс
мени на обнаружение и локализацию дефекта) нужно устанавливать
Слава 4. Факторы, влияющие на затраты при разработке.
187
допустимую среднюю продолжительность и суммарную трудоем¬
кость работ специалистов при их реализации (см. п.2.2 и п.3.2).
Мобильность: подготовленность ПС к переносу из одной ап¬
паратно-операционной среды в другую [14, 41, 46]. Установление
^требований к мобильности ПС может быть сведено к формализации
трудоемкости и длительности процессов: адаптации к новым харак¬
теристикам пользователей и внешней среды, инсталляции версий
ПС в среде пользователей и замены крупных компонентов версий
ПС по требованиям заказчиков или конкретных пользователей (см.
п. 3.2).
4.3. Влияние характеристик специалистов на затраты
при разработке программных средств
Важнейшим фактором при технико-экономическом обосно¬
вании, определяющим создание программных средств являются лю¬
ди - специалисты, с их уровнем профессиональной квалификации,
а также с многообразием знаний, опыта, стимулов и потребностей.
Быстрый рост сложности и повышение ответственности за качество
комплексов программ привели к появлению новых требований к
специалистам, обеспечивающим все этапы жизненного цикла ПС.
Теперь недостаточно навыков процедурного программирования не¬
больших компонентов, а необходимы глубокие знания системотех¬
ники, технологии проектирования, методов обеспечения и контроля
качества сложных комплексов программ в определенной области
применения. Эти специалисты должны владеть новой интеллекту¬
альной профессией, обеспечивающей высокое качество ЖЦ про¬
граммных средств, а также контроль, испытания и удостоверение
реального достигнутого качества на каждом этапе разработки и со¬
вершенствования программ. Крупномасштабное проектирование ПС
различных классов, разделение труда специалистов по квалифика¬
ции при разработке программ и данных, организация коллективов и
экономика таких разработок стали важнейшей частью выбора, обу¬
чения и подготовки специалистов для обеспечения всего ЖЦ ПС.
В детальной модели СОСОМО значительное внимание
Уделено влиянию организации и взаимодействия коллектива
разработчиков на трудоемкость создания сложных программных
средств - таблица 4.10.
188
Технико-экономическое обоснование проектов.
Таблица 4.10
Характеристики и влияние коллективизма разработчиков
программных средств на трудоемкость
1
Значение характеристики |
КоЛЛСКТИВИ!М
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень ]
высокий I
!
Согласованность
целей
коллскгнва
Мини¬
мальная
Незначи¬
тельная
Относи¬
тельная
Значи¬
тельная
Полная
Способность
членов
коллектива
адаптироваться
к целям других
Малая
Незначи¬
тельная
Относи¬
тельная
Значи¬
тельная
1
1
п 1
Полная 1
1
Опыт работы в
составе данного
коллектива
Нет
Малый
Незначи¬
тельный
Значи¬
тельный
1
i
Большой 1
1
Степень доверия
и
взаимодействия
в коллективе
Нет
В малой
степени
В
некоторой
степени
Значи¬
тельная
Большая |
Обобщенная
коллективность
работ
Некоторое
взаимо¬
действие в
коллективе
Сложное
взаимо¬
действие
Зачастую
коллек¬
тивная
работа
Высокая
степень
взаимо¬
действия
Непрс- !
рывши1
взанмо- 1
действие i
Обобщенный
коэффициент
влияния
коллективности
работ на
трудоемкость
5,48
4,38
3,29
1,10
0,00
1
Глава 4. Факторы, влияющие на затраты при разработке... 189
В составе организационных характеристик коллектива рекомен¬
дуется учитывать согласованность целей специалистов, участвую¬
щих в проекте, их психологическую совместимость и способность к
дружной коллективной работе, наличие опыта работы в данном
коллективе и другие объективные и субъективные свойства участни¬
ков проекта. При этом большое значение может иметь личная моти¬
вация и психологические особенности поведения разных специалис¬
тов при комплексной работе над сложным проектом. Эти характе¬
ристики могут быть обобщены в качественный показатель влияния
сложности взаимодействия специалистов в коллективе, которому
сопоставлены коэффициенты изменения трудоемкости разработки
ПС (последняя строка в табл. 4.10).
Наилучшим считается непрерывное корректное взаимодействие
организованных специалистов с большим опытом работы в данном
коллективе при полной согласованности их целей, планов и методов
работы. В остальных случаях в той или иной степени (даже в 3 - 5
раз) может возрастать трудоемкость разработки ПС, что нельзя не
^учитывать при прогнозировании ТЭП и обосновании разработки
крупно-масштабных проектов.
При разработке программ большими коллективами значительно
повышается роль квалификации руководителей разработки, что
непосредственно отражается на средней производительности труда
всего коллектива. Известны случаи, когда только вследствие уровня
квалификации руководителей крупных проектов суммарные затраты
на разработку изменялись в несколько раз как в лучшую, так и в
худшую сторону. Некоторые типовые методы организации коллек¬
тивов и процесса разработки позволяют сократить негативное
влияние человеческого фактора. Однако формализовать и учесть
влияние руководителя разработки и ведущих специалистов на
затраты и ТЭП комплекса программ пока трудно.
Уровень квалификации заказчика и определенность техничес¬
кого задания на разработку ПС может весьма сильно влиять на
суммарные затраты и длительность создания программ. Изменения
технического задания и объем переделок непосредственно отража¬
ются на средней производительности труда специалистов, рассчи¬
танной по конечному размеру созданного комплекса программ.
Особенно сильно на достоверность технического задания и возрас¬
тание затрат влияет попытка заказчика форсировать сроки разработ¬
190
Технико-экономическое обоснование проектов.
ки. При этом первоначальное техническое задание оказывается
недостаточно квалифицированным и подвергается в дальнейшем
многократным изменениям. Этому же может способствовать разли¬
чие между заказчиком и разработчиком в квалификации, уровне
понимания целей разработки и необходимых затрат на реализацию
дополнительных требований. По тем или иным причинам даже при
испытаниях заказчик зачастую обнаруживает, что решаются не
совсем те задачи и не совсем так, как нужно, вследствие чего
необходима переработка готовых программ. Даже квалифициро¬
ванные заказчики вынуждены иногда корректировать техническое
задание на любых этапах разработки, что может влиять на снижение
производительности на 10 - 20%.
При проектировании и создании высококачественных комплек¬
сов программ, прежде всего, необходима организация и тесное
взаимодействие представителей заказчика и разработчиков про¬
екта. Взгляды и требования заказчика, в основном, отражаются в
функциональных и потребительских характеристиках ПС. Устрем¬
ления разработчиков направлены на возможность и способы их реа¬
лизации с требуемым качеством. Эти различия исходных точек зре¬
ния на проект приводят к тому, что некоторые неформализованные
представления тех и других имеют зоны неоднозначности и взаим¬
ного непонимания, что может приводить к конфликтам. Организа¬
ция четкого взаимодействия и сокращение этих зон требует прове¬
дения определенных мероприятий и контактов по обмену знаниями,
взаимному повышению квалификации и обучению. Представители
заказчика, участвующие в оценке и прогнозировании ТЭП проекта,
должны обучаться формализации автоматизируемых технологиче¬
ских процессов, для которых предназначены соответствующие ПС.
и иметь представление об эффективных путях их реализации.
Практически в каждом успешном проекте должен быть лидер
Лидером продукта может быть: менеджер продукта, менеджер про¬
ектирования, руководитель проекта. Лидер должен [12, 27,42]:
- руководить процессом выявления и формирования требова¬
ний;
- рассматривать конфликтующие пожелания, поступающие от
различных участников проекта и находить компромиссы, необходи¬
мые для определения набора функций, представляющих наиболь¬
шую ценность для максимального числа участников проекта;
Глава 4. Факторы, влияющие на затраты при разработке..
191
- вести переговоры с руководством, пользователями и разра¬
ботчиками и поддерживать равновесие между тем, чего хочет заказ¬
чик, и тем, что может предоставить команда разработчиков за ресур¬
сы и время, отведенные для реализации;
- осуществлять проверку спецификаций программного средст¬
ва, чтобы удостовериться, что они соответствуют реальной концеп¬
ции, представленной детальными функциями;
- осуществлять управление изменением приоритетов задач, а
(также добавлением и исключением функций.
j Процесс разработки крупных программных средств чрезвычай¬
но трудоемок, а области применения специалистов весьма различ¬
ные. Поэтому трудно ожидать, что некий способ организации ко¬
манды будет во всех случаях предпочтительнее, чем альтернативные
варианты. Тем не менее, определенные общие элементы присутст¬
вуют во многих успешных командах. Руководство крупномасштаб¬
ным проектом ПС должны осуществлять один или два лидера - ме¬
неджера с различными функциями:
- менеджер проекта - этот специалист, обеспечивающий
коммуникацию между заказчиком и проектной командой, его задача
- определить и обеспечить удовлетворение требований заказчика с
учетом доступных ресурсов;
- менеджер-архитектор комплекса программ - управляет
коммуникациями и взаимоотношениями в проектном коллективе,
является координатором создания компонентов, разрабатывает базо¬
вые, функциональные спецификации и управляет ими, ведет график
проекта и отчитывается за его состояние, инициирует принятие кри-
Ьчных для хода проекта решений.
Разработчики должны иметь в своем составе квалифицирован¬
ных, проблемно-ориентированных аналитиков и системных ар¬
хитекторов, способных переводить функциональные требования
фказчика в конкретные спецификации и технические требования к
комплексу программ и его компонентам (таблицы 4.11 и 4.12) [30].
Системные аналитики по проектированию сложных ПС должны
иметь, прежде всего, хорошую подготовку по системному анализу
^горитмов и комплексов программ, по методам оценки эффектив-
’фсти проектов, организации и планированию крупномасштабных
Р&чработок программ и баз данных.
192
Технико-экономическое обоснование проектов
Таблица 4.11.
Характеристики разработчиков программных средств
Характеристика
Значение характеристики
Очень
низкая
Низкая
Номина¬
льная
Высокая
Очень
высокая
Квалификации
аналитиков
15%
35%
55%
75%
90%
Квалификация
программистов
15%
35%
55%
75%
90%
Тематический
опыт
2 мес.
6 мес.
1 год
3 года
6 лез
Инструментальный
опыт
2 мес.
6 мес.
1 год
3 года
6 лет
Опыт работы с
языками
2 мес.
6 мес.
1 год
3 года
6 лет
Стабильность
коллектива
48%
24%
12%
6%
3%
Им необходима высокая квалификация по архитектурному по¬
строению, комплексной отладке и испытаниям ПС определенных
классов, умение организовать коллектив для решения общей целе¬
вой задачи ИС. Это позволит на ранних этапах исключать или со¬
кращать дефекты, обусловленные различием представления ими це¬
лей и задач проектов, а также их показателей качества.
Крупномасштабные ПС являются одними из наиболее сложных
объектов, создаваемых человеком, и в процессе их разработки
творчество как поиск новых методов, альтернативных решений и
способов осуществления заданных требований, а также формирова¬
ние и декомпозиция этих требований составляют значительную
часть всех трудозатрат.
лава 4. Факторы, влияющие на затраты при разработке.
193
Таблица 4.12
Рейтинги характеристик разработчиков программных средств
Характеристика
Уровень оценки
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень
высокий
Квалификация
аналитиков
1,42
1,19
1,00
0,85
0,71
Квалификация
программистов
1,34
1,15
1,00
0,88
0,76
Тематический
опыт
1,22
1,10
1,00
0,88
0,81
Инструментальный
опыт
1,19
1,09
1,00
0,91
0,85
Опыт работы с
языками
1,20
1,09
1,00
0,91
0,84
Стабильность
коллектива
1,29
1,12
1,00
0,90
0,81
Индустриализация разработки ПС позволяет автоматизировать
нетворческие, технические и рутинные операции и этапы, а также
облегчает творческий процесс за счет селекции, обработки и подго¬
товки информации, необходимой для принятия творческих решений.
Следствием этого является значительное сокращение доли затрат на
творческий труд в непосредственных затратах на разработку про¬
грамм [12, 18].
Трудоемкость творческой части затрат на разработку ПС в
основном определяет человеческий фактор — квалификация и
организация коллектива специалистов (см. табл. 4.10). Следствием
этого является большой разброс трудоемкости, производительности
труда и длительности создания аналогичных ПС разными коллекти¬
вами. Коллективы с наилучшими ТЭП могут служить ориентирами
достижимых в ближайшие годы значений ТЭП для соответствую¬
щих классов ПС. Однако неуклонно повышается сложность созда¬
194
Технико-экономическое обоснование проектов.
ваемых ПС, что вызывает возрастание затрат творческого труда на
единицу размера ПС. В перспективе, несмотря на автоматизацию и
повышение инструментальной оснащенности технологии разработ¬
ки программ, доля творческого труда при создании полностью
новых крупномасштабных ПС возрастает. Даже при сокращении
суммарных затрат на разработку программных компонентов за счет
автоматизации нетворческого труда, все более определяющей для
технико-экономических показателей создания ПС становится доля
затрат на творческий труд и возрастают требования к творческим
способностям специалистов.
В детальной модели СОСОМО - изложены экспертные оценки
для учета влияния квалификации и характеристик различных спе¬
циалистов на технико-экономические показатели разработки ПС
(см. табл. 4.11 и 4.12) [30]. Аналогичные оценки учета особенностей
специалистов и их влияния на ТЭП, базируются на отечественном
опыте создания крупномасштабных программных продуктов и пред¬
ставлены в [13]. Эти характеристики сводятся в основном к дли¬
тельности и опыту работы в определенной области и экспертной
оценке квалификации специалистов. Выбор и использование их зна¬
чений при прогнозировании ТЭП требует высокой квалификации
экспертов и детального знания особенностей среды разработки ре
ального проекта ПС. Для обеспечения возможности их использова¬
ния при прогнозировании трудоемкости и длительности разработки
сложных комплексов программ в модели СОСОМО представлены
соответствующие относительные рейтинги - таблица 4.12 (коэффи¬
циенты изменения трудоемкости - в формуле (4.1)). При примене¬
нии этих рейтингов следует учитывать, что некоторые из них взаи¬
мосвязаны, и целесообразно анализировать их корреляцию, возмож¬
ность объединения или исключения при оценке реальных проектов
(см. табл. 4.2).
Затраты и труд специалистов при реализации крупномасштаб¬
ного проекта ПС можно распределить по двум категориям специа¬
листов'. разрабатывающим компоненты и ПС в целом и обеспечи
вающим технологию и качество программного продукта. Организа¬
ционное разделение специалистов, осуществляющих разработку lit
(первая категория), и специалистов, контролирующих и управляю
щих его качеством в процессе разработки и всего ЖЦ (вторая кате¬
гория), должно обеспечивать эффективное достижение задан н bin
fjiaeu 4. Факторы, влияющие на затраты при разработке... 195
характеристик, а также независимый, достоверный контроль затрат
и качества результатов разработки.
Специалисты первой категории непосредственно создают
компоненты и ПС в целом с заданными показателями качества (см.
табл. 4.11) . В процессе разработки их функции заключаются в тща¬
тельном соблюдении принятой в фирме технологии и в формирова¬
нии всех предписанных руководствами исходных и отчетных доку¬
ментов. При этом предполагается, что выбранная технология спо¬
собна обеспечить необходимые значения конструктивных показате¬
лей качества, а достижение заданных функциональных характери¬
стик гарантируется тематической квалификацией соответствующих
специалистов и регулярным контролем этих характеристик в про¬
цессе разработки. Система стандартизированного документирования
частных работ должна обеспечить объективное отражение качества
компонентов и процессов их создания на всех этапах ЖЦ ПС [8, 12,
15].
Разделение труда специалистов этой категории в крупных про¬
ектных коллективах приводит к необходимости их дифференциации
по квалификации и областям деятельности:
в. - спецификаторы подготавливают описания функций соот¬
ветствующих компонентов с уровнем детализации, достаточным для
корректной разработки текстов программ программистами и их ин-
'терфейсов;
- разработчики программных компонентов - программи¬
сты создают компоненты, удовлетворяющие спецификациям, реа¬
лизуют возможности продукта, отслеживают и исправляют ошибки,
при разработке сложных систем это требует детального знания вы¬
сокоуровневых языков программирования, визуального программи¬
рования, сетевых технологий и проектирования баз данных;
- системные интеграторы сложных проблемно¬
ориентированных ПС работают над проектами в значительной сте¬
пени отличными от программистов методами, на разных языках
проектирования, используют различные средства автоматизации и
имеют на выходе различные результаты крупных компонентов и
комплексов программ;
- тестировщики обеспечивают проверку функциональных
спецификации, систем обеспечения производительности, пользова¬
тельских интерфейсов, разрабатывают стратегию, планы и выпол¬
196
Технико-экономическое обоснование проектов.
няют тестирование для каждой из фаз и компонента проекта, долж¬
ны быть административно независимыми от программистов и спе¬
цификаторов;
- управляющие сопровождением и конфигурацией, инст¬
рукторы интерфейсов отвечают за снижение затрат на модифика¬
цию и сопровождение продукта, обеспечение максимальной эффек¬
тивности работы разработчиков по взаимодействию компонентов и
реализации версий ПС, принимают участие в обсуждениях пользо¬
вательского интерфейса и архитектуры продукта;
- документаторы процессов и объектов ЖЦ ПС обеспечива¬
ют подготовку и издание сводных технологических и эксплуатаци¬
онных документов в соответствие с требованиями стандартов.
Успех и качество при разработке сложных программных ком¬
плексов все больше зависит от слаженности работы и профессиона¬
лизма коллектива этой категории специалистов на всех этапах и
уровнях создания таких проектов - стабильность коллектива в
табл. 4.11 и 4.12. При выборе заказчиком надежного поставгцика-
разработчика проекта необходима оценка тематической и техно¬
логической квалификации возможного коллектива специалистов, а
также его способности реализовать проект с заданными требования¬
ми и качеством в пределах допустимых затрат. Тематическую ква¬
лификацию специалистов в области создания ПС определенного
функционального назначения приближенно можно характеризовать
средней продолжительностью работы в данной проблемной области
основной части команды, непосредственно участвующей в разра¬
ботке алгоритмов, спецификаций, программ и баз данных. Важней¬
шую роль при этом играет квалификация руководителей - лидеров
разработки и системных аналитиков функциональных компонен¬
тов и в меньшей степени непосредственных разработчиков про¬
грамм в конкретной прикладной области. Особенно важна не инди¬
видуальная характеристика каждого специалиста, а, прежде всего.
интегральный показатель квалификации «команды», реализую¬
щей некоторую, достаточно крупную функциональную задачу или
весь проект. При низкой тематической квалификации допускаются
наиболее грубые системные ошибки, требующие больших затрат
при доработке программ или даже делающие проект практически не
реализуемым [26, 42].
Глава 4. Факторы, влияющие на затраты при разработке.
197
Тематическая квалификация и опыт специалистов в конкрет¬
ной прикладной области, для которой разрабатываются программы,
приближенно может оцениваться продолжительностью работы по
.данной тематике. При низкой тематической квалификации допуска¬
ются наиболее грубые системные ошибки, требующие больших
затрат при доработке программ. Имеются примеры, когда из-за
таких ошибок, допущенных на этапе системного анализа, приходи¬
лось в процессе разработки изменять 70-90% программ [26, 31, 38].
Целесообразность использования в качестве параметра квалифика¬
ции, значений длительности работы в определенной прикладной
области подтверждается достаточно высокой ее корреляцией с ко¬
эффициентом изменения трудоемкости. При этом квалификация
J системных аналитиков и непосредственных разработчиков про¬
грамм в конкретной прикладной области особенно важна не столько
как индивидуальная характеристика каждого специалиста, а прежде
всего как интегральный показатель бригады, реализующей некото¬
рую, достаточно крупную функциональную задачу. Приводимые в
разных работах оценки показывают, что при изменении опыта
работы в данной области от 1 до 10 лет производительность труда
может повышаться в 1,5-2 раза.
Технологическая квалификация программистов в использова¬
нии инструментальной системы автоматизации разработки ПС
(отражает опыт применения методов, средств и всего технологи¬
ческого процесса при создании данного типа программ. Этот опыт
можно характеризовать длительностью работы с конкретной инстру-
■ ментальной системой автоматизации или ее версиями, базирую¬
щимися на единых технологических концепциях, опытом и длитель-
, ностью работы с регламентированными технологиями, инструмен¬
тальными комплексами автоматизации разработки, языками проек¬
тирования, программирования и тестирования ПС. Особое зна¬
чение имеет коллективный опыт организации и выполнения слож¬
ных проектов на базе современных автоматизированных технологий
и инструментальных средств. Опыт применения конкретного ком¬
плекса автоматизации, языков проектирования и программирования
ПС может являться существенным фактором при выборе технологии
Для создания новых компонентов и обеспечении качества ПС (см.
табл. 4.11 и 4.12).
198
Технико-экономическое обоснование проектов.
Оценка квалификации существенно зависит от стабильности
состава и психологического климата в коллективе специалистов и
их способности к сотрудничеству и дружной совместной работе над
единым проектом (см. табл. 4.10). В данном факторе годы работы с
конкретной технологической системой отражают не только опьп
работы с инструментами, но и слаженность коллектива по проведе¬
нию больших комплексных работ. Нарушение технологии, задержка
при разработке отдельных модулей или групп программ может
приводить к болшим дополнительным затратам и значительной
задержке разработки ПС в целом, Это вызывает простои групп
специалистов, соответствующее увеличение совокупных затрат и
снижение производительности труда. В целом за счет технологи¬
ческой квалификации и четкого управления разработкой при
увеличении стажа от 1 года до 10 лет производительность труда
может возрастать в 1,5-2 раза. Однако чаще всего коллективы
специалистов имеют уже некоторый технологический опыт, и
дальнейшее повышение их квалификации может дать относительно
немного 10 — 20% производительности. Небольшое влияние этого
фактора обусловлено также нивелирующим влиянием трудозатрат
вспомогательного и руководящего персонала, которые практически
не зависит от технологической квалификации и инструментального
опыта.
Программистская квалификация специалистов и опыт работы
с языками проектирования и программирования, из приведенных
факторов квалификации в наименьшей степени отражается па
производительности труда. В данном факторе учитывается освоен¬
ность не только языка непосредственного программирования, но и
всех компонентов языков, используемых при создании программ
(спецификаций, диалога, отладки, комплексирования и т.д.) [30].
После двух-трех лет работы в наибольшей степени проявляются
индивидуальные особенности конкретных специалистов, их твор¬
ческие способности, тщательность в работе, рациональное исполь¬
зование средств автоматизации. Далее программистская квалифика¬
ция все меньше отражается на повышении производительности
труда коллектива. Для опытных специалистов переход на новый
язык программирования обычно не требует особых усилий и
успешно проходит за несколько месяцев. При создании сложных ГК
Глава 4. Факторы, влияющие на затраты при разработке.
199
после первых лет работы возрастание программистской квалифика¬
ции может повысить производительность труда на 5 - 10% .
Совокупность перечисленных видов квалификации можно
представить как обобщенный человеческий фактор при технико¬
экономическом обосновании и в процессе разработки сложных
программных средств. На эту величину влияет множество трудно
'читываемых условий, и приводимые в литературе оценки часто
отличаются излишней смелостью и общностью выводов при малом
юбъеме экспериментальных данных и их низкой достоверности.
Кроме того, приведенные факторы в значительной степени коррели¬
рованны. Сложность психологических экспериментов с регистра¬
цией всех основных условий приводит к большому разбросу
результатов. В некоторых случаях этот фактор изменял совокупные
затраты даже в 2 - 5 раз. Вследствие этого некоторые специалисты в
основном на опыте разработки относительно простых программ
тверждают, что при разработке программ только человеческий
фактор определяет длительность и трудоемкость разработки.
Отсюда делается вывод о принципиальной невозможности планиро¬
вания и прогнозирования процесса разработки программ. В дейст¬
вительности при крупных разработках человеческий фактор в
^коллективах значительно усредняется. Тем не менее, достаточно
часто по этой причине возможен разброс производительности труда
в 2 - 3 раза на крупных практически аналогичных разработках ПС.
Специалисты второй категории - технологи, обслуживаю¬
щие и сопровождающие технологический инструментарий, который
применяется специалистами первой категории, обеспечивают при¬
менение системы качества проекта или предприятия, контролируют
и инспектируют ее использование для минимизации затрат. Основ¬
ные задачи второй категории специалистов должны быть сосредото¬
чены на контроле процессов, затрат и результатов выполнения работ
и на принятии организационных и технологических мер для дости¬
жения их необходимого качества, обеспечивающего выполнение
всех требований технического задания на ПС с учетом ТЭП.
Технологи должны выбирать, приобретать и осваивать наибо¬
лее эффективный инструментарий для проектов, реализуемых кон¬
кретной фирмой с учетом особенностей создаваемых ПС требуемого
качества и рентабельности технологических средств. Они должны
1 разрабатывать регламентированный технологический процесс и сис¬
200
Технико-экономическое обоснование проектов.
тему качества, поддерживающие весь ЖЦ ПС и обучать разработчи¬
ков ПС квалифицированному применению соответствующих инст¬
рументальных средств и технологий.
Специалисты, управляющие обеспечением качества Лс.
должны овладеть стандартами и методиками фирмы, поддерживаю¬
щими регистрацию, контроль, документирование и воздействия на
показатели качества и ТЭП на всех этапах ЖЦ программ. Они долж¬
ны обеспечивать эксплуатацию системы качества проекта, выявле¬
ние всех отклонений от заданных показателей качества объектов и
процессов, а также от предписанной технологии на промежуточных
и заключительных этапах разработки. Эти же специалисты должны
анализировать возможные последствия выявленных отклонений от
требований технического задания или спецификации на ПС. В ре¬
зультате должны приниматься меры либо по устранению отклоне¬
ний, либо по корректировке требований, если устранение отклоне¬
ний требует чрезвычайно больших затрат ресурсов.
Для реализации крупномасштабных проектов ПС с учетом ТЭП
наиболее часто применяются две схемы организации коллективов
специалистов:
- формирование для выполнения каждого проекта жесткой ор¬
ганизационной структуры целостного коллектива с полным соста¬
вом необходимых специалистов под единым, централизованным ру¬
ководством лидера проекта;
- выделение руководителя (главного конструктора) и неболь¬
шой группы интеграторов, по заданиям которых выполняются част¬
ные работы узкими специалистами по компонентам, не входящими
организационно в единый коллектив для реализации каждого кон¬
кретного крупного проекта.
Первая схема предпочтительна, когда фирма реализует не¬
большое число особенно крупных проектов-заказов и имеет воз¬
можность для каждого из них скомплектовать полноценную, орга¬
низационно замкнутую, «команду». Она полностью реализует про¬
ект и несет ответственность за его качество. Однако при этом воз¬
можны простои отдельных специалистов вследствие ожидания зада¬
ний или результатов последовательных этапов проектирования ком*
понентов другими специалистами. Вторая схема для фирмы мо*с1
иметь преимущества при большом числе относительно небольши-4
проектов, близких по содержанию и функциональному назначени*0
Глава 4. Факторы, влияющие на затраты при разработке... 201
! компонентов. В этом случае большинство специалистов одновре-
] менно участвуют в нескольких заказах по локальным заданиям ли¬
деров и интеграторов различных проектов, и может использоваться
Е" лее полно. Однако задачи интеграторов при этом усложняются и
ебуют более высокой квалификации. Хотя за качество проекта в
. _ лом также несут ответственность руководитель - лидер и группа
);интеграторов, усложняется взаимодействие с поставщиками компо-
I нентов и руководство их качеством.
: t< Структура коллектива разработчиков в значительной
( степени отражает структуру разрабатываемого ПС. Особенно это
заметно при создании крупных комплексов программ размером 105
- 107 строк. При этом группы функциональных программ локализу-
! | ются по соответствующим группам специалистов с целью миними-
! ^зации связей и взаимодействия как между группами разработчиков,
так и между создаваемыми ими программами. В целом тенденция
состоит в том, что профессионалы в различных областях техничес-
I кого и научного применения ЭВМ достаточно быстро осваивают
I программистскую и технологическую квалификацию и обычно
являются лидерами при разработке ПС соответствующего назначе¬
ния или его крупных функциональных компонентов.
■ Для реализации мероприятий по планированию и управлению
^жизненным циклом концептуально целостных, крупномасштабных
I ПС и обеспечения их качества в пределах допустимых затрат, необ¬
ходимы организационные действия системных архитекторов, на¬
правленные на подбор и обучение коллектива специалистов разных
категорий и специализаций. Перечисленные выше специализации и
квалификации персонала, участвующего в крупномасштабных про¬
ектах ПС, требуют соответствующей их подготовки, отбора и
непрерывного обучения, которые являются самостоятельной, важ¬
ной проблемой в технико-экономическом обосновании всего ЖЦ
комплексов программ. Обучение представляет собой процесс и тре¬
бует организации и сопровождения обучаемого персонала. Должны
быть разработаны и документированы планы, требования и цели
обучения, а также разработаны руководства, включая материалы,
используемые для обучения (см. шестую часть ISO 15504, [20]).
Персонал, ответственный за выполнение конкретных задач, если это
Необходимо, должен быть аттестован на основе соответствующе¬
го образования, подготовки и/или опыта работы. Может также стать
202
Технико-экономическое обоснование проектов
необходимым включение в подготовку, ознакомление со специфи¬
ческой (проблемно-ориентированной) областью, в которой буде,
работать данное программное средство, и повышение квалификации
в этой области.
Целесообразно активно привлекать заказчиков к управлению
требованиями и масштабом проекта, чтобы обеспечить как качество,
так и своевременность разработки ПС. Именно заказчики несут фи¬
нансовую ответственность за выполнение внешних обязательств пе¬
ред пользователями. Необходимы согласия заказчиков при принятии
основных решений, и только они могут реально определить, как.
сократив функции ПС, получить полезный комплекс программ вы¬
сокого качества, выполненный в срок и в пределах бюджета. При¬
влечение заказчика помогает наименее болезненно решить пробле¬
мы управления масштабом и функциями проекта.
Необходимость всегда выполнять значительную долю творчес¬
ких работ, которые даже для высококвалифицированных коллекти¬
вов требуют определенных затрат, приводит к пониманию наличия
потенциальных предельных значений ТЭП для полностью новых
разработок. По мере повышения квалификации коллектива и авто¬
матизации творческой части труда следует ожидать асимптотиче¬
ского приближения к потенциальным значениям интегральных ТЭП.
Эти предельные значения определяются возможностями человека по
интенсивности принятия творческих решений.
При технико-экономическом обосновании проектов сложных
ПС рассчитать такие характеристики вряд ли возможно, и реальным
путем их оценки являются изучение и экстраполяция эксперимен¬
тальных данных реальных разработок ПС с наилучшими ТЭП с
учетом возрастания квалификации специалистов и уровня автомати¬
зации. Эти факторы способствуют эволюционному, относительно
медленному приближению к предельным ТЭП для новых крупно¬
масштабных ПС. Предельные значения производительности труда-
обусловленные долей творчества, по-видимому, в два-три раза
выше, чем современные значения для наилучших коллективов при
среднем уровне автоматизации разработки и квалификации специа¬
листов. Вряд ли можно ожидать в ближайшие годы повышения
производительности труда на порядок для полностью новых.
сложных ПС. Еще более консервативна длительность разработки
(см. п. 3.1). Принципиальным путем улучшения ТЭП при разработке
лава 4. Факторы, влияющие на затраты при разработке.
203
сложных ПС является исключение творчества на тех этапах, где
озможны типовые стандартные решения и заготовки, не требую¬
щие при их многократном применении высококвалифицированного
творческого труда. Основой такого подхода является сборочное
лрогралширование на базе единой технологии, базы данных
товых апробированных компонентов и стандартизированной
'"архитектуры определенных классов ПС (см. п. 3.2).
| 4.4. Влияние технологической среды на затраты
| при разработке программных средств
В Затраты на технологию и программные средства автома-
Iтизации разработки ПС обычно являются весьма весомыми при
■использовании высокоэффективных автоматизированных техноло¬
гий. При технико-экономическом обосновании проекта следует
учитывать, что размер и сложность создаваемого ПС значительно
[влияет на выбор инструментальных средств и уровня автоматизации
’ технологии, а также на долю этих затрат в общих затратах на разра¬
ботку. Встречаются ситуации, при которых затраты на технологию
достигают 50% общих затрат на разработку. Такие затраты могут
быть оправданы повышением производительности труда, сокраще¬
нием сроков разработки и последующим снижением затрат на мно¬
жество базовых версий ПС. Однако чаще всего эта группа затрат
при создании первой версии сложных ПС находится в пределах 30%
от суммарных затрат. В первом приближении степень автоматиза¬
ции разработки программ отражает размер программных средств,
используемых в технологических системах. Этот показатель соот¬
ветствует сложности систем автоматизации разработки программ и
I пропорционален затратам на их приобретение или создание и экс¬
плуатацию.
I Затраты, обеспечивающие технологическую оснащенность
Ркизненного цикла ПС можно представить двумя составляющими:
ft - оснащенностью специалистов методами и инструменталь¬
ными программными средствами, автоматизации технологических
[процессов разработки, изготовления и сопровождения программ
(программная «энерговооруженность»);
204
Технико-экономическое обоснование проектов.
- оснащенность аппаратными средствами вычислительной
техники, используемыми в жизненном цикле ПС для автоматизации
технологии (аппаратурная «энерговооруженность»).
Виды оснащенности желательно характеризовать численно и в
одинаковых единицах, что позволило бы сопоставлять обобщенный
уровень технологий в разных проектах и оценивать эффективность
затрат на повышение составляющих оснащенности разработок.
Однако, их значительное физическое различие и трудность оценки
эффективности их воздействия на технико-экономические показате¬
ли процессов создания программ, приводят к нескольким показате¬
лям, каждый из которых только в некоторой степени характеризует
оснащенность. В отдельных случаях этот показатель может описы¬
ваться, базируясь на гипотезе, что обеспечение заданной оснащен¬
ности пропорционально затратам.
Стремление уменьшить технологические затраты в период раз¬
работки без учета последующего использования ПС, его компонен¬
тов и всего жизненного цикла может оказаться мало полезным, а в
некоторых случаях привести к значительному увеличению совокуп¬
ных затрат в ЖЦ. При применении сложных ПС эти затраты исчис¬
ляются сотнями человеко-лет, что определяет особую актуальность
их снижения. Поэтому необходим системный анализ распределения
и использования технологических ресурсов на разработку программ
с учетом всего их жизненного цикла, включая сопровождение и
возможный перенос на другие платформы.
В большинстве случаев технология и средства автоматизации
создаются для проектирования многих (М) ПС. При этом затраты на
их создание входят в стоимость каждой версии ПС только М-ой до¬
лей. Величина этой доли зависит от широты применения данного
средства, т.е. от общего числа М экземпляров технологической сис¬
темы, использованных за цикл жизни технологии или за некоторый
нормативный срок. При разработке каждого ПС эта доля увеличива¬
ется на величину, обусловленную затратами на внедрение и освое¬
ние технологии и на величину, связанную с ее эксплуатацией. Таки"
образом, затраты на технологическое обеспечение разработки
ПС можно представить следующими составляющими:
- долей суммарных затрат на приобретение или создание тех¬
нологии и системы автоматизации разработки программ;
Глава 4. Факторы, влияющие на затраты при разработке.
205
- однократными затратами на внедрение и освоение техноло¬
гии и средств автоматизации, а также на подготовку версии техно¬
логической системы адаптированной к конкретным условиям при¬
менения для разработки данного ПС;
- затратами на эксплуатацию средств автоматизации в течение
всего календарного времени разработки или ЖЦ данного ПС;
- на создание технологии и инструментальных средств для ис¬
пытаний и оценивания требуемых характеристик качества про¬
граммного средства;
- на выполнение измерений и оценивания достигнутых значе¬
ний характеристик качества ПС.
Стремление использовать апробированные технологии и инст-
| рументальные системы проводит к тому, что в этих случаях первую
| составляющую иногда можно игнорировать. Некоторые средства
автоматизации используются в готовой версии и не адаптируются к
конкретным условиям применения, тогда доминирующей становит-
!ся последняя составляющая. Минимизации этих затрат способствует
массовое применение типовых технологий с высоким уровнем авто¬
матизации. Технико-экономические показатели и качество комплек¬
сов программ определяется не только величиной общих затрат на
достижение требуемого значения каждой характеристики качества,
но и тем как распределяются и используются эти ресурсы.
Уровень автоматизации и качество технологии и инстру¬
ментальных средств, используемых для поддержки всего жизнен¬
ного цикла ПС, обычно сильно коррелирован с достигаемым качест¬
вом комплексов программ, а также с качеством средств автоматиза-
I ции для оценивания этого качества. Оценивание качества техноло¬
гической базы ЖЦ позволяет прогнозировать возможное качество
ПС и ориентировать заказчика и пользователей при выборе разра¬
ботчика и поставщика для определенного проекта с требуемыми ха¬
рактеристиками качества. Очевидно, что низкий уровень технологии
и средств разработки программ, не может обеспечить их высокое
качество и достоверное его оценивание. Поэтому определение уров¬
ня зрелости технологической поддержки процессов жизненного
Цикла, организационного и инструментального обеспечения качест¬
ва ПС, непосредственно связано с выбором и оцениванием реаль¬
ных или возможных характеристик качества конкретного ком¬
плекса программ [12, 18].
206
Технико-экономическое обоснование проектов.
В модели СОСОМО для оценивания и повышения технико¬
экономических показателей при разработке ПС рекомендуется
методология обеспечения качества сложных программных средств
СММ (Capability Maturity Model) - система и модель оценки зре¬
лости комплекса, применяемых технологических процессов жиз¬
ненного цикла ПС [20]. Она основана на формализации и использо¬
вании пяти уровней зрелости технологий поддержки всего ЖЦ IIC',
которые также определяют потенциально возможные ТЭП и качест¬
во создаваемых на предприятии комплексов программ. Чем выше
уровень зрелости, тем выше статус предприятия среди поставщиков,
доверие к его продукции, его конкурентоспособность, а также воз¬
можное качество ПС. Тем самым при прогнозировании затрат и вы¬
боре значений характеристик качества ПС (см. гл. 2) можно в соот¬
ветствующей степени доверять поставщику и предприятию разра¬
ботчика, что оно сможет реализовать согласованные требования за¬
казчика. Эти уровни зрелости характеризуются степенью форма¬
лизации, адекватностью измерения и документирования процессов и
продуктов ЖЦ ПС, широтой применения стандартов и инструмен¬
тальных средств автоматизации работ, наличием и полнотой реали¬
зации функций системой обеспечения качества технологических
процессов и их результатов.
Методология обеспечения качества ПС поддержана рядом ме¬
тодических документов, а также формализована международными
стандартами ISO 12207:1995 и ISO 15504:1-9:1998. Имеются случаи
успешного и эффективного применения СММ для ответственных,
крупномасштабных проектов ПС, однако следует учитывать, что
внедрение и освоение системы требует больших усилий и затрат.
Это ограничивает ее массовое использование для относительно про¬
стых и средней сложности проектов.
Описание процессов ЖЦ ПС в СММ сфокусировано на опреде¬
лении затрат, реально достигаемых результатов и на оценивании
качества их выполнения. Качество процессов зависит от технологи¬
ческой среды, в которой они выполняются. Зрелость процессов -
это степень их управляемости, возможности поэтапной количест¬
венной оценки затрат и качества, контролируемости и эффективно¬
сти результатов. Модель зрелости предприятия представляет собой
методический материал, определяющий правила создания и приме¬
нения системы управления жизненным циклом ПС и методы систе-
Глава 4. Факторы, влияющие на затраты при разработке.
207
матического повышения культуры и качества производства ком¬
плексов программ. Повышение зрелости обеспечивает потенциаль-
Уную возможность увеличения технико-экономической эффективно¬
сти и согласованности использования процессов создания, сопрово¬
ждения и оценивания качества компонентов и ПС в целом. Реальное
использование процессов предполагает их документирование, пе¬
чатанный контроль ТЭП и характеристик качества ПС. На предпри-
,ятиях, достигших высокого уровня зрелости, процессы ЖЦ ПС
должны принимать статус стандарта, фиксироваться в организаци¬
онных структурах и определять производственную тактику и страте¬
гию корпоративной культуры производства и системы обеспечения
качества ПС.
Назначение СММ - состоит в предоставлении необходимых
руководств и инструкций предприятиям, производящим ПС, по вы¬
бору стратегии повышения характеристик качества процессов и про¬
граммных продуктов путем анализа степени их производственной
1 зрелости и оценивания факторов, в наибольшей степени влияющих
Q на ЖЦ ПС, а также выделение процессов, требующих модерниза-
| ции. При технико-экономическом обосновании проектов, для дос¬
тижения впоследствии устойчивых результатов в процессе развития
технологии и организации управления жизненным циклом ПС реко¬
мендуется использовать эволюционный путь, который позволяет
совершенствовать, постепенно снижать затраты и повышать качест¬
во процессов и продуктов. Фокусируя внимание на небольшом ко¬
личестве наиболее критичных операций и характеристик качества, и
м планомерно повышая эффективность и качество их выполнения,
1,1 предприятие может добиваться постоянного повышения культуры и
1 уровня обеспечения ЖЦ ПС. Выбор и совершенствование уровней
зрелости в СММ связаны и должны адаптироваться к характеристи¬
кам объектов разработки, внешней среды и доступных ресурсов
проектов ПС. В методологии СММ выделены следующие уровни
зрелости - рис. 4.1.
Уровень 1 —Начальный. Наиболее массовые разработки проек¬
тов ПС характеризуются относительно небольшими объемами про-
13мм в несколько тысяч строк, создаваемых несколькими (2 - 5)
специалистами.
208
Технико-экономическое обоснование проектов
fjiaea 4. Факторы, влияющие на затраты при разработке.
209
Они применяют простейшие не формализованные технологии с
использованием типовых инструментальных компонентов операци¬
онных систем. Требования к ТЭП и качеству таких ПС формализу¬
ется только в общем виде, без конкретизации номенклатуры и тре¬
буемых значений стандартизированных характеристик. Основные
процессы ЖЦ ПС на этом уровне не регламентированы, выполняют¬
ся почти не упорядоченно и зависят от не координированных инди¬
видуальных усилий специалистов. В предприятии нет стабильной
i инструментальной среды для поддержки и документирования всей
совокупности планов, затрат и процессов ЖЦ ПС. Успех проекта,
как правило, зависит от энергичности, таланта и опыта нескольких
руководителей и исполнителей. Однако если такой специалист по¬
кидает предприятие, исчезает гарантия того, что развитие, корректи¬
ровка и совершенствование проекта или следующий подобный про¬
ект будут успешными.
Процессы на первом уровне характеризуются своей непредска¬
зуемостью по срокам и затратам в связи с тем, что их состав, назна¬
чение и последовательность выполнения меняются в зависимости от
текущей ситуации. Взаимодействие между специалистами не доку¬
ментируется и ограничивается беседами. Графики, бюджет и резуль¬
тирующее качество программного продукта в этом случае также ес¬
тественно непредсказуемы. В связи с этим при выполнении проек¬
тов, как правило, перерасходуются отпущенные на них ресурсы и
срываются заданные сроки работ. Успешными бывают только не-
■большие по трудоемкости и срокам проекты, а крупномасштабные
проекты, как правило, терпят провал. Успех в этом случае зависит в
основном от квалификации ведущих специалистов и от их активно¬
сти.
Уровень 2 - Управляемый. Для сложных проектов ПС объемом
в десятки и сотни тысяч строк, в которых участвуют десятки спе¬
циалистов разной квалификации, необходимы организация, регла¬
ментирование технологии и процессов деятельности каждого из них.
Требования к ТЭП и качеству таких проектов формулируются заказ¬
чиком более конкретно и для их выполнения используются значи¬
тельные ресурсы. Для координации работ и контроля результатов
необходимо их регулярное документирование и отслеживание изме¬
нений. Стандарты, необходимые для успешного выполнения проек¬
та, должны быть не только декларированы, но и активно применять¬
210
Технико-экономическое обоснование проектов
ся. Процессы на втором уровне заранее планируются, их выполне¬
ние строго контролируется, чем достигается предсказуемость затрат
результатов и времени выполнения этапов, компонентов и проекта в
целом. С увеличением размеров и усложнением проектов внимание
специалистов смещается с технических аспектов их выполнения на
организационные и управленческие. Выполнение процессов требует
от персонала эффективной, скоординированной работы, в соответ¬
ствии с международными стандартами.
Оценки технико-экономических показателей, планирование и
дисциплина выполнения проектных работ базируются на опыте ана¬
логичных проектов. Процессы управления проектом на этом уровне
должны обеспечивать текущий контроль стоимости проекта, графи¬
ка его выполнения и реализуемых функций. Основной особенно¬
стью второго уровня является наличие формализованных и доку¬
ментированных процессов управления проектами, которые пригод¬
ны для модернизации и результаты поддаются количественной
оценке. На этом уровне акценты управления сосредоточиваются на
упорядочении и регламентировании графиков процессов создания,
сопровождения и оценивания качества программного средства, од¬
нако для крупномасштабных проектов ПС с гарантированным каче¬
ством риск провала остается еще достаточно большим.
Уровень 3 - Фиксированный. При высоких требованиях заказ¬
чика и пользователей к конкретным характеристикам качества
сложного ПС и к выполнению ограничений по использованию ре¬
сурсов, необходимо дальнейшее совершенствование и повышение
уровня зрелости процессов ЖЦ ПС, что является причиной для пе¬
рехода к регламентированию и контролю качества технологических
и организационных процессов на третьем уровне. Участие в проекте
нескольких подразделений и десятков специалистов с разными
функциями требует четкой организации и документирования ре¬
зультатов их труда. Процессы ЖЦ ПС на этом уровне должны быть
стандартизированы и представляют собой единую технологическую
систему, обязательную для всех подразделений предприятия. При
этом во всех проектах используется апробированная, утвержденная
и возведенная в статус стандарта предприятия единая технология
создания, конфигурационного управления и сопровождения ПС. Па
этом уровне в предприятии создается специальная группа, ответе f
венная за состав и регламентирование очередности операций, из к°
Глава 4. Факторы, влияющие на затраты при разработке... 211
[торых состоят процессы, и за систему обеспечения качества их ре¬
зультатов. С тем, чтобы более эффективно использовать такую тех¬
нологическую систему, в предприятии необходима специальная
’ программа обучения и повышения квалификации специалистов.
■ На основе единой технологической системы поддержки и обес¬
печения ЖЦ ПС, для каждого проекта могут разрабатываться до¬
полнительные процессы оценивания качества продуктов с учетом их
| Особенностей. Описание каждого процесса должно включать усло¬
вия его выполнения, входные данные, стандарты и процедуры вы¬
полнения, механизмы проверки результатов, выходные данные, ус¬
ловия и документы завершения процесса. В описания процессов
включаются сведения об инструментальных средствах, необходи¬
мых для выполнения, роль, ответственность и квалификация спе¬
циалистов. Интеграция процессов должна обеспечивать поэтапную
Преемственность результатов выполнения задач без дополнительных
преобразований промежуточных данных.
Уровень 4 - Предсказуемый. Для реализации проектов круп¬
номасштабных, особенно сложных ПС в жестко ограниченные сроки
и с высоким гарантированным качеством, необходимы активные
меры для прогнозирования и контроля ТЭП, предотвращения и вы¬
явления дефектов на всех стадиях ЖЦ ПС. Коллектив специалистов-
разработчиков в тесном взаимодействии с заказчиком должен не¬
прерывно координировать и уточнять спецификации требований к
программному продукту, а также осуществлять текущий контроль за
ресурсами, процессами ЖЦ и их результатами. Управление должно
обеспечивать выполнение процессов в соответствии с текущими
^Требованиями к характеристикам компонентов и ПС в целом. На
четвертом уровне, должна применяться система детального поэтап¬
ного оценивания ТЭП и характеристик качества, как технологиче¬
ских процессов ЖЦ, так и самого создаваемого программного про¬
дукта и его компонентов.
Для всего предприятия должна разрабатываться единая про¬
грамма количественного контроля затрат, обеспечения и оценивания
Характеристик качества ЖЦ ПС. Для поддержки такого анализа
Должна использоваться единая база данных процессов и результатов
создания и сопровождения ПС, выполняемых в предприятии. Долж¬
ны разрабатываться и применяться универсальные методики коли¬
чественной оценки реализации процессов и их качества. Одновре¬
212
Технико-экономическое обоснование проектов
менно с повышением сложности и требований к ПС, следует совер¬
шенствовать управление проектами за счет сокращения текущИч
корректировок и исправлений дефектов при выполнении процессов
Результаты процессов на четвертом уровне становятся предсказуе¬
мыми по затратам и срокам в связи с тем, что они измеряются в ходе
их выполнения и реализуются в рамках заданных ресурсных огра¬
ничений. На этом уровне появляется возможность заранее планиро¬
вать требуемое и достигаемое качество выполнения процессов и ко¬
нечного продукта.
Уровень 5 - Совершенствуемый. Основное назначение пятого
уровня - дальнейшее последовательное совершенствование и мо¬
дернизация технико-экономических показателей процессов ЖЦ ПС
для снижения затрат, повышения качества ПС, выполнения и рас¬
ширение глубины контроля за их реализацией. В целях плановой
модернизации технологии создания ПС должно создаваться специ¬
альное подразделение для обеспечения контроля затрат, графика и
качества процессов, основными обязанностями персонала которого
является сбор данных о выполнении процессов и их результатах,
анализ, модернизация имеющихся и создание новых процессов, их
проверка на пилотных проектах и придание им статуса стандартов
предприятия.
Одна из основных целей пятого уровня - сокращение потерь
ресурсов и качества от случайных дефектов и ошибок, путем выяв¬
ления сильных и слабых сторон используемых технологических
процессов. При этом приоритетным является анализ рисков, дефек¬
тов и отклонений от заданных требований и ТЭП заказчика. Эти
данные также используются для снижения затрат и стоимости ЖЦ
особо сложных ПС в результате внедрения новых технологий и эф¬
фективного инструментария, а также для планирования и осуществ¬
ления модернизации всех видов технологических процессов. Техно¬
логические нововведения, которые могут принести наибольшую
экономическую выгоду, должны стандартизироваться и адаптиро¬
ваться в технологию обеспечения и оценивания системы качества
предприятия и его продукции.
Методология СММ рекомендует большой комплекс процессов-
который предприятие должно выполнять для приобретения, постав¬
ки, разработки, использования и сопровождения ПС, и виды ДеЯ'
лава 4. Факторы, влияющие па затраты при разработке.
213
тельности, характеризующие степень технологической зрелости
тих процессов. Виды деятельности для высоких уровней зрелости в
СММ делятся на базовые и общие. Базовые виды деятельности и
процессы являются обязательными и сгруппированы в пять кате¬
горий.
Контрактная категория (заказчик-поставщик) состоит из ви¬
дов деятельности, непосредственно влияющих на взаимодействие с
-аказчиком, они поддерживают комплекс процессов технико¬
экономического обоснования разработки, испытаний и передачи ПС
заказчику и обеспечивают возможность его корректного использо¬
вания.
Инженерная категория включает виды деятельности, которые
непосредственно определяют, реализуют или поддерживают жиз¬
ненный цикл программного продукта и документацию на него.
Управленческая категория определяет все аспекты управления
проектом и координацию использования его ресурсов в ЖЦ или при
предоставления услуг, удовлетворяющих заказчиков ПС.
Вспомогательная категория включает виды деятельности, ко¬
торые обеспечивают совершенствование основных технологических
процессов, и поддерживают производительность остальных процес¬
сов в проекте.
Организационная категория определяет цели предприятия-
разработчика, и формирует методы управления, необходимые для
повышения качества использования ресурсов и всего ЖЦ ПС.
Общие виды деятельности приложимы к любому процессу и
необходимы для управления им и улучшения характеристик его вы¬
полнения. Они включаются в группы и уровни производственной
зрелости.
В модели СОСОМО приводятся количественные рекоменда¬
ции коэффициентов влияния уровней зрелости СММ на трудо¬
емкость реализации сложных проектов ПС - таблица 4.13.
Влиянию технологической зрелости разработки ПС в детальной
модели СОСОМО сопоставлены уровни СММ, для каждого из кото¬
рых приводятся коэффициенты изменения трудоемкости разработки.
Среднему - номинальному уровню оценки в модели СОСОМО со¬
ответствует уровень 2 СММ, при котором для крупномасштабных
ПС трудоемкость повышается в 4,68 раза относительно достигаемой
214
Технико-экономическое обоснование проектов.
при использовании наиболее совершенной технологии с пятым
уровнем зрелости СМ М.
Таблица 4.13
Технологическая зрелость разработки программных средств
Характе¬
ристика
1
Уровень оценки
Очень
низкий
Низкий
Номи¬
нальный
Высокий
Очень
высокий
1
Сверх |
высокий
Технологи¬
ческая
зрелость
процесса
разработки
CMlvf
Уровень
1
СММ
Уровень
1
СММ
Уровень
2
СММ
Уровень
3
СММ
Уровень
4
СММ
Уровень !
5
1
Козффицнеит
повышения
трудоемкости
разработки
7,8
6,24
4,68
3,12
1,56
0,00
1
Таким образом, применение совершенных технологий и инст¬
рументальных средств высшего уровня зрелости может снизить тру¬
доемкость разработки сложных ПС в 3 - 5 раз по сравнению с наи¬
более широко применяемыми технологиями второго - третьего
уровня зрелости СММ. Независимую оценку уровня СММ, выбран¬
ной технологии разработки сложного ПС, можно использовать как
ориентир при прогнозировании и технико-экономическом обос¬
новании предполагаемого проекта. Естественно, применение техно¬
логии разработки крупномасштабных ПС, характеризующейся вы¬
соким уровнем зрелости, соответствует высокая производительность
труда коллектива разработчиков и снижение относительной труд0"
емкости и длительности реализации таких проектов.
Для приближенной оценки влияния на трудоемкость неко¬
торых характеристик разработки ПС, в детальной модели СОСОМ^
выделена небольшая группа показателей (таблица 4.14) и соответст¬
вующие им наборы рейтингов (таблица 4.15).
Глава 4. Факторы, влияющие на затраты при разработке.
215
Таблица 4.14
Характеристика процессов разработки программных средств
Характеристика
Содержание характеристики
Очень
низкое
Низкое
Номина¬
льное
Высокое
Очень
высокое
Инегрументальная
поддержка
Отдель¬
ные
простые
инстру¬
менты
Простые
интегриро¬
ванные
инсгру-
менты
Базовые
интегриро¬
ванные
инстру¬
менты
Компле¬
ксные
интегри¬
рованные
системы
Ограничения
ериков разработки
75%
85%
100%
130%
160%
Таблица 4.15
Рейтинги процессов разработки программных средств
Характеристика
Уровни оценки
Очень
низкий
Низкий
Номина¬
льный
Высокий
Очень
высокий
Инструментальная
Поддержка
1,17
1,09
1,00
0,90
0,78
Ограничения
сроков разработки
1,43
1,14
1,00
1,00
1,00
Распределение
процессов
разработки
1,22
1,09
1,00
0,93
0,86
216
Технико-экономическое обоснование проектов
Инструментальные системы, поддерживающие разработку
описаны качественными характеристиками и рейтингами, изменяю,
щими трудоемкость в пределах приблизительно 20% от средней
номинальной. Уровень технологии и комплекса инструментальных
средств особенно сильно влияет на ТЭП крупных проектов ПС. По¬
этому затраты на их реализацию и применение, целесообразно учи¬
тывать конкретно с использованием функций и характеристик про¬
екта. Рейтинги инструментальной поддержки коррелированны с
уровнями зрелости технологий разработки программ СММ и ком¬
ментированы в таблице 4.13.
В этих же таблицах отмечено влияние на трудоемкость ПС ди¬
рективного ограничения сроков разработки относительно типовых
- номинальных. При ограничении сроков до уровня 75% от номи¬
нальных, сокращению трудоемкости может сопутствовать значи¬
тельное снижение качества ПС и увеличение рисков реализации
проекта. В приведенных данных неявно предполагается, что руково¬
дство проекта заранее знает о требуемом уменьшении или увеличе¬
нии сроков разработки и в состоянии вести планирование и управ¬
ление проектом наиболее выгодным, с точки зрения минимизации
трудоемкости или стоимости. При увеличении сроков разработки
это приводит к большим затратам времени меньшей группой проек¬
тировщиков на тщательные разработку и подтверждение требований
к ПС, на спецификаций проекта, составление планов тестирования.
Для уменьшения сроков разработки есть ряд путей, с помощью ко¬
торых руководство может добиваться некоторого ускорения разра¬
ботки за счёт увеличения трудоемкости и стоимости проекта:
- обеспечить детальные структурирование комплекса про¬
грамм на модули и спецификации интерфейса для обеспечения мак¬
симального параллелизма работы специалистов;
- приобрести технологические, инструментальные средства
для более быстрого кодирования, контроля и тестирования и обу¬
чить разработчиков их использованию;
- обеспечить дополнительную подготовку программистов и
группы тестирования к работе в тематической области функции
проекта;
- привлечь дополнительный вспомогательный персонал;
- отложить на время не существенное документирование пр0'
Глава 4. Факторы, влияющие на затраты при разработке... 217
Тем не менее, есть предел сокращению сроков разработки с по¬
мощью увеличения числа специалистов и приобретения оборудова¬
ния. Этот предел приходится примерно на 75% от оптимального,
|типового срока разработки. При максимально возможном сокраще-
1 нии сроков разработки до 75% от оптимального, затраты возрастают
I на 23%.
Показателем «распределение разработки» в СОСОМО реко¬
мендуется учитывать негативное влияние на трудоемкость террито¬
риального распределения соисполнителей проекта. Влияние про-
1|ртранственного распределения процессов создания компонентов
I крупного проекта, и взаимодействия субподрядчиков с использова¬
нием различных методов телекоммуникации, от электронной почты
до широкополосной видео конференции, отражено рейтингами в
[нижней строке таблицы 4.15.
При разработке комплексов программ систем реального време¬
ни большие затраты могут потребоваться для обеспечения отладки
I и испытаний, которые отдельно не учитываются моделью СОСО¬
МО. Приведенные в п. 3.3 распределения трудоемкости и других
показателей по этапам работ получены экспериментально, когда от-
Вносительно мало внимания уделялось организации проектирования,
Павтоматизации начальных этапов разработки, применению специфи¬
кации требований и использованию отладки в реальном времени.
НПоэтому основные усилия сосредотачивались на процессах про-
|раммирования и автономной отладки компонентов. На этих этапах
I выявлялась основная масса ошибок, хотя при использовании ПС и
сопровождении обнаруживалось некоторое их количество. Впослед-
II ствии центр тяжести разработки сложных ПС сдвинулся к началь-
'1 ным этапам и внимание акцентировано на предотвращение оши¬
бок, прежде всего путем тщательного системного проектирования
ПС из готовых программных компонентов, а также на комплексной
Jj отладке и испытаниях в реальном времени. Вследствие этого рас¬
пределения анализируемых технико-экономических показателей де¬
формировались, их максимумы сдвинулись в сторону начальных и
конечных этапов. На трудоемкость и длительность комплексной от¬
ладки, тестирование и испытания ПС оказывают влияние три груп¬
пы факторов [26, 38, 46]:
- доля затрат на отладку, тестирование и испытания в общем
роцессе разработки ПС;
218
Технико-экономическое обоснование проектов
- доля творческого труда при отладке и испытаниях ПС;
- относительное число готовых апробированных, ранее отла¬
женных и испытанных компонентов, используемых в данной версии
ПС.
Этапы комплексной отладки, испытаний и модификации про¬
грамм имеют много общего, в основе которого лежит широкое при¬
менение их тестирования для обнаружения ошибок и удостоверения
функциональной корректности ПС. Разработка детерминированных
тестов при отладке модулей и некоторых групп программ в боль¬
шинстве случаев производится вручную. Однако их доля может со¬
ставлять заметную часть общих затрат на отладку компонентов.
Достаточно автономными и локализуемыми обычно являются затра¬
ты на стохастические тесты и тесты в реальном времени, используе¬
мые при комплексной отладке. Для этого необходимы методы и
средства автоматизации, обеспечивающие генерацию тестов для
проверки функциональных групп программ и ПС в целом.
На создание и эксплуатацию таких средств может приходиться
значительная доля от совокупных затрат на разработку ПС, которая
может быть соизмеримой и даже превышать затраты на непосредст¬
венную разработку программного средства. Сложность ПС в неко¬
торой степени адекватна сложности внешней среды, являющейся
источником обрабатываемой информации и потребителем обрабо¬
танных данных, получаемых при функционировании программ.
Только для очень небольших комплексов программ можно вручную
разработать достаточно полные наборы тестов для отладки, отра¬
жающие реальные условия их эксплуатации. Для средних и больших
ПС, необходим принципиально иной подход, заключающийся в раз¬
работке автоматизированных моделей внешней среды, применяе¬
мых в качестве источников тестовых данных, затраты на которые’
необходимо учитывать при технико-экономическом обосновании
таких проектов.
В зависимости от особенностей реальных объектов их модели
создаются либо на базе аналоговой вычислительной техники с со¬
блюдением функционального и структурного подобия реальны^
объектам, либо на базе цифровых ЭВМ, содержащих программные
имитаторы исходных данных внешней среды. В п. 1.3 рассматрива¬
лись затраты на имитацию внешней среды при применении моде-111'
рующих имитационных стендов (МИС) преимущественно на С>а*е
-fnaea 4. Факторы, влияющие на затраты при разработке... 219
U
цифровых ЭВМ [18, 27, 31]. Такие стенды создаются на отдельных
щиверсальных ЭВМ с аппаратурой вывода данных в линии связи
или непосредственно на ЭВМ, реализующую создаваемый комплекс
программ.
Задача имитации тестов, особенно сложна, для ПС, функциони¬
рующих в реальном времени, когда данные, отражающие внешнюю
среду, должны поступать так же в реальном времени. Анализ эффек¬
тивности подобной имитации внешней среды при разработке ПС
целесообразно разделить на две части: оценка факторов, опреде-
|ляющих эффективность средств имитации, и оценка экономического
выигрыша при моделировании внешней среды на ЭВМ по сравне¬
нию с натурными экспериментами. Программная имитация внеш¬
ней среды на ЭВМ позволяет:
- расширять диапазоны характеристик имитируемых объектов
за пределы реально существующих или доступных источников дан¬
ных и генерировать потоки информации, отражающие перспектив¬
ные характеристики создаваемых систем;
- создавать тестовые данные, соответствующие критическим
Или опасным ситуациям функционирования объектов внешней сре¬
ды, которые невозможно или рискованно реализовать при натурных
экспериментах;
- обеспечивать высокую повторяемость имитируемых данных
при заданных условиях их генерации и возможность прекращения
/или приостановки имитации на любых фазах моделирования внеш¬
ней среды;
- проводить длительное непрерывное генерирование имити¬
руемых данных для определения безопасности и надежности функ¬
ционирования ПС, в широком диапазоне условий, что зачастую не¬
возможно для реальных объектов.
Экономическая эффективность программных имитаторов тес¬
тов тем выше, чем более сложные ПС реального времени создаются
с их применением. Они обеспечивают качество и надежность про¬
грамм. которые не достижимы при натурных экспериментах. Ряд
Характеристик внешней среды, обусловленных предельными, крити¬
ческими или опасными значениями параметров, вообще не доступен
Для проверки в реальных условиях. Несмотря на значительные за¬
каты на создание программ имитации внешней среды, сокращение
220
Технико-экономическое обоснование проектов.
объема тестирования при натурных экспериментах может много¬
кратно перекрывать эти затраты (см. п. 1.3) [18, 27, 38].
4. 5. Влияние аппаратной вычислительной среды на затраты
при реализации программных средств
При технико-экономическом обосновании проектов комплексов
программ, на оценку трудоемкости их разработки может оказать
существенное влияние ограниченность вычислительных ресурсов
специализированных, реализующих ЭВМ реального времени. Это
привело к необходимости разрабатывать методы эффективного
использования аппаратных ресурсов ЭВМ. Одним из важнейших и
наиболее общих показателей, характеризующих возможность при¬
менения таких ЭВМ, является их производительность для конкрет¬
ных задач реального времени. При этом существенным ограничи¬
вающим фактором являются длительность, в течение которой ЭВМ
может быть предоставлена для решения данной задачи, или то ре¬
альное время, в пределах которого целесообразно получить резуль¬
таты для их практического использования. Таким образом, уже на
стадии формулирования любой задачи приходится сопоставлять
доступную производительность ЭВМ с необходимыми затратами
времени для решения требуемого набора задач или с допустимой
длительностью ожидания результатов (длительностью отклика). 11о-
этому весьма актуальной для всех типов систем реального времени
является проблема эффективного распределения ограниченной
производительности ЭВМ для решения комплекса функциональ¬
ных задач и поиск методов рациональной организации вычисли¬
тельного процесса.
Быстрый рост количества решаемых задач, их сложности и тре¬
буемой производительности вычислительных средств стимулирован
поиск различных путей удовлетворения потребностей заказчиков в
ресурсах для решения таких задач. Мировая практика развития вы¬
числительной техники показала, что потребность в вычислительных
ресурсах для решения ряда задач растет быстрее, чем реальные ха¬
рактеристики ЭВМ. Технические трудности улучшения характер*1'
стик процессоров и памяти непосредственно за счет увеличения бы¬
стродействия элементной базы вычислительных систем привели к
созданию многомашинных и многопроцессорных комплексов. В *а"
Глава 4. Факторы, влияющие на затраты при разработке... 221
I.
|ких ЭВМ проблема эффективного распределения и использования
• ресурсов еще больше усложняется, так как необходимо оперативно
распределять производительность (в принципе различных) вычисли
1тельных процессоров для решения всей заданной совокупности за¬
дач. Так как задачи могут быть взаимосвязаны последовательностью
решения или обрабатываемой информацией, возникала необходи-
. мость эффективного использования памяти и производительности
ВС при параллельном решении совокупности взаимодействую-
| щих задач.
(Формальная постановка такой задачи не позволяла получать
конструктивные решения. Поэтому основные исследования были
сосредоточены на анализе частных задач и характеристик распреде¬
ления ресурсов в отдельных компонентах сложных и распределен¬
ных ЭВМ. Значительное внимание было уделено анализу эффектив¬
ности дисциплин диспетчеризации с относительными и абсолютны¬
ми приоритетами. Эти дисциплины активно применяются при орга-
шзации вычислений в специализированных, реализующих ЭВМ
эеального времени. Для практического использования характери¬
стик и методов расчета рационального распределения производи-
ельности ВС созданы методики и типовые модели, позволяющие
\анализировать диспетчеризацию в конкретных системах.
В последние годы стали возможными ситуации, когда в совре¬
менных ЭВМ реального времени может быть создан такой избыток
производительности и памяти, что нет необходимости в детальном
выборе и применении методов рационального и экономного исполь¬
зования вычислительных ресурсов при технико-экономическом
обосновании таких проектов. Однако применение более дешевых и
Рростых ЭВМ может позволить те же задачи решать при меньших
аппаратурных затратах, особенно это актуально для мобильных
ЭВМ. При ограничениях ресурсов вследствие требований миними¬
зации весов и габаритов специализированных, реализующих ЭВМ в
авиационных, ракетных и космических" системах, их экономное ис¬
пользование остается актуальным и следует учитывать при обос¬
новании соответствующих проектов ПС. Кроме того, в некоторых
случаях полезно выделение высоких приоритетов для особо важных
Или коротких задач, например, для обмена с внешними абонентами.
Н Ограничения ресурсов вычислительной среды может сильно
ажаться на затратах при разработке ПС. В этих случаях на каче¬
222
Технико-экономическое обоснование проектов
ство комплексов программ и ТЭП влияет эффективность использо¬
вания памяти и производительности реализующей ЭВМ, а также цх
ограничения при разработке и применении ПС. Выше в п. 4.2 (таб¬
лица 4.4) изложены требования согласованности проекта ПС с дос¬
тупными ресурсами, а также особенности и характеристики возмож¬
ных ограничений на эти ресурсы для разных классов ПС. В таблицах
4.16 и 4.17 приведены диапазоны характеристик памяти и произво¬
дительности ЭВМ, которые целесообразно учитывать как ограничи¬
вающие в модели СОСОМО. На практике наибольшие технические
трудности обычно вызывают ограничения производительности
реализующей ЭВМ, для преодоления которых приходится не столь¬
ко экономить программные ресурсы и сокращать размеры Г1С',
сколько искать пути увеличения производительности ЭВМ и эффек¬
тивности их использования.
Таблица 4.16
Характеристика вычислительной среды реализации
программных средств
Характеристика
Содержание характеристики
Низкое
Номина¬
льное
Высокое
Очень
высокое
Сверх
высокое
Ограничения
времени
исполнения
< 50%
< 50%
70%
95%
Ограничения по
оперативной
памяти
< 50%
70%
85%
95%
■■ -1
Изменчивость
среды
разработки
Каждые
12-1
месяца
Каждые
6-0,5
месяца
Каждые
2-0,25
месяца
Каждые
0,5 - 0,1
месяца
Глава 4. Факторы, влияющие на затраты при разработке... 223
Таблица 4.17
Рейтинги вычислительной среды реализации
программных средств
Характеристика
Уровень оценки
Низкий
Номина¬
льный
Высокий
Очень
высокий
Сверх
высокий
Ограничения
времени
исполнения
1,00
1,11
1,29
1,63
Ограничения по
оперативной
памяти
1,00
1,05
1,17
1,46
Изменчивость
среды
разработки
0,87
1,00
1,15
1,30
Влияние ограничения объема памяти реализующей ЭВМ в
детальной модели СОСОМО характеризуется долей от фактического
^размера оперативной памяти, которая будет использоваться для
^размещения программ и данных при решении возлагаемых на ЭВМ
Ьадач с приемлемой для практики точностью и надежностью.
Г Пример определения влияния на производительность труда доли
использования памяти исследован в [13]. Доля подкласса малых
(управляющих ПС (до 30 тыс. команд), представлена в базе ретро¬
спективных данных наибольшим числом объектов, в совокупности
50% объектов. Однородная группа, сформированная из этой
‘Совокупности, состоит из 16% ПС, в которых разработчики вынуж¬
дены были использовать ресурсы ЭВМ по памяти на 80 - 95 %, а
йри разработке остальных - менее чем на 50%. Средняя произ¬
водительность труда разработчиков при использовании ими опера¬
тивной памяти ЭВМ практически без ограничения, когда для
224
Технико-экономическое обоснование проектов
решения возлагаемых на ПС задач, потребовалось менее 5()о/о
объема, достигала 1,81 команды на человеко-день, а при вынужден,
ном использовании памяти на 80 - 95% от фактически имеющейся
составила 1,16 команды на человеко-день, т.е. была ниже почти на
60%. Снижение средней производительности труда приводит соот¬
ветственно к увеличению сроков разработки ПС. Таким образом
избавляя разработчиков от необходимости учета влияния ограниче¬
ний на объем используемой памяти, можно значительно повысить
среднюю производительность труда. Разумеется, это будет выгодно
в том случае, если удельная стоимость памяти (стоимость на одну
ячейку) достаточно низкая.
Изменчивость среды разработки (виртуальной машины)
может быть вызвана изменением и расширением функций Г1С,
модернизациями и устранением ошибок, частота которых вызывает
смену версий комплекса программ и соответствующие дополнитель¬
ные затраты на инструментальную среду реализации ПС. Номи¬
нальной в модели СОСОМО принята стабильность вычислительной
среды, когда изменения происходят в среднем каждые 3 месяца. При
более частых изменениях среды (каждую неделю) трудоемкость мо¬
жет возрастать на 30% (см. табл. 4.16-4.17).
При разработке крупных комплексов программ и ограниченных
ресурсах реализующих ЭВМ реального времени, кроме этих машин
могут быть необходимы дополнительные технологические и моде¬
лирующие внешнюю среду ЭВМ. В полном жизненном цикле ПС
систем реального времени в этом случае следует прогнозировать
затраты на ЭВМ для реализации комплекса программ, автоматиза¬
ции его разработки - технологическая ЭВМ и для имитации внеш¬
ней среды - моделирующая ЭВМ, которые изменяются по этапам и
значительно зависят от требований к качеству ПС, от его сложности,
предполагаемого тиража и ряда других факторов (рис.4.2).
Соотношение между этими затратами У(%) зависит от уровня
автоматизации (U) разработки программ. При низких уровнях авто¬
матизации все функции разработки решаются на реализующей ЭВМ-
По мере возрастания U повышается доля использование технологи¬
ческих ЭВМ, а затем и моделирующих ЭВМ, имитирующих внеш¬
нюю среду. При создании особо сложных ПС реального времени с
применением высоко автоматизированных технологий (уровни
СММ - U =4-5, см. п. 4.4) суммарные затраты на машинное время
J
Глава 4. Факторы, влияющие на затраты при разработке.
225
применения реализующей, технологической и моделирующей ЭВМ
могут становиться соизмеримыми.
У, %
Рис. 4.2
Затраты па технологические ЭВМ, используемые для авто¬
матизации разработки ПС реального времени включают капи¬
тальные затраты на закупку и установку соответствующих ЭВМ, а
также текущие затраты на их эксплуатацию в течение времени раз¬
работки ПС. При создании ПС реального времени и высоком уровне
автоматизации технологии, доля этих затрат может достигать 50%.
Капитальные затраты на реализующую ЭВМ для опытного образца
ПС при прогнозировании разработки программ влияют на оценива¬
ние проекта ПС косвенно, вследствие необходимости учета перспек¬
тивы тиражирования и эксплуатации системы управления или обра¬
ботки информации с данным ПС на реализующей ЭВМ с учетом ог¬
раничения её ресурсов. Затраты на эксплуатацию этой ЭВМ в про¬
цессе разработки программ обычно входят как составляющая в сум¬
марные затраты. Применение при создании ПС реального времени
специальных технологических ЭВМ позволяет снизить интенсив¬
ность использования реализующих ЭВМ за счет переноса на техно¬
логические машины ряда функций и инструментальных средств ав¬
226
Технико-экономическое обоснование проектов
томатизации разработки программ. В первом приближении затраты
на эксплуатацию технологических ЭВМ пропорциональны уровням
автоматизации технологии и полному времени функционирования
инструментальных средств автоматизации на технологических
ЭВМ.
Моделирующие ЭВМ, также как технологические, редко ис¬
пользуются при разработке уникального ПС. Поэтому капитальные
затраты на их приобретение и установку целесообразно учитывать
также в виде затрат на амортизацию в стоимости единицы времени
эксплуатации, используемого для имитации внешней среды. Поэто¬
му данная составляющая затрат пропорциональна длительности ис¬
пользования моделирующей ЭВМ на этих этапах. Перечисленные
виды затрат в некоторой степени коррелированы. Соотношение ме¬
жду ними в частности зависит от роли комплексной отладки ПС в
реальном масштабе времени.
Глава 5. Методики технико-экономического обоснования.
227
Глава 5
МЕТОДИКИ ТЕХНИКО-ЭКОНОМИЧЕСКОГО
ОБОСНОВАНИЯ ПРОЕКТОВ СЛОЖНЫХ
ПРОГРАММНЫХ СРЕДСТВ
5.1. Методика первичного, экспертного технико-экономического
обоснования разработки программных средств
При технико-экономическом обосновании проекта ПС на лю¬
бом уровне целесообразно применять методы и методики адекват¬
ные целям и этапам его реализации. Приступая к разработке ком¬
плекса программ, как в любой профессиональной деятельности, не¬
обходимо сначала провести реалистическую оценку возможного
масштаба проекта - поставленных целей, ресурсов проекта и вы¬
деленного времени [12]. Задача управления масштабом состоит в
|задании базовых требований, которые включают разбитое на компо¬
ненты ограниченное множество функций и требований, намеченных
| для реализации в конкретной версии проекта. Базовый уровень
масштаба должен обеспечивать:
- приемлемый для заказчика минимум функций и требований
к проекту;
- разумную вероятность успеха с точки зрения возможностей
коллектива разработчиков.
При оценивании масштаба следует определить приоритеты
функций для установления состава работ, согласованного между
[Заказчиком и разработчиком, которые обязательно должны быть
выполнены и для определения базового уровня масштаба конкрет¬
ного проекта с допустимым риском неуспешной реализации. Со-
I |кращение масштаба проекта до размеров, адекватных выделенному
времени и ресурсам, может привести к конфликтам заказчиков и
228
Технико-экономическое обоснование проектов
разработчиков. Для уменьшения вероятности таких конфликтов це¬
лесообразно активно привлекать заказчиков к управлению их требо¬
ваниями и масштабом проекта, чтобы обеспечить как качество, так и
своевременность разработки ПС. При этом следует учитывать, что:
- именно заказчики несут финансовую ответственность за
выполнение обязательств перед внешними клиентами и пользовате¬
лями (пусть и в несколько сокращенном, при необходимости, мас¬
штабе);
- комплекс программ, его важнейшие функции и удовлетво¬
ряемые требования принадлежат заказчику, а не коллективу разра¬
ботчиков или поставщику.
Привлечение заказчика помогает менее болезненно решать
проблемы управления масштабом проекта и реализуемыми функ¬
циями с учетом ограничений ресурсов. Любые дополнительные
функции за пределами базовых, которые реализует разработчик, бу¬
дут восприняты заказчиком как превзошедшие ожидания. В зависи¬
мости от этапа разработки сложного комплекса программ и досто¬
верности исходных данных о характеристиках и особенностях про¬
екта ПС целесообразно выбирать и применять разные методики и
сценарии технико-экономического обоснования проекта и прогнози¬
рования ТЭП. С самого начала работы над проектом ПС важно вести
постоянный учет данных о его действительной трудоемкости,
стоимости и развитии затрат и сравнивать эти данные с реальными
оценками характеристик проекта по следующим причинам:
- несовершенство исходных данных для оценивания ТЭП
(оценки размера, рейтинги влияния факторов) определяет важность
для руководителя проекта пересматривать их оценки, учитывая но¬
вую информацию, чтобы обеспечить более реальную основу для
дальнейшего управления проектом;
- вследствие несовершенства методов оценивания ПС следует
сравнивать оценки с действительными значениями и использовать
эти результаты для улучшения методов оценивания ТЭП;
- проекты ПС имеют тенденцию к изменению характеристик и
экономических факторов и руководителю проекта необходимо
идентифицировать эти изменения и выполнять реалистичное обнов¬
ление оценок затрат.
Следует согласовывать цели оценивания с потребностями в
информации, способствующей принятию решений для планирова¬
Глава 5. Методики технико-экономического обоснования.
229
ния затрат труда и других ресурсов. В общем случае необходимо
достигать сбалансированного состава целей оценивания разных
характеристик, который бы давал примерно одинаковую абсолют¬
ную величину уровня неопределенности для всех компонентов
ПС. Кроме того, каждая оценка ТЭП должна сопровождаться, указани¬
ем степени ее неопределенности. Это означает, что абсолютная вели¬
чина уровня неопределенности для каждого компонента долж¬
на быть примерно одинаковой, если в процессе принятия реше¬
ния все компоненты имеют одинаковый вес. По мере разработки
1 проекта их необходимо пересматривать и изменять, когда это ста¬
новится выгодным. Бюджетные решения, принимаемые на ран¬
них фазах должны влиять лишь на следующую фазу. Для этого в
данной главе последовательно рассмотрены и рекомендуются три
методики - рис. 5.1:
- первичная оценка ТЭП при подготовке концепции и техни¬
ческого задания на новый комплекс программ на основе экспертных
данных размера ПС, производительности труда или стоимости раз¬
работки одной строки текста программ - прототипов;
- прогнозирование ТЭП при предварительном и детальном
проектировании ПС на базе расчетных значений трудоемкости и
длительности разработки комплекса программ по данным модели
СОСОМО с учетом влияния различных дополнительных факторов;
- определение технико-экономических показателей ПС с уче¬
том доступных оценок множества факторов и календарное планиро¬
вание разработки сложного комплекса программ с использованием
системы ПЛАПС.
В качестве основных критериев выбора методик прогнозирова¬
ния ТЭП разработки ПС целесообразно учитывать возможность их
использования, как на начальных, так и на более поздних этапах
разработки, а также наличие апробирования методик в отечествен¬
ной и зарубежной практике.
В первой методике реализован метод прогноза ТЭП с учетом
экспертной оценки минимального числа факторов. Выше, в главе
3 приведены значения возможной достоверности оценки ТЭП в за¬
висимости от основных этапов разработки проекта сложного ПС и,
‘«ответственно, от возможной достоверности знаний о состоянии и
характеристиках реализации проекта (см. рис. 3.1).
Разработка
230
Технико-экономическое обоснование проектов.
т
«*
т
ей
а
(Т)
'л
т
н
с»
г
в
со
«Эи
От
в*>
а
о
С9
•л
В
н
а
ев
«е
Е
и
я
о
Рис. 5.1
Глава 5. Методики технико-экономического обоснования.
231
Данная методика экспертной оценки ТЭП может применяться,
когда определены цели и общие функции проекта ПС, сформулиро¬
ванные в концепции и первичных требованиях с достоверностью
около 30 - 40% . Основная цель оценки ТЭП - подготовить возмож¬
ность принять обоснованное решение о допустимости дальнейшего
продвижения проекта в область системного анализа, разработки
(требований и предварительного проектирования. Если оказывается,
(что рассчитанные технико-экономические показатели и требуемые
[ресурсы не могут быть обеспечены для продолжения проекта, то
возможны кардинальные решения: либо изменение некоторых ТЭП
и выделяемых ресурсов, либо прекращение проектирования данного
ПС. Учитывая полноту и достоверность доступных характеристик и
(требований к проекту ПС должны быть определены цели и воз¬
можная достоверность технико-экономического обоснования
ратрат на продолжение проектирования ПС.
I При первичном технико-экономическом обосновании сложных
! проектов ПС наибольшее значение имеют три ключевых фактора
-таблица 5.1:
- размер — масштаб, подлежащих разработке полностью новых
программных компонентов;
- размер и относительная доля готовых программных компо¬
нентов, которые могут быть заимствованы из предшествовавших
проектов и повторно использованы в новом проекте ПС;
- относительные затраты ресурсов на создание проекта: труда
специалистов, времени или бюджета на единицу размера (на строку
текста программ) проектируемого ПС.
Эти факторы могут быть оценены квалифицированными экс¬
пертами на основе имеющегося у них опыта реализации предшест¬
вовавших подобных проектов, а также использования опубликован¬
ных данных. При наличии необходимых данных важно оценить их
достоверность и возможную точность (30 - 40%). Наименее точный
из перечисленных факторов полностью определяет достоверность
расчета технико-экономических показателей проекта ПС поэтому
желательно, чтобы значения точности экспертного оценивания пе¬
речисленных факторов были сбалансированы.
232
Технико-экономическое обоснование проектов.
Таблица 5.1.
Бланк для экспертных оценок исходных данных технико¬
экономических показателей разработки комплексов программ
Экспертные оценки
исходных данных
Средние
Оптимис¬
тические
Пессими¬
стические
1. Размер - масштаб комплекса
программ (тысячи строк текста
с указанием языка программи¬
рования).
2. Относительное число строк
готовых повторно
используемых программных
компонентов (%).
3. Исходная производитель¬
ность труда при разработке
новых программ ПС (число
строк на человеко-месяц).
4. Исходная стоимость
разработки одной строки текста
программ.
5. Распределение трудоемкости
по этапам работ (график или
таблица).
Глава 5. Методики технико-экономического обоснования.
233
При наличии перечисленных исходных данных и положитель¬
ной оценке целесообразности экспертного анализа ТЭП проекта мо¬
жет реализовываться методика, состоящая из следующих шагов
(рис. 5.2):
- экспертная оценка размера - масштаба, числа строк предпо¬
лагаемого текста разрабатываемых программ, с учетом размера по¬
вторно используемых компонентов и характеристик возможного
языка программирования (этапы 1.1 - 1.2);
- экспертная оценка возможной средней производительности
труда специалистов при разработке программ и/или стоимости раз¬
работки одной сроки текста программ проекта ПС (этапы 2.1. - 2.2);
- расчет возможной полной трудоемкости и длительности раз¬
работки проекта ПС, а также среднего числа специалистов, необхо¬
димых для его реализации (этапы 3.1 - 3.3);
- обобщение основных технико-экономических показателей и
полной стоимости разработки проекта ПС, анализ результатов и тех¬
нико-экономическое обоснование рентабельности продолжения
проектирования комплекса программ (этапы 4.1 -4.2).
Достоверность прогнозов ТЭП зависит, прежде всего, от точ¬
ности экспертной оценки исходных данных', размера - масштаба
ПС и от достоверности экспертной оценки производительности тру¬
да специалистов или оценки стоимости разработки одной строки
текста программ (см. табл. 5.1). Выше (см. п. 1.2) отмечались осо¬
бенности и недостатки экспертной оценки ТЭП. Они позволяют ис¬
пользовать опыт прошлых разработок и их отличия от новых мето¬
дов, предусмотренных в конкретных проектах, а также индивиду¬
альные возможности коллектива разработчиков или другие уни¬
кальные особенности проекта. Однако, экспертные оценки зависят
от компетенции и объективности экспертов, их оптимистичности,
пессимистичности, знания существенных особенностей проекта.
Оценки одного эксперта трудно проверять и контролировать на дос¬
товерность. Из-за индивидуальных особенностей экспертов пред¬
почтительным является оценивание характеристик несколькими
экспертами и получение средних оценок на совещании группы экс¬
пертов для формирования единой оценки.
234
Технико-экономическое обоснование проектов.
Класс в функции
проекта ПС
1.1. Экспертная
оценка размера -
масштаба программ
проекта ПС
Цели анализа и
возможная
достоверность
исходных данных
1.2. Экспертная
оценка доли
готовых повторно
используемых
компонентов
Выбор методики
и сценария
оценки технико¬
экономических
показателей
Экспертная
оценка
обобщенного
размера
программ
2.1. Экспертная
2.2. Экспертная
Экспертная
оценка
оценка стоимости
производительности
разработки одной
оценка удельных
труда при разработке
строки текста
затрат на строку
программ проекта
программы проекта
текста программы
ПС
ПС
3.1. Расчет полной
3.2. Расчет полной
3.3. Расчет
трудоемкости
длительности
необходимого среднего
разработки проекта
разрабо тки проекта
числа специалистов
ПС
ПС
для разработки
проекта ПС
4.1. Обобщение основных
4.2. Анализ результатов
технико-экономических
и технико¬
показателей и полной
экономическое
стоимости разработки
обоснование
проекта ПС
продолжения
проектирования ПС
Рис. 5.2
Глава 5. Методики технико-экономического обоснования... 235
При этом возможно отсеивание оценок, связанных с неосве¬
домленностью, но группа экспертов может попасть под влияние ав¬
торитетной личности или ситуации.
Экспертная оценка размера проекта программного средства
наиболее сложная задача в этой методике (см. п. 2.2). Точность оце¬
нок должна быть сбалансирована с достоверностью экспертного оп¬
ределения или выбора характеристик других компонентов, исполь¬
зуемых при расчете ТЭП (удельной трудоемкостью или стоимостью
строки текста программы). Все методы оценивания основываются на
опыте предшествующих разработок, которые не всегда могут обла¬
дать чертами структурного программирования, использовать авто¬
матизированные инструментальные средства, языки спецификаций
или распределенную обработку данных. В этом случае для ближай¬
ших, и для перспективных целей важно осознавать отличия влияния
дополнительных факторов.
Исходными данными является концепция проекта ПС и ком¬
плекс требований к иерархическому набору приоритетов функций,
которые могут быть разбиты на предполагаемые фактические ком¬
поненты ПС. В дальнейшем разбиение может детализироваться,
формируя упрощенный или более точный уровень абстракции и
взаимодействия компонентов. Наиболее низкий и глубокий уровень
детализации, как правило, редко формируется ко времени первона¬
чальной экспертной оценки размера ПС. Обычно несколько уровней
бстракции могут определяться на весьма ранних стадиях планиро-
ания проектов. Следует учитывать, что в максимальной степени
детализированная структура ПС может принести пользу на стадии
предварительных измерений размера ПС, за которой следует стадия
более точных оценок по второй или третьей методикам (см. п. 5.2 и
5.3).
Один из путей оценки размера ПС, находящегося на этапе соз-
ания концепции проекта, заключается в сравнении его функцио¬
нальных задач и свойств с уже существующими аналогами. Конеч¬
но, данный метод не является точным, поскольку при написании
компонентов прототипов могли использоваться различные языки
[Программирования, относящиеся к разным областям приложений.
Также могли применяться разнообразные алгоритмы, имеющие раз¬
личные уровень сложности, совместно с не проверенными функцио¬
нальными свойствами, а также с различной степенью адекватности
236
Технико-экономическое обоснование проектов
моделирования реальности. Более подробно методы экспертной
оценки размера ПС представлены в п. 2.2. Их выбор зависит от кон¬
кретных условий разработки проекта, а также от возможностей ис¬
пользования информации о ранее созданных прототипах с близкими
функциональными характеристиками.
Экспертная оценка удельных затрат на строку текста про¬
грамм выше (см. гл. 3 и рис.5.2) приводилась для некоторых приме¬
ров проектов ПС. При этом подчеркивалось, что оценки относятся к
полному циклу разработки крупномасштабных комплексов про¬
грамм, начиная от создания концепции и требований до завершения
испытаний и передачи программного продукта заказчику или поль¬
зователям. В составе участников проекта учитывались все категории
специалистов, обеспечивавших реализацию программного продукта
(см. п. 4.3).
Выше в главе 3 приводилась ссылка на мнение некоторых спе¬
циалистов, что, несмотря на появление новых методов и инструмен¬
тальных средств разработки сложных ПС, средняя производитель¬
ность при их создании за последние двадцать лет осталась почти
неизменной и составляет около 3000 строк кода на одного разработ¬
чика проекта в год (порядка 250 строк на человеко-месяц) [2, 27].
Это отражает то, что уменьшение времени, затрачиваемого на цикл
разработки, не может быть достигнуто за счет значительного повы¬
шения производительности труда отдельных специалистов. Причем
это практически не зависит от усовершенствований языка програм¬
мирования, организационных усилий со стороны менеджеров, от
наличия или отсутствия некоторых отдельных видов инструмента¬
рия и автоматизации работ, хотя значительную роль играет увели¬
чившаяся доля повторно используемых компонентов. На самом деле
при достаточно высоком уровне технологии (3-4 уровень СММ -
см. п. 4.4) большое значение имеет возросший размер и сложность
состава функциональных задач комплексов программ, а также зна¬
чительное повышение требуемого качества создаваемых Г1С.
В качестве ориентиров при экспертной оценке ТЭП можно
использовать следующие данные средней трудоемкости разработ¬
ки сложных комплексов программ:
- отдельные, разрозненные сведения в публикациях о метода*
и технологиях разработки комплексов программ;
Глава 5. Методики технико-экономического обоснования.
237
j - результаты статистических исследований ТЭП проектов ПС,
, обобщенные в базовой модели СОСОМО;
| - результаты исследований экономических характеристик раз-
I работки отечественных проектов ПС, выполненных по программе
] ПРОМЕТЕЙ.
' Так как разработчики сложных комплексов программ не заин-
J тересованы раскрывать реальную экономику выполненных проек-
j тов, и эти данные склонны относить к коммерческой тайне, опубли¬
кованные ТЭП носят отрывочный, не упорядоченный и не всегда
достоверный характер. Кроме того, обычно не представляются де¬
тальные сведения об особенностях и требованиях к качеству объекта
разработки, применявшейся технологии и инструментальных сред-
j ствах, характеристиках коллектива специалистов и других фактора.
Поэтому такие данные трудно обобщать и использовать для прогно¬
зирования новых проектов. Весьма общие данные опубликованы в
виде широких диапазонов производительности труда [27]: для про¬
стых ПС - 8 SLOC на человеко-день, и 4 SLOC на человеко-день
для сложных ПС. Там же приведены широкие диапазоны произво¬
дительности труда при разработке программ на ассемблере — 60 -
500 SLOC на человеко-месяц, и 50 - 300 SLOC на человеко-месяц
для языков высокого уровня. Подобные оценки можно использовать
как ориентиры при первичных определениях ТЭП.
Более точные оценки производительности при разработке про-
[■ грамм различного размера и классов на основе обобщения статисти-
; ческих данных множества проектов представлены в базовой модели
} СОСОМО [2]:
- для встроенных комплексов программ (СРВ) размером 30
тысяч строк рекомендуется для оценок использовать производи¬
тельность около 140 строк на человеко-месяц, а для крупных ПС
размером 500 тысяч строк предлагается значение производительно¬
сти около 80 строк на человеко-месяц;
f - для программ административных систем (ИПС) размером 30
I тысяч строк оценка производительности составляет около 220 строк
на человеко-месяц, а для ПС размером 500 тысяч строк — 160 строк
f на человеко-месяц.
\ Эти данные находятся в середине представленных выше диапа¬
зонов и их целесообразно использовать при экспертной оценке пол¬
238
Технико-экономическое обоснование проектов.
ной трудоемкости разработки соответствующих новых ПС (этапы
3.1 - 3.3 на рис. 5.2).
При использовании готовых повторно используемых компо¬
нентов обобщенная производительность труда возрастает и зависиз
от доли таких компонентов в комплексе программ. Для таких ситуа¬
ций можно использовать примеры коэффициентов снижения трудо¬
емкости и длительности разработки ПС за счет применения ПИК,
изложенные в п. 3.2 и на соответствующих графиках рис.3.6 - 3.7.
В исследованиях по программе ПРОМЕТЕИ [13] при разработ¬
ке ПС класса СРВ, преимущественно на ассемблере, получена про¬
изводительность 60 - 80 строк на человеко-месяц. Для относительно
небольших комплексов программ административных систем (ИПС)
(в значительной степени на языках высокого уровня) производи¬
тельность составила около 260 строк на человеко-месяц. Таким об¬
разом, в зависимости от характеристик объекта и условий разработ¬
ки возможен экспертный выбор величин производительности труда
для последующего прогноза полной трудоемкости создания ПС.
Эти данные можно использовать для оценки полной стоимо¬
сти проекта конкретного ПС. Однако при этом необходимы удель¬
ные данные стоимости труда одного человеко-месяца специалистов
в конкретном предприятии с учетом всех накладных расходов, кото¬
рые могут различаться в несколько раз. Такие сведения обычно яв¬
ляются коммерческой тайной, и при использовании данной методи¬
ки для определенного проекта ПС, их следует запрашивать у эконо¬
мических служб конкретного предприятиям. Тем не менее, опубли¬
кованы ориентиры стоимости разработки одной строки текста про¬
грамм реального времени около 100$ и более, а для администра¬
тивных систем около 20 - 50$.
Экспертная оценка длительности разработки сложных ПС
может базироваться на экспериментальных графиках, приведенных
в главе 3, или на формулах модели СОСОМО (4.1) - (4.2). Основой
для расчета длительности целесообразно использовать рассчитан¬
ную ранее трудоемкость разработки проекта ПС, от которой не ли¬
нейно зависит длительность. Например, крупные проекты ПС ре¬
ального времени размером около 500 тысяч строк требуют для реа¬
лизации около 3,5 лет, а небольшие (30 тысяч строк) - около одного
года [2]. Полная длительность разработки ПС может быть структу¬
рирована на затраты времени по четырем или шести технологиче¬
Глава 5. Методики технико-экономического обоснования.
239
ским этапам с использованием экспериментальных таблиц и графи¬
ков приведенных в п. 3.3.
Экспертная оценка необходимого числа специалистов рас¬
считывается путем деления полной трудоемкости разработки ПС на
длительность её реализации. Для примера крупного проекта ПС ре¬
ального времени, размером 500 тысяч строк, необходимое число
специалистов достигает 160 человек [2], а для относительно не¬
большого проекта (30 тысяч строк) - в десять раз меньше (16 чело¬
век). Аналогично можно получить оценки необходимого числа
специалистов на выделенных крупных этапах разработки ПС, что
полезно для первичного формирования коллектива и оценки воз¬
можности реализации им конкретного проекта ПС.
1'Обобщенные экспертные оценки технико-экономических по¬
казателей проекта ПС целесообразно представлять в виде таблицы с
^указанием достоверности оценок результатов расчетов - таблица
5.2. Пример таких оценок в системе ПЛАПС представлен на рис. 5.3.
На основе анализа результатов и оценивания рассчитанных ха¬
рактеристик следует выполнять заключительное технико¬
экономическое обоснование проекта ПС и определять:
- целесообразно ли продолжать работы над конкретным про¬
ектом ПС или следует его прекратить, вследствие недостаточных
[ресурсов специалистов, времени или трудоемкости разработки;
- при наличии достаточных ресурсов, следует ли провести
маркетинговые исследования для определения рентабельности пол¬
ного выполнения проекта ПС и создания программного продукта
для поставки на рынок;
- достаточно ли полно и корректно формализованы концепция
и требования к проекту ПС, на основе которых проводились экс¬
пертные оценки и расчеты ТЭП, или их следует откорректировать и
выполнить повторный анализ с уточненными исходными данными;
- есть ли возможность применить готовые повторно исполь¬
зуемые компоненты ПС, в каком относительном объеме комплекса
программ и рентабельно ли их применять в конкретном проекте ПС
или весь проект целесообразно разрабатывать как полностью новый.
240
Технико-экономическое обоснование проектов
Таблица 5.2.
Бланк расчетных или экспертных оценок технико-экономических
показателей разработки комплексов программ
Экспертные оценки
расчетных данных
Средние
Оптими¬
стические
Пессими¬
стические
1. Полная трудоемкость
разработки комплекса
программ (человеко-месяцы с
указанием языка
программирования).
2. Полная длительность
разработки комплекса
программ (месяцы).
3. Необходимое среднее число
специалистов (человек).
4. Распределение трудоемкости
но этапам работ (график или
таблица).
5. Распределение длительности
но этапам работ (график или
таблица).
6. Распределение числа
специалистов по этапам работ
(график или таблица).
Глава 5. Методики технико-экономического обоснования.
241
Г13Не |р Г2«Иен>« ГБ^Печать Г1И»Вмхоп Еас»воовр |
Прогноз с минимальным числом факторов
Исходные данные
КЛНСС программного средства
Встроенное
ОПТ ИМ
ВЕРОЯТ
ЛЕССИМ
ОБЪЕМ программного средства (гмс.стр)
1*1 1
|1вв е |
|«20.в |
ПРОИЗВОДИТЕЛЬНОСТЬ (стр/чел-нес)
&* II
I 80 I
I 80 I
Прогмоаируемые
омачвнмя
ДЛИТЕЛЬНОСТЬ (пео)
20 7
24.4
20.4
ТРУДОЕМКОСТЬ (чел-мео)
743. В
«243.2
1988.2
Прогн ооирц е мые нервднвнныа аначения
ДЛИТЕЛЬНОСТЬ (пес) 24 4
ТРУДОЕМКОСТЬ (чел-пес) 1284.,
НЯКС. чиоленнооть (чел) 74
СРЕД чиоленнооть (чел) 52. •
^исанне^римен^ ^^|||^^|^^2^^^^2^|аминеаа^шм1|швв1ааавенм1|в
Рис. 5.3
5.2. Методика технико-экономического обоснования разработки
программных средств на базе модели СОСОМО 11.2000
В руководстве по применению представлены две модели ис¬
пользования СОСОМО 11.2000 - для этапов предварительного и де¬
тального (пост-архитектурного) проектирования [30]. Детальная мо-
I дель рекомендуется для применения при разработке сложных и до-
(рогих систем, когда требуется тщательный учет факторов, влияю¬
щих на оценку стоимости ПС. Предварительная модель - более вы¬
сокого уровня, предназначена для анализа общих архитектурных
решений и выработки стратегий последующей разработки при на¬
чальных сведениях о содержании проекта. В обеих моделях исход¬
242
Технико-экономическое обоснование проектов.
ным является размер комплекса программ (с учетом повторно ис¬
пользуемых компонентов) и совокупность влияющих факторов.
На этапе предварительного проектирования, после утвер¬
ждения требований и концепции проекта, повышается достовер¬
ность данных о функциях, спецификациях, компонентах и структур^
разрабатываемого комплекса программ. Это позволяет, прежде все¬
го, более точно оценить размер - масштаб ПС и возможность ис¬
пользования готовых программных компонентов из других анало¬
гичных проектов. Если достоверность оценки размера ПС может
достигать 15 - 20%, то при определении ТЭП, целесообразно сба¬
лансировано выделять и учитывать факторы, влияние которых на
трудоемкость достаточно велико, и составляет также около 20%.
Путем анализа рейтингов приведенных в главе 4, таких факторов
может быть около 10 - 15, и их число зависит от конкретных харак¬
теристик объекта и среды разработки ПС. При технико¬
экономическом обосновании проекта ПС на этом этапе, состав и но¬
менклатура учитываемых факторов должны выбираться путем ис¬
ключения из анализа, тех факторов, которые слабо влияют на ТЭП
конкретного проекта. Таким образом, методика и сценарии оценки
ТЭП должны калиброваться по шагам (этапам) в соответствии с
неопределенностью исходных данных о размере проекта ПС - рис.
5.4.
Так как величина и достоверность определения размера про¬
екта ПС ключевой фактор последующего технико-экономического
анализа (этапы 1.1 - 1.2 на рис. 5.4), то целесообразно применять
несколько доступных методов для его оценивания.
Прежде всего, необходимо использовать, ревизовать и углубить
данные экспертной оценки размера ПС, полученные при использо¬
вании предыдущей методики (см. п. 5.1), с учетом повышения дос¬
товерности характеристик проекта по результатам предварительного
проектирования. Конкретизация функций, структуры ПС и состава
компонентов проекта позволяет более достоверно определить раз¬
меры групп программ и, суммируя их, рассчитать размер всего ком¬
плекса программ. Кроме того, на этом этапе повышается возмож¬
ность выбора и использования аналогов данного проекта, так как
становятся более определенными задачи, функции и компоненты
разрабатываемого ПС, для которого желательно найти аналоги с
известными апробированными характеристиками.
Глава 5. Методики технико-экономического обоснования.
243
** Л Е
В ■ £
6ч»
м» О В
О Н В
U ж
Is
Я S
И
я
I Е Ей
[ш
! а «I
si
V faa 2
«Н §
ц
8 а
|8
4»
S
О
IH 1!
ь £ г I § t
" Iа с
JL *
1.,|!
9 5 В1 Л
м
S
1?ИВ
ills
м
с и
S с
244
Технико-экономическое обоснование проектов.
Особенно сильно на ТЭП влияет использование готовых ком¬
понентов из предшествующих разработок. При анализе аналогов
могут быть выделены компоненты, пригодные для повторного при¬
менения в новом проекте. Это позволяет оценить возможную долю
использования готовых компонентов и тем самым определить эф¬
фективный размер комплекса программ, подлежащий непосредст¬
венной разработке.
На этапе предварительного проектирования, вследствие повы¬
шения точности определения размера разрабатываемого комплекса
программ, целесообразно использовать соответственно более точ¬
ные выражения для расчета трудоемкости и длительности разработ¬
ки ПС предложенные в модели СОСОМО 11.2000 [30]. Эти выраже¬
ния базируются на статистическом анализе затрат на разработку 161
проекта сложных ПС. Первоначально целесообразно рассчитать
ТЭП разработки ПС без учета влияния дополнительных факторов
(этапы 1.3 - 1.5 на рис.5.4). Для этого могут использоваться выраже¬
ния (4.1), (4.2) детальной модели СОСОМО II представленные в гл.
4 для расчета трудоемкости (человеко-месяцы).
По значениям трудоемкости и длительности разработки ПС мо¬
жет быть рассчитана необходимая средняя численность - L = С/Т
коллектива специалистов, который должен быть выделен для реали¬
зации проекта. Однако реальная численность коллектива может не
соответствовать рассчитанному значению. Тогда оценивается допус¬
тимость получающейся длительности разработки при таком реаль¬
ном составе специалистов, которую следует сравнить с границами
«нерациональной» и «невозможной» длительности (см. п. 3.1). Если
полученная длительность превышает границу «нерациональной», то
коллектив приходится увеличивать для сокращения длительности.
Если значение длительности меньше, чем граница «невозможного»,
то коллектив можно уменьшить без ущерба для дела. В результате
должна устанавливаться и согласовываться с заказчиком рациональ¬
ная длительность разработки проекта.
Выбор состава и оценку факторов, влияющих на ТЭП кон¬
кретного проекта ПС (этапы 2.1 - 2.4 на рис.5.4) целесообразно про¬
водить по шагам при калибровании модели СОСОМО II [30] на ос¬
нове совокупности 22 факторов из таблицы 4.1. В данной методике
на этапе предварительного проектирования рекомендуется анали¬
зировать около половины из них, которые могут оказывать паи-
Глава 5. Методики технико-экономического обоснования... 245
iT
I большее влияние на трудоемкость разработки ПС (таблицы 4.2 и
' 4.3). Первоначально должна производиться оценка коэффициентов
i влияния F(j) пяти групп факторов, описанных в главе 4.
; В приведенных выражениях (4.1), (4.2) значения M(i) отражают
|! коэффициенты влияния i-ых факторов на трудоемкость разработки
;| ПС, которые первоначально (все п) считаются равными единице.
!, Предварительный расчет трудоемкости и длительности разработки
I ПС при M(i) = 1 может служить уточненным ориентиром, так как
f он базируется на более точном значении размера проекта комплекса
программ и более адекватных значениях основных коэффициентов в
1 выражениях (4.1) и (4.2), чем в первой методике (см. п. 5.1).
| Выбирать и учитывать следует те факторы, коэффициенты
I! влияния которых на трудоемкость в конкретном проекте, имеют
? достаточную величину, сбалансированную с точностью определения
ij размера комплекса программ или превышают её. Эти факторы мож-
j| но разделить на две группы, которые существенно различаются по
степени влияния на трудоемкость разработки ПС. В первую группу -
F(j) следует включать, кроме размера и доли повторно используе-
; мых компонентов, совокупность факторов, которые способны изме¬
нять трудоемкость в несколько (до 3-5) раз (см. Приложение 2):
: - новизну проекта комплекса программ;
' - необходимую степень согласованности проекта с требова-
иниями технического задания;
ji - наличие управления рисками и архитектурой проекта;
I - уровень обобщенной слаженности и организованности кол¬
> лективной разработки проекта;
I; - уровень обеспечения и оснащения технологии разработки по
j оценке СММ;
- наличие значительного ограничения сроков разработки ПС.
Вторую группу факторов M(i) следует выбирать из совокупно¬
сти перечисленных в таблице 4.2 такие, которые в конкретном про¬
екте могут повлиять на изменение трудоемкости разработки на 20 -
30%, соизмеримое с точностью оценок размера ПС:
- требования надежности ПС;
- требования степени соответствия документации программ¬
ному продукту;
- тематическая квалификация специалистов;
246
Технико-экономическое обоснование проектов.
- технологическая квалификация проектировщиков и про¬
граммистов;
- стабильность состава коллектива разработчиков;
- ограничения ресурсов объектной ЭВМ реального времени;
- стабильность требований заказчика к задачам и функциям
ПС.
Остальная совокупность факторов модели СОСОМО II обычно
может изменять трудоемкость проекта менее чем на 20% и их целе¬
сообразно учитывать в процессе или после детального проектиро¬
вания, когда точность оценивания размера проекта ПС может дости¬
гать около 10%.
Среди характеристик объекта разработки, кроме его разме¬
ра и доли, повторно используемых компонентов, наибольшее влия¬
ние на ТЭП могут оказывать новизна проекта и согласованность с
требованиями заказчика (табл. 4.4). Эти факторы в некоторых слу¬
чаях могут увеличивать трудоемкость разработки ПС в несколько
раз, что определяет необходимость особой тщательности их экс¬
пертного анализа и оценивания. Кроме того, среди характеристик
объекта разработки, значительное влияние на ТЭП некоторых кри¬
тических проектов, могут оказывать высокие требования надежно¬
сти и документированности программного продукта (табл. 4.5 - 4.6).
Они могут увеличивать трудоемкость разработки ПС более чем на
20% . Ориентирами влияния этих и других стандартизированных
требований к качеству ПС могут служить данные, приведенные в
табл. 4.7-4.8.
Среди множества характеристик коллектива разработчиков
наибольшее влияние на трудоемкость могут оказывать тематическая
и технологическая квалификации специалистов, которые в табл. 4.11
-4.12 представлены совокупностью из шести факторов. Совместно
эти факторы могут изменять трудоемкость разработки ПС на 30 -
40%. Кроме того, в модели СОСОМО II выделен и обобщен на осно¬
ве пяти характеристик коэффициент - комплексная коллективность
участников проекта (табл. 4.10), влияние которого может достигать
пятикратного изменения трудоемкости разработки ПС.
Технологическую среду и процессы разработки в СОСОМО П
рекомендуется учитывать в соответствии с уровнями зрелости моде¬
ли СММ (табл. 4.13). Это означает, что при повышении уровня зре¬
лости со второго до четвертого уровня, трудоемкость разработки
Глава 5. Методики технико-экономического обоснования.
247
может уменьшиться в три раза (от 4,68 до 1,56 - см. табл. 4.13).
Значительное влияние на повышение трудоемкости разработки (до
40%) может оказать ограничение заказчиком сроков создания ПС
до 75% от оптимального (табл. 4.14-4.15).
В некоторых комплексах программ реального времени (СРВ) на
увеличение трудоемкости разработки (до 50%) может оказать огра¬
ничение вычислительных ресурсов оперативной памяти и произво¬
дительности объектной ЭВМ, на которой функционирует ПС (табл.
4.16 - 4.17). При таких ограничениях ресурсов резко усложняется
разработка ПС и приходится адаптировать размеры алгоритмов и
программ с целью не нарушить ограничения вычислительных ресур¬
сов.
При этом следует учитывать, что приводившиеся цифры отра¬
жают максимальные изменения трудоемкости конкретного проекта
при воздействии названных факторов, или в сторону её уменьшения,
или в сторону увеличения в зависимости от специфики анализируе¬
мого фактора. При обобщении значений этих факторов и расчете
произведения M(i) следует учитывать направление изменения тру¬
доемкости при воздействии каждого фактора, после чего по формуле
(4.1) можно рассчитать уточненное значение трудоемкости разра¬
ботки ПС с учетом выделенных дополнительных факторов (этап 3.1
на рис.5.4). Далее рассчитывается по формуле (4.2) уточненное зна¬
чение длительности разработки, а затем число необходимых специа¬
листов (этапы 3.2 - 3.3). Для расчета распределения трудоемкости,
длительности и числа специалистов по этапам работ, желательно
; использовать аналогичные характеристики подобного прототипа
■ или, в крайнем случае, распределения приведенные в п. 3.3.
1 При детальном проектировании возможно значительное по¬
вышение точности определения размера - масштаба проекта ком¬
плекса программ. Последовательная детализация и конкретизация
проекта ПС позволяет уточнять его будущий размер и привлекать
|для расчета трудоемкости большее число факторов, способных по¬
высить точность прогноза ТЭП. Разработка полного содержания
спецификаций функций и структуры программных компонентов, их
аимодействия и интерфейсов, архитектуры всего комплекса про-
амм и базы данных, обычно позволяет повысить точность опреде¬
ления размера ПС с учетом особенностей языка программирования
приблизительно до 10% (см. п. 2.2). Поэтому при расчете трудоем¬
248
Технико-экономическое обоснование проектов.
кости разработки по формуле (4.1), при прогнозировании целесооб¬
разно выбирать и учитывать влияние ряда дополнительных факто¬
ров из таблицы 4.1, которые не оценивались ранее вследствие их
относительно малого влияния.
Таких дополнительных факторов может быть выделено около
10, и влияние каждого целесообразно рассматривать и учитывать
при оценках, если он способен изменить трудоемкости разработки
конкретного проекта на 5 - 10%. Анализ, выбор и оценивание коэф¬
фициентов влияния M(i), этих дополнительных факторов довольно
сложный процесс. Он оправдан, когда совместное влияние совокуп¬
ности этих дополнительных факторов может изменить оценки тру¬
доемкости на 10 - 20%. В результате расчет трудоемкости несколько
усложняется, однако процессы последующего расчета длительности
разработки и необходимого числа специалистов практически не из¬
менятся.
В целом, методика технико-экономического обоснования про¬
екта ПС с учетом ряда дополнительных факторов, практически не
отличается от предыдущей предварительной методики, однако тре¬
бует более тщательного определения размера комплекса программ,
и оценивания влияния на трудоемкость разработки большего числа
факторов. В этой методике более полно должны учитываться факто¬
ры, влияющие на трудоемкость разработки и требования к качеству
ПС, регламентированные международными стандартами (см. табл.
4.5-4.9).
Для распределения затрат по этапам разработки могут ис¬
пользоваться графики относительных затрат для соответствующего
класса ПС (см. рис. 3.8 - 3.9). Подобные графики позволяют также
оценить рациональное соотношение числа необходимых специали¬
стов разной квалификации по этапам работ. Аналогично, используя
графики распределения относительной длительности этапов,
можно оценить продолжительность основных этапов разработки
прогнозируемого проекта. Полученные данные могут служить ос¬
новой последующего календарного планирования.
Календарную длительность использования реализующей,
технологической и моделирующей ЭВМ в прогнозируемой разра¬
ботке целесообразно уточнять с учетом их относительной за¬
грузки по этапам (см. рис. 4.2) и предполагаемого распределения
программных средств автоматизации разработки по этим ви¬
Глава 5. Методики технико-экономического обоснования.
249
дам ЭВМ. Как уже отмечалось в п. 4.5, повышение уровня авто¬
матизации и программной оснащенности разработки приводит к
перераспределению степени использования видов ЭВМ и возрас¬
танию эффективно используемого процессорного времени. В
результате при повышении программной оснащенности, календар¬
ное время разработки и использования совокупности ЭВМ может
сокращаться.
При обобщении рассчитанных технико-экономических пока¬
зателей (этап 4.1 на рис. 5.4) на практике, некоторые значения, мо¬
гут не удовлетворить специалистов ведущих прогнозирование. По¬
этому в методиках допускается возможность пересчета получае¬
мых прогнозных значений на основе дополнительно вводимых зна¬
чений некоторых факторов или ТЭП. Например, на базе учтенных
при прогнозе факторов, производительность труда может оказаться
отличающейся от реальной, характерной для данного предприятия,
определявшейся по реализованным предшествующим разработкам.
Для того чтобы учесть это различие, может быть предусмотрена
возможность ввода реальной производительности специалистов
данного предприятия и пересчета всех остальных ТЭП. Это особен¬
но удобно для прогнозирования ТЭП комплексов программ относи¬
тельно небольшого размера, когда индивидуальная производитель¬
ность труда используемого коллектива и отдельных специалистов
может существенно отличаться от «усредненной», заложенной в мо¬
дель по статистике обобщения множества различных разработок.
Кроме того, на практике могут существовать ограничения реальной
численности коллектива, выделяемого для данного проекта ПС, или
допустимой (директивной) длительности разработки ПС. Для учета
таких ограничений должна быть предусмотрена возможность пере¬
счета ТЭП при дополнительно откорректированных значениях.
Достоверность рассчитанных значений основных ТЭП це¬
лесообразно проверять сопоставлением с показателями отдельно¬
го аналога созданного на том же предприятии, наиболее близкого
к прогнозируемому ПС. Полная стоимость и длительность раз¬
работки обычно подлежат согласованию с заказчиком ПС. В
процессе согласования уточняются сценарии разработки и возмож¬
но изменение не только влияния некоторых факторов, но и требо¬
ваний технического задания на объект и характеристики проекта.
Это особенно необходимо, если превышаются допустимые значе¬
250
Технико-экономическое обоснование проектов.
ния стоимости или длительности разработки. Согласованные с за¬
казчиком основные ТЭП позволяют зафиксировать базовый сцена¬
рий разработки, провести расчеты распределений трудоемкости и
длительности по этапам. По этим данным может проводиться
детальное календарное планирование и контролирование работ
всего проекта.
Таким образом, по уточненному сценарию можно опреде¬
лить основные прогнозируемые ТЭП, а также некоторые дополни¬
тельные данные для технико-экономического обоснования
проекта ПС (этап 4.2 на рис. 5.4). В результате выявляются
факторы, от которых в наибольшей степени зависят ТЭП разра¬
ботки проекта. Анализ тенденций изменения совокупных затрат и
выделенных факторов позволяет избежать грубых ошибок, свя¬
занных с нерациональным планированием распределения ресур¬
сов проекта при детальном проектировании и последующей раз¬
работке ПС. При этом обычно значения ряда факторов являются
фиксированными в силу объективных условий разработки. Только
некоторые ТЭП и факторы доступны управлению со стороны ме¬
неджера разработкой нового ПС. В отдельных случаях для выбора
наилучшей стратегии реализации проекта может быть полезным
проведение нескольких вариантов численных оценок по представ¬
ленным выше схемам решения. В крайнем случае, на основе вы¬
полненных оценок может потребоваться достоверное обоснование
прекращения разработки предполагавшегося комплекса программ
на этапах предварительного или детального проектирования.
Для практического применения модели СОСОМО II в книге
[30] опубликован пакет прикладных программ и руководство по его
применению. Оно иллюстрировано формами экранов и несколькими
обширными практическими примерами применения для технико¬
экономического анализа конкретных проектов сложных комплексов
программ. Изложены тенденции и перспективы дальнейшего разви¬
тия СОСОМО 11.2000. В шести Приложениях и текстах CD-ROM
комментируется практическое применение модели.
Глава 5. Методики технико-экономического обоснования.
251
5.3. Методика технико-экономического обоснования разработки
программных средств на базе отечественной модели ПЛАПС
Кроме рассмотренной методики на основе модели СОСОМО II,
в середине 90-х годов была разработана и апробирована методика
ПЛАПС (ПЛАнирование ПС), которая базируется на отечественных
статистических данных о завершенных разработках ПС (более 250
проектов) общим объемом около 17 млн. объектных команд (проект
ПРОМЕТЕЙ см. п. 1.1). Проанализированные разработки комплек¬
сов программ в основном относились к системам реального време¬
ни, в них применялись языки программирования низкого уровня.
Методика отражает отечественную практику создания сложных про¬
граммных комплексов. Она основана на модели и формулах анало¬
гичных (4.1) и (4.2), основные параметры и учитываемые факторы
которой частично отличаются от модели СОСОМО II. Расчеты про¬
изводятся по формулам (3.2) и (3.3) с основными коэффициентами
из таблиц 3.1 и 3.2. Эту методику целесообразно использовать на
этапах предварительного и детального проектов, когда становится
известной дополнительная информация об условиях разработки и
размере разрабатываемого программного средства. В методике учи¬
тываются следующие группы дополнительных факторов [13]:
- характеристики проектируемого программного средства;
- квалификация коллектива разработчиков;
- технологическая среда разработки;
- организация проектирования.
В качестве характеристик ПС применяются:
- доля используемых готовых программных компонентов;
- требования к надежности (наработке на отказ);
- ограничения на доступные вычислительные ресурсы - уро¬
вень (процент) загрузки ЭВМ;
- ожидаемая длительность сопровождения и эксплуатации ПС:
- ожидаемый тираж ПС:
- размер базы данных, с которой взаимодействует ПС.
Группу характеристик коллектива разработчиков включа¬
ют:
- тематическая квалификация разработчиков (опыт работы в
конкретной прикладной области, оцениваемый в годах);
252
Технико-экономическое обоснование проектов.
- программистская квалификация разработчиков (опыт рабо¬
ты на конкретном языке программирования и с определенным инст¬
рументарием, оцениваемый в годах).
Группу характеристик технологической среды разработки
составляют:
- быстродействие технологической ЭВМ, приходящееся ня
одного разработчика:
- размер - масштаб технологических программных средств:
- уровень используемого языка программирования (коэффи¬
циент расширения объектного кода программ в зависимости oi
уровня языка программирования).
К характеристикам организации процесса разработки отно¬
сятся:
- активность применения современных методов программиро¬
вания (структурное программирование, структурное проектирова¬
ние, бригада главного программиста и т.п.);
- стабильность исходных требований, представленных заказ¬
чиком в техническом задании.
В составе приведенных выше факторов подчеркнуты те, кото¬
рые отсутствуют в модели СОСОМО II, однако некоторые факторы
из этой модели не учитываются в модели ПЛАПС. При расчете тру¬
доемкости, длительности и численности специалистов по этапам
разработки в ПЛАПС используются усредненные данные на основе
опубликованных в [13] (см. п. 3.3). Если расчеты производятся после
завершения очередных этапов проектирования, то предусмотрено и
рекомендуется реальную трудоемкость и длительность этих этапов
корректировать. Для этого из получаемых при прогнозировании ре¬
зультатов можно исключать реальные затраты, соответственно на
завершенных этапах предварительного или детального проектиро¬
вания.
Представленный в п. 5.1, этап экспертного технико-экономи¬
ческого обоснования проектов ПС с учетом минимума факторов,
реализован в ПЛАПС для первичного анализа трудоемкости и дли¬
тельности (рис. 5.3). Он направлен, в основном, на последователь¬
ное, определение экономической рентабельности, целесообразности
продолжения конкретных проектов комплексов программ и на оцен¬
ку вероятных последующих затрат ресурсов. Тем самым должна
уменьшаться неопределенность ТЭП при начале и развитии проекта
Глава 5. Методики технико-экономического обоснования.
253
и снижаться риск неудачи при его реализации. Кроме того, оценива¬
ние ТЭП в ПЛАПС служит базой для планирования и мониторин¬
га последующих планов разработки сложных программных ком¬
плексов.
Данные прогнозов по мере развития проекта могут уточняться
и корректироваться с использованием реальных затрат ресурсов при
последовательном завершении определенных этапов проекта. При
этом возможен анализ технико-экономических показателей при из¬
менении характеристик и разных вариантах состава функций и раз¬
мера ПС, а также некоторых специфических факторов проекта,
влияющих на ТЭП. При реальной разработке, тестировании и кор¬
ректировке программ общая тенденция состоит в непрерывном уве¬
личении размера ПС, что при оценке ТЭП требует отслеживания
роста требуемых и используемых ресурсов. Кроме того, технико¬
экономические показатели, требующиеся ресурсы и планы разра¬
ботки должны корректироваться путем исключения из прогнози¬
руемых ТЭП затрат ресурсов, уже использованных на завершенных
этапах проекта. Эти обстоятельства ограничивают область исполь¬
зования аналитических моделей прогнозирования ТЭП, началь¬
ными этапами жизненного цикла ПС, пока не велики уже истрачен¬
ные ресурсы.
Принципиальным отличием методики ПЛАПС от модели СО¬
СОМО II является возможность планирования процесса разработки
комплекса программ, а также учета и корректировки реальных зна¬
чений трудоемкости и длительности. В методике реализована визуа¬
лизация планов разработки ПС в виде диаграмм Ганта по шести
укрупненным этапам и множеству (около 40) частных работ, состав¬
ляющих каждый из этих этапов. Состав и характеристики работ и
этапов можно корректировать по длительности и взаимодействию с
предшествующими и последующими работами. Для каждого этапа и
для частных работ отображаются значения трудоемкости и необхо¬
димое число специалистов, а также по вызову содержание работ и
отчетных документов, начиная от системного анализа и до заверше¬
ния испытаний версии программного продукта.
После или в процессе детального проектирования рекомендует¬
ся переходить к анализу и планированию фактических затрат на
разработку комплексов программ и управлять реализацией проектов
с учетом ограниченности доступных ресурсов и требуемого качества
254
Технико-экономическое обоснование проектов.
проекта ПС. Мониторинг и варьирование параметров проектов в
ПЛАПС может положительно влиять на сокращение общих затрач
ресурсов конкретных разработок и обеспечивать накопление значе¬
ний ТЭП реализованных проектов для использования их характери¬
стик в качестве прототипов. Применение ПЛАПС поддержано опи¬
санием применения и ниже иллюстрируется примерами содержа¬
ния экрана на фазах эксплуатации.
Пример экрана и части исходных данных для прогноза ТЭП
встроенного ПС размером 100 тысяч строк на ассемблере при кри¬
тических требованиях к надежности, умеренной унификации компо¬
нентов (40%), повышенных ограничениях на ресурсы (80%), а также
малых значениях некоторой части параметров представлен на рис.
Прогноз с расширенным числом факторов
5.5.
:«£»!£:■; шаг
Исходные денные
Клаоо программного средства
встроенное
Объем программного средства
I 108.в
Характеристики программного средсва
Н&ияенованне
Выбранные значения
Надежность
критическая
Раомер баои данник
Унификация
3меренная
Ограничение на ресурс*
повмоеннме
Длительность сопровождения
умеренная
Тираж
.Описание применения
Рис. 5.5
Гшва 5. Методики технико-экономического обоснования.
255
Пример экрана и исходных данных, отражающих квалифика¬
цию коллектива разработчиков и особенности организации процесса
проектирования, представлен на рис. 5.6.
Fl=HeU>
Лщушт. *йячв*йк-
Прогноз с расширенным числом факторов
Искодные мнныа :
Клаос ^огранмиого средства
Объем программного средства
встроенное
100 0
Характеристики программного с: ре дс ка
1Г
Усллекш* разрабтиксб
Тематическая квалификация
Кеалтр программистов еюсовая
Организация срщссса лрсеширсвамя
Внедрение соврем, методов
Стабильность исход.паннмх
Рис. 5.6
Пример результатов прогноза производительности труда, дли¬
тельности и трудоемкости разработки, а также необходимого числа
специалистов при предыдущих исходных данных отражает рис. 5.7.
Пример плана разработки ПС в виде диаграммы Ганта по шести
этапам (1- разработка концепции, 2 - предварительное и 3 - деталь¬
ное проектирование, 4 - программирование и отладка компонентов,
5 -комплексная отладка, 6 — испытания), с указанием для каждого
этапа: относительной трудоемкости /необходимого числа специали¬
стов - рис. 5.8.
256
Технико-экономическое обоснование проектов.
Г1,=не1‘р . Jfcfemp
Прогноз с расширенным числом факторов
Исиодзны* данные :
Класс программного средства встроенное
Овьем программного средства [
100.0 {
Коэффициент изменения трудоемкости
0.37
Производительность < отр/чел-мео)
89 |
Длительность разработки <мес>
26 |
Трудоемкость Счел-мео>
1000.8
Иако. чиоленнооть <чел>
59
Среда». чиоленнооть < чел >
38. А
ЧГу^М'.!,1 <' Ч1Ш8-Гап?Т»-". [MMMIMMnaaH
швнааШ!
Описание. прм^еменияЦни^игтум.^актрро^
!.*ЖЙ^ИИиЙЙМ!*1Йа лл«>шро**ни*. явбот 1 ■
Рис. 5.7
Начало равот 30/12/99 Распределение равот по времени
ЭТППЫ|{ 9Q 2080 2001
Ш
ш
и
ш
ш
ГГ]
Б.6 /15.3
6.6 /15.3
11 .6 /26 .8
20.0 /46.0
66 /38.А
Глава 5. Методики технико-экономического обоснования.
257
Пример плана программирования и отладки компонентов (8 ра¬
бот) с вариантом расшифровки содержания каждой работы (по вы¬
зову) - рис.5.9.
Начало раит 30/12/99
Распределение равот по времени
ЭТАПЫ
0
T.zj
0
77!
53
53
771
т
—I—I—I—I—I—I—I—I—I—I—*
июль авг сент окт иояб дек ян в ч>ев март апр май
|126.9/50.0
||ЯЦЫ
Содержание работ по этапам
4.1. Разработка исходами текстов программны!; модален.
Функциональны:; компонент и описаний данных в соот¬
ветствии со спецификациями требований, методиками
и стандартами.
4.2. Трансляция исходных текстов и устранение синтак¬
сических и семантических ошибок.
4.3. Планирование отладки модулей и компонент, подготов¬
ка тестовых данных и имтаторов для генерации тестов
126.9/50.8
№ММ№Ш(К:д
втШ
Рис. 5.9
258
Технико-экономическое обоснование проектов.
Приложение у
Перечень основных стандартов в области
технико-экономического обоснования проектов
сложных программных средств
1. ISO 12207:1995. (ГОСТ Р - 1999). ИТ. Процессы жизненного
цикла программных средств.
2. ISO 15271:1998. (ГОСТ Р - 2002). ИТ. Руководство по приме¬
нению ISO 12207.
3. ISO 16326:1999. (ГОСТ Р - 2002). ИТ. Руководство по приме¬
нению ISO 12207 при административном управлении проекта¬
ми.
4. ISO 15504:1-9:1998. ТО. Оценка и аттестация зрелости процес¬
сов жизненного цикла программных средств. 4.1. Основные по¬
нятия и вводное руководство. 4.2. Эталонная модель процессов
и их зрелости. 4.3. Проведение аттестации. 4.4. Руководство по
проведению аттестации. 4.5. Модель аттестации и руководство
по показателям. 4.6. Руководство по компетентности аттестато-
ров. 4.7. Руководство по применению при усовершенствовании
процессов. 4.8. Руководство по применению при определении
зрелости процессов поставщика. 4.9. Словарь.
5. ГОСТ Р 51904 - 2002. Программное обеспечение встроенных
систем. Общие требования к разработке и документированию.
6. ISO 9000:2000. (ГОСТ Р - 2001). Система менеджмента (адми¬
нистративного управления) качества. Основы и словарь.
7. ISO 9001:2000. (ГОСТ Р - 2001 ). Система менеджмента (адми¬
нистративного управления) качества. Требования.
8. ISO 9004:2000. (ГОСТ Р - 2001). Система менеджмента (адми¬
нистративного управления) качества. Руководство по улучше¬
нию деятельности.
9. ISO 10005: 1995 - Административное управление качеством
Руководящие указания по программам качества.
10. ISO 10006: 1997 - Руководство по качеству при управлении
проектом.
11. ISO 10007: 1995 - Административное управление качеством
Руководящие указания при управлении конфигурацией.
Приложение 1
259
12. ISO 10013: 1995 - Руководящие указания по разработке руко¬
водств по качеству.
13. ISO 12182:1998. (ГОСТ Р- 2002). ИТ. Классификация про¬
граммных средств.
14. ISO 9126:1991. (ГОСТ - 1993). ИТ. Оценка программного про¬
дукта. Характеристики качества и руководство по их примене¬
нию.
15. ISO 14598-1-6:1998-2000. Оценивание программного продукта.
4.1. Общий обзор. Ч. 2. Планирование и управление. Ч. 3. Про¬
цессы для разработчиков. 4.4. Процессы для покупателей. 4.5.
Процессы для оценщиков. 4. 6. Документирование и оценива¬
ние модулей.
16. ISO 9126-1-4. (проект). ИТ. Качество программных средств:
4.1. Модель качества. 4.2. Внешние метрики. 4. 3. Внутренние
метрики. 4. 4. Метрики качества в использовании.
17. ISO 14756: 1999. ИТ. Измерение и оценивание производитель¬
ности программных средств компьютерных вычислительных
систем.
18. ISO 12119:1994. (ГОСТ Р - 2000 г). ИТ. Требования к качеству
и тестирование.
19. ISO 13210:1994. ИТ. Методы тестирования для измерения со¬
ответствия стандартам POSIX.
20. ISO 9945-1:1990 (IEEE 1003.1). ИТ. Интерфейсы переносимых
операционных систем. 4.1. Интерфейсы систем прикладных
программ (язык Си).
21. ISO 9945-2:1992 (IEEE 1003.2). ИТ. Интерфейсы переносимых
операционных систем. Часть 2. Команды управления и сервис¬
ные программы.
22. ISO 15846:1998. ТО. Процессы жизненного цикла программных
средств. Конфигурационное управление программными сред¬
ствами.
23. ISO 14764: 1999. (ГОСТ Р - 2002). ИТ. Сопровождение про¬
граммных средств.
24. ISO 15408:1-3. 1999. (ГОСТ Р - 2002). Методы и средства обес¬
печения безопасности. Критерии оценки безопасности инфор¬
мационных технологий. 4.1. Введение и общая модель. 4. 2.
Защита функциональных требований. 4. 3. Защита требований к
качеству.
260
Технико-экономическое обоснование проектов.
25. ISO 13335 - 1-5. 1996-1998. ИТ. ТО. Руководство по управле¬
нию безопасностью. Ч. 1. Концепция и модели обеспечения
безопасности информационных технологий. 4.2. Планирование
и управление безопасностью информационных технологий. Ч.З.
Техника управления безопасностью ИТ. 4.4. Селекция (выбор)
средств обеспечения безопасности. 4.5. Безопасность внешних
связей.
26. ISO 10181: 1-7. ВОС. 1996-1998. Структура работ по безопас¬
ности в открытых системах. 4.1. Обзор. 4. 2. Структура работ
по аутентификации. 4.3. Структура работ по управлению дос¬
тупом. 4.4. Структура работ по безотказности. 4.5. Структура
работ по конфиденциальности. 4.6. Структура работ по обеспе¬
чению целостности. 4.7. Структура работ по проведению ауди¬
та на безопасность.
27. ISO 15910:1999. (ГОСТ Р - 2002) ИТ. Пользовательская доку¬
ментация программных средств.
28. ISO 6592:2000. ОИ. Руководство по документации для вычис¬
лительных систем.
29. ISO 9294:1990. (ГОСТ-1993 г). ТО. ИТ. Руководство по управ¬
лению документированием программного обеспечения.
30. ISO 14143: 1-5: 1998 - 2004. ИТ. Измерение программных
средств. Измерение функционального размера. 4.1. 1998. Опре¬
деление концепции. 4.2. 2002. Оценивание соответствия мето¬
дов измерения размера программных средств стандарту ISO
14143:1:1998. 4.3. 2003. Верификация методов измерения функ¬
ционального размера. 4.4.2002. Эталонная модель. 4.5. 2004.
Определение функциональных доменов для использования при
измерении функционального размера.
31. ГОСТ Р 51901 - 2002. Управление надежностью. Анализ риска
технических систем.
32. ГОСТ 34.602-89. ИТ. Техническое задание на создание автома¬
тизированных систем.
33. ГОСТ 34.201-89. ИТ. Виды, комплектность и обозначение до¬
кументов при создании автоматизированных систем.
34. РД 50-34.698-90. Методические указания. Информационная
технология. Автоматизированные системы. Требования к со¬
держанию документов.
Приложение 2
261
Приложение 2
Примеры прогнозирования технико-экономических показателей
разработки программных средств на основе моделей СОСОМО
Базовая модель СОСОМО (КОМОСТ) опубликована в начале
80-х годов [2] и отражала первоначальные оценки технико¬
экономических показателей разработки программ на основе имев¬
шейся статистики в те годы. В этой модели для предварительных
оценок рекомендовалось учитывать только два наиболее важных
параметра — класс и размер ПС, которые позволили выявить основ¬
ные тенденции изменения ТЭП. Поэтому в качестве исходного
ориентира полезно рассмотреть простейший пример оценок с ис¬
пользованием этой модели без учета влияния дополнительных фак¬
торов.
По формулам (3.1) и (3.3) с учетом коэффициентов из таблиц
3.1 и 3.2 рассчитаны значения трудоемкости и длительности разра¬
ботки ПС трех размеров и двух классов - реального времени (СРВ) и
административных систем (ИПС), результаты которых представле¬
ны в таблице П-1.
Трудоемкости разработки ПС этих классов различаются почти
вдвое при любых размерах, однако значения длительности разработ¬
ки при одинаковых размерах почти не отличаются. При увеличении
размеров обоих классов ПС в 10 раз (от 50 до 500 тыс. строк) трудо¬
емкость возрастает более чем в 15 раз, а длительность разработки
только в 2,5 раза. Производительность труда в этом диапазоне раз¬
меров уменьшается приблизительно в полтора раза и составляет в
среднем около 100 строк на человеко-месяц для СРВ и вдвое боль¬
ше для ИПС. В этом диапазоне изменения размеров ПС среднее
число специалистов, необходимых для создания комплексов про¬
грамм необходимо увеличивать почти в 6 раз. Таким образом, раз¬
мер проектов ПС пропорционально отражается на трудоемкости
разработки и необходимом числе специалистов и относительно сла¬
бо влияет на длительность и производительность труда при разра¬
ботке комплексов программ. Эти общие тенденции, как показано
ниже, в основном сохраняются при учете дополнительных факторов
и особенностей проектов ПС.
262
Технико-экономическое обоснование проектов.
Таблица Г1-]
Оценки технико-экономических показателей разработки
комплексов программ, рассчитанные по базовой модели
СОСОМО
Расчетные данные - классы
комплексов программ
(СРВ / ИПС)
Размер комплекса программ
(тысяч строк текста)
50
100
500
1. Полная трудоемкость
разработки комплекса
программ (человеко-месяцы).
393 / 239
904 / 521
6238 / 3162
2. Полная длительность
разработки комплекса
программ (месяцы).
17/17
22/22
41/42
3. Необходимое среднее число
специалистов (человек).
23/14
41/23
152/75
4. Средняя производительность
труда специалистов (строк
тсксга на человеко-месяц).
127 / 209
110/191
80 /158
Модель СОСОМО 11:2000 основана на статистических данных
конца 90-х годов, когда значительно усовершенствовалась техноло¬
гия и инструментарий разработки ПС [30] и повысилась точность
прогнозов ТЭП вследствие учета ряда дополнительных факторов.
При прогнозировании трудоемкости и длительности ниже использо¬
ваны основные выражения модели СОСОМО 11:2000 - (4.1) и (4.2) и
перечень факторов, представленных в таблице 4.1 (четыре масштаб¬
ных фактора, кроме управления рисками) и семь факторов из табли¬
цы 4.2. Для калибровки исходных данных примера модели при
оценке ТЭП приняты характеристики и дополнительные факторы
Приложение 2
263
предварительного проекта крупного комплекса программ реального
времени - таблица П-2.
Таблица П-2
Исходные данные калибровки предварительной модели СОСОМО II
для примера оценивания трудоемкости и длительности разработки
программных средств
Сим¬
вол
Содержание фактора
Значение
факгора
Коэффи
-циент
Исходная
таблица
F1
Новизна проекта
Во многом
новый
4,96
4.4
F2
Согласован ность с
требованиями
Допускаются
компромиссы
4,05
4.4
F4
Слаженность коллектива
Высокая
1,10
4.10
F5
Технологическая зрелость
4 уровень
СММ
1,56
4.13
IF
Масштабные факторы
11,67
М!
Сложность и надежность
Очень
высокая
1,74
4.3
М2
Требование повторного
использования компонентов
Высокая
1,07
4.3
М4
Квалификация коллектива
Высокая
0,83
4.3; 4.11;
4.12
М5
Опыт по тема гике и с
инструментарием
Высокий
0,87
4.3; 4.11;
4.12
Мб
Уровень инструментальной
поддержки
Очень
высокий
0,73
4.3;
4.14; 4.15
М7
(.Цраничеиие длительности
разработки
Отсутствует
1,00
4.3;
4.14; 4.15
М3
Ограничения аппаратной
платформы
Очень
высокие
1,29
4.3;
4.16; 4.17
ПМ
Произведение
коэффициентов факторов
1,27
Предполагается, что должен создаваться почти новый про¬
граммный продукт высокой сложности и надежности в соответствии
264
Технико-экономическое обоснование проектов.
требованиями заказчика, компоненты которых допускают повторное
использование в аналогичных проектах и их версиях. Разработка ПС
предстоит коллективом специалистов высокой квалификации и сла¬
женности, имеющим значительный опыт создания подобных проек¬
тов. Процесс разработки поддержан современным инструментарием
и сертифицированной технологией на уровне 4 СММ. Заказчик не
предъявляет специальных требований по ограничению сроков раз¬
работки. Однако для функционирования комплекса программ в ре¬
альном времени должны эффективно использоваться вычислитель¬
ные ресурсы реализующей ЭВМ по оперативной памяти и произво¬
дительности на уровне 90%.
Оценки ТЭП рассчитаны для средних размеров ПС 100 и 500
тыс. строк текста, а также для оптимистических и пессимистических
отклонений размера на 20% от среднего значения - таблица П-3.
Оценки трудоемкости при размере ПС более 100 тыс. строк, рассчи¬
танные по базовой модели (таблица П-1) и по модели СОСОМО II
отличаются почти в три раза. Это обусловлено учетом в этом приме¬
ре влияния ряда дополнительных факторов, а также обновлением
исходной статистики ТЭП современных проектов, позволивших
уточнить выражения (4.1) и (4.2).
Кроме того, уменьшение затрат труда в последние годы объек¬
тивно обусловлено усовершенствованием технологии и инструмен¬
тария при разработке аналогичных ПС.
Производительность труда для комплексов программ СРВ по¬
высилась приблизительно в два раза до величины свыше двухсот
строк на человеко-месяц, а длительность разработки крупных ПС
почти не изменилась (ср. для СРВ результаты в табл. П-1 с табл. П-
3). Это можно объяснить повышением требований к качеству ком¬
плексов программ и необходимостью соблюдения технологических
процессов и документирования. Ошибки определения размера ПС на
20% от среднего, почти не влияют на прогнозы длительности разра¬
ботки и производительности труда, но изменяют на 25% трудоем¬
кость разработки. Таким образом, при экспертных оценках трудоем¬
кости разработки современных ПС реального времени (см. п. 5.1)
при представленных в таблице П-2 значениях факторов можно поль¬
зоваться производительностью труда около 220 - 250 строк на чело¬
веко-месяц.
Приложение 2
265
Таблица П-3
Оценки технико-экономических показателей разработки
комплексов программ размером 100 тысяч и 500 тысяч строк,
рассчитанные по базовой модели СОСОМО II
Расчетные данные
Оптими¬
стические
Средние
Пессими¬
стические
1. Размер комплекса программ
(тысячи строк текста)
80 /400
100 / 500
125 /625
2. Полная трудоемкость
разработки комплекса
программ (человеко-месяцы).
336 /1756
423 / 2207
532 /2776
3. Полная длительность
разработки комплекса
программ (месяцы).
21/35
23/38
24/41
4. Необходимое среднее число
специалистов (человек).
16/50
18/58
22/69
5. Средняя производительность
труда специалистов (строк
текста на человеко-месяц).
238 / 227
236 / 226
234 / 225
Более подробный учет дополнительных факторов по результа¬
там детального проектирования, хотя и более трудоемко, особенно
при подготовке исходных данных, позволяет более четко предста¬
вить особенности и характеристики проекта комплекса программ.
После оценок ТЭП на предыдущих этапах, целесообразно сравни¬
вать их с реальными доступными ресурсами коллектива специали¬
стов и заданными сроками, и при необходимости производить пере¬
счеты с использованием откорректированных значений факторов.
266
Технико-экономическое обоснование проектов.
ЛИТЕРАТУРА
1. Андон Ф.И., Коваль Г.И., Коротун Т.М., Суслов В.Ю. Основы
инжене- рии качества программных систем. - К.: Академпе-
риодика. 2002.
2. Боэм Б.У. Инженерное проектирование программного обеспе¬
чения. Пер. с англ. /Под ред. А.А. Красилова. - М.: Радио и
связь, 1985.
3. Брукс Ф.П. Как проектируются и создаются программные ком¬
плексы. (Мифический человеко-месяц). Пер. с англ. - М.: Нау¬
ка. 1970.
4. Вендров А.М. Проектирование программного обеспечения эко¬
номических информационных систем. Учебник. - М.: Финансы
и статистика. 2002.
5. Глудкин О.П. и др. Всеобщее управление качеством: Учебник
^ для вузов. - М.: Радио и связь. 1999.
\ 6. Зиглер К. Методы проектирования программных систем. Пер.с
I англ. /Под ред. Я.А.Хетагурова. - М.: Мир. 1985.
7. Калянов Г.Н. Теория и практика реорганизации бизнес-
процессов. - М.: СИНТЕГ. 2000.
"ГГ Кантор М. Управление программными проектами. Практиче¬
ское руководство по разработке успешного программного обес¬
печения. Пер. с англ. - М.: Вильямс. 2002.
Когаловский М.Р. Энциклопедия технологий баз данных. - М.:
Финансы и статистика. 2002.
10. Крайер Э. Успешная сертификация на соответствие нормам
ИСО серии 9000. Пер. с нем. - М.: ИЗДАТ. 1999.
11. Леман М.М. Программы, жизненные циклы и законы эволюции
программного обеспечения //ТИИЭР. Техника программного
обеспечения: Пер. с англ. М.:Мир. 1980. - Т.68. - N 9. - С.26-45.
Литература
267
12. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями
к программному обеспечению. Унифицированный подход. Пер.
с англ. - М.: Вильямс. 2002.
Липаев В.В., Потапов А.И. Оценка затрат на разработку
траммных средств. — М.: Финансы и статистика. 1988.
14. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в
открытых информационных системах. - М.: РФФИ. 1997.
15. Липаев В.В. Документирование и управление конфигурацией
программных средств. Методы и стандарты. - М.: СИНТЕГ.
16. Липаев В.В. Выбор и оценивание характеристик качества п
граммных средств. - М.: СИНТЕГ. 2001.
17. Липаев В.В. Системное проектирование сложных программных
средств для информационных систем. Изд. второе переработан¬
ное и дополненное. - М.: СИНТЕГ. 2002.
18. Липаев В.В. Методы обеспечение качества крупномасштабных
программных средств. - М.: РФФИ. СИНТЕГ. 2003.
19. Липаев В.В. Функциональная безопасность программных
средств. - М.: СИНТЕГ. 2004.
20. Оценка и аттестация зрелости процессов создания и сопровож¬
дения программных средств и информационных систем
(ISO/IEC TR 15504-СММ). - М.: Книга и бизнес. 2001.
21. Поспелов Г.С., Ириков В.А. Программно - целевое проектиро¬
вание и управление (введение). - М.: Советское радио. 1976.
22. Прангишвили И.В. Системный подход и общесистемные зако¬
номерности. - М.: СИНТЕГ. 2000.
23. Тельнов Ю.Ф. Интеллектуальные информационные системы в
экономике. Учебное пособие. - М.: СИНТЕГ. 2002.
24. Трахтенгерц Э.А. Субъективность в компьютерной поддержке
управленческих решений.-М.: СИНТЕГ. 2001.
25. Трубачев А.П., Долинин М.Ю., Кобзарь М.Т. и др. Оцен1
безопасности информационных технологий. Общие критери
Под ред. В.А. Галатенко. - М.: СИП РИА, 2001.
26. Тэллес М., Хсих Ю. Наука отладки. - М.: Кудиц-образ. 2003.
27. Фатрелл Р. Т., Шафер Д. Ф., Шафер Л. И. Управление rip
граммными проектами: достижение оптимального качества nj
минимальных затратах. Пер. с англ. - М.: Вильямс. 2003.
1998.
268
Технико-экономическое обоснование проектов.
28. Холстед М.Х. Начала науки о программах: Пер. с англ. - М.:
Финансы и статистика. 1981.
29. Щербо В.К., Козлов В.А. Функциональные стандарты в откры¬
тых системах. Ч. 1. Концепция открытых систем. 4.2. Между¬
народные функциональные стандарты. - М.: Изд. МЦНТИ.
1997.
30. Boehm B.W. et al. Software cost estimation with СОСОМО II.
Prentice Hall PTR. New Jersey. 2000.
31. Beizer B. Software testing techniques. N.Y.: Van Nostrand Rein¬
hold. 1990.
32. Buckle J.K. Software configuration management. - London: Mac¬
millan Press. 1982.
33. Charett R. Software engineering risk analysis and management.
N.Y.: McGraw-Hill. 1989.
34. Davis A. Software requirements: Objects, functions and states. -
Englewood Cliffs. NY. Prentice-Hall. 1993.
35. Grady R. Practical software metrics for project management and
process improvement. - Englewood Cliffs. NY. Prentice-Hall. 1992.
36. Encyclopedia of Software Engineering. Vol.l A-N; Vol.2 O-Z. Edi¬
tor- In - Chief John J. Marciniak. John Wiley & Sons. Inc. 1995.
37. Jones C. Applied software measurement, assuring productivity and
quality. McGraw-Hill. NY. 1996.
38. Kit E. Software Testing in the Real World - Improving the Process.
Addison-Wesley. 1996.
39. Littlewood B. ed. Software Reliability - Achievement and Assess¬
ment. London. Blackwell Scientific Publications. 1987.
40. Londeix B. Cost estimation for software development. Cornwall:
Addison-Wesley. 1987.
41. Martin J., McClure C. Software maintenance, the problems and its
solutions. -N.Y.: Prentice-Hall. 1983.
42. Microsoft Solutions Framework. Пер. Решения Microsoft 99, Вы¬
пуск 7.
43. Musa J.D., Iannino A., Okumoto K. Software Reliability: Measure¬
ment, Prediction, Application.N.Y. McGraw Hill. 1987.
44. Ng P.A., Yeh R.T. ed. Modem software engineering. Foundations
and current perspectives. - N.Y.: Van Nostrand Reinhold. 1990.
45. Quarterman J.S., Wilhelm S. Unix, Posix and open systems: The
open standards puzzle. N.Y., Addison - Wesley. 1993.
Литература
269
46. Schindler M.J. Computer - aided software design. Build quality
software with CASE. - N.Y. John Wiley & Sons, 1990.
47. Shooman M.L. Software Engineering: Reliability, Development and
Management. N.Y. McGraw-Hill. 1983.
48. Sommerville I. Software engineering. Lancaster University. Addi¬
son-Wes-ley.2000.
49. Vincent J., Waters A., Sinclair J. Software quality assurance. Vol. II.
A programme guide. - Englewood Cliffs, New Yersey: Prentice-
Hall. 1988.
50. Yourdon E. Modem Stuctured Analysis. N.J.Yuordon Press/
Prentice-Hall. 1995.
270
Технико-экономическое обоснование проектов.
ОБ АВТОРЕ
Владимир Васильевич ЛИПАЕВ - профессор, главный научный со¬
трудник Института системного программирования РАН.
Окончил физический факультет МГУ в 1950 году. С 1954 по 1988 год
работал в Московском НИИ приборной автоматики, в последние годы -
Главным конструктором и председателем Координационного совета Мини¬
стерства радиопромышленности СССР по автоматизации проектирования
программного обеспечения, руководителем комплексного проекта "Проме¬
тей" по технологии создания крупномасштабных программных средств для
систем реального времени.
Основные научные интересы сосредоточены в области программной
инженерии, надежности функционирования программ, Открытых инфор¬
мационных систем и мобильности программных средств. Активно занима¬
ется проблемами обеспечения качества, тестирования, стандартизации и
сертификации сложных программных комплексов. Около 40 лет занима¬
ется исследованиями и разработкой программного обеспечения для систем
обработки радиолокационной информации и инструментальных средств
для создания управляющих программ реального времени. На базе теорети¬
ческих исследований и большого практического опыта реализации круп¬
ных программных проектов под его руководством разработаны шесть
больших инструментальных систем для автоматизации технологических
процессов жизненного цикла сложных комплексов программ, широко ис¬
пользовавшихся в оборонной промышленности и частично эксплуатируе¬
мых до настоящего времени.
С 1970-го года до настоящего времени опубликовал более 30 моно¬
графий и учебных пособий в области методов, технологий, инструменталь¬
ных средств и стандартизации разработки и обеспечения качества жизнен¬
ного цикла сложных комплексов программ. Автор около трехсот публика¬
ций в периодической печати. 30 лет читал курсы лекций по программной
инженерии в МИФИ, МИРЭА, МФТИ. Под его научным руководством
подготовлены и защищены более 20 кандидатских и 2 докторских диссер¬
тации.
В 1957 году защитил кандидатскую, а в 1965 году - докторскую дис¬
сертацию, с 1970 года - профессор. Заслуженный деятель науки и техники
РСФСР (1983 г.), лауреат премии Совета министров СССР (1985 г.), лауре¬
ат премии Правительства Российской Федерации в области образования
(2001 г.).
Научно-производственное издание
Липаев Владимир Васильевич.
Технико-экономическое обоснование проектов сложных
программных средств. - М.: СИНТЕГ, 2004. - 284 с.
(Серия «Управление качеством»).
Подписано в печать 15.07.2004 г. Формат 60x88/16.
Гарнитура Таймс. Печать офсетная. Бумага офсетная № 1.
П. л. 17,75. Доп. тираж 500. Заказ № 7429
ООО «НПО СИНТЕГ»
Адрес: 109542, Москва, ул. Вострухина, 6-5-77
Адрес для переписки: 109542, Москва, а/я 16.
Тел./факс: (095) 371-1316 http://www.sinteg.ru
E-mail: info@sinteg.ru sinteg@mail.ru
Отпечатано в ФГУП «Производственно-издательский комбинат ВИНИТИ».
140010, г. Люберцы, Московская обл., Октябрьский пр-кт, 403.
Тел. (095)554-21-86.
ISBN 5-89638-082-8
Липаев В.В. Системное проектирование сложных
программных средств для информационных
систем. Издание второе, переработанное и допол¬
ненное. Серия "Управление качеством". М.: СИНТЕГ,
2002. - 268 с.
ISBN 5-89638-060-7
Второе издание книги значительно переработано и до¬
полнено новыми материалами. Это обусловлено высокими
темпами развития за последние три года методов и стандар¬
тов создания программных средств (ПС) информационных
систем (ИС). В новом издании внимание акцентировано на
обеспечении высокого качества ПС, начиная с системного
анализа и проектирования. В то же время значительно со¬
кращены разделы, излагающие содержание международных
стандартов, которые стали доступны российским разработ¬
чикам, а некоторые утверждены как ГОСТы.
Изложены основы предварительного структурного проек¬
тирования и современных технологий системного анализа и
проектирования сложных комплексов программ. Значитель¬
ное внимание уделено методам разработки требований к ха¬
рактеристикам качества и распределению ресурсов, необхо¬
димых для реализации проектов ПС, планированию жизнен¬
ного цикла и управлению их качеством. Рассмотрены задачи
и принципы системного проектирования защиты функциони¬
рования комплексов программ, а также выбору инструмен¬
тальных средств для поддержки всего ЖЦ ПС. Представлены
фрагменты международных стандартов, регламентирующие
основные задачи и требования к системному проектирова¬
нию, к характеристикам и процессам обеспечения качества
ПС при их реализации. Изложены методики системного про¬
ектирования сложных ПС и требований к их качеству, а также
структура и содержание документов, отражающих результа¬
ты выполненных работ.
Для разработчиков, заказчиков и руководителей проектов
информационных систем, может использоваться как исход¬
ный материал при подготовке фирменных руководств по под¬
готовке контрактов на проекты ПС и как учебное пособие по
системному проектированию сложных программных средств.
Липаев В.В. Выбор и оценивание характери¬
стик качества программных средств. Методы
и стандарты. Серия "Информационные техноло¬
гии". - М.: СИНТЕГ, 2001. 228 с. ^
ISBN 5-89638-053-4
Рассмотрены основные понятия, факторы и методы анали¬
за характеристик качества сложных программных средств
(ПС). Систематически изложены сущность и содержание
стандартизированных характеристик, субхарактеристик и ат¬
рибутов качества ПС. Отражены свойства внутренних и
внешних метрик качества, а также метрик качества программ
в использовании. Показана их зависимость от ряда внешних
и внутренних факторов, а также от ограниченности ресурсов
при создании и применении ПС по прямому назначению.
Приводятся примеры мер и шкал для выбора и оценивания
значений атрибутов качества сложных комплексов программ.
Уделено внимание трудоемкости и длительности процессов,
необходимых для достижения требуемых значений характе¬
ристик качества, а также их влиянию на экономику функцио¬
нальной пригодности ПС. Представленные методы стандар¬
тизированного оценивания и измерения различных характе¬
ристик качества рекомендуется использовать при подготовке
методик испытаний и сертификации качества конкретных про¬
граммных продуктов.
Книга предназначена для специалистов, обеспечивающих
этапы жизненного цикла сложных программных средств и
применяющих их характеристики качества. Она может слу¬
жить базой для сравнения качества ПС разных поставщиков
и выявления среди них предпочтительных, а также при под¬
готовке и внедрении систем качества фирм для их сертифи¬
кации на соответствие международным стандартам. Книга
может использоваться в качестве учебного пособия при обу¬
чении студентов созданию сложных программных средств
высокого качества.
Липаев В.В. Функциональная безопасность про¬
граммных средств. - М.: СИНТЕГ, 2004. - 348 с.
(Серия «Управление качеством»),
ISBN 5-89638-070-4
Рассматриваются исходные данные, основные понятия и
факторы, характеристики объектов и среды, для которых долж¬
на обеспечиваться функциональная безопасность программных
средств (ПС) и систем. Анализируются ресурсы необходимые
для функциональной безо-пасности, а также причины и стати¬
стические характеристики проявления дефектов и ошибок в
комплексах программ. Изложена организация и планирование
разработки требований к функциональной безопасности и каче¬
ству ПС. Значительное внимание уделено технологическим
процессам, разработке и документированию ПС, встроенных в
системы, а также содержанию стандартов, регламентирующих
обеспечение их функциональной безопасности в полном жиз¬
ненном цикле. Представлены рекомендации по верификации
требований к функциональной безопасности ПС, по тестирова¬
нию модулей и программных компонентов, а также по квалифи¬
кационному тестированию безопасных комплексов программ.
Рекомендуются методы повышения функциональной безопас¬
ности путем оперативного контроля и восстановления (рестар¬
та) компонентов ПС и систем, а также методы совершенствова¬
ния и конфигурационного управления их функциональной безо¬
пасностью. Особое внимание уделено испытаниям, оцениванию
и удостоверению функциональной безопасности сложных ПС
при сертификации.
Книга предназначена для специалистов, обеспечивающих
жизненный цикл сложных программных средств и систем, к ко¬
торым предъявляются высокие требования к безопасности и
надежности функционирования. Она может быть полезна ис¬
полнителям научных проектов и опытно-конструкторских работ,
студентам и аспирантам, связанным с созданием сложных
безопасных систем и программных средств высокого качества.
Липаев В.В. Методы обеспечения качества круп¬
номасштабных программных средств. М.: СИНТЕГ,
2003. - 520 с., ил. (Серия "Управление качеством").
ISBN 5-89638-068-2
Монография состоит из двух частей. В первой части рассмот¬
рены основные понятия, факторы и методы представления каче¬
ства в жизненном цикле (ЖЦ) крупномасштабных программных
средств (ПС). Описаны основы базовых стандартов администра¬
тивного управления качеством продукции, процессов жизненного
цикла и характеристик качества ПС. Выделены основные фак¬
торы, определяющие свойства и атрибуты качества функцио¬
нальных возможностей, защиты, конструктивных характеристик и
качества баз данных. Исследована зависимость качества про¬
грамм от ряда внешних и внутренних факторов, а также от огра¬
ниченности ресурсов при создании и применении ПС по прямому
назначению. Представлены методы оценки затрат ресурсов на
обеспечение функциональной пригодности, на конструктивные
характеристики качества для обеспечения ЖЦ ПС.
Во второй части значительное внимание уделено разработке
требований к характеристикам качества ПС, а также методам
проектирования комплексов программ высокого качества. Изло¬
жены принципы и методы верификации, технологические этапы
и стратегии тестирования ПС. Рассмотрены методы стандарти¬
зированного оценивания характеристик качества, которые реко¬
мендуется использовать при подготовке методик испытаний.
Представлены методы квалификационного тестирования и ис¬
пытаний крупномасштабных ПС, оценивания надежности ис¬
пользования ресурсов ЭВМ. Изложены методы совершенствова¬
ния качества при сопровождении программ и конфигурационном
управлении версиями ПС, а также удостоверения достигнутого
качества при сертификации программных продуктов.
Монография предназначена для специалистов, обеспечи¬
вающих все этапы жизненного цикла крупномасштабных про¬
граммных средств, создающих и применяющих системы и харак¬
теристики качества в этой области. Она может быть полезна ис¬
полнителям научных проектов и опытно-конструкторских работ
для обеспечения высокого качества сложных программных
средств. Ее рекомендуется использовать при обучении студен¬
тов и аспирантов созданию сложных комплексов программ.
Липаев В.В. Обеспечение качества программных
средств. Методы и стандарты. Серия "Информаци¬
онные технологии". - М.: СИНТЕГ, 2001. - 380 с.
ISBN 5-89638-044-5
Рассмотрены основные понятия, факторы и методы
обеспечения качества в жизненном цикле (ЖЦ) слож¬
ных программных средств (ПС). Систематически изло¬
жены основы стандартизации в области качества ПС,
содержание и фрагменты комплекса международных
стандартов, регламентирующих качество их жизненно¬
го цикла. Значительное внимание уделено планирова¬
нию и управлению качеством ПС, а также подготовке
систем качества предприятий, обеспечивающих их ЖЦ.
Представлены принципы и методы верификации, тес¬
тирования и испытаний сложных комплексов программ,
определяющие достигаемое качество ПС, совершенст¬
вование качества в процессе сопровождения и конфи¬
гурационного управления проектами. Отдельный раз¬
дел посвящен организации сертификации предприятий,
разрабатывающих программные средства и удостове¬
рению достигнутого качества ПС.
Книга предназначена для специалистов, обеспечи¬
вающих все этапы жизненного цикла сложных про¬
граммных средств, создающих и применяющих систе¬
мы качества предприятий в этой области. Она может
служить базой при подготовке и внедрении систем ка¬
чества фирм для их сертификации и при проведении
экспертизы на соответствие международным стандар¬
там, а также может использоваться в качестве учебного
пособия при обучении студентов созданию сложных
программных средств высокого качества.
Липаев В.В. Надежность программных
средств. Серия «Информатизация России
на пороге XXI века». М. СИНТЕГ.1998, 232 с.
ISBN 5-89638-008-9
Рассматриваются основные показатели и фак¬
торы, определяющие надежность функциониро¬
вания и безопасность применения сложных про¬
граммных средств (ПС). Приведены характери¬
стики типичных дефектов и ошибок в программах.
Изложены методы и средства тестирования и
обеспечения высокого качества модулей и про¬
граммных компонент. Представлены рекоменда¬
ции по предупреждению дефектов и обеспечению
надежности в жизненном цикле ПС, по проведе¬
нию их тестирования и сертификации. Рассмот¬
рены способы повышения надежности сложных
программных комплексов за счет введения вре¬
менной, программной и информационной избы¬
точности. Значительное внимание уделено экс¬
периментальным методам определения реальной
надежности функционирования ПС, генерации
тестов, обработке результатов тестирования и
структуре стендов для проведения испытаний на¬
дежности программ.
Предназначено для специалистов, связанных
с разработкой, эксплуатацией и сопровождением
сложных программных средств и информацион¬
ных систем.
Липаев В.В. Фрагменты истории развития отече¬
ственного программирования для специализи¬
рованных ЭВМ в 50-80-е годы. - М.: СИНТЕГ, 2003.
-132 с. (Серия "Управление качеством").
ISBN 5-89638-064-Х
Рассмотрены основные особенности развития в
стране специализированных вычислительных машин в
50-80-е годы и функциональных задач для ЭВМ в ре¬
альном времени. Изложена концепция ПРОМЕТЕЙ-
технологии для обеспечения жизненного цикла ком¬
плексов программ.
Приводятся основные результаты научных исследо¬
ваний по программе ПРОМЕТЕЙ-технологии в направ¬
лениях: технико-экономических показателей разработки
программных средств; характеристик ошибок в ком¬
плексах программ; методов распределения вычисли¬
тельных ресурсов и дисциплин диспетчеризации в объ¬
ектных ЭВМ реального времени; построения кросс¬
систем автоматизации программирования для объект¬
ных ЭВМ; тестирования структуры программных моду¬
лей. Изложены особенности конструкции основных ин¬
струментальных компонентов ПРОМЕТЕЙ-технологии:
языков программирования и трансляторов кросс¬
систем; системы отладки программных компонентов
вне реального времени, а также средств для динамиче¬
ской отладки и испытаний программ объектных ЭВМ в
реальном времени. Представлены основные результа¬
ты освоения и применения ПРОМЕТЕЙ-технологии для
разработки комплексов программ реального времени в
оборонной промышленности.
Книга предназначена для специалистов по вычисли¬
тельной технике и программированию, студентов и ас¬
пирантов, интересующихся историей развития отечест¬
венной науки и техники в этой области.
Книги издательства СИНТЕГ
по системной интеграции
(СИНТЕГ - аббревиатура слов "Системный ИНТЕГратор")
Сдвинуты влево и дополнены знаком коды, где тираж
закончился или от тиража остались отдельные экз. книг
Код
Автор.
Наименование книги
Формат.Объем, с.«Тираж»
Год-квартал выпуска*
Кол. книг в пачке» ISBN*
Обложка: М-мягк./Т-тверд.
1. Системы и проблемы управления
03*
Управление большими системами. Мате¬
риалы Международной научно-практической
конференции. Общая редакция - Бурков
B.H., Новиков Д.А.
А5.432.1000.1997-4.10.
ISBN 5-89638-001-1.М
18.
Прангишвили И.В., Абрамова Н.А., Спири¬
донов В.Ф., Коврига С.В., Разбегин В.П.
Поиск подходов к решению проблем.
А5.284.1000.1999-2.16.
ISBN 5-89638-018-6.М
25.
26*
Международная конференция по проблемам
управления (29 июня - 2 июля 1999 года).
ИПУ РАН - 60 лет. Избранные труды. В двух
томах.
Т1 :А5.316.600.1999-4.12.
ISBN 5-89638-025-9.М
Т2:А5.312.600.1999-4.16.
ISBN 5-89638-026-7.М
39
Прангишвили И.В. Системный подход и об¬
щесистемные закономерности.
А5.528.1500.2000-4.8.
ISBN 5-89638-042-9.Т
44
Фридман Л.М. Основы проблемологии.
А5.228.1000.2001 -2.24.
ISBN 5-89638-043-7.М
49
Косяков Ю.Б. Мой мозг: строение, принципы
работы, моделирование.
А5.164.1500.2001-3.30.
ISBN 5-89638-049-6.M
73
Прангишвили И.В., Бурков В.Н., Горгидзе
И.А., Джавахадзе Г.С., Хуродзе Р.А. Сис¬
темные закономерности и системная оптими¬
зация.
A5.208.500.2004-1.16.
ISBN 5-89638-072-0.T
79
Райков А.Н. Лепесток опоры, или филосо¬
фия решений.
A5.56.1000.2004-2.60»
ISBN 5-89638-079-8.M
2. Компьютерная поддержка принятия решений
05»
Трахтенгерц. Э.А. Компьютерная поддержка
принятия решений.
A5.376.3000.1998-1.16»
ISBN 5-89638-003-8.M
42
Трахтенгерц Э.А. Субъективность в компью¬
терной поддержке управленческих решений
A5.256.1500.2001-2.16.
ISBN 5-89638-041-0.M
62
Трахтенгерц Э.А. Компьютерная поддержка
переговоров при согласовании управленче¬
ских решений.
A5.284.1500.2003-1.18.
ISBN 5-89638-062-3.M
72
Трахтенгерц Э.А., Шершаков В.М., Камаев
Д.А. Компьютерная поддержка управления
ликвидацией последствий радиационного
воздействия.
A5.464.1000.2004-1.8.
ISBN 5-89638-071-2.T
3. Управление организационными системами
•
СМ
СМ
Теория активных систем. Труды Юбилейной
международной научно-практической конфе¬
ренции. Общая редакция -Бурков B.H., Но¬
виков Д.А.
А5»320»600.1999-3.16.
ISBN 5-89638-021-6.М
23.
Бурков В.Н., Новиков Д.А. Теория активных
систем. Состояние и перспективы. Учебное
пособие.
А5.128.1000.1999-3.20.
ISBN 5-89638-022-4.М
24.
Новиков Д.А., Петраков С.Н. Курс теории
активных систем. Учебное пособие.
А5.108.1200.1999-4.40.
ISBN 5-89638-023-2.М
55
Бурков В.Н., Заложнев А.Ю., Новиков Д.А.
Теория графов в управлении организацион¬
ными системами. Учебное пособие.
А5»124.1500.2001 -4.24.
ISBN 5-89638-055-0.T
56
Юдицкий С.А. Сценарный подход к модели¬
рованию поведения бизнес-систем
A5.112.1500.2001 -4.40.
ISBN 5-89638-054-2.M
58
Губко М.В., Новиков Д.А. Теория игр в
управлении организационными системами.
Учебное пособие.
A5.148.1000.2002-2.20.
ISBN 5-89638-057-7.T
64
Новиков Д.А., Чхартишвили А.Г. Рефлек¬
сивные игры.
A5.160.1000.2003-1 «20.
ISBN 5-89638-063-1.T
66
Новиков Д.А. Стимулирование в организа¬
ционных системах.
A5.312.500.2003-2.16.
ISBN 5-89638-065-8.T
70
Бурков В.Н., Новиков Д.А. Как управлять
организациями.
A5.400.500.2004-1.10.
ISBN 5-89638-069-0.T
4. Управление проектами
01.
Бурков В.Н., В.Н. Новиков В.Н. Как управ¬
лять проектами.
А5» 188.3000*1997-3.20»
ISBN 5-86639-029-9.M
11
Симионова Н.Е. Управление реформирова¬
нием строительной организации.
A5.224.1000.1998-4.20.
ISBN 5-89638-012-7.M
48
Смирнов B.C., Власов С.А., Ваулинский
Е.С., Лебедев Б.И. Методы и модели управ¬
ления проектами в металлургии.
A5.176.1500*2001-2.20.
ISBN 5-89638-048-8.T
5. Управление качеством программных средств
07.
Липаев В.В. Документирование и управле¬
ние конфигурацией программных средств.
Методы и стандарты.
A5»212.3000» 1998-2*20.
ISBN 5-89638-004-6.M
08
Липаев В.В. Надежность программных
средств.
A5.232.3000.1998-3*20*
ISBN 5-89638-008-9.M
21.
Липаев В.В. Системное проектирование
сложных программных средств для инфор¬
мационных систем.
A5.224.1400.1999-3.20»
ISBN 5-89638-019-4.M
•/4‘
Липаев В.В. Обеспечение качества про¬
граммных средств. Методы и стандарты.
A5«380»1000.2001-2« 12»
ISBN 5-89638-044-5.M
54
Липаев В.В. Выбор и оценивание характери¬
стик качества программных средств. Методы
и стандарты.
А5.228» 1500*2001-4.20»
ISBN 5-89638-053-4.M
61
Липаев В.В. Системное проектирование
сложных программных средств для инфор¬
мационных систем Издание второе, пере-
A5.268.1500.2002-3.20.
ISBN 5-89638-060-7.M
работанное и дополненное.
65
Липаев В.В. Фрагменты истории развития
отечественного программирования для спе¬
циализированных ЭВМ в 50 - 80-е годы.
А5»132.500.2003-2.30.
ISBN 5-89638-064-Х.М
68
Липаев В.В. Методы обеспечения качества
крупномасштабных программных средств.
А5.520»650»2003-3»8.
ISBN 5-89638-068-2.Т
71
Липаев В.В. Функциональная безопасность
программных средств.
А5«348*500«2004-1 • 12»
ISBN 5-89638-070-4»Т
83
У
Липаев В.В. Технико-экономическое обосно¬
вание проектов сложных программных
средств.
А5«284»500»2004-3. 14.
ISBN 5-89638-082-8«Т
6. Информационные технологии и проектирование
информационных систем
04*
Калянов Г.Н. Консалтинг при автоматизации
предприятий. Подходы, методы, средства.
А5»316*3000. 1997-4» 14»
ISBN 5-89638-002-Х.М
19
Кульба В.В., Ковалевский С.С., Косяченко
С.А., Сиротюк В.О. Теоретические основы
проектирования оптимальных структур рас¬
пределенных баз данных.
А5»660« 1200*1999-3.6*
ISBN 5-89638-016-Х.Т
33
Безкоровайный М.М., Костогрызов А.И.,
Львов В.М. Инструментально-моделирую-
щий комплекс для оценки качества функцио¬
нирования информационных систем "КОК".
Руководство системного аналитика. Прила¬
гается демо-версия на дискете.
А5* 120» 1000.2000-2.40*
ISBN 5-89638-032-1.М
37
Гайфуллин Б.Н., Антипина Г.С. Современ¬
ные информационные технологии. Обучение
и консалтинг.
А5.176.1500.2000-3.20.
ISBN 5-89638-039-9.М
40*
Калянов Г.Н. Теория и практика реорганиза¬
ции бизнес-процессов.
А5.212.1500.2001-1.20.
ISBN 5-89638-040-2.М
69
Кульба В.В., Ковалевский С.С., Шелков
А.Б. Достоверность и сохранность информа¬
ции в АСУ.
А5.500.500.2003-3.8.
ISBN 5-89638-067-4.Т
78
Кульба В.В., Кононов Д.А., Косяченко С.А.,
Шубин А.Н. Методы формирования сцена¬
риев развития социально-экономических
систем.
А5.296.500.2004-2.14.
ISBN 5-89638-078-X.T
7. Информационная безопасность и информационные войны
13»
Цыганков В.Д., Лопатин В.Н. Психотронное
оружие и безопасность России.
A5.152.2000.1999-1 «30.
ISBN 5-89638-006-2.M
16»
Гриняев С.Н. Интеллектуальное противодей¬
ствие информационному оружию.
A5.232.1000.1999-2.20»
ISBN 5-89638-015-1»M
17.
Прокофьев В.Ф. Тайное оружие информа¬
ционной войны.
A5.152.1000.1999-2*30.
ISBN 5-89638-017-8.M
32
Почепцов Г.Г. Информационно¬
психологическая война.
A5.180.1500.2000-2.30*
ISBN 5-89638-028-3.M
38
Устинов Г.Н. Основы информационной безо¬
пасности систем и сетей передачи данных.
Учебное пособие.
A5.248.1500.2000-3*20.
ISBN 5-89638-035-6.M
43
Приходько А.Я. Информационная безопас¬
ность в событиях и фактах.
А5»260«1500*2001 -2*16*
ISBN 5-89638-036-4.М
50
Приходько А.Я. Словарь-справочник по ин¬
формационной безопасности.
А5« 124.1500.2001 -3.40»
ISBN 5-89638-050-X.M
51
Бурков В.Н., Грацианский Е.В., Дзюбко
С.И., Щепкин А.В. Модели и механизмы
управления безопасностью.
А5.160.1500.2001 -3.30.
ISBN 5-89638-045-3.M
63
Прокофьев В.Ф. Тайное оружие информа¬
ционной войны: атака на подсознание. Изда¬
ние второе, расширенное и доработанное.
А5.408.1500*2003-1.12»
ISBN 5-89638-059-3.T
67
Цыганков В.Д. Психотроника и безопасность
России. Издание второе, скорректированное.
А5.136.1000.2003-2.30.
ISBN 5-89638-066-6.М
8. Экономика и бизнес
5»
Тельнов Ю.Ф. Интеллектуальные информа¬
ционные системы в экономике. Учебное по¬
собие. Издание второе.
А5.216*1000*1999-2.20.
ISBN 5-89638-010-0.M
34
Толковый словарь предпринимателя. Соста¬
витель и редактор - Рыкунов В.И.
A6.216.1500.2000-2.40.
ISBN 5-89638-033-X.M
59
Тельнов Ю.Ф. Интеллектуальные информа¬
ционные системы в экономике. Учебное по¬
собие. Издание третье, расширенное и
доработанное.
A6.316.1500.2002-4.16*
ISBN 5-89638-061-5.M
60
Брамс Стивен Дж., Тейлор Алан Д. Делим
по справедливости, или Гарантия выигрыша
каждому. Перевод с англ. - Яновская Ю.М.,
научн. ред. - Алескеров Ф.Т.
A6.196.2000.2002-4.20.
ISBN 5-89638-058-5.M
9. Промышленная автоматика
77
Захаров Н.А. Средства промышленной авто¬
матики GE Fanuc и системы на их основе.
А5»108.500.2004-1.40»
ISBN 5-89638-076-3.M
10. Наука и творчество
06
Гаврилов Д.А. и др. Старые и новые стол¬
бовые шахматные игры.
А5.98» 1000» 1998-2.60*
ISBN 5-89638-005-4.M
12
Абовский Н.П. Творчество: системный под¬
ход, законы развития, принятие решений.
A5.296.1500.1998-4.16»
ISBN 5-89638-009-7.M
27
Варшамов P.P. Введение в новую нетради¬
ционную математику.
A5.116.1100.1999-4.20.
ISBN 5-89638-024-0.T
31
Соснин Э.А., Пойзнер Б.Н. Путь в науку XXI
века. Руководство к действию. Учебное по¬
собие.
A5.88.1500.2000-2.50.
ISBN 5-89638-031-3.M
11. Информация и социум
09
Бодякин В.И. Куда идешь, человек? Основы
эволюциологии. Информационный подход.
A5.332.3000.1998-4.16.
ISBN 5-89638-011-9.M
45
Фомин Ю.А. Человечество в XXI веке.
A5.80.1500.2001-2.60.
ISBN 5-89638-047-X.M
47
Затуливетер Ю.С. Информационная приро¬
да социальных перемен.
A5.132.1500.2001-2.30.
ISBN 5-89638-046-1*M
53
Лесков Л.В. Знание и власть. Синергетиче-
A5.100.1500.2001 -4.50.
I I "ска я кратология. | ISBN 5-89638-052-6«М Д
12. Человек, Земля, Вселенная
02*
Пресман А.С. организация биосферы и ее
космические связи (кибернетические основы
планетно-космической организации жизни).
А5.240.1000*1997-3*20.
ISBN 5-86639-031-0«М
10
Куликов В.В. Узник бессмертия. Научно¬
фантастический роман.
А5.148.1000* 1998-4*36.
ISBN 5-89638-013-5.М
14.
Чуев А.С. Физическая картина мира в раз¬
мерности «длина-время».
А5.96.500* 1999-2*60.
ISBN 5-89638-014-З.М
28
Цыганков В.Д. Вселенная Хокинга и нейро¬
компьютер.
А5.84.1500*2000-1.50.
ISBN 5-89638-027-5.М
35*
Мартынов А.В. Философия жизни. Испове-
димый путь к богочеловеку.
А5»400«3000»2000-3»12»
ISBN 5-89638-037-2.М
36
Рогульченко М.Г. От «Розы мира» Даниила
Андреева - к концепции «Разум».
А5.72.1000*2000-3.60*
ISBN 5-89638-038-0.M
41
Цыганков В.Д. Нейрокомпьютер и мозг.
A5.248.1500.2001-1.20»
ISBN 5-89638-034-8.M
57
Цыганков В.Д. Вселенский разум и кванто¬
вый нейрокомпьютер.
A5»176.1000.2002-1.30.
ISBN 5-89638-056-9.M
Приглашаем к сотрудничеству авторов, библиотеки
и книготорговые организации
Связь с издательством СИНТЕГ:
Адрес для переписки:
109542, Москва, а/я 16, Гуревич Владимир Львович
Тел.:(095)371-1316 Сайт: www.sinteg.ru
e-mail: sinteq@mail.ru info@sinteq.ru