Теги: программирование
Текст
Б.ЖБОЭМ
ИНЖЕНЕРНОЕ
ПРОЕКТИРОВАНИЕ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Перевод с английского
под редакцией проф. А. А. Красилова
МОСКВА
РАДИО И СВЯЗЬ*
1985
Боэм Б. У.
Б 72 Инженерное проектирование программного обеспече-
ния: Пер. с англ. — М.: Радио и связь. 1985 —512 с.,
ил.
В пер.: 2 р. 80 к. 10 000 экз
В книге известного американского специалиста обобщен многолетний опыт
оценки и анализа затрат на создание и эксплуатацию сложных комплексов
программ. Предложен подход к проблеме оценивания труда коллективов про-
граммистов, поставлена реальная задача построения систем управления раз-
работками программ. Рассмотрены стоимостные модели проектирования про-
грамм и распределение затрат на работы по фазам их жизненного цикла.
Проведено сравнение различных методов оценивания стоимости конкретного
программного обеспечения.
Для инженерно-технических работников, занимающихся проектированием и
эксплуатацией программного обеспечения.
2405000000—151
Б --------------127—85
046(01)—85
ББК 32.973
6Ф7
I 1981 by Prentice-Hall, Inc., Englewood Clifts, N J 07632
(С' Перевод на русский язык, предисловие редактора перевода, при-
мечанш. редактора, переводчиков, дополнительный список литера-
туры Издательство «Радио и связь», 1985
ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА
Книга Б. У. Боэма посвящена новому направлению вычисли-
тельной науки. В связи с быстрым внедрением в промышленность,
научный эксперимент, сельское хозяйство, сферу обслуживания,
торговлю и другие отрасли деятельности человека средств авто-
матизации с применением ЭВМ резко возрос спрос на програм-,
мы. Ежегодный прирост спроса на программы составляет в по-
следние годы 20 ... 26%. Если проектирование и разработка
технических средств, в частности ЭВМ и их элементов, достигли
уровня, при котором возможно конвейерное производство этих
средств, то разработка программ по многим признакам все еще
относится к области инженерного искусства. В связи с этим
спрос на программы не удовлетворяется в достаточной мере.
Основная ценность предлагаемой читателю книги заключается
в раскрытии понятия инженерное проектирование в применении к
Программному обеспечению (ПО). Его можно трактовать следую-
щим образом. Поскольку программа любого типа становится изде
лием (кроме, может быть, учебных, макетных программ), подход
к ее изготовлению во многом должен быть аналогичен подходу
к производству промышленной продукции, и вопросы проектирова-
ния программ становятся чрезвычайно важными. Программное
изделие (вначале как проект) должно определяться замыслом,
суммой документов (требования к программе, планы разработки и
сопровождения, предварительное описание программ), прототипом
или эскизом. Проектирование ПО следует понимать как процесс
создания проекта программного изделия.
Инженерное программирование определяется как отрасль вы-
числительной науки, основанная на применении прикладной мате-
матики и других конкретных наук для эффективного использова-
ния средств вычислительной техники в решении народнохозяйст-
венных, научных и учебных задач с помощью программ, ПО, орга-
низационных мероприятий и документации.
Процесс инженерного проектирования ПО подразделяется на
этапы: планирование, проектирование, разработка, опытное внед-
рение, эксплуатация и сопровождение. Эти этапы определяют жиз-
ненный цикл ПО. Каждый этап расчленяется на фазы, характери-
3} ющиеся однородной деятельностью (планирование и выработка
требований, проектирование изделия, кодирование, комплексиро-
ание и испытания изделия). На каждой фазе выполняются конк-
Ретные работы, с которыми связаны конкретные функции исполни-
ТВЛ«И на „протяжении всего жизненного цикла ПО (анализ
реоований, детальное проектирование изделия, программирова-
5
ние, планирование отладки, верификация и подтверждение, управ-
ление проектом, управление конфигурацией и качеством изделия,
документирование). Под кодированием понимают работу по напи-
санию текстов программ и записи данных, а под опытным внедре-
нием — поставку и ввод ПО в ЭВМ, пробную проверку его функ-
ционирования и обучение пользователей. Опытное внедрение от-
личается от более широкого понятия внедрения, которое включает
в себя также распространение образцов, подсчет экономического
эффекта, тиражирование, доставку и др.
Промышленное применение ЭВМ и растущий спрос на про-
граммы поставили актуальные задачи существенного повышения
производительности разработки ПО, разработки индустриальных
методов планирования и проектирования программ, переноса ор-
ганизационно-технических, технико-экономических и социально-
психологических приемов, закономерностей и методов из сферы
материального производства в сферу применения ЭВМ. Вопросы
эффективного использования ЭВМ, экономного распределения
людских ресурсов, разработки новых технологических методов,
внедрения безбумажной технологии всегда, а сейчас в особенно-
сти, находились и находятся в центре внимания программистов и
их руководителей. Современное программирование в СССР харак-
теризуется широким внедрением языков записи программ и дан-
ных, пакетов прикладных программ, систем автоматизированного
или автоматического программирования, новых технологий разра-
боток. Комплексный подход к процессам разработки, эксплуата-
ции и сопровождения ПО выдвинул ряд насущных проблем, реше-
ние которых исключит «узкие места» в проектировании программ,
уменьшит сроки завершения работ, улучшит выбор и адаптацию
существующих программ, а иногда и определит судьбу системы со
встроенными ЭВМ. Среди существенных следует отметить также
проблемы оценивания затрат труда и сроков проведения работ и
управление производством ПО. В связи с этим руководители кол-
лективов программистов вынуждены учитывать большое число
разнообразных факторов. Без такого комплексного подхода к раз-
работкам программ невозможно получить промышленный продукт,
пригодный к тиражированию, внедрению с минимальными затра-
тами, эффективной эксплуатации и сопровождению.
В практике разработок больших программных проектов зача-
стую отсутствует единый подход к оцениванию затрат труда, сро-
ков проведения работ и материальных затрат, что сдерживает по-
вышение производительности разработки ПО, а в конечном сче-
те — и эффективное управление жизненным циклом ПО. В книге
Боэма предложен систематический подход к решению этих проб-
лем. В доступной массовому читателю форме, с конкретными про-
цедурами расчета и иллюстрациями в ней рассмотрены иерархия
конструктивных моделей стоимости (КОМОСТ) ПО, обоснование
моделей оценивания, методы повышения производительности раз-
работки и управления жизненным циклом ПО. Изложение в книге
базируется на элементах теории информации, системного анализа,
6
большом статистическом материале конкретных разработок про-
грамм. Упомянутые выше проблемы еще далеко не разрешены.
Этот факт подчеркивает автор книги, указывая некоторые темы
дальнейших исследований.
Важно отметить некоторые используемые в книге основные
средства для определения области применения моделей оценива-
ния стоимости ПО. В ней рассматриваются три типа программного
изделия. Самым распространенным типом разработки является
создание программ, пакетов и программных комплексов (в пакет-
ном или диалоговом режимах), ориентированных на решение раз-
нообразных задач науки и производства. Наиболее сложный тип —
это разработка программ, встроенных в технические системы ЭВМ
(программы встроенного типа), потому что размер, требуемая на-
дежность, сложность обработки поступающих по каналам данных,
обычно в реальном масштабе времени, и ограничения на техниче-
ское обеспечение являются факторами, влияющими на эффектив-
ность разработки программ. Имеются и разработки промежуточ-
ного полунезависимого типа, которые обладают чертами разрабо-
ток распространенного и встроенного типов. Общей для всех
типов характеристикой, в основном определяющей стоимость ПО,
является размер исходного текста записи алгоритмов и данных.
Автор книги рассматривает в качестве исходного для оценивания
затрат на ПО технический термин число исходных команд (ЧИК),
в отличие от числа выполняемых машинных команд. Числу исход-
ных команд отведена такая роль в связи с тем, что, во-первых, ис-
ходная команда—это непосредственный продукт человеческой
деятельности в инженерном программировании, а машинная
команда — результат трансляции, компиляции или генерации;
во-вторых, ЧИК хорошо согласуется с физическими носителями ин-
формации (перфокарта, строка на бумаге или на экране дисплея
и другие).
На основе этого понятия автор книги развивает метрологиче-
ский подход к программированию для выявления методов проек-
тирования программного изделия, повышения производительности
тРУда при создании ПО, разработки мероприятий по улучшению
управления проектом ПО. Он отказывается от технократическо-
го подхода к проектированию ПО, уделяя существенное внима-
ние социальным вопросам в проектировании систем обработки
информации. Однако существующие в США безработица, неустой-
чивость доллара и погоня за денежной прибылью наложили опре-
деленный отпечаток на некоторые его рекомендации.
Человеческий фактор в инженерном проектировании становит-
ся одним из главных, определяющих факторов повышения произ-
одительности разработок систем на базе вычислительной техни-
и. Эти положения и многие вопросы второстепенного по важно-
и характера подвергаются в книге анализу и обоснованию. Все
иные и обсуждения базируются на систематизации накопленно-
30QB ПУбликациях материала (список литературы -содержит более
7
Кроме того, важное достоинство книги состоит в описании при-
емов и методов применения и настройки моделей оценивания за-
трат на проектирование и программирование.
В СССР имеется значительное число коллективов, разрабаты-
вающих и внедряющих в практику предприятий и организаций
метрологические методы в проектировании. Поэтому известные ме-
тоды могут быть сопоставлены с методами, предложенными
Боэмом.
Над переводом книги работали: В. В. Лукашев (предисловие,
гл. 1 —15 и гл. 26), П. Н. Петрушкин (гл. 16—24), В. П. Чепкасов
(гл. 21, 24, 25, 27 и 28), А. X Красилов (гл. 29—33).
Книга предназначена для инженеров-программистов, руково-
дителей коллективов программистов и вычислительных центров,
экономических групп вычислительных центров, осуществляющих
технико-экономическое обоснование программных проектов, для
преподавателей курсов по программированию, а также для студен-
тов старших курсов и аспирантов по специальности «Математиче-
ское обеспечение» в качестве вспомогательного пособия.
Проф. А. А. Красилов
Шарле, Ромни и Тенли
посвящается
ПРЕДИСЛОВИЕ
Курс инженерной экономики стал довольно обычной составной
частью образования инженеров-разработчиков аппаратуры. Для
инженеров-программистов возможности пройти аналогичный курс
по экономике программного обеспечения (ПО) до сих пор весьма
ограничены. В результате этого большинство программистов упу-
скают удобный случай изучить и использовать в своей деятельно-
сти ряд важных экономических понятий и методов для облегчения
работы с ПО и повышения его качества.
Поэтому главной целью предлагаемой книги является изложе-
ние основ инженерного проектирования ПО, ориентированное на
студентов старших курсов и аспирантов вузов, при этом боль-
шое внимание уделяется экономическим аспектам проектирования.
Для достижения указанной цели необходимо удовлетворить двум
вспомогательным требованиям:
1) сделать книгу легкой для изучения студентами,
2) сделать книгу легкой для обучения по ней преподавате-
лями;
я также приложил усилия для того, чтобы книга содействовала
выполнению третьего требования:
3) предоставить в распоряжение программистов-практиков по-
лезный аппарат проектирования ПО.
Поскольку указанные требования иногда противоречат друг
другу, то для каждой группы читателей (студентов, преподавате-
лей и инженеров-практиков) приводятся примечания по содержа-
нию книги.
Общую структуру книги иллюстрирует рис. А. Часть 1 содер-
жит вводный материал, в котором описаны область применения,
мотивировка и структура целей инженерного программирования.
В ч. 2 и 3 рассмотрены две дополняющие друг друга темы: коли-
чественная модель жизненного цикла ПО (ЖЦПО) и основы ин-
женерной экономики в применении к программным проектам.
° ч. 4 описана подробная методика оценивания затрат на ЖЦПО,
которая лежит в основе простых моделей стоимости (см. ч. 2) и
роваД°В ^ехник°‘экономического анализа инженерного программи-
Ми^а РИС' А приведены также основные вопросы, рассматривае-
е п каждой части книги. Так, в ч. 4 обсуждены не только вопро-
оценивания стоимости ПО и факторы, влияющие на его стои-
9
мость, но и ряд других вопросов, например: «Каким образом мож-
но использовать знание этих факторов для улучшения обозримо-
сти и управляемости программных проектов и увеличения произ-
водительности труда при разработке программ?». Рисунку А в
полной мере соответствует оглавление книги.
Рис. А. Структура книги и основные вопросы, рассмотренные в ней
В книге описаны последовательные уровни детализации
КОМОСТ (Конструктивной МОдели Стоимости)—иерархиче-
ской модели оценивания стоимости. Верхний уровень иерархии —
базовая КОМОСТ — является темой гл. 5—7; он определяется про-
стой формулой для вычисления стоимости программного проекта
в зависимости от размера проекта, выраженного числом исходных
команд. Следующий уровень — промежуточная КОМОСТ — описан
в гл. 8 и 9. В этой модели оценка стоимости зависит от размера
программного проекта и ряда стоимостных атрибутов, например
опыта и квалификации исполнителей проекта, аппаратных ограни-
10-
чений и степени использования современных методов программи-
рования. Наиболее точным и детальным уровнем иерархии являет-
ся детальная КОМОСТ, описанная в гл. 23 и уточненная
в гл. 24—27. В этой модели оценивание затрат на программное из-
делие производится по каждой фазе, подсистеме и модулю.
Использование термина «конструктивная» обосновывается в
гл. 24—27 объяснением влияния различных факторов на объем за-
трат, требуемых на завершение каждой фазы ЖЦПО. Кроме того,
конструктивность модели определяется тем, что она не только
предоставляет оценочные формулы, но и обеспечивает достовер-
ное объяснение получаемых с ее помощью результатов.
В гл. 24—31 детально обсуждаются границы имеющихся зна-
ний о методах стоимостного оценивания ЖЦПО и приводится спи-
сок тем для дальнейших исследований, которые смогут расширить
знания о ЖЦПО и его экономических характеристиках.
Я чувствую себя в неоплатном долгу перед многими людьми
за их поддержку, советы и информацию; хотелось бы назвать всех,
кто мне помогал.
Большую помощь многочисленными советами по вопросам уп-
равления мне оказали сотрудники фирмы TRW С. Рамо, К- Бессе-
рер, Б. Уильямс и Э. Голдберг; обширную техническую информа-
цию и множество технических советов предоставили также
Т. Бауэр, М. Коззенс, М. Липоу, Ф. Мэнти, Н. Микула, Э. Нельсон,
Р. Осборн и Т. Тейер и бывшие сотрудники фирмы TRW Б. Аб-
рамсон, Т. Белл, Дж. Браун, К- Фишер, Б. Пейдж, У. Ройс и в осо-
бенности Р. Уолвертон.
По вопросам количественного анализа ПО было проведено
много приятных, вдохновляющих и полезных обменов мнениями
с проф. В. Бейснли из Университета штата Мэриленд, д-ром Л Би-
леди из фирмы IBM, Т. Демарко, Т. Джилбом и покойным
проф. М. Хэлстедом из Лафайеттского университета, К. Джонсом
из фирмы ITT, проф. М. Леманом из Имперского колледжа в Лон-
доне, Д. Нельсоном из Научно-исследовательского центра ВВС
Ром, Б. Парком из фирмы RCA, д-ром М.Фистером, мл., Л. Пут-
немом из фирмы Quantitative Software Management и К- Уолсто-
ном из фирмы IBM.
В других областях мне посчастливилось много полезного узнать
из обсуждений с д-ром Дж. Уейнбергом психологических аспектов
программирования, с д-ром Д Парнасом из Научно-исследова-
тельской лаборатории ВМС и фирмы IBM, д-ром X. Милзом из
фирмы IBM и проф. Т Хоаром из Оксфордского университета —
методологии проектирования ПО; многое мне дали также много-
численные неформальные семинары на теннисных кортах, посвя-
щенные экономике и статистике с участием д-ра Ч. Уолфа из фир-
мы RAND и проф. К. Морриса из Университета штата Техас.
Подготовке настоящей книги существенно содействовали
К. Карлстром из издательства «Прентис-холл» и в особенности
пРоф. Р. Хэмминг из Высшего училища ВМС США, который, соб-
ственно говоря, и вдохновил меня на написание этой книги. Исклю-
11
чительно большую поддержку и помощь оказали мои секретари
AL Грипенуолд и К- Клайн. Редактор издательства «Прентис-холл»
Л. Фрэнкел способствовала существенному улучшению книги.
Много ценных предложений было получено от лиц, просмотревших
книгу в рукописи, в особенности от проф. Л. Купрайдера и проф.
Э. Хоровитца из Университета штата Южная Каролина, проф.
Р. Фэйрли из Университета штата Колорадо, Б. Кернигана из фир-
мы BTL, проф. Т. Стендиша из Калифорнийского университета в
Эрвине и Д. Вейсса из Научно-исследовательской лаборатории
ВМС.
В заключение хочется особенно поблагодарить всех тех много-
численных оставшихся неназванными лиц, которые своей работой
способствовали сбору данных о ПО. Больше же всего я благода-
рен своей семье, однако словами эту благодарность выразить не-
возможно.
Примечание для студента. Вполне возможно, что в недалеком
будущем вы окажетесь в одной комнате с группой людей, которые
будут решать, сколько времени и денежных средств предоставить
вам для выполнения важного нового программного проекта. Вряд
ли кто-нибудь из присутствующих, кроме одного-двух человек,
будет хорошо понимать проблемы разработки ПО. В основном ва-
шими собеседниками будут представители высшего руководства,
экономисты-аналитики, специалисты по рынку, плановики и т. п.
Как правило, эти люди будут обсуждать вопросы и принимать ре-
шения в таких терминах, как предельная прибыль на инвестиро-
ванный капитал, отношение прибыли к затратам и степень риска.
Некоторых весьма заинтересованных людей в комнате не будет.
К ним относятся специалисты, которые будут работать с вами или
для вас над программным проектом, а также пользователи ПО,
создаваемого вашей бригадой. Независимо от того, знают они об
этом или нет, их судьба в течение следующих нескольких месяцев
или лет будет зависеть от того, насколько реалистичное решение
вы и ваши собеседники, не знакомые с программированием, смо-
жете принять относительно требуемых масштаба, бюджета и сро-
ков программного проекта.
Присутствующие на совещании непрограммисты не смогут сде-
лать этого самостоятельно, они не будут ощущать ваших альтер-
натив в разработке. Поэтому для вас будет чрезвычайно важно
уметь найти с ними общий язык и понимать экономические концеп-
ции, которые лежат в основе их рассуждений и принятия ими ре-
шений. Если вы сумеете это сделать, у вас появится возможность
превратить часто враждебные отношения между программистами
и экономистами в отношения понимания, ответственности и до-
верия.
В этой книге предпринята попытка познакомить вас с основны-
ми понятиями и методами, которые дадут вам возможность ис-
пользовать экономические знания так же хорошо, как и програм-
мистские. Мой личный опыт свидетельствует, что помимо практи-
ческой пользы изложенный в книге материал позволит вам по-но-
12
вому взглянуть на область вычислительного дела. В частности,
этот материал очень полезен для ответа на следующие вопросы.
В чем заключается ценность информации?
Зачем нужны программные изделия?
Как определяется необходимость программного изделия?
Какова сущность ЖЦПО?
Как и в других областях, чем лучше понимание существа инже-
нерного проектирования, тем эффективнее оно применяется на
практике.
Примечание для преподавателя. С помощью этого примечания
и самой книги хотелось бы убедить вас в следующем.
1. Инженерная экономика ПО является вдохновляющей и до-
ставляющей большое удовольствие темой обучения и изучения.
2. Эта книга может быть использована для полусеместрового
или семестрового курса по инженерной экономике ПО или в каче-
стве дополнительного пособия по общим вопросам инженерного
программирования.
3. Инженерная экономика ПО является важной и благодатной
областью исследований.
Во-первых, вы обнаружите, что обучение инженерной экономи-
ке ПО доставляет удовольствие и вознаграждает за затраченные
усилия. Так, основные соотношения микроэкономики образуют
изящную и строгую математическую дисциплину. Материал, отно-
сящийся к оценке степени риска и ценности информации, помогает
понять необходимость для общества ЭВМ, ПО и информации, вы-
рабатываемой нашей отраслью. А материал, относящийся к фак-
торам, влияющим на стоимость ПО, позволяет объяснить весьма
многие рекомендации современного инженерного программирова-
ния и их влияние на ЖЦПО.
Кроме того, вряд ли необходимо все время прибегать к опыту
и жаргону, принятым в промышленности, для поиска примеров
применений инженерной экономики ПО Еще во время работы в
университете штата Южная Каролина меня потрясло огромное
разнообразие разрабатываемых в университете аппаратных и про-
граммных систем и особенно в наше время напряженных универ-
ситетских бюджетов — большое внимание к вопросам стоимости
аппаратуры и программ. Поэтому мною были приложены усилия,
чтобы при изложении знакомого материала устранить засорение
книги промышленным жаргоном и включить довольно много воп-
росов и примеров, связанных с деятельностью университетов.
Важная задача обучения заключается в предоставлении сту-
денту возможности:
.определять факторы, наиболее сильно влияющие на стоимость
и использовать их для оценивания стоимости программного
проекта;
понять основные концепции микроэкономики в применении к
инженерному программированию;
применять методы экономического анализа для принятия реше-
и в процессе инженерного программирования.
13
Ниже приводится план весьма напряженного полусеместрового
курса, прочитанного на базе предлагаемой книги:
Неделя Главы книги Тема
1 1—4 Экономическое значение жизненного цикла ПО
2 5—6 Простые модели стоимости
3, 4 7—9 Промежуточные модели стоимости ПО н факто- ры, влияющие на стоимость
5 10—12 Анализ эффективности затрат, эффект масштаба, ьыбор среди альтернативных решений
6 — Обзор, промежуточный экзамен
7 13—15 .Анализ многоцелевых решений: чистая и теку- щая стоимости, целевые функции
8 16—18 Анализ многоцелевых решений: ограничения на область решений, системный анализ, качествен-
пые показатели
9 19—20 Риск, неопределенность и ценность информации
10 21—22 Практические методы оценивания затрат на ПО
11 31—32 Анализ и контроль затрат в ЖЦПО на примерах
12 — Заключительный экзамен
При чтении курса по инженерной экономике ПО, указанный в
плане материал по своему объему, вероятно, больше подходит
для семестрового курса. Приемлемый полусеместровый курс мог
бы охватить только материал по гл. 18 включительно и все же
достаточно хорошо соответствовать целям обучения.
Предлагаемый материал можно читать либо студентам стар-
ших курсов, либо аспирантам первого года обучения. Единствен-
ным требованием к предварительной подготовке слушателей явля-
ется общее знакомство с программированием (приблизительно в
объеме двухлетнего обучения вычислительной науке) и с основами
дифференциального исчисления. Для применения моделей оценки
стоимости ПО весьма желательно использовать микрокалькулятор
с операцией возведения в степень, хотя в книгу и включены графи-
ки для приближенных расчетов.
Наконец, хотелось бы надеяться, что вы достаточно углуби-
тесь в инженерную экономику и заинтересуетесь некоторыми из
фундаментальных вопросов, поднятых в книге, относительно про-
цесса разработки ПО, например такими:
Почему столь велики затраты на ПО?
Какие факторы уменьшают или увеличивают затраты на ПО
и как они взаимодействуют?
Какие работы требуют наибольших затрат?
Каким образом новые методы программирования могут умень-
шить затраты на ПО?
В ч. 4 этой книги описана и проанализирована база данных по
затратам и характеристикам 63 программных проектов в попытке
ответить на следующий вопрос:
J4
Как объяснить собранные данные о программных проектах и
извлечь пользу для оценивания будущих проектов и понимания
природы затрат на ПО?
Описанное семейство моделей стоимости представляет первый
щаг в ответе на этот вопрос, но необходимо еще провести много-
численные важные исследования. Значительные результаты можно
получить просто дальнейшим анализом базы данных 63 проектов.
Гораздо большего можно достичь сбором и анализом дополнитель-
ных данных практических разработок и экспериментов. Для ука-
зания наиболее перспективных направлений исследований и
получения ответов на приведенные выше вопросы в некоторые гла-
вы включены разделы «Темы для исследований». Хотелось бы
надеяться, что вы попытаетесь провести эти исследования.
Примечание для инженера-программиста. По-видимому, в ре-
зультате практической деятельности у вас выработались некото-
рые собственные приемы оценивания затрат на ПО, работы с про-
граммным изделием и рассмотрения проектных решений. Хочется
надеяться, что эта книга поможет вам сравнить ваши личные эм-
пирические правила с опытом других людей и обеспечит вас неко-
торыми дополнительными полезными методами оценивания затрат
на ПО и рассмотрения программных решений. Хотелось бы также
надеяться, что при изучении этой книги вы испытаете вдохновение
и почувствуете удовлетворение от приложенных усилий, когда уви-
дите единую систему экономических принципов, составленную на
основе различных на первый взгляд методов принятия решений.
В зависимости от ваших основных интересов и потребности в
информации вы можете пожелать сосредоточить внимание на от-
дельных частях этой книги, а не читать ее целиком. Для вас ниже
приводятся рекомендации по выбору подходящих частей книги.
Если вы стремитесь, главным образом, развить ваши способно-
сти оценивания затрат на программную разработку (или повысить
в этом отношении возможности вашей организации), вам лучше
всего начать с чтения гл. 21 и 22 о методах оценивания затрат на
ПО, после чего перейти к гл. 4-9 о ЖППО и КОМОСТ.
Если, кроме того, вы интересуетесь и оценками затрат на сопро-
вождение, прочитайте гл. 30 и 31.
Если же, наконец, вы интересуетесь и внедрением модели сто-
имости ПО, а также ее настройкой на условия функционирования
вашей организации, прочитайте гл. 23 и 29.
Если вы интересуетесь, главным образом, влиянием конкретной
характеристики разработки (например, квалификации исполните-
лей, применения современных методов программирования или
уровня применяемого языка) на стоимость ПО, прочитайте
гл. 24—28.
Если вы стремитесь, главным образом, развить ваши способно-
сти выполнения технико-экономического анализа решений в обла-
сти разработки ПО, прочитайте гл. 10—18.
Если вы интересуетесь методами планирования и контроля
Программного проекта, прочитайте разд. 31.6 и гл. 32.
15
Даже если вы интересуетесь, главным образом, какой-нибудь
конкретной темой, весьма желательно прочитать вводный материал
(гл. 1—3). В этих главах описаны основные проблемы инженер-
ного проектирования и некоторый подход к реализации более эф-
фективного и удовлетворительного средства проектирования про-
грамм.
СПИСОК СОКРАЩЕНИИ
АПИ
АПП
АЛТ
АСУ
АТПО
АЧИК
Б
БОСПА
БПКО
БП/ЭП
ВЕР
вмк
вп
ВЦ
вчик
гот
дзк
дик
дип
д/п
ЗАО
ЖЦПО
ИБПЗ
ИВМ
ИИ
ИИС
ипс
ИТ
ич
к
КА
КАП
КЗ
киз
кк
ККА
ккз
ККП
км
кмк
КОМОСТ
КП
КПГИ
КПУП
КС
ксик
КУП
кчик
кэчик
— Анализ проекта изделия
— Анализ приемки программ
— Анализ планов и требований
— Автоматизированная система управления
— Анализ требований к программному обеспечению
— Адаптированное число исходных команд
— Большой размер программы
— Базовое окружение системы программирования на языке Ада
— Бланк для покомпонентной оценки
— Быстрый прототип/эволюционное проектирование
— Вероятность
— - Выполняемая машинная команда
— Верификация и подтверждение
- — Вычислительный центр
— Взвешенное число исходных команд
— Готовность
— Доля затрат на комплексирование и испытания
— Доля изменяемых кодов
— Доля изменений проекта
— Размер базы данных/размер программы
— Завершение автономной отладки
— Жизненный цикл программного обеспечения
— Итоговый бланк планирования задач
— Изменяемость виртуальной машины
— Искусственный интеллект
— Использование инструментальных средств
— Информационно-поисковая система
— Изменяемость требований
— Издержки на оплату исполнителей за один ЧМ
— Обозначение тысячи (слов, команд)
— Квалификация аналитиков
— Критический анализ проекта
— Коэффициент затрат
— Коэффициент идеальных затрат
— Контроль качества
— Корректирующий коэффициент адаптации
— Корректирующий коэффициент затрат
— Корректирующий коэффициент переноса
— Конструктивный метод
— Тысяча машинных команд
— Конструктивная модель стоимости
— Квалификация программистов
— Коэффициент пересчета годовых изменений
— Коэффициент планового увеличения переноса
— Качество системы
— Тысяча строк исходного текста
— Коэффициент увеличения производительности разработки
— Тысяча ЧИК
— Тысяча ЭЧИК
16
м МКУП МО мод мсдпи МОСПА — Малый размер программы; модуль —Максимальное значение КУП — Математическое ожидание — Математическое ожидание дохода — Математическое ожидание дохода от полной информации — Минимальное окружение системы программирования ьа языке Ада
мся НАД нвп ОБ ОБД ОБС ОМ ОП ОРВМ ОРП ОРЯП ОС ОСР п п пг ПГР по пос ПОСПА ПОСТПО пп ппо ПС псп пчс РБД РМ РП "ЭС с с сво СЕР сиз СИП сос сот СПР СПС СР ст СТОИМПО СТПР СУБД C'TI сц СЦУОЗ — Машинно-ориентированный язык — Надежность — Независимые верификация и подтверждение — Очень большой размер программы — Огрангчение по быстродействию — Общая стоимость — Основной метод — Ограничение по оперативной памяти — Опыт работы с виртуальной машиной — Опыт работы в данной прикладной области — Опыт работы с языком программирования — Операционная система — Ограничение сроков разработки — Производительность — Промежуточный размер программы — Повышение гибкости — План-график работ — Программное обеспечение — Процессор обработки сообщений — Полное окружение системы программирования на языке Ада — Пакет оценки стоимости программного обеспечения — «Пакет программ — Процессор первичной обработки — Подсистема — Практика современного программирования — Предельная чистая стоимость — Размер базы данных — Радикальный метод — Реальная производительность — Реальная эффективность системы — Средний размер программы — Затраты, стоимость — вреднее время ответа — Сборник едини 1 разрг Вотки — Сложность изделия — Сборочное (при комллексировании) изменение проекта — Система обработки сообщений — Система обработки текстов — Структура подразделения работ — Система приведенной стоимости — Сроки разработки — Стоимость — Стоимость программного обеспечения — Структурное программирование — Система управления базой данных — Система управления процессом — Снижение цен — Система централгзованного управления оборудованием и запа-
счм сшр сэвм тнпо сами — Стоимость человеко-месяца — Сохраняемость штата разработчиков — Стоимость ЭВМ — Требуемая надежность программного обеспечения
17
— Техническое обеспечение
— Тип программного обеспечения
— Текущая стоимость
— Тип ЭВМ
— Управление конфигурацией
— Улучшение качества планирования и контроля
— Уменьшение числа ошибок
— Увеличение скорости обработки
— Фаза детального проектирования
— Форма иерархического оценивания ПО
— Фаза кодирования и автономной отладки
— Фаза комплексирования и испытаний
— Форма оценивания на уровне компонентов
— Фаза проектирования
— Фаза проектирования изделия
— Фаза проектирования требований к изделию
— Цикл обращения к ЭВМ
— Целеориентированный подход к ЖЦПО
— Центральный процессор
—-Число исполнителей с полным рабочим днем
— Число исходных команд
— Число исходных строк кодовой программы
— - Человеко-месяц
— Час машинного времени
— Чистая стоимость
— Число страниц документации
— Человеко-час
— Электронная вычислительная машина
— Электронная система платежей
— Эквивалентное число исходных команд
— Язык высокого уровня
— Язык программирования
— Язык проектирования программ
ЧАСТЬ 1
ВВЕДЕНИЕ
В ч. 1 основное внимание уделяется анализу двух конкретных
примеров для иллюстрации важности учета социальных факторов
в практике инженерного программирования.
При анализе первого примера (гл. 1) описаны две последова-
тельные попытки создания системы обработки информации для
журнала «Scientific American»1. В основу первой попытки было
положено чисто программное решение без учета экономических
факторов. Результатом явилась изящная программная система,
которая, однако, лишь усугубила тяжелое положение журнала. Во
второй попытке были учтены и программные, и экономические
факторы. В результате была разработана хорошо запрограммиро-
ванная система, удовлетворяющая всем целям журнала: сокраще-
нию затрат, ускорению обработки подписки, уменьшению числа
ошибок, сокращению текучести кадров и уменьшению числа жалоб
подписчиков.
При анализе второго примера (гл. 2) показана необходимость
учета экономических факторов, выходящих за узкие рамки бух-
галтерских забот о доходах и убытках. С этой целью описан про-
ект информационной системы для большого района городских
школ. Этот проект полностью удовлетворил финансовые требо-
вания данного района, но лишь за счет таких социальных мер,
как предоставление территориально близких рабочих мест учетчи-
ков нуждающимся матерям, дети которых посещают школы этого
округа. Проведенный анализ показывает, что инженерная эконо-
мика ПО не может сводиться к чисто количественному (денежно-
му) исследованию, направленному на максимальное увеличение
доходов, но может и должна учитывать социальные вопросы.
В гл. 3 представлены общая структура целей проектирования
ПО и способ объединения приемов рассмотрения программных,
экономических и социальных аспектов в единый практический
подход к инженерному программированию, в рамках которого
будут применяться методики инженерной экономики ПО. Указан-
ный подход называется ЦОП (целеориентированный подход к жиз-
ненному циклу ПО). В главе даны также примеры использования
ПОП и обсуждена его роль в инженерном программировании без
пераничений области применения.
1 В русском издании — «В мире науки». Издается с 1983 г. М.: Мир.—
19
ГЛАВА 1
ПРИМЕР СИСТЕМЫ ОБРАБОТКИ ПОДПИСКИ НА ЖУРНАЛ
1.1. ПРЕЖНЯЯ СИСТЕМА
В конце 60-х годов журнал «Scientific American» оказался в по-
ложении, характеризующемся быстрым увеличением числа подпис-
чиков, ростом объема обработки данных по подписке и медленной,
громоздкой, ненадежной ручной системой их обработки. На рис. 1.1
приведена общая схема системы, применявшейся в то время. По-
ступающая почта сначала попадала к кассиру, который выбирал
из нее платежи наличными деньгами, чеки и денежные переводы.
Остальные поступления разделялись на заказы и прочие поступ-
ления (жалобы, извещения об изменении адреса и т. п.). На этой
стадии производились ручной подсчет и подытоживание поступле-
ний для облегчения контроля последующих операций.
Следующие операции выполнялись последовательно по цепоч-
ке рабочих мест сотрудниками отдела обработки подписки. Эти со-
трудники сортировали заказы по типу обработки (новые, продол-
жающиеся, дарственные), кодировали для ввода и пакетировали
их для последующей перфокарточной обработки. После перфора-
ции заказы обрабатывались на перфокарточной оборудовании (та-
буляторах, печатающих и сортирующих устройстгах и т. п.) для
получения начального комплекта счетов и почтовых ярлыков. За-
тем перфокарты с информацией о подписке вставлялись вручную
во входной перфокарточный файл и обрабатывались для получе-
ния ежемесячных почтовых ярлыков, годовых сводок и т. п.
Эта трудоемкая система становилась все более медленно дей-
ствующей, дорогой, ненадежной и неспособной справиться с сезон-
ными пиками в обработке подписки. Суммарные задержки привели
к росту жалоб подписчиков, и руководство журнала решило по-
следовать примеру многих издательств периодической литературы,
которые автоматизировали операции обработки подписки.
1.2. ПРОГРАММНОЕ РЕШЕНИЕ
Руководство журнала «Scientific American» заключило договор
с фирмой по проектированию ПО о разработке автоматизирован-
ной системы, учитывающей его потребности. Разработчики фирмы
обычно решали поставленные перед ними задачи, принимая во
внимание лишь программные факторы. Их подготовка и опыт были
сосредоточены на получении программных решений четко сформу-
лированных задач. Поэтому они проанализировали сложившуюся
для журнала ситуацию, определили часть, имевшую программное
решение, и реализовали это решение.
Действительно, правая часть рис. 1.1 (обработка и модифика-
ция главного файла) похожа на знакомые из современных учебни-
ков по структурному программированию схемы разработки свер-
20
Новый главный файл
Главный
Счета,
ярлыки,
извещения
Некорректные
данные
Рис. 1.1. Прежняя си-
стема обработки подпис-
ки
Обработка данных
Рис. 1.2. Программно-
ориентированная раз-
работка методом свер-
ху—вниз
ху _ вниз с пошаговой конкретизацией. Как видно из рис. 1.2,
следующие этапы в пошаговой конкретизации сверху — вниз состо-
ят в определении операций верхнего уровня (см. рис. 1.1, обработ-
ка данных) как последовательности операций нижнего уровня
(проверка правильности данных и т. п.), на котором при необхо-
димости определяются операции для более низких уровней (опре-
деление типа данных и т. п.).
Программное решение, полученное фирмой, показано на
рис. 1.3. Созданная система позволила автоматизировать сортиров-
ку данных с помощью ЭВМ IBM 360/30, программа которой была
разработана в соответствии со схемой рис. 1.2. Рассмотрим теперь,
как полученное решение отразилось на положении журнала.
1.3. РЕЗУЛЬТАТЫ ПРОГРАММНОГО РЕШЕНИЯ
Главные результаты:
возросли расходы;
ухудшились надежность и качество обслуживания;
потребовались дополнительные конторские работники;
ухудшился микроклимат в коллективе;
хвозросла текучесть кадров.
Главной причиной таких результатов явилось то, что программ-
ное решение не учло некоторых важных производственных аспек-
тов проблемы. Неучтенные факторы существенно повлияли на
технические и экономические свойства системы обработки данных.
Например, простейшие ошибки во входных данных приводили, как
правило, к невозможности обработки целого пакета этих данных
или к полному прекращению всей обработки. После этого необхо-
димо было найти и вручную проверить листинги ввода и обнару-
жить ошибки. Исправление ошибок включало еще один трудоем-
кий процесс, связанный с редактированием файла. В прежней
системе при сортировке эти ошибки обычно обнаруживались и сра-
зу же исправлялись операторами, хорошо знающими, появления
каких ошибок можно ожидать и как их исправлять.
Для исключения большего числа ошибок, требующих много
времени на их исправление, были введены дополнительные уровни
контроля на предшествующих машинному прогону шагах ручной
обработки. Чтобы не допустить таких действий, как возобновление
несуществующих подписок, были введены дополнительные провер-
ки. Для уменьшения числа исключительных ситуаций были внед-
рены более сложные бланки для записи исходных данных и конт-
рольные ведомости. В результате этого увеличились штаты, расхо-
ды, потери времени и ухудшился микроклимат в коллективе.
1Л ЭКОНОМИКО-ПРОГРАММНЫЙ подход
К счастью, в это время журналу удалось привлечь к работе
специалиста, который смог рассмотреть проблему как с программ-
ной, так и с экономической точек зрения. Этот специалист проана-
22
лизировал всю систему, используя ориенти-
рованную в значительной степени на пользо-
вателя разработку сверху — вниз. При этом
были рассмотрены следующие вопросы:
1. Какие цели ставит пользователь?
2. Какие решения, зависящие от разра-
ботчиков, влияют на достижение этих це-
лей?
3. Какие имеются ограничения на об-
ласть допустимых решений?
4. Какие критерии следует использовать
для оценки возможных решений? Как эти
критерии зависят от переменных, характери-
зующих возможные решения?
5. Какие решения обеспечивают наилуч-
ший результат по отношению к установлен-
ным критериям?
Учитывая ответы на эти вопросы, новый
специалист смог определить и реализовать
более оптимальное по показателю затра-
ты — эффективность решение для удовлет-
ворения запросов журнала. Ниже кратко из-
лагаются найденные им ответы.
1. Какие цели ставит пользователь?
Главные цели журнала заключались в
увеличении скорости и надежности обработ-
ки подписки, уменьшении расходов, числен-
ности персонала и текучести кадров, а так-
же числа жалоб подписчиков. Для ответа
на этот вопрос были также собраны и про-
анализированы данные относительно важ-
нейших источников расходов, ошибок, по-
терь времени и жалоб.
2. Какие решения, зависящие от разра-
ботчиков, влияют на достижение этих це-
лей?
В рассмотренном случае к таким решени-
ям относились не только вопросы примене-
ния ЭВМ, но также и использование индиви-
дуальных почтовых ящиков для заказов раз-
личных типов; тем самым сортировка умело
перекладывалась на почтовую службу США.
3. Какие имеются ограничения на об-
ласть допустимых решений?
Одним из существенных ограничений бы-
ла необходимость хранения данных для ре-
визии финансовых операций, и это было
столь же важным для ряда других потреб-
ностей. Заметим, что отсутствовали такие
Рис. 1.3. Программное решение проблемы обработки подписки
23
ограничения, как, например, требования сохранить трудоемкие опе-
рации первичной обработки или использовать только один индекс
почтового ящика.
4. Какие критерии следует использовать для оценки возмож-
ных решений? Как эти критерии зависят от переменных, характе-
ризующих возможные решения?
Важной для журнала явилась минимизация следующих пока-
зателей: стоимости обработки подписки, времени учета сообщен-
ных подписчиком изменений, частоты ошибок, численности персо-
нала, текучести кадров. При оценке возможных решений по этим
показателям аналитики провели сравнительный стоимостный ана-
лиз, примеры которого будут описаны в книге. Они обнаружили,
Рис. 1 4. Экономико-программное решение проблемы обработки подписки
что самым узким местом была предварительная ручная обработка
и что ЭВМ IBM 360/30 использовалась неэффективно.
5. Какие решения обеспечивают наилучший результат по отно-
шению к установленным критериям?
Руководством журнала было принято решение о внедрении си-
стемы, приведенной на рис. 1.4. В реализованной системе для за-
казов различных типов использовались почтовые ящики с соответ-
ствующими индексами, что позволило сортировать основную часть
вводимых данных с помощью почтовой службы. В качестве перво-
го шага оператор журнала вскрывал конверты и регистрировал
заказы на персональном миникомпьютерном интеллектуальном
терминале. Используемый терминал был запрограммирован для
диалоговой проверки вводимых данных, он проверял эти данные и
немедленно сообщал оператору о необходимости исправления. Вво-
димые данные упорядочивались по частоте использования так, что
наиболее часто поступающие сообщения (стандартное возобновле-
ние заказа) вводились только нажатием 21 клавиши. Проверенные
данные записывались на магнитные ленты, которые ежедневно
передавались на обработку в вычислительный центр (ВЦ).
1.5. РЕЗУЛЬТАТЫ ЭКОНОМИКО-ПРОГРАММНОГО ПОДХОДА
Получение ответов на приведенные выше вопросы основано на
подходе, использующем технико-экономический системный анализ
(см. гл. 17). В примере с журналом «Scientific American» резуль-
,ат примен гния этого подхода заключался в установке пяти мини-
компьютерных интеллектуальных терминалов стоимостью 10 тыс.
долл, каждый, в отказе от ЭВМ 1ВМ 360/30 (что привело к эко
номии приблизительно 9 тыс. долл, в месяц) и в получении услуг
ВЦ приблизительно за 7 тыс. долл, в месяц. Разработанная систе-
ма потребовала существенно меньшего числа людей, так что
журнал смог возместить затраты на терминалы к концу первого
года работы. В конце года результаты были таковы:
число конторских служащих сократилось с более чем 40 чело-
век до менее чем 20 человек;
число канцелярских ошибок было сокращено до небольшого
числа неизбежных «ошибок подписчика» (например, повторные
заказы или платежи);
фактически все операции выполнялись менее чем за неделю, в
то время как при использовании прежней системы весьма частыми
были задержки более чем на месяц;
новая система успешно справлялась с объемом работ, увели-
ченным на 33%;
субъективные реакции служащих указывали на возросшее чув-
ство удовлетворения работой. Пошаговый ввод заказов сделал
работу более интересной, увеличил возможности для проявления
способностей в решении проблем и анализе исключительных си-
туаций.
Таким образом, экономико-программный подход позволил по-
лучить решение, удовлетворяющее всем требованиям по улучше-
нию работы журнала и давшее в ряде случаев более хорошие, чем
ожидалось, результаты, тогда как чисто программное решение
только ухудшило положение.
1.6. ОБЩЕЕ ОБСУЖДЕНИЕ
Главное достсинство экономико-программного подхода заклю-
чалось в том, что он дал аналитикам возможность рассмотреть
стоящую перед ними проблему с нескольких сторон. При О'1 сутст-
вии такой возможности все могло бы произойти в соответствии со
словами: «Дайте человеку молоток, и ему покажется, что гесь мир
состоит из гвоздей». Так и получилось после внедрения первого ре-
шения: программисты-аналитики определили программный аспект
проблемы (крайность) и получили ограниченное решение.
В практике инженерного программирования обнаруживается,
что имеются как программные, так и непрограммные проблемы:
производственные и бюджетные, проблемы календарного планиро-
вания и определения относительных приоритетов запросов пользо-
25
вателей. Концентрация усилий на программных проблемах в
ущерб непрограммным будет почти всегда приводить к последую-
щим трудностям.
Понимание экономической стороны проблемы поможет анали-
зировать различные ситуации применения инженерного програм-
мирования и формулировать более удовлетворительные экономи-
ко-программные решения. В следующей главе рассматривается
еще одна сторона проблемы, существенная для успешного приме-
нения инженерного программирования.
ГЛАВА 2
ПРИМЕР СИСТЕМЫ УЧЕТА ПОСЕЩАЕМОСТИ ГОРОДСКИХ ШКОЛ
2.1. ПРОГРАММНЫЕ АСПЕКТЫ
В начале 70-х годов группа аналитиков из одной консультирую-
щей фирмы разработала проект системы учета посещаемости го-
родских школ. Система была задумана как часть общей инфор-
мационной системы большого района городских школ. Про-
граммные аспекты проекта были решены хорошо: модульная,
функционально-ориентированная структура программы и структу-
ра данных точно соответствовали предполагаемому для этого рай-
она распределению запросов, постоянному обновлению базы
данных и формированию сообщений.
2.2. ЭКОНОМИЧЕСКИЕ АСПЕКТЫ
Экономические аспекты проекта также были решены: предпо-
лагаемый экономический эффект для района городских школ со-
ставил несколько миллионов долларов в год. Основную часть эко-
номии давало совершенствование системы учета посещаемости
школ, поскольку прежняя система не была автоматизирована и
требовала до девяти учетчиков в некоторых школах. Для сбора
данных о посещаемости новым проектом предусматривались ис-
пользование перфокарт с графическими пометками, непосредствен-
но воспринимаемыми устройствами ввода ЭВМ, и установка в
каждой школе станции ввода и печати данных. Эта система выда-
вала бы более оперативные и непротиворечивые отчеты о посещае-
мости при одновременном сокращении числа учетчиков до двух
человек на каждую школу.
2.3. СОЦИАЛЬНЫЕ АСПЕКТЫ
Предусматриваемое уменьшение числа учетчиков было глав-
ным социальным недостатком проекта. Оказалось, что большинст-
во учетчиков, места которых в новой системе подлежали сокраще-
26
нию, составляли матери из бедных районов города, работающие
часто в тех школах, где учатся их дети. Места учетчиков были
фактически их единственной возможностью работать и в то же
время быть вместе со своими детьми. Без этих мест большинству
таких матерей пришлось бы либо поступить на более удаленную
от дома работу и потерять возможность присматривать в школе за
своими детьми, либо записаться в списки на получение пособия.
Хотя точное определение функций системы школьного обучения
вряд ли включает обеспечение нуждающихся людей приемлемой и
удобной работой, администрация системы образования и школьное
правление сочли, что эта функция удовлетворяет важную общест-
венную потребность. Поэтому они решительно отвергли ту часть
проекта системы, которая относилась к автоматизации учета посе-
щаемости. Главная ошибка группы проектировщиков заключалась
в том, что они уделили слишком много внимания программным и
количественным экономическим аспектам проблемы. При этом бо-
лее важные социальные аспекты проекта, затрагивающие интере-
сы значительного слоя общества, были полностью выпущены из
вида.
2.4. УСВОЕННЫЕ УРОКИ
Автор входил в состав этой группы проектировщиков и хорошо
запомнил, что первоначальная неудача проекта нанесла болезнен-
ный удар по его профессиональной гордости. Автор был активным
участником различных мероприятий, объединенных девизом «Вли-
яние ЭВМ на общество» и состоящих в основном в умозритель-
ных обсуждениях долгосрочного влияния ЭВМ на общество в це-
лом. Казалось, что участием в этих мероприятиях можно испол-
нить свой долг перед обществом. Полученная встряска заставила
осознать, что проводимые мероприятия подытоживали только
повседневную деятельность подобных автору аналитиков и про-
граммистов, которые, по-видимому, не очень умели выявлять важ-
ные социальные последствия своих проектов.
Однако по зрелому размышлению главный усвоенный из рас-
смотренного случая урок оказался очень полезным. Сущность его
заключалась в следующем:
Каждый программист может оказать существенное положи-
тельное влияние на общество, просто более тщательно учиты-
вая долгосрочные социальные последствия своей деятельности
и воплощая результаты этого учета в своих программных про-
ектах и изделиях.
Требуется определенный опыт для достаточно хорошего изуче
ния проблем, поставленных этим уроком, и для правильной рас-
становки приоритетов между социальными, программными и эко-
номическими аспектами.
27
ГЛАВА 3
ЦЕЛИ ИНЖЕНЕРНОГО ПРОГРАММИРОВАНИЯ
3.1. ВВЕДЕНИЕ
О разделении аспектов. Главный вывод гл. 1 и 2 состоит в том.
что эффективность инженерного программирования основывается
на учете не только программных, но также социальных и экономи-
ческих аспектов.
Однако даже без этих дополнительных аспектов программиро-
вание уже является чрезвычайно сложным делом. Лучшие специа-
листы в области программирования указывают на необходимость
еще большего упрощения, или разделения аспектов, для решения
большинства проблем программирования [86]. Если это верно, то
как можно оправдать усложнение программирования, требуя рас-
смотрения дополнительных социальных и экономических аспек-
тов? Ответ на этот вопрос состоит из двух частей:
1. Указанные аспекты нельзя не рассматривать. В гл. 1 и 2 по-
казаны типичные неудовлетворительные результаты, являющиеся
следствием пренебрежения социальными и человеческими аспекта-
ми инженерного программирования.
2. Можно в значительной степени сохранить преимущества обо-
их подходов, включая действия по разделению указанных аспектов
в цикл разработки ПО с периодическим анализом и доработкой
программных изделий для учета более общих целей.
Основные компоненты цикла показаны на рис. 3.1. Соответст-
вующий подход к инженерному программированию можно назвать
целеориентированным подходом к жизненному циклу ПО, или со-
кращенно ЦОП. Как видно из рис. 3.1, это довольно общий под-
ход, вовсе не ограниченный областью разработки ПО. Его ориен-
тация на программирование поддерживается иерархической струк-
турой целей (см. рис. 3.5), которая включает все главные цели, до-
стигаемые в результате создания программного изделия и в про-
цессе разработки ПО.
Для успешного использования ЦОП необходимо знать предпоч-
тительные или удовлетворительные способы согласования несколь-
ких противоречащих друг другу целей. Они объясняются в инже-
нерной экономике (см. ч. 3), где представлены методы анализа
экономической эффективности, приведенной стоимости, а также
методы системного анализа, обеспечивающие согласование целей
и принятие решений при наличии нескольких целей.
В этой главе представлена понятийная основа применения ме-
тодов инженерной экономики ПО. Рассмотрены следующие воп-
росы:
Что такое инженерное программирование?
Почему так важны социальные и экономические аспекты инже-
нерного программирования?
28
Рис. 3.1. Структура ЦОП
Почему необходим многоцелевой подход?
Как учесть широкий диапазон целей инженерного программи-
рования?
3.2. ОПРЕДЕЛЕНИЕ ИНЖЕНЕРНОГО ПРОГРАММИРОВАНИЯ
Определение инженерного программирования основывается на
определениях ПО и инженерной деятельности, приводимых в од-
ном из последних изданий словаря [295].
29
Программное обеспечение — это вся совокупность программ,
процедур работы и соответствующей документации для некоторой
системы, и в особенности для вычислительной системы.
Инженерная деятельность — это такое применение естествен-
ных и математических наук, посредством которого свойства мате-
рии и природных источников энергии ставятся на пользу человеку
в виде сооружений, машин, изделий, систем и процессов.
Учитывая, что используемые программным обеспечением свой-
ства материи и источников энергии воплощены в потенциальных
возможностях ЭВМ, и понимая под инженерным программирова-
нием прежде всего инженерную деятельность с целью -получения
ПО, получаем следующее определение: 1
Инженерное программирование—это такое применение есте-
ственных и математических наук, в результате которого потенци-
альные возможности ЭВМ реализуются на пользу человеку с по-
мощью машинных программ, организационных процедур и соот-
ветствующей документации.
Обсуждение. Приведенное определение инженерного програм-
мирования содержит два ключевых момента, которые заслужива-
ют дополнительного обсуждения. Во-первых, согласно этому опре-
делению ПО далеко не исчерпывается только машинными програм-
мами. Таким образом, деятельность хорошего инженера-програм-
миста никоим образом не сводится к умению разрабатывать ма-
шинные программы. Она подразумевает также умение создавать
качественную документацию, базы данных и разрабатывать проце-
дуры работы с вычислительными системами.
Вторым ключевым моментом являются слова «полезными че-
ловеку». С точки зрения практики эти слова требуют разработки
программных изделий, действительно полезных людям. Поэтому
преобразование некоторого набора спецификаций в правильную
машинную программу, удовлетворяющую этим спецификациям, не
исчерпывает всех функций инженера-программиста. Инженеры-
программисты должны также применять свои знания и здравый
смысл для разработок требуемых спецификаций и для того, чтобы
ПО действительно выполняло полезные обществу функции. Таким
образом, анализ значимости для общества вычислительных систем
является частью работы инженера-программиста, а методы прове-
дения этого анализа должны быть включены в практическую мето-
дологию инженерного программирования, а не рассматриваться в
качестве отдельной темы, изолированной от повседневной прак-
тики.
С научной точки зрения слова «полезными человеку» подразу-
мевают, что естественные и математические науки, используемые
в инженерном программировании, охватывают значительно боль
шую область знаний, чем собственно вычислительная наука. При
этом под полезностью следует понимать удовлетворение некото-
рой человеческой потребности за счет затрат, которые общество
может себе позволить. Поэтому весьма важным является исполь-
зование естественных и математических наук в социальной эко-
30
комической теории. Указанные науки представлены в данной кни-
ге и обеспечивают, с одной стороны, возможность научиться неко-
торым способам анализа таких аспектов проблем инженерного
программирования, которые связаны с вопросами стоимости и че-
ловеческими потребностями, а с другой — возможность объединять
указанные аспекты в единое целое с аспектами, относящимися к
вычислительной науке.
з.з. ТЕНДЕНЦИИ РОСТА СТОИМОСТИ ПО
Стоимость и качество производимого ПО определяются уров-
нем развития инженерного программирования. Важность инженер-
ного программирования обусловливается следующими двумя тен-
денциями:
Рис. 3.2. Тенденции изменения стоимости аппар?ту-
ры и ПО
1) программное обеспечение является сложным изделием и сто-
имость его все более возрастает;
2) программное обеспечение оказывает значительное и все воз-
растающее воздействие на общественное благосостояние. Эти тен-
денции рассматриваются в данном и следующем параграфах.
Стоимость ПО, разработанного в США в 1980 г., составила
приблизительно 40 млрд. молл., или около 2% стоимости валового
национального продукта. Темпы роста объема производства ПО
значительно выше аналогичного показателя для экономики в це-
лом. По сравнению со стоимостью аппаратуры ЭВМ стоимость ПО
продолжает расти в соответствии с предсказанными ранее в [41]
закономерностями (рис. 3.2).
В настоящее время эта тенденция (см. рис. 3.2) стала настоль-
ко резко выраженной, что аппаратуру можно рассматривать как
своего рода упаковку ПО, которое в значительной степени опреде-
ляем ценность вычислительной системы. Сегодня в покупаемой как
«аппаратура» вычислительной системе собственно аппаратура, как
31
правило, стоит в 3 раза меньше ПО. Большинство тщательно под-
готовленных поставок «аппаратуры» является, главным образом,
закупками ПО, так как при закупке большее значение придается
ПО, чем аппаратуре (см. гл. 15). Некоторые новые вычислитель-
ные системы (например, Amdahl, Magnuson, Cambridge и National
Semiconductor) представляют собой в значительной степени ПО
фирмы IBM, приспособленное для другого центрального процес-
сора. А в случае использования базовой системы IBM 4331 аренда
ПО может обойтись дороже аренды аппаратуры [189].
Что же касается будущего всей отрасли производства средств
вычислительной техники и обработки информации, то главным
продуктом отрасли будет ПО, доля которого, как ожидается, вы-
растет к 1985 г. до 8,5% [93] и к 199G г. до 13% валового нацио-
нального продукта [276].
Подобный рост спроса на ПО предъявляет существенные тре-
бования к инженерному программированию. Требования эти двоя-
кого рода: во-первых, существенно повысить производительность
труда при разработке ПО и, во-вторых, повысить эффективность
сопровождения ПО. Последнее требование является особенно важ-
ным, поскольку (см. рис. 3.2) сопровождение требует больших
затрат, чем разработка. В частности, экспериментальная точка для
1978 г. заимствована из отчета о результатах исследования 487 си-
стем обработки. данных, причем среднее распределение затрат
труда для этих систем оказалось следующим: разработка — 43,3%,
сопровождение — 48,8% и другие работы — 7,9% [184].
34. ТЕНДЕНЦИИ РОСТА СОЦИАЛЬНОГО ВОЗДЕЙСТВИЯ ПО
Рост спроса на ПО является следствием того, что по мере уде-
шевления, повышения надежности и увеличения объема производ-
ства ЭВМ автоматизация труда человека с помощью машины ста-
новится все более и более выгодной.
Эту тенденцию иллюстрирует рис. 3.3. На нем подытожены ре-
зультаты трех исследований [3, 38, 93] расширения масштабов ис-
пользования ЭВМ и увеличения социального влияния этого исполь-
зования. Самым поразительным выводом из этих исследований
является то, что в США к 1985 г. приблизительно 40% работаю-
щих будут в своей повседневной профессиональной деятельности
использовать ЭВМ и ПО, не обязательно зная, как эти средства
функционируют. Таким образом, эти 40% рабочей силы будут
неявно полагаться на результаты применения ПО ЭВМ.
Еще более глубокое воздействие ЭВМ и ПО оказывают на ча-
стную жизнь. С каждым днем все большая часть данных, относя-
щихся к личной жизни, банковским расчетам, коммунальным услу-
гам, управлению движением, воздушному сообщению, медицинско-
му обслуживанию и национальной безопасности, доверяется, хо-
телось бы надеяться, надежному и удобному функционированию
ЭВМ и ПО. Поэтому становится все труднее ограничивать потен-
32
циальную угрозу личному благосостоянию, которая возможна при
использовании ЭВМ в преступных целях [230], а также из-за на-
личия огромных банков данных [293, 304] и вычислительных си-
стем, заставляющих людей думать и действовать как машины
[90, 303].
Рис. 3.3. Расширение масштабов использования
ЭВМ и ПО
Такое возрастающее воздействие вычислительных систем на
благосостояние человека предъявляет несколько важнейших тре-
бований к инженерному программированию. Эти требования состо-
ят в необходимости разработки и сопровождения ПО, которое
гарантирует, что вычислительные системы являются:
исключительно надежными;
естественными;
удобными в использовании;
труднодоступными для злоупотребления;
проверяемыми;
оставляющими главную роль за человеком, а не за машиной.
Эти требования вместе с установленными выше требованиями
повышения экономичности разработки и сопровождения обуслов-
ливают обсуждаемые в следующем разделе цели инженерного про-
граммирования.
3.5. РАЗНООБРАЗИЕ ЦЕЛЕЙ
Было бы полезно сформулировать такую общую цель инженер-
ного программирования, достижение которой привело бы к удов-
летворению всех рассмотренных ранее требований. В подобной
ситуации (когда существует такая цель) обычно находится сту-
дент. Большинство контрольных и домашних заданий имеют еди-
ную, хорошо определенную шкалу оценок их выполнения, и оценка
за курс обычно определяется простой взвешенной суммой оценок
всех выполненных заданий.
„ , Г~>'£С. Г,УБ л: ЧНАЯ I
2 Зак. 628 J .4.a i 33
к несчастью (а по зрелому размышлению — к счастью), об-
ласть инженерного программирования не столь проста. Некоторые
из ранее рассмотренных требований противоречат друг другу, на-
пример высокая производительность труда при разработке ПО,
эффективность программы, высокая надежность, легкость исполь-
зования и сопровождения. Сосредоточив внимание на любом из
этих требований, невозможно, по-видимому, полностью удовлетво-
рить остальные.
3.6. ПРИМЕР ЭКСПЕРИМЕНТА [298]
Наглядный пример подобных противоречий между целями охарактеризован
данш • и табл. 3.1, в которой приведены результаты эксперимента, описанного
в [298]. В этом эксперименте пяти оригадам програм (истов было дано одно и то
Таблица 3.1
Оценки работы бригад программистов в зависимости
от поставленных целей и их осуществления (из [298])
Цель бригады — оптимизировать Оценки (1 — наилучшая, 5—наихудшая) по
затратам труда числу операторов программы объему требуемой памяти ЯСНОСТИ программы четкости выходных данных
Затраты труда Число операторов про- 1 4 4 5 3
граммы Объем требуемой памя- 2—3 1 2 3 5
ти 5 2 1 4 4
Ясность программы Четкость выходных дан- 4 3 3 2 2
ных 2—3 5 Ь 1 1
же задание по программированию. Однако перед разными бригадами были по-
ставлены разные цели. Первой бригаде было предложено закончить работу с наи-
меньшими затратами труда, второй — минимизировать число операторов в про-
грамме, третьей — минимизировать объем требуемой памяти, четвертой — разра-
ботать как можно более ясную программу и последней — разработать как можно
Золее четкое представление выходных данных программы.
Когда программы были завершены и оценены, получились весьма интересные
результаты:
каждая бригада заняла первое место (только четвертая бригада — второе) по
осуществлению поставленной перед ней цели;
ни одна из бригад не выполнила одинаково хорошо все задачи.
В частности, полезно обратить внимание на оценки первой бригады, которой
было предложено закончить работу с наименьшими затратами труда. Хотя эта
бригада заняла первое место по сокращению затрат труда и второе по производи-
тельности (ni ЧИСЛ5 разработанных за человеко-день строк программы), она была
предпоследней по числу операторов программы и объему требуемой памяти, пос-
ледней по ясности представления программы и третьей по четкости представления
результатов работы программы.
Важнейшие выводы из результатов эксперимента таковы.
1. Стремление к успеху является весьма сильным мотивом в деятельности
программистов. Если определить успех в терминах требуемого проектом резуль-
34
тата, то программисты, как правило, прилагают все усилия для получения этого
результата.
2. Различные цели инженерного программирования действительно противоре-
чат друг другу на практике. В частности, из характеристик разработки первой
бригады видно, что стремление любым способом уменьшить затраты труда и сро-
ки разработки ПО, по всей видимости, окажет неблагоприятное влияние на затра-
ты, сроки и эффективность всего жизненного цикла ПО вследствие того, что за
достигнутые результаты придется расплачиваться по другим статьям расходов
на ПО.
3. Для успешного применения инженерного программирования ко всему жиз-
ненному циклу ПО необходимо непрерывное разрешение противоречий между
существенными целями.
3.7. РАЗНООБРАЗИЕ СРЕДСТВ ИНЖЕНЕРНОГО ПРОГРАММИРОВАНИЯ
Как при рассмотрении целей инженерного программирования
было бы полезно сформулировать единую цель, так было бы по-
лезно предложить единое правило (например, «Необходимо про-
граммировать без GOTO»), следуя которому можно было бы
удовлетворить одновременно всем указанным ранее целям и тре-
бованиям к разработке ПО. И снова, к (не) счастью, область ПО
оказывается не столь простой.
Фактически, ситуация более похожа на ту, которая представ-
лена на рис. 3.4. Инженера-программиста засыпают различными
советами: разрабатывай сверху — вниз, доказывай правильность
программ, разрабатывай извне — вовнутрь, используй независимые
верификацию и подтверждение, разрабатывай дважды и т. д.
Каждый из этих советов способствует выполнению определенных
требований, но никак не учитывает другие и фактически препятст-
вует их удовлетворению.
Например, доказательство правильности программ весьма спо-
собствует увеличению надежности, но нисколько не облегчает
использование ПО людьми и (по крайней мере, при существующей
технологии) часто тормозит увеличение производительности труда
на этапах жизненного цикла ПО *. В качестве другого примера
можно привести метод повторной разработки, который при работе
в незнакомых условиях обеспечивает более полное удовлетворение
запросов пользователей и увеличивает эффективность применения
системы: первая попытка дает практический опыт, в результате
чего вторая попытка оказывается гораздо более успешной. Однако
в уже знакомой ситуации этот подход будет, как правило, приво-
дить к непроизводительной трате времени программистов и сво-
дить на нет творческий элемент в их работе.
Таким образом, наиболее важным в инженерном программи-
ровании является знание методов достижения разнообразных, воз-
можно, противоречащих друг другу целей и согласования разнооб-
1 Это особенно верно в быстро изменяющихся ситуациях, когда модифициро-
ванная версия ПО должна быть разработана до завершения доказательства пра-
вильности программ первоначальной версии. В таких ситуациях становится бес-
полезной большая часть усилий по доказательству правильности устаревших
программ.
2*
35
Выбирайте правила разработки ПО
Разрабатывайте
дважды
Тщательно планируйте испытания
Разрабатывайте *4*1ц
извне-вовнутрь
/
о° Стандартизируйте
.лу программирование
3Ът,
Доказывайте
правильность
программ
П₽Ов°ДИге
авИсимь,е
Используйте подход
бригады главного
лрограм миста 'е
Заблаговременно оформляйте требования oe^
Программируйте
структурно
Используйте
инструментальные
средства
X
X
ч
Используйте
стандартную процедуру
заключения договоров
Используйте бланки при разработке отдельных компонентов
Привлекайте к работе,
пользователя
Рис. 3.4. Советы по разработке ПО
разных применяемых средств, каждое из которых в зависимости
от ситуации в различной степени помигает или мешает достиже-
нию конкретной цели *.
Обсуждаемые в следующих двух разделах иерархическая
структура целей инженерного программирования и ЦОП лежат
1 По крайней мере, автор пришел к такому выводу, затратив много усилий
на попытки доказать ложность этого утверждения путем формулирования еди-
ного принципа (например, принципа опережающей разработки ПО), который
помог бы решить все проблемы инженерного программирования. Каждая из этих
попыток была ~эбезно, но убедительно опровергнута коллегами, указавшими си-
туации, в ко-орых соответствующий принцип оказывался либо недостаточно об-
щим для применения, либо слишком общим для обеспечения полезного руковод-
ства г. действию в конкретном случае.
36
в основе этих знаний. В остальной части книги будет рассмотрено
применение экономических методов в инженерном проектировании
ПО.
3.8. СТРУКТУРА ЦЕЛЕЙ ИНЖЕНЕРНОГО ПРОГРАММИРОВАНИЯ
На рис. 3.5 представлена иерархическая структура целей инже-
нерного программирования. Из рисунка видно, что эффективность
инженерного программирования основывается на осуществлении
двух основных подцелей:
1) получении качественного программного изделия;
2) реализации эффективного процесса разработки и сопровож-
дения ПО.
Каждая из этих подцелей состоит из следующий трех компонентов:'
а) учет человеческих факторов;
б) управление ресурсами;
в) программотехника.
Следует помнить, что эффективность инженерного программи-
рования обеспечивается согласованием всех подцелей как для
программного изделия, так и для процесса его разработки. Ниже
рассматриваются определения подцелей, которые указаны в иерар-
хической, структуре.
Качество программного изделия. Учет человеческих факторов.
Легкость использования означает такую разработку документации, средств
управления, структур и форматов входных и выходных данных, которая делает
программное изделие удобным, естественным, гибким и простым для пользова-
теля
Удовлетворение потребностей пользователей означает учет тех их требова-
ний относительно информации или вычислительных средств (билеты, чеки для
оплаты, бланки, процедуры), для выполнения которых предназначено программ-
ное изделие.
Реализация потенциальных способностей пользователя означает обеспечение
более творческо! о характера труда и большего удовлетворения своей работой
пользователей, эксплуатирующих программное изделие.
Следование модифицированному золотому правилу. Это правило гласит'
«Относитесь к другим людям так же, как Вы хотели бы, чтобы относились к Вам,
будь Вы на месте этих людей». В инженерном программировании одной из
самых больших ошибок является следование (но с весьма неудовлетворительными
результатами) немодифицированному золотому правилу.
Относитесь к другим людям, как Вы Разрабатывайте вычислительные си-
хотели бы, чтобы относились к Вам. стемы, с которыми будут работать
пользователи и операторы, предпола-
гая, что они любят программировать
и весьма сведущи в вычислительной
науке
В области системного ПО (компиляторы, операционные системы и т. п.), которая
в значительной степени является сферой деятельности университетских кафедр
вычислительной науки (предположение в правом столбце), это вполне допустимо.
Действительно, пользователями компиляторов и операционных систеь. являются
программисты, которые любят программировать и весьма сзедущи в вычислитель-
ной науке. Однако указанное предположение совершенно неверно в области при-
кладного ПО В этой области типичными пользователями и операторами являются
пилоты самолетов, служащие различных магазинов, врачи, кассиры в банке и
37
Человеческие
факторы
Управление
ресурсами
Программотехника
Человеческие
факторы
Управление
ресурсами
Программо-
техника
Легкость
использования
Удовлетворение
потребностей
пользователя
Реализация
_ потенциальных
способностей
пользователя
Следование
— модифицированному
золотому правилу
-Эффективность
Сбалансированность
-Измеряемое™
-Специфицированное™:
полнота
безопасность
непротиворечивость
осуществимость
проверяемость
—Правильность
. А да пти руемость:
стру ктурирован ность
независимость
понятность
— П ланируемость
-Организованность
.-Укомплектованность
штатов
—Руководимое™
—Контролируемость
—Автоматизируемое™
—Следование
модифицированному
золотому правилу
_ Анализируемое™
эффективности
затрат
—Планируемое™
Оцениваемость
—Контролируемость
Выполняемое™
сроков и бюджета
-Осуществимость
П одтверждаемость
Полнота и
—непротивореч ивость
требований
П одтверждаемость
-Проектируемое™
изделия
ВП
-П рограммируемость
ВП
-КомплексИруемость
ВП
-Внедряемое™
ВП
- Сопровождаемость
ВП
Рис. 3.5. Структура целей инженерного программирования
-Снимаемость
-Управляемость
конфигурацией
диспетчер!" пожарной службы. Они, как правило, недостаточно сведущи в прог-
раммировании и в вычислительной науке и при использовании разработанных
для них систем гораздо больше озабочены надежным управленгем самолетов,
удовлетворением запросов покупателей и быстрым излечением своих пациентов,
че : изучением вычислительной науки. Для успешного выполнения модифицирован-
ного золотого правила необходимы хорошее понимание практических навыков
пользователей, их запросов и функций и учет этого понимания при разработке
форматов входных и выходных данных, документации и средств обращения к про-
граммной системе.
Качество программного изделия. Управление ресурсами.
Эффективность означает, что программное изделие выполняет свои функции
без излишних затрат ресурсов. К ресурсам относятся все средства, запасы и дру-
гие величины, объем которых ограничен: денежные ресурсы, время разработки,
машинное время, оперативная память ЭВМ, пропускная способность канала пере-
дачи данных и т. п.
Измеряемость означает, что программное изделие можно легко оснастить
(контрольно-измерительными средствами и замерить его характеристики для опре-
деления хузких мест» и неэффективности ПО, а также можно легко модифициро-
вать эти средства или настроить их для учета изменений.
Качество программного изделия. Программотехника.
Специфицированность означает, что до начала программной разработки тща-
тельно и недвусмысленно специфицированы функциональные, технические и ин-
терфейсные требования на программное изделие. Это вовсе не обязывает разра-
ботчиков воздерживаться от программирования до полного окончания специфи-
кации требований. Основными характеристиками специфицированности являются
следующие.
I. Полнота. Спецификация является полной, если в ней присутствуют все
необходимые части, и каждая часть разработана надлежащим образом.
2. Безопасность. Спецификация учитывает требования безопасности, если
в ней четко определено функционирование ПО для всех нештатных условий. Кон-
структивным методом достижения безопасности является предложенный в [86]
подход, основанный на преобразовании предикатов
3. Непротиворечивость. Спецификация непротиворечива, если ее положения
не противоречат друг другу или другим главным спецификациям или целям.
4. Осуществимость. Спецификация осуществима, если в течение всего жиз-
ненного цикла специфицированной системы прибыль превосходят затраты на ее
разработку.
5. Проверяемость. Спецификация проверяема, если разработанное ПО может
быть подвергнуто проверке на соответствие положениям этой спецификации.
6. Правильность означает, что ПО строго соответствует всем функциональ-
ным и интерфейсным спецификациям, а также удовлетворяет в пределах допус-
ков всем с.гецификациям технических характеристик
7. Адаптируемость означает, что программное изделие или его компоненты
можно легко использовать или приспосооить для выполнения новых функций.
Адаптируемость включает в себя:
модифицируемость — изделие способствует простоте внесения изменений;
пе реноси-ош — изделие может легко и хорошо эксплуатироваться в новых
конфигурациях ЭВМ;
работоспособность в других системах — изделие или его компоненты могут
использоваться в качестве компонентов других систем.
uc.ni шь ми характеристиками адаптируемости являются следующие.
1) Структурированность. Программное изделие структурировано, если оно
построено по следующим принципам.
Абстракция Изделие организовано в виде иерархии «уровней абстракции»,
как»д из которых не содержит информации о свойствах нижних уровней и
скрывает информации о своих внутренних свойствах от более высоких уровней.
Модульность. Изделие составлено из небольших и независимых модулей,
каждый из котэршх состоит из сильно связанных между собой частей.
Минимальное число примитивов. Число видов компонентов, из которых по-
кроено изделие, минимально (например, в качестве управляющих структур ис-
39
пользуются только составные операторы: if-then-else, case, do-while, do-until и
undo). Следует отметить, что принципы структурированности относятся не только
к программам, но и к данным и документации.
2) Независимость. Программное изделие независимо, если на его работу не
влияют изменения в устройствах, используемых при его функционировании (на-
пример, изменения в операционных системах и системах, управления базами дан-
ных) .
3) Понятность. Программное изделие является понятным, если его назначе-
ние и функционирование ясны тем специалистам, которые должны с ними рабо-
тать.
Эффективность процесса разработки ПО. Рассмотренные выше цели характе-
ризуют жепаемг е свойства программного изделия. Цели процесса разработки и
сопровождения ПО заключаются в выполнении ряда операций в течение жизнен-
ного цикла ПО (иногда параллельно, иногда последовательно). Как и в случае
обеспечения необходимого качества программного изделия, достижение эффектив-
ности процесса разработки ПО требует согласования целей с человеческими фак-
торами (поощрение успешной работы, повышение квалификации), управлением
ресурсами (сокращение затрат на разработку и сопровождение), а также с осо-
бенностями программотехники (разработка четкой и обоснованной спецификации
требований, четкая проверка ппоекта изделия и т. п.).
Эффем звность процесса разработки ПО. Учет человеческих фак оров. В этом
случае целью учета человеческих факторов является такое управление занятыми
в процессе сотрудниками, которое позволит удовлетворить их запросы и реализо-
вать их творческий потенциал.
Планируемость предполагает разработку и непрерывное поддержание в ра-
бочем состоянии плана проектирования изделия. В.плане указываются:
причины, по которым предпринята разработка проекта;
результаты, ожидаемые от проекта;
сроки достижения результатов;
ответственные за достижение результатов;
способы достижения рез' льтатог;
необходимые ресурсы;
предположения, на основе которых должны быть получены результаты.
Организованность предполагает разработку и непрерывное поддержание не-
которой структуры должностей и обязанностей. Главными элементами организо-
ванности являются:
передача прав и ответственности подчиненному;
разделение труда.
Некоторые принцш ы организованности аналогичны принципам структуриро-
ванности программного изделия (наприме!, модульность и скрытность информа-
ции). Это выражено в законе Конвея [68]: «Структура программного изделия
однозначно соответствует структуре разработавшей его организации».
Укомплектованность штатов предполагает подбор, набор и закреплезие спе-
циалистов. При этой руководитель обычно озабочен согласованием двух различ
ных жизненных циклов: жизненного цикла программного изделия и жизненного
цикла или продвижения по службе каждого сотрудника. Такое согласование часто
предполагает, что некоторые цели проекта приносят п жертву долгосрочным целям
продвижения по службе сотрудников, участзующих в разработке.
Руководимое™ предполагает качественное выполнение следующих дейст-
вий:
мотивации — создания и поддержания интереса и стимулов, которые побуж-
дают людей прилагать все усилия для успеха проекта;
организации общения — создания и поддержания необходимых сведений
о проекте и его окружении для участников проекта;
руководства сотрудниками — улучшения понимания факторов, обеспечивав
щих мотивацию и учет их в решениях руководства.
Контролируемость предполагает сравнение результатов проектирования
с установленными целями и планами, исправление отклонений в разработках.
Автоматизируемое™ предполагает использование ЭВМ для освобождения
разработчиков от ручной работы
40
Использование модифицированного золотого привили предполагает установ-
ление одинакового отношения к проекту исполнителя и руководителя.
Эффективность процесса разработки ПО.
Управление ресурсами. Анализируемое™ эффективности затрат предпола-
гает обеспечение тщательного анализа затрат и ресурсов для всех возможных
подходов к проектированию при выборе оптимального проекта.
Планируемость и контролируемость предполагают составление и контроль
графиков выполнения проекта и планов координации ресурсов Важность этой
подцели подчеркивается примером. Проверки в США в период с 1965 г. по 1976 г.
показали, что недостатки планирования и контроля были более крупными псточ-
[никами проблем, чем технологические факторы. По результатам более чем 50 %
проверок существенные проблемы являлись следствием плохого планирования,
в 34 % проверок — следствием недостатков контроля проекта, только в 15 % —
следствием технологических факторов.
Эффективность процесса разработки ПО. Программотехника. Восемь главных
последовательных подцелей таковы.
1. Осуществимость предполагает формулировку предпочтительного замысла
функционирования программного изделия, установление реализуемости проекта
с учетом всего жизненного цикла и определение его преимущества по сравнению
с другими предложениями.
2. Полнота и непротиворечивость требований предполагает разработку спе-
цификаций функций, интерфейсов и технических характеристик программного
ИЗДС...1Я.
3. Проектиру емость изделия предполагает разработку спецификаций пол-
ной аппаратно программной архитектуры, структур управления и данных из-
делия.
4. Программируемость, т. е. возможность разработки полного набора про-
граммных компонентов.
5. Комплексируемость, т. е. возможность получения правильно функциони-
рующего программного изделия из отдельных компонентов.
6. Внедряемое™, т. е. возможность получения функционирующей в полном
объеме производственной аппаратно-программной системы, запуск ее в произ-
водство и налаживание обучения пользователей
7. Сопровождаемость, т. е. возможность получения функционирующей в пол
ном объеме модификации аппаратно-программной системы.
8. Снимаемость предполагает планомерную передачу функций изделия его
преемнику
Кроме того, в структуре целей рассматриваются следующие подцели.
Верификация и подтверждение (ВП) определяются следующим образом:
верификация — установление соответствия изделия его спецификации;
подтверждение—установление пригодности или соответствия изделия его
производственному назначению.
. Или неформально: верификация — это установление правильности построения
изделия, а подтверждение — это установление необходимости построения изделия
и его полезности.
Управляемость конфигурацией прогоаммного изделия предполагает, что
в любой момент проектирования можно представить его полную версию пли базо-
вые версии, процесс разработки которых проходит следующим образом [289].
1. Разрабатывается начальная версия изделия.
2. Начальная версия верифицируется, подтверждается, а при необходимо-
сти — дорабатывается.
3. В результате формального анализа устанавливается, находится ли изделие
в состоянии, удовлетворительном для того, чтобы можно было перейти к следую-
щей фазе. Если нет, то процесс продолжается с шага 1.
4. При удовлетворительных характеристиках изделия оно идентифицируется
как базовая версия (подлежащая формальному контролю изменений).
Базовые версии имеют три главных достоинства:
1) никакие изменения не производятся без согласия всех заинтересованных
сторон;
41
2) наложение ограничений на изменения стабилизирует изделие;
3) сотрудник, ответственный за управление конфигурацией, в любой момеш
имеет полную версию изделия.
3.9. ЦЕЛЕОРИЕНТИРОВАННЫЙ ПОДХОД В ИНЖЕНЕРНОМ
ПРОГРАММИРОВАНИИ
Целеориентированный подход (ЦОП) основан на использова-
нии представленной на рис. 3.5 структуры при спецификации, раз-
работке и сопровождении ПО. Структура ЦОП была проиллюст
рирована на рис. 3.1, а более конкретная пошаговая процедура
представлена на рис. 3.2.
На рис. 3.1 и в табл. 3.2 ЦОП сформулирован несколько абст-
рактно. Чтобы лучше освоить практические возможности этого
подхода, надо рассмотреть примеры шагов, приведенных в табл. 3.3
и иллюстрирующих четыре цели на материале гл. 1 и 2 книги.
Осуществленный к концу шага 4 набор подцелей состоит из под-
целей проектирования изделия, планирования испытаний всего из-
делия, написания предварительных руководств для пользователей
и составления плана разработки.
Таблица 3.2.
Целеориентированный подход в инженерном программировании
1. Определить главные цели, которые необходимо достичь в результате
создания программного изделия и в самом процессе проектирования ПО.
2. По иерархической структуре целей проконтролировать, все ли главные
цели учтены.
3. Определить средства достижения поставленных целей. Для этого необхо-
димо составить план, в котором необходимо указать:
кто ответственен за достижение целей;
когда и где будет достигнута каждая цель;
как будет достигнута каждая цель, подцели и какова последовательность
их выполнения;
какие предположения должны выполняться для достижения целей.
4. Добиться выполнения плановых подцелей процесса разработки (или на-
бора подцелей, если некоторые из них выполняются параллельно)
5. Проверить соответствие состояния изделия и процесса разработки целям
и подцелям.
6. При необходимости доработать цели и планы.
7. В порядке следования подцелей выполнять шаги 4—6 табл. 3.3, пока
разработка не будет завершена.
8. Независимо от приведенных выше шагов периодически проверять ход
разработки, учитывая структуру целей и подцелей. При необходимости дораба-
тывать цели и планы.
Из шага 5 табл. 3.3 можно увидеть некоторые типичные резуль-
таты анализа осуществления целей изделия и процесса его разра-
ботки. Так, анализ целей руководства журнала «Scientific Ameri
сап», показал бы, что предложенный проект не приводит к умень
шению стоимости обработки подписки, а анализ целей системы
учета посещаемости городских школ показал бы, что предложен-
ный проект не улучшает условий работы служащих.
42
Таблице 3.3
Примеры использования ЦОП
Шаг Пели изделия Цели процесса разработки
Количественные (см. гл. 1) Качественные (см. гл. 2) Количественные (см. гл. 1) Качественные (см. гл. 2)
1. Определить цель
2. Определить средства
достижения целей
4. Завершить осуществ
ление следующей подце
ли
5. Проверить осуществ-
ление предыдущих целей
и завершить осушествле
вие следующей подцели
6. Доработать цели и
планы
7. Проверить учет струк-
туры целей
Уменьшить стоимость
обработки подписки в
расчете на одну опера-
цию на 25%
Автоматизация состав
ления табуляграмм
Разработать общую
структуру программы
1'лавные затраты идут
на предварительную об-
работку, автоматиза-
ция увеличит издержки
Проанализировать и пе-
репроектировать схемы
обработки данных вруч-
ную и на машине
Проверить планы пере-
вода служащих, поте-
рявших место
Улучшить условия
работы служащих
Автоматизация обра-
ботки данных о посе-
щаемости
Составить проект
эффективной обра-
ботки данных
Вместо улучшения
условий работы лик-
видируются рабочие
места
Пополнить функцию
бюро учета посещае-
мости, например
функциями консуль-
тирования
Проверить реали-
стичность сметы те-
кущих затрат
Разработать ПО за
12 месяцев
Детализация сроков
разработки, сетевых
графиков
Завершить проект из-
делия
Проверить правиль-
ность сроков, завер-
шить разработки ос-
новных компонентов
Доработать пункты
плана испытаний
Проверить, верны ли
сведения о том, что
ведущие разработчи-
ки недовольны и го-
товы подать заявле-
ния об уходе
Разработать план про-
фессионального обуче-
ния контролеров
Последовательное обу-
чение, назначение работ
Завершить проект изде-
лия
Проверить готовность
контролеров и характе-
ристик процесса; опре-
делить исполнителей, не
знающих методов конт-
роля
Обеспечить помощь и
обучение на рабочем ме-
сте при подготовке сете-
вых графиков'
Проанализировать вме-
сте с контролерами ход
разработки и профессио-
нального обучения
Целеориентированный подход является разновидностью целево-
го управления [96] с набором целей, представленных в структуре
на рис. 3.5. Поэтому ЦОП имеет следующие достоинства:
установление явной персональной ответственности за достиже-
ние целей изделия и процесса разработки;
обеспечение схемы проверки полноты целей;
установление хорошо документируемой последовательности
подцелей для достижения целей;
обеспечение заблаговременного предупреждения о трудностях
достижения некоторых целей;
обеспечение возможностей согласования количественных и ка-
чественных целей.
В заключение следует отметить, что для процесса разработки
ПО набор подцелей программирования отличается от других на-
боров тем, что они должны рассматриваться поочередно. Эти под-
цели представляют основные вехи жизненного цикла ПО, который
будет рассмотрен в следующей части книги.
ЧАСТЬ 2
КОЛИЧЕСТВЕННАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ПО
В этой части книги обсуждается ЖЦПО от самых первых фаз, на которых
исследуют осуществимость программного изделия, до прекращения использования
данного программного изделия или снятия его с производства. Жизненный цикл
представлен количественно с указанием затрат труда и сроков завершения каж-
дой фазы.
Количественные соотношения жизненного цикла представлены в виде упоря-
доченной иерархии моделей оценок стоимости ПО, имеющих общее название
КОМОСТ. Вначале будет рассмотрена простейшая модель, базовая КОМОСТ,
в которой оценки затрат зависят только от размера программного изделия Затем
будет обсуждена промежуточная модель, в которой оценка затрат является функ-
цией не только размера, но и других наиболее важных стоимостных факторов.
В роли этих факторов выступают различные атрибуты 1 изделия (например,
сложность и требуемая надежность), ЭВМ (например, ограничения по быстродей-
ствию и оперативной памяти), исполнителей (например, квалификация и опыт
работы в данной предметной области или с аналогичными вычислительными си-
стемами) и проекта (например, ограничение сроков разработки и использование
инструментальных средств). (Позднее, в ч. 4 этой книги будет рассмотрена еще
более детальная и точная модель, в которой учитывается влияние всех таких ат-
рибутов на каждую фазу жизненного цикла. При этом будут обсуждены также
данные практических разработок, лежащие в основе всех соотношений КОМОСТ,
которые применяются для оценивания затрат, и использованные для общей кор-
ректировки этой модели.)
Значение оценки стоимости ПО. Причиной большого внимания, уделяемого
оценке стоимости ПО, является то, что такая оценка обеспечивает крайне необхо-
димую связь понятий и методов экономического анализа с инженерным програм-
мированием. Ведь совершенно бесполезно выполнять анализ затрат и результатов
внедрения, безубыточности или целесообразности собственного производства или
закупки изделия, если отсутствует какой-нибудь достаточно точный метод оцени-
вания стоимости ПО и степени зависимости ее от различных атрибутов изделия,
проекта и условий разработки.
Методы оценивания затрат важны также потому, что они лежат в основе
эффективной организации производства ПО. Отсутствие приемлемо точных
средств оценивания затрат часто приводит к следующим проблемам при осущест-
влении программных проектов.
1. Разработчик ПО не в состоянии привести руководителю, заказчику или
специалисту по сбыту достаточно обоснованные доказательства нереалистичности
предложенных бюджета и сроков. Это приводит к оптимистической переоценке
выгод собственной программной разработки, недооценке роли других конку-
рирующих предложений о заключении контрактов на разработку ПО и вследствие
всего этого — к неизбежным перерасходам и ухудшению качества ПО.
2. Аналитики при проектировании системы не в состоянии выполнить доста-
точно обоснованный реалистический анализ компромиссов аппаратно-программных
1 Атрибут — необходимое, существенное, неотъемлемое свойство объекта
(в частности, программного изделия или процесса разработки ПО). Это свой-
ство поддается градации для учитываемого фактора, аЛияющего в данном слу-
чае на стоимость объекта. — Прим. ред.
45
решений. Это часто приводит к появлению проектов, в которых затраты на аппа-
ратуру уменьшены за счет более значительного увеличения затрат на ПО.
3. Руководители проекта не в состоянии достаточно обоснованно определить,
сколько времени и затрат труда потребуется на каждую фазу и работу программ-
ной части проекта. Следовательно, они не в состоянии определить, насколько
успешно выполняется план разработки ПО. Это, как правило, означает, что
программная часть проекта с самого начала выходит из-под контроля.
Пример. Перечисленные проблемы наглядно проявились в одном проекте [84],
проиллюстрированном на рис. Б, где показано изменение оценок затрат на ПО и
фактических затрат на жизненный цикл реализованного для ВВС США программ-
ного проекта по созданию оперативной систем!’ управления. Указание конкрет-
ных проекта и заказчика не умаляют значения рассматриваемого примера, по-
скольку история разработки этого проекта типична и для многих других проектов
(государственных или частных) во всем мире. Единственным отличием является.
Числе месяцев, прошедших после заключения
контракта на разработку
Рис. Б. Пример изменения затрат на программ-
ный проект
возможно, то, что в данном примере выполнение проекта было тщательнее задо-
кументировано и проанализировано для устранения в будущем аналогичных
проблем.
Первоначальная оценка затрат на программную разработку равнялась при-
мерно 1500 тыс долл. После конкурса «лучших и окончательных» решений оценка
победившей фирмы составила приблизительно 400 тыс долл., причем основыва-
лась эта оценка скорее на оптимистических допущениях и заявлениях, чем на
каком-нибудь здравом подходе к оцениванию затрат.
В ходе последующего выполнения проекта разработчики несколько раз — по-
следовательно на уровнях 400, 700, 2500 и 3200 тыс. долл. — оказывались в ситуа-
ции, когда данный бюджет был уже исчерпан, но проект не был еще закончен.
Каждый раз при этом согласовывалось увеличение расходов и сроков, в резуль-
тате чего в конечном счете полные затраты на проект составили приблизительно
3700 тыс. долл., т. е. почти в 10 раз больше первонача пьноч оптимистической
оценки (даже на последних этапах проекта оценки затрат на его окончание
были весьма неточными).
«Согласование увеличения расходов и сроков» звучит как стандартная произ-
водственная процедура, однако на самом деле означает, что создалась весьма
46
тяжелая и неприятная ситуация, с которой все соприкоснувшиеся никогда не хо-
тели бы иметь дела. Некоторые аспекты этой ситуации таковы
1. Пользователи уже запланировали замену существующего процесса, что
влечет за собой: распределение исполнителей, заказ нового оборудования, пре-
кращение прежних поставок, включение новых операций в используемый у них
общий производственный процесс. Они не захотят повторять эту работу еще раз.
2. Разработчики ПО вынуждены работать более напряженно, чтобы спра-
виться с трудностями, возникшими не по их вине.
3. Необходимо решить, откуда взять средства на спасение проекта. Иногда
эти средства поступают из прибылей или налоговых отчислений корпорации, и
сотрудников, не обеспечивших достижения финансовых целей, увольняют Иногда
средства поступают из других бюджетов (например, бюджетов на исследования,
обучение и командировки), что плохо влияет на микроклимат в коллективе и его
будущий научно-технический потенциал.
4. Приходится задерживать сроки осуществления других проектов, в которых
запланировано использование сотрудников данного проекта. Тем самым не только
срываются сроки выполнения этих проектов, но и уменьшается их эффективность
и часто создается «эффект домино», распространяющийся на новые проекты.
Все указанные обстоятельства приводят к разочарованию и вражде в коллек-
тиве, а иногда к предъявлению судебных исков против участников проекта. Боль-
шей части этих последствий можно избежать, используя достаточно точные мето-
ды оценивания затрат на ПО и управления.затратами и проектом, причем указан-
ные методы обеспечат также весьма эффективную основу для успешного заверше-
ния проекта и для получения людьми удовлетворения от своей работы.
Точность моделирования стоимости ПО. Следует обратить особое внимание
на выражение «достаточно точный», использованное ранее при описании средств
оценивания стоимости ПО. Важно признать, что затраты' на производство
100 000 команд не удается оценить столь же точно, как затраты на производство
100 000 таблеток аспирина, 100 000 бутылок кетчупа или 100 000 радиоприемни-
ков. Это объясняется многими причинами, из них наиболее важными являются
следующие-
исходные команды различны и по отдельности не определяют конечное изде-
лие;
производство ПО требует творчества и сотрудничества людей, индивидуаль-
ное и групповое поведение которых, как правило, трудно предсказать;
в области производства ПО накоплен гораздо меньший опыт количественных
оценок и его трудно увеличить, проводя небольшие эксперименты.
По этим и другим причинам может показаться удивительным, что существу-
ют сколько-нибудь полезные средства оценивания затрат на ПО. Однако за по-
следние несколько лет ряд ценных исследований и работ по сбору данных зало-
жили основы для некоторых моделей стоимости, которые (опять используя
обсуждаемое выражение) обладают достаточной точностью.
Современная модель оценки стоимости ПО считается хорошей, если с ее по-
мощью можно оценить затраты на программную разработку с точностью 20 %
в 70% случаев, причем при условии использования модели, так сказать, «на
своем поле» (т. е. в классе проектов, на которые она настроена) *. В настоящее
время промежуточная и детальная КОМОСТ работают примерно так же хорошо
(с точностью 20 % от фактических затрат в 68 ... 70 % случаев) в широкой
области применений, определенной выборкой из 63 завершенных проектов разра-
ботки ПО для экономики, управления и человеко-машинных систем, а также
научного, вспомогательного и системного ПО. Модель не столь точна, как хоте-
лось бы, но достаточно точна, чтобы весьма существенно помочь при экономиче-
ском анализе и принятии решений в инженерном программировании.
1 Это означает, что оценки, полученные с помощью этой модели, часто будут
сильно ухудшаться при ее использовании вне той области, на которую она на-
строена. Этот недостаток проявился в двух ранних версиях КОМОСТ, что потре-
бовало дальнейшей доработки модели для учета расхождений и расширения об-
ласти применения КОМОСТ.
47
Краткое содержание части 2. 3 гл. 4 обоснованы определения фаз и работ
ЖЦПО, знание которых необходимо для правильного использования полученных
в КОМОСТ оценок затрат на ПО. Кроме того, в этой главе экономически обосно-
вываются как предпочтительность упорядочения фаз ЖЦПО в виде классической
каскадной модели программной разработки, так и условия, при которых экономи-
чески целесообразно отходить от этой модели.
В гл. 5 представлена простая модель — базовая КОМОСТ — для оценивания
стоимости и сроков программных проектов наиболее распространенного типа, для
оценивания распределения затрат и сроков по фазам, а также для оценивания
годовых затрат на сопровождение В гл. 6 базовая КОМОСТ расширена с целью
учета всех трех типов программа к проектов и обсуждена точность модели по
отношению к базе данных КОМОСТ, состоящей из данных по 63 завершенным
программным проектам (точность оказывается достаточной для приближенных
оценок, но недостаточной для согласования окончательного бюджета или для де-
тального планирования проекта). В гл. 7 показано применение КОМОСТ для оце-
нивал! распределения затрат между глазными работами проекта для каждой
фазы ЖЦ1IO В этой главе показано также, как эти распределения можно ис-
пользовать при составлении первоначальных организационных структур для раз-
личных фаз проекта.
В гл. 8 представлен следующий уровень иерархии моделей — промежуточная
КОМОСТ — которая учитывает влияние на стоимость ПО не только размера про-
граммного изделия, но и ряда других атрибутов изделия, ЭВМ, исполнителей и
проекта. Промежуточная КОМОСТ охватывает также важный случай оценивания
затрат на адаптацию существующего ПО для использования в новом изделии.
Кроме того, в гл. 8 исследованг также точность промежуточной КОМОСТ по
отношзнию к базе данных КОМОСТ (точность оказывается достаточной для боль-
шинства работ по согласованию окончательного бюджета или дез ального плани-
рования проекта). В гл. 9 показано, что промежуточная КОМОСТ может быть
использована не только как макромодель (для получения оценки на уровне всего
изделия), но и как микромодель (для получения оценки на уровне отдельных
компонентов), и приведено несколько примеров, включая пример системы обра-
ботки сообщений (которая будет использована как основной пример в ч. 3
книги).
ГЛАВА 4
ФАЗЫ И РАБОТЫ ЖИЗНЕННОГО ЦИКЛА ПО
4.1. ВВЕДЕНИЕ
В этой главе даны определения основных фаз и работ ЖЦПО.
Вначале представлена «каскадная» модель программной разра-
ботки, основанная на структуре целей инженерного программиро-
вания (см. рис. 3 5). Наряду с этим дано экономическое обоснова-
ние упорядочивания фаз. Затем обсуждаются различные усовер-
шенствования идеальной каскадной модели с использованием та-
ких концепций, как пошаговая разработка прототипа, инструмен-
тальное ПО и предварительная документация. В конце главы при-
ведены подробные определения конечных целей всех фаз и работ,
выполняемых на каждой фазе.
18
4.2. КАСКАДНАЯ МОДЕЛЬ
Каскадная модель ЖЦПО представлена на рис. 4.1. Первона-
чальная версия ее была представлена в [258] и подсказана раз-
личными публикациями ВВС США и промышленности [5, 257].
Главные характерные черты каскадной модели следующие:
завершение каждой фазы верификацией и подтверждением
(ВП), цель которых — устранить возможно большее число проб-
лем, связанных с разработкой изделия;
49
циклическое повторение реализованных фаз с возможно более
ранней фазы.
В каскадной модели успешное окончание одной из фаз ЖЦПО
означает достижение соответствующей цели (см. рис. 3.5) инже-
нерного программирования. Заметим, что помимо указанных на
рис. 3.5 подцелей необходимо определить еще две:
Детальная проектируемость— получение полных верифициро-
ванных спецификаций и структур управления и данных, интер-
фейсных связей, характеристик, основных алгоритмов и определе-
ние условий работы каждого программного компонента (подпро-
граммы, состоящей менее чем из 100 исходных команд).
Кодируемость — получение полного верифицированного набора
компонентов программы.
Достижение последовательных1 подцелей тесно связано с та-
кими подцелями, как верификация и подтверждение, а также уп-
равление конфигурацией, которые должны быть достигнуты на
каждой фазе ЖЦПО.
4.3. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ КАСКАДНОЙ МОДЕЛИ
Экономическое обоснование каскадной модели, ориентирован-
ной на последовательное достижение целей, базируется на двух
главных предпосылках:
1. Для получения качественного2 программного изделия необ-
ходимо в любом случае осуществить все подцели на каждом этапе.
2. Любое другое упорядочивание подцелей приводит к созда-
нию менее качественного программного изделия.
Предпосылка 1: необходимость осуществления всех подцелей
процесса разработки. Несомненно, что осуществление подцели ко-
дируемостч и всех последующих подцелей (кроме снимаемости)
необходимо для получения любого функционирующего изделия.
Основной вопрос состоит в том, необходимы ли предыдущие под-
цели (осуществимость, полнота и непротиворечивость требований,
проектируемость изделия и детальная проектируемость). В случае
многих небольших и простых программных изделий можно полу-
чить приемлемый результат, уделяя относительно мало внимания
ранним подцелям, поскольку разработчик и так четко понимает
запросы пользователя и все последствия решения легко предска-
зуемы. Однако подобный неформальный подход часто ведет к
весьма неприемлемым результатам, которые обычно можно пред-
видеть и избежать при тщательном выполнении более ранних под-
целей.
1 Указание на чисто последовательное достижение целей является удобным
упрощением. Существуют ситуации, в которых экономически целесообразно изме-
нить последовательность достижения целей, например при изготовлении прототипа
(см. разд. 4.3), в пошаговой разработке (см. разд. 4 4) и в предварительной под-
готовке (см. разд. 4.5).
2 Качественное программное изделие — изделие, в полной мере удоглетвопяю
щее всем целям требуемого программного изделия (см. рис. 3.5).
50
Рис. 4.2. Увеличение стоимости исправления или изменения ПО в течение
ЖНПО
В крупных и сложных проектах недостаточное внимание к бо-
лее ранним подцелям почти всегда приводило к серьезным недо-
статкам программного изделия и процесса его разработки. Это ил-
люстрируется следующими примерами:
1) в двух больших оперативных системах управления из-за их
несоответствия требованиям пользователя объем доработок соста-
вил 67 и 95% соответственно [38];
2) из-за пренебрежения анализом требований и предваритель-
ным анализом осуществимости были полностью прекращены мно-
гие проекты. К наиболее дорогим из таких проектов относятся си-
стема стоимостью 56 млн. долл, для предварительного заказа авиа-
билетов [18] и система стоимостью 217 млн. долл, для материаль-
но-технического обеспечения [67] *. Анализ этих и других анало-
1 Для системы предварительного заказа авиабилетов первоначальная оценка
числа команд, требуемых для обработки одного сообщения, составила 9000,
а перед прекращением проекта — 146 000. По первоначальной спецификации си-
стема материально-технического обеспечения требовала обработки в реальном
времени 90 % всех сообщений. Перед прекращением проекта выяснилось, что
вполне достаточно обрабатывать в реальном времени 10 % всех сообщений.
51
гичных случаев [15, 37, 179, 204] привел к выводу, что рассмот-
рение ранних подцелей существенно для успешной разработки
программного изделия.
Предпосылка 2: последовательное достижение подцелей про-
цесса разработки. Экономическое обоснование предпосылки 2 сле-
дует в основном из данных, приведенных на рис. 4.2 [41]. Сплош-
ная линия на этом рисунке подытоживает современный опыт
разработки больших проектов [79, 106, 277] и результаты иссле
дований (для нескольких проектов [289]) зависимости относитель-
ной стоимости исправления ошибки (или внесения какого-либо
изменения) в ПО от фазы, в которой производятся эти исправле-
ния или изменения. Согласно накопленному опыту, если ошибка
в требованиях обнаруживается и исправляется на фазе планиро-
вания и анализа требований, то ее исправление сводится к срав
нительно простым изменениям спецификаций требований. Если же
эта ошибка не исправлена до фазы сопровождения, то ее исправ-
ление затрагивает больший объем спецификаций, кодов, руко-
водств для пользователя и по сопровождению, а также учебных
материалов.
Кроме этого, более поздние исправления связаны с гораздо бо-
лее формальным процессом утверждения и контроля изменений,
требуют значительного объема работ по подтверждению правиль-
ности сделанных изменений. В результате совместного действия
этих факторов исправление ошибки на фазе сопровождения боль-
шого программного проекта обходится обычно в 100 раз до-
роже, чем исправление той же ошибки на фазе анализа тре-
бований *.
Штриховая линия на рис. 4.2 изображает зависимость стоимо
сти исправления ошибок в двух небольших неформальных проек-
тах ПО [45]. Эта линия показывает, что для таких проектов обос-
новать предпосылку 2 сложнее, чем для крупных более формали-
зованных проектов. Главные причины меньшего роста стоимости
исправления заключались в следующем:
1) уменьшение размера программы приводило к уменьшению
объема исправлений на более поздних стадиях;
2) уменьшение формализованное™ проекта допускало более
простые изменения и исправления, чем для более формализован-
ных проектов.
Хотя эффект для небольших проектов менее резко выражен,
четырехкратный рост стоимости исправления от фазы анализа тре-
бований до фаз комплексирования и отладки говорит в пользу
предпосылки 2. Такой рост существенно повышает важность за
благовременной спецификации и подтверждения требований и для
небольших разработок.
1 Полное влияние на стоимость ПО ошибок, оставшихся в функционирующем
ПО, фактически гораздо больше из-за дополнительных производственных затрат
порождаемых ошибками (см. [38, 218]).
52
Таким образом, предпосылка 2 означает, что нельзя переходить
к кодированию, не выполнив более ранних работ по составлению
требований и проектированию. В противном случае в окончатель-
ном изделии значительно увеличится число ошибок, связанных с
требованиями и проектированием. В соответствии с данными
рис. 4.2 исправление этих ошибок в более поздних фазах обходит-
ся гораздо дороже и приводит к менее удачным проектам и изде-
лиям.
Отклонение от последовательного подхода при разработке про-
тотипа. Следует отметить, что рис. 4.2 не обосновывает чисто по-
следовательный подход в достижении подцелей процесса разра-
ботки ПО для всех типов проектов. Фактически на нем приведены
зависимости для случаев, в которых целесообразнее разрабатывать
вначале прототип изделия, чем тратить усилия на формулирова-
ние полных требований.
В качестве примера рассмотрим проектирование диалоговой
системы решения нового для разработчиков класса задач (систе-
мы, обеспечивающей принятие решений для оперативного управ-
ления или медицинского диагноза). В этом случае только опреде-
ление необходимых видов обработки информации может потребо-
вать затрат, более чем в 100 раз превышающих затраты на исправ-
ление спецификаций требований после завершения анализа этих
требований. Если тот же результат можно было бы получить (ча-
сто с большей гарантией) путем разработки прототипа системы и
представления его пользователям для апробации, то даже стократ-
ное увеличение стоимости исправления ошибок не сделало бы этот
вариант менее предпочтительным по сравнению с чисто последова-
тельным процессом Еще более веско может быть обоснована
разработка прототипа в случае небольших проектов, для которых
стоимость исправления ошибок в 4—6 раз дороже, и в случае про-
граммирования в прикладных областях, когда возможна быстрая
разработка прототипа. Указанные зависимости позволяют сформу-
лировать более строгий количественный подход к решению пробле-
мы повторной разработки (см. разд. 3.7).
4.4. УСОВЕРШЕНСТВОВАНИЕ КАСКАДНОЙ МОДЕЛИ
Рассмотрим два усовершенствования идеальной каскадной мо-
дели, важных для инженерного программирования, и их влияние
на сроки и распределения затрат по фазам разработки ПО. Этими
усовершенствованиями являются пошаговая разработка и так на-
зываемая предварительная подготовка.
Пошаговая разработка является усовершенствованием метода
повторной разработки с созданием прототипа и поуровневой раз-
работкой сверху — вниз (см. гл. 1). Этот метод предполагает по-
шаговое увеличение функциональных возможностей ПО в процес-
се разработки.
В качестве усовершенствованной каскадной модели пошаговая
разработка успешно применялась при создании очень больших
53
программных изделий, таких как система тактической обороны
стоимостью в 100 млн. долл. [306], и небольших программных из-
делий, таких как версия КОМОСТ объемом 3 К исходных операто-
ров *.
На рис. 4.3 показаны три последовательных шага разработки
КОМОСТ. На шаге / (прямоугольники) предусматривались толь-
ко самые необходимые средства для использования модели и на-
копления опыта работы с ней: массовый ввод в жестком порядке,
основные алгоритмы вычисления оценок стоимости и упрощенная
распечатка результатов. На шаге 2 (овалы) были добавлены такие
важные для функционирования средства, как возможность запо-
минания и восстановления предыдущих прогонов, а также адрес-
ный ввод для избирательного изменения данных модели. На
шаге 3 (пятиугольники) были добавлены различные сервисные
средства: управляемый запросами ввод, дополнительные вычисли-
тельные алгоритмы расчетов сроков и подразделения работ.
Главными преимуществами пошаговой разработки перед абсо-
лютно повторной разработкой и поуровневой разработкой свер-
ху — вниз являются следующие:
использование последовательных расширений программы обес-
печивает гораздо менее дорогой способ учета в усовершенствован-
ном изделии опыта пользователей, чем при повторной разработке;
расширение функциональных возможностей намного упрощает
проверку и полезнее, чем промежуточные изделия при поуровневой
разработке.
Значение пошаговой разработки заключается главным образом
в изменении распределения затрат труда на проект. Вариант кас-
кадной модели для пошаговой разработки показан на рис. 4 4.
Главный результат внесенных изменений состоит в выравнивании
кривой распределения исполнителей по проектам ПО. Вместо по-
казанного на рис. 4.5, а классического рэлеевского распределения
исполнителей по срокам разработки [11, 225, 243] на рис. 4.5,6
наблюдается более пологое распределение (например, для систе-
мы, разработанной недавно пошаговым методом для обработки
данных радиолокационной станции).
Предварительная подготовка. Обычным приемом политической
или рекламной кампании является проведение предварительной
подготовки перед началом основной работы. На этом этапе забла-
говременно решаются все потенциальные технические, политиче-
ские и организационные проблемы для успешного и эффективного
выполнения основной работы. Предварительная подготовка такого
же рода существенна и для проекта ПО. В этом случае она прини-
мает две основные формы: разработка предварительной докумен-
тации и создание инструментальных программных средств.
Разработка предварительной документации производится для
решения двух главных задач.
1 Рекомендации по применению пошаговой разработки приводятся в [22, 232].
1. Подробно определить
цели и планы предстоящих
работ над ПО (планы разра-
ботки, отладки, переноса
программ) в рамках ЦОП
(см. табл. 3.2, разд. 3.9).
2. Создать первоначаль-
ный вариант документации
для пользователей (напри-
мер, подготовить пользовате-
лю для рассмотрения пер-
вую редакцию руководства к
окончанию фазы проектиро-
вания изделия). Это прино-
сит большую пользу заказ-
чикам и дает возможность
им увидеть со своей точки
зрения влияние системы на
их работу и договориться о
необходимых изменениях до
существенного удорожания
этих изменений. Кроме того,
выпуск предварительной до-
кументации надежно га-
рантирует создание докумен-
тации для пользователей од-
новременно с программами
системы.
Создание инструменталь-
ных программных средств.
Инструментальные средст-
ва — это дополнительные из-
делия, применяемые для воз-
можно большего улучшения
конечного изделия и повы-
шения эффективности основ-
ной программной разработ-
ки, а также для верификации
и подтверждения. Как указа-
но в [51], эти средства мо-
гут содержать фиктивные
компоненты ПО, или заглуш-
ки, небольшие файлы или
другие имитируемые части
будущего операционного ок-
ружения. Кроме того, в со-
став инструментальных
средств могут входить вспо-
55
могательные программы (генераторы тестовых данных, постпро-
цессоры, генераторы перекрестных ссылок, средства переноса,
средства контроля стандартов и требований, а также процессоры
языков разработки).
Анализ
осуществимости
модели
"•"^Подтверждение
Планирование и
анализ
требований
к ПО^--''^Подтверждение
Расширение 1
Расширение 2s*—
Кодирование
Комплексирование
Проектирование
изделия
Детальное
проектирование
"Автономная
отладка
Верификация
Кодирование
Кодирование
Детальное
проектирование
Рис. 4.4. Каскадная модель с использованием пошаговой разработки
Верификация
Комплексирование
Автономная
отладка
Верификация
изделия
Внедрение
Системная
отладка
Эксплуатация и
сопровождением
^м"Перепод-
тверждение
Расширение 3
Значение предварительной подготовки для экономики ПО. По-
видимому разработка предварителвной документации и подготов-
ка инструментальных средств оказывают двоякое экономическое
влияние на ЖЦПО.
1. Они сокращают общую стоимость ПО, главным образом, за
счет уменьшения энтропии [161] ЖЦПО, т. е. сокращения тех ра-
бот, которые без каких-либо созидательных результатов поглоща-
ют творческую энергию людей. Оценка соответствующего сокра-
56
щения дается в КОМОСТ (см. гл. 8 и 27) с помощью коэффициен-
тов затрат на применение инструментальных средств и современ-
ных методов программирования.
2. Они увеличивают начальное число исполнителей разработ-
ки. Приобретение средств отладки или составление планов отладки
Рис. 4.5. Распределение исполнителей разработки:
а — кривая Рэлея; б — пошаговая разработка
и первых редакций руководств для пользователей способствуют
увеличению затрат на фазах анализа требований и проектирова-
ния и существенному уменьшению затрат на фазах отладки и со-
провождения. Оценка величины такого влияния определяется в
КОМОСТ (см. гл. 23).
57
4.5. ОПРЕДЕЛЕНИЕ ФАЗ ЖИЗНЕННОГО ЦИКЛА
В табл. 4.1, которая содержит основные определения фаз
ЖЦПО, перечисленных в разд. 4.2, даны формулировки конечных
целей каждой фазы для перехода к следующей фазе. Для пошаго-
вой разработки приводимые формулировки относятся к границам
фаз каждого шага расширения.
Таблица 4.1
Конечные цели фаз
1. Начать фазу планирования и анализа требований. (Завершение концеп-
туального обзора ЖЦПО.)
Получение одобренной и подтвержденной архитектуры системы с включени-
ем основных соглашений о распределении функций между аппаратурой и про-
граммами.
Получение одобренного и подтвержденного общего представления о функ-
ционировании ПО с включением основных соглашений о распределении функций
между человеком и системой.
Формирование общего плана ЖЦПО с определением основных этапов ре-
сурсов, обязанностей, сроков и главных работ.
2. Завершить фазу планирования и анализа требований. Начать фазу про-
ектирования изделия. (Завершение обзора требований к ПО).
Формирование, детального плана разработки: детальных показателей завер-
шения этапов разработки, планов распределения ресурсов, схем организационной
структуры, обязанностей, сроков, работ, методов и изделий.
Формирование детального плана использования: пунктов плана разработки,
содержание которых ориентировано на обучение, перенос программ, внедрение,
эксплуатацию и поддержание.
Формир, „ание детального плана отладки изделия — план управления кон-
фигурацией ТО, план контроля качества, общий план ВП.
Одобренная и подтвержденная спецификация требований к ПО: функцио-
нальные, технические и интерфейсные спецификации, для которых подтверждены
их полнота, непротиворечивость, проверяемость и осуществимость.
Одобренный (формально или неформально) договор на разработку, осно-
ванный на приведенных выше пунктах.
3. Закончить фазу проектирования изделия. Начать фазу детального проек-
тирования. (Завершение анализа результатов проектирования изделия.)
Разработка верифицированной спецификации проекта программного из-
делия:
формирование иерархии программных компонентов, межблочных 1 интерфей-
сов по данным и управлению;
формирование физической и логической структур данных до уровня отдель-
ных полей;
разработка плана распределения вычислительных ресурсов (времени, памя-
ти, точности);
верификация полноты, непротиворечивости, осуществимости и обоснованно-
сти требований.
Установление и разрешение всех противоречий разработки, которые повыша-
ют степень риска.
Разработка предварительного плана комплексирования и отладки, плана
руководства для пользователей и приемных испытаний.
4. Закончить фазу детального проектирования. Начать фазу кодирования
и автоноя ной отладки. (Завершение сквозного контроля проекта или критиче-
скогс поблочного анализа проекта.)
Верифицированная детальная спецификация каждого блока:
спецификация каждой подпрограммы (блока не более чем из 100 исходных
команд), имени, назначения, предположений, размеров, последовательности вы-
зовоо, ошибочных выходов, в: одных и выходных данных, алгоритмов и логиче-
ской схемы;
58
Окончание табл. 4.1
описание базы данных до уровня отдельных параметров, символов и битов;
верификация полноты, непротиворечивости и соответствия требованиям про-
ектных спецификаций системы и планам распределения ресурсов.
Одобренный план приемных испытаний.
Руководства пользователю, а также завершенный предварительный план
комплексирования и отладки.
5. Закончить фазу копирования и отладки. Начать фазу комплексирования
и отладки. (Удовлетворение критериев автономной отладки.)
Проверка работы всех блоков не только для номинальных, но также для
исключительных и предельных значений.
Проверка всех вариантов ввода и вывода, включая сообщения об ошибках.
Выполнение всех операторов и всех ветвей передачи управления.
Проверка выполнения стандартов программирования.
Завершение поблочного документирования внутренней структуры.
6. Закончить фазу комплексирования и испытаний. Начать фазу внедрения.
(Завершение анализа результатов приемных испытаний.)
Проверка удовлетворения тесту приемных испытаний программ:
проверка удовлетворения требованиям к ПО;
демонстрация приемлемости указанных в спецификациях характеристик ра-
боты в нештатных условиях.
Приемка поставляемых программных изделий, отчетов, руководств, баз дан-
ных, спецификаций внутренней структуры.
7. Закончить фазу внедрения. Начать фазу эксплуатации и сопровождения.
(Завершение анализа приемки системы.)
Проверка удовлетворительности результатов приемных испытаний системы.
Проверка удовлетворения системных требований.
Проверка производственной готовности ПО, аппаратуры, средств обслужи-
вания и персонала.
Приемка поставляемых и входящих в систему изделий: аппаратуры, ПО,
документации, средств обучения и обслуживания.
Завершение всех специфицированных работ и ввод системы в действие.
8. Закончить фазу эксплуатации и сопровождения (путем снятия с произ-
водства).
Выполнение всех пунктов плана снятия с производства: перенос программ,
документирование, создание архива, переход к новой системе (или новым си
стемам).
1 Программный блок выполняет одну точно определенную функцию, может быть раз-
работан одним исполнителем и, как правило, содержит от 100 до 300 исходных команд.
4.6. ОПРЕДЕЛЕНИЕ ФАЗ И РАБОТ
Рассматриваемые в этой книге модели стоимости позволяют
оценивать не только общие затраты труда на каждой фазе ЖЦПО,
но и распределение этих затрат по восьми основным работам над
проектом. Эти работы перечислены ниже:
Анализ требований
Проектирование изделия
Программирование
Планирование отладки
Верификация и подтверждение
Для придания смысла оценкам этих работ необходимо опреде-
лить функции, включаемые в каждую работу (табл. 4.2), и зада-
чи каждой работы на каждой фазе (табл. 4.3).
Управление проектом
Управление конфигурацией и
контроль качества
Документирование
59
Таблица 4.2
Функции, включаемые в каждую работу
Анализ требований Определение, спецификация, анализ и модифи-
кация функциональных, технических, интерфейс-
ных и верифицировочных требований. Охватыва-
ет все элементы SX21 СПР * за исключением
элемента SX212 (подтверждение требований) (см.
рис. 4.6, б).
Проектирование изде- Определение, спецификация, анализ и модифи-
лия кация аппаратно-программной архитектуры, про-
екта программы и Зазы данных. Охватывает все
элементы SX22 СПР за исключением элемента
SX222 (верификация и подтверждение).
’ Программирование Детальное проектирование, кодирование, авто-
номная отладка и комплексирование отдельных
компонентов машинной программы, а также пла-
нирование штатов программистов, приобретение
инструментальных средств, разработка базы дан-
ных, документирование отдельных компонентов и
организация программирования на уровне компо-
нентов. Охватывает элементы SX3 СПР за исклю-
чением SX413, 414, 423 и 424.
Планирование от- Спецификация, анализ и модификация планов
ладки 4 отладки изделия и приемных испытаний. Приоб-
ретение тестовых драйверов, средств отладки и
тестовых данных. Охватывает все элементы
SX4 СПР за исключением SX413, 414, 423, 424.
Верификация и под- Независимое выполнение подтверждения тре-
тверждение бований, ВП проекта, отладка изделия и прием-
ные испытания Приобретение инструментальных
средств, ВП требований и проекта. Охватывает
элементы SX212, 222, 4'13-4, 423-4 СПР.
Управление проектом Функции управления проектом: планирование
и контроль проекта, контроль и регулирование
договоров и субдоговоров, связь с пользователя-
ми. Охватывает элементы SXI СПР
Управление конфигу-
рацией и контроль ка-
чества (УД и КК)
Документирование
Управление конфигурацией включает в себя
идентификацию компонентов изделия, контроль
изменений, анализ состояния дел, ведение библио-
теки поддержания разработки, разработку и кон-
троль плана приемки конечных компонентов из-
делия. Контроль качества включает в себя раз-
работку и контроль стандартов и технические
проверки программных изделий и процессов раз-
работки. Охватывает элементы SX23, 24, 25 СПР.
Разработка и корректировка руководств для
пользователей, оператопов и по сопровождению.
Охватывает элемент SX61 СПР.
1 СГТР — структура подразделения работ, определяемая и обсуждаемая в разд. 4.7.
60
Таблица 4.3
Распределение задач проекта по видам работ и фазам
Вид работы Планирование и анализ требований Проектирование изделия Программирование Ком плексированИс и испытания
Анализ требований Анализ существующей си- стемы, определение запро- сов пользователей, комп- лексирование. документи- рование и доработка требо- ваний Разработка базовой архи- тектуры, анализ моделей, прототипов, степени риска Обновление требований Обновление требований Обновление требований
Проектирование из- делия Разработка проекта изде- лия, анализ моделей, про- тотипов, степени риска Обновление проекта Обновление проекта
Программирование Общее планирование шта- тов и использования инст- рументальных средств Планирование штатов, при- обретение инструменталь- ных средств, сервисных про- грамм Детальное проектирование, кодирование и автономная отладка, документирование компонентов, планирова- ние комплексирования Комплексирование ПО, об- новление компонентов
Планирование от- Определение требований к Предварительное планиро- Детальное планирование Детальное планирование
ладки и испытаний приемным испытаниям, об- щее планирование отладки и испытаний, приобретение инструментальных средств отладки и испытаний вание отладки и испыта- ний, приобретение инстру- ментальных средств отлад- ки и испытаний отладки и испытаний, при- обретение инструменталь- ных средств отладки и ис- пытаний отладки и испытаний, под- готовка к использованию инструментальных средств отладки и испытаний
Верификация и под- Подтверждение требова- ВП проекта изделия, при- ВП блок-схем и изменений Отладка изделия, приемные
тверждение ннй, приобретение инстру- ментальных средств ВП тре- бований и проекта обретение инструменталь- ных средств ВП проекта в проекте испытания, ВП изменений в проекте
Управление проек- Планирование проекта, ве- Контроль и регулирование Контроль и регулирование Контроль и регулирование
том дение договоров, связь с фирмами и т. п. состояния проекта, ведение договоров, связь с фирмами и т. п. состояния проекта, ведение договоров, связь с фирмами и т. п. состояния проекта, ведение договоров, связь с фирмами и т. п.
УК и кк Планирование и разработка процедур УК и КК. плани- рование приемки, определе- ние инструментальных средств УК и КК УК и КК требований про- екта; разработка стандар- тов проекта, приобретение инструментальных средств УК и КК УК и КК требований, про- екта; кодирование, ведение библиотеки УК и КК требований, про- екта; кодирование, ведение библиотеки: управление планом приемки
СТ) Документирование Подготовка набросков не- которых частей руководства для пользователей Подготовка предваритель- ных руководств для пользо- вателей и операторов, на- бросков руководства по сопровождению Подготовка предваритель- ных руководств для поль- зователей и операторов Подготовка окончательных руководств для пользовате- лей, операторов и по сопро- вождению
Длц иллюстрации использования табл. 4.2 и 4.3 рассмотрим
типичный вариант распределения работ по фазам. Сначала с по-
мощью представленной в гл. 7 базовой модели оценки стоимости
можно определить, что 6% затрат на фазе программирования при-
ходится на УК и КК- Таблица 4.2 показывает, что УК и КК вклю-
чает в себя идентификацию компонент изделия, контроль измене-
ний, ведение библиотеки поддержания разработки, разработку и
контроль стандартов и технические проверки. Теперь из табл. 4.3
можно определить, что указанные 6% затрат на фазе программи-
рования приходятся на выполнение перечисленных функций УК и
КК по отношению к требованиям, проекту и коду, а также на ве-
дение библиотеки поддержания разработки.
4.7. СТРУКТУРА ПОДРАЗДЕЛЕНИЯ РАБОТ
Для финансового планирования и целей управления весьма по-
лезно организовать выполняемые в ходе проектирования работы
в иерархическую структуру, которая называется структурой под-
разделения работ (СПР). Она относится к разработке ПО, доста-
точно детализирована и является модульной структурой. В состав
СПР входят две иерархические схемы, которые могут быть связа-
ны любым наиболее подходящим для конкретного проекта спосо-
бом. Эти иерархические схемы определяются следующим образом:
Иерархия изделий (рис. 4.6, а) показывает место различных
Рис. 4.6, а. Структура подразделения работ, иерар-
хия изделий
62
SX1 -SX7
Работы над
подсистемой SS%
SX1 | SX2 SX3
Управление SSx Системное проектирование SSx Программи- рование SSx
SX11, Управление затратами, сроками, характеристиками SX12, Контроль и регулирование договоров SX13, Контроль и регулирование субдоговоров SX14, Связь с пользователями SX15, Управление филиалами SX16, Анализ и проверка управления SX21, Анализ требований к ПО SX211, Формулирование Требований SX212, Подтверждение требований SX213, Анализ требований К ПО SX214, Обеспечение инструментальных средств анализа требований L I SX31, Детальное проектирование SX32, Кодирование и автономная отладка SX33, Комплексиро- вание
SX215, Обновление требований
SX4
Отладка,
испытания и
оценка SSx
SX41, Отладка изделия
SX411, Планирование
SX412, Разработка
процедур
SX413, Отладка
SX414, П редставление
отчетов
SX42, Приемные
испытания
SX421, Планирование
SXE
Документиро-
вание ssx
SX51, Разработка
руководств SSx
SX6
Внедрение SSX
Включается в
оценки
стоимости
разработки
SX22, Проектирование
программного изделия
SX221, Проектирование
SX222, ВП проекта
SX223, Анализ проекта
изделия
SX224, Обновление проекта
SX225, Обеспечение
инструментальных средств
проектирования
БХ23,Управление
конфигурацией
SX23J ведение библиотеки
поддержки разработки
SX24, Разработка и контроль
плана приемки конечных
компонентов изделия
SX25. Контроль качества
SX251, Разработка и контроль
стандартов
SX422, Разработка
процедур
SX423, Отладка
SX424, Представление
отчетов
S X 43 Обеспечение
отладки и испытаний
SX431, Обеспечение
испытательных стендов
SX432, Обеспечение
инструментальных средств
SX433, Обеспечение
тестовых данных
SX61, Опытное
внедрение
SX611, Планирование
SX612, Работы по
опытному внедрению
SX613, Отладка
SX614, Представление
отчетов
SX62, Перенос
SX621, Планирование
SX622, Работы по
. переносу
SX6221, Перенос
программ
SX6222, Перенос базы
данных
SX6223, Перенос
документов
SX623, Отладка
SX624, Представление
отчетов
SX63, Обучение
| SX7
Сопровождение
SX71,Обновление ПО
SX72, Корректирование
SX73, Адаптирование
SX74, Совершенство-
вание
l"sX75, Управление "|
I базой данных
I__________________I
Включвется в
оценки стоимости
сопровождения
SX2B. Анализ осуществимости
Рис. 4.6, б. Иерархия работ в СПР
компонентов (подпрограммы, модуля, подсистемы и т. п.) в полной
системе ПО.
Иерархия работ (рис. 4.6, б) показывает различные работы, вы-
полняемые над отдельным компонентом ПО.
Иерархия изделий отражает основную структуру программно-
го изделия в том виде, в каком эта структура определена проек-
тировщиками ПО. Отдельные части иерархии работ могут исполь-
зоваться на любом уровне иерархии изделий, на котором приме-
нимы соответствующие работы. Так, например, управление
(элемент SX1 на рис. 4.6,6) может применяться ко всему проекту,
к подсистеме SSAB (SABI) или к любой другой подсистеме. Иден-
тификатор элемента СПР получается подстановкой в идентифика-
тор иерархии работ вместо буквы X идентификатора соответству-
ющей подсистемы. Например, SAB1 (Х=АВ) является элементом
СПР, предназначенным для контроля управленческих расходов на
подсистему SSAB, a SI (X — пусто) является элементом СПР,
предназначенным для контроля управленческих расходов на всю
систему ПО SS.
На практике элементы СПР — как в иерархии изделий, так и
в комплексе иерархий работ для всех компонентов — уточняются
только до уровня, необходимого для отчета о затратах и их конт-
роля *. На рис. 4.7 приведен пример СПР проекта разработки мо-
дели трудоемкостью 40 ЧМ и объемом 10000 команд. Из приведен-
ной структуры видно, что некоторые работы проводятся на не-
скольких уровнях иерархии изделий. Управление осуществляется
как для всего проекта (S1), так и для разработки вычислительной
подсистемы (SB1). Системное проектирование применяется как
на уровне всего проекта (S2 с компонентами S21 и S22), так и
на уровне модуля (SBA2).
Применение СПР. Одно из основных применений СПР состоит
в том, чтобы уточнить, какие именно затраты оцениваются мо-
делью стоимости ПО. Без таких уточнений стоимостные оценки и
данные теряют определенность и значение. Штриховые линии на
рис. 4.6, б показывают, что затраты на разработку ПО, оценивае-
мые с помощью КОМОСТ, охватывают все мероприятия первых
пяти главных работ (SX1—SX5) за исключением анализа осуще-
ствимости, проводимого на фазе анализа осуществимости ЖЦПО,
и анализа требований, затраты на проведение которого оценива-
ются отдельно от затрат на разработку ПО.
Другое основное применение СПР состоит в том, что эта струк-
тура служит основой для сбора данных и представления отчета по
стоимости ПО. Каждому элементу СПР может быть выделен бюд-
жет и назначен номер, который будет использоваться при сообще-
1 Некоторые обоснованные границы, определяющие необходимость введения
отдельных элементов СПР, указываются ниже в терминах долей от общей затрат
и числа человеко-месяцев (ЧМ):
для небольших (7 ЧМ) проектов: не менее 7% или 0,5 ЧМ; v
для средних (300 ЧМ) проектов: не менее 1 % или 3 ЧМ;
для очень больших (7000 ЧМ) проектов: не менее 0,2% или 15 ЧМ.
нии о затратах времени на
различные работы при про-
ектировании. Эти данные
могут обрабатываться в АСУ
с целью предоставления ру-
ководителям средств оцени-
вания соотношения затрат
и бюджета по каждой зада-
че (подробнее см. гл. 32).
Кроме того, если в ка-
кой-нибудь организации дан-
ные о затратах на разработ-
ку ПО собирают в соответ-
ствии со структурой СПР,
то в результате будет полу-
чена чрезвычайно ценная
база данных по распределе-
нию затрат на разработку
ПО в этой организации, а
это может быть использова-
но для усовершенствования
и адаптации общей модели
стоимости к особенностям10
данной организации.
4.8. СОПРОВОЖДЕНИЕ ПО
Сопровождение ПО—это
процесс изменения сущест-
вующего ПО при сохране-
нии неизменными его основ-
ных функций. Согласно это-
му определению под поня-
тие сопровождения подпа-
дают следующие работы:
перепроектирование и пе-
реразработка небольших ча-
стей (составляющих менее
50% объема нового кода)
существующего программ-
ного изделия;
проектирование и разра-
ботка небольших интерфейс-
ных программных пакетов,
которые требуют перепроек-
тгрования (объемом менее
20 %) существующего про-
граммного изделия;
65
3 Зак. 628
модификация кода, документации или структуры базы данных
программного изделия.
Согласно приведенному определению к сопровождению не от-
носятся следующие работы:
крупные перепроектирование и переразработка (в результате
которых получится более 50% новых ко job), сохраняющие в ос-
новном функции прежнего программного изделия;
проектирование и разработка значительного по размеру (более
20% ЧИК. существующего изделия) интерфейсного программно-
го пакета, который требует относительно небольшого перепроекти-
рования существующего программного изделия;
поддержание функционирования системы обработки данных,
ввод данных и изменение значений в базе данных
Можно выделить два главных вида сопровождения-
1) обновление ПО, приводящее к изменению функциональной
спецификации программного изделия:
2) исправление ПО, не изменяющее функциональной специфи-
кгции.
3 свою очередь, в исправлении ПО можно выделить три глав-
ных подвида:
2а) копректирование (сшибок обработки, характеристик и
внедрения);
26) адаптирование (к изменениям программного окружения);
2в) совершенствование (характеристик и сопровождаемости).
ГЛЛВА 5
БАЗОВАЯ КОМОСТ
5.1. ВВЕДЕНИЕ
Hei оторые уравнения оценки и постаноька вопросов. В этой
главе обсуждаются уравнения оценки ь человекп-месяцах затрат
труда на разработку самого обшего типа программного изделия.
Одно уравнение определяет зависимость ЧМ от численно выражен-
ного в тысячах исходных команд (КЧИК) размера программного
изделия и имеет вид
ЧМ = 2,4 -КЧИК*05 (5.1)
Второе уравнение оценивает в месяцах сроки разработки (СР)
и имеет вид
СР=2,5 'ЧМ0-38 (5 2)
Однако прежде чем широко применять эти уравнения на прак-
тике, необходимо дагь ответ на несколько важных вопросов.
66
Какие команды считать исходными? Например, относить ли к
последним комментарии, которые часто составляют свыше полови-
ны исходного текста?
Какие ЧМ составляют оценку затрат труда? Например, вклю-
чаются ли затраты труда библиотекарей и секретарей проекта, опе-
раторов ЭВМ и работников хозяйственных служб?
Какие фазы включаются в понятие «разработка»? Например,
включаются ли в это понятие фаза планирования и анализа требо-
ваний, а также фаза внедрения?
К каким классам проектов применимы указанные оценочные
уравнения? Применимы ли они при любых условиях проектирова-
ния, для плохо управляемых проектов, при частом изменении це-
лей и т; п.?
Некоторые из этих вопросов в значительной степени рассмот-
рены в предыдущей главе при определении фаз и структуры под-
разделения работ. Остальные будут рассмотрены в разд. 5.2 до
фактического обсуждения самих уравнений.
Версии КОМОСТ, Конструктивная модель стоимости, описыва-
емая в данной книге, представляет собой иерархию моделей в по-
рядке возрастания детальности и точности. Приведенные выше
уравнения задают одну из версий модели — базовую КОМОСТ,
которая применима к огромному числу программных проектов,
связанных с созданием малых и средних программных изделий
собственной (не покупной) разработки. Другие аспекты базовой
КОМОСТ — оценки распределений затрат по фазам, срокам и
работам — рассматриваются в следующих трех главах.
Базовая КОМОСТ хороша для получения первичных быстрых
приближенных оценок затрат на ПО. Ее точность ограничивается
отсутствием в ней учета различий в аппаратуре, квалификации и.
опыте работы исполнителей, использовании современных методов
и инструментальных средств и в других атрибутах, существенно
влияющих на затраты. В гл. 8 и 9 будут изложены основы проме-
жуточной КОМОСТ, которая учитывает указанные атрибуты.
В следующей части будет рассмотрена детальная КОМОСТ, учи-
тывающая влияние таких факторов на отдельные фазы проекта.
S.2. ОПРЕДЕЛЕНИЯ И ПРЕДПОЛОЖЕНИЯ
В предыдущей главе были представлены необходимые для
КОМОСТ определения фаз и работ ЖЦПО. Ниже приведено не-
сколько дополнительных определений и допущений, положенных в
основу применения КОМОСТ.
1. Первичным для итоговой стоимости является число исход-
ных команд (ЧИК) конечного программного изделия. Это понятие
определяется следующим образом
Конечное ПО. Этот термин, как правило, исключает промежу-
точное и вспомогательное ПО, например, тесты. Однако, если они
разрабатываются так же тщательно, как и конечное ПО, со свои-
ми собственными процедурами анализа, планами испытаний, доку-
3*
67
ментацией и т. п., то такие тесты следует учитывать в качестве
исходных команд.
Исходные команды. Этот термин охватывает все команды, раз-
работанные в ходе проектирования и переработанные в машинный
код с помощью препроцессоров, компиляторов и ассемблеров. Ис-
ходные команды не включают комментарии и штатное ПО, но
включают операторы языка управления заданиями, операторы
формата и описания. Команды определяются как кодовые строки
или перфокарты. Поэтому 'строка, содержащая два и большее чис-
ло исходных операторов, считается одной командой, а пятистроч-
ное описание данных — пятью командами.
2. Период разработки, на который распространяются оценки по
КОМОСТ, начинается фазой проектирования изделия после успеш-
ного анализа требований к ПО (см. табл. 4.1) и оканчивается
фазой комплексирования и испытаний (после успешного заверше-
ния анализа результатов приемки ПО). Затраты и сроки выполне-
ния других этапов и остальных фаз оцениваются отдельно.
3. Оценки по КОМОСТ относятся к тем и только тем работам,
которые указаны в СПР (см. рис. 4.6,6). В соответствии с этим,
например, оценки охватывают затраты на управление и докумен-
тирование, но не включают некоторые затраты периода разработ-
ки, такие как обучение пользователей, планирование внедрения и
переноса. Некоторые соотношения для оценки указанных затрат
приведены в гл. 31.
4. Оценки по КОМОСТ относятся ко всем исполнителям проек-
та на фазах, указанных выше. Таким образом, эти оценки учиты-
вают работу руководителей и библиотекарей проекта, но не при-
нимают во внимание работу операторов ВЦ, сотрудников отдела
кадров, секретарей, высших руководителей, работников хозяйст-
венных служб и т. п.
5. В КОМОСТ человеко-месяц состоит из 1521 часов рабочего
времени. Было найдено, что эта цифра согласуется с наблюдае-
мым на практике средним ежемесячным нерабочим временем из-за
праздников, очередного отпуска и отпуска по болезни. Для преоб-
разования в КОМОСТ оценок нужно использовать следующие
правила перевода ЧМ в другие единицы:
для получения человеко-часов — умножить ЧМ на 152;
для получения человеко-дней — умножить ЧМ на 19;
для получения человеко-годов — разделить ЧМ на 12.
6. В КОМОСТ предполагается хорошее управление проектом
как разработчиком, так и заказчиком. Например, предполагает-
ся, что руководитель проекта и заказчик удерживают на низком
уровне общее непродуктивно используемое время.
7. В КОМОСТ предполагается отсутствие существенных изме-
нений в спецификации требований после фазы планирования и
анализа этих требований. Некоторые изменения и усовершенство-
1 При анализе или применении числового материала книги в аналогичных
разработках указанное соотношение может измениться. — Прим. ред.
68
вания будут неизбежны, но любые существенные обновления или
дополнительные возможности требуют исправления оценок затрат.
8. В детальной КОМОСТ предполагается, что влияние стоимо-
стных факторов зависит от фазы разработки. В базовой и проме-
жуточной КОМОСТ это не предполагается за исключением того,
что проводится различие между разработкой и сопровождением.
9. Затраты по указанным выше фазам включаются полностью
в оценки. Как видно из рис. 5.1, затраты на обновление плана ком-
плексирования и испытаний и на завершение плана отладки вклю-
чаются в затраты на фазе детального проектирования.
На рис. 5.1 приведена общая модель процесса разработки ПО,
которая, как предполагается в КОМОСТ, будет использована в
проекте. В этом процессе упор делается на следующие основные
моменты:
1. Тщательное определение и подтверждение требований к ПО
относительно небольшой группой специалистов до начала основной
работы над проектом всей системы.
2. Тщательное определение и подтверждение проекта програм-
мной системы до уровня блоков (см. табл. 4.1) большей, но все
еще относительно немногочисленной группой специалистов до на-
чала основных работ по детальному проектированию и кодиро-
ванию.
3. Параллельное выполнение детального проектирования, коди-
рования и автономной отладки группой программистов, работаю-
щих в рамках системного проектирования в условиях планируемой
пошаговой разработки.
4. На каждом шаге комплексирование и испытание обеспечи-
вают значительный объем работ по предварительному планирова-
нию отладки и устранению почти всех внутриблочных ошибок в
результате тщательного сквозного контроля и автономной отладки.
5. Заблаговременное выполнение большого объема работ по до-
кументированию (например, подготовка первой редакции руко-
водств для пользователей) с тем, чтобы создать некоторые пред-
варительные сведения для пользователей (и разработчиков) об
эксплуатационных характеристиках изделия.
Сопоставление ЧМ и денежных оценок. В КОМОСТ, как пра-
вило, не используются денежные оценки затрат на исполнителей
вследствие больших расхождений относительно того, что включать
в издержки на оплату исполнителей (включать ли накладные рас-
ходы, учитывать ли пенсионные отчисления, аренду помещений,
прибыль), и из-за того, что ЧМ являются более постоянными вели-
чинами, чем доллары, при современных темпах инфляции и коле-
баниях курсов валюты.
Лучший компромисс между простотой и точностью перевода
ЧМ в денежные единицы заключается в применении для каждой
фазы своего среднего коэффициента перевода, учитывающего ин-
фляцию и различия в окладах специалистов. Например, средний
69
Разработка ПО
Разработка спецификаций
изделия
Программирование
Планирование
и выработка требований
Проектирова
ние изделия
Детальное
проектиро-
вание
Кодирование
и автономная
отладка
Комплексирование
и испытания
Со прово?
дение
Начало
проекта
Планирование
Планирование.
Планирование
Документирование
Планирование.
Контроль качества
Приемка
Приемка конечного изделия
Управление конфигурацией
Анализ и управление
Анализ
осущест-
вимости
Организация
и планиро-
вание
Анализ
требований
к ПО
Разработка
спецификаций
требований
к ПО
Анализ
проекта
изделия
Разработка
специфика-
ций проекта
изделия
Критический
анализ проекта
Разработка
детальных
специфика-
ций проекта
Использование стандартов4
программирования у
Коди-
рова-
ние
Планирование \ р
автономной отладки /'
Авто-
номная
отлад-
ка
Планирование комп'лекси'
рования и испытаний у
Комплек-
сирование
и испыта-
ния
Планирование приемных
испытаний
(предварительных!
Приемные
испытания
Разработка руководства
для пользователей
(первая редакция!
Заверше-
ние
Подго-
товка /
окончательного
варианта
Р«с. 5.1. Фазы, работы и эташ программного проекта
Зксплуата
ция и сопро-
вождение
70
ЧМ мог бы стоить 60001 долл, на фазах планирования и анализа
требований, а также проектирования изделия, 5000 долл, на фазе
детального проектирования, кодирования и автономной отладки
и 5500 дочл. на фазах комплексирования и испытаний, а также
сопровождения.
5.3. ЗАТРАТЫ ТРУДА И СРОКИ РАЗРАБОТКИ
Теперь установлена достаточно полная система понятий ЖЦПО
для четкой квалификации назначений оценок. Рассмотрим урав-
нения КОМОСТ для затрат труда и сроков разработки, которые
относятся к наиболее часто встречающемуся типу программного
Рис. 5.2. Оценка затрат на программы распространенного типа по базовой
КОМС СТ
Рис. 5.3. Оценка сроков разработки программ распространенного типа по базо-
зой КОМОСТ
проекта, называемому далее распространенным и связанному с
созданием малых и средних изделий собственной (не покупной)
разработки ПО. Для таких разновидностей программной разра-
ботки приводятся таблицы для оценки распределений затрат тру-
да и сроков разработки по фазам.
Уравнения для затрат и сроков базовой КОМОСТ. Рассмотрим
еще раз оценочные уравнения (5.1) и (5.2). Величина КЧИК со-
гласно определению задает число исходных команд в программ-
ном изделии. Величина ЧМ является оценкой числа человеко-ме-
сяцев на разработку в ЖЦПО с учетом определений и предполо-
жений разд. 5.2. Графики оценок, даваемых основным уравнением
затрат труда (сплошная линия) и соответствующих оценок произ-
водительности в ЧИК/ЧМ (штриховая линия) приводятся на
рис. 5.2 2.
При анализе и применении данных книги, выраженных в долларах, необ-
ходимо учитыва~ь условность таких данных. — Прим. ред.
2 При использовании КОМОСТ полезно иметь калькулятор с возможностью
возведения в степень. Однако можно воспользоваться графиками на рис. 5.2 и 5 3
Для пол5 чения искомых значений.
71
Величина СР [см. уравнение (5.2)] задает оценку длительно-
сти разработки в месяцах с учетом тех же определений и предпо-
ложений. График оценок, соответствующий уравнению для сроков
разработки, приводится на рис. 5.3.
Примеры оценок. Предположим, что химическая компания Du Bridge Chemi-
cal, Inc. планирует разработку новой машинной программы (для учета сырья)
собственной бригадой программистов и аналитиков, которые в течение уже не-
скольких лет разрабатывали подобные программы. В соответствии со сказанным
разработка такой программы является хорошим примером разработки распро-
страненного программного изделия. В результате предварительных исследований
был установлен приблизительный размер программы — 32 000 конечных исходных
команд (32 КЧИК). С помощью основных уравнений можно оценить следующие
характеристики проекта:
Затраты труда: ЧМ=2,4-321>05=91;
Производительность труда: 32 000/91=352 ЧИК/ЧМ;
Сроки разработки: СР=2,5-91°-38= 14 мес.;
Средние штаты: 91 ЧМ/14 мес.=6,5 ЧИ,
где ЧИ— число исполнителей с полным рабочим днем, единица измерения приве-
денного к полному рабочему дню числа людей, участвующих в проекте.
Характеристика проектов. В табл. 5.1 приведены характеристики
распространенных программных проектов стандартных размеров:
Малый . . .
Промежуточный
Средний . .
Большой . .
2 000 ЧИК
8 000 ЧИК
32 000 ЧИК
128 000 ЧИК
Таблица 5.1.
Характеристики проектов распространенного типа
Размер изделия, КЧИК Затраты труда, кчик Производи- тельность, ЧИК/ЧМ Сроки, мес. Средние штаты, ЧИ
Малый, 2 5,0 400 4,6 1,1
Промежуточный, 8 21,3 376 8,0 2,7
Средний, 32 91,0 352 14,0 6,5
Большой, 128 392,0 327 24,0 16,0
Из таблицы видно, что малый проект выполняется по существу
одним человеком *, в то время как для выполнения большого про-
екта требуется в среднем 66 исполнителей. В следующем разделе
будет показано, как эти люди распределяются в ЖЦПО.
* Следует учитывать, что равная 5 ЧМ оценка затрат труда на малый проект
относится к разработке программного изделия размером 2000 ЧИК, и это подра-
зумевает тщательное документирование, отладку, обеспечение надежности при
наличии ошибок, обучение пользователей и т. п Многие создавали персональные
программы объемом 2000 ЧИК, не соблюдая указанных выше характерных прин-
ципов разработки программного изделия, за меньшее число ЧМ. Это вполне воз-
можно, поскольку, как указывалось в [51], па программное изделие требуются
приблизительно в 3 раза большие затраты труда, чем на персональные программы
такого же размера.
72
J.4. РАСПРЕДЕЛЕНИЕ ПО ФАЗАМ
В табл. 5.2 представлено долевое распределение основных за-
трат труда и сроков по фазам программной разработки, приведен-
ных в табл. 4.1 и на рис. 5.1. Распределение по фазам зависит от
размера изделия. В более крупных проектах требуется относи-
тельно больше времени и усилий на выполнение комплексирования
и испытаний, имеется возможность сокращения сроков програм-
мирования после выделения большего числа людей для параллель-
Таблица 5.2
Распределение по фазам затрат труда. */•, и сроков выполнения работ,
•/•, для программ распространенного типа
Фаза Размер изделия
малый промежу- точный средний большой
Затраты труда
Планирование и анализ требований 6 6 6 6
Проектирование изделия 16 16 16 16
Программирование 68 65 62 59
детальное проектирование 26 25 24 23
кодирование и автономная отладка 42 40 38 36
Комплексирование и испытание 16 19 22 25
Всего 100% 100% Ю0о/0 100%
Сроки
Планирование и анализ требований 10 11 12 13
Проектирование изделия 19 19 19 19
Программирование 63 59 55 51
Комплексирование и испытание 18 22 26 ^0
Всего 100% 100% 100% юо%
ных работ. В менее крупных программных проектах наблюдается
более равномерное (пологое) распределение числа исполнителей
по фазам и выделяется относительно меньше ресурсов в фазе комп-
лексирования и испытаний. (Как крупные, так и малые распро-
страненные программные проекты имеют относительно пологие
распределения числа исполнителей по сравнению с другими типа-
ми разработок, которые обсуждаются в гл. 6.)
В качестве примера использования табл. 5.2 рассмотрим преж-
ний проект среднего размера (32 КЧИК) разработки системы уче-
та запасов сырья, для которой в базовой КОМОСТ определены
затраты 91 ЧМ и сроки 14 месяцев. Предположим, что нужно было
оценить затраты, сроки, а также число исполнителей. По табл. 5.2
на программирование требуется 62% всех затратили 0,62-91 ЧМ=
=56 ЧМ. По этой же таблице на программирование требуется
55% срока разработки или 0,55-14 мес.=7,7 мес.
73
Среднее число специалистов по программированию определяет-
ся следующим образом:
56 ЧМ/7,7 мес.=7,3 ЧИ.
5.S. НОМИНАЛЬНЫЕ ХАРАКТЕРИСТИКИ ПРОЕКТОВ
Используя данные табл. 5.2, можно получить значения затрат,
сроков и числа исполнителей для других фаз среднего (32 КЧИК)
проекта. Эта информация и аналогичные данные для других про-
ектов стандартного размера приведены в табл. 5.3, в которой ука-
зана также и производительность труда в единицах ЧИК/ЧМ.
Таблица 5.3
Основные характеристики программ распространенного типа
Размер изделия, КЧИК Малый, 2 Промежу- точный, 8 Средний, 32 Большой 128
Полные затраты труда, ЧМ 5,0 21,3 91 392
Планирование и анализ требований 0,3 1,3 5 24
Проектирование изделия 0,8 3,4 15 63
Программирование 3,4 13,8 56 231
детальное проектирование 1,3 5,3 22 90
кодирование и автономная отладка 2,1 8,5 34 141
Комплексирование и испытания 0,8 4,1 20 98
Полные сроки разработки, мес. 4,6 8 14 24
Планирование и анализ требований 0,5 0,9 1.7 3,1
Проектирование изделия 0,9 1,5 2,7 4,6
Программирование 2,9 4,7 7,7 12,2
Комплексирование и испытания 0,8 1,8 3.6 7,2
Среднее число исполнителей, ЧИ
Планирование и анализ требований 0,6 1,4 2,9 8
Проектирование изделия 0,9 2,3 5,6 14
Программирование 1,2 2,9 7,3 19
Комплексирование и испытания 1,0 2,3 5,6 14
Проектное среднее число исполните- 1,1 2,7 6,5 16
лей, ЧИ
Доля среднего числа исполнителей, %
Планирование и анализ требований 60 55 50 46
Проектирование изделия 84 84 84 84
Программирование 108 ПО 113 116
Комплексирование и испытания 89 87 85 83
Производительность, ЧИК/ЧМ 400 376 352 327
Из табл. 5.3 можно увидеть относительные характеристики раз-
личных фаз и проектов и некоторые последствия расширения мас-
штабов проекта. Например, если предполагается разрабатывать
изделие (объемом 32 КЧИК) в 4 раза крупнее любого из ранее
Z4
созданных изделий объемом 8 КЧИК, то следует ожидать умень-
шения производительности труда для всего проекта до 94% от
прежней производительности труда (от 376 до 352 ЧИК/ЧМ).
Это уменьшение производительности труда для более крупных
проектов называется в экономике отрицательным эффектом мас-
штаба. (Положительные и отрицательные эффекты масштаба бу-
дут обсуждаться в гл. 11.) Главными причинами отрицательных
эффектов масштаба при разработке более объемных программ-
ных изделий являются следующие.
1. Требуются более трудоемкие работы по детальной специфи-
кации блоков программы для организации параллельной работы
большего числа программистов.
2. Требуются относительно большие затраты труда для вери-
фикации и подтверждения более объемных спецификаций требова-
ний к ПО и проекта.
3. Даже при наличии детальных спецификаций программисты
большого проекта будут тратить относительно больше времени на
обсуждение и решение вопросов интерфейса.
4. Требуются относительно большие затраты на комплексиро-
вание блоков программы.
5. Как правило, требуется более сложная отладка для верифи-
кации и подтверждения программного изделия.
6. Требуются относительно большие затраты труда на управле-
ние проектом.
Процентные соотношения для числа исполнителей проекта,
взятые из табл. 5.3, дают распределения с более высоким пиком
для крупных проектов, что соответствует увеличению объема па-
раллельно проводимых работ на фазе программирования. На
рис. 5.4 проиллюстрированы распределения исполнителей (в долях
от среднего числа исполнителей) для малого, среднего и большого
проектов программных изделий распространенного типа.
5.6. РАСПРЕДЕЛЕНИЕ РЭЛЕЯ
В КОМОСТ средние оценки числа исполнителей разработки
образуют ступенчатые распределения (см. рис. 5.4). На самом же
деле усредненное число исполнителей, особенно в случае больших
проектов, изображается скорее непрерывной кривой, поскольку
маловероятно одновременное привлечение большого числа людей.
Примеры таких кривых также представлены на рис. 5.4.
Известна математическая функция, дающая хорошее прибли-
жение для графиков распределения числа исполнителей для мно-
гих типов программных проектов, включая широко распространен-
ные программные изделия. Это функция распределения Рэлея для
числа исполнителей:
ЧИ = ЧМ (t/tfy (5.3)
75
Рис. 5.4. Распределение исполнителей программ распространенного типа:
--------— большой (128 КЧИК);
----------средний (32 КЧИК);
-------малый (2 КЧИК) проекты
где переменная t задает месяц, для которого вычисляется значе-
ние ЧИ, a tD — месяц, для которого число исполнителей достигает
наибольшего значения.
В работах [225, 226] было показано, что распределение Рэлея
является довольно хорошим приближением для распределений чис-
ла исполнителей для многих научно-исследовательских и опытно-
конструкторских работ. Результаты указанных публикаций допол-
няются данными работ [241, 243], в которых подтверждается пра-
вильность аппроксимации распределений числа исполнителей для
ряда прогоаммных проектов распределением Рэлея. Проведенный
в последних работах анализ распределения Рэлея позволил уста-
новить зависимости между затратами труда и сроками разработок
(см. гл. 6 и 27).
Применение к разработкам распространенных программных
проектов. На рис. 5.5 показано распределение Рэлея для среднего
(32 КЧИК) программного проекта, для которого ЧМ=91,
tn—1 мес, или половине оценки сроков разработки (14 мес.).
Очевидно, что форма кривой распределения Рэлея не является
в полной мере хорошим приближением для реальных распределе-
ний числа исполнителей в проектах распространенного типа (ср.
рис. 5.4 и 5.5). Это объясняется, главным образом, тем, что в ра-
боту над такими проектами сразу включается большая часть уча-
стников (вместо более медленного развертывания работ, как дик-
туется распределением Рэлея), и тем, что график распределения
Рэлея медленно приближается к нулю с ростом I.
76
Однако центральная часть распределения Рэлея дает хорошее
приближение для графиков распределения числа исполнителей.
Если для представления в КОМОСТ всей разработки в моменты
времени от 0 до конца СР использовать только часть распределе-
ния Рэлея от 0,3 tD до 1,7 tD, то можно получить следующее урав-
нение для оценки числа исполнителей:
(0,15-СР4-0,7О«
ЧИ = ЧМ °.15-СР+0-7% °-5-ср1 (5.4)
0,25-СР2
Это уравнение обеспечивает достаточно хорошее приближение
к сглаженному распределению числа исполнителей для оценок по
базовой КОМОСТ среднего (32 КЧИК) проекта (см. рис. 5.6).
Единственным существенным отличием является более медленное
убывание распределения Рэлея при больших t, и это подтвержда-
Рис. 5.5. Распределение Рэлея для tB—7 и ЧМ=91
Рис. 5.6. Распределения Рэлея и оценка по КОМОСТ для среднего проекта
(32 КЧИК, 91 ЧМ, длительность разработки 14 мес.)
ется на многих проектах. Таким образом, уравнение (5.4) можно
использовать как довольно эффективное средство оценки числа
исполнителей в любой момент времени разработки программного
проекта распространенного типа.
J.7. ИНТЕРПОЛЯЦИЯ
Рассмотрим количественное планирование на фазе программи-
рования изделия размером 12,8 КЧИК. Легко вычислить полные
затраты труда и сроки разработки:
Затраты труда —2,4-12,81105=35 ЧМ;
Сроки разработки=2,5-35°’38=9,7 мес.
Чтобы получить оценки для фазы программирования, следует
использовать табл. 5.2. Поскольку рассматриваемый проект имеет
нестандартный размер, для получения нужных значений необхо-
димо воспользоваться интерполяцией данных из табл. 5.2.
Вначале можно определить, что рассматриваемый проект раз-
мером 12,8 КЧИК на 20% разницы двух стандартных размеров
(8 и 32 КЧИК) больше промежуточного проекта. Согласно же ли-
нейной интерполяции процент затрат на программирование для
77
рассматриваемого проекта будет меньше затрат для промежуточ-
ного проекта на 20% разницы между значением 65% для проме-
жуточного проекта и значением 62% для среднего проекта, т. е.
составит 64,4% (см. рис. 5.7).
Рис. 5.7. Линейная интерполяция
В общем случае, если имеются две точки в таблице (х0, Уо) и
(xi, yi) и нужно посредством линейной интерполяции найти значе-
ние у для х, расположенного между х0 и х, (x0^x^Xi), то можно
использовать следующую формулу:
0=4fo+[(x—х0)/(Х1— хо)] (yi— Уо) (5.5)
Подставляя приведенные выше значения, можно убедиться, что
действительно
у=65+[(12,8—8)/(32—8)] (62--65) =65+(0,2) - (—3)=64,4.
Привеченной формулой линейной интерполяции будем пользо-
ваться при работе со всеми таблицами КОМОСТ. Эта же формула
может быть использована для экстраполяции за пределы диапазо-
нов, задаваемых данными таблиц КОМОСТ (например, для оцен-
ки проектов размером 1000 или 1000 000 ЧИК), но это весьма
рискованно, поскольку КОМОСТ не была проверена вне этих пре-
делов. В частности, необходимо проявлять крайнюю осторожность
при использовании КОМОСТ или любой другой алгоритмической
модели стоимости для изделий размером менее 2 КЧИК, так как
в случае малых проектов влияние индивидуальных различий раз-
работчиков, по-видимому, существенно превосходит влияние всех
других факторо!
Продолжим анализ рассматриваемого проекта размером
12,8 КЧИК Путем интерполяции сроков разработки (см. табл. 5.2)
можно установить, что на фазу программирсьания потребуется
58,2% общих сроков. В заключение вычислим для фазы програм-
мирования затраты труда, сроки разработки и среднее ЧИ:
Затраты груда = 0,644-35 ЧМ — 225 ЧМ;
Сроки разработки = 0,582-9,7 мес. = 5,6 мес.;
Среднее ЧИ = 22 5/5,6=4,0 ЧИ.
7Ь
iA. ОЦЕНКА ЗАТРАТ НА СОПРОВОЖДЕНИЕ ПО
Оценку годового сопровождения в базовой КОМОСТ вычисля-
ют с помощью коэффициента пересчета годовых изменений
(КПГИ), т. е. доли исходных команд программного изделия, кото-
рые добавляются или модифицируются в течение типичного года
(см. разд. 4.8). Например, предположим, что в течение первого го-
да сопровождения программное изделие размером 32 КЧИК пре-
терпело следующие изменения: было добавлено 4 КЧИК и моди-
фицировано 2,4 КЧИК. В этом случае
КПГИ = (4 + 2,4)/32 = 6,4/32 = 0,20.
В уравнении оценки основных ежегодных затрат на сопровожде-
ние ЧМг.с Используется значение затрат труда на разработку
ЧМР; это уравнение имеет вид
ЧМГ.С = 1,0КПГИ • ЧМР. (5.6)
Поскольку затраты труда исполнителей программного проекта
составляют 12 ЧМ в год, легко вычислить значение ЧМС для со-
провождения по следующей формуле: ЧМС = ЧМгс/12.
Например, рассмотрим сопровождение программного изделия
объемом 32 КЧИК с КПГИ — 0,20. На разработку этого изделия
согласно данным табл. 5.3 потребуется 91 ЧМ. Теперь можно оце-
нить затраты труда на первый год сопровождения: ЧМГ.С =
=0,2-91 =18 ЧМ и значение ЧИ, необходимого для сопровожде-
ния: 18/12=1,5 ЧИ.
ГЛАВА 6
БАЗОВАЯ КОМОСТ И ТИПЫ РАЗРАБОТОК
6.1. ВВЕДЕНИЕ
Представленная выше базовая КОМОСТ позволяет оценить
основные затраты труда и сроки для наиболее распространенного
типа разработок, собственных разработок малых и средних изде-
лий в обычных условиях.
Важным результатом, полученным в ходе приведших к напи-
санию книги исследований, является вывод о существовании не-
скольких типов программной разработки. Затрать! для этих типов
разработки оцениваются похожими по форме выражениями, кото-
рые однако дают существенно различные результаты при одинако-
вом размере программ.
В этой главе приводятся формулы оценки для двух других ти-
пов разработок: крайне напряженного встроенного типа и проме-
жуточного полунезависимого типа.
В разд. 6.2 для каждого типа приведены основные уравнения
затрат труда и сроков разработки. В разд. 6.3 описаны характер-
79
ные черты каждого типа и обсуждена его зависимость от вида вы-
полняемых работ. В разд. 6.4 представлена база данных КОМОСТ
по 63 проектам и показана степень подтвержденности оценок фак-
тическими данными. Наконец, в разд. 6.5 приведены и обсуждены
таблицы оценок распределений затрат по фазам для всех трех
типов разработок.
6.2. ОСНОВНЫЕ УРАВНЕНИЯ ЗАТРАТ
В табл. 6.1 приведены уравнения базовой КОМОСТ для оценки
труда и сроков разработок распространенного, полунезависимого
и встроенного типов. В табл. 6.2 приведены примеры оценок, полу-
чаемых из этих уравнений, оценки производительности труда и
Таблица 6.1
Уравнения базовой КОМОСТ для оценки затрат труда и сроков разработки
Тип разработки Затраты труда Срок разработки
Распространенный Полунезависимый Встроенный ЧМ=2,4-КЧИК1'05 ЧМ=3,0 КЧИК1’12 ЧМ=3,6-КЧИК1’20 СР=2,5ЧМ°'38 СР=2,5-ЧМ0'55 СР = 2,5-ЧМ°-32
Таблица 6.2
Оценки по базовой КОМОСТ для разработок изделия стандартных размеров
Характеристика Тип разработки Оценка для размеров
малого, 2 КЧИК промежу- точного, t 8 КЧИК среднего 32 КЧИК большого, 128 КЧИК очень большого, 512 КЧИК
Затраты труда, Распространенный 5,0 21,3 91 392 —
ЧМ Полунезависимый 6,5 31,0 146 687 3250
Встроенный 8,3 44,0 230 1216 6420
Производитель- Распространенный 400 376 352 327 —
ность труда, Полунезависимый 308 258 219 186 158
ЧИК/ЧМ Встроенный 241 182 139 105 80
Сроки разработ- Распространенный 4,6 8,0 14 24 —
ки, мес. Полунезависимый 4,8 8,3 14 24 42
Встроенный 4,9 8,4 14 24 41
Среднее число ис- Распространенный 1,1 2,7 6,5 16 —
полнителей, ЧИ Полунезависим ый 1,4 3,7 10,0 29 77
Встроенный 1,7 4,2 16,0 51 157
80
среднего числа исполнителей, участвующих в разработке, по всем
типам программных разработок следующих стандартных размеров:
Малый................................... 2 КЧИК
Промежуточной........................... 8 КЧИК
Средний................................. 32 КЧИК
Большой................................ 128 КЧИК
Очень большой.......................... 512 КЧИК
На рис 6.1 и 6.2 для трех типов показана зависимость затрат
от размеров изделия, на рис. 6 3 — зависимость оценок сроков
разработки от затрат труда. Главные различия типов разработок
видны из этих рисунков и заключаются в следующем:
1. При одинаковом размере программных изделий для встроен-
ного типа разработок оценки затрат труда значительно больше, а
произвоцительность труда значительно меньше, чем для распро-
страненного типа.
2. При увеличении размера изделия производительность труда
(отрицательный эффект масштаба!) снижается более заметно для
встроенного типа разработки.
3. Зависимость оценки сроков разработки от размеров изделия
примерно одинакова для всех типов.
4. При одинаковых сроках разработки на встроенный проект
потребуются большие затраты труда.
В следующих двух разделах более подробно описаны типы раз-
работок и обсуждены перечисленные различия.
₽ис f 1. Оценка затрат труда по базовой КОМОСТ для трех типов разработок
81
Рис. 6.2. Оценка сроков разработки по базовой КОМОСТ для трех типов раз
работок
Рис. 6.3. Зависимость оценок сроков по базовой КОМОСТ от затрат труда для
трех типов разработок
82
6.3. ТРИ ТИПА ПРОГРАММНОЙ РАЗРАБОТКИ
Данные табл. 6.2 и рис. 6.1—6.3 показывают, как важно инже-
неру-программисту уметь распознавать различные типы програм-
мной разработки. Например, если ему необходимо разработать
встроенное изделие среднего размера (32 КЧИК), а оценка и
укомплектование проекта исполнителями осуществлены как для
распространенного проекта, то произойдет серьезная недооценка
затрат труда (будет получена оценка в 91 ЧМ вместо 230 ЧМ).
Кроме того, такое планирование штатов проекта приведет к труд-
но исправимым ситуациям (такое случилось со многими програм-
мными проектами).
Распространенный тип характеризуется тем, что ПО разраба-
тывается относительно небольшой группой специалистов в весьма
знакомых условиях своей фирмы, большинство связанных с про-
ектом людей обладают большим опытом работы с аналогичными
системами в условиях своей организации и хорошо понимают, как
и каким образом разрабатываемая система будет способствовать
достижению целей фирмы.
Это означает, что большинство участников проекта могут с
пользой участвовать на начальных стадиях разработки, не созда-
вая при этом больших накладных расходов на обмен информацией
о сущности проекта и занятиях других участников Этим объясня-
ется относительно пологий характер функции распределения чис-
ла исполнителей для распространенного проекта (см. гл. 5). Это
также означает, что с увеличением размера проекта потери произ-
водительности труда, вызываемые накладными расходами на обмен
информацией, возрастают сравнительно немного.
В проекте распространенного типа налагаются относительно
менее жесткие ограничения на соответствие ПО требованиям и
спецификации интерфейса. Если возникает ситуация, при которой
достижение такого соответствия привело бы к большим переработ-
кам, то бригада разработчиков может, как правило, договориться
об изменении спецификаций, облегчающем обновление изделия и
адаптацию пользователя. Это еще одна причина более высокой
производительности труда и меньшего отрицательного эффекта
масштаба для распространенного проекта.
Другими характерными чертами программных проектов распро-
страненного типа являются следующие:
обычно стабильные условия разработки проекта с незначитель-
ной параллельной разработкой ПО, нового технического обеспече-
ния (ТО) и вычислительного процесса;
минимальная необходимость новых системных и алгоритмиче-
ских решений проблем обработки данных;
относительно малое поощрение за раннее завершение проекта;
относительно малый размер. В очень немногих распространен-
ВЫх проектах были разработаны новые средства ПО размером бо-
Лее 50 КЧИК (более крупные изделия часто могут быть разрабо-
таны в условиях существующего ПО).
83
Приведенные характеристики проектов, по-видимому, также
являются причиной более высокой производительности труда и
меньшего отрицательного эффекта масштаба.
Полунезависимый тип программной разработки занимает про-
межуточное положение между распространенным и встроенным
типами. Промежуточность положения определяется наличием лю-
бого из следующих двух свойств:
промежуточные значения характеристик проекта;
смещение характеристик распространенного и встроенного ти-
пов.
Так, по отношению к признаку «опыт работы с аналогичными
системами ПО» полунезависимый проект может характеризовать-
ся следующими свойствами:
все члены бригады имеют средний опыт работы;
состав бригады крайне неоднороден по степени опытности;
члены бригады знакомы лишь с некоторыми характеристиками
разрабатываемой системы.
В отношении соответствия спецификаций функций и интерфей-
са типичным примером полунезависимого проекта мог бы явиться
проект разработки системы обработки сообщений с весьма стро-
гим соблюдением одних правил интерфейса (к примеру, налагае-
мых терминальным ТО или правительственными требованиями) и
с весьма гибким — других правил ( к примеру, относящихся к со-
держанию и формату сообщений на дисплее оператора и сведени-
ям о тенденциях сбыта). Эта частичная гибкость связи системы с
пользователями объясняет происхождение термина «полунезави-
симый».
В заключение укажем, что размер полунезависимых изделий
обычно не превосходит 300 КЧИК-
Встроенный тип отличается от других жесткими ограничениями
на характеристики ЭВМ и правила использования интерфейса.
Такое изделие должно работать при тесной взаимосвязи1 ап-
паратуры, программ, руководств и вычислительных процессов.
Примерами являются система резервирования авиабилетов и си-
стема управления воздушным движением. Как правило, затраты на
изменение частей комплекса настолько высоки, что гораздо выгод-
нее оставлять характеристики комплекса неизменными. Вследст-
вие этого следует ожидать стабильности ПО встроенного типа.
При разработке встроенного ПО, как правило, отсутствует воз-
можность договориться об уменьшении изменений и исправлений
в программах при модификации требований и интерфейса. Поэто-
му встроенный проект требует больших затрат на изменения и
исправления (см. графики на рис. 4.2 для затрат на исправление).
Он требует также больших затрат труда на установление соответ-
ствия ПО своим спецификациям (более высокие затраты на вери-
фикацию и подтверждение) и обеспечение правильности изменений
1 Программное обеспечение встроенного типа разрабатывается для ЭВМ,
встроенной в техническую систему. — Прим, перев.
84
(более высокие затраты на управление конфигурацией). Все эти
факторы приводят к уменьшению производительности труда, а
также к увеличению отрицательного эффекта масштаба для боль-
ших проектов.
По сравнению с распространенным встроенный проект, как пра-
вило, планируется при меньшем объеме информации об условиях
его реализации. Это заставляет использовать малую бригаду ана-
литиков на ранних стадиях проекта, в противном случае огромные
накладные расходы на обмен информацией погубили бы проект
в самом начале.
После завершения проектирования изделия лучшей стратегией
осуществления встроенного проекта является привлечение очень
большой группы программистов для параллельного выполнения
детального проектирования, кодирования и автономной отладки.
В противном случае для завершения проекта потребовалось бы
гораздо больше времени, что было бы нежелательно по двум глав-
ным причинам:
в изделие пришлось бы включать большее число изменений;
к моменту поставки изделие устарело бы в большей степени.
(Вообще говоря, за раннее завершение проекта встроенного типа
поощряют в большей степени, что часто обусловливается необхо-
димостью быстрого ввода в строй всего комплекса.) Для встроен-
ных проектов указанная стратегия приводит к более высоким пикам
функции распределения числа исполнителей и к большим затра-
там труда, чем в проектах распространенного типа, реализуемых в
такие же общие сроки *.
Краткие итоги. Итоги сравнения характеристик трех типов про-
граммной разработки приведены в табл. 6.3 вместе с типичными
примерами проектов. В табл. 6.4 приведена сводка другого типа,
показывающая главные отличия работ на разных фазах проекта в
зависимости от типа программной разработки. Данные этой табли-
цы позволяют лучше понять причины роста отрицательного эффек
та масштаба для встроенных проектов: более крупные проекты
имеют больший относительный объем внутренних и внешних интер-
фейсов, усложняющих управление и переработку.
Для окончательного подытоживания различий приведем при-
меры функционально похожих программных систем предсказания
положения самолета по показаниям многочисленных датчиков.
Распространенный тип (обработка послеполетных данных в
авиации): «По опыту последних десяти лет программирования этих
алгоритмов известно, насколько хороши они для предсказания по-
ложения самолета. Если произойдет что-то неожиданное, и ошибка
или время вычислений окажется значительно больше обычного, то
специалисты по анализу данных просто примут это к сведению».
’ Проекты распространенного типа обладают также тем преимуществом, что
большинство программистов принимают участие в более ранних стадиях анализа,
а это приводит к еще большему разрыву по производительности труда между
Распространенными и встроенными типами проектов.
85
§ Таблица 63
Сравнительные характеристики типов программной разработки
Тип разработки Распространенный Полунезависимый Встроенный
Понимание целей изделия Опыт работы с аналогичными систе- Полное Значительное Общее
мами Необходимость соответствия ПО тре- Большой Значительный Умеренный
Сованиям Необходимость соответствия ПО спе- Относительная Значительная Полная
цификациям внешнего интерфейса Параллельная разработка новых ТО Относительная Значительная Полная
и вычислительных процессов Необходимость новых системных и алгоритмических решений проблем Незначительная Умеренная Большая
обработки данных Поощрение за раннее завершение Минимальная Незначительная Значительная
проекта Малое Среднее Большое
Размер изделия <50 КЧИК <300 КЧИК Любо!
Примеры Пакетная обработка дан- ных Системы обработки сооб- щений Большие системы обработ- ки сообщений
Научно-исследовательские модели Экономические модели Обычные ОС, трансляторы Новые ОС, СУБД Мощные системы управле- ния запасами, производст- венными процессами Мощные; очень большие ОС Авиационные радиоэлект- ронные системы
Простые системы управле- ния запасами, производст- сенными процессами Простые оперативные си- стемы управления Мошные оперативные си- стемы управления
Примечание ОС — операционная система, СУБД — система управления базой данных.
Таблице /1,4
Различия работ рад проектом на разных фазах в зависимости от типа программной разработки
Тип разработки Анализ требований и проекти- рование изделия Детальное проектирование Кодирование и автономная отладка Ком нлекенроввн ие и испытание
Встроенный Полунезависимый Распространенный Большие переработки при из- менении спецификаций — — ». Строго формализован- Полные спецификация и под- ное управление конфи- тверждение требований и ин- гурацией н контроль ин- терфейса терфейса — — . —— —► Большие перера- Большой объем работ по ана- ботки при измене- лизу, изготовлению прототипов НИН кодов »- элементов Большой объем прове- рок соответствия требо- ваниям, интерфейсу Промежуточный объем указан- ных выше работ ► Относительно небольшие пере- работки при изменении спецн ф и к а и и н Довольно общие специфика- Довольно неформализо- ции и подтверждение требова- санные управления кон- ннй и интерфейса фигурацией и контроле — ► интерфейса Умеренные пере- Нерегулярные анализ и изго- работки при из- товленне прототипов элементов мененни кодов — - Умеренный объем про-
Верок соответствия тре-
бованиям, интерфейсу
°?
Полунезависимый тип (тренажер для обучения управлению са-
молетом): «Для этого тренажера необходима довольно большая
точность, а датчики данных несколько отличаются от обычных; их
главным назначением является обеспечение своевременного вычис-
ления положения имитируемого самолета для каждого цикла фор-
мирования изображения на дисплее. Если для удовлетворения вре-
менных ограничений необходимо уменьшить точность, то на это
можно пойти».
Встроенный тип (бортовая система предотвращения столкнове-
ний): «Поскольку будет использован новый радиолокатор, придет-
ся провести эксперименты для поиска алгоритма с требуемыми точ-
ностью и скоростью работы. Если удовлетворительный алгоритм не
будет найден, то придется перерабатывать всю систему предотвра-
щения столкновений».
Большой программный проект может включать несколько под-
проектов различных типов (например, ПО управления полетом раз-
рабатывается как встроенный тип, а вспомогательное ПО — как
распространенный) Кроме того, если подпроекты не очень сильно
связаны и не вызывают друг у друга отрицательных эффектов мас-
штаба, затраты на них следует оценивать независимо, как для не-
скольких менее крупных проектов.
6.4. ОБСУЖДЕНИЕ УРАВНЕНИЙ БАЗОВОЙ КОМОСТ
База данных КОМОСТ. Оценочные уравнения базовой
КОМОСТ (как и другие версии) были получены в результате ана-
лиза тщательно составленной выборки 63 программных проектов.
В табл. 6.5 приведены основные итоговые характеристики базы
данных (более подробная информация приводится в гл. 29).
Как видно из таблицы, распределение характеристик проектов
не типично ни для современных программных проектов (например,
недостаточно данных по Коболу), ни для вероятных будущих (на-
пример, недостаточно данных по микропроцессорам). Однако в
этой базе данных все же имеются типичные представители всех
главных областей разработки ПО и вместе с тем не замечено су-
щественного расхождения данных с оценками КОМОСТ. Кроме
того, используемая база данных обладает еще одним важным до-
стоинством: все характеристики данных определены тщательно и
согласованы в смысле таких терминов, как «конечные исходные
команды», «разработка», «человеко-месяц» и т. п.
Сравнение оценок по уравнениям затрат с фактическими дан-
ными. На рис. 6 4 приводится такое сравнение для 63 проектов.
Заметим, что для идеальной модели все экспериментальные точки
находились бы на диагонали, соответствующей равенству оценок
и фактических данных.
Поскольку экспериментальные точки находятся близко к диа-
гонали, результаты сравнения кажутся удовлетворительными
Однако не следует проявлять излишний оптимизм, основываясь
на внешнем виде представленных в логарифмическом масштабе
88
Таблица 6.5
Основные характеристики базы данных КОМОСТ
Характеристика Число данных Производитель- ность труда, чик/чм
Вся база данных 68 20...1250
Тип разработок: 82...1250
распространенный 23
полунезависимый 12 41...583
встроенный 28 20...667
Тип ПО:
экономическое 7 55. .862
.управления 10 20...304
диалоговое 13 28—336
научное 17 47...1250
. вспомогательное 8 82 583
системное 8 28-667
Годы разработки: 113. 775
1964—1969 3
1970—1974 14 20...485
1975—1979 46 41...1250
Тип ЭВМ:
большая 31 28... 1250
средняя 7 114...583
мини 21 20...723
микро 4 41...379
Языки программирования: 28...883
Фортран 24
Кобол 5 55—862
Джовиал 5 45...583
ПЛ/1 1 93... 1250
Паскале 2 336-560
Другие ЯВУ 3 124-300
Язык ассемблера 20 20-667
Примечание. ЯВУ — язык высокого уровня.
результатов. Для практического прогнозирования важно отметить,
что оценки по базовой КОМОСТ отличаются от фактических дан-
ных не более чем на 30% только в 29% проектов и не более чем
на 100% — в 60%.
Зависимость уравнений затрат от типа разработки. На рис. 6.5
показаны графики оценочных уравнений базовой КОМОСТ для
трех типов разработок. Точки соответствуют фактическим разме-
рам и затратам труда для каждого проекта.
Главные выводы из данных рис. 6.4 и 6.5 следующие:
1. Три типа разработок отчетливо различаются по производи-
тельности труда и эффектам масштаба.
2. Оценочные уравнения базовой КОМОСТ получены не мето-
дом наименьших квадратов по экспериментальным данным и не
являются оптимальными. Фактически на имеющейся выборке опти-
мальное приближение дало бы большее различие между типами
разработок. Оптимальные приближения не используются в базо-
вой КОМОСТ по следующим причинам:
89
числовые коэффициенты и форма уравнений легко запоминают-
ся и упрощают расчет (простота);
уравнения не меняются при добавлении в базу новых данных
по новым проектам (устойчивость);
соотношения сохраняют постоянство и для более детальных
версий КОМОСТ (инвариантность).
3. Оценочные уравнения не отличаются высокой точностью.
Рис. 6.4. Сравнение затрат труда, полученных по базовой КОМОСТ, с фактиче-
скими данными для трех типов разработок:
о — распространенный, А — встроенный, х — полунезависимый тип разработки
Как упоминалось ранее, они дают оценку фактических затрат
труда и стоимости.
4. Оценочные уравнения имеют ту же точность, что и в случае
приближений, полученных с помощью других функций одной пе-
ременной. Лучших результатов трудно ожидать, поскольку, кроме
КЧИК, имеется еще большое число множителей, учитывающих дру-
гие затраты на разработку программного изделия. Как будет пока-
зано в гл. 8, промежуточная КОМОСТ обеспечивает гораздо более
точное приближение к фактическим данным за счет включения не-
скольких новых множителей.
90
Сравнение различных уравнений затрат труда. В ряде других
исследований и моделей стоимости ПО используются уравнения за-
трат, имеющие ту же форму, что и уравнения базовой КОМОСТ.
Их сводка приведена в табл. 6.6. Эти уравнения нельзя сравнивать
строго, поскольку они выведены на основе различных предположе-
ний и определений (и зависят от того, учтены ли комментарии, за-
траты на анализ требований, управленческие расходы и т. п.).
КЧИК
Рис. 6.5. Сравнение оценок затрат труда, полученных из уравнений базовой
КОМОСТ, с фактическими данными для трех типов разработок:
О-------распространенный» ЧМ=2,4-КЧИК1«05:
X —— ----полунезависимый, ЧМ=3,0-КЧИК,>|2;
А------— встроенный, ЧМ.=3,6«КЧЙК1»20
Весьма интересны различия в приведенном спектре моделей.
Они отражают как тот факт, что в большом проекте имеются отри-
цательные эффекты масштаба (в расчете на одну команду требу-
ются большие затраты на проектирование изделия и комплексиро-
вание, а также большие накладные расходы на обмен информа-
цией и т. д.), так и то, что возможен положительный эффект мас-
штаба (вкладывая капитал в средства автоматизации и стандар-
тизации, можно в больших программах существенно возместить
такие затраты). Уравнения базовой КОМОСТ показывают, что от-
рицательные эффекты масштаба превышают положительные для
91
встроенных проектов. Все три уравнения КОМОСТ занимают про-
межуточное положение среди других уравнений по значениям
коэффициентов и показателей степени.
Сравнение оценок по уравнениям сроков с фактическими дан-
Рис. 6.6. Сравнение оценок сроков разработки, полученных из уравнений
КОМОСТ, с фактическими данными:
I О — распространенный, х — полунезависимый, А — встроенный тип разработки; • , А — по-
шаговая разработка
фактическими значениями для 63 проектов базы данных КОМОСТ,
а на рис. 6.7 сравниваются графики, полученные по уравнениям
КОМОСТ, с фактическими данными для разных типов проектов.
Главные выводы, которые можно сделать из анализа рис. 6.4
и 6.5 аналогичны выводам, полученным при сопоставлении урав-
нений и данных по затратам труда:
1. Три типа разработок отчётливо различаются (рис. 6.7), хотя
различие менее заметно для полунезависимого типа разработки.
92
Таблица 6.6
Сравнение уравнений затрат труда
Модель или исследование Уравнение
См. [291 ЧМ=5,2 - КЧИК °-91
См. [224 ЧМ=4,9 -КЧИК0-90
См. [116 ЧМ=1,48-КЧИК1-02
КОМОСТ (проект распространенного
типа ЧМ=2,4 -КЧИК'-05
См. [1471 ЧМ=5.3 -КЧИК'-06
КОМОСТ (проект полунезависимого ти-
па) ЧМ=3,0 -КЧИК1-,2
См. [1171 ЧМ=2,43-КЧИК1-18
КОМОСТ (проект встроенного типа) ЧМ=3,6 КЧИК'-20
См. 238 ЧМ=0,99-КЧИК'-275
См. 164 ЧМ=1,0 КЧИК1-40
См. [292 ЧМ=1,]2-КЧИК'-43
См. 141 ЧМ=О,7О-КЧИК'-50
См. 265 ЧМ=28 -КЧИК'-83
2. Уравнения оценки сроков приемлемы, но не оптимальны (см.
рис. 6.6 и 6.7).
3. Уравнения оценки сроков более точны, чем уравнения оцен-
ки затрат труда. В 58% случаев оценки сроков отличаются от фак-
тических данных не более чем на 20%. Однако точность оценок
Рис. 6.7. Сравнение оценок сроков, полученных из уравнений КОМОСТ, с фак-
тическими сроками (исключая проекты с применением пошаговой разработки):
О-----СР=2,5-ЧМ°-38 (распространенный тип);
х-------CP=2,5-4M°-3S (полунезависимый тип):
Д-----— СР=2,5-ЧМ0*32 (встроенный тип)
93
существенно меняется для различных проектов из-за того, что
сроки выполнения некоторых из них были затянуты вследствие
частых изменений требований заказчика и неэффективного плани-
рования *.
4. Для проектов с пошаговой разработкой оценка сроков по
уравнениям занижена (см. рис. 6.6).
Таблица 6.7 позволяет сравнить уравнения базовой КОМОСТ
для оценки сроков с другими уравнениями. Приводимые данные на
редкость хорошо согласуются друг с другом, особенно принимая во
внимание отсутствие в некоторых моделях точного определения
начала и конца разработки. (Следует заметить, что до сих пор не
Таблица 6.7
Сравнение уравнений сроков разработки
Модель или исследование Уравнение
См. [116J КОМОСТ (проект встроенного типа) См. [243| КОМОСТ (проект полунезависимого ти- СР=4,38-ЧМ°-25 СР=2,5 -ЧМ0-32 СР--2,15-ЧМ°-333
па) См. [291] См [224] КОМОСТ (проект распространенного СР=2,5 -ЧМ1*-36 СР=2,47-ЧМ°>зв СР=3,04ЧМ°-зв
типа) СР=2,5 -ЧМ0-33
было дано хорошего объяснения в терминах характеристик проек-
тов приводимой в таблице зависимости между затратами труда и
сроками, а поиск такого объяснения является одной из самых ув-
лекательных исследовательских проблем в области оценки затрат
на ПО.)
6.5. РАСПРЕДЕЛЕНИЕ ЗАТРАТ ТРУДА И СРОКОВ РАЗРАБОТКИ ПО ФАЗАМ
Долевое распределение. Обсуждение различий между тремя
типами проектов при создании ПО, возможно, заставило читателя
ожидать, что оценки распределений затрат по фазам для этих про-
ектов будут существенно отличаться. Такие отличия действительно
имеются и они отражены в табл. 6.8.
Основные отличия распределений затрат труда и сроков для
полунезависимого, встроенного и распространенного типов проектов
(см. рис. в разд. 5.4 и 5.5) следующие.
1 Например, время разработки одного проекта увеличилось из-за того что
подготовка тестовых данных не была проведена до начала отладки. В резуль-
тате группа отладки не смогла успешно работать до завершения подготовки
тестовых данных, на что потребовалось три месяца и что легко можно было бы
сделать заранее.
94
Таблица 6.8
Распределение затрат труда, •/., и сроков, %, по фазам для всех типов разработок
Тип разработки Фаза Размер проекта. КЧИК
малый, 2 промежу- точный, 8 средний, 32 большой. 128 очень большой. 512
Затраты труда
Распространенный Планирование и анализ требований 6 6 6 6 —
Проектирование изделия 16 16 16 16 —
Программирование: 68 65 62 59 —
детальное проектирование 26 25 24 23 —
кодирование и автономная отладка 42 40 38 36 —
Комплексирование и испытание 16 19 22 25
Полунезависимый Планирование и анализ требовании 7 7 7 7 7
Проектирование изделия 17 17 17 17 17
Программирование: 64 61 58 55 52
детальное проектирование 27 26 25 24 23
кодирование и автономная отладка 37 35 33 31 29
Комплексирование и испытание 19 22 25 28 31
Встроенный Планирование и анализ требований 8 8 8 8 8
Проектирование изделия 18 18 18 18 18
СП
Тип разработки Фаза
малый. 2
Программирование: детальное проектирование кодирование и автономная отладка Комплексирование и испытание 60 28 32 22
Сроки разработок
Распространенный Планирование и анализ требований Проектирование изделия Программирование Комплексирование и испытание 10 19 63 18
Полунезависимый Планирование и анализ требований Проектирование изделия Программирование Комплексирование и испытание 16 24 56 20
Встроенный Планирование и анализ требований Проектирование изделия Программирование Комплексирование и испытание 24 30 48 22
_______________Окончание табл. 6.8
Размер проекта. КЧИК
промежу- точный. | средний. 32 большой, 128 очень большой. 512
8
57 54 51 48
27 26 25 24
30 28 26 24
25 28 31 34
11 12 13 —
19 19 19 —
59 55 51 —
22 26 30 —
18 20 22 24
25 26 27 28
52 48 44 40
23 26 29 32
28 32 36 40
32 34 36 38
44 40 36 32
24 26 28 30
1. Встроенный проект требует значительно больших затрат на
фазе комплексзрования и испытаний. Это объясняется необходи-
мостью для встроенного (а также и для полунезависимого) проек-
тов более тщательных соблюдения и верификации программных
требований и спецификаций интерфейса.
2. Встроенный проект требует относительно мень'ших затрат тру-
да на фазе кодирования и автономной отладки. Это является ре-
зультатом относительно больших затрат труда на других фазах
разработки. Можно ли отсюда сделать вывод, что встроенный про-
ект по сравнению с распространенным требует меньших фактиче-
ских затрат труда на базе кодирования и автономной отладки?
Нет, поскольку для встроенного проекта совокупные затраты труда
на разработку, вообще более велики, в чем можно убедиться из
данных для среднего проекта (32 КЧИК) в табл. 6.9.
Таблица 6.9
Тип проекта Затраты на раз- работку, ЧМ Доля фазы коди- рования и авто- номной отлад- ки, % Затраты на кодирование и автономную отладку, ЧМ
Распространенный 91 38 35
Полунезависимый 146 33 48
Встроенный 230 28 64
Основные причины больших затрат на фазе кодирования и авто-
номной отладки встроенного проекта были приведены в табл. 6.4:
значительные переоаботки при изменении спецификаций, более
формализованный контроль изделия и значительные переработки
при изменении кодов.
3. Встроенный проект требует существенно больших сроков вы-
полнения как на фазе планирования и анализа требований, так и
на фазе проектирования изделия. Это объясняется необходимостью
^олее детальных, тщательно подтвержденных спецификаций требо-
ваний и проекта и еще большей необходимостью выполнения ука-
занных фаз относительно небольшим коллективом исполнителей.
4. Встроенный проект требует значительно меньших затрат вре-
мени на фазе программирования. Это является результатом йсполь-
Вовгния большого коллектива параллельно работающих про.рам-
‘мистов для уменьшения общих сроксв выполнения проекта (и тем
самым сокращения числа изменений изделия, которые необходимо
(учесть вс время разработки).
Использование таблиц. Таблица 6.8 используется аналогично
таб..г. 5.2 (распределение по фазам для распространенных проек-
>)- Так, требуемые значения затрат и сроков для проектов не-
стандартных размеров можно получить интерполяцией двух сосед-
них значений. Например, оценка сроков разработки на фазе комп-
лексирования и испытания встроенного изделия объемом 20 КЧИК
В Зак. 628
97
(среднее значение между 8 и 32 КЧИК) составляет 25% (среднее
значение между 24 и 26%, взятыми из табл. 6.8).
Основные характеристики проектов. В гл. 5 были рассмотрены
основные характеристики распространенных проектов различного
Таблица 6.10
Основные характеристики средних проектов
Тип проекта Распростра- ненный Полунезависи- мый встроенный
Общие затраты труда, ЧМ 91 146 230
Планирование и анализ тре-
бований 5 10 18
Проектирование изделия 15 25 42
Программирование- 56 85 124
детальное проектирование 22 37 60
кодирование и автономная
отладка 44 48 64
Комплексирование и испыта-
ние 20 36 64
Общие сроки, мес. 14 14 14
Планирование и анализ тре-
бований 1,7 2,8 4,5
Проектирование изделия 2,7 3,6 4,8
Программирование 7,7 6,8 5,6
Комплексирование и испыта-
ние 3,6 3,6 3,6
Средняя численность исполни-
телей, ЧИ 6,5 10,4 16,4
Планирование и анализ тре-
бований 2,9 3,6 4,0
Проектирование изделия 5,6 6,9 8,8
Программирование 7,3 12,5 22,1
Комплексирование и испыта-
ние 5,6 10,0 17,8
Доля от средней численности
исполнителей, %
Планирование и анализ тре
бований 45 35 24
Проектирование изделия 84 66 54
Программирование ИЗ 120 135
Комплексирование и испыта-
ние 85 96 108
Производительность труда,
ЧИК/ЧМ 352 219 139
Кодирование и автономная от-
ладка 941 667 500
размера с целью определить изменения затрат и числа исполни-
телей на различных фазах. В табл. 6.10 приводятся основные ха-
рактеристики средних (32 КЧИК) проектов, чтобы определить
изменения затрат и числа исполнителей в зависимости от типа
разработки.
98
Особенно поучительно сравнить средние значения числа испол-
нителей для распространенных и встроенных типов. Средний про-
ект может быть успешно выполнен относительно небольшой груп-
пой специалистов (менее восьми человек), большинство которых
работают над проектом в течение всей разработки. Для среднего
же встроенного проекта требуются на фазе программирования
22 специалиста, большинство которых не принимали участия на
ранних фазах.
Рис. 6.8. Распределения в базовой КОМОСТ числа исполнителей для средни
проектов (32 КЧИК)
При дальнейшем рассмотрении проектов можно заметить, что
встроенный проект потребует для завершения фазы планирования
и анализа требований, а также фазы проектирования изделия
9,3 мес.,. в то. время как распространенный проект потребовал толь-
ко 4,4 мес. (в основном вследствие более знакомых условий раз-
работки). Таким образом, для успешного выполнения встроенного
проекта необходимо существенно сократить сроки проведения ра-
бот по сравнению со сроками для распространенных проектов Кро-
ме того, необходимо учитывать, что раннее завершение встроен-
ного проекта, как правило, хорошо поощряется.
В начале фазы программирования затраты труда на оставшие-
ся работы составляют все еще 188 ЧМ. Даже если сокращение
[числа членов бригады до 8 человек могло бы уменьшить оставшие-
ся затраты труда до 120 ЧМ (весьма оптимистическое допущение),
то на завершение проекта потребовалось бы 120 ЧМ/8 ЧИ =
1= 15 мес., а не 9,2 мес., как при укомплектовании штатов до сред-
4* 99
него для фазы программирования значения 22 иИ *. Однако такое
сокращение совершенно неприемлемо, поскольку для большинства
встроенных проектов гораздо важнее получить действующую си-
стему на 6 мес. раньше, чем сэкономить 68 ЧМ за счет уменьшения
численности группы разработчиков.
Графики распределения исполнителей и распределение Рэлея.
На рис. 6.8 показаны нормированные относительно среднего числа
исполнителей графики распределения исполнителей для распро-
страненного, полунезависимого и встроенного проектов объемом
32 КЧИК На рисунке ясно видны сравнительно более пологие из-
Рис. 6.9. Распределения в базовой КОМОСТ числа исполнителей для встроен-
ных проектов:
-----очень большой (512 КЧИК); --- средний (32 КЧИК);------малый (2 КЧИК)
менения графиков в начале и более высокий максимум для проек-
тов встроенного типа (эти особенности еще более резко выражены
для очень больших встроенных проектов, как на рис. 6.9). На
рис. 6 8 приведен также график нормированного распределения
Рэлея
ЧИ = 13 300 (/2/602) е-<*/2<60>‘,
максимум которого приходится на точку, соответствующею затра-
там 60% времени разработки (константа 13 300 определяется нор-
мированием). И снова кривая Рэлея оказывается довольно хоро-
шим приближением для некоторых частей распределения числа
1 Конечно, существует предел сокращения сроков разработки при увеличении
числа исполнителей. Эта тема обсуждается в гл. 27.
исполнителей (особенно для полунезависимого типа) с тем глав-
ным недостатком, что ее значения близки к нулю в начале проекта.
Таким образом, для практического применения следовало бы
использовать некоторую часть кривой распределения Рэлея для
конкретных типов и этапов разработки, как это было сделано в
гл. 5 для распространенного типа. Вообще говоря, более легким и
реалистичным подходом является планирование числа исполните-
лей по представляемой КОМОСТ информации о среднем числе
разработчиков на каждой фазе, учитывая при этом будущие воз-
можности привлечения для работы над проектом новых специали-
стов, их предварительную подготовку и знания стратегии пошаго-
вой разработки, необходимость предварительного создания систем-
ного ПО и т. д. (указанные вопросы подробно освещаются в гл. 32).
Выводы. Учитывая приведенные в предыдущем абзаце замеча-
ния, можно сформулировать для этой главы важный вывод отно-
сительно использования аналитических моделей в планировании
штатов проекта:
Модели оказывают существенную помощь в управлении проек-
том, но окончательное принятие решения остается за человеком.
Так, если КОМОСТ или распределение Рэлея будут указывать
на необходимость привлечения к проекту еще 10 человек на следу-
ющей неделе, а руководитель будет говорить о невозможности
использования дополнительных людей в течение месяца, следует
обязательно подождать еще месяц с набором новых сотрудников.
ГЛАВА 7
БАЗОВАЯ КОМОСТ И РАСПРЕДЕЛЕНИЕ ЗАТРАТ ПО РАБОТАМ
7.1. ВВЕДЕНИЕ
В предыдущих главах были рассмотрены как несколько простых
методов оценки полных затрат труда, стоимости и сроков на раз-
работку и сопровождение программного изделия, так и распреде-
ления указанных величин по различным фазам проекта. Кроме
этой информации часто необходима оценка распределения затрат
труда между основными работами ЖЦПО: проектированием, про-
граммированием, планированием отладки и испытаний и т. д. Не-
обходимость такой оценки определяется, например, следующими
соображениями:
1. При тщательном планировании штатов исполнителей необхо-
димо знать, какие именно специалисты и в какое время потребу-
ются для программного проекта.
2. При комплектовании штатов необходимо определять обязан-
ности и род деятельности членов бригады.
3. При организации проекта необходимо приспосабливать орга-
низационную структуру к размерам бригады и групп, выполняю-
щих различные работы. (В случае больших проектов организаци-
101
онная структура может изменяться несколько раз в течение
ЖЦПО.)
4. При контроле хода выполнения проекта необходимы данные
о распределении затрат труда по всем работам.
В этой главе для каждой фазы ЖЦПО представлены оценки
распределения затрат по проектным работам. Кроме того, даны
некоторые рекомендации по общей организации программного про-
екта и показано, как эти рекомендации и оценки распределений по
работам могут быть использованы для получения организационной
структуры на каждой фазе.
Применение указанных рекомендаций будет проиллюстрирова-
но примером конкретного проекта с привлечением оценочных соот-
ношений базовой КОМОСТ, Рассмотрение базовой КОМОСТ за-
вершается сравнением ее с аналогичными моделями и обсуждени-
ем ограничений, многие из которых будут устранены в промежу-
точной КОМОСТ (см. гл. 8 и 9).
7.2. РАСПРЕДЕЛЕНИЕ ЗАТРАТ ТРУДА НА КАЖДУЮ РАБОТУ ПО ФАЗАМ
В табл. 7.1—7.3 приведены распределения затрат труда для
каждой фазы программного проекта с восемью главными работа-
ми, к которым относятся:
анализ требований;
проектирование изделия;
программирование;
планирование отладки;
верификация и подтверждение;
управление проектом;
управление конфигурацией и качеством изделия;
документирование.
Таблица 7.1
Распределение по фазам затрат труда, %, на каждую проектную работу
для разработки встроенного типа
Фаза Планирование и анализ требо- ваний Проектирование изделий Программирование
Размер изделия ! М П С Б ОБ М П С Б ОБ М П С Б ОБ
Доля всей фазы, % 8 8 8 8 8 18 18 18 18 18 60 57 54 51 48
Доля работы, %: Анализ требований 50 48 46 44 42 10 10 10 10 10 3 3 3 3 3
Проектирование 12 13 14 15 16 42 42 42 42 42 6 6 6 6 6
изделия Программирование 2 4 6 8 10 10 11 12 13 14 55 55 55 55 55
Планирование от- 2 3 4 5 6 4 5 6 7 8 4 5 6 7 8
ладки Верификация и 6 7 8 9 10 6 7 8 9 10 8 9 10 11 12
по дтвер ж дение Управление проск- 16 14 12 10 8 15 13 11 9 7 9 8 7 6 5
ТОМ УК и КК 5 4 4 4 3 4 3 3 3 2 8 7 7 7 6
Документирование 7 7 6 5 5 9 9 8 7 7 7 7 6 5 5
i02
Окончание табл. 7.1
Фаза Комплексирование и испытания Разработка Сопровождение
Размер изделия Дзля всей фазы, % Диля работы, %: М П С Б ОБ 22 25 28 31 34 М П С Б ОБ М П С Б ОБ
Анализ требований Проект ирование 2 2 2 2 2 4 4 4 4 4 6 6 6 5 5
изделия 4 4 4 4 4 12 12 12 12 12 11 11 11 11 11
1 Еограммирование Планирование от- 32 36 40 44 48 42 43 43 44 45 38 39 39 40 41
ладки Верификация и 3 3 4 4 5 4 4 5 6 7 3 3 4 5 6
подтверждение Управление проек- 30 28 25 23 20 12 13 14 14 14 12 13 14 14 14
том 10 9 8 7 6 10 9 8 7 6 10 9 8 7 6
УК и КК 10 9 9 9 8 8 7 7 7 6 8 7 7 7 6
Документирование 9 9 8 7 7 8 8 7 6 6 12 12 11 11 11
Примечание. М — малый, 2 КЧИК; П — промежуточный, 8 КЧИК; С — средний. 32
КЧИК; Б — большой, 128 КЧИК, ОБ — очень большой, 512 КЧИК.
Каждая из таблиц соответствует одному из типов разработки:
встроенному, полунезависимому и распространенному. Ниже об-
суждено использование табл. 7.1 для встроенного проекта, осталь-
ные используются аналогично.
Как видно из таблиц, распределение затрат труда по работам
зависит от стандартного размера изделия.
Распределения для проектов других размеров получаются ли-
нейной интерполяцией данных из таблиц.
' Для пояснения табл 7.1 рассмотрим самый левый столбец чи-
лел. В нем указано, что в небольшом проекте (2 КЧИК) на фазу
планирования и анализа требований приходится 8% всех затрат
труда 50% этой составляющей (или 4% всех затрат) приходится
на решение следующих задач анализа требований: анализ сущест-
вующей системы, определение запросов пользователей, а также
комплексирование, документирование и повторный анализ требо-
ваний. Еще 12% из доли в 8% (или 1% всех затрат) пойдут на
фазе планирования и анализа треоований на выполнение задач
проектирования изделия: исследование общей аппаратно-програм-
мной архитектуры всего изделия, а также анализ чувствительности
и степени риска для гарантии осуществимости требований. Следу-
ющие 2% из доли в 8% пойдут на программирование и т. п.
L Из следующего столбца табл. 7.1 можно увидеть, что для про-
£ а промежуточного размера доли затрат являются другими.
- частости, из таблицы ясно, что программная разработка ни в
Яцм случае не сводится только к кодированию. Для встроенного
проекта среднего размера лишь 30% (54%-55% — 30%) всех за-
трат приходится на фазу программирования. Кроме того, чут„ ли
Не половина из этих 30% идет на детальное проектирование, а
103
g Таблица 7.2
Распределение по фазам затрат труда, %, на каждую проектную работу для разработки полунезависимого типа
Фаза Планирование и анализ Проектирование изделия Программирование
требований -
Размер изделия М П С Б ОБ М П С Б ОБ М П С Б ОБ
Доля всей фазы, % 7 7 7 7 7 17 17 17 17 17 64 61 58 55 52
Доля работы, %
Анализ требований 48 47 46 45 44 12,5 12,5 12,5 12,5 12,5 4 4 4 4 4
Проектирование изделия 16 16,5 17 17,5 18 41 41 41 41 41 8 8 8 8 8
Программирование 2,5 3,5 4,5 5,5 6,5 12 12,5 13 13,5 14 56,5 56,5 56,5 56,5 56,5
Планирование отладки 2,5 3 3,5 4 4,5 4,5 5 5,5 6 5 4 4,5 5 5,5 6
Верификация и подтверждение 6 6,5 7 7,5 8 6 6,5 7 7,5 8 7 7,5 8 8,5 9
Управление проектом 15,5 14,5 13,5 12,5 11,5 13 12 11 10 9 7,5 7 6,5 6 5,5
УК и КК 3,5 3 3 3 2,5 3 2,5 2,5 2,5 2 7 6,5 6,5 6,5 6
Документирование 6 6 5,5 5 5 8 8 7,5 7 7 6 6 5,5 5 5
Фаза Комплексирование и Разработка Сопровождение
испытания
Размер изделия м П С Б ОБ М П С Б ОБ М П С Б ОБ
Доля всей фазы, % 19 22 25 28 31
Доля работы, %
Анализ требований 2,5 2,5 2,5 2,5 2,5 5 5 5 5 5 6,5 6,5 6,5 6 6
Проектирование изделия 5 5 5 5 5 13 13 13 13 13 12 12 12 12 12
Программирование 33 35 37 39 41 45 45 44,5 44,5 44,5 41,5 41,5 41 41 41
Планирование отладки 2,5 2,5 3 3 3,5 4 4 4,5 5 5,5 3 3 3,5 4 4,5
Верификация и подтверждение 32 31 29,5 28,5 27 11 12 13 13,5 14 11 12 13 13,5 14
Управление проектом 8,5 8 7,5 7 6,5 8,5 8 7,5 7 6,5 8,5 8 7,5 7 6,5
УК и КК 8,5 8 8 8 7,5 6,5 6 6 6 5,5 6,5 6 6 6 5,5
Документирование 8 8 7,5 7 7 7 7 6,6 6 6 11 11 10,5 10,5 10,5
Примечание. М — малый, 2 КЧИК: П — промежуточный. 8 КЧИК; С — средний, 32 КЧИК, Б — большой. 128 КЧИК: ОБ — очень боль-
шой, 512 КЧИК-
Таблица 7.3
распределение по фазам затрат труда, %, на каждую проектную работу
для разработки распространенного типа
фаза Планирование Проектирова- Программиро-
и анализ тре- ние изделия ванне
бований
Размер изделия М П С Б М П С Б М П С Б
Доля всей фазы, % 6 16 68 65 62 59
Доля работы, %:
Анализ требований 46 15 5
Проектирование изделия 20 40 10
Программирование 3 14 58
Планирование отладки 3 5 4
Верификация и подтверж-
дение 6 6 6
Управление проектом 15 11 6
УК И КК 2 2 6
Документирование 5 7 5
Фаза Комплексиро- Разработка Сопровождение
вание и испы-
тания
Размер изделия М П С Б М П С Б М П С Б
Доля всей фазы, % 16 19 22 25
Доля работы, %:
Анализ требований 3 6 7
Проектирование изделия 6 14 13
Программирование 34 48 47 46 45 45 44 43 42
Планирование отладки 2 4 3
Верификация и подтверж-
дение 34 10 11 12 13 10 11 12 13
Управление проектом 7 7 5
УК и КК 7 5 7
Документирование 7 6 10
Примечание. М — малый. 2 КЧИК; П — промежуточный, 8 КЧИК; С — средний,
32 КЧИК; Б — большой, 128 КЧИК.
остаток делится почти поровну между кодированием и автономной
отладкой. Это значит, что только около 8% полных затрат на про-
ект приходится на кодирование.
В качестве примера использования табл. 7.1 вычислим распре-
деление затрат труда по работам на фазе проектирования изделия
Для очень большого по размеру (512 КЧИК) встроенного проекта.
Из табл. 6.2 получаем полные затраты и сроки осуществления
очень большого встроенного проекта (соответственно 6420 ЧМ и
мес.). Из табл. 6.8 определяем доли затрат и сроков на фазе
проектирования этого изделия (соответственно 18 и 38%). Следо-
вательно, в этом проекте на фазе проектирования потребуется:
6420 ЧМ-0,18= 1156 ЧМ; 41 мес.-0,38= 15,6 мес.
Отсюда следует, что в среднем на фазе проектирования в про-
J е заняты 74 человека: 1156/15,6=74 ЧИ. А из табл. 7.1 можно
с ^ед„елить> чем будут заниматься эти исполнители. Используя
ый правый (ОБ) столбец, соответствующий фазе проектирова-
• можно определить, что 10% исполнителей, или приблизитель-
105
но.7 человек, будут заняты анализом требований; 42% исполните-
лей, или 31 человек, будут выполнять функции проектирования
изделия и т. д. Число исполнителей распределяется так:
Анализ требований.................7 Р_рификация н подтверждение . 7
Проектирование изделия ... 31 J правление проектом . , . 5
Программирование.................10 УК и КК..........................2
Планирование отладки и испытаний 6 Документирование...............5
Дсполнительная информация может быть получена из таол. 4.3,
в которой описаны задачи для исполнителей отдельных работ
7.3. ПРИМЕР ЭЛЕКТРОННОЙ СИСТЕМЫ ПЛАТЕЖЕЙ
Допустим, что Национальный банк Ханта за вершил фазу анализа осуществи-
мости крупной электронной системы платежей (ЭСП), которая должна паботать
в реальном времени и обрабатывать сообщения о финансовых операциях этого
Таблица 7.4
Распределение по фазам затрат труда, сроков и числа исполни.глей для ОСП
Характеристика Планирова- ние и ана- лиз требо- ваний Проектиро- вание изделия Программи- рование Комплекси- рование и испытания
Затраты труда:’ % ЧМ Счжи: % мес. Среднее число исполните- лей, ЧИ 8 55 34 6,8 8,1 18 125 35 7,0 17,9 52.5 363 38 7,о 47,8 29,5 204 27 5,4 37,8
Таблица 7.5 Распределение по фазам затрат труда, •/•, на каждую работу для ЭСП
Вид работы Планирование и анализ требований Проектирование изделия
% ЧМ % чм
Анализ требований Проектирование изделия 1Шогра г ширование Планирование отладки Верификаиия и подтверж- дение Управление проектом УК и КК Документирование 45 14,5 7 4,5 8,5 11 4 5,5 3,6 1.2 0,6 0,4 0.7 С9 0,л 0,4 10 42 12,5 6,5 8,5 10 3 7,5 1.8 7,5 2,2 1.2 1.5 1.8 9,5 1.4
Всего 100 8,1 100 179
106
банка в масштабе всеп страны. Прав 1сние банка приняло реыенпе о создании
первоначальной версии этой систем у для выполнения основных функций ЭС11
в севеоо-восточной части страны. Предположим, что необходимо спланировать
разработку и сопровождение этого изделия Предварит! льно можно сделать четы-
ре вывода относительно оъсчдгеыого характера издепил:
по табл. 6.3 опреде"яем, что про.>кт относится к вс гроенн! >му типу;
ожидается, что размер первоначальной версии составил 80 КЧГ К;
ожидается, что коэффициент пересчета годовых изменений (КПГИ) будет
равен 15 %;
ожидается довольн > стандартная зависимость проекта от других стоимост-
ных факторов (квалификации персонала, условий разработки и т. п.).
Последний вывод означает, что для оценивания характер истцк ЖЦГ.О мож-
но воспользоваться базовой КОМОСТ. [В детальной КОМОСТ (см. гл. 23—27)
при оценивании распределений затрат труда учитываются и другие факторы
(например, высокие ipe6oтания по надежности сильно увеличивают расходы на
отладку и испытания).]
Вначале по уравнению для встпиенного типа из табл. 6.1 определим затраты
труда и соок разработки изделия:
Затраты труда=3,6-80*>2°=692 ЧМ.;
Срок=2.5-692°'32=20 мес.
При расходах 6006 долл, на типичный ЧМ совокупные издержки на оплату рабо-
ты исполнителей составят 4152 тыс. долл.
Затем воспользуемся табл 6.8 дли нахождения распределен и за 'ра. и сро-
ков по различным фазам разработки Поскольку размер изделия 80 КЧ1 К нахо-
дится точно посередине между стандартными средним (32 КЧИК) и б >льшчм
(128 КЧИК), будем использовать прч ин-ерголяцид среднее арифметическое
двух столбцов табл. 6.8 для встроенного типа. Наьрнмгр, затраты труда на разе
планирования и (нализа требований составят 8 % всех затрат, или 55 ЧМ
(692-0,08=55 ЧМ). Аналогично можно оценить затраты труда, сроки и число
исполнител _й для каждой фазы. Полученные оценки приведены в табл. 7 4
Годовой объем работ по сопровождению можно оценить с помощью (5.1) и
(5.7), учитывая, что КПГИ=15 %:
ЧМг с=0,15-692=104 ЧМ;
ЧИС = 104/12 = 8,7 ЧИ.
Годовые расходы=104 ЧМ-6000 долл /ЧМ=С24 000 долл.
Наконец, по данчь м табл. 7 1 можно ”Ы"ис шть для каждой фазы распреде-
ление затрат между главными работами. Для этого опять должна применяться
I интерполяция долей затрат для среднего и большого проектов. Получени е оцен-
ки прив .дятся в збл. '.5.
Программирование Комплексирование н испытания Сопровождение
% ЧМ % ЧМ % ЧМ
3 1,4 2 0,8 5.5 0,5
6 2,9 4 1,5 11 1.0
55 26,3 42 15,9 39,5 3,4
6,5 3,1 4 1.5 4,5 0,4
10,5 5,0 24 9,1 14 U
,5 3 ' 7.5 2,8 7,5 0.6
3.4 9 3,4 0.6
5.5 2.6 7,5 2,8 И 1.0
100 47,8 1С0 100 37.8 87
— 1
107
1Л. РАЗРАБОТКА ОРГАНИЗАЦИОННЫХ СТРУКТУР ПРОЕКТА
Организационная структура проекта помогает руководителю
распределять между исполнителями права и обязанности по от-
дельным работам или их частям. Эта структура весьма полезна при
реализации принципов эффективного управления проектом (напри-
мер, «централизация управления» и «равенство прав и обязанно-
стей» [178]). Структуры для каждой фазы ЖЦПО разрабатывают-
ся на основе оценок по базовой КОМОСТ и с помощью практиче-
ских рекомендаций, обсуждаемых ниже.
Обобщенная организационная структура проекта представлена
на рис. 7.1. Она может быть приспособлена для конкретной разра-
Рис. 7.1. Обобщенная организационная структура проекта
ботки путем объединения смежных работ. Работа с кадрами, пла-
нирование и управление, а также руководство проектом соответст-
вуют управлению проектом в КОМОСТ. Системное проектирова-
ние включает такие работы, предусмотренные КОМОСТ, как ана-
лиз требований, проектирование изделия и документирование. Ве-
рификация и подтверждение в структуре включают работы по пла-
нированию отладки и испытаний. Символы SS1( ..., SSn обознача-
ют программирование подсистем с номерами от 1 до п. Внедрение
включает в себя перенос программ, опытное внедрение, обучение и
другие работы этой фазы (см. табл. 4.1).
Смежные по структуре виды деятельности легче объединить из-
за сходства целей, задач и знаний, требуемых для их выполнения.
Например, УК и КК лучше согласуются друг с другом, чем УК и
ВП при анализе состояния дел, выпуске и контроле стандартов, а
также при проведении проверок.
Рекомендации по адаптации организационной структуры пред-
ставлены в табл. 7.6. Использование термина «рекомендации»
108
вместо термина «правила» объясняется тем, что управление и ор-
ганизация относятся к сфере практической деятельности людей, а
не к области упражнений в абстрактной логике. Различные явле-
ния субъективного порядка — предпочтения заказчика или испол-
нителей или недостатки разработчиков, конфликтные ситуации, во-
просы продвижения по службе — могут привести к отклонениям от
рекомендаций табл. 7.6Ч Фактически лишь рекомендация 5 должна
трактоваться как правило.
Таблица 7.6
^Рекомендации по адаптации организационной структуры
'1. Объедините смежные виды деятельности организационной структуры, при-
веденной на рис. 7.1.
2. Объедините с< седние работы с оценкой менее 2 ЧИ, если:
а) они не относятся к руководству несколькими подчиненными работами;
б) для выполнения работ требуемся менее 0,5 ЧИ и отсутствует перспекти-
ва роста занятости на следующей фазе.
3. Если для какого-либо вида деятельности необходимо более 7 ЧИ, разбей-
те ее на работу по руководству и несколько подчиненных работ.
4. Ограничивайте круг обязанностей любого руководителя управлением не
более чем семью работами.
5. Если какая-нибудь рекомендация входит в прстиворечие со здравым
смыслом, руководствуйтесь последним.
Применение к проекту ЭСП. Составим организационную струк-
туру крупного встроенного проекта ЭСП для фазы проектирования
изделия. Для этого проекта распределение числа исполнителей по
фазам и работам приводилось в табл. 7.5. Из столбца «проектиро-
вание изделия» видно, что на этой фазе для управления проектом
необходимо в среднем 1,8 ЧИ. Пусть 1,0 ЧИ приходится на руково-
(Дителя, а 0,8 ЧИ выделяются на работу с кадрами, планирование
и контроль. С учетом части работ следующей фазы число исполни-
телей превысит 2, поэтому совокупную деятельность следует офор-
мить в виде самостоятельной работы.
Соседние для нее по рис. 7.1 УК и КК в соответствии с табл. 7.5
требуют на данной фазе в среднем 0,5 ЧМ, а в последующей —
3,4 ЧИ. В согласии с рекомендацией 2 они должны быть выделены
в О1дельную работу. Однако оча и соседняя с ней работа по пла-
нированию и контролю довольно малы по объему. В подобных
ситуациях целесообразнее менее строго следовать рекомендациям
и объединять такие работы в одну.
П панирование отладки и испытаний вместе с ВП по табл. 7.5
требует 2,7 ЧИ и заслуживает введения в организационную струк-
туру отдельной работы по ВП. Аналогично, выделение на програм-
I 1 Использование в рекомендациях 3 и 4 «магического чис.~а 7» обычно уточ-
няется фразой «плюс или минус два». В такой форме реко& ендации представляют
собой результат научных наблюдений и большого опыта работы в сфере управле-
а"я (см. [206]).
109
мирование 2,2 ЧИ заставляет определять ее как самостоятельную
работу. По данным табл. 7.5 анализ требований, проектирова-
ние изделия и документирование вместе требуют 10,7 ЧИ для си-
стемного проектирования. Для этой работы имеется три возмож-
ности:
1. Разделить ее в соответствии с рекомендацией 3 на руководст-
во (1 ЧИ), проектирование изделия (6,5 ЧИ) и анализ требований
и документирование (3,2 ЧИ).
2. Разделить ее в соответствии с рекомендаций 3 на руководство
и две работы по системному проектированию двух частей изделия.
3. Объединить ее, пренебрегая рекомендацией 3, в единое си-
стемное проектирование.
Из трех возможностей первая менее всего привлекательна из-
за тесной взаимосвязи указанных работ. Вторая возможность пред-
почтительнее, если существует естественное деление изделия на две
части. В остальных случаях (за исключением особых обстоя-
тельств) предпочтительнее была бы третья возможность.
Проектирование изделия
Обновление требований
Подготовка предваритель-
ных руководств
Рис. 7.2. Организационная структура ЭСП на фазе проектирования
На рис. 7.2 показана окончательная организационная структура
при выборе второй возможности (в скобках указано приблизитель-
ное число исполнителей соответствующих работ).
Организационные структуры и типичные решения для других
фаз. Аналогичные предварительные структуры для других фаз
проекта ЭСП приведены на рис. 7.3. Некоторые изменения уже
внесены, другие, граничные, ситуации требуют пояснений.
1. На фазе планирования и анализа требований можно было бы
объединить работу с кадрами и ВП. В рассматриваемом случае это
сделано из-за большого разнообразия функций, которые тогда вхо-
дили бы в компетенцию одного руководителя, а также вследствие
намеченного на следующей фазе разделения этих работ на три от-
дельные.
по
2. На фазе программирования имеется несколько возможностей
объединения программистов в бригады:
а) три бригады по восемь человек в каждой;
б) четыре бригады по шесть человек в каждой;
в) пять бригад по пять человек в каждой;
г) шесть бригад по четыре человека в каждой;
д) восемь бригад по три человека в каждой.
При выборе наиболее подходящей альтернативы самое важ-
ное — организовать бригады в соответствии с четко определенными
работами, применяя принципы единства, связности и скрытности
информации, которые используются при эффективном проектиро-
вании ПО [80]. Важно учитывать следующее замечание: малым
числом более многочисленных бригад легче управлять, чем боль-
шим числом более малочисленных бригад. (Существуют пределы
и исключения, ограничивающие справедливость этого замечания.)
3. Для простоты деятельность по обновлению руководств на
фазах программирования, а также комплексирования и испытаний
была отнесена к системному проектированию. Часто имеет смысл
отнести всю эту работу или ее часть к программированию, когда
программистам приходится долго ожидать результатов машин-
ных прогонов или сообщений от бригады ВП о замеченных
ошибках.
4. На фазе сопровождения из программирования можно было
бы выделить системное проектирование, требующее для выполне-
ния 2 ЧИ. Однако предпочтительным решением является объеди-
нение этих работ и предоставление каждому исполнителю возмож-
ности заниматься анализом и проектированием. Следует также за-
метить, что во многих случаях на фазе сопровождения системное
проектирование и программирование предпочтительнее организо-
вывать в соответствии с главными подсистемами изделия или со
структурой организации заказчика [311]-
7.S. ОБСУЖДЕНИЕ РАСПРЕДЕЛЕНИЙ ПО ФАЗАМ И РАБОТАМ
Сравнение с распределением Рэлея. В базовой КОМОСТ рас-
пределение общего числа исполнителей весьма близко к распреде-
лению Рэлея [225 и 243] (см. рис. 6.8 в разд. 6.5). Главными раз-
личиями являются, по-видимому, следующие.
Наиболее существенное увеличение штатов проекта приходится
по КОМОСТ на завершение ВП проекта; рост числа исполнителей
До максимального значения происходит для больших проектов
значительно позднее и быстрее, чем по распределению Рэлея.
На фазе планирования и анализа требований происходит по-
степенное увеличение числа исполнителей, а в распределении
Рэлея численность персонала в начале фазы проектирования рав-
на нулю и быстро растет до уровня полного укомплектования шта-
гов. (В [243] для приближения к фактическим данным предлага-
ется добавлять в начало распределения еще одно распределение
Рэлея с малыми параметрами.)
111
Подготовка предварительных руководств
г)
б)
СО
2)
Рис. 7 3. Организационная структура ЭСП на других фазах:
а — планирование и анализ требований; б — программирование; в — комплексирование и
испытания; г — сопровождение
Результаты моделирования распределений числа исполнителей
на сопровождение также различаются (обсуждение см. в гл. 30).
Распределения работ по фазам. Используемые в КОМОСТ рас-
пределения сходны с предлагаемыми в [164 и 313]. Во второй ра-
боте предлагается более детальное распределение (8 фаз и до 25
работ на фазе), но оно специфично для относительно больших про-
ектов в узком диапазоне стоимостных факторов, характерных для
правительственных проектов с высокими требованиями по надеж-
ности функционирования в близком к реальному масштабу време
ни. Первая работа содержит данные, сходные по форме распреде-
лений (см. табл. 6.8, 7.1—7.3), и зависимости от размера проекта.
Предлагаемая модель близка к базовой КОМОСТ, но отличается
от промежуточной и детальной КОМОСТ независимостью распре-
делений от других стоимостных факторов (таких как, например,
требование высокой надежности, ограничение доступа к ЭВМ, ко-
торые вызывают рост расходов на отладку и испытания).
Распределение по работам в [164] иногда не согласуется с дан
ными КОМОСТ. Например, доля затрат труда на спецификацию
требований составляет 8% для очень большого проекта, 2% для
среднего и 31% для малого проекта. Соответствующие доли в
КОМОСТ лучше согласуются с фактическими данными и состав
ляют: 6% для распространенного, 7% для полунезависимого и 8%
для встроенного проектов.
7.6. ОГРАНИЧЕНИЯ БАЗОВОЙ КОМОСТ
Одним из ограничений базовой КОМОСТ (по сравнению с из-
вестными моделями) является отсутствие учета особенностей по-
шаговой разработки. Оценки затрат остаются вполне приемлемы-
ми, а расчет сроков должен производиться другим способом (см.
разд. 29.4).
Другое ограничение заключается в том, что оценивается сред-
нее число исполнителей на каждой фазе. На границах между фаза-
ми появляются разрывы ЧИ, которые необходимо сгладить так,
как это сделано на рис. 5.6, 6.6 и 6.7. Подобные эффекты уменьша-
ют точность организационных структур, особенно в случае програм
мирования на фазе комплексирования и испытаний (см. рис. 7.3).
(В начале фазы комплексированием занято большое число про-
граммистов, а ближе к концу— никто им не занимается).
Главное ограничение базовой КОМОСТ заключается в отсутст-
вии учета других стоимостных факторов, кроме размера програм-
много изделия (ЧИК) и КПГИ. (Дополнительные стоимостные
факторы, например аппаратурные ограничения, характеристики
разработчиков и условия разработки, учитываются в промежуточ-
ной КОМОСТ.)
ГЛАВА 8
ПРОМЕЖУТОЧНАЯ КОМОСТ. ОЦЕНКА НА УРОВНЕ ИЗДЕЛИЯ
8.1. ВВЕДЕНИЕ
В последних трех главах была представлена базовая КОМОСТ,
в которой затраты на разработку программного изделия оценива-
ются посредством учета единственной независимой переменной
(размера, выраженного числом исходных команд) и типа програм-
мной разработки. Как видно из рис. 6.4, такой уровень моделиро-
вания вполне хорошо объясняет большую часть различий в затра-
тах на программные проекты. Однако его точность достаточна
только на этапах приблизительного предварительного исследова-
ния программного изделия. (Для базы данных КОМОСТ оценки
по базовой КОМОСТ отличаются от фактических значений не бо-
лее чем на 30% лишь в 29% случаев и не более чем на 100% лишь
в 60% случаев.)
В этой и следующей главах будет представлена промежуточная
КОМОСТ (расширение базовой КОМОСТ), большие точность и
степень детализации которой делают ее более подходящей для
оценки затрат на этапах формирования программного изделия.
Промежуточная КОМОСТ включает 15 дополнительных независи-
мых переменных, которые отвечают на большую часть различий в
затратах на программные проекты, оставшихся необъясненными в
базовой КОМОСТ. (Для базы данных КОМОСТ оценки по проме-
жуточной КОМОСТ отличаются от фактических значений не более
чем на 20% в 68% случаев.)
Стоимостные атрибуты в промежуточной КОМОСТ. Имеются
стоимостные факторы, которые целесообразно рассмотреть при
разработке более совершенной модели оценки затрат на програм-
мный проект. В ранних исследованиях [223, 300], проведенных в
середине 60-х годов, было рассмотрено 104 различных фактора,
каждый из которых до некоторой степени определяет затраты на
программную разработку. Среди рассмотренных были такие фак-
торы, как тип применения, число типов ввода и вывода, доля в
программе команд ввода-вывода, а также управляющих или вы-
числительных команд, средний опыт работы аналитиков и про-
граммистов, конфигурация вычислительной системы и язык про-
граммирования, число согласований, требуемых для принятия ре-
шений относительно проектируемого изделия, число командировок
в ходе выполнения проекта. Более поздние исследования [291]
выявили дополнительные факторы, которые также влияют на сто-
имость ПО и к которым относятся, например, сложность выполне-
ния программы, наличие ограничений из-за необходимости обеспе-
чения секретности, а также использование методов структурного
программирования, сквозного контроля, разработки сверху — вниз
или бригады главного программиста.
115
Для сокращения большого числа возможных факторов до отно-
сительно легко контролируемой группы, которую можно использо-
вать для практической оценки затрат на ПО, все потенциальные
факторы были проанализированы с точки зрения удовлетворения
двум следующим главным требованиям.
Важность. При этом были исключены важные только для отно-
сительно небольшого числа специальных ситуаций факторы, такие
как число командировок или наличие ограничений при обеспечении
секретности.
Независимость. При этом были исключены факторы, которые
сильно зависят от размера изделия (например, число типов ввода
и вывода), а тесно связанные факторы были объединены в единый
фактор (так, например, факторы использования структурного про-
граммирования, сквозного контроля и т. п. были учтены единым
атрибутом «практическое применение современных методов про-
граммирования») .
В результате проведенного анализа было получено 15 стоимост-
ных атрибутов *, используемых в промежуточной КОМОСТ и объе-
диненных в четыре группы.
1. Атрибуты изделия:
ТНПО — требуемая надежность ПО;
РБД — размер базы данных;
СИЗ — сложность изделия.
2. Атрибуты ЭВМ:
ОВД — ограничение по быстродействию;
ОП — ограничение по оперативной памяти;
ИВМ — изменяемость виртуальной машины 1 2;
ЦО — цикл обращения к ЭВМ.
3. Атрибуты исполнителей:
КА — квалификация аналитика;
ОРП —опыт работы в данной прикладной области;
КП — квалификация программиста;
ОРВМ — опыт работы с виртуальной машиной;
ОРЯП — опыт работы с языком программирования.
4. Атрибуты проекта:
ПСП — применение современного программирования;
ИИС — использование инструментальных средств;
OGP — ограничение сроков разработки.
Каждому из указанных стоимостных атрибутов соответствует
коэффициент, характеризующий влияние атрибута на программную
разработку. Эти коэффициенты используются в качестве множи-
1 Влияние, ока ываемое на производительность труда каждым стоимостным
атрибутом КОМОСТ, подробно обсуждается в гл. 24 — 27. В гл. 28 обсуждаются
причины того, почему некоторые довольно важные атрибуты не были включены
в КОМОСТ.
2 Для конкретного программного изделия виртуальной машиной называется
комплекс аппаратуры и ПО (ОС, СУБД и т. п.), используемые при выполнении
задач изделия.
116
телей при получении из номинальных оценок КОМОСТ уточнен-
ных оценок затрат труда на разработку. Аналогично уточняется и
оценка затрат труда на сопровождение ПО.
Предварительный обзор главы. В данной главе представлены
используемые в промежуточной КОМОСТ таблицы коэффициентов
затрат труда и соответствующие определения. Приведены также
примеры использования этих таблиц для оценки трудоемкости и
стоимости разработки и сопровождения ПО.
Упомянутые примеры иллюстрируют также применение проме-
жуточной КОМОСТ в процессе решения нескольких распростра-
ненных проблем, относящихся к приобретению ПО и управлению
проектом. Они показывают, как применение промежуточной
КОМОСТ может способствовать:
выполнению анализа чувствительности программного проекта;
лу"шему пониманию сущности предстоящей разработки про-
граммы.
В этой главе описаны также методы анализа способов разра-
ботки с использованием адаптируемых компонентов уже существу-
ющего ПО. В конце главы сопоставлены оценки по промежуточ-
ной КОМОСТ с фактическими значениями из базы .данных
КОМОСТ и сделан вывод о том, что 15 стоимостных атрибутов
промежуточной КОМОСТ действительно отвечают за большую
часть различий, не объясненных в базовой КОМОСТ.
8.2. ОЦЕНКА ЗАТРАТ ТРУДА ПО ПРОМЕЖУТОЧНОЙ КОМОСТ
Уравнения для номинальных значений. В промежуточной
КОМОСТ оценивание затрат труда на программную разработку
начинается с определения номинальных затрат труда по уравнени-
ям, имеющим тот же вид, что и уравнения базовой КОМОСТ. За-
тем полученное значение корректируется путем умножения на
коэффициенты затрат труда, определяемые в соответствии с оцен-
ками проекта по основным 15 стоимостным атрибутам.
Используемые в промежуточной КОМОСТ уравнения приведены
в .абл. 8.1. Эти уравнения отличаются от уравнений базовой
КОМОСТ для соответствующих типов разработки только коэффи-
циентами ’.
графики номинальных затрат труда для всех трех типов раз-
работок приводятся на рис. 8.1.
Кпэффициенты затрат труда на программную разработку.
Каждый стоимостный атрибут имеет набор рейтингов2, которые
1 В ранней версии промежуточной КОМСТ использовались коэффициенты из
Чазовой КОМОСТ, однако результаты применения этой версии были неуповлетво-
Рительш [ми- Главной причиной этого являлось то, что совокупное влияние коэф-
фициентов было неодинаковым для различных типов разработки. Так, для встре-
чных проектов оценки были завышенными, а для распространенных — занижен-
ными.
Регтиш — степень влияния атрибута, оценка интенсивности работ, стои-
остных атрибутов и других факторов по некоторой шкале градации по отно-
шению к номинальной оценке. — Прим. ред.
117
Таблица 8.1
Уравнение промежугодной КОМОСТ для оценивания
номисальних затра труда
Тип разработки Уравнение затрат
Распространенный Полунезависимый Встроенный ЧМиом=3,2-КиИК1,05 ЧМном=3,0-КЧИК‘-,а ЧМном =2,8-КЧИК,-«°
соответствуют оценкам проекта по этому атрибуту (см. табл. 8.2).
Основная же шкала рейтингов го каждому атрибуту поясняется в
табл 8.3 *.
Для пояснения использования табл. 8.2 и 8.3 рассмотрим не-
сколько полунезависимых программных изделий объемом 32
КЧИК, к которым предъявляются различные требования по надеж-
ности из-за различия в способах их применения. Из уравнения для
полунезависимого типа разработки можно определить без учета
Рис. 8.1. Оценка номинальных затрат труда по промежуточной КОМОСТ для
тоех типов проектов
* Подробное пояснение шкалы рейтингов по каждому атрибуту дано
в гл. 24—27
118
требований по надежности, что затраты равны 146 ЧМ (3,0-32'-|2=
= 146). Ниже приводятся скорректированные оценки для несколь-
ких изделий.
1. К имеющим объем 32 КЧИК прототипу или модели для де-
монстрации осуществимости системы с вводом на естественном
языке, или речевым вводом, по-видимому, предъявляются очень
низкие требования по надежности, поскольку эти изделия не пред-
назначены для производственного применения; влияние програм-
мной ошибки состоит просто в некотором неудобстве для разработ-
чиков из-за необходимости исправления этой ошибки (см таб. 8.3).
Оценка затрат труда, скорректированная по данным табл. 8.2,
такова:
146 ЧМ-0,75= ПО ЧМ.
2. К моделям перспективного планирования или предсказания
погоды, имеющим объем 32 КЧИК, предъявляются относительно
низкие требования по надежности, поскольку их воздействие явля-
ется, как правило, долгосрочным, и большинство ошибок приведут
к низким, легко восстанавливаемым потерям труда пользователей.
В этом случае скорректированная оценка затрат труда такова:
146 ЧМ-0,88=128 ЧМ.
3. Имеющие объем 32 КЧИК 'административная информацион-
ная система и система управления запасами являются типичными
представителями большого класса программных изделий, к кото-
Таблица 8.2
Коэффициенты затрат труда на программную разработку
Коэффициенты для рейтингов
Стоимостный фактор очень низкого низкого номиналь- ного высокого очень высокого сверхвы- сокого
Атрибут изделия: ТНПО 0,75 0,88 1,00 1,15 1,40
РБД — 0,94 1,00 1,08 1,16 —
СИЗ 0,70 0,85 1,00 1,15 1,30 1,65
Атрибут ЭВМ: ОВД . 1,00 1.П ’,30 1,66
оп —- — 1,00 1,06 1,21 1,56
ИВМ — 0,87 1,00 1,15 1,30 —
но — 0,87 1,00 1,07 1,15 —
Атрибут исполни- телей: КА 1,46 1,19 1,00 0,86 0,71
ОРП 1,29 1,13 1,00 0,91 0,82 —
КП 1,42 1,17 1,00 0,86 0,70 —►
ОРВМ 1,21 1,10 1,00 0,90 — —
ОРЯП 1,14 1,07 1,00 0,95 — -—.
псп^ут пРоекта: 1,24 1,10 1,00 0,91 0,82 —
Иис 1,24 1,10 1,00 0,91 0,83 —
Оср 1,23 1,08 1,00 1,04 0,10
119
Таблица 8.3
Рейтинги стоимостных факторов ПО
Стоимостный фактор Рей
очень низкий низкий
Атоибут изделия: ТНПО Незначительное ограни- чение Небольшие, легко вос- станавливаемые потери
РБД. байт СИЗ Атрибут ЭВМ: ОВД См. табл. 8.4 РБД ——<10 ЧИК
ОН
ИВМ Значительное измене- ние — каждые 12 меся- цев, незначительное — каждый месяц
ЦО, час Диалог
Атрибуты исполнителей: КА, процентиль1 ОГ-П, лес. КП, процентиль1 ОРВМ, мес. ОРЯП? мес. Атрибуты проекта: ПСП ИИС 15 <4 15 <1 <1 Отсутствует Простейшие микропро- цессорные инструмен- тальные средства 35 12 35 4 4 Начальное Простейшие инструмен- тальные средства на мини-ЭВМ
ОСР, % от номинальны* сроков 75 85
1 Критерий оценки бригады: способность к анализу (программированию), эффектив
градации на некотором участке шкалы: например, отрезок 0...100 может быть поделен на
120
ТИНГ
- номинальный ВЫСОКИЙ очень высокий сверх- высокий
5 меренные, восстанав- ливаемые потери РБД Ю< —— <100 ЧИК Требуется не более 50% и» еющегося быстродей- ствия Требуется не более 50% имеющейся оперативной памяти Значительное измене- нье — каждые 6 мес., незначительное — каж- дые 2 недели Средний цикл обраще- ния <4 55 36 55 12 12 Тегю-орое Простейшие инструмен- тальные средства на средних и больших ЭВМ 100 Большие финансовое потери РБД 1°°< чик<юоо 70% 70 % Значительное изме- нение — каждые 2 мес., незначитель- ное — каждую неде- лю 4—12 75 72 75 36 36 Широкое Мощные инструмен- тальные средства программирования и отладки на больших ЭВМ 130 Риск для человече- ской жизни РБД чик >100° 85% 85% Значительное измене ние — каждые 2 не- дели, незначнтель ное — каждые 2 дня >12 90 144 90 Обязательное Указанные в преды- дущем столбце, а также инструменталь- ные средства анализа требований, проекти- рования, документи- рования 160 95% 95%
ность, способность к общению и сотрудничеству. Процентиль — единица относительной
100 (100 процентилей). — Прим. ред.
121
g Таблица 3 4
Связь рейтинга сложности и типа модуля
Рейтинг Управление выполнением Вычисления Управление устройствами Управление Д‘ иными
Очень низкий Последовательный код с небольшим числом опе- раторов СТПР1. DO, CASE, IF THEN ELF E. Вложенность отсутству- ет. Простые предикаты Вычисление простых вы- ражений, например: А=В + С * (М — Е) Простые опера-орн чте- ния и записи, использу- ющие простые форматы Простые массивы в опе- ративной памяти
Низкий Несложная вложенность операторов СТПР. Пре- дикаты, в основном про- стые Вычисление выражений средней сложности, на- пример таких, как M=SQRT (В * * 2- -4 * А * С) Не требуется знания ха- рактеристик конкретного процессора или устрой- ства ввода-вывода, а также совмещения во времени работы различ- ных устройств Использование одного файла без изменения структуры данных, без редактирований и про- межуточных файлов
Номинальный В основном простая вло- женность. Некоторое межмодульное управле- ние. Использование таб- лиц решений Использование стандарт- ных математических и статистических подпро- грамм, элементарных матрично-векторных опе- раций Ввод-вывод с выбором устройства, проверкой состояния и обработкой ошибок Ввод из нескольких фай- лов и вывод в один файл. Использование простых структурных из- менений, простых редак- тирований
Высокий Операторы СТПР с глу- бокой вложенностью и многочисленными слож- ными предикатами. Уп- равление очередями и стеками. Существенный объем межмодульного управления Элементарный числен- ный анализ: многомер- ная интерполяция, обык- новенные дифференци- альные уравнения. Эле- ментарный учет потерь точности при округле- нии, усечении Физический ввод-вывод (определение адресов физической памяти, по- иск, чтение и т. п.). Оп- тимизация совмещения ввода-вывода Специализированные подпрограммы, работа- ющие в зависимости от содержимого потока данных. Сложная ре- структуризация данных на уровне записей
Очень высокий Реентабелыюе и рекур- сивное кодирование. Об- работка прерываний с фиксированными при- оритетами Сложный, но структури- рованный численный анализ: уравнения с пло- хо обусловленными мат- рицами, уравнения в ча- стных производных Анализ, обслуживание и маскирование прерыва- ний. Обслуживание ли- ний связи Обобщенное, парамет- ризованное структури- рование файла. Оптими- зация формования фай- ла, обработки команд, поиска
Сверхвысокий Планирование многочис- ленных ресурсов с дина- мически изменяющими- ся приоритетами. Управ- ление на микроуровне Сложный и неструктури- рованный численный анализ: анализ с высокой точностью стохастиче- ских данных с большим количеством шумов Кодирование с учетом временных характери- стик аппаратуры, микро- программирование Применение сильносвя- занных динамических реляционных структур. Управление данными с помощью естественного языка
1 СТПР — структурное программирование.
рым предъявляются номинальные требования по надежности
В таких системах влияние ошибок часто приводит к серьезным за-
труднениям, которые однако, как правило, преодолимы без слищ.
ком больших потерь. Поскольку для номинальных оценок коррек-
тирование не проводится, то оценка затрат труда для такой систе-
мы остается равной 146 ЧМ.
4. К имеющим объем 32 КЧИК банковским системам, системам
проверки кредитоспособности или регулирования распределения
электроэнергии, по-видимому, предъявляются высокие требования
по надежности. В таких системах программные ошибки могут при-
водить к значительным финансовым потерям или к огромным не-
удобствам для людей. Скорректированная оценка затрат труда
такова:
146 ЧМ-1,15= 168 ЧМ.
5. К имеющим объем 32 КЧИК военной оперативной системе
управления и системе контроля атомного реактора, по-видимому,
предъявляются очень высокие требования по надежности. В таких
системах программная ошибка могла бы привести к человеческим
жертвам. Скорректированная оценка затрат труда для построения
системы с желаемой надежностью такова:
146 ЧМ-1,40=204 ЧМ.
Причины .того, почему на разработку изделия с более высокой
надежностью требуются большие затраты, подытожены в табл. 8 5.
В ней указаны типичные причины уменьшения или увеличения за-
трат труда на каждой фазе разработки в зависимости от требуемой
надежности. Так, например, по данным табл. 8.5, на фазе комплек-
сирования и испытаний программного изделия, к которому предъ-
являются очень низкие требования по надежности, требуются отно-
сительно малые затраты труда на процедуры отладки, проверку
требований, контроль качества, управление конфигурацией, про-
верку в предельных и нештатных условиях эксплуатации и деталь-
ное документирование внутренней структуры изделия. В то же вре-
мя при создании изделия, к которому предъявляются очень высо-
кие требования по надежности, будет затрачено гораздо больше,
чем обычно, труда на выполнение указанных работ и, кроме того,
появятся дополнительные затраты на независимые верификацию
и подтверждение.
Таблица 8.5 является примером таблиц детальной КОМОСТ,
излагаемой в ч. 4. Детальная КОМОСТ содержит для каждой фазы
коэффициенты затрат труда, учитывающие в зависимости от рей-
тингов стоимостных атрибутов относительные затраы на выполне-
ние работ каждой фазы программной разработки. Таблицы, анало-
гичные табл. 8.5, поясняют, почему увеличиваются или уменьша-
ются затраты труда на каждой фазе программного проекта в за-
висимости от рейтингов стоимостных атрибутов.
В табл. 8.4 приведены различные типы программ и рейтинги
сложности программ. Так, например, программе вычисления подо-
ходных налогов, использующей простую систему уравнений Д-”8
124
Та б л tt it a 8.5
Различия выполняемых над проектом работ в зависимости от требований к надежности ПО
Рейтинг Анализ требований и проектирование изделий Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Очень низкий Незначительная детали- зация. Отсрочка многих решений. Незначитель- ная верификация. Мини- мальные КК и УК, пред- варительное руководст- во для пользователя, планы отладки н испыта- ний Упрощенное описание проекта. Минимальные КК и УК, предваритель- ное руководство для пользователя, планы от- ладки и испытаний. Не- формальный контроль проекта Отсутствие процедур от- ладки и испытаний. Ми- нимальные проверка пу- тей передачи управле- ния, контроль соблюде ппя стандартов, КК и УК, проверка ввода-вы- вода и работы в не- штатных условиях, руко- водство для пользовате- ля Отсутствие как процедур отладки и испытаний, так и проверок выполне- ния многих требований. Минимальные КК и УК, проверки в предельных и нештатных условиях, документирование внут- ренней структуры
Низкий IO сл Упрощенные описание, верификация. Частая отсрочка, решений. Упро- щенные КК и УК, пред- варительное руководст- во для пользователя, планы отладки и испы- таний Умеренная детализация. Упрошенные КК и УК, предварительное руко- водство для пользовате- лей, планы отладки и ис- пытаний Минимальные процедуры отладки и испытаний. Частичные проверка пу- тей передачи управле- ния, контроль соблюде- ния стан дратов. Упро- щенные КК и УК, руко- водство для пользовате- ля. Частичные проверки ввода-вывода и работы в нештатных условиях Минимальные процеду- ры отладки и испытаний. Редкая проверка выпол- нения требований. Упро- щенные КК и УК, руко- водство для пользова- теля. Частичные провер- ки в предельных и не- штатных условиях
Окончаниетабл. 8.5
Рейтинг Управление выполнением Вычисления Управление устройствами Управление данными
Номинальный
Высокий
Номинальные ВП проекта
Детальные верификация,
КК и УК, стандарты,
АПИ, документирование.
Детальные планы и про-
цедуры отладки и испы-
таний
Детальные верифика-
ция КК и УК, стандар-
ты, КАП, документиро-
вание. Детальные планы
и процедуры отладки и
испытаний
Детальные процедуры
отладки и исш гганий,
КК и УК, документиро-
вание. Обширные про-
верки в нештатных усло-
виях
Детальные процедуры
отладки и испытаний,
КК и УК, документиро-
вание. Обширные про-
верки в предельных и
нештатных условиях
Очень высокий
Детальные верификация,
КК и УК, стандарты,
АПИ, документирова-
ние, НВП интерфейса.
Свснхдетальные планы и
процедуры отладки и
испытаний
Детальные верифика-
ция. КК и УК, стандар
ты, КАП, документиро-
вание. Очень тщатель-
ный сквозной контроль
проекта. Сверх дуаль-
ные планы и процедуры
отладки и испытаний,
НВП интерфейса
Детальные процедуры
отладки и тестирования.
КК и УК, документиро-
вание. Очень тщатель-
ный контроль кода.
Очеш обширные проьер-
ки в нештатных услови-
ях, НВП интерфейса
Сверхдетальные про-
цедуры отладки и. испы-
таний, КК и УК, доку-
ментирование. Очень об-
ширные проверки в пре-
дельных и и .штатных
усло1 иих, НВП интер-
фейса
Примечание. АПИ — анализ проекта изделия; НВП — независимые верификация и подтверждение; КАП — критический анализ про-
екта.
определения на логоз, был бы приписан в зависимости от вида урав-
нения очень низкий или просто низкий рейтинг (см. столбец, от-
носящийся к вычислениям). Если же при вычислении подоходного
налога использовать интерполяцию по нескольким налоговым
таблицам, то указанной программе был бы присвоен номинальный
рейтинг.
На рис. 8.2 для каждого атрибута приведены относительные
значения используемых в промежуточной КОМОСТ коэффициентов
затрат труда. Графическое сравнение позволяет улучшить интуи-
тивное понимание того, какие факторы оказывают главное влияние
на затраты [квалификации аналитика и (или) программиста, ог-
Рис. 8.2. Коэффициенты затрат труда в промежуточной
КОМОСТ
127
раничения по оперативной памяти и (или) быстродействию, слож-
ность и (или) требуемая надежность],а какие — относительно не-
значительное влияние.
Распределение по фазам и работам затрат труда и сроков.
В промежуточной КОМОСТ для оценивания распределения по
фазам и работам сроков разработки используются те же соотно-
шения, что и в базовой КОМОСТ. Это значит, что:
оценка сроков разработки СР может быть вычислена по урав-
нениям табл. 6.1 с использованием полученной в промежуточной
КОМОСТ оценки затрат труда в человеко-месяцах;
процентное распределение затрат труда и сроков по фазам мо-
жет быть получено из табл. 6.8 с учетом типа разработки и раз-
мера изделия.
Процентное распределение затрат труда по работам и фазам
может быть получено из табл. 7.1—,7.3 с учетом типа разработки
и размера изделия.
8.3. ПРИМЕР РАСЧЕТА СТОИМОСТИ РАЗРАБОТКИ ПО СВЯЗИ
НА МИКРОПРОЦЕССОРАХ
Предположим, что с компанией Megabit Communication ведутся переговоры
относительно стоимости разработки встроенного изделия объемом 10 КЧИК, пред-
назначенного .для обработки сообщений с помощью серийного микропроцессора.
Из уравнений номинальных затрат труда для встречного типа разработки (см.
табл. 8.1) можно получить, что на' проект объемом 10 КЧИК в среднем требуется
44 ЧМ (2,8-10|'20=44), и надо определить влияние различных свойств проекта на
полные затраты и стоимость. При этом необходимо учесть, например, что ПО
связи, как правило, имеет высокую оценку стоимости (см. столбец управления
устройствами в табл. 8.4), но чтобы сбалансировать увеличение затрат труда
из-за сложности, планируется привлечь высококвалифицированных аналитиков и
программистов. Однако в таком случае средние издержки на оплату исполнителей
составят 6000 долл./мес. на человека (включая накладные расходы), поэтому для
принятия окончательного решения необходимо также оценить стоимость разра-
ботки в долларах.
Результаты оценивания описанной ситуации по всем стоимостным атрибутам
сведены в табл. 8.6 вместе с рейтингами стоимостных атрибутов (из табл. 8.3)
и соответствующими коэффициентами затрат труда (из табл. 8.2). Приведенные
данные показывают, что увеличение затрат труда в 1,30 раза из-за высокой слож-
ности более чем уравновешивается их двукратным уменьшением в 0,86 раза вслед-
ствие повышения квалификации аналитиков и программистов. Однако после пере-
множения всех коэффициентов затрат труда результирующий корректирующий
коэффициент затрат (ККЗ) оказывается равным 1,17, что означает увеличение
затрат труда на 17 % по отношению к номинальным значениям. С учетом ск: ан-
ного получаем следующие окончательные скорректированные оценки на програм-
мную разработку:
Затраты труда: 44 ЧМ-1,17=51 ЧМ;
Затраты денежных средств: 51 ЧМ-6000 долл./ЧМ=306 000 долл.
Анализ чувствительности. С помощью промежуточной КОМОСТ можно вы-
полнить анализ чувствительности к стоимостным атрибутам, что позволяет опре-
делить влияние рейтингов на стоимость программной разработки.
Например, предположим, что имеется возможность укомплектовать штаты
проекта менее высокооплачиваемыми, но и менее квалифицированными исполни-
телями. В слу чае осуществления этой возможности средние издержки на оплату
исполнителей составили бы 5000 долл, вместо 6000 долл, в месяц на человека,
а оценки квалификации аналитика и программиста стали бы номинальным
вместо высоких. Для таких оценок коэффициенты затрат труда на программную
128
71блица 8.6
рейтинги стоимостных атрибутов разработки ПО связи на микропроцессорах
i-—— Стоимост- ный атрибут Характеристика условий разработки Рейтинг Коэффици- ент затрат труда
тнпо Локальное использование систе- Номинальный 1,00
РБД мы. Отсутствие серьезных проб- лем, связанных с восстановлением 20 000 байт Низкий 0,94
СИЗ Обработка сообщений Очень высокий 1,30
L ОБД Использование 70% быстродейст- вия Высокий 1.11
оп Использование 70% оперативной памяти (45 К из 64 К) Высокий 1,06
ИВМ Использование серийного микро- процессора Номинальный 1,00
ЦО Средний цикл обращения 2 ч Номинальный 1,00
КА Высококвалифицированные стар- шие аналитики Высокий 0,86
ОРП Три года Номинальный 1,00
КП Высококвалифицированные стар- шие программисты Высокий 0,86
ОРВМ 6 мес. Низкий 1,.О
ОРЯП 12 мес. Номинальный 1,00
псп Методы применяются более одно- го года Высокий 0,91
иис Простые средства на мини-ЭВМ Низкий 1,10
ОСР 9 мес. Номинальный 1,00
Корректирующий коэффициент за- трат труда 1.17
разработку равны 1,00 вместо 0,86 для высокого рейтинга (по данным табл. 8.2).
Это приводит к необходимости корректирования оценки КОМОСТ для исключения
коэффициентов, приводящих к сокращению затрат труда и равных 0,36; с учетом
казанного итоговые оценки КОМОСТ были бы следующими:
ККЗ=1,58;
Затраты труда = 44 ЧМ-1,58=70 ЧМ;
| Затраты денежных средств—70 ЧМ-5000 дол.”/ЧМ=350 000 долл.
В Таким образом, из рассмотренного примера видно, что преимущества исполь
зования более квалифицированных специалистов перевешивают (на 44 тыс долл )
влияние их более высоких окладов.
В ачестве еше одного примера предположим, что компания, разрабатываю-
щая ПО, за дополнительные 10 тыс. долл могла бы купить для используемого
‘кропроцессора память объемом 96 Келов вместо прежних 64 Келов. Это изме-
нило бы ограничение на память и с 70 % на 47 % (45 К/96 К=0,47, т. е. 47 %),
после чего рейтинг стоимостного атрибута ОП снизился бы с высокого до номи-
нального. В результате этого ККЗ стал бы для этого атрибута равным 1,00 вме-
010 1.06 и модифицированные оценки были бы следующими:
ККЗ=1,10;
1траты труда=44 ЧМ-1,10=48 ЧМ;
Затраты денежных средств=48 ЧМ-(6000 долл./ЧМ) =288 000 долл.
ая Полученные оценки свидетельствуют о возможности сокращения расходов
а 18 тыс. долл., что бплее чем компенсир; ет дополнительные затраты на 10 тыс.
'ВЛл- на аппаратуру. Следовательно, во время переговоров с разработчиками ПО
ожне предложить рассмотреть этот вариант уменьшения расходов на ПО и об-
Дить распределение сэкономленных денежных средс-в.
5 Зак
628
129
В качестве последнего примера предположим, что ожидается выпуск нового
дешевого микропроцессора, эквивалентного по своим техническим характеристи-
кам уже выбранному и стоящего на 20 тыс. долл, меньше Однако этот новый
микропроцессор оснащен едва достаточным минимумом инструментальных
средств: разработанные для него компиляторы, ассемблеры и загрузчики прими
тивн1 [ и ненадежны; и в отличие от уже выбранного микропроцессора он не обес-
печен средствами сопровождения и диагностики. В результате рейтинг атрибута
ИИС меняется с низкого на очень низкий, что приводит к увеличению соответст-
вующего коэффициента затрат труда с 1,10 до 1,24. В этом случае модифициро-
ванная оценка стоимости программной разработки стала бы следующей:
ККЗ=1,32; '
Затраты труда = 44 ЧМ-1,32=58 ЧМ;
Затраты денежных средств=56 ЧМ-6000 долл./ЧМ ^348 000 долл.
Таким образом, расходы на ПО возросли бы на 42 тыс. долл, и, следовательно,
приобретение более дешевого микропроцессора неоправданно.
84. ПРИМЕР УПРАВЛЕНИЯ ПРОЕКТОМ ПРИ УМЕНЬШЕНИИ СРЕДСТВ
ДЛЯ ЕГО ЗАВЕРШЕНИЯ
Проблема. Предположим, что обсужденный в предыдущем разделе проект
разработки ПО системы связи на микропроцессорах решено осуществит! с исполь-
зованием варианта закупки дополнительной памяти и сокращения стоимости
программной разработки до 288 тыс. долл. Предположим также, что фаза про-
ектирования изделия завершается в соответствии с бюджетом и на ее выполнение
потребовалось 52 тыс. долл. (18 % полных затрат на разработку согласно дан-
ным табл. 8.1) *. После этого на завершение проекта остается 23Г тыс. долл
Допустим, что в этот момент компания, заказавшая ПО, сообщает разработ-
чикам об отсутствии у нее необходимых денежных средств и о возможности пре-
доставления на завершение программной разработки только 200 тыс. долл,
(на 15 % меньше). Что можно предпринять в подобной ситуации?
Для решения поставленной проблемы необходимо установить возможные
изменения стоимостных атрибутов проекта, позволяющие уменьшить оценку про-
ектных затрат на 15 % (на рассматриваемой ранней стадии проекта это по суще-
ству равносильно сокращению на 15 % средств, необходимых для завершения
проекта). Изменения же эти можно определить и оценить с помощью прсмежу
точной КОМОСТ.
Первое ре-ц !ние: уменьшение размера изде -ия. Наиболее удовлетворительным
решением является уменьшение размера разрабатываемого изделия за счет исклю-
чения некоторых его функций или перенесения сроков их разработки на более
поздний момент времени. Это означает, что необходимо определить, до какого
ЧИК нужно довести размер изделия, чтобы уменьшить на 15 % номинальные
затраты труда на разработку, т. е. с 44 до 37,4 ЧМ (при уменьшении номиналь-
ной оценки на 15 % скорректированная оценка также уменьшится на 15 %, если
все остальные стоимостные атрибуты не изменяются).
Из ‘'равнения затрат труда (см. табл. 8.1) находим, что оценке номинальных
затрат 37,4 ЧМ соответствует размер изделия приблизительно 8700 ЧИК. Следо-
. ательно, если можно найти такой способ уменьшения размера изделия на 1300
ЧИК, при котором по-прежнему будут удовлетворяться основные ~ потребности
заказчика то можно будет уложиться в сокращенный бюджет разработки1 2.
Другие возможные решения. Промежуточная КОМОСТ указывает (в соо -
ветствии с табл. 8.2) другие возможности уменьшения приблизительно на 15 %
стоимости проект-
1. Уменьшить требуемую надежность с номинальной до низкой.
1 В промежуточной КОМОСТ для оценки распределений по фазам и работам,
а также для оценки сроков разрабстг- в зависимости от числа ЧМ используются
те же соотношения, что и в базовой КОМОСТ.
2 Здесь предчолагается, что издержки на переориентацию проекта пренебре-
жимо малы. Это, однако, не всегда верно.
130
Это сократило бы стоимость проекта на 12 % (коэффициент затрат труда из-
менился бы с 1,00 до 0,88). Такое решение можно рекомендовать лишь при соот-
ветствующем изменении предполагаемого использования изделия; в противном
случае это решение просто приведет к увеличению затрат и трудностей при экс-
плуатации и сопровождении.
2. Повысить требования к квалификации привлекаемых к работе аналитиков
и программистов с высоких до очень высоких (привлечение специалистов экстра-
класса). Осуществление любой из этих двух мер позволило бы уменьшить стои-
мость проекта приблизительно на 17... 19 % [для аналитиков:
(1—0,71/0,86) 100 % = 17 %; для программистов: (1—0,70/0,86)100 % = 19 %]. Обыч-
ной трудностью при этом решении является поиск специалистов такого
класса.
3. Повысить требования к опыту работы в данной прикладной области с но-
минальных до очень высоких или к опыту работы с виртуальной машиной с низких
до высоких (привлечь экспертов). Осуществление любой из указанных мер позво-
лило бы сократить стоимость проекта на 19 % [для повышенного опыта работы
в данной прикладной области: (1—0,81) 100% = 19%; для повышенного опыта ра-
боты с используемой виртуальной машиной: (1—0,9/1,10)100 % = 18,2 %]. И снова
главной трудностью является поиск для проекта таких специалистов.
4. Обеспечить проект диалоговой системой поддержки программной разра-
ботки. Это позволило бы уменьшить рейтинг цикла обращения к ЭВМ с поминаль-
ного до низкого, что привело бы к экономии на 13 % (соответствующий коэффи-
циент затрат труда изменился бы с 1,00 до 0,87).
5. Ослабить требования к характеристикам работы в реальном времени. Так,
положим, что 70 %-ное ограничение по быстродействию связано с желанием за-
казчика обеспечить обработку одного сообщения в среднем за 2 мс. Если же
заказчик согласится на увеличение среднего времени обработки с 2 до 3 мс, то
ограничение по быстродействию станет равным 47 % [70 % (2 мс/3 мс)=47%],
в результате чего рейтинг атрибута ОВД уменьшится с высокого до номинального,
что приведет к экономии на 10 % [(1—1,00/1,11)100 % = 10 %].
Другие факторы снижения затрат. Учет других стоимостных факторов вряд
ли поможет в рассматриваемой ситуации. Некоторые стоимостные атрибуты (раз-
мер базы данных, ограничение по объему памяти и срокам разработки) уже име-
ют наименьшие возможные значения, для других трудно ожидать быстрого улуч-
шения (использование инструментальных средств и практика применения совре-
менных методов программирования), на некоторые разработчик почти не может
повлиять (сложность изделия и изменяемость виртуальной машины). А последний
стоимостный атрибут КОМОСТ (опыт работы с языком программирования) может
позволить сэкономить не более 5 %.
Выбор решения. Итак, наиболее подходящим решением является исключение
некоторых функций разрабатываемого изделия или перенесение сроков разра-
ботки на более поздний момент времени. Следующим по предпочтительности ре-
шением было бы ослабление требований к характеристикам работы системы
в реальном времени, особенно если значения этих характеристик были установле-
ны в какой-то степени произвольно. Принятие же других решений зависит
от наличия необходимых специалистов или диалоговых средств разработки
программ.
Таким образом, окончательное решение будет, по-видимому, выбрано в про.-
Цессе переговоров представителей разработчиков и заказчика, которые должны
будут учесть все соображения. При этом промежуточная КОМОСТ может ока-
Зать большую помощь как при определении возможных решений бюджетных
проблем заказчика и разработчика, так и в процессе согласования изменений
плана разработки.
И КОРРЕКТИРОВКА ОЦЕНКИ ЕЖЕГОДНЫХ ЗАТРАТ НА СОПРОВОЖДЕНИЕ
Коэффициенты затрат промежуточной КОМОСТ могут приме-
ияться не только в случае разработки, но и в случае сопрово-
ждения.
5*
131
Для ботьшинс^ва стоимостных атрибутов можно с полной уве-
ренностью предположить, что соответствующие коэффициенты за-
трат труда определяются одинаково для сопровождения и разра-
ботки (т. е. они задаются табл. 8.2). В этом случае достаточно
определить корректирующие множители по изменившимся рейтин-
гам: исполнители сопровождения являются более (или менее)
опытными, чем разработчики; цикл обращения к ЭВМ меньше
(или больше) при сопровождении и т. п.
Стоимостный атрибут, не используемый при оценке сопровожде-
ния. Ограничение сроков разработки влияет только на разработку
Тот факт, что ПО создавалось не в номинальные сроки, заметно
не влияет на затраты труда при сопровождении. Поэтому на фазе
сопровождения соответстгующий стоимостному атрибуту ОСР
коэффициент затрат труда устанавливается равным 1,00.
Изменение коэффициента затрат труда для TH ПО. Из-за раз-
личного влияния на разработку и сопровождение атрибутов ТНПО
и ПСП их коэффициенты изменятся.
Таблица 8.7
Коэффициенты затрат труда для ЦНПО при сопровождении
Рейтинг Очень низкий Низкий Номиналь- ный Высокий Очень высокий
Коэффициент 1,35 1,15 1,00 0,98 1,10
Коэффициенты для ТНПО приведены в табл. 8.7 по каждому
рейтингу. Данные этой таблицы указывают ча две тенденции:
1) чем ниже требуемая надежность, тем меньшие затраты не-
обходимы на поддержание этого уровня надежности;
2) чем ниже требуемая надежность, тем большие затраты не-
обходимы на исправление скрытых программных ошибок и на об-
новление программного изделия с некачественными документацией
и (или) кодом.
Следует также отметить, что оценка ТНПО не изменится при
переходе от разработки к сопровождению. Так, например, не сле-
дует ожидать что созданное при низких требованиях по надежности
программное изделие будет работать с небольшим числом ошибок.
Изменение коэффициента затрат труда для атрибута ПСП.
Использование современных методов программирования (структу-
рирования программ, проектирования и разработки методом свер-
ху— вниз, сквозного контроля, предварительного документирова-
ния и библиотеки поддержки разработки) во время разработки (и
сопровождения) оказывают двойное влияние на сопровождение'
1) чем в большей степени используется ПСП, тем меньше за-
траты на сопровождение;
132
Таблица 8.8
Коэффициенты затрат труда для ПСП в случае сопровождения
Размер изделия, КЧИК Рейтинг
очень низкий НИЗКИЙ номи- нальный высокий очень высокий
2 1,25 1,12 1,00 0,90 0,81
8 1,30 1,14 1,00 0,88 0,77
32 1,35 1,16 1,00 0,86 0,74
128 1,40 1,18 1.00 0,85 0,72
512 1,45 1,20 1,00 0,84 0,70
2) чем в большей степени используется ПСП, тем легче сопро-
вождать большие изделия (тем меньше отрицательный эффект
масштаба при сопровождении ПО).
Это двойное влияние наглядно иллюстрируют коэффициенты
затрат для ПСП в случае сопровождения из табл. 8.8.
8.6. ПРИМЕР СОПРОВОЖДЕНИЯ ПО СВЯЗИ НА МИКРОПРОЦЕССОРАХ
В качестве примера использования коэффициентов затрат на сопровождение
рассмотрим ПО связи на микропроцессорах, оценки стоимостных атрибутов раз-
работки которого приводились в табл. 8.6, причем рейтинг ОП нужно снизить до
номинального в связи с приобретением дополнительной оперативной памяти.
Напомним, что на разработку этого программного изделия объемом 10 КЧИК
потребовалось 48 ЧМ и 288 тыс. долл.
Определим теперь годовые затраты труда и денежных средств на сопровож-
дение этого изделия, учитывая следующее:
изделие будет сопровождаться аналитиками и программистами номинальной,
а не высокой квалификации, и издержки снизятся до 5000 долл, на человеко-
месяц;
изменяемость виртуальной машины будет низкой, а не номинальной;
опыт работы с виртуальной машиной будет номинальным, а не низким;
коэффициент пересчета годовых изменений составит 20 %.
Номинальные годовые затраты труда на сопровождение можно получить из
номинальных затрат на разработку (44 ЧМ для изделия размером 10 КЧИК) и
КПГИ (0,20):
ЧМ1,.г.с = 0.20-44 ЧМ=8,8 ЧМ.
Скорректированная оценка затрат на сопровождение ЧМ берется равной 1,00
Для ОСР и вычисляется с использованием коэффициентов, определяемых из
табл. 8.7 для ТНПО; из табл. 8.8 для ПСП и из табл. 8.2 для остальных стоимо-
стных атрибутов.
В табл. 8.9 сведены окончательные рейтинги стоимостных атрибутов разра-
ботки и сопровождения. С учетом этих рейтингов ККЗ на сопровождение полу-
чается равным 1,14.
Таким образом, скорректированная оценка годовых затрат труда составит
8,8 ЧМ-1,14= 10,0 ЧМ.
Отсюда определяем, что среднее число исполнителей для сопровождения
Улет равно 0,83 ЧИ (10 ЧМ/12 мес.=0,83 ЧИ). Учитывая издержки в 5 тыс.
Долл /ЧМ, определим расходы на сопровождение как 50 тыс. долл./год.
Анализ чувствительности шестилетнего ЖЦПО к требуемой надежности. Если
“ предполагалось эксплуатировать и сопровождать программное изделие в тече-
лет> Т0_52л1Че затраты на ЖЦПО составили бы 288 000 долл.+
ПО не с но-
“ OUVUU долл. = РВИ U00 долл.
м Предположим, что было решено разрабатывать и сопровождать
"Нальной, а с очень низкой надежностью.
133
Таблица 8.9
Рейтинги стоимостных атрибутов сопровождения ПО
связи на микропроцессорах
Стоимостный атрибут Рейтинг разработки Рейтинг сопровожден ия Коэффициент затрат труда при сопровожден и и
ТНПО Номинальный Номинальный 1,00
РБД Низкий Низкий 0,94
СИЗ Очень высокий Очень высокий 1,30
ОБД Высокий Высокий 1,11
ОП Номинальный Номинальный 1,00
ИВМ Номинальный Низкий 0,87
ЦО Номинальный Номинальный 1,00
КА Высокий Номинальный 1,00
ОРП Номинальный Номинальный 1,00
КП Высокий Номинальный 1,00
ОРВМ Низкий Номинальный 1,00
ОРЯП Номинальный Номинальный 1,00
ПСП Высокий Высокий 0,88
НИС Низкий Низкий 1,10
ОСР Номинальный — 1,00
Корректирующий коэффициент затрат труда 1.14
Оправдывает ли себя экономия при разработке, если учесть шестилетний срок
жизни изделия? Для получения ответа вычислим исправленные оценки стоимости
разработки (по данным табл. 8.2):
288 000 долл.-0,75=216 000 долл.
и стоимость сопровождения (по данным табл. 8.7)
300 000 долл.-1,35=405 000 долл
В результате получаем, что полные расходы на ЖЦПО составят 621 000 долл.
Отсюда ясно, что для рассмотренной в данной ситуации программной разработки
невыгодно разрабатывать ненадежное ПО. Однако в других ситуациях (например,
при уменьшении КПГИ до 2% или сокращении времени сопровождения до года)
такой подход к ЖЦПО мог бы оказаться вполне экономически целесообразным
8.7. ИНТЕРПОЛЯЦИЯ И ЭКСТРАПОЛЯЦИЯ
Таблицы 8.2, 8.7 и 8.8 можно использовать для интерполяции
таким же образом, как и в гл. 6 и 7. Например, ограничению по
быстродействию, равному 90% (среднее между значениями из
табл. 8.3 для очень высоких и сверхвысоких рейтингов), соответст-
вовал бы коэффициент затрат труда, равный 1,48 (среднее между
значениями из табл. 8.2 для очень высоких и сверхвысоких рейтин-
гов). Аналогично для квалификации аналитика с рейтингом 80%
(делящим диапазон между высоким и очень высоким рейтингом в
табл. 8.3 в отношении 1:2) соответствовал бы коэффициент за-
трат, равный 0,81 (делящий диапазон между значениями из
табл. 8.2 для высоких и очень высоких рейтингов в отношении
1 :2).
В табл. 8.3 встречается знак Такое обозначение подразу-
мевает, что соответствующая оценка относится ко всем ситуациям,
134
удов-етвопяющим этому соотношению и что соответствующее зна-
чение коэффициента может использоваться при интерполяции. На-
пример, ограничению по оперативной памяти 40% соответс.вует
коэффициент затрат труда, равный 1,00, а ограничению 60% — 1,03.
Экстраполяцию за пределы значений таблицы использовать не
Рекомендуется, так как вне этих пределов результаты сильно за-
висят от конкретной ситуации и трудно предсказуемы. В частности,
оценка ограничения сроков разработки никогда не должна быть
меньше очень низкой оценки, равной 75% номинальных сроков,
Поскольку опыт разработок показал, что практически невозможно
сократить номинальные сроки ботее чем на 25% (см. гл. 27).
8.8. ВЫЧИСЛЕНИЕ КОЭФФИЦИЕНТА АДАПТАЦИИ СУЩЕСТВУЮЩЕГО ПО
Обсуждение адаптации. Ранее оценка стоимости ПО основыва-
лась на предположении, что все исходные команды программного
изделия специфицируются и разрабатываются заново. Однако ча
сто дело обстоит не так. Многие программные изделия состоят из
вновь разработанных частей и заимствованного ПО, адаптирован-
ного для нового изделия.
Каким образом следует учитывать адаптированное ПО в оцен-
ках программной разработки? Безусловно, не следует учитывать
размер адаптированного ПО аналогично размеру разрабатываемо-
го ПО. Например, предположим, что в разработанном изделии
используется простая программа ввода-вывода из библиотеки стан-
дартных сервисных программ ВЦ и при подсчете размера изделия
в ЧИК для оценки проекта учитывается размер этой подпрограм-
мы. В этом случае размер изделия увеличивается на несколько
сотен ЧИК, что в свою очередь увеличивает на несколько ЧМ
оценку затрат труда на разработку. Однако на самом деле исполь-
зование этой подпрограммы ввода-вывода нисколько не увеличи-
вает трудоемкость осуществления программного проекта.
В то же время нецелесообразно не принимать во внимание
адаптированное ПО. Во многих случаях его использование может
потребовать значительных усилий на проведение следующих работ
при создании изделия:
1) перепроектирование адаптируемого ПО с тем, чтобы оно
соответствовало целям разработки нового изделия;
2) переработку некоторых частей программы для учета резуль-
татов перепроектирования или приспособления к условиям работы
создаваемого изделия (аппаратуре, ОС и т. п.);
3) комплексирование адаптированного изделия с разрабатывае-
мым и испытание окончательного изделия.
Следовательно, необходим метод оценивания результатов адап-
•Пжи, учитывающий каждую из трех указанных статей расходов
1а адаптацию. Такой учет лежит в основе используемых в
КОМОСТ уравнений для оценки адаптации.
Уравнения КОМОСТ для оценки адаптации. Для учета адапти-
рованного ПО используется величина, называемая эквивалентным
135
числом исходных команд (ЭЧИК)- Эта величина применяется
вместо ЧИК в оценках адаптируемого ПО и вычисляется на базе
следующих величин:
АЧИК (адаптированное число исходных команд) — число по-
ставляемых исходных команд, полученных адаптированием сущест-
вующего ПО для включения в новое изделие;
ДИП (доля изменений проекта)—выраженная в процентах
доля ПО измененного при адаптации к новым условиям работы и
цепям (оценка этой величины неизбежно субъективна);
ДИК (доля изменяемых кодов) — выраженная в процентах до-
ля команд, измененных при адаптации ПО к новым условиям ра-
боты и целям;
ДЗК (доля затрат на комплексирование и испытания) —выра-
женная в процентах доля затрат труда, требующегося на комп
лексирование адаптированного ПО с разрабатываемым изделием
(эта доля берется от номинальных затрат на комплексирование и
испытания для ПО равного объема).
Уравнения для вычисления ЭЧИК включают промежуточную
величину — корректирующий коэффициент адаптации (ККА) — и
имеют следующий вид:
' ККА=0,4? - ДИП+0,30 • ДИК+0,30 • ДЗК;
ЭЧИК=АЧИК-ККА/100.
Подробное обоснование будет дано ниже, но вначале рассмо-
трим несколько примеров использования этих уравнений.
Пример 1: подпрограмма ввода-вывода (простое сервисное ПО). Адаптация
подпрограммы ввода-внвода не требует по существу никаких усилий. Для этой
подпрограммы характеристики адаптации примут следующие значения:
ДИП=0 (отсутствует изменение проекта); ДИК=0 (отсутствует изменение
код?);
ДЗК=0 (не требуется затрат на комплексирование с изделием).
Следовательно, ККА=0 и ЭЧИК=0. Это означает, что использование простых
сервисных пс дпрограмм не приводит к увеличению расходов
Пример 2: простой перенос ПО. Предположим, что необходимо перенести
программу анализа электронных схем (р щмером 50 КЧИК, распространенного
типа, написанную на языке Фортран) с ЭВМ Univac 1110 на ЭВМ IBM 3033. Ти-
пичными для рассматриваемой ситуации являются следующие значения характе-
ристик адаптации:
ДИП=0 (отсутствуют изменения проекта);
ДИК=15 (возможно изменение 15 % команд из-за собенностей компилято-
ра, ОС, интерфейса, языка управления заданиями и т. п.);
ДЗК=5 (указанные изменения не повлекут значительных затрат на комплек-
сирование) .
Используя приведенные оценки, получаем остальные характеристики:
ККА=0,40-0+0,30-15+0,30-5=6;
ЭЧИ1’=50 000-6/100=3000.
В базовой КОМОС Г для оценки проектов распространенного типа исполь-
зуется уравнение (5.1). Подставив в него значение ЭЧИК, выраженное, в тыся-
чах эквивалентных исходных команд (КЭЧИК), получае»-
ЧМ=2,4 КЭЧИК’-°5=2,4-3‘.оь=7,6.
В заключение определим производительность труда при переносе:
50 000 ЧИК/7,6 ЧМ=6580 ЧИК/ЧМ.
Пример 3: более сложней перенос Предположим, что прч переносе ocoi о
внимание должно быть уделено эффективности и точности и что вследствие этого
136
„еренос оверлейной структуры программы анализа электронных схем и переход
от 36-разрядного слова ЭВМ Univac 1110 к 32-разрядному слову ЭВМ IBM 3033
требует некоторого перепроектирования программы. Типичными для рассматри-
ваемой ситуации являются следующие значения характеристик адаптации:
ДИП=15 (некоторые изменения оверлейной структуры, численных алгорит-
мов и связанной с ними логической структуры);
. ДИК=30 (при таких значениях характеристик объем изменений кодов про-
граммы примерно в 2 раза больше объема изменений проекта);
ДЗК=20 (в основном из-за необходимости согласования изменений оверлей-
ной структуры).
Г Используя приведенные значения, получаем оценку затрат труда на перенос:
ККА=0,40 -15+0,30 30+0,30 20=21;
ЭЧИК=50 000-21/100= 10 500;
ЧМ=2,4- 10,5,-О5=28.
В заключение определим производительность труда при переносе:
50 000 ЧИК/28 ЧМ= 1800 ЧИК/ЧМ.
I Пример 4: большие доработки, сложные интерфейсы. Предположим, что раз-
работано ПО процессора связи, имеющее объем 10 КЧИК. Спустя некоторое вре-
мя получен заказ на оценку стоимости адаптации этого ПО для использования
в ЭСП. В такой ситуации можно было бы получить следующие оценки:
ДИП=35 (существенное изменение проекта для учета новых форматов сооб-
щений, протоколов и оборудования);
ДИК=60 (многие изменения проекта будут иметь побочные эффекты, влеку-
щие за собой дополнительные изменения кодов программы);
ДЗК= 140 (комплексирование и испытания ПО будут проводиться в совер-
шенно новых условиях?).
С помощью приведенных оценок получаем остальные характеристики адапта-
ции.
ККА=0,40 • 35+0,30 • 60+ 0,30 • 140 = 74;
ЭЧИК= 10 000-74/100= 7400.
Как и в разд. 8.3, используя уравнения промежуточной КОМОСТ из табл. 8.1
цля оценки номинальных затрат труда на разработку встроенного ПО, получаем
ЧМВОм = 2,8-7,41'20=31 ЧМ.
Используя приведенный в табл. 8.6 корректирующий коэффициент затрат
труда, находим
ЧМОЦ=31-1,17=36 ЧМ.
Теперь, учитывая издержки в 6000 долл, на ЧМ, можно вычислить оценку
стоимости адаптации:
36 ЧМ-6000 долл./ЧМ=216 000 долл.
Пример 5: адаптация компоненты. Предположим, что для бразильского
агентства связи необходимо разработать ПО процессора связи. Поскольку про-
цессор связи и протоколы передачи данных существенно отличаются от ранее
Рассмотренных, в новом проекте нельзя использовать большей части ранее разра-
ботанного ПО. Однако оказывается, что имеющий объем 1 КЧИК модуль марш-
рутизации сообщений можно адаптировать без особых затруднений. Параметры
адаптации этого модуля к новому применению таковы:
ДИП=5 (небольшое изменение проекта для учета изменившихся правил
Маршрутизации при подтверждении приема);
ДИК= 15 (изменение кодов программы, отражающее изменение проекта и
Учитывающее особенности новой ЭВМ);
ДЗК=25 (модуль маршрутизации сообщений вполне независим от других
Отей ПО, однако ожидаются некоторые расходы при работе с новыми тестовыми
Данными и программами).
б 1 Нет никаких причин, по которым значения ДИП, ДИК и ДЗК не могут
ParJ больше 100. Фактически довольно часто на адаптацию существующего ПО
подуется больше усилий, чем требовалось бы на новую разработку.
137
Р^Используя приведенные оценки, получаем остальные характеристики адапта
ции:
ККА=0,40-5+0,30-15 +0,30-25= 14;
ЭЧИК=1 000-14/100=140.
При расчете общего размера ПО, разрабатываемого для Бразильского агент-
ства связи, необходимо прибавить полученную оценку адаптировайной программ-
ной компоненты (140 ЭЧИК) к размеру остальных частей ПО, допустим
9000 ЧИК, что дает в результате 9140 ЭЧИК. Считая тип разработки, корректи
рующий коэффициент затрат и издержки на оплату труда исполнителей в расчете
на один ЧМ такими же, как и в первоначальном проекте (т. е. тип разработки —
встроенный, ККЗ— 1,17, издержки — 6000 долл./ЧМ), получаем:
ЧМном = 2',8-9,14,'20=40 ЧМ;
ЧМ0Ц = 40-1,17=47 ЧМ.
Затраты денежных средств =(47 ЧМ-6000 долл./ЧМ) =280 000 долл.
Обоснование уравнений КОМОСТ для оценки адаптации. Коэф
фициенты в уравнении (8.1), используемом для оценки ККА, вы
браны с учетом соотношения затрат труда на проектирование^ ко-
дирование, комплексирование и испытания:
Проектирование ..... . 40%
Кодирование .... . 30%
Комплексирование и испытания 30%
Соотношения затрат труда на различных фазах несколько ме-
няются в зависимости от размера изделия и типа разработки, но
поскольку ККА не очень чувствителен к небольшим изменениям
коэффициентов, то для простоты используются их средние значе-
ния. Организации, проекты которых имеют распределения по фа-
зам, значительно отличающиеся от указанного, могли бы исполь-
зовать и другую формулу, например для малых встроенных про-
ектов.
ККА=0,40 ДИП + 0,40 ДИК + 0,20 ДЗК.
Предостережение против недооценки адаптации. Ни одну вели-
чину нельзя так легко недооценить, как объем тех изменений
существующих, программ, которые необходимы для успешной рабо-
ты программ в составе нового изделия. Чтобы избежать недооцен-
ки, полезно следовать двум приводимым ниже общим рекоменда-
циям
1) необходимо избегать излишне оптимистических оценок;
2) целесообразно рассмотреть характерный образец существую-
щего ПО и подробно определить, что необходимо для адаптации
(Как правило, при этом неожиданно обнаруживается множество
побочных эффектов и усложняющих обстоятельств, что существен-
но помогает осознать всю сложность ситуации.)
8.9. ОБСУЖДЕНИЕ УРАВНЕНИЙ ПРОМЕЖУТОЧНОЙ КОМОСТ
Коэффициенты для стоимостных атрибутов промежуточной
КОМОСТ являются средними значениями коэффициентов деталь-
ной КОМОСТ, описываемой далее в ч. 4. В детальной КОМОСТ
138
для каждой фазы программной разработки используются отдель-
ные наборы коэффициентов стоимостных атрибутов; эти коэффи-
циенты были определены в результате выполнения следующих че-
тырех действий:
1) анализа фактических данных для определения наиболее важ-
ных стоимостных атрибутов;
Рис. 8.3. Оценки затрат труда по промежуточной КОМОСТ и фактические дан-
ные:
ООО —распространенный тип; ххх — полунезависимый тип: АДА — встроенный тип
2) двух последовательных опросов в рамках метода «Дельфы»,
8 результате которых десять опытных руководителей программных
разработок определили начальные значения коэффициентов;
3) уточнения коэффициентов при использовании подмножества
базы данных КОМОСТ из 36 проектов;
4) небольшой окончательной корректировки коэффициентов при
использовании подмножества базы данных КОМОСТ из 56 проек-
те с целью устранить некоторые расхождения в распределении
затрат по фазам.
После этого фазозависимые коэффициенты детальной КОМОСТ
были усреднены по всем фазам разработки и в результате были
139
получены коэффициенты промежуточной КОМОСТ, не зависящие
от фазы программной разработки.
Сравнение оценок промежуточной КОМОСТ с фактическими
данными. Такое сравнение по 63 проектам представлено на
цис. 8.3. На приведенном графике оценки и Фактические значения
значительно лучше согласуются друг с другом, чем на графике для
базовой КОМОСТ (ср. рис. 6.4). (Значительные расхождения
Рис. 8.4. Номинальные затраты, полученные по уравнениям промежуточной
КОМОСТ, и фактические данные:
ООО —распространенный тип: ххх — полунезависимый тип: АДА — встроенный тип
между оценками базовой КОМОСТ и фактическими данными уст-
ранены, главным образом за счет учета в промежуточной КОМОСТ
дополнительных стоимостных атрибутов.) Оценки промежуточной
КОМОСТ отличаются от фактических данных не более чем на
20% в 68% всех случаев, т. е. являются достаточно точными для
большинства практически важных целей. Из рисунка видно также,
что оценки приблизительно одинаково точны для всех трех типоэ
программной разработки.
Сравнение уравнений промежуточной КОМОСТ для номиналь-
ных затрат труда с фактическими данными. На рис. 8.4 показано,
почему в промежуточной КОМОСТ для каждого из трех типов раз-
140
работки используется отличное от других уравнение оценки но-
минальных затрат труда. На нем отражено влияние только разме-
ра изделия после того, как затраты труда были нормированы
приведением к номинальному значению.
Точнее, на рис. 8.4 сопоставлены размеры изделия с нормиро-
ванными затратами труда:
ТТХЛ Затраты труда на проект
^''Тном К КЗ *
где корректирующий коэффициент вычисляется по имеющимся в
базе данных КОМОСТ оценкам стоимостных атрибутов для каж-
дого проекта (эти оценки приведены в табл. 29.1).
После приведения стоимостных атрибутов, отличных от разме-
ра изделия, к номинальному значению данные по затратам труда
(см рис. 8.4) четко расчленяются на группы, которые достаточно
хорошо описываются уравнениями промежуточной КОМОСТ для
оценки номинальных затрат.
Более подробно настройка и обоснование промежуточной
КОМОСТ обсуждаются в главе 29. В частности, в указанной главе
рассматривается вопрос настройки промежуточной КОМОСТ на
опыт разработок в конкретной организации. По различным причи-
нам, главным образом вследствие отличий в определениях, этот
опыт может не соответствовать характеристикам проектов базы
данных КОМОСТ В таком случае настроенная версия КОМОСТ
даст для рассматриваемой организации более хорошие результаты.
Система измерений взвешенными исходными командами. Мож-
но взглянуть на различия базовой и промежуточной КОМОСТ сле-
дующим образом.
В базовой КОМОСТ предполагается, что затраты на производ-
ство команды (в разработке конкретного типа) никак не зависят
от условий разработки. В промежуточной же КОМОСТ учитывает-
ся, что исходные команды зависят от требований по надежности,
ограничений по быстродействию и памяти и т. п., их относительно
труднее разрабатывать или «тяжелее правильно согласовать друг
с другом», чем равное число команд, проектируемых в номиналь-
ных условиях.
Таким образом, в промежуточной КОМОСТ оценка стоимост-
ных атрибутов используется для создания новой системы измере-
ния размера изделия числом взвешенных исходных команд ’, кото-
рая, как видно из рис. 8.4, гораздо лучше согласуется с фактиче-
скими данными по проектам базы данных КОМОСТ, чем в случае
использования для измерений размеров изделий невзвешенных
исходных команд, которые применялись в базовой КОМОСТ (см.
рис. 6.5).
1 В данном случае число взвешенных исходных команд определяется как
15
ВЧИК-КЧИКе/ П К3„
гДе — показатель степени в уравнении затрат для рассматриваемого типа раз-
работки, а КЗ,- — коэффициент затрат для стоимостного атрибута.
141
ГЛАВА 9
ПРОМЕЖУТОЧНАЯ КОМОСТ. ОЦЕНКА НА УРОВНЕ
КОМПОНЕНТОВ
9.1. ВВЕДЕНИЕ
В предыдущих главах рассматривались только макромодели
оценки стоимости, самые распространенные в настоящее время
модели стоимости ПО (см., например, [118, 243, 244]). В макромо-
делях предполагается, что стоимостные атрибуты одинаковы для
всех частей программного проекта, например разработчики каждо-
го компонента обладают одинаковыми квалификацией и опытом и
все компоненты одинаково сложны. Такой подход пригоден для
приближенных первоначальных оценок стоимости всего програм-
много изделия, но безусловно недостаточен при учете свойств его
отдельных компонентов.
Например, планируется назначение высококвалифицированных
специалистов на сложные участки работы (а это увеличивает из-
держки на оплату труда исполнителей), а специалистов с меньши-
ми квалификацией и опытом — на простые участки работы, и не-
обходимо проанализировать такой подход к управлению проектом
Так вот, оказывается, что при использовании средних для всего
изделия значений оценок стоимости результаты такого подхода
получаются неопределенными, а иногда рискованными ’.
В этой главе будут представлены процедуры и форма использо-
вания промежуточной КОМОСТ на уровне компонентов изделия.
Это позволит легко и согласованно применять промежуточную
КОМОСТ на всех этапах разработки программного изделия: как
макромодель на ранних этапах и как микромодель на более позд
них этапах.
9.2. ФОРМА ДЛЯ ОЦЕНКИ НА УРОВНЕ КОМПОНЕНТОВ
Опыт показал, что при сборе и регистрации информации для
оценивания стоимости ПО на уровне компонентов весьма полезна
стандартная, специально приспособленная для этой цели форма.
Форма оценивания на уровне компонентов (ФОК) показана на
рис. 9.1. Процедура использования ФОК для получения оценок
стоимости ПО довольно проста, она приведена в табл. 9.1.
* Это наглядно показывает следующий расчет. Будем считать, что программ-
ное изделие состоит из W компонентов размером V,- (1=1, ... N); сложность раз-
работки одной команды i-го компонента обозначим С,-. Среднее значение слож
ности вычисляется в макромодели как YCi/N, а корректирующий коэффициент
оценки стоимости пропорционален сложности. Отношение корректирующих коэф-
фициентов для изделия при учете компонентов и расчете с помощью макромодели
равно (2C, Vi)/(ECi/A') (V,-)). Если предположить, что и Vt«XVi, то
значение приведенного отношения равно приблизительно N. Таким образом, ис-
пользование макромодели дает результаты, далекие от фактических значений. —
Прим перев.
142
Проск О Компонент г. рмрлОрукв ® ЭЧИК штомвт © ККА пиропе ® тнпо ИНОЙ с 4здел1 ® РБД истемь 1е © сиз упри/ ® ° БД онин п ЭВМ ® оп кэцеесс ® ИВМ М Н1’ф1 ® ЦО еочист ® КА ки Испол ® ОРП нитель ® КП Анел ® OPBM итик: ® ОРЯП фами ® псп пил 1поект ® иис ® OCP ® ККЗ ® ЧМ чмр или ЧМГС, ЧМ ЭЧИК/ЧМ или КПГИ ИЧ и СТ, тыс. ~ долл./ЧМ и (ср |2 тыс. долл. К СТ/ЭЧИК, ! 1 ДОЛЛ./ЭЧИК » 11
1.ПРОЦЕСС 7000 1.0 в ни в В но но ни В но но но но в но НО 26 24 292 5,5 19
1.15 0.94 1.15 1.11 1.0 1.0 0, 87 0,86 1.0 1,0 1.0 1.0 0.91 1,0 1.0 094 132
2.ОПСИС 5000 1.0 В НИ ОВ в но но НИ В ни в ни ни В НО но 19 23 217 6,0 28
1.15 0.94 1,30 1.11 1.0 1.0 0.87 0,86 1.13 0.86 1,10 1,07 0,91 1.0 1.0 1,21 138
З.ВВ 10 000 1.0 НО НИ но НО но но НИ НО но но ни НО В НО НО 37 30 333 5,0 15
10 0.94 1.0 1.0 1.0 1,0 0,87 1.0 1.0 1.0 1,10 1.0 0,91 1,0 1,0 0,82 150
4.
5.
6.
7.
8.
9.
10.
11. 22 000 Общее ЭЧИК ёсего 77 286 420 19
12. 82 (чм)„ом.чм Тип разработки: распространенный Срок разработки, мес. 13
13. 268 (ЭЧИК/ЧМ)ном
Рис. 9.1. Форма оценки на уровне компонентов по КОМОСТ (рейтинги:
В —высокий; НО — номинальный, НИ — низкий; ОВ — очень высокий)
Таблица 9.1
Процедура использования формы на уровне компонентов
1. Определить все компоненты программного изделия и записать их в после-
довательные строки столбца 1.
2. Оценить размеры всех конмпонентов (в ЧИК). Если компонент разраба-
тывается заново, его размер записывается в столбец 2. Если же компонент адап-
тируется из существующего ПО, вычислить для него ККА, записать полученное
-значение в столбец 3, вычислить размер в ЭЧИК и записать его в столбец 2.
3. Суммированием размеров компонентов получить размер всего изделия
(общее ЭЧИК) и записать результат в строку 11 столбца 2.
4. Используя размер изделия и уравнение оценки номинальна :х затрат тру-
да для соответствующего типа разработки, получить оценку затрат ЧМном и
записать результат в строку 12 столбца 2.
5. Вычислить номинальную производительность труда по формуле (общее
ЭЧИК)/ЧМном и записать полученное значение в строку 13 столбца 2.
6. Для каждого компонента вычислить номинальные затраты труда по фор
муле
ЧМ„0«=ЭЧИК/(общее ЭЧИК/ЧМ) НОМ
(где ЧМном в правой части формулы вычислено на шаге 4) и записать получен-
ное значение в столбец 20.
7. Используя табл. 8.3. получить рейтинги стоимостных атрибутов для всех
компонентов и записать их в столбцы с 4-го по 18-й.
8. Используя табл. 8.2 и полученные на шаге 7 рейтинги, определить соот-
ветствующие коэффициенты затрат труда и записать их в столбцы с 4-го по
18-й.
9. Для каждого компонента (строки) вычислить корректирующий коэффи-
циент затрат труда (ККЗ) путем перемножения ККЗ из столбцов с 4-го по 18-й
и записать полученное значение в столбец 19.
10 Для получения скорректированной оценки ЧМР каждого компонента пе-
ремножит! ЧМном и соответствующий ККЗ и записать полученное значение в
столбец 21.
11. Сложить скорректированные оценки затрат труда по всем компонентами
записать результат в строку 11 столбца 21.
12. Используя соответствующие типу разработки приведенное ниже уравне-
ние для оценивания сроков, вычислить число месяцев разработки изделия и
записать полученное значение в строку 12 столбца 21.
13. Для каждого компонента и всего изделия вычистить оценку произволч
тельност. труда по формуле ЭЧИК/ ЧМГ и записать полученное значение в
столбец 22.
14 Для каждого компонента оценивать средние издержки на оплату испол-
нителей в течение одного человеко-месяца (ИЧ) и записать результат в верх
нюю часть каждой строки столбца 23.
15. Вычислить стоимость каждого компонента в тысячах долларов по форму-
ле СТ=ЧМР-ИЧ и записать результат в нижнюю часть каждой строки столб-
ца 23.
16. Для получения стоимости всего изделия сложить стоимости отдельных
компонентов и записать результат в строку 11 столбца 23.
17. Для . аждого компонента и всегс изделия вычислить стоимость команды
по формуле СТ/ЭЧИК и записать в столбец 24.
Уравнения адаптации [уравнения (8.1) и (8.2)];
ККА=0,4-(доля изменения проекта)
+0,3-(доля изменения кодов программы)
+0,3- (доля затрат на комплексирование)
ЭЧИК=АЧИК-ККА/100
144
Уравнения затрат труда и сроков (см. табл. 8.1 и 6.1):
Тип разработки Номинальные затраты Сроки
распространенный Полунезависимый Встроенный ЧМном =3,2- КЭЧИК'06 ЧМном = 3,0-КЭЧИК112 ЧМнпм=2,8КЭЧИК|-!0 СР=2,5-ЧМ»-зв СР=2,5-ЧМО’35 СР=2,5-ЧМ° 32
Примечание. КЭЧИК — тысяча ЭЧИК.
Указанная процедура проиллюстрирована также на рис. 9.1
для случая разработки простой автоматизированной системы уп-
равления процессом нефтеочистки. Ниже поясняется пошаговое
применение процедуры к данному примеру.
Шаги 1 и 2. Автоматизированная система управления состоит
из трех главных компонентов, описанных в столбцах 1 и 2 ФОК.
1. Компонент ПРОЦЕСС выполняет основные операции управ-
ления процессом нефтеочистки. Компонент ПРОЦЕСС использует
показания датчиков (температуры, давления, расхода жидкости)
для обеспечения эффективности процесса нефтеочистки и опреде-
ления всех потенциальных аварийных ситуаций. Размер этого ком-
понента оценивается в 7000 ЧИК ’.
2. Компонент ОПСИС выполняет функции операционной систе-
мы: опрос датчиков, обработка прерываний, планирование и управ-
ление ресурсами ЭВМ. Размер ОПСИС оценивается в 5000 ЧИК-
3. Компонент ВВ выполняет функции ввода-вывода: получение
и предварительная обработка информации, вводимой с датчиков,
передача команд устройствам управления процессом нефтеочист-
ки, контроль состояния оборудования, обеспечение индикации на
операторском терминале, ввод с операторского терминала запро-
сов и команд.
Шаги 3, 4 и 5. Общий размер изделия составляет 22 000 ЭЧИК
(22 КЭЧИК). Подставляя общий размер в уравнение номинальных
затрат труда для разработки распространенного типа (см. нижнюю
часть табл. 9.1), можно получить номинальное число ЧМ:
ЧМ„оМ=3,2-221-05=82 ЧМ.
Используя полученное значение, можно определить номиналь-
ную производительность труда:
ЭЧИК/ЧМНом=22 000 ЭЧИК/82 ЧМ=268 ЭЧИК/ЧМ.
Полученные значения следует внести в строки 11—13 столбца
2 ФОК.
Шаг 6. Для каждого компонента вычисляют (исходя из его
размера и производительности труда для всего проекта) затраты
труда на его разработку, затем полученные значения записывают
1 Поскольку в разработке адаптация не применяется, то ЧИК и ЭЧИК сов-
падают.
145
в столбец 20. Например, номинальные затраты труда на ПРОЦЕСС
вычисляют так:
ЧМНом=7000 ЭЧИК/268 ЭЧИК/ЧМ=26 ЧМ.
Шаг 7. С помощью табл. 8.3 определяют рейтинги каждого из
трех компонентов по 15 стоимостным атрибутам. В общем случае
лучше всего выполнить этот шаг, поочередно рассматривая все
компоненты по каждому стоимостному атрибуту, а не наоборот
(для каждого компонента все стоимостные атрибуты), поскольку
процесс сравнения рейтингов одного стоимостного атрибута позво-
ляет, по-видимому, получить более согласованный и обоснованный
набор рейтингов. Полученные рейтинги записывают в верхнюю
часть строки соответствующего компонента по всем столбцам сто-
имостных атрибутов (столбцы 4—18).
Рассмотрим, например, определение рейтингов надежности.
Ясно, что компоненты ПРОЦЕСС и ОПСИС должны обладать вы-
сокой надежностью, поскольку их неправильная работа вполне мо-
жет привести к серьезным авариям и финансовым потерям, а воз-
можно, к определенным нарушениям техники безопасности (но не
столь серьезным, чтобы требовать очень высокой надежности).
В то же время ошибки компонент ВВ обычно менее опасны, а их
влияние, как правило, легче контролировать и компенсировать.
Полученные высокие и номинальное значения рейтингов надеж-
ности записывают в столбец 4.
Еще один пример обеспечивает заполнение столбцов 6, И и 13
(сложность, квалификация аналитика и программиста). Так, ком-
понент ПРОЦЕСС обладает высокой сложностью (значительный
объем межмодульных свяЗёй по управлению и использование ос-
новных операций численного анализа), поэтому планируется для
разработки этого компонента использовать высококвалифициро-
ванных аналитиков и программистов. Компонент же ОПСИС по
оценкам будет обладать очень высокой сложностью (использование
реентерабельного кода и обработки прерываний с фиксированны-
ми приоритетами), поэтому для его разработки планируется при-
влечь аналитиков и программистов с очень высокой квалификаци-
ей. Наконец, компонент ВВ обладает по оценкам номинальной
сложностью (см. табл. 8.4), учитывая использование таких средств,
как выбор устройства, проверка состояния и обработка ошибок
операторов структурного программирования с простой вложен-
ностью, и поэтому планируется поручить разработку этого компо-
нента аналитикам и программистам номинальной квалификации.
Шаг 8. После определения для каждого компонента изделия
рейтингов всех стоимостных атрибутов можно получить соответст-
вующие коэффициенты затрат труда (см. табл. 8.2) и записать эти
коэффициенты в нижние половины строк столбцов с 4-го по 18-й.
Например, в столбце 6 строки ПРОЦЕСС записывают коэффици-
ент затрат труда, равный 1,15, строки ОПСИС—1,30, а строки
ВВ — 1,00 вследствие того, что эти компоненты обладают высокой,
очень высокой и номинальной сложностью соответственно.
146
Шаг 9. Для каждого компонента вычисляют полный ККЗ путем
I перемножения всех частных коэффициентов из столбцов с 4-го по
18-й. Например, ККЗ для ВВ вычисляют следующим образом:
ККЗ =± 0,94 0,87 • 1,10 • 0,91=0,82
и полученный результат записывают в столбец 19.
Шаги 10 и 11. Для каждого компонента вычисляют скорректи-
рованную оценку затрат труда путем умножения номинальной
оценки (содержимое столбца 20) на ККЗ этого компонента (содер-
жимое столбца 19). Так, для ВВ получается следующий результат:
ЧМр=0,82-37 ЧМ=30 ЧМ.
Каждую из скорректированных оценок записывают в соответст-
вующую строку столбца 21; затем оценки для всех компонентов
суммируют и общую скорректированную оценку затрат труда на
разработку зсего изделия (77 ЧМ) записывают в строку 11 столб-
ца 21.
Шаг 12. Для оценки сроков проектирования используют урав-
нение для разработки распространенного типа
СР=2,5-77°-38=13 мес
и полученное значение записывают в строку 12 столбца 21.
Шаг 13. Для каждого компонента и для всего изделия вычис-
ляют оценки производительности труда в ЧИК/ЧМ. Примеры:
компонент ВВ: 10 000 ЧИК/30 ЧМ=333 ЧИК/ЧМ;
все изделие: 22 000 ЧИКЛ'0 ЧМ=286 ЧИК/ЧМ
Полученные результаты записывают в столбец 22.
Шаг 14. Для каждого компонента оценивают средние издерж-
ки на оплату исполнителей в расчете на один ЧМ. Эти издержки
обычно определяются уровнем квалификации и опытности разра-
ботчиков компонентов. Так, например, использование для проек-
тирования ОПСИС высококвалифицированных аналитиков и
программистов приводит к средним издержкам в размере
6000 долл, за один ЧМ, а использование для проектирования ВВ
аналитиков и программистов номинальной квалификации приводит
к средним издержкам в размере 5000 долл, за один ЧМ. Получен-
ные на этом шаге оценки записывают в верхнюю половину строк
столбца 23 для соответствующих компонентов.
Шаги 15 и 16. Для получения оценки стоимости каждого компо-
нента перемножают число ЧМ разработки этого компонента и
соответствующие издержки на оплату исполнителей.
Например:
компонент ОПСИС: 23 ЧМ-6000 долл./ЧМ=138000 долл.;
компонент ВВ: 30 ЧМ-5000 долл./ЧМ=150 000 долл
Полученные оценки записывают в нижнюю часть строк столбца
23 для соответствующих компонентов. Затем для определения оцен-
ки стоимости всего изделия стоимости компонентов суммируют и
полученное значение (420 000 долл.) записывают в стпоку 11 столб-
ца 23.
147
Шаг 17. Для каждого компонента всего изделия вычисляют
оценку стоимости одной команды в долл./ЧИК.-Например:
компонент ВВ: 150000 долл./ЮООО ЧИК=15 долл./ЧИК;
все изделие: 420000 долл./22 000 ЧИК=19 долл./ЧИК-
Полученные значения записывают в столбец 24. На этом процесс
оценивания заканчивается.
9.3. ИСПОЛЬЗОВАНИЕ ФОК ДЛЯ АДАПТИРУЕМОГО ПО
Предположим, что при разработке описанной автоматизирован-
ной системы управления процессом нефтеочистки компоненты
ОПСИС и ВВ можно было бы получить путем адаптации сущест-
вующей системы управления технологическим процессом, разра-
ботанной на подобной конфигурации вычислительной системы.
Имеющаяся операционная система удовлетворяет предъявляемым
требованиям, поэтому оценка параметров адаптации такова:
ДИП = 15, ДИК=30, ДЗК=60.
Компонент ВВ потребует значительных доработок для учета
новых форматов показаний датчиков и индикации на терминале
оператора, однако основные характеристики этого компонента
достаточно хорошо соответствуют новым требованиям. Поэтому
параметры адаптации можно оценить следующим образом:
ДИП = 30, ДИК=60, ДЗК=80.
Полученные оценки и результаты вычислений ККА и ЭЧИК
сведены в табл. 9.2. Следуя шагам табл. 9.1, сначала для адапти-
Таблица 9.2
Характеристики адаптации компонентов СОС
Компонент дип ДИК ДЗК ККА АЧИК ЭЧИК
ОПСИС 15 30 60 33 5000 1650
ВВ 30 60 80 54 10000 540С
руемых компонентов в столбцах 2 и 3 ФОК записывают значения
ЭЧИК и ККА, после чего процедура использования ФОК продол-
жается так же, как и прежде. Результаты выполнения процедуры
показаны на рис. 9.2. Главными результатами адаптации существу-
ющих ОПСИС и ВВ по сравнению с новой разработкой этих ком-
понентов являются следующие:
Оценка затрат труда уменьшается с 77 до 47 ЧМ. В частности,
затраты на разработку ОПСИС уменьшатся с 23 до 7 ЧМ, а на
эазработку В В — с 30 до 16 ЧМ.
Оценка стоимости уменьшается с 420 до 254 тыс. долл.
Оценка сроков разработки уменьшается с 13 до 11 мес.
[48
Проект: разработка автоматизированной системы управления процессом Ч. . нефтеочистки Аналитик: фамилия ® К КЗ ® 2 X о X г-.:„или х-. чмгс, чм 'о' Дата: 4. 0L 81
i © Компонент ® ЭЧИК ® ККА Изделие ® ОВД ЭВМ ® ЦО О КА Исполнитель ® ОРВМ ® ОРЯП ® ПСП Проект ЭЧИК/ЧМ илиКПГИ ИЧ и СТ, тыс. долл./ЧМ и (й) тыс, долл. СТ/ЭЧИК, rfy. ДОЛЛ./ЭЧИК W
тнпо ® РБД ® сиз ® оп ® ИВМ ® 0РП ® КП ® иис ® OCP
1.0 в НИ в в но но ни В но но но но в но но 25 292 5.5
1. ПРОЦЕСС 7000 1,15 0,94 1,15 1,11 1.0 1,0 0,87 0,86 1,0 1,0 1,0 1,0 0,91 1.0 1,0 0,94 24 132
0,33 В НИ ОВ в но но НИ В ни в ни -ни В но но 7 236 6,0 25
2. ОПСИС 1650 1,15 0,94 1,30 1.11 1.0 1,0 0,87 0,86 1,13 0,86 1.10 1,07 0,91 1.0 1,0 1,21 42
0,54 НО НИ НО но но но НИ НО но но ни НО В но но 20 338 5.0 15
З.ВВ 5 400 1,0 0,94 1,0 1.0 1.0 1,0 0,87 1,0 1,0 . 1.0 1,10 1.0 0,91 1,0 1.0 0,82 80
4.
5.
6,-
7.
—
В.
9.
10.
11. 14,050 Общее ЭЧИК Всего 47 299 254 1В
12. 51 (ЧМ) , ЧМ 'ном' Тип разработки: распространенный Срок разработки, мес. 11
13. 275 (ЭЧИК/ЧМ)ном
Рис. 9.2. Оценка адаптации ПО для автоматизированной системы управления процессом нефтеочистки
9Ж ОЦЕНКА РАЗРАБОТКИ СИСТЕМЫ ОБРАБОТКИ СООБЩЕНИЙ
Описываемая здесь система обработки сообщений (СОС) будет
использована в качестве примера в ч. 3 книги. При этом будет не-
обходима оценка стоимости разработки операционной системы —
компонента СОС. Эта оценка будет получена здесь с помощью
промежуточной КОМОСТ. В следующем разделе изучение примера
будет продолжено для иллюстрации применения промежуточной
КОМОСТ при оценке расходов на весь жизненный цикл проекта,
включая этап сопровождения отдельных компонентов и распреде-
ление по фазам затрат труда на проект.
Описание СОС. Обычными характерными особенностями СОС
являются:
входные сообщения вводятся пользователем в произвольные
(непредсказуемые) моменты времени;
входные сообщения имеют стандартные форматы, обычно число
таких форматов невелико;
отдельные сообщения не требуют большой обработки;
требуется быстрая обработка каждого сообщения.
Типичными примерами сообщений являются сообщения о фи-
нансовых операциях и предварительных заказах авиабилетов,
сос бщения в системе цифровой связи с промежуточным запомина-
нием или сообщения о продаже тоьаров в большом универсальном
магазине. Используемые в книге методы анализа примера СОС
можно применять к любой системе обработки сообщений одного
из указанных типов.
Перед обсуждением СОС следует указать, что центральную
часть этой системы было решено реализовать (в основном, имея в
виду производительность, стоимость, возможность расширения и
необходимость резервирования дублированием) с использованием
большого числа микропроцессоров.
Базовая структура этой части СОС показана на рис. 9.3. В ее
состав входят процессор первичной обработки, несколько парал-
лельно работающих процессоров обработки сообщений и файловая
система. Предполагается, что потребуется 25 копий этой структу-
ры для обработки сообщений в 25 различных географических
пунктах.
Подсистемы ПО процессора первичной обработки. Сообщения
поступают в процессор первичной обработки (ППО) по несколь-
ким линиям связи. Принятые сообщения вводятся в ППО, просма-
триваются, классифицируются и запоминаются программной под-
системой Обслуживания связи. Подсистема управления работой
приписывает каждое сос зщение одному из параллельно работаю-
щих процессоров обработки сообщений (ПОС); специальный ком-
понент программы обслуживания связи ППО выбирает сообщение
из памяти и посылает его в соответствующий ПОС
Другими программными компонентами ППО являются: подси-
стема контроля состояния, обрабатывающая посылаемые для ПОС
сообщения о нормальной работе и выполняющая необходимые
действия при выходе из строя или восстановлений работоспособно-
сти одного из ПОС; подсистема обеспечения работы с клавиатурой
и экраном, высвечивающая на экране информацию о состоянии и
характеристиках работы всех ПОС и принимающая приказы опе-
ратора об изменении приоритетов сообщений, окончании или по-
вторном возобновлении обработки, выдаче дополнительной инфор-
мации о состоянии и характеристиках работы и т. п.
Подсистемы ПО процессора обработки сообщений. Каждый
ПОС оснащен копией одного и того же ПО. Часть этого ПО, от-
Сообщения
Процессор
первичной
обработки
Обслуживание связи
Контроль состояния Управление работой Обеспечение работы с клавиатурой и экраном
Обслуживание связи
Обслуживание связи
Процессоры
обработки
сообщений
Управление
ра6°ТОЙ OfipaficTK;
Запуск и
окончание
Обслуживание связи
Управление
ра'ботой
___________Обработка
Запуск и
окончание
I р\-
Обслуживание связи
Управление
работой I
___________Обработ ка
Запуск и
окончание
Работа с файлами
Работа с файлами
Работа с файлами
Z3
Файловый процессор
Рис. 9.3. Базовая структура системы обработки сообщений
носящаяся к операционной системе, состоит из подсистемы обслу-
живания связи (обработка поступающих от ППО сообщений и по-
сылка результатов), подсистемы работы с файлами (считывание и
обновление файлов состояния обработки сообщений), подсистемы
управления работой (контроль и распределение ресурсов) и под-
системы запуска и завершения для возобновления и прекращения
работы ПОС. Программное обеспечение каждого ПОС включает в
себя также обрабатывающую подсистему, которая выполняет фак-
тическую обработку сообщений (таких, как сообщения о финансо-
вых операциях, предварительных заказах авиабилетов, пополнени-
ях или сокращениях запасов) и подчинена подсистеме управления
работой.
Оценка разработки операционной системы СОС. Эту оценку
получают по ФОК, ориентированной на применение промежуточ-
151
Проект: разработка операционной системы, входящей в состав ПО СОС Исполнитель Аналитик фамилия © ККЗ £ 3“ 2 о 51 ЧМр или . ЧМГ<С, ЧМ ЭЧИК/ЧМ /кЬ или КПГИ VS/ Дата: 4.01.8
0 Компонент ® ЭЧИК ® ККА ® ТНПО Изделие ® ОБД ЭВМ ® ЦО © КА ® ОРВМ © ОРЯП © ПСП Проект ИЧ и СТ,тыслз\ долл./ЧМ и и-э) тыс, долл. СТ/ЭЧИК, долл./ЭЧИК W
® РБД ® сиз ® оп ® ИВМ © ОРП ® КП © И ИС © ОСР
1. Процессор предваритель- ной обработки Управление 1100 1.0 в НИ ов В но ни В ни в ни ни ни 4,1 6,0 180 5,2 28
1,15 0,94 1,30 1.11 0,87 0,86 1 13 0.86 1,10 1,07 1,10 1.47 31
работой Обслужива- ние связи 1300 1,0 4,9- 7,2 180 5,2
1.15 0,94 1,30 1.11 0,87 0,86 1,13 0,86 1,10 1,07 1,10 1,47 37
3. Контроль состояния 1,0 1,9 2.8 180 5.2 28
500 1,15 0,94 1,30 1,11 0,87 0,86 1,13 0,86 1,10 1,07 1,10 1.47 15
4.0беспечение работы с 1200 0,50 НО в но но 5,3 226 4.5 20
клавиатурой и экраном 0,94 1,15 0,87 0.86 1,13 1,10 1,07 ио 1,18 24
5. Процессор обработки сообщений 700 1.0 В ов в В в 2,6 4,1 5,2 30
1.15 0,94 1.30 1,11 1,06 0.87 0,86 1,13 0,86 1,10 1,07 1,10 1.56 171 21
работой 1,0 1.5 2,3 5,2 30
6. Обслужи- 400 1,15 0,94 1.30 1,11 1,06 0,87 0,86 1,13 0,86 1,10 1,07 1,10 1,56 171 12
вание связи 1,0 НО НО 3.8 7,3 137 4,5 зз
7. Работа с 1000 1,15 1,30 1.11 1,06 0,87 0,86 1,13 1,10 1,07 1,10 1.93 33
файлами 1.0 НИ в но В 1.1 1.4 5,2 23
8. Запуск и 300 1,15 0.94 1,15 1,06 0,87 0.86 1,13 0,86 1.10 1,07 1,10 1,24 7
окончание
9.
10.
11. 6500 Общее ЭЧИК Всего 364 179 180 28
12. 24,4 (ЧМ)„ом.ЧМ Тип разработки: полунезависимый Срок разработки, мес. 9
13. 266 (ЭЧИК/ЧМ)^
Рис. 9.4. Оценка характеристик разработки операционной системы СОС
ной КОМОСТ (см. рис. 9.4). Для получения оценки используют
процедуру из 17 шагов (см. табл. 9.1). Некоторые отличия состоят
в том, что в столбцах с 4-го по 18-й для простоты и удобства чте-
ния показаны лишь изменения (при движении вниз по столбцу)
рейтингов стоимостных атрибутов и не выписаны коэффициенты,
равные 1,00.
В результате оценивания получены следующие характеристики
разработки. Полный размер операционной системы равен
6500 ЭЧИК1, полные затраты на разработку составляют
180 тыс. долл., а одна команда обходится в 28 долл. Однако сто-
имость команды меняется от 20 долл, для относительно простой
подсистемы программного обеспечения ППО (работа с клавиату-
рой и экраном) до 33 долл, для функционирующей в параллельном
режиме подсистемы работы с файлами, входящей в состав про-
граммного обеспечения ПОС. Далее, на всю разработку требуется
36,4 ЧМ, а средняя производительность труда составляет
6500 ЭЧИК/36,4 ЧМ=179 ЭЧИК/ЧМ. И снова наблюдаются боль-
шие различия в производительности труда при разработке различ-
ных подсистем: от 137 ЭЧИК/ЧМ для подсистемы работы с файла-
ми до 226 ЭЧИК/ЧМ для подсистемы обеспечения работы с кла-
виатурой и экраном. И последнее, оценка сроков показывает, что
на разработку потребуется 9 мес.
9.5. ОЦЕНКА СОПРОВОЖДЕНИЯ СОС НА УРОВНЕ КОМПОНЕНТОВ
И РАСПРЕДЕЛЕНИЕ ПО ФАЗАМ ЗАТРАТ ТРУДА И СРОКОВ
Фазу сопровождения операционной системы, входящей в состав
СОС, характеризуют следующие особенности:
более близкие к номинальным, чем к низким, значения рейтин-
гов стоимостных атрибутов, связанных с опытом работы в данной
прикладной области, с виртуальной машиной, с языком програм-
мирования;
более близкое к низкому, чем к номинальному, значение рей-
тинга изменяемости виртуальной машины;
коэффициент пересчета годовых изменений равен 15% для под-
системы обеспечения работы с клавиатурой и экраном и 10% для
остальных подсистем.
Для оценок сопровождения можно использовать ту же ФОК,
которая применялась и при оценке разработки. В табл. 9.3 приве-
1 Фактический размер равен 7700 ЧИК. Однако необходимо принять во вни-
мание, что подсистема обеспечения работы с клавиатурой и экраном, состоящая
.из 2400 ЧИК, будет адаптирована из существующего ПО, для чего потребуется
изменить проект на 35 %, код — на 60 %, а затраты на комплексирование соста-
вят 60 % обычных затрат. Учитывая сказанное, можно получить следующие оцен-
ки для ККА и ЭЧИК:
ККА=0,40 0,35+0,30• 0,60+0,30 -0,60= 0,50;
ЭЧИК= 2400 0,50= 1200.
153
Таблица 9.3
Процедура использования ФОК для оценки затрат на сопровождение
1. Для каждого компонента записать ККЗ, вычисленный для разработки
ПО, в нижнюю часть столбца 19.
2. Для каждого компонента определить все изменения связанных с затра-
тами труда коэффициентов стоимостного атрибута. Коэффициент для разработки
записывается в нижнюю часть строки столбца стоимостного фактора, а соответ-
ствующий коэффициент для сопровождения (отличный от коэффициента для
разработки) — в верхнюю часть строки столбца того же стоимостного атрибута
(и так для всех стоимостных атрибутов в столбцы с 4-го по 18-й). Коэффици-
енты могут изменяться по следующим причинам:
неноминальные для разработки коэффициенты ОСР изменяются на номи-
нальные (1,00) для сопровождения;
неноминальные для разработки коэффициенты ТНПО и ПСП могут изме-
нить свои значения (ТНПО в соответствии с табл. 8.7, ПСП — с табл. 8.8);
рейтинги стоимостного атрибута могут измениться (например, рейтинги опы-
та работы).
3. Для каждого компонента вычислить его ККЗ сопровождения по формуле
ККЗс = ККЗр • [(произведение коэффициентов сопровождения, не равных
коэффициентам разработки)/(произведение коэффициентов разработки, не рав-
ных коэффициентам сопровождения)]
и записать результат в верхнюю часть столбца 19*.
4. Для каждого компонента записать в столбец 22 КПГИ в виде доли от
общего объема ПО (например, в виде 0,10 вместо 10%).
5. Если ККА для всех компонентов равен 1,0, то записать номинальные
затраты труда на разработку каждого компонента ЧМВОЫ в столбец 20. В Про-
тивном случае необходимо вычислить заново ЧМном> учитывая размер сопро-
вождаемого изделия. С этой целью для любого компонента, ККА которого
равен 1,0, вычислить его фактический размер и записать результат в столбец 2.
После этого выполнить следующие действия:
вычислить исправленное ЧИК для всего изделия и записать .результат в
строку 11 столбца 2;
вычислить исправленное значение ЧМпом для всего изделия, используя скор-
ректированное значение ЧИК и соответствующее данному типу разработки урав-
нение для номинальных затрат труда (см. нижнюю часть табл. 9.1), и записать
результат в строку 12 столбца 2;
вычислить исправленную производительность труда для данного проекта по
формуле (ЧИК/ЧМ)ном=Общее ЧИК/ЧМ„пм
и записать результат в строку 13 столбца 2;
для каждого компонента вычислить исправленное значение затрат труда
по формуле ЧМном=ЧИК/(ЧИК/ЧМ)иом
и записать результат в столбец 20.
6. Для каждого компонента вычислить годовые затраты труда на сопро-
вождение по формуле ЧМг.с = ККЗ ЧМНОмКПГИ
и записать результат в столбец 21.
7. Сложить затраты труда на сопровождение всех компонентов и записать
результат в строку 11 столбца 21.
8. Для каждого компонента оценить средние издержки на оплату исполни-
телей за один ЧМ (т. е. ИЧ) и записать .результат в верхнюю часть каждой
строки столбца 23.
9. Вычислить стоимость каждого компонента по формуле СТ=ЧМг.с-ИЧ
и записать результат в нижнюю часть каждой строки столбца 23.
40. Для получения стоимости годового сопровождения изделия сложить
стоимости годового сопровождения каждого компонента и записать результат
в строку 11 столбца 23.
• В шагах 2 и 3 сформулирован сокращений метод вычисления (ККЗ)с, когда при
переходе от разработки к сопровождению изменяется относительно малое число коэффи-
циентов затрат труда. Если изменяется много коэффициентов, то может оказаться, что
легче вычислить ККЗс непосредственно как произведение всех относящихся к сопровожде-
нию коэффициентов затрат труда
154
Проект» сопровождение операционной системы СОС
Аналитик: фамилия
Дата: S. 01.61
© Компонент ® ЭЧИК ® ККА ® тнпо бздели © РБД е ® сиз ® ОБД ЭЕ ® ОП м © ИВМ ® ЦО КА Испог ® ОРП кители ® КП ® орвм ® О’РЯП ® псп 1роек1 иис ® ОСР ® ккз 4M«oM.4M (§) ЧМрИЛИ ЧМГС,ЧМ ЭЧИК/ЧМ <з>. илиКПГИ м3/ о и 0 тыс, долл. _ СТ/ЭЧИК, дрлл/ЭЧИК^У
1. Процессор предваритель- ной обработки Управление 1100 0,9В 0,87 1.0 1,0 , 1.0 0,82 4,2 0,34 0,10 6,6
1.15 1.0 1,13 1,10 1.07 1,47 1.9
работой 2. Обслужи- вание связи 1300 0.98 0,87 1,0 1,0 1.0 0,82 8,0 0,41 0,10 5,6
1.15 1.0 1,13 1,10 1.07 1.47 2,3
3. Контроль состояния 500 0.98 0,87 1.0 1,0 1.0 0,82 1,9 0,16 0,10 5.5
1,15 1.0 1.13 1,10 1,07 1.47 0,9
4.Обеспечение работы с кла- виатурой и экраном 2400 0,50 0,87 1.0 1,0 1,0 0,77 9,2 1,06. 0,16 5,5
1.0 1.13 1,10 1,07 1.18 5,В
5. Процессор обработки сообщений 700 0,98 0.87 1.0 1,0 1.0 0,87 2,7 0,23 0,10 5,5
1,15 1.0 1,13 1,10 1,07 1,56 1,3
работой б.Обслужива- 400 0.98 0.87 1.0 1,0 1.0 0,87 1,5 0,13 0,10 6,5
1.15 1.0 1,13 1,10 1,07 1,56 0,7
ние связи 7. Работа с файлами 1000 0.98 0.87 1,0 1.0 1,0 1,08 3.8 0,41 0,10 5.5
1,15 1,0 1,13 1.10 1,07 1,93 2,3
8. Запуск и окончание 300 0,98 0,87 1.0 1,0 1,0 0,69 1.1 0,08 0,10 5,5
1,15 1.0 1,13 1.10 1.07 1,24 0.4
9.
10.
11. 7700 Общее ЭЧИК Тип разработки: полунезависимый Всего 2,82 15,6
12. 29.5 (ЧМ)„,„,ЧМ Срок разра- ботки, мес.
1'1 261 (ЭЧИК/ЧМ) иом
5; Рис. 9.5. Оценка характеристик сопровождения операционной системы
ся
дены шаги процедуры использования ФОК для оценки затрат на
уровне компонентов при сопровождении. На рис. 9.5 показаны ре-
зультаты применения этой процедуры при оценке сопровождения
СОС. Шаги процедуры поясняются ниже.
Шаг 1. Из столбца ФОК разработки СОС берут значения ККЗ
для каждого компонента и записывают их в нижнюю часть соответ-
ствующей строки столбца 19 ФОК сопровождения.
Шаг 2. При переходе от разработки к сопровождению коэффи-
циент, соответствующий высокому рейтингу надежности всех ком-
понентов, кроме компонента обеспечения работы с клавиатурой и
экраном, уменьшается с 1,15 до 0,98 (согласно данным табл. 8.7).
Указанные выше изменения рейтингов атрибутов ОРП, ОРВМ,
ОРЯП и ИВМ учтены соответствующими коэффициентами.
Шаг 3. Вычисляют и записывают в верхнюю часть строк столб-
ца 19 измененный для сопровождения ККЗС. Для всех компонен-
тов, кроме компонента обеспечения работы с клавиатурой и экра-
ном, используется один и тот же корректирующий коэффициент:
ККЗс^ККЗр o^w.oo-i.oo.i,^ .^055 ккз
‘ 1,15-1,00-1,13-1,10-1,07 ‘
Шаг 4. В столбец 22 записывают значение КПГИ, равное 0,15
для компонента обеспечения работы с клавиатурой и экраном и
0,10 для остальных компонентов.
Шаг 5. Так как ККА для компонента обеспечения работы с кла-
виатурой и экраном не равен 1,0, то вычисляют фактическое зна-
чение ЧИК для этого компонента (2400 ЧИК). Затем вычисляют
следующие величины: скорректированное общее значение ЧИК
(7700 ЧИК), скорректированные затраты труда ЧМном (29 ЧМ),
скорректированную производительность труда ЧИК/ЧМном
(261 ЧИК/ЧМ) и скорректированные затраты труда ЧМном ДЛЯ
каждого компонента. В частности, скорректированные затраты тру-
да ЧМном для компонента обеспечения работы с клавиатурой и
экраном равны 9,2 ЧМ.
Шаги 6 и 7. Для каждого компонента вычисляют и записывают
в столбец 23 годовые затраты труда на сопровождение. Например,
для подсистемы работы с файлами получаем:
ЧМГ.С = 1,08-3,8-0,10=0,41 ЧМ.
Общие же затраты труда на годовое сопровождение СОС со-
ставляют 2,82 ЧМ, т. е. для сопровождения необходимо 0,23 ЧИ.
Шаги 8, 9 и 10. Поскольку на сопровождение операционной си-
стемы, входящей в состав программного обеспечения СОС, по
оценкам требуется менее одного сотрудника, работающего на чет-
верть ставки (0,23 ЧИ), можно привлечь к сопровождению всех
компонентов одного и того же специалиста, издержки на оплату
работы которого составят 5500 долл, за один ЧМ. Поэтому оценка
общих годовых затрат на сопровождение составит 15,6 тыс. долл,
(строка 11 столба 23).
156
Распределение по фазам затрат труда и сроков. Для определе-
ния этого распределения можно использовать данные табл. 6.8.
Поскольку размер рассматриваемого изделия (6500 ЧИК) делит
отрезок между малым и промежуточным размерами в отношении
3: 1, то для получения искомых распределений необходимо произ-
вести в таком же отношении интерполяцию для затрат труда и
сроков, соответствующих этим размерам. Результирующие распре-
деления затрат труда (36,4 ЧМ) и сроков (9 мес.) приведены в
табл. 9.4.
Таблица 9.4
Распределение по фазам жизненного цикла СОС затрат труда и сроков
Затраты труда Срок ЧИ
Фаза % ЧМ % мес.
Проектирование изделия 17,00 6,2 24,75 2,2 2,8
Программирование Комплексирование и испыта- 61,75 22,5 53,00 4,8 4,7 3,8
НИЯ 21,25 7,7 22,25 2,0
Разработка 100 36,4 100 9,0
Сопровождение 2,8 0,2
Максимальный штат проекта, по-видимому, составит 5—6 ЧИ.
Даже в этом случае организационная структура потребует одного
руководителя и небольшой группы исполнителей. Поэтому отсут-
ствует необходимость в определении изменений по фазам органи-
зационной структуры данного проекта.
ЧАСТЬ 3
ОСНОВЫ ИНЖЕНЕРНОЙ ЭКОНОМИКИ ПО
Введение. На протяжении ч. 2 при иллюстрации использования
модели КОМОСТ, предназначенной для оценивания затрат на ПО,
рассматривалось несколько конкретных примеров и вопросов с при-
влечением некоторых приемов технико-экономического анализа.
В частности, использовались следующие методы:
анализ целесообразности собственного производства, закупки
или адаптации;
стоимостный анализ характеристик систем (таких, как время
ответа) и сравнение их с затратами на программную разработку;
анализ чувствительности соотношений для стоимости ПО к ха-1
рактеристикам разработки или параметрам управляющих решений.
Приемы анализа, использованные в ч. 2, относятся к первому
уровню в иерархии расположенных в порядке возрастания мощно-
сти методов технико-экономического анализа, разработанных за
последние несколько десятилетий. Эти методы широко применяют-
ся во всех связанных с обработкой информации случаях для ана-
лиза как главных, так и второстепенных решении, влияющих на
разработку, приобретение и сопровождение ПО. Поэтому для прак-
тических целей весьма важным является умение инженера-про-
граммиста использовать эти методы анализа.
Столь же полезны для инженера-программиста и общие эконо-|
мические концепции и принципы, лежащие в основе рассматривав-'
мых в ч. 3 книги конкретных методов и относящиеся к эффективно-
сти затрат, текущей стоимости, условной оптимизации, определе-
нию целей и альтернатив, степени риска, ценности информации.
Эти концепции и принципы обеспечивают единый аппарат для рас-
смотрения чрезвычайно сложных ситуаций, возникающих в прак-
тике инженерного программирования, в частности, для установле-
ния подлежащих решению проблем, возможностей их решения и
согласования приоритетов различных работ.
Более того, экономические методы помогут принимать правиль-1
ные решения и в других случаях, например при покупке автомоби-
ля, дома или стереоаппаратуры, при определении размера суммы
страхования или даже при выборе учебного заведения для обуче-
ния в аспирантуре.
Экономика инженерного программирования. В этой части кни-
ги читатель знакомится с основными концепциями инженерной
экономики, которые, по всей видимости, необходимо знать инже-
158
неру-программисту. Эти концепции относятся к разделу экономики,
называемому микроэкономикой. Другой главный раздел экономи-
ки, называемый макроэкономикой, включает вопросы государст-
венного масштаба; проблемы инфляции, платежного баланса, без-
работицы и т. п. Микроэкономика занимается вопросами более
частного характера; о собственном производстве, закупке или арен-
де, о достаточности проведенных моделирования или испытаний.
Из всей микроэкономики будут рассмотрены только главные
для инженерного программирования темы. К таковым относятся
анализ эффективности затрат, предельный анализ, анализ по чи-
стой и текущей стоимости, анализ степени риска, а также условная
оптимизации и теория статистических решений
Помимо этого, в ч. 3 будет рассмотрено несколько важных во-
просов инженерного программирования, выходящих за традицион-
ные рамки микроэкономики. Так, в соответствии с главным прин-
ципом ЦОП, заключающемся в непрерывном согласовании в тече-
ние ЖЦПО целей человеческих отношений, программотехники и
управления ресурсами, будет обсуждено несколько методов согла-
сования многих целей, в частности, количественных и существен-
но качественных целей.
Кроме того, в ч. 3 придается особое значение технико-экономи-
ческому анализу как средству, обеспечивающему принятие реше-
ний в инженерном программировании, и тесно связанным с техни-
ко-экономическим анализом концепциям значимости информации
для принятия решений. Следует учитывать, что обычно инженеры-
программисты являются поризводителями информации, которой
руководствуются другие люди, однако в течение ЖЦПО они сами
должны быть потребителями информации, необходимой для при-
нятия ими решений. По мере же того как инженеры программисты
начинают лучше понимать значение факторов, обеспечивающих по-
лезность информации для принятия более целесообразных решений
в их профессиональной деятельности, они получают более правиль-
ное представление о том, что необходимо их заказчикам и пользо-
вателям от систем обработки данных. Часть 3 состоит из трех ос-
новных подчастей.
Каждая глава ч. 3 (и каждый раздел гл. 10) содержит следую-
щие компоненты.
1. Пример для демонстрации применения конкретного метода и
обоснования его полезности. В примере затрагиваются как аппа-
ратные, так и программные аспекты микропроцессорной системы
обработки сообщений, введенной в гл. 9.
2. Общее обсуждение метода, представленного в примере: его
общую формулировку, возможности и ограничения, а также при-
менение в инженерном программировании.
В ч. 3 не будут рассматриваться анализ предложения и спроса и ценообра-
зование. Однако эти темы представляют определенный интерес в таких относя-
щихся к обработке информации областях, как сбыт готовых изделий и управле-
ние вычислительными центрами. Указанные темы обсуждаются в [269].
159
ЧАСТЬ ЗА
АНАЛИЗ СТОИМОСТЬ —ЭФФЕКТИВНОСТЬ ЗАТРАТ
В инженерном программировании наиболее важной является
оценка относительных затрат и эффективности различных альтер-
нативных решений. Для обеспечения сравнения решений инженер-
ного программирования в ч. ЗА введены основные понятия, отно-
сящиеся к анализу эффективности затрат. Эти понятия лежат в
основе более развитых методов экономического анализа, изложен-
ных в частях ЗБ и ЗВ.
Материал гл. 10 обеспечивает переход от более знакомого из
вычислительного депа анализа производительности вычислитель-
ной системы к анализу эффективности затрат.
В ней обсуждены основные цели и схемы анализа эффективно-
сти затрат и рассмотрен пример системы обработки сообщений
(СОС), используемый для иллюстрации экономических понятий и
методов.
В гл. 11 введено несколько весьма полезных основных понятий
микроэкономики — производственные функции, положительные и
отрицательные эффекты масштаба — в терминах определенной в
гл. 10 системы анализа эффективности затрат.
В гл. 12 обсуждены различные критерии экономической эффек-
тивности — максимум производительности при фиксированном
бюджете, максимум затрат при ограничении производительности,
максимум отношения эффективности к затратам и т. п. — и указа-
ны их достоинства и трудности использования в практике инженер-
ного программирования.
ГЛАВА 10
МОДЕЛИ ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ И
ЭФФЕКТИВНОСТИ ЗАТРАТ
10.1. МОДЕЛИ ПРОИЗВОДИТЕЛЬНОСТИ
Пример. В качестве примера здесь (и до конца ч. 3) будет ис-|
пользована система обработки сообщений, описание и анализ за-
трат на разработку которой приведены в гл. 9 К типичным при-
мерам сообщений, обрабатываемых СОС, относятся сообщения о
фикзнсовых операциях и предварительных заказах авиабилетог,
сообщения в системе цифровой связи с промежуточным запомина-]
нием или сообщения о продаже товаров в большом магазине.
Перед более подробным обсуждением примера СОС следует!
напомнить, чтс ее центральную часть было решено реализовать —
в основном, имея в виду требуемые производительность, стоимость,
возможность расширения и необходимость резервирования дубли-
рованием — с использованием большого числа микропроцессоров.
На рис. 9.3 была показана базовая структура СОС, которая и бу-
160
дет в дальнейшем исследоваться, 25 копий такой структуры потре-
буется для работы в 25 различных географических пунктах.
В качестве процессора обработки сообщений был выбран кон-
кретный микропроцессор, лучше всего подходящий для выполнения
функций СОС. Этот микропроцессор обладает быстродействием
1 млн. операций в секунду (1000 тыс. оп/с) и может обрабатывать
сообщения, затрачивая 20 000 операций на сообщение (20 тыс. оп./
сообщ.).
Таким образом, если бы операционная система СОС не требо-
вала для своей работы вычислительных ресурсов, то каждый про-
цессор СОС мог бы обрабатывать 50 сообщ./с. Однако операцион-
ная система должна выполнять несколько административных
функций, например планирование, управление ресурсами, диспет-
черизацию, обнаружение и обработку ошибок и контроль работы.
Каждый процессор расходует на такие функции приблизительно
200 тыс. оп./с, что уменьшает производительность СОС до
40 сообщ./с на один процессор.
Сверх указанных внутрипроцессорных накладных расходов
имеются также межпроцессорные расходы на выполнение допол-
нительных административных функций в многопроцессорной си-
стеме, например планирование, управление ресурсами и т. п., а
также на проведение многочисленных обновлений таблиц состоя-
ний в каждом процессоре, которые изменяются во время обработ-
ки сообщений. Для СОС с W процессорами дополнительные на-
кладные расходы составляют 80 (N — 1) тыс. оп./с. Следовательно,
при введении в систему нового процессора каждый из уже имею-
щихся процессоров должен будет терять дополнительные
80 тыс. оп./с на разрешение конфликтов с новым процессором.
Для определения оптимального числа закупаемых процессоров
необходимо знать, как зависит производительность, или пропуск-
ная способность этой системы, от числа процессоров 7V. Используя
параметры:
5 — быстродействие процессора, тыс. оп./с;
Р — внутрипроцессорные накладные расходы, тыс. оп./с;
М — коэффициент межпроцессорных накладных расходов,
тыс. оп./с;
Т — число операций на обработку одного сообщения, тыс. оп./
сообщ.
для производительности СОС П (N) можно получить следующие
формулы:
77(7V) Общее число К оп./с для обработки сообщений
Число К оп. на обработку одного сообщения
(101)
Поскольку для данной СОС 5=1000, Р=200, 7И=8О и Г=20,
то приведенная формула примет вид
П (7V)=7V[1OOO—200—80 (TV — 1)]/20= (880—802V)/20=
=47V(11 — N).
6 Зак 628 161
График П (N) для рассматриваемой ситуации показан на
рис. 10.1, из которого видно, что наилучшую производительность
120 сообщ./с можно получить от СОС, включающей пять или шесть
процессоров. При дальнейшем росте числа процессоров производи-
тельность падает, так как замедление работы других процессоров
каждым дополнительным процессором превосходит вклад нового
процессора в увеличении производительности '.
Рис. 10.1. Зависимость производительности СОС П (N) от числа процессора
Общее обсуждение. Уравнение (10.1) задает некоторую модель
производительности в зависимости от набора переменных, называ-
емых системными параметрами. В уравнении не только N, но так-
же S, Р, М и Т являются системными параметрами. Таким образом,
строго говоря, П (/V) следует обозначить как П (N, S, Р, М, Т).
Главная цель применения моделей производительности в инже-
нерном программировании состоит в том, что с их помощью мож-
но получить следующую информацию, необходимую для принятия
решения о разработке или приобретении ПО.
1. Информация об оптимальной производительности. В резуль-
тате анализа моделей производительности можно определить, при
каких значениях системных параметров достигается максимальная
производительность.
2. Данные анализа чувствительности. В результате анализа мо-(
делей производительности можно определить чувствительность
производительности системы к характеристикам модели.
Использование этих типов информации обсуждается поочеред-
но в следующих двух разделах.
1 Следует отметить, что показанный на рис. 10 1 характер зависимости произ-
водительности многопроцессорной системы от числа процессоров часто наблюд»
ется на практике. В одной большой правительственной многопроцессорной системе
максимальная производительность была достигнута при четырех процессора^
а при использовании девяти процессоров она фактически падала до нуля. Друпв
примеры аналогичного поведения производительности многопроцессорной система
приводятся в (248, 287].
10.2- ОПТИМАЛЬНАЯ ПРОИЗВОДИТЕЛЬНОСТЬ
Пример вычислений. Модель производительности (10.1) можно использовать
для определения числа процессоров Nmax, при котором будет достигнута наивыс-
шая производительность СОС. Это можно сделать, используя тот факт, что
в точке максимума (см. рис. 10.1) тангенс угла наклона касательной к кривой
/7 (N) равен нулю н что он задается производной функции П (JV) по N при фик-
сированных значениях остальных параметров. Переписывая (10.1) в форме
П (N) = (S—Р+М) NJT— (М/Г) №, (10.2)
можно легко вычислить требуемую производную *:
dn(N)/dN= (S—P+M)/T—(2M/T)N. (10.3)
Если определить А'шах как точку, в которой тангенс угла наклона касательной
равен нулю
dH/dN (A/max)=0, (10.4)
то, подставив выражение для dPI/dN из (10.3) в (10.4)
(S -Р+А4) /Т - (2М /Т) Атак = 0
и разрешив полученное уравнение относительно ААтах, получим
/А—Р+М\[Т \ S—Р-1-7И
max у I (гм") (Ю.5)
Для рассматриваемого примера СОС, когда 5=1000, Р=200 и М = 80, опти-
мальное число процессоров
Mna X = (1000—200+80) /160 = 5,5.
Поскольку на практике можно работать только с целым числом процессоров,
то придется довольствоваться системой из 5 или 6 процессоров с /7((У) =
- 120 сообщ./с.
Одним очень полезным следствием знания точного значения Атах является
возможность оценить ухудшение производительности из-за того, что нельзя на
практике реализовать абсолютно оптимальное решение. В рассмотренном случае
П (5,5) =5,5(1000—200—80(4,5)]/20= 121 сообщ.,/с,
т. е. убеждаемся, что ухудшение производительности относительно невелико.
Общее обсуждение. Обращение производной в нуль является
необходимым, но не достаточным условием нахождения абсолютно
максимального или минимального значения функции, или опти-
мального значения. Ниже рассматриваются несколько ситуаций, в
которых производная обращается в нуль и не в точках абсолютно-
го минимума и максимума, или оптимума.
1 Несколько максимумов или (и) минимумов. В точке х0 на
Рис. Ю.2 производная обращается в нуль и функция имеет в этой
точке локальный максимум, но х0 не является оптимальной точкой,
точкой глобального максимума. С подобной ситуацией можно
сталкиваться довольно часто. Таким образом, нахождение опти-
1 В этой книге используется лАшь одна простая формула из математического
анализа: формула для производной полинома. А именно, если
То И (х) =ап хп-гдп—! х” 1. Ч-Ol х-|-ао,
‘^-^-==папХп-1+(п-1) a (n_h xn-2+...+Cl.
** 163
П(х>
Рис. 10.2
мальной точки связано с иссле
дованием всех точек, в которые
производная обращается в нуль
2. Точки перегиба и седловые
£ точки. На графике в левой часп
рис. 10.3 точка х=0 является точ-
кой перегиба функции П(х)=х3
Производная этой функций
dn/d.x=3x2 обращается в нуль при х=0, однако функция в этой
точке не имеет ни максимума, ни минимума.
В правой части рис. 10.3 показана седловая точка. В седловой
точке производная функции равна нулю, однако в зависимости от
ограничений, накладываемых на аргументы, в этой точке может
достигаться как максимум, так и минимум 1 функции.
Рис. 10.3
Наиболее часто точки перегиба или седловые точки встречают-
ся при анализе очень сложных функций. Лучший способ исследо-
вания таких точек состоит в рассмотрении второй производной:
если она равна нулю (а третья производная не равна нулю), то
найдена точка перегиба; если она положительна в одном направ-
лении и отрицательна в другом, то найдена седловая точка; если
она отрицательна во всех направлениях, то найдена точка макси-
мума; если она положительна во всех направлениях, го — точка
минимума.
Все рассуждения верны при существовании производных функ-
ции. В инженерном программировании это предположение часто
не выполняется. Так, например, в тарифах на передачу данных
или использование ЭВМ нередко имеются разрывы в расценках,
производительность цифровых систем обычно выражается дискрет-
ными значениями. Поэтому необходимо также убедиться, что поиск
максимума не ограничен областью существования производной,
поскольку может существовать максимум, показанный на рис. 10.4.
Оптимальные решения в инженерном программировании наибо-
лее часто используются на фазах детального проектирования и
кодирования. На более ранних фазах ЖЦПО можно найти пред-
1 В зависимости от ограничений на системные параметры эта точка може'
быть также и точкой перегиба. — Прим, пере в.
164
почтительное решение, не являющееся
оптимальным по производительности.
Как будет видно из последующего
изложения, существует целый ряд со-
ображений— степень риска, производ-
ственные ограничения, психология и
профессиональный рост пользователей,
сопровождаемость, которые могут за-
ставить выбрать решение, не обеспе-
чивающее оптимальной производительности. Однако даже в таких
ситуациях, как правило, важно определить оптимальную точку и
оптимальное значение, так как это позволяет оценить объем уси-
лий, которые стоит затратить на улучшение неоптимального ре-
шения.
10.3. АНАЛИЗ ЧУВСТВИТЕЛЬНОСТИ
Обсуждение примера. Любое решение в инженерном програм-
мировании или в какой-нибудь другой области основывается на
некоторых предположениях. В случае СОС решение о закупке пя-
ти процессоров для обеспечения производительности 120 сообщ./с
основывалось бы на предположении, что фактические характери-
стики работы аппаратуры и программ будут достаточно близки к
значениям системных параметров, использованных в моделях.
В частности, учитывалось бы предположение о значении коэффи-
циента межпроцессорных накладных расходов М.
Допустим, однако, что указанное предположение на практике
не подтверждается. Какое влияние окажет это на производитель-
ность СОС?
Рассмотрим ситуацию, в которой М — 160, а все остальные си-
стемные параметры остались прежними. В этом случае из (10.1)
получаем
n(N) = ЛД1000—200 16O(7V — 1)]/20 = Д (960 1607V)/20 =
= 8ЛД6- N).
Результаты сравнения с первоначальным примером показаны
на рис. 10.5.
Таким образом, если бы было закуплено пять процессоров и
после включения их в работу обнаружено, что коэффициент меж-
процессорных накладных расходов равен 160, а не 80, то была бы
получена пятипроцессорная СОС с производительностью
40 сообщ./с. Этот результат был бы не лучше, чем для однопроцес-
сорной СОС и существенно отличался бы от ожидаемой произво-
дительности 120 сообщ./с.
Можно получить более полную картину чувствительности функ-
ции П(N, S, М, Т) к М, положив 7V=5, оставив 5=1000, Р=
=200 и Т=20 и изучив поведение следующей функции:
П (М) = 5 [ 1000—200—М (5—1) ] /20=5 (800—4М) /20=200—М.
165
Рис. 10.5. Производительность СОС для двух значений коэффициента межпро-
цессорных накладных расходов
На рис. 10.6 приведен график чувствительности. Из него видно,
что в рассматриваемом случае пятипроцессорной СОС любое уве-
личение коэффициента межпроцессорных накладных расходов на
х единиц приведет к уменьшению производительности СОС на
х сообщ./с.
Рис. 10.6. Чувствитель-
ность производительно-
сти пятипроцессорной
СОС
Общее обсуждение. В общем случае, если имеется функция
П{а, Ь,_____ z) от нескольких параметров, ее чувствительность код-
ному из них, например z, в данной точке (а0, Ьо, ..., z0) можно оп-
ределить вычислением производной 1 функции П по z в точке («о,
i>o, . , Zq) :
d/7 . , .
~ (aoi Ьц,... z0).
dz
В случае СОС из (10.1) можно получить
n(N, S, Р, М, Т) = 7V[S — Р — M(N— 1)]/Т = 7V(S —
— Р)/Т— MN(N — 1)/Т.
1 Частная производная функции нескольких переменных П (а, Ь, .... z) по
одной из этих переменных, например z, вычисляется как обыкновенная производ-
ная соответствующего выражения, в котором все переменные, кроме z, считаются
константами. Следовательно, если бы функция производительности трактовалась
как Л (N, S, Р, М, Г), а не П (IV), то вместо производной dnjdN следовало бы
использовать частную производную дП]дЛ.
166
Поэтому частная производная функция П по М
— (5, 100, 200, М, 20) = I = = — 1.
ЛИ Г |£=®0 20
Полученное значение представляет собой тангенс угла наклона
показанной на рис. 10.6 характеристики чувствительности.
Во многих случаях инженерного программирования вычисление
частных производных будет трудным, так как функция П может
оказаться весьма сложной. Или может случиться, что эта функция
не имеет производных, либо производные не являются непрерыв-
ными. В таких случаях лучший способ анализа чувствительности
заключается в рассмотрении значений системных параметров вбли-
зи тех точек, которые желательно исследовать, вычислении соот-
ветствующих значений П и сравнении полученных значений со зна-
чениями в исследуемых точках.
Анализ чувствительности чрезвычайно важен для двух главных
работ инженерного программирования: анализа осуществимости
на исследовательских фазах, отвлеченных от конкретных практи-
ческих вопросов, и анализа степени риска на фазах планирования,
анализа требований и проектирования изделия. Особенно важно
исследовать чувствительность производительности к накладным
расходам в операционных системах в реальных условиях, харак-
теристикам работы алгоритмов распределения ресурсов, а также
характеристикам таких систем искусственного интеллекта, как про-
цессоры естественных языков, систем распознавания образов или
эвристического поиска.
10.4. МОДЕЛИ ЭФФЕКТИВНОСТИ ЗАТРАТ
В предыдущих разделах была предложена модель решения про-
блемы оптимальной производительности:
Для данных 'значений системных параметров S, Р, М и Т опре-
делить число процессоров N, необходимое для получения макси-
мальной производительности П (N, S, Р, М, Т).
Если число процессоров было бы неограниченным и единствен-
ной целью было бы максимальное увеличение производительности,
то приведенная формулировка была бы идеальной. Однако в боль-
шинстве случаев процессоры приобретают в условиях ограничен-
ных денежных ресурсов, причем эти средства требуются для удо-
влетворения и других целей. Поэтому предпочтительнее иметь мо-
дель, устанавливающую связь таких показателей, как производи-
тельность, с затратами в долларах или в единицах каких-либо дру-
гий ограниченных ресурсов. Такая модель называется моделью
эффективности затрат.
-ример. Обычно довольно просто преобразовать модель произ-
водительности в модель эффективности затрат. Для рассмотренной
Формулы производительности это можно сделать заменой N на
167
функцию затрат N (С)—число процессоров, которое можно при-
обрести, затратив С долларов:
П (С) =N (C)[S — Р — M(N (С) — 1)]/7\ (10.6)
Поскольку будет изготовлено 25 копий СОС и каждый процес-
сор обработки сообщений стоит 400 долл., получим, что добавление
одного процессора в базовую структуру СОС обойдется в
10 тыс. долл. (25-400 долл. = 10 000 долл.). Поэтому при измере-
нии С в тысячах долларов получим N(С) = С/10 и
77(C) = C/10[S — Р — 7И(С/10 — 1)]/Т. (10.7)
Таким образом, кривую эффективности затрат, соответствую-
щую рис. 10.1, можно получить простым изменением масштаба по
оси абсцисс, как показано на рис. 10.7.
С помощью понятия эффективности затрат можно легче оце-
нить, действительно ли вариант (N = 5 или М = 6), максимизи-
рующий производительность системы, является лаилучшим спосо-
бом распределения ограниченных ресурсов. Безусловно, вариант
N = 5 лучше, чем N = 6, но лучше ли он чем N = 4? Ведь может
оказаться необоснованным расход 10 тыс. долл, для перехода от
четырехпроцессорной системы к пятипроцессорной при увеличе-
нии производительности только на 8 сообщ./с.
Результаты улучшения функции затрат. Иногда выбор подхо-
дящего варианта упрощается с улучшением функции затрат N (С).
Например, пусть имеется возможность договориться с поставщи-
ками аппаратуры относительно следующего (весьма упрощенного)
прейскуранта со «скидной с количества» (предусматривающего
снижение цены при покупке крупной партии процессоров):
цена каждого из первых 75 процессоров равна 400 долл.;
цена каждого процессора сверх 75 равна 240 долл.
Для этого случая кривая эффективности затрат на СОС пред-
ставлена на рис. 10.8, из которого видно, что при наличии скидки
с количества приобретение пятипроцессорной системы вместо че-
тырехпроцессорной становится более привлекательным.
Общее обсуждение.
Модель эффективности затрат состоит из последовательности
формул, которые определяют оценку эффективности в зависимо-
сти от затрат денежных средств или каких-нибудь других ограни-
ченных ресурсов
Модели эффективности затрат обычно состоят из двух частей:
1) модели затрат С = С (F), определяющей затраты на приоб-
ретение некоторых средств F;
2) модели производительности П = П (F), определяющей про-
изводительность при использовании средств F.
Такое расчленение производится, главным образом, для удоб-
ства. Обычно удобнее рассматривать затраты и производительность
в зависимости от некоторых промежуточных данных (таких, как
168
число процессоров для СОС), чем исключать подобную взаимо-
связь. Кроме того, если рассматривать модель как программное
изделие, то указанный способ ее разбиения вполне соответствует
принципу моделирования, поскольку функции связи затрат и про-
изводительности со средствами (некоторыми ресурсами) по всей
видимости будут изменяться независимо друг от друга.
Ниже приводятся несколько примеров таких средств и их ти-
пичные прейскуранты.
Рис. 10.7. Кривая эффективности затрат на СОС при издержках 10 тыс. долл,
на процессор
Рис. 10.8. Кривая эффективности затрат на СОС при покупке процессоров со
скидкой
Техническое обеспечение ЭВМ. Типичный прейскурант на тех-
ническое обеспечение выглядит так:
1000 долл, за каждое из первых четырех устройств (с l-ro
по 4-е);
850 долл, за каждое из последующих 10 устройств (с 5-го
по 14-е);
750 долл, за каждое из последующих 35 устройств (с 15-го
по 49-е);
650 долл, за каждое из последующих 150 устройств (с 50-го
по 199-е);
600 долл, за каждое приобретенное сверх того устройство
(с 200-го).
Машинное время. Типичная расценка за минуту времени рабо-
ты центрального процессора универсгльной ЭВМ такова: 5 долл.
Для срочных работ, 3 долл, для нормального (2 ч.) цикла обраще-
ния и 1 долл, для ночного (12 ч) цикла обращения.
Программные изделия. Типичный прейскурант на программное
Изделие выглядит так: 10 000 долл, за использсвание на первой
Установке в некоторой организации и 2000 долл, за использование
на каждой из дополнительных установок в той же организации.
Дополнительную информацию о структуре цен на вычислитель-
ные оборудование и услуги можно получить в [269], хотя приво-
димые там цены уже устарели.
169
Заключение выгодного соглашения о ценах не разрешает пол-
ностью проблемы определения целесообразного числа покупаемых
процессоров. Однако модель эффективности затрат дает возмож-
ность уточнить эту проблему следующим образом.
Формула эффективности затрат П (С) показывает, какую про-
изводительность можно получить при заданных затратах. Как же
определить желательную производительность?
Такая постановка проблемы помогает четко установить альтер-
нативы и сформулировать дополнительные вопросы, на которые
необходимо ответить для принятия решения. Среди них:
1. Предположим, что можно найти какой-нибудь альтернатив-
ный способ использования ресурсов для разработки СОС (напра-
вить эти ресурсы на упрощение операционной системы и уменьше-
ние межпроцессорных накладных расходов). Как выбрать лучшую1
альтернативу? Получение ответа на этот вопрос относится к обла-'
сти сравнения эффективностей затрат (см гл. 11 и 12).
2. Как определить важность скорости обработки сообщений?
Как согласовать различные оценки затрат и важность их в рамках
единого критерия принятия решений о выборе правильной альтер-
нативы и определении числа закупаемых процессоров? Получение
ответа на этот вопрос относится к области принятия многоцелевых
решений (см, гл. 13—18).
3. Предположим, что для принятия удовлетворительного реше-
ния не хватает информации относительно определенных системных
параметров. Какие средства следует затратить на получение до-
полнительной информации и проведение анализа с целью умень-
шения вероятности выбора неправильного пути? Получение ответа
на этот вопрос относится к области анализа степени риска и ста-
тистической теории решений (см. гл. 19 и 20).
ГЛАВА 11
ПРОИЗВОДСТВЕННЫЕ ФУНКЦИИ И ЭФФЕКТЫ МАСШТАБА
11.1. ПРИМЕР
Одним из решений, относящихся к области инженерного программирования,
которое целесообразно рассмотреть в случае СОС, является разработка более
эффективной операционной системы с меньшими межпроцессорными накладными,^
расходами. Допустим, что в результате анализа установлена возможность созда- ।
ния эффективной системы с коэффициентом межпроцессорных накладных расхо-
дов, равным 50 вместо 80 для существующей операционной системы. В гл. 9
с помощью промежуточной КОМОСТ было определено, что затраты на разработ- '
ку такой специализированной системы составят 180 тыс. долл. Закупаемая же
операционная система стоит 80 тыс. долл, и для выбора предпочтительного ре-
шения необходимо сравнить экономические характеристики применения двух ука-
занных операционных систем.
Выбор решения можно осуществить с помощью графиков на рис. 11.1, где
дано сравнение эффективности затрат при использования закупаемой операцион-
ной системы (вариант А) и разрабатываемой специализированной операционной
системы (вариант В); затраты на аппаратуру предполагаются равными 10 тыс.
170
3
Рис. Ill
Сравнение эф-
фективности за-
трат для вари-
антов Л и В
с:
200 —
180-
160 -
140-
120 -
100 -
80-
60-
40-
20-
Инвестирование
Сокращение отдачи
Высокая отдач.
Вариант В
С Л (С)
В — разработать ОС
Затраты С, тыс. дол1Ъ
долл, за один процессор (эта цена не зависит от размера партии). Кривые эффек-
тивности затрат на рис. 11.1 не опускаются после достижения максимального
значения, как это было на рисунках предыдущего раздела. Это достигается ис-
ключением непроизводительных затрат. Например, выделение 150 тыс. долл, па
вариант А вовсе не означает, что будет разрабатываться семипроцессорный ва-
риант системы с производительностью 112 сообщ./с. Вместо этого будет принято
более предпочтительное решение: разработать и ввести в действие за 130 тыс.
долл, пятипроцессорную систему с производительностью 120 сообщ./с, а 10 тыс.
долл, оставить в резерве для каких-либо других нужд или на случай непредви
денных обстоятельств.
11.2. ОПРЕДЕЛЕНИЯ
Указанная на рис. 11.1 зависимость в экономике называется
производственной функцией. Она устанавливает связь объема про-
изводства (число сообщений) в единицу времени с затратами
(в рассматриваемых случаях—денежных средств) при условии
использования только технологически эффективных1 комбинаций
затрат и объема производства. (В приводимом примере расхо-
дование 150 тыс долл, для получения производительности
112 сообщ./с — точка X на рис. 11.1 — было бы технологически
неэффективным.) При выполнении этого условия производствен-
ная функция будет неубывающей. Другим свойством производст-
-енной функции является ее неотрицательность, поскольку в лю-
бом случае можно ничего не делать и обеспечить тем самым нуле-
вой объем производства.
Как правило (но не всегда), можно выделить три основных
участка (диапазона) производственной функции (на рис. 11.1 они
указаны для варианта В):
1 Комбинация затрат и объема производства технологически эффективна, если
при данных затратах объем производства увеличить невозможно.
171
1. Участок инвестирования (капиталовложения), на котором
затраты не обусловливают сколько-нибудь значительный объем
производства.
2. Участок высокой отдачи, на котором относительно небольшое
увеличение затрат дает в результате относительно большое увели-
чение объема производства.
3. Участок сокращения отдачи, на котором дополнительные за-
траты приводят к относительно небольшому увеличению объема
производства.
11.3. ДИСКРЕТНЫЕ ПРОИЗВОДСТВЕННЫЕ ФУНКЦИИ
Существуют различные виды производственных функций. В ин-
женерном программировании часто встречаются дискретные про-
изводственные функции, для которых увеличение эффективности
(объема производства) возможно лишь при достаточно большом
Рис. 11.2. Дискретные
производственные функ-
ции вариантов А и В
для СОС
увеличении затрат. Например, для СОС производственная функция
фактически является дискретной, так как увеличение эффектив-
ности можно добиться лишь при увеличении затрат не менее чем
на 10 тыс. долл., что соответствует покупке еще одного процессора.
Поэтому графики на рис. 11.2 более точно изображают производ-
ственные функции вариантов А и В.
11.4. ОСНОВНЫЕ ПРОИЗВОДСТВЕННЫЕ ФУНКЦИИ ПРОГРАММНОЙ
РАЗРАБОТКИ
Основной производственной функцией в инженерном програм-
мировании является зависимость, связывающая число исходных
команд с затратами труда в человеко-месяцах. На рис. 6.1 пред-
ставлены версии таких производственных функций для трех основ-
ных типов программной разработки.
11.5. ПОЛОЖИТЕЛЬНЫЕ И ОТРИЦАТЕЛЬНЫЕ ЭФФЕКТЫ МАСШТАБА
Ход правых концов графиков рассмотренных производственных
функций определяется положительными и отрицательными эффек-
тами масштаба. Положительные эффекты масштаба состоят в по-
вышении эффективности производства при увеличении масштабов
172
N=4
Рис. 11.3. Потенциальные лути общения в группе из N человек
производства. В крупных программных проектах часто можно до-
биться положительного эффекта масштаба путем приобретения
специализированных средств повышения производительности тру-
да, например инструментальных средств тестирования, диагности-
ки, документирования и работы с программной библиотекой, а
также процессоров и постпроцессоров. В таких проектах перечис-
ленные инструментальные средства найдут достойное применение,
экономический эффект которого превысит затраты на их приобре-
тение. Тем самым будет обеспечен положительный эффект масшта-
ба, недоступный для менее крупных проектов, в которых использо-
вание указанных инструментальных средств было бы недостаточ-
ным для возмещения затрат на их приобретение.
Отрицательные эффекты масштаба проявляются аналогично
межпроцессорным накладным расходам в случае СОС: чем больше
исполнителей вводится в состав бригады, тем больше времени
каждого сотрудника расходуется на общение членов бригады по
обновлению общей информации, исправлению ошибок или исполь-
зованию разделяемых ресурсов. Групповой программной разработ-
ке присущи также некоторые чисто человеческие отрицательные
эффекты масштаба: чем больше людей занято в проекте, тем в
большей степени противоречия личного характера, различия в под-
ходах к программированию и стиле работы различных сотрудников
будут уменьшать производительность труда всей бригады.
11.6. ОТРИЦАТЕЛЬНЫЕ ЭФФЕКТЫ МАСШТАБА ДЛЯ БОЛЬШИХ
ПРОГРАММНЫХ ПРОЕКТОВ
Если в программном проекте участвуют /V человек, то сущест-
вует N-(N—1)/2 потенциальных межличностных путей общения
или взаимодействия, которые и могут привести к отрицательным
эффектам масштаба. На рис. 11.3 показан рос-” числа этих путей
Для К, равного 4, 6 и 8.
Таким образом, инженер-программист крупного программного
проекта находится в самом центре влияния положительных и от-
рицательных эффектов масштаба. Имеется целый ряд организаци-
онных, ггхнических и стимулирующих практических приемов, ко-
торые можно использовать для уменьшения отрицательных эффек-
тов масштаба. Основным приемом, конечно, является создание для
173
крупных программных проектов иерархической функциональнс
специализированной организационной структуры (см. гл. 7). На-
пример, в представленной на рис 7.3 организационной структуре
фазы программирования число парных взаимодействий равно 144,
а не 1128 (48X47/2=1128) для 48 исполнителей.
11.7. ОСНОВНОЙ СПОСОБ УМЕНЬШЕНИЯ ОТРИЦАТЕЛЬНЫХ
ЭФФЕКТОВ МАСШТАБА
Наиболее действенным способом уменьшения отрицат
эффектов масштаба является
[УМЕНЬШЕНИЕ МАСШТАБА ПРОИЗВОДСТВА}
В реализации программного проекта буквально на каждом ша-
гу появляются соблазны увеличить размер изделия и объем рабо-
ты, придать им более грандиозный характер. Необходимо всячески
избегать таких соблазнов. Гораздо выгоднее уменьшать масштабы
проекта, используя методы пошаговой разработки, изготовления
прототипа и сокращая список желательных свойств изделия.
Устранение отрицательных эффектов масштаба. Для любого
программного изделия можно составить длинный перечень средств,
которые способствуют улучшению в каком-либо отношении этого
изделия. Одни классы средств оказались бы весьма полезными для
многих программных изделий, а другие дорогостоящими излишест-
вами, их реализация увеличивает объем работы и стоимость изде-
лия и не приносит пользы.
Ниже представлено несколько примеров таких практически до-
рогостоящих средств, затем обсуждены средства, которые не явля-
ются излишествами, как это могло показаться при первом рассмо-
трении. Наконец, приведены средства, которые в зависимости от
конкретных условий могут попасть в тот или иной класс.
Дорогостоящие излишества.
Мгновенный ответ. Для некоторых операций и решений весьма
необходим быстрый ответ. И многие системы были обременены тре-
бованиями мгновенной выдачи информации, которая использова-
лась только через несколько часов и даже дней. Например, в пер-
воначальных спецификациях злополучной системы материально-
технического обеспечения [67], стоящей 216 млн, долл., требовал-
ся быстрый ответ на 90% запросов, а последующий анализ пока-
зал необходимость быстрого ответа лишь для 10% запросов.
Абсолютная точность. В одной организации было сэкономлено
6 млн. долл., выделенных на покупку дополнительной супер-ЭВМ,
когда обнаружилось, что имеющаяся ЭВМ тратит основную часть
своего времени на получение результатов с четырьмя точными циф-
рами, в то время как пользователям нужны были лишь две точные
цифры.
Системная несбалансированность. Это означает, что хорошие
характеристики работы одних частей системы не используются е
174
других частях. Например, при разработке одной информационной
с^темы городского аварийного энергоснабжения было безуспешно
-тоачено свыше 1 млн. долл, для автоматизации получения гео-
графических коопдинат с тремя точными цифрами, а времени про-
езда к месту аварии — с одной точной цифрой. В конечном счете
быта разработана менее чем за 5000 долл, система ручного ввода
координат, обеспечившая достаточную точность.
Средства искусственного интеллекта (ИИ). Этс весьма инте-
ресная область исследований, а соответствующие средства весьма
привлекательны для пользователя, когда они представлены в об-
щих выражениях (ввод на естественном языке, понимание речи,
распознавание схем сбыта и т. п.). Некоторые средства ИИ, такие
как умение проводить сложное календарное планирование, были
успешно реализованы в программных изделиях и в результате
перестали относиться к ИИ. На реализацию других пошли миллио-
ны долларов без какого-либо положительного результата.
Диалоговая многоцветная графика. Это еще одна увлекатель-
ная область исследований с большими возможностями повышения
эффективности человеко-машинных систем, но с уже долгой исто-
рией разработок излишеств. Например, при разработке одной ин-
формационной системы для высшего руководства были затрачены
миллионы долларов на создание нескольких дисплеев, выдающих
красивые контрольные диаграммы, однако высшее руководство
сочло, что дисплеи привлекательны, но весьма сложны и не имеют
отношения к основной их работе.
Универсальные системы. В конце 60-х годов был предпринят
ряд попыток разработать «единые информационные системы
управления», которые объединили бы все потребности корпораций
в обработке информации в рамках единой системы. Однако к на-
чалу 70-х годов стала совершенно очевидной неудача таких систем,
главным образом из-за отрицательных эффектов масштаба и сла-
бого понимания действительных потребностей корпораций в обоа-
ботке информации (см., например, [83, 168]).
Средства, обычно не являющиеся излишествами.
Препроцессоры ввода. Стредства, создающие простой и надеж-
ный ввод данных большого объема, не являются излишествами
(см., например, [129]).
Постпроцессоры вывода. Вывод сообщений об исключительных
ситуациях, избавляющий пользователя от необходимости анализа
огромных кип распечаток, не относится к излишествам. Конечно,
и при разработке средств вывода, да и ввода, можно выйти за
пределы разумного, как, например, в случае диалоговой много-
цветной графики.
Средства, обеспечивающие модульносто и скрытность информа-
ции, На обеспечение этого требуются дополнитечьные усилия в на-
чале р 1зраоотки, но, как видно из используемого в промежуточной
КОМОСТ значения коэффициента учета опыта применения совре-
менного программирования (см. табл. 8.2 и 8.3), эти затраты при-
носят существенную отдачу при разработке и сопровождении.
175
к излишествам. Существую!
одних применениях, но совер
Средства измерения, диагностики, резервирования, восстановле
ния и т. п. Эти средства улучшают качество ПО и, как правило, щ
являются излишествами за исключением, возможно, быстро раз
рабатываемых изделий с коротким
же [42 и 186]).
Средства, относящиеся иногда
средства, которые весьма полезны в
шенно излишни в других, например:
обобщенные структуры данных и управления;
изощренные командные языки пользователей;
сервисные и вспомогательные программы общего назначения,
автоматический анализ тенденций.
Способ распознавания излишеств для ПО. Лучший способ рас-
познавания излишеств заключается в использовании метода про-
изводственных функций. В этом методе вначале для каждого воз-
можного средства определяется его вклад в эффективность систе-
мы обработки информации и в затраты на разработку изделия
Если при учете этих двух вкладов средство попадает на участок
сокращения отдачи производственной функции (рис. 11.4), то онс
является излишеством и от него следует отказаться. Если же сред-
ство попадает на участок инвестирования или высокой отдачи, тс
его следует учесть в разработке программного изделия. Однакс
при разработке
жизненным циклом (см. так-
нового программного изделия, необходимо такж.
Затраты на программное изделие
Рис. 11.4. Типичная производственная функция для средств программного изде-
лия
17Б
Модуль Г
Рис. 11-5. Модуль-
ная система обра-
ботки сообщений
Модуль?
оценивать возможность переноса на более поздние сроки разра-
ботки средств, не ставя при этом под угрозу жизнеспособность
очередной версии системы. Так, например, систему с производст-
венной функцией, приведенной на рис. 11.4, можно было бы раз-
рабатывать, реализуя все начальные возможности вплоть до базо-
вых прикладных функций на первом шаге, основных прикладных
функций на втором шаге, ввода-вывода, ориентированного на че-
ловека, и второстепенных прикладных функций на третьем шаге,
а уже затем исследовать другие возможности.
При разработке ПО указанные оценки получают естественно в
процессе анализа целей на пятом шаге ЦОП (см. табл. 3.2) и
после подтверждения осуществимости, анализа требований, пла-
нирования и проектирования изделия.
Несколько более конкретных указаний относительно установ-
ления ценности средств программного изделия дано в гл. 20 в рам-
ках подхода к определению стоимости информации.
Устранение отрицательного эффекта масштаба в производстве
аппаратно-программных изделий. Этого можно также достичь
уменьшением масштаба. Очень эффективным методом уменьше-
ния масштаба является следование принципу функциональной мо-
дульности, применение которого проиллюстрировано ниже на при-
мере.
Предположим, что необходима СОС с производительностью
180 сообщ./с. По данным рис. 11.1, для получения такой произво-
дительности следует затратить не менее 260 тыс. долл. Предполо-
жим однако, что можно найти способ разбиения сообщений на два
класса с независимой обработкой. Будем считать, что производи-
тельности для этих классов сообщений примерно одинаковы:
95 сообщ//с для класса 1 и 85 сообщ./с для класса 2. Если это
177
верно, то систему можно разделить на два функциональных моду-
ля, обрабатывающих сообщения своего класса (см. рис. 11.5).
В оба модуля входит по три процессора. Трехпроцессорная конфи-
гурация в состоянии обработать 96 сообщ./с, а этого достаточно
для функций каждого модуля.
Окончательные затраты составляют 60 тыс. долл, на процессо-
ры и 80 тыс. долл, на ПО *, т. е. в сумме 140 тыс. долл. Таким об-
разом, используя принцип функциональной модульности для умень-
шения требуемых масштабов мультипроцессирования, удалось поч-
ти вдвое уменьшить первоначальную оценку затрат, а также обес-
печить существенно большие возможности для расширения.
ГЛАВА 12
КРИТЕРИИ ПРИНЯТИЯ РЕШЕНИЯ ПРИ ВЫБОРЕ АЛЬТЕРНАТИВ
12.1. МАКСИМУМ ПРОИЗВОДИТЕЛЬНОСТИ ПРИ ОГРАНИЧЕННОМ БЮДЖЕТЕ
Предположим, что невозможно подразделить сообщения на два
класса и использовать в силу этого модульную структуру СОС,
как обсуждалось в предыдущем разделе. Поэтому решение необ-
ходимо искать в условиях, характеризуемых рис. 11.2. Это ставит
трудную проблему выбора оптимального решения. Какой вариант
следует выбрать, А или В? Если бы значения одной производст-
венной функции (вариант F
на
рис. 12.1) были всегда не меньше
значений другой производствен-
ной функции (вариант G), то вы-
бор пал бы на вариант F. Одна-
ко, как видно из рис. 11.2, ва-
риант А более предпочтителен,
пока затраты не превышают
220 тыс. долл., после чего более
предпочтительным становится ва-
риант В.
Существует несколько крите-
риев принятия решения:
1) максимум производитель-
ности при ограниченном бюд-
жете;
2) минимум затрат при ограниченной производительности;
3) максимум отношения производительности к затратам;
4) максимум разности эффективности и затрат;
5) критерии смешанных стратегий.
Обсудим последовательно эти критерии. Сначала рассмотрим
первый из них. Если, например, на разработку СОС выделено толь-
1 По-видимому, потребуются дополнительные затраты на приспособление ПО
для обработки двух классов сообщений, однако эти затраты будут невелики по
сравнению с полученной общей экономией.
178
ко 150 тыс. долл., то, очевидно, решение следует принять в пользу
варианта А. Однако, пользуясь первым критерием, можно упустить
определенные возможности, если слишком строго придерживать-
ся зачастую произвольно установленного бюджета. Например,
ограничение бюджета суммой 90 тыс. долл, привело бы к решению
о создании СОС с производительностью, соответствующей точке в
самом низу участка высокой отдачи (см. рис. 11.2). Ослабление
же бюджетного ограничения примерно на 10% (до 100 тыс. долл.)
дало бы увеличение производительности на 80% (от 40 до
72 сообщ /с при переходе из точки X в точку К).
В других случаях использование первого критерия может за-
ставить выбрать неудовлетворительный вариант решения. Напри-
мер, ограничение бюджета суммой 210 тыс. долл, заставило бы
выбрать вариант А (точка Z), что явилось бы неудачным решени-
ем, если было бы необходимо предусмотреть возможность некото-
рого увеличения производительности сверх 120 сообщ./с.
12.2. МИНИМУМ ЗАТРАТ ПРИ ОГРАНИЧЕНИИ ПРОИЗВОДИТЕЛЬНОСТИ
Если в конкретном применении требуется производительность
не менее 160 сообщ./с, то очевидным решением является выбор
варианта В. Однако слишком жесткие требования по производи-
тельности могут привести к неудовлетворительному результату
(как и в случае неоправданно жестких ограничений на бюджет)
Например, произвольно установленное требование обеспечить про-
изводительность 125 сообщ./с заставляет принять решение о за-
тратах 220 тыс. долл, (точка Р на рис. 11.2). Сднако, если потреб-
ности этого применения можно было бы удовлетворить произво-
дительностью 115 сообщ./с, то приемлемую систему можно было бы
приобрести за 130 тыс. долл (точка О).
12.3. МАКСИМУМ отношение ПРОИЗВОДИТЕЛЬНОСТИ К ЗАТРАТАМ
Такой критерий максимизирует отдачу на единицу капитало-
вложений. На рис. 12.2 все точки с заданным отношением лежат
на прямой линии, проходящей через начало координат. Например,
на прямой L лежат все точки с отношением производительности к
затратам, равным 2.
Следовательно, для определения решения по данному критерию
необходимо найти прямую, проходящую через начало координат,
имеющую угол максимального наклона к оси затрат и содержа-
щую хотя бы одну общую точку с графиком производственной
функции. Искомой прямой в случае СОС является линия К с угло-
вым коэффициентом 0,93, а точкой максимума отношения произво-
дительности к затратам является точка, которая соответствует
затратам в 120 тыс. долл, и производительностью в 1'12 сообщ./с.
Третий критерий позволяет получать приемлемые решения. Од-
нако он совершенно не учитывает бюджетные ограничения, требо-
179
Рис. 12.2. Определение максимума отношения эффектив-
ности к затратам
вания к производительности и необходимость будущих расширений
системы. В некоторых ситуациях приведенные соображения могут
оказаться очень важными и тогда рассмотренный критерий может
привести к неудачному решению.
12.4. МАКСИМУМ РАЗНОСТИ ЭФФЕКТИВНОСТИ И ЗАТРАТ
Предположим, что затраты и эффективность можно выразить
в одних и тех же единицах. Например, если каждая единица про-
изводительности (1 сообщ./с) стоит 2500 долл., то можно измерить
эффективность в денежных единицах и использовать разность эф-
фективности и затрат в качестве критерия принятия решения.
Применим этот критерий для выбора варианта СОС. Для этого
рассмотрим рис. 12 3 с производственными функциями вариантов
А и В, где значения эффективности приведены в долларах. На
Рис. 12.3. Определение максимума разности эффективности и затрат, вариант 1
180
Рис. 12 4. Определение максимума разности эффективности и затрат, вариант 2
рисунке показана также прямая L, задающая все точки равенства
эффективности и затрат. Поскольку для любой точки производст-
венной функции разность эффективности и затрат равна расстоя-
нию по вертикали между этой точкой и прямой L, максимальное
значение этой разности можно определить, найдя наиболее удален-
ную по вертикали прямой L точку производственной функции.
В рассматриваемом случае такой точкой является точка D с Э =
= 450 тыс. долл., С = 260 тыс. долл, и Э — С = 190 тыс. долл.
Если стоимость единицы производительности была бы другой,
то были бы получены новая прямая £' и часто новая точка D', со-
ответствующая наибольшему значению разности эффективности и
затрат. На рис. 12.4 показана ситуация выбора варианта СОС,
когда стоимость единицы производительности равна 2000 долл,
вместо 2500 долл.
Четвертый критерий, как и третий, позволяет получить прием-
лемое решение, но совершенно не учитывает бюджетные ограниче-
ния, требования к производительности или необходимость будущих
расширений системы. Методы учета указанных факторов будут
обсуждены в части ЗБ.
12.5. СМЕШАННЫЕ СТРАТЕГИИ
Вовсе не обязательно выбирать одну альтернативу и отказы-
ваться от всех других: наилучшее решение часто состоит в согласо-
ванном использовании имеющихся альтернатив. Например, пред-
положим, что операционные системы вариантов А и В, стоящие
соответственно 180 и 80 тыс. долл., имеют общую часть стоимостью
30 тыс. долл, (в общую часть могут входить тесты, документация
и т. п.). Рассмотрим следующую смешанную стратегию разработки:
1. Используя поставляемую операционную систему и пятипро-
цессорную конфигурацию, ввести в действие систему с производи-
тельностью 120 сообщ./с при затратах 130 тыс. долл.
181
2. Использовать полученную аппаратно-программную систем^
и в то же время приступить к разработке специализированной ОС
выделив для этой цели дополнительные 150 тыс. долл.
3. После изготовления новой ОС внедрить ее на имеющейся
конфигурации аппаратных средств, увеличив тем самым произво-
дительность до 150 сообщ./с.
4. По мере необходимости добавлять дополнительные процес-
соры.
Соответствующая этой стратегии составная производственная
функция показана на рис 12.5.
По сравнению с вариантом В затраты при смешанной стратегии
разработки на достижении таких же высоких значений эффектив-
Рис. 12.5. Производственная функция для смешанной стратегии разработки СОС
ности больше на 50 тыс. долл., которые, однако, позволяют исполь-
зовать систему с производительностью 120 сообщ./с еще до разра-
ботки специализированной ОС. Это обеспечивает полезную воз-
можность постепенного расширения СОС и изучения ее работы при
эксплуатации, пока еще остается время для учета результатов изу-
чения в проекте специализированной СОС. Это также избавляет
разработчиков ОС от необходимости быстрейшего завершения ра-
боты, обычно достигаемого за счет ухудшения качества програм-
много изделия.
В заключение следует указать, что разнесение затрат и при-
былей во времени при смешанных стратегиях создает определен-
ные трудности в сопоставлении настоящих и будущих ресурсов.
Это объясняется тем, что ценность денежной суммы отличается от
ценности такой же суммы через два года. (Более подробно затро-
нутые вопросы будут рассмотрены в гл. 14.)
12.6. ОБЩЕЕ ОБСУЖДЕНИЕ
Решения в инженерном программировании и соответствующие
критерии не так просты, как это было в приведенных примерах.
Однако рассмотренные критерии чрезвычайно полезны для форму-
лировки и разрешения многих вопросов в связи с принятием реше-
ний в ЖЦПО. Они также лежат в основе более развитых методов
принятия решений, которые будут обсуждены далее в ч. 3.
182
ЧАСТЬ ЗБ
анализ многоцелевых решений
Сущность представл гнного в ч. 1 ЦОП состоит в том, что для
j спешного инженерного программирования необходимо непрерыв-
ное определение пелей, их согласование, принятие решений яри
наличии противоречащих друг другу целей и управление с учетом
нескольких целей Лишь в редких случаях в области инженерного
программирования имеется возможность принимать решения по
единственному критерию. Как показало изучение конкретных при-
меров в гл. 1 и 2, очень опасно действовать в предположении, что
имеется только одна цель. Следовательно, крайне важно хорошо
знать методы согласования целей и принятия многоцелевых ре-
шений.
В этой части будут рассмотрены следующие основные методы
1. Предельный анализ чистой стоимости (по существу это сто-
имость программного изделия или услуг за вычетом затрат на их
предоставление) Этот метод представлен в гл. 13 и позволяет при-
нимать решения в тех случаях, когда все существенные цели мо
гут быть выражены в единицах измерения чистой стоимости
2. Сопоставление текущих и будущих расходов и доходов. Та-
кое сопоставление является необходимым, особенно в условиях
инфляции, поскольку денежная сумма, потраченная или получен-
ная в данный момент времени, обладает большей ценностью, чем
та же сумма, потраченная или полученная через год. Для учета
подобных обстоятельств в гл. 14 будут представлены методы опре-
деления текущей стоимости.
3. Показатели качества. В гл. 15 рассмотрены различные пока-
затели качества, используемые для сведения большого числа целей
к единственной. Обсуждена их применимость для принятия реше-
ния посредством единого показателя качества.
4. Цели в качестве ограничений при условной оптимизации.
В гл. 16 представлены методы упрощения процесса принятия мно-
гоцелевых решений путем трактовки некоторых целей в качестве
ограничений.
5. Системный анализ и условная оптимизация Системный ана-
лиз является наиболее эффективным подходом к принятию реше-
ний на фазе анализа осуществимости. Схема применения и основ-
ные понятия системного анализа в рамках условной оптимизации
представлены в гл. 17.
6. Учет несопоставимых и невыражоемых количественно целей
В инженерном программировании должны очень часто принимать-
ся решения по отношению к группе целей (уменьшение затрат на
Разработку, улучшение морального климата в коллективе разра-
ботчиков, повышение надежности и облегчение использования из-
делия), которые либо являются существенно неколичественными,
183
либо практически не поддаются оценке с использованием какой
либо общей единицы, такой как доллар. Некоторые методы для
учета таких ситуаций представлены в гл. 18.
ГЛАВА 13
ПРЕДЕЛЬНЫЙ АНАЛИЗ ЧИСТОЙ СТОИМОСТИ
13.1. ПРИМЕР
Рассмотрим снова пример из разд. 12.4, посвященного критерию принятия
решения по максимуму разности эффективности и затрат. При наличии какого-
нибудь способа измерения производительности в денежных единицах (соответ-
ствующее значение будет далее называться общей стоимостью, или сокращенно
ОБС) разность эффективности и затрат используется в качестве полезного крите-
рия принятия решения. Поэтому, как только была установлена цена единицы про-
Рис. 13.1. Сравнение чистой стоимости вариантов СОС с затра-
тами
изводительности (например, 2500 долл.), оказалось возможным определить по
рис. 12.3 конфигурацию СОС с наибольшим значением этого критерия и предло-
жить предпочтительный вариант разработки системы. По рис. 12.3 этому решению
соответствует точка D: восьмипроцессорная конфигурация вместе со специализи-
рованной ОС, с затратами С=260 тыс. долл., ОБС=450 тыс. долл, и чистой
стоимостью, равной ОБС — С=190 тыс. долл.
Другой способ определения оптимального решения состоит в построении для
различных вариантов решений графика чистой стоимости ЧС=ОБС—С и поиска
точки максимума этой функции (полученная этим способом точка D показана
на рис. 13.1).
13.2. ОБЩЕЕ ОБСУЖДЕНИЕ ПРЕДЕЛЬНОГО АНАЛИЗА
Общая стоимость системы обработки информации представляет собой ее
эффективность, выраженную в единицах затрат С. В этом случае чистая стоимость
определяется как разность эффективности и затрат по формуле: ЧС=ОБС—С.
На рис. 13.1 показана зависимость чистой стоимости от затрат. Поскольку
эатраты часто определяются уровнем работоспособности варианта1 (в данном
1 Уровень работоспособности варианта является количественной мерой реали-
эации этого варианта.
84
случае числом приобретаемых процессоров), то полезно выражать затраты, общую
стоимость и чистую стоимость функцией уровня работоспособности.
На рис. 13.2 показаны типичные формы функций затрат С (х), общей
стоимости ОБС (х) и чистой стоимости [ЧС (х)=ОБС (х)—С (х)], где х —
уровень работоспособности.
Типичная функция чистой стоимости имеет участки, аналогичные рассмотрен-
ным в разд. 11.2 для функции общей стоимости (или производственной функ-
ции) — инвестирования, высокой отдачи и сокращения отдачи. Так, функция
чистой стоимости начинается участком инвестирования, который представляет
собой первую лежащую ниже горизонтальной оси и заканчивающуюся в точке Х]
часть кривой. Затем следует участок получения прибыли, включающий точку хтах.
Правее этой точки функция затрат увеличивается быстрее функции общей стоимо-
сти, а после точки х2 начинается участок сокращения отдачи, на котором общая
стоимость опять меньше затрат.
УровеньраБотоспособностих
а)
Рис. 13.2. Затраты и общая стоимость (а)' и зависимость чистой стоимости от
уровня работоспособности (б)
б)
Предельная чистая стоимость. Для любого уровня работоспособности х
можно определить его локальные изменения, вычисляя тангенс угла наклона кри-
вой чистой стоимости, называемый предельной чистой стоимостью (ПЧС):
ПЧС=б(ЧС)/бх.
Рассматривая участок получения прибыли, можно сформулировать следующие
правила ее максимизации:
1. Если ПЧС положительна, то увеличить уровень работоспособности.
2. Если ПЧС отрицательна, то уменьшить уровень работоспособности.
3. Если ПЧС равна нулю, то достигнут оптимальный уровень работоспособ-
ности.
Следовательно, оптимальный уровень работоспособности можно определить,
решая уравнение для предельной чистой стоимости
d(4C),/dx=0. (13.1)
Поскольку ЧС=ОБС—С, это уравнение можно представить в следующем
виде:
d(4C) /dx=d(OBC)J'dx—dC/dx=0,
или
d(OBC)/dx=dC/dx. (13.2)
Функции d(OBC)/rfx и dC/dx называются предельной общей стоимостью и
предельными затратами соответственно. Графики этих функций показаны на
Рис. 13.3, они соответствуют функциям общей стоимости и затрат на рис. 13.2.
В терминах предельной общей стоимости и предельных затрат приведенные
выше правила максимизации чистой стоимости можно переформулировать сле-
дующим образом:
185
1. Если предельная общая стоимость больше предельных затрат, то увеличить
уровень работоспособности.
2. Если предельная общая стоимость меньше предельных затрат, то уменьшить
уровень работоспособности
3 Если предельные общая стоимость и затраты равны, то достигнут опти-
мальный уровень работоспособности. Так же, как и в случае первой формулиров-
ки, использование этого правила допустимо лишь на участке получения прибыли.
13.3. ПРИМЕР
Проиллюстрируем использование введенных понятий на примере анализа раз-
работки СОС. Для этого вспомним (см. рис. 12.3), что чистая стоимость СОС
достигает максимального значения при использовании в варианте В восьмипро-
Рис. 13.3. Предельные затраты и общая стоимость (а) и предельная чистая
стоимость (б)
цессорной конфигурации аппаратных средств. Однако это заключение основыва-
лось на оценке в 2500 долл, для стоимости единицы производительности Се.п,
причем точность этой оценки невелика. Поэтому желательно исследовать чувстви-
тельность зависимости TVmax от Се.п.
В случае СОС уровень работоспособности задается числом процессоров N.
Затраты и общая стоимость зависят от N следующим образом:
C(7V) = 18O+1O/V;
ОБС (/V) = Се. D N [ 1 000—200 —50 (W — 1) ] /20 = Се. п (42, 5N—2, 5№),
где выражение для ОБС (/V) получено из (-10.1). Теперь можно вычислить пре-
дельные затраты и общую стоимость:
dC/dN=l0; d (ОБС) /dN=Ce п (42,5— 5/V).
Значение Л/тах можно найти подстановкой приведенных выражений в (13.2)
и решением полученного уравнения относительно 7Ушах.-
^тах=(42,5Се.п-10)/5Се.п = 8,5-2/Се.п. (13.3)
Определяемый формулой (13.3) график зависимости показан на рис. 13.4. Из
этого графика видно, что вблизи точки Се.п=2500 долл, кривая очень полога.
Рис. 13.4. Зависимость оп-
тимального числа процес-
соров от стоимости едини-
цы производительности
186
Следовательно, приобретая в результате проведенного ранее анализа восьмипро-
цессорнук> систему, можно особенно не беспокоиться по поводу ее плохого соот-
ветствия оптимальной системе из-за некоторой неточности первоначальной оцен-
ки Сея-
13.4. НЕКОТОРЫЕ ПРЕДОСТЕРЕЖЕНИЯ ОТНОСИТЕЛЬНО ИСПОЛЬЗОВАНИЯ
ПОНЯТИЯ ЧИСТОЙ СТОИМОСТИ
Во многих работах по «теории фирмы» в основу деятельности фирмы положен
принцип максимизации прибыли. Однако использование критерия максимизации
денежной прибыли в качестве единственного обычно приводит к решениям, обеспе-
чивающим определенное время хороший доход, но оказывающим плохое воздей-
ствие на социальное положение людей (и часто это приводит к плохим перспек-
тивам фирмы в плане долгосрочного дохода).
В этой же книге для устранения недостатков традиционной трактовки кате-
гории прибыли (чистой стоимости) предполагается, что все существенные компо-
ненты эффективности — удовлетворение потребностей разработчиков, доброжела-
тельность заказчиков, защищенность информации пользователя от несанкциониро-
ванного доступа, легкость управления системой оператором — будут представлены
в денежной форме и включены в функцию общей стоимости (и, таким образом,
будут учтены и в прибыли). Если же для некоторых факторов количественное
представление невозможно, то должен быть найден какой-нибудь способ представ-
ления их ограничениями (см. гл. 16) или неколичественными целями (см .гл. 18).
При таком подходе можно пользоваться мощными количественными метода-
ми, когда их применение целесообразно, и в то х<е время иметь возможность учи-
тывать субъективные соображения, когда они важнее количественных факторов.
13.5. СТОИМОСТЬ СИСТЕМ ОБРАБОТКИ ДАННЫХ
Даже в ситуациях, в которых социальные последствия принимаемых решений
имеют сравнительно небольшое значение, может оказаться трудным нахождение
точно определенной функции для выражения стоимости изделия. Примером этому
может служить определение стоимости единицы производительности для СОС.
В экономике «стоимость» изделия является наибольшей ценой, которую кто-
либо согласен уплатить за него. Для системы обработки данных стоимость изде-
лия может зависеть от довольно большого числа различных факторов. Так,
на стоимость влияют, в частности, следующие факторы.
Время окончания обработки. Вследствие нарушения ежедневного срока об-
работки сообщений теряется часть процентного дохода в расчете на один день.
Поскольку же общий объем финансовых операций, производимых большими бан-
ками за день, составляет свыше миллиарда долларов, то эти потери приближа-
ются к 300 тыс. долл. [87], что вполне может оправдать значительное повышение
стоимости СОС
Стоимость альтернативных вариантов. Если единственной альтернативой
является ручная обработка сообщений, то стоимость автоматизированной СОС
может быть довольно большой. Однако, если уже существует экономичная
служба обработки сообщений, то стоимость новой системы может быть относи-
тельно низкой.
Возможности, предоставляемые информацией. Влияние этого фактора прояв-
ляется, например, в том, что в случае СОС для фондовой биржи значительный
прирост стоимости можно обеспечить за счет предоставления системой возможно-
стей изучения и использования тенденций экономической активности. В случае же
СОС оперативного обслуживания сбыта добиться прироста стоимости можно за
счет предоставления возможности более эффективного управления запасами.
Существенное влияние могут оказывать также другие факторы, такие как
точность, надежность, объем и структура информации. Влияние надежности ин-
формации на стоимость будет обсуждено в гл. 20.
Обобщая сказанное, можно заключить, что стоимость системы обработки дан-
ных определяется двумя главными факторами.
187
1. Ценностью для принятия решений получаемой информации. Так, в слу-
чае СОС предварительного заказа авиабилетов информация о числе и типах сво-
бодных и уже заказанных мест важнее информации о числе и типах двигателей
самолета. В то же время для СОС технического обслуживания самолетов ценной
была бы информация о двигателях. (Подробнее см. гл. 19 и 20.)
2. Степенью удовлетворения основных потребностей человека системой
обработки данных. Так, ценность оплаченного чека определяется в основном
тем, что он обеспечивает (продукты, развлечения, безопасность и т. п.), а не ис-
пользованием содержащейся на нем информации для принятия решений.
ГЛАВА 14
СОПОСТАВЛЕНИЕ ТЕКУЩИХ И БУДУЩИХ РАСХОДОВ
И ДОХОДОВ
14.1. ПРИМЕР УПРОЩЕННОГО АНАЛИЗА СТОИМОСТИ
Допустим, что решено использовать СОС в варианте А первые два года
(с применением поставляемой ОС). Предположим, что за это время будет приоб-
ретен опыт работы с системой, а к концу указанного периода будет подготовлена
более приспособленная к конкретным условиям работы система-преемник.
Может возникнуть требующая экономического решения проблема, которая
заключается в выборе между арендой и покупкой процессоров. Предположим
также, что в варианте А решено использовать пятипроцессорную систему и име-
ются следующие возможности *:
А1—арендовать процессоры за общую сумму 1200 долл, в месяц;
А2 — купить процессоры у посредника за 50 тыс. долл, и получить через
2 года при возврате их посреднику 25 тыс. долл.
Простой расчет выглядит следующим образом:
затраты на Л/=1200 долл./мес.-24 мес. = 28 800 долл.;
затраты на 42=50 000 долл.—25 000 долл. = 25 000 долл. Следовательно, ва-
риант А2 предпочтительней.
Однако сделанный вывод может оказаться неправильным, так как проведен-
ный анализ основывается на ошибочной предпосылке о постоянстве ценности дол-
лара. На самом деле имеющийся в данный момент доллар ценнее будущего, хотя
бы только потому, что его можно положить на два года в банк и получить про-
центы.
14.2. РАСЧЕТ ПРОЦЕНТОВ
Предположим, что имеется способ получения дохода с вложенных денег
в размере 9 % годового вклада в год или 0,75 % в месяц. Вариант А2 покупки
процессоров приводит к замораживанию на два года 25 тыс. долл. Подсчитаем,
в какую сумму превратились бы 25 тыс. долл, через два года при увеличении ее
на 0,75 % (т. е. с коэффициентом 1,0075) в месяц. После первого месяца полу-
чаем
С (25 000,1) =25 000 долл. • 1,0075;
после второго
С (25000,2) =25000 долл,-1,0075-1,0075=25 000 долл. 1,00752.
Рассуждая аналогично, получаем после 24-го месяца
С (25000,24) =25000 долл. 1,007524=25 000 долл.-1,1964 =29 910 долл.
Таким образом, замораживание 25 тыс. долл, при покупке процессоров при-
вело к потер'' дохода почти в 5000 долл.
1 Эти возможности характерны для использования скорее больших ЭВМ,
нежели микропроцессоров.
188
14.3. РАСЧЕТ ТЕКУЩЕЙ СТОИМОСТИ
Другой способ оценивания варианта А2 состоит в определении стоимости
на данное время тех 25 тыс. долл., которые будут получены через два года при
возвращении процессоров посреднику. Значение этой стоимости можно опреде-
лить разрешая относительно X следующее уравнение:
25 000 долл. = С (X, 24) =Х (1,0075)2<;
Х=25 000 долл./1,007524=25 000/1,1964 =20 896 долл.
Вычисленное значение представляет собой текущую стоимость тех 25 тыс.
долл., которые будут получены через два года. Следовательно, затраты на ва-
риант А2 составят
50 000 долл.—20 896 долл.=29 104 долл.
Если теперь определить текущие затраты на вариант А1, то можно будет бо-
лее обоснованно осуществить выбор между двумя вариантами.
Приведем предварительно несколько полезных формул. Так, из рассмотрен-
ного ранее уравнения для X — текущей стоимости ТС=25 тыс. долл, при станке
процента г=0,0075 в месяц, выплачиваемой в течение 24 месяцев, — получим
Х=ТС (25 000 долл.; 0,0075; 24) =25 000/1,007524.
Поскольку эти рассуждения остаются в силе для любого движения денежной
наличности F, любой ставки процента г за некоторый период времени и любого
числа таких периодов п, то можно получить общую формулу для текущей стои-
мости в следующем виде:
ТС (F, г, п)=Е/(1+г)". (14.1)
Часто удобнее выражать текущую стоимость в зависимости от учетной
ставки или дисконта:
П=1/(1+г); ТС (F, D, n)=FDn. (14.2)
(Дополнительную информацию о дисконтировании см. в разд. 14.6.)
14.4. ТЕКУЩАЯ СТОИМОСТЬ СЕРИИ ПОТОКОВ ДЕНЕЖНОЙ НАЛИЧНОСТИ
Используя (14.2), можно получить текущую стоимость ежемесячных аренд-
ных платежей в варианте А1. Каждый из этих платежей равен 1200 долл, и
выплачивается в начале соответствующего месяца (одного из 24). Обозначая те-
кущую стоимость серии потоков денежной наличности через ТСсер, получаем для
первого платежа
ТСсер (1200, D, 1) =ТС (1200, D, 0) = 1200 долл.
После второго платежа
ТСсер (1200, D, 2) = 1200 долл.+ТС (1200, D, 1) = 1200 долл.+ 1200 долл.-О.
В последнем выражении второй член получен из (14.2) для учета появления
потока денежной наличности F (F= 1200), уплаченной через п (п=1) периодов
времени при учетной ставке D.
После третьего платежа
ТСсер (1200, D, 3) = 1200 долл. +1200 долл.-D +1200 долл.-Т)2=
= 1200 долл. (1+D+D2).
Снова была использована формула (14.2) для получения последнего члена в при-
веденном выражении.
Аналогично после 24-го платежа 1
ТСсер(1200, D, 24) = 1200 долл.-(1+П+£>2+ .. +£>23) =
= 1200 долл.-(1— £)24)/(1—D).
1 Используемое тождество доказывается следующим образом:
l + D+0-+. +Р»-.,<‘+Р+№+ _
1 -\Р-|-£>2+ .., + ~1 —О—D2—... —£>т~1 —Dm 1—Dm
1—D = 1— D
189
С помощью таких же рассуждений можно получить общую формулу текущей
стоимости серии из т одинаковых выплачиваемых в начале каждого периода вре-
мени потоков денежной наличности р при учетной ставке D:
ТСсеР(р. D, т) =p(l—Dm)/(l—D' (14.3)
В рассматриваемом примере учетная ставка такова:
0=1/1,0075=0,9925558,
а текущая стоимость серии платежей
ТСсер(1200; 0,9925558; 24) = 1200 долл, - (1 0,9925558-) / (1 —0,9925558) =
= 1200 долл.-0,16417/0,0074442= 26 464 долл.
14.5. ИТОГИ АНАЛИЗА ВАРИАНТОВ АРЕНДЫ И ПОКУПКИ
Ниже подытожены затраты на варианты А1 и А2 для
и анализа по текущей стоимости.
упрощенного анализа
Затраты на А1, долл.
Затраты на А2, долл.
Упрощенный
анализ
28 800
25 000
Анализ по теку
щей стоимости
26 464
29 104
При анализе по текущей стоимости ценность варианта с арендой возрастает,
поскольку отсрочка платежей дает возможность получить дополнительную при-
быль с остающихся денег. В то же время ценность варианта покупки уменьшает-
ся, поскольку такая возможность пропадает. Сопоставление же окончательных
значений затрат приводит к противоположному заключению по сравнению с ре-
зультатом предшествующего упрощенного анализа: более предпочтителен ва-
риант А1.
14.6. СВОДКА ПОНЯТИЙ И ФОРМУЛ ДЛЯ АНАЛИЗА ПО ТЕКУЩЕЙ
СТОИМОСТИ
Стоимость изделия — это наибольшая сумма денег, которую можно полу-
чить за это изделие.
Текущая стоимость некоторой будущей суммы денег (т. е. ечммы, относя-
щейся к определенному будущему времени), или будущего потока денежной'
наличности, — это такая сумма денег в настоящий момент или такой текущий
поток денежной наличности, которые в будущем сравняются (например, за счет
процентных отчислений) с соответствующей будущему моменту суммой.
Текущую стоимость можно нередко выразить через постоянную ставку
процента г за данный период времени. Соответствующая связь между будущей!
суммой денег, или потоком денежной наличности F в конце рассматривав иого
периода, и текущей стоимостью этого потока денежной наличности ТС (F, г)
выражается формулой F=TC(F, г) (I +г) или TC(F, г) =Е/(1+г).
Эта связь часто выражается через учетную ставку О=1/(1+г) следующим
образом: TC(F. r)=FD
Проиллюстрированное выше вычисление текущей стоимости будущих пото-
ков денежной наличности относится к области дисконт1.рования.
Если будущий поз эк денежной наличн сти F появляется через п периодов
времени, а процент добавляется после каждого периода, то текущая стоимость F
определяется по формулам (14.1) или (14.2).
Если полный поток денежной наличности является серией m одинаковых
потоков денежной наличности, или платежей р, появляющихся последовательно
в начале каждого периода времени, и учетная ставка D постоянна, то текущая
стоимость серии платежей такова:
ТСеер(р, D, щ)=р(1— Om)/(1— D).
190
Конечно, понятия, связанные с текущей стоим, стью, вполне согласованы
с п< нлтиями прибыли и предельного анализа, так что можно проводить экономи-
ческий анализ разработки систем на базе таких понятий, как текущая прибыль,
предельная текущая стоимость и т. п.
14.7. ХАРАКТЕРИСТИКА ТЕКУЩЕМ СТОИМОСТИ
Главным достоинством понятия текущей стоимости для принятия решений яв-
ляется обеспечение на его основе согласованной системы приведения потоков
денежной наличности, относящихся к различным моментам времени, к одинаковым
единицам: текущим долларам. Если бы такого приведения не было, сложение и
сравнение текущих и будущих потоков денежной наличности во многом походило
бы на сложение и сравнение яблок и апельсинов.
Предпочтение текущих ресурсов будущим кроется в двух особенностях чело-
веческого характера: во временном предпочтении и в стремлении избежать риска.
Временное предпочтение основано на том, что при более раннем получении ресур
са имеется больше вариантов его использования или, наоборот, при более позд
нем получении ресурса могут быть упущены некоторые прекрасные возможности
его использования Стремление же избежать риска объясняется невозможностью
гарантировать будущую ценность ресурса: деньги могут быть обесценены без
удсржной инфляцией, товары могут упасть в цене из-за перепроизводства и,
кроме того, нельзя гарантировать, что принимающий решение будет в состоянии
использовать эти ресурсы.
14.8. ЧУВСТВИТЕЛЬНОСТЬ К СТАВКЬ ПРОЦЕНТА ИЛИ УЧЕТНОЙ СТАВКЕ
Результаты сравнения по текущей стоимости могут быть очень чувствительны
к ставке процента или учетной ставке. Это можно проиллюстрировать на примере
разработки СОС, для которого на рис. 14.1 показано изменение текущих затрат
на варианты А1 (аренда) и А2 (покупки) в зависимости от ставки процента.
Рис. 14.1 Зависимость текущих затрат от ставки процента
Из рисунка видно, что для нулевой ставки процента справедлив первоначаль-
ный упрощенный анализ, поскольку в нем предполагалось отсу_ствие различий
между текущими и будущими потоками денежной наличности. При очень низких
ставках процента покупка остается предпочтительной вплоть до приблизительно
0,42 % в месяц, или 5 % в год. При ставках же процента выше 5 % в год пред-
почтительной становится аренда.
14.9. ПРИМЕНЕНИЕ В ИНЖЕНЕРНОМ ПРОГРАММИРОВАНИИ
Анализ\по текущей стоимости применяется в инженерном программировании,
славным образом, на фазе анализа осуществимости для сравнения затрат на
ЖЦПО альтернативных систем с целью выбора экономически эффективного спо-
191
соба разработки. Применяемый в таких случаях анализ похож на выполненный
в приведенном примере, возможно, с добавлением дополнительных потоков пла-
тежей на техническое обслуживание аппаратуры, оплату операторов и разработ-
чиков ПО, а также потоков дохода от разработанной системы.
Другая проблема, решение которой требует проведения анализа по текущей
стоимости, состоит в определении сроков покупки ЭВМ для новой системы. (Опре-
деление оптимальных сроков необходимо, поскольку, с одной стороны, слишком
ранняя покупка замораживает большие денежные средства, вкладываемые в ре-
сурс, который будет мало использоваться до фазы кодирования, а с другой сто-
роны, слишком поздняя покупка приводит к росту затрат труда и времени на про-
граммную разработку.) Помимо учета ставок процента принятие подобных реше-
ний может также требовать рассмотрения налогов, отчислений на страхование,
эксплуатацию и сопровождение. Для целей анализа эти факторы часто можно'
объединить в единую составную учетную ставку.
С анализом по текущей стоимости тесно связано определение бюджета
ЖЦПО. Следует учитывать, что довольно часто программные проекты испытыва-
ют на поздних стадиях бюджетные затруднения, так как бюджеты составлялись
с использованием постоянных значений окладов исполнителей, ставок накладных
расходов компании, затрат на покупаемые ресурсы и т. п. Учет роста этих пока-
зателей не относится, строго говоря, к анализу по текущей стоимости, но тесно
с ним связан и особенно важен в длительных проектах, бюджет которых установ-
лен в долларах (а не в человеко-месяцах).
В заключение следует отметить, что существуют ситуации, в которых затраты
на анализ по текущей стоимости не оправданы. Главным образом к ним отно-
сятся случаи сравнительного анализа систем, которые имеют очень похожие рас-
пределения денежных потоков во времени. В подобных случаях различия по ре-
зультатам такого анализа будут соответствовать уровню шумов по сравнению
с влиянием других факторов.
ГЛАВА 15
ПОКАЗАТЕЛИ КАЧЕСТВА
В двух предыдущих главах были введены понятия чистой и
текущей стоимости, положенные в основу объединения функций
затрат и эффективности в единую целевую функцию: чистую теку-
щую стоимость альтернативы в долларах. Однако представление
критерия в долларах часто затруднительно или неоднозначно.
В таких случаях можно прибегнуть к другим методам объединения
нескольких критериев в единый критерий принятия решения, кото-
рый обычно называется показателем качества.
15.1. ПРИМЕР ВЫБОРА ПРОГРАММНОГО ПАКЕТА
В предыдущей главе обсуждение СОС было''завершено принятием решения об
использовании варианта А1 (аренда необходимого числа процессоров на два года
и использование поставляемой изготовителем операционной системы). Предполо-
жим теперь, что изготовитель предлагает на выбор две версии операционной си-
стемы:
стандартную операционную систему А;
систему А ПЛЮС, которая имеет те же технические характеристики, но
обладает лучшими средствами измерения и диагностики и стоит на 5 тыс. долл,
больше. Результаты изучения этих двух вариантов приведены в табл. 15.1.
И снова возникает проблема принятия решения при наличии нескольких
целей. Конечно, лучше всего было бы получить повышение качества бесплатно, но
такая возможность отсутствует. Поэтому необходимо согласовать цель уменьше-
ния затрат с дополнительными целями улучшения качества работы.
192
0.2. анализ по чистой стоимости
Один из способов решения указанной проблемы состоит в оцен-
ке денежных значений всех рейтингов для показателей из
табл. 15.1 и в применении полученных оценок для анализа по чи-
стой стоимости. Существует два основных метода оценивания де-
нежных значений.
1. Значение каждого показателя оценивается по порядку вели-
чины, например «хорошие» диагностические средства принесут за
два года доход 3 тыс. долл., «достаточные» — только 2 тыс. долл.
Подобная оценка обладает преимуществом быстрого получения.
Ее главные недостатки состоят в возможности упущения сущест-
венных факторов и в трудностях обоснования.
2. Анализируются предполагаемая статистика использования
диагностических средств (или других возможностей), сокращение
затрат времени, повышение готовности и производительности, обе-
спечиваемые улучшенными диагностическими средствами, и опре-
деляется соответствующая денежная экономия. Достоинствами
этого метода являются большая гарантия учета всех существен-
ных факторов и лучшее обоснование денежных оценок. Главный
недостаток состоит в значительной трудоемкости такого тщатель-
ного анализа. Ведь разница в затратах на системы А и А ПЛЮС
составляет лишь 5 тыс. Долл. Если же на анализ проблемы выбора
затрачивается более 5 тыс. долл., то ни о какой экономии не может
быть и речи.
Для анализа чистой стоимости необходимо применить один из
указанных методов оценивания. При этом нужно решить неболь-
шую самостоятельную проблему. Как и раньше, когда требовалось
Таблица 15.1
Характеристики альтернативных операционных систем СОС
Показатель Система А Система А ПЛЮС
Дополнительные затраты, тыс. долл. О’ 5
Внутрипроцессорные на- кладные расходы, тыс. долл. 200 200
Межпроцессорные наклад- ные расходы, тыс. долл. 80 80
Средства измерения Плохие Хорошие
Средства трассировки Отсутствуют Достаточные
Диагностика, сообщения об ошибках Достаточные Хорошие
Обеспечение сопровожде- ния Предельно допустимое Хорошее
Система учета Достаточная Очень хорошая
Средства сбора статистиче- ских данных Отсутствуют Хорошие
Документирование Хорошее Достаточное
7 Зак. 62В
193
выбрать между менее дорогой и более эффективной системами,
теперь хотелось бы использовать недорогой и высоконадежный
метод анализа, однако одновременно оба эти качества получить
нельзя. Поэтому необходимо мысленно оценить затраты и выгоды
методов оценивания по порядку величины и детального анализа и
решить, какой метод использовать (рис. 15.1).
i. Проблема выбора метода анализа системы
Меньшие затраты
Большие возможности
Проблема выбора системы
Рис. 15.1. Уровни проблем принятия решений
Меньшие
затраты на
проведение
анализа
Большее
понимание
Однако предварительно следует рассмотреть также возможность'
применения описанного в следующем разделе анализа по показа-
телю качества.
15.3. АНАЛИЗ ПО ПОКАЗАТЕЛЮ КАЧЕСТВА
Другой метод решения проблемы, представленной в разд. 15.1,
заключается в определении безразмерного показателя качества и
выборе варианта с наибольшим значением этого показателя.
Наиболее распространенным методом определения показателя
качества является использование взвешенной суммы. При этом
всем показателям назначаются веса (обычно составляющие в сум-
ме 100), которые учитывают их относительную важность. Затем
для каждого варианта определяются рейтинги всех показателей
194
J* Таблица 15.2
Вычисление показателей качества для вариантов операционной системы СОС
Показатель Вес, % Система Л Система А ПЛЮС
Характеристика Рейтинг Взвешен- ный рейтинт Характеристика Рей- тинг Взвешен- ных рейтинг
Дополнительные затраты, тыс долл. 30 0 10 300 5 4 120
Внутрипроцессорные наклад- ные расходы, тыс. долл. 10 200 3 30 200 3 30
Межпроцессорные накладные расходы, тыс. долл. 15 80 3 45 80 3 45
Средства измерения 7 Плохие 2 14 Хорошие 8 56
Средства трассировки 8 Отсутствуют 0 0 Достаточные 6 48
Диагностика, сообщения об ошибках 10 Достаточные 6 60 Хорошие 8 80
Обеспечение сопровождения 10 Предельно допустимое 4 40 Хорошее 8 80
Система учета 2 Достаточная 6 12 Очень хорошая 10 20
Средства сбора статистики 3 Отсутствуют 0 0 Хорошие 8 24
Документирование 5 Хорошее 8 40 Достаточное 4 20
Всего CD 100 541 523
(обычно по шкале от 0 до 10) в соответствии с их значениями в!
этом варианте.
Результаты применения этого метода для рассматриваемого
примера приведены в табл. 15.2. Согласно данным этой таблицы
нужно было бы отдать предпочтение системе А. Следует, однако,
отметить значительную чувствительность полученного вывода к на-
значенным весам и рейтингам. Так, если бы показателю дополни-
тельных затрат в случае системы А ПЛЮС был приписан рейтинг
5 вместо 4, эта система стала бы более предпочтительной, посколь-
ку соотношение значений показателей качества составило бы 553
и 541 в ее пользу. Или, если бы веса показателей внутрипроцессор-
ных накладных расходов (10) и системы учета (2) поменять места-
ми, что было бы оправдано для некоторых применений, система .4
ПЛЮС стала бы предпочтительнее с соотношением показателей
качества 579 к 565 в ее пользу.
Перечисленные замечания весьма существенны. Они свидетель-
ствуют о невозможности гарантировать абсолютную правильность
проведенного анализа. На данный момент все положительное, что!
можно сказать о таком анализе, сводится к следующему:
подход с использованием взвешенных сумм является четким и
конкретным, позволяет определять наиболее важные веса и рей-
тинги, а также обсуждать и уточнять их;
проведенный конкретный анализ претендует на слишком мно-
гое, особенно при попытке учесть показатель затрат. Возможно,
что более полезной оказалась бы какая-нибудь модификация пре-
дложенного показателя качества.
Имея в виду улучшение показателя качества, обсудим еще один
пример использования взвешенной суммы при выборе крупно-мас-
штабной вычислительной системы, после чего в конце главы вновь
вернемся к примеру СОС, но используя уже усовершенствованный
показатель качества.
15.4. ОБЩИЕ ЗАМЕЧАНИЯ ОБ ИСПОЛЬЗОВАНИИ АНАЛИЗА
ПО ВЗВЕШЕННОЙ СУММЕ ДЛЯ ВЫБОРА ТО И ПО
Приобретение одного из вариантов операционной системы СОС
относится к сравнительно простому случаю проблем принятия ре-
шений, часто встречающихся при выборе вычислительной системы
или программного пакета. В таких ситуациях обычно требуется
сравнить сложные системы с большим числом возможностей и ат-
рибутов, многие из которых трудно оценить по важности для дан-
ного предприятия.
Метод взвешенных сумм довольно хорошо подходит для реше-
ния подобного рода проблем. В [65] рекомендуется использовать
этот метод для оценивания относительных достоинств ориентиро-
ванных на некоторые определенные приложения систем управления
базами данных. В частности, в указанной работе рекомендуются
методы иерархических взвешенных сумм (см. также [95, 127]).
Фактически метод взвешенных сумм был предложен гораздо рань-1
196
me появления указанных работ, он использовался при выборе ЭВМ
уже в середине 60-х годов. Пример использования обсуждается
ниже в качестве иллюстрации некоторых аспектов применения
взвешенных сумм. Обсуждение конкретного примера даст также
представление о числе и типах показателей, используемых при вы-
боре большой аппаратно-программной системы.
15.5. ОПИСАНИЕ ПРОЦЕДУРЫ ВЫБОРА ЭВМ
Цель процедуры состояла в выборе мощной вычислительной
системы для замены IBM 7040/7044. Эта система применялась для
решения научно-исследовательских задач, а также для обработки
текстов и управления предприятием. Около 70% решаемых задач
программировались на Фортране, примерно 25%—на языке
ассемблера, а остальные — на Коболе и Симскрипте. Приблизи-
тельно 75% решались за менее чем 5 мин, а среднее время счета
задачи составляло 3,5 мин. Для небольших диалоговых задач ис-
пользовалась отдельная система. Основная цель приобретения
новой вычислительной системы состояла в расширении возможно-
стей вспомогательного ПО и увеличения производительности ЭВМ
при ее использовании специалистами-профессионалами. Требова-
лось также обеспечить увеличение мощности вычислительной си-
стемы без значительных затрат.
Для обоснования выбора была определена детальная и всесто-
ронняя иерархия показателей, которая приведена в табл 15.3 вме-
Таблица 15.3
Иерархия показателей для оценки вычислительной системы
(веса приводятся слева)_
0,27 I. Техническое обеспечение
0,07 А. Модульность системы 1 Центральные процессоры (ЦП) 2. Память 3. Ввод-вывод 4. Периферия
0,08 Б. Характеристики семейства ЭВМ 0,10 1. Число типов ЭВМ в семействе 0,34 2. Диапазон быстродействия ЦП 0,43 -3. Диапазон объемов памяти 0,13 4. Периферийные устройства
0,20 В. Центральные процессоры 0,15 1. Максимальное число 0,49 2. Быстродействие 0,19 3. Универсальность системы команд 0,09 4. Обработка прерываний 0,04 5. Таймеры и часы 0,04 6. Аппаратный контроль
0,14 Г. Оперативная память 0,50 1. Цикл обращения 0,23 2. Длина и форматы слова 0,23 3. Средства защиты 0,04 4. Аппаратный контроль
0,03 Д. Техническое обеспечение разделения времени 1. Быстродействие 2 Схема адресации
197
Продолжение табл. 153
0,05 Е. Набор символов
0,45 1. Внутренний код
0,55 2. Внешнее преставление (на устройствах подготовки ц
отображения данных)
0,11 Ж. Устройства ввода-вывода (каналы)
0.20 1 Степень независимости
0,25 2. Скорости передачи
0,04 3. Максимальное число
0,08 4. Максимальное число интерфейсов
0,05 5. Объемы буферной памяти
0,18 6. Схемы приоритетов и обработка прерываний
0,14 7. Гибкость назначения
0,05 '8. Программное управление
0,05 3. Интерфейсы (устройства управления)
1. Число контроллеров на интерфейс
2. Число устройств на интерфейс
3. Скорости передачи
4. Степень независимости
5. Гибкость назначения
6. Программное управление
0,15 И. Внешние запоминающие устройства 0,05 1. Сверхбыстродействие (магнитные сердечники) 0,40 2. Высокое быстродействие 0,25 3. Среднее быстродействие 0,'15 4. Память большого объема 0,15 5 Память на магнитных лентах
0,06 К. Устройства ввода-вывода 0,18 1. Перфокарточное оборудование 0,36 2. Печатающие устройства 0,04 3. Перфоленточное оборудование 0,24 4. Дисплеи 0,18 5. Телетайпы
0,06 Л. Мультиплексоры связи 1. Управление передачей данных и коммутацией 2. Число устройств 3. Скорости передачи 4. Интерфейсы каналов связи
0,27 II. Супервизор
0,58 А. Функции 0,13 1. Интерпретация языка управления заданиями 0,17 2. Планирование выполнения задач 0,07 3. Обработка прерываний 0,16 4. Распределение памяти 0,08 5. Мультипроцессирование 0,14 6. Защита программ и данных 0,05 7. Механизмы обнаружения сбоев 0,10 8. Анализ функционирования и ведение учета 0,05 9. Обеспечение отладки 0,03 10. Взаимодействие системы с оператором 0,02 И. Начальная загрузка и остановка
о,п Б. Простота исправления 0,65 1 Модульность
0,35 2. Средства редактирования
0,12 В. Надежность
0,16 Г. Простота использования 0,40 1. Язык управления заданиями 0,20 2. Ясность ответных сообщений 0,40 3. Виртуальная память
0,03 Д. Требования к техническому обеспечению
198
Продолжение табл. 15.3
0 08 III. Управление данными
0,66 А Управление файлами 0,20 1. Операции над файлами 0,13 2. Надежность и средства восстановления 0,20 3. Защита данных 0,16 4. Использование памяти 0,16 5. Структура файлов 0,15 6. Комплексирование с операционной системой 0,21 Б. Операции над данными 1. Состав операций 2. Типы доступа к элементам 0,13 В Физический ввод-вывод
0,16 IV. Языковые процессоры 0,58 А. Фортран 0,18 1. Эффективность компилятора 0,27 2. Эффективность объектного кода 0,10 3. Соответствие стандарту 0,08 4. Надежность 0,08 5. Средства отладки 0,14 6. Реентерабельность 0,10 7. Сообщения и диагностика О.«5 8. Совместимость с другими диалектами 0,10 Б. ПЛ,л1 (рассматриваются пункты из А) 0,04 В. Кобол (рассматриваются пункты из А) 0,15 Г. Ассемблер (рассматриваются пункты из А) 0,08 Д Симскрипт (рассматриваются пункты из А) 0,05 Е. Совместимое! D языков 0,40 1. Связь подпрограмм 0,40 2. Связь по данным 0,20 3. Совместимость на уровне загрузки
0,02 V. Вспомогательное ПО общего назначения 0,15 А. Библиотека 1. Распространенность 2. Доступность системному процессору . 3. Совместимость с языками 4. Реентерабельность 0,35 Б. Пакет прикладных программ (рассматриваются пункты из А) 0,45 В. Прикладные подпрограммы (линейное программирование, сор- тировка и слияние и т п) (рассматриваются пункты из А) 0,05 Г. Сервисные программы (рассматриваются пункты из А)
0,12 VI. Возможность переноса 0,65 А. Возможность использования языков прежней ЭВМ 0,70 1. Машинный и ассемблерный языки 0,20 2. Фортран, степень совместимости 0,05 3. Симскрипт, степень совместимости 0,05 4. Язык управления заданиями, степень совместимости 0,15 Б. Файлы данных 1. Длина слова 2. Набор символов и их упорядочение 3. Физические и логические форматы на ленте 0.20 В. Содействие поставщик а 0,40 1. Пре. (оставление машинного времени ‘1,40 2. Выделение персонала 0,20 3. Обучение персонала
0.08 VII. Поддержка поставщиком вычислительной системы 0,20 А. Надежность и репутация в целом 0,13 1. Число, заявленн! IX и поставленных ЭВМ
I
199
Окончание табл. 13
0,19 2. Данные о поставках
0,31 3. Удовлетворенность заказчика
0,23 4. Надежность ТО и ПО, сост зяние на момент оценивая,
0,1'4 5. Продолжительность специализации в данной области
0,10 Б. Технология
0,60 1. Новизна и прогнозируемый срок морального старения
0,20 2 Прогнозируемое расширение семейства
0,20 3. Элементная база
0,10 В. Процедуры сопровождения
1. ТО
2. ПО
0,25 Г. Непрерывность поддержки
1. Обеспеченность персоналом
2. Наличие экспертов
0,25 Д. Документация
0,80 1. Качество и читабельность руководств
0,20 2. Доступность руководств и схем
0,10 Е. Эффективность группы обслуживания
0,40 1. Обмен информацией
0,30 2. Обмен программами
0,15 3. Контроль изготовителем
0,15 4. Готовность изготовителя к сотрудничеству
сте с соответствующими весами. Интересно отметить, что уже в
1965—1966 гг. даже в научно-исследовательских ВЦ вес ТО состав-
лял только 27%, а ПО — 63% полного веса. Остальные 10% прихо-
дились на поддержание вычислительной системы поставщиком. По
указанным в таблице показателям были оценены IBM 7040/7044
(существующая система), IBM 360/67 — TSS, IBM 360/65 — OS,
Univac 1108, CDC 6400 и GE 635. Эти вычислительные системы!
обладали приблизительно одинаковой ценой, и поэтому в прово-
димом выборе затраты на приобретение не были главным показа-
телем.
Каждая из указанных альтернативных систем была оценена по
всем показателям табл. 15.3 с использованием шкалы рейтингов от!
0 до 10. Детальному анализу предложений поставщиков было от-
дано несколько человеко-месяцев. Некоторые результаты оценки
приведены в табл. 15.4.
Все рейтинги были умножены на веса, соответствующие их ме-
сту в иерархической системе показателей, а результаты были про-1
суммированы для получения общей оценки каждой альтернативы.I
Результаты вычисления взвешенных сумм приведены в табл. 15.5.
Самые высокие оценки получили IBM 360/67 и Univac 1108. Эти!
системы были подвергнуты дальнейшему анализу, по итогам кото-
рого была выбрана и заказана для покупки IBM 360/67.
15.6. ПРОБЛЕМЫ ИСПОЛЬЗОВАНИЯ ОЦЕНОЧНОЙ ФУНКЦИИ
Через несколько месяцев было обнаружено, что операционная
система IBM 360/67, первая серийная операционная система для
работы с виртуальной памятью, требовала при своей работе боль-
200
Таблица 15.4
Некоторые результаты оценивания ПО вычислительных систем
раздел из табл» Вес' IBM CD& GE IBM IBM UNIVAC
15.3. 7040/7044 6400 635 360/65 360/67 1108
II 21 3.67 4.91 5.44 4.58 6.80 6.64
А .58 2.64 4.33 5.35 .4.46 7.54 7.42
1 .13 4 3 41 6 8 8
2 .17 1 4 5 5- 7 8
3 .07 6 5 6 6 6 7
4 .16 1 5 5 4 81 71
5 .08 0 0 7 0 8 8
6 .14 3 8 7 5 8 8
7 .05 3 4 3 3 7 8
8 .10 3 3 5 3 7 6-
9 .05 3 3 4 6 8 5
10 .03 6 6 6 6 6 6
11 .02 5 в 6 7 7 7
Б .11 5 35 7.30 6.00 6.35 6.00 7.00
1 .65 5 8 6 6 6 7
2 .35 6 6 6 7 6 7
В .12 6 - 7 8 5 4 6
Г .16 2.60 3.20 3.20 3.20 7.00 4.00
1 .40 5 5 5 5 В 7
2 .20 3 6 6 6 7 6
3 .40 0 0 0 0 6 О
Д .03 .6 В 7 6 51 7
III .08 3.02 2.62 3.46 5.43 6.47 6.33
А .66 2.19 2.22 2.66 4.В1 6.08 5.86
1 .20 2 3 2 7 7 5
2 •13 0 0 0 t 2 2
3 .20 2 2 2 41 8 61
4 .16 0 0 1 4 5 7
5 .16 4 2 5 7 7 8
6 .15 5 6 6 5 6 6
Б .21 6 3 5 7 В 8
В .13 4 4 5 6 6 6
IV .18 3.40 3.23 4.61 4.86 5.22 626
А .58 332 3.11 4.20 4.52 5.29 7.42
1 .1В 2 6 4 5 51 9
2 .27 3 3 5 4 41 81
3 .10 51 4 61 .7 7 В
4 .08 9 4 5 5 4 7
5 .08 6 0 6 6 6 6
6 .14 0 0 0 4 7 4
7 .10 4 5 6 4 6 8
8 /15 0 0 0 0 0 6
Б В .10 .04 0 4.17 0 4.81 4} 4.17 6 4.89 6 4.89 2 5.4В
1 .18 6 6 6 6 6 6
2 .26 6 6 6 6 6 6
3 .11 6 7 6 6 6 7
I
201
Окончание табл. 15
Раздел из табл. 15.3 Вес IBM 7040/7044 СОС 6400 GE 635 IBM 360/65 IBM 360/67 UNIVAC 1108
4 .09 6 3 6 6 6 7
5 .09 0 4 0 8 8 5
6 .16 0 0 0 0 0 0
7 .11 3 7 3 3 3 9
8 —— —- — •— — — ——
Г .15 5.47 4.03 5.25 5.98 7.22 5.85
1 .60 6 5 6 7 8 7
2 — — — — — — ——
3 — —— — — — —.
4 .11 9 5 7 6 5 7
5 .08 5 0 5 8 6 5
6 .13 О 0 0 0 7 0
7 ,08 6 6 6 6 6 6
8 W—« — — — — — —
д .08 2.79 4.30 6.34 3.31 0.00 4.30
1 .18 2 6 8 4 0 6
2 .26 2. 6 8 4 о 6
3 .11 5 6 в 5 0 6
4 .09 9 5 7 5 0 5
5 .09 0 0 6 0 0 0
6 .16 0 0 0 0 О 0
7 .11 ~ 5 5 7 5 0 5
В —— <=— -— — — — —
Е .05 5.20 5.60 5.20 5.60 5.60 6.40
1 .40 5 6 5 5 5 6
2 .40 4 5 4 5 5 6 1
3 .20 8 6 8 в в 8
Таблица 15.5
Итоговые оценки (взвешенные средние)
Раздел из табл. 15.3 IBM 7040/7044 СОС 6400 GE 635 IBM 360/65 IBM 360/67 UNIVAC 1108 Вес
1 3.81 5.79 5.75 6.40 7.08 6.87 027
II 3.67 4.91 5.44 4.58 6.80 6.64 027
III 3.02 2.62 3.46 5.43 6.47 6.33 0.08
IV 3.40 3.23 4.61 4.86 5.22 6.26 0.16
V 6.58 4.73 5.38 7.55 6.53 7.85 002
VI 10.00 2.94 7.51 6.61 5.86 4.00 0 12
VII 6.57 4.69 5.86 6.50 6.30 5.98 0.08
Всего 4.66 4.44 5.51 5 64 6.44 627 1.00
ших накладных расходов. Как правило, эта система предоставл»
ла пользователям лишь 10.. .15% выполняемых на ЭВМ операций
Безусловно, это сделано неприемлемым применение IBjV
360/67 и было запланировано выбрать и заказать другую ЭВМ-
Удивительно, что введение новой информации о недостатках one
рационной системы в модель оценки по взвешенной сумме не при
202
вело к заметному уменьшению оценки этой ЭВМ. В самом деле, в
иерархии показателей лишь один из них учитывает характеристи-
ки операционной системы. Это показатель из п. 2.Д (Супервизор.
Требования к ТО) с полным весом 0.0081 (0,27 0,03 =0,0081). На-
значение этому показателю даже нулевого рейтинга уменьшило
полную оценку менее чем на 1%, так что вычислительная система
IBM 360/67 по-прежнему получила наибольшую оценку.
Что явилось причиной неверных результатов анализа по пока-
зателю качества и как можно было бы улучшить этот анализ?
Можно дать два различных объяснения, которые приводят к двум
основным направления улучшения.
1 . Использовался неудачный набор показателей и весов. Так,
если реальная производительность была критическим показателем,
то ее следовало бы выделить в качестве высокоуровневого показа-
теля с большим весом *.
2 Использовалась аддитивная целевая функция при наличии
показателя (накладные расходы операционной системы), влияние
которого на работу было мультипликативным. Действительно,
низкая производительность ухудшает все возможности системы в
одинаковое число раз. Поэтому для учета такой ситуации следует
использовать мультипликативную (по соответствующему показа-
телю) целевую функцию.
Целесообразной мерой в случае первого объяснения является
совершенствование метода взвешенной суммы путем определения
более характерного для рассматриваемой ситуации набора показа-
телей и весов. В случае же второго объяснения целесообразной
мерой для учета неаддитивных характеристик производительности
системы явилась бы модификация показателя качества.
Обе меры имеют свои достоинства. Так, первая, сохраняет про
стоту метода взвешенных сумм. Вторая же мера приводит к исполь-
зованию более сложного показателя качества, который, однако,
точнее учитывает поведение системы.
После обсуждения результатов анализа рассматриваемого кон-
кретного примера будет представлен показатель качества, учиты-
вающий вторую из приведенных мер и называемый реальной про-
изводительностью системы. Затем будет проведено сравнение этого
показателя с показателем взвешенной суммы.
1S.7. ПРОБЛЕМЫ ОПРЕДЕЛЕНИЯ ВЕСОВ И РЕЙТИНГОВ
Другие проблемы оценки были связаны с относительными веса-
ми показателей и шкалами рейтингов. Вначале была сделана по-
пытка определения весов на основе предложений различных групп
1 В [130] особо подчеркивается, что взвешенную сумму наиболее эффективно
Можно использовать для оценки относительных достоинств приемлемых альтерна-
тив Это подразумевает исключение из рассмотрения «патологических> альтерна-
тив, у которых рейтинги чрезвычайно высоки либо совершенно неприемлемы. Это
фактически является одной из форм обсуждаемого в следующей главе подхода
к трактовке целей как ограничений.
203
пользователей вычислительной системы. Одна из возникших при
этом проблем вызывалась стремлением некоторых специализиро-
ванных групп (например, занимающихся большими производст-
венными задачами, для которых гораздо важнее производитель-
ность аппаратуры, чем программные средства) придавать чрезмер-
но высокие веса конкретным показателям, представляющим для
них особый интерес, с целью увеличения их значимости при
оценке.
Эта проблема была достаточно хорошо разрешена в результате
нескольких индивидуальных обсуждений с представителями спе-
циализированных групп, в ходе которых были выявлены и обосно-
ваны веса и сформулированы в заключении их предложения.
10 -г* Отличный
9— Очень хороший
10 -Отличный
9- -
7- - Хороший
5— Достаточный
3- - Предельный
7- - Очень хороший
- - Хороший
5- - Достаточный
- - Предельный
3- - Неудовлетворительный
1- -Неудовлетворительный
0 -L Отсутствие
а)
0-L Отсутствие
б)
Рис. 15.2. Шкалы рейтингов:
а — показателей А; б — показателей Б
Другая проблема явилась следствием первоначального предпо-
ложения об отсутствии в будущем какой-либо собственной про-
граммой поддержки новой системы. Это предположение было не-
реалистичным и привело к завышению весов показателей ПО и
участия в поддержке поставщиков. Оно было затем пересмотрено
в сторону учета небольшой (3—5 сотрудников) штатной группы
программной поддержки, в результате чего эти веса уменьшились.
Проблема определения рейтингов состояла в трудности получе-
ния согласованной шкалы. Так, для некоторых показателей шкала
рейтингов выглядела, как на рис. 15.2, а, для других — как на
рис. 15.2, б. Результат же фактически заключается в среднем в
двукратном увеличении веса каждого показателя на рис. 15.2, а
по сравнению с весом показателя на рис. 15.2, б.
Эта проблема в значительной степени решена посредством не-
зависимого анализа и доработки оценочной шкалы. Было также
204
проанализир< >вано, насколько выводы чувствительны к весам и
рейтингам. В процессе этого анализа подавляющее преобладание
рейтингов для IBM 360/67 и 1108 нарушалось лишь в очень редких
случаях *.
15.8. ИТОГИ
Обсужденные выше проблемы показывают важность учета ус-
ловий использования взвешенной суммы з качестве показателя ка
чества и способы ее адаптации к конкретным случаям. Но они не
должны служить причиной полного отказа от применения показа-
телей качества. Довольно часто, особенно в случаях со столь же
большим числом частных показателей, которое встречается при
выборе сложного программно-аппаратного изделия, метод иерар-
хических взвешенных сумм оказывается весьма полезным. Этот
метод обеспечивает достаточно хорошую основу для обсуждения
приоритетов, сбора оценочных данных, рассмотрения субъектив-
ных факторов, а также для представления, обсуждения и уточне-
ния результатов оценивания1 2.
Другие показатели качества. Можно считать, что любое урав-
нение производительности задает формулу вычисления значений
некоторого показателя качества. Например формула (10.1) задает
более предпочтительный показатель качества работы рассматри-
ваемой многопроцессорной СОС, чем любая формула вида
/7(77, S, Р, М, Г) oq 4- Oj/V 4- a%S 4- G3 Р 4- аДЛ 4- а$Т.
Не существует универсального показателя качества для всего
диапазона проблем принятия решений в инженерном программи-
ровании 3,- Каждый показатель качества должен быть ориентирован
на конкретные применение и цель, для достижения которой он не-
обходим. Один такой показатель, реальная эффективность систе-
мы, дающий хорошие результаты для нескольких классов задач
оценивания вычислительных систем, приводится ниже.
1 Следовательно, выводы не очень чувствительны к точности шкалы рей-
тингов. — Прим, перев.
2 Автор книги [167] решительно выступает в пользу анализа по чистой стои-
мости (называемого им анализом по стоимости и затратам) и против анализа по
показателям качества. В указанной книге представлены способы определения
Денежных показателей. В ней также приводится достаточный набор процедур и ре-
комендаций по выбору ЭВМ. Однако там не рассматриваются подробно програм-
мные аспекты выбора вычислительной системы, включенные в табл. 15.3. В то же
время программные показатели обычно не менее важны, чем аппаратные, и гораздо
труднее поддаются оценке в денежных единицах. Поэтому для учета подобных
показателей при поиске решения необходимы такие методы, как анализ по взве
Шенной сумме.
3 Такое же заключение было получено и в случае использования других уни-
версальных показателей качества, например, предложенных для оценки качества
ПО в [42].
205
15.9. РЕАЛЬНАЯ ЭФФЕКТИВНОСТЬ СИСТЕМЫ КАК ПОКАЗАТЕЛЬ
КАЧЕСТВА
Определения. Реальная эффективность системы (РЭС) зада
ется мультипликативной функцией:
РЭС = (Качество системы; - (Реальная производитель-
ность) - (Готовность) -= КС-РП-ГОТ. (15.1) 9
Определим использованные термины следующим образом:
Качество сис^еуы — иерархическая взвешенная сумма рейтин-
гов отдельных показателей
SWifi, (15 2)
где-а1; — вес, а г, — рейтинг t-ro показателя конкретной альтерна-
тивы. Сумма всех w{ должна быть равна 1,0, а рейтинги должны]
принимать значения от 0,0 до 1,0.
Реальная производительность — фактическая производитель-
ность, которая может быть использована для обеспечения желае-|
мых возможностей. При этом подразумевается, что для получения!
РП необходимо из полной производительности ЭВМ вычесть такие |
величины, как накладные расходы операционной системы.
Готовность доля времени, в течение которого вычислительная!
система может выполнять возложенные на нее функции. Следова-1
тельно, при определений ГОТ должно исключаться время, затра-1
чиваемое на профилактическое обслуживание или на пребывание
системы в неисправном состоянии.
1S.10. СВОЙСТВА ПОКАЗАТЕЛЯ РЭС
1. Реальная эффективность системы по существу является без-
размерным показателем качества, так как входящие в КС веса и
рейтинги не имеют физической или экономической значимости.
2. Этот показатель относится только к производительности и
должен быть еще согласован с затратами. Включение же затрат
в показатель качества требовало бы выражения РЭС в долларах,]
что невозможно из-за безразмерности РЭС. Кроме того, при по-
добном включении анализ по РЭС превратился бы в анализ но
чистой стоимости.
3. Компонент КС позволяет использовать преимущества иерар-
хических взвешенных сумм там, где эти преимущества особенно
необходимы: для согласования значительного числа показателей,
с трудом выражаемых количественно (например, показателей из I
табл. 15.3).
4. Компоненты РП и ГОТ позволяют устранить трудности при-^
менения взвешенных сумм учетом мультипликативного влияния
реальных производительности и готовности. Мультипликативные
компоненты ГП и ГОТ можно гычислить любым удобным спосо-
бом, например используя формулы типа (10.1) для вычисления
реальной производительности СОС. Трактовку этих компонент
можно также расширить для охвата и других частей системы, на-
пример исполнителей, связи и т. п.
206
К.11. ПОВТОРНЫЙ АНАЛИЗ ПРИМЕРА ВЫБОРА СОС
Вернемся к проблеме выбора операционной системы СОС сре-
ди систем А или А ПЛЮС, используя анализ по РЭС. Вначале
рассмотрим затраты отдельно и попытаемся оценить влияние, ока-
зываемое на затраты характеристиками системы А ПЛЮС
(табл. 15.6), полагая, что издержки на сопровождение на два года
равны 30 тыс. дочл (в соответствии с данными разд. 9.4 издерж-
ки на сопровождение составляют приблизительно 15 тыс. долл./
год).
Таблица 15.6
Затраты на систему Система А Система А ПЛЮС
Основная стоимость, тыс. долл. 130 135
Обеспечение сопровождения (10% от 30 тыс. долл.) 0 —3
Диагностика и сообщения об ошибках (5% от 30 тыс. долл.) 0 —1,5
Документация (5% от 30 тыс. долл.) 0 1,5
Всего, тыс. долл. 130 132
Теперь рассмотрим отдельно реальные производительность и
готовность и снова попытаемся оценить влияние улучшенных ха-
рактеристик системы А ПЛЮС (табл. 15.7).
Таблица 15.7
Характеристика Система А Система А ПЛЮС
Реальная производите..ьность (3%-ное увеличение из-за средств измерения), сообщ./с Готовность (50%-ное уменьшение из-за 120,0 . 123,6
неисправностей) 0,95 0,975
На следующем шаге анализа включим те функциональные воз
можности, которые не былч полностью охвачены ранее во взвешен-
ной сумме, учитывая и основные операции обработки сообщений
(табл. 15.8).
Окончательные результаты представлены в табл. 15.9. Приве-
денные данные» недвусмысленно свидетельствуют о предпочтитель-
ности системы А ПЛЮС и довольно четко обосновывают выбор
этой системы, особенно по сравнению с выбором в разд. 15.3 по
Данным табл. 15.2.
207
Таблица 15.8
Показатель Вес Система А Систола А ПЛЮС
Рейтинг Взвешен- ный рейтинг Рейтинг Взвешен- ный рейтинг
Функции ПРС 0,95 1 0 0,950 1,0 0,950 '
Система учета 0,01 0,6 0,006 1,0 0,010
Статистика 0,01 0,0 0,000 0,8 0,008
Документиро- вание 0,03 0,8 0,024 0,4 0,012
Всего 1,00 0,980 0,980
Таблица 15.9
Сравнение вариантов операционной системы для СОС
Показатель Значение
Система А Система А ПЛЮС
Качество системы Реальная производительность, сообщ./с Готовность Реальная эффективность системы, сообщ/с, РЭС=КС-РП ГОТ Затраты, тыс. долл. 0,980 2С 0,9-5 111,7 130 0,980 123,6 0,975 118,1 132
15.12. СРАВНЕНИЕ ПОКАЗАТЕЛЕЙ ВЗВЕШЕННОЙ СУММЫ И РЭС
Для СОС анализ по РЭС безусловно позволил осознать про-
блему принятия решения лучше, чем анализ по взвешенной сумм?
(см. табл. 15.2). Однако прежде чем заключить, что так и должно
было случиться, следует вспомнить замечание из приведенного ра-
нее обсуждения анализа конкретного примера выбора ЭВМ о
существовании еще одного способа совершенствования неудовле-1
творительного показателя взвешенной суммы путем определения
более характерного для конкретной ситуации набора показателей
и весов.
В случае СОС оказывается, что анализ по РЭС позволяет'
определить более подходящий набор показателей и весов для взве- I
шенной суммы. Например, если использовать качество системы, ре-
альную производительность и готовность в качестве показателей I
с примерно одинаковыми весами, приходим к анализу по взвешен-1
ной сумме, иллюстрированному табл. 15.10.
При использовании приведенных в табл. 15 10 показателей и
весов взвешенная сумма позволяет примерно столь же хорошо, как I
и РЭС, разобраться в проблеме принятия решения в случае СОС. ,
В цанной ситуации это является следствием приблизительно одина- I
ковой относительной значимости реальной производительности и '
готовности Если бы альтернативные системы существенно разли-1
208
таблица 15.10
Пересмотренный анализ СОС по взвешенной сумме
Показателе Вес Система А Система А ПЛЮС
Значение Рейтинг 5= я " к « 3 s Дкн Значение Рейтинг «о*3 Я ф □ Л QJ _ « 3 х CQ х н
Качество системы 40 0,980 9 360 0,980 9 360
реальная производительность, Сообщ./с 30 120,0 8 240 123,6 9 270
Готовность 30 0.950 7 210 0,975 9 270
Всего 100 810 900
чались по этим показателям, то применение взвешенной суммы
было бы более затруднительным.
В то же время взвешенная сумма позволяет лучше учитывать
побочные эффекты реальной производительности и готовности.
Например, для большого банка, в котором от готовности вычисли-
тельной системы обрабатывать сообщения о финансовых операци-
ях зависит начисление ежедневных процентов на сумму почти в
1 млн. долл., различие между ГОТ=1,00 и ГОТ=0,99 гораздо
больше, чем 1% в реальной эффективности системы. Анализ же по
взвешенной сумме позволяет оценивать это различие с учетом
весов и рейтингов.
В табл. 15.11 приведены главные достоинства показателей
взвешенной суммы и РЭС и рекомендации по их использованию, на
основе которых можно сформулировать следующее правило выбо-
ра предпочтительного показателя качества:
если оцениваемые системы сильно различаются по РП и ГОТ,
то следует использовать РЭС. В противном случае нужно обра-
титься к анализу по взвешенной сумме.
Заключительные замечания. Методы анализа по взвешенной
сумме и РЭС исключительно полезны при выборе вычислительной
системы или сложного программного пакета, когда необходимо
Таблица 15.11
Сопоставление показателей взвешенной суммы и РЭС
Показатель Взвешенная сумма Реальная эффективность системы
Относительные досто- инства РекомеНдацИИ Простота Учет побочных эффектов, РП, ГОТ Использовать при незначи- тельных различиях по РП, ГОТ Применимость для многих вычислительных систем Учет больших различий по РП, ГОТ Использовать при больших различиях по РП, ГОТ
209
учесть большое число (более 20) показателей, трудно поддающих]
ся количественной характеристике. Однако необходим^ по-прежн>
му быть готовым к возможности отсутствия удовлетворительного
способа объединения всех имеющихся показателей в единый прц.
емлемый показатель качества В таких случаях можно попытаться
использовать два подхода к оцениванию, которые изложены в
гл. 16—18.
ГЛАВА 16
ЦЕЛИ В КАЧЕСТВЕ ОГРАНИЧЕНИЙ
16.1. ПРИМЕР СОС С ОТКАЗАМИ
Рассмотрим опять пример СОС двухлетняя аренда нескольких процессоров
работающих со штатной поставляемой операционной системой А ПЛЮС в рас-<
ширенном варианте. Допустим, что в процессе эксплуатации обнаруживается
неприятный дефект операционной системы при выходе из с? эоя любого процес-
сора останавливается вся система, а для восстановления ее работоспособности
с остальными процессорами требуется в среднем 30 мин. Кроме того, обнаружи-
вается, что надежность каждого процессора составляет 99 % в час. Это озна-
чает, что каждый процессор с вероятностью 0,99 сохраняет свою работоспособ-]
ность в течение любого заданного часа.
16.2. НАДЕЖНОСТЬ И ГОТОВНОСТЬ СИСТЕМЫ
Надежность НАД (А) системы с N процессорами в единицу времени (час)
определяется вероятностью того, что вся система не выйдет из строя за заданный
час. Поскольку в рассматриваемом случае система выходит из строя при отказе
любого из процессоров, то НАД (N) равна вероятности выхода из строя любого
процессора за заданный час. Эта вероятность равна произведению надежностей
всех процессоров:
НАД (А) = (0,99)*. (161)
Тогда готовность системы (доля времени, в течение которого система рабо-
тоспособна) может быть вычислена по формуле
ГОТ (А) = 1—(Доля времени отказа системы) =
(Вер, отказа в ед, времени) • (Ср. время восст)_
Единица времени
_ ( _П—НАД(А)]-30 мин
60 мин
Рис. 16.1. Надежность, готовность и производительность СОС
210
ИЛИ
ГОТ (1V) = 1—0,5(1—0,99"). (16.2)
Графики надежности и готовности системы как функции числа процессоров
доказаны на рис. 16 1. На ней приведена также функция производительности
fl (/V) в единицах сообщ./с.
16.3. ОЦЕНКА ПОКАЗАТЕЛЯ КАЧЕСТВА
Из рис. 16.1 видно, что с приобретением большего числа процессоров произ-
водительность системы повышается, а надежность и готовность падают. Для вы-
бора числа покупаемых процессоров необходимо согласовать требования к про-
изводительности с показателями надежность — готовность.
Одним из возможных путей решения этой задачи является подход, основы-
вающийся на оценке РЭС. Функция обработки сообщений не зависит от числа про-
цессоров N, поэтому примем, что качество системы (КС) является константой,
а для удобства положим КС =1,0. Для получения реальной производительности
РП воспользуемся уравнением (10.1) или рис. 10.2, а для получения готовности
ГОТ — уравнением (16.1). Например, для Л?=3 получим
РЭС (3) = 1,0-Д (З)-ГОТ (3)= 96-0,985=94,6 сообщ./с.
График функции РЭС (N) показан на рис. 16.2. По РЭС-критерию наилучшая
система должна иметь пять процессоров. Тем не менее РЭС не всегда является
удовлетворительным критерием для оценки СОС, если дело касается требования
высокой готовности СОС.
Рис. 16.2. Зависимость РЭС от числа процессоров
Во многих случаях цена прерывания обслуживания пользователей СОС зна-
чительно выше цены снижения скорости обслуживания. Например, если СОС
является системой резервирования авиабилетов, эта цена окажется намного выше
из-за потери постоянных клиентов и подрыву репутации аэрофлота как надежной
организации, которой мы вручаем свою судьбу во время полета. Или, если СОС
является системой обслуживания вызовов (полиции, пожарных, скорой помощи),
Чена должна возрастать с увеличением вероятности потери жизни человека.
Так, хбтя критерий РЭС эффективен при выборе ЭВМ общего назначения,
пакетов прикладных программ и большинства случаев работы в пакетном режи-
ме, для многих систем обработки сообщений такая трактовка готовности является
не совсем удовлетворительной. В некоторых случаях применения СОС можно
было бы назначить некоторую денежную компенсацию пользователю (например,
каждое прерывание обслуживания СОС обходится фирме в 1000 долл, за мину-
ТУ), затем, как и раньше, провести анализ по чистой прибыли. Однако во многих
случаях, в особенности касающихся жизни человека, ни анализ по чистой при-
были, ни график для РЭС не будут удовлетворительны для всего спектра рассмат-
риваемых проблем.
211
16.4. ВЫРАЖЕНИЕ ЦЕЛЕЙ В КАЧЕСТВЕ ОГРАНИЧЕНИЙ
Другой путь согласования целей готовности, стоимости и производительное^
для СОС состоит в постановке следующей задачи:
Выбрать систему с готовностью не менее чем 0,98. Определить такое число
процессоров N, чтобы система имела максимальную производительность П (JVJ
при условии, что ее готовность ГОТ (N) не ниже 0,98. Таким образом, цель
готовности выступает как ограничение. Из рис. 16.1 видно, что для решения
задачи должно быть выбрано четыре процессора. Это обеспечивает минимальную
приемлемую готовность 0,98 и производительность 112 сообщ./с. При таком под.
ходе любой показатель можно рассматривать как ограничение.
К примеру, можно поставить и такую задачу:
Выбрать систему с достижимой производительностью, не меньшей чем
90 сообщ.[с. Определить N, обеспечивающее максимальную готовность при
П (77)5=90 сообщ./с. Из рис. 16.1 видно, что при этом требовании надо выбрать
7V=3 процессора с производительностью 96 сообщ./с и готовностью 0,985.
В инженерном программировании ограничения могут быть заданы независи-
мо, как в приведенных выше примерах с готовностью и производительностью,
либо могут быть предопределены другими условиями, например особенностями
аппаратуры, требованиями пользователя, или условиями внешнего сопряжения
Система обработки сообщений может обслуживаться системой связи с максималм
ной пропускной способностью 75 сообщ./с. В этом случае рассмотренная задача
выбора будет переформулирована так:
Выбрать N, максимизирующее П (N),
при условиях: ГОТ (Д') 5=0,98 и П (77)^75.
Из рис. 16J видно, что ограничение П (77)^75 является более сильным, чем
ограничение ГОТ (7/) 5= 0,98 (или 77^4) Решением задачи в этом случае должен
быть выбор 7V=2 при П (7V)=72 и ГОТ (7V)=0,99.
16.5. ДОПУСТИМЫЕ МНОЖЕСТВА И ЛИНИИ УРОВНЯ
СТОИМОСТЬ — доход
На самом деле ограничение П (N) ^75 не обязательно подразумевает Дг^2.
Если было бы выгодно, можно было бы выбрать трехпроцессорную систему и ог-
раничить ее обработкой 75 вместо 96 сообщ../с. Если доход от одного обслужен-
ного в секунду сообщения составляет 2000 долл., то вряд ли стоит платить 10 тыс.
долл, за дополнительный процессор, чтобы получить 6 тыс., долл, за дополнитель-
ные 3 сообщ./с. Если же доход от обработки 1 сообщ./с составит 4 тыс. долл.,
то дополнительные 3 сообщ./с принесли бы 12 тыс. долл., что делает выгодной
плату 10 тыс. долл, за т"1'"'|1й процессор.
Один из способов изображения такой ситуации показан на рис. 16 3, а, б,
на которых задача принятия решения рассматривается в виде функции двух
переменных; числа приобретенных процессоров IV и числа П (сообщ./с), харак-
теризующих систему. Множество всех возможных точек решения (N, П) назы-
вается обычно пространством решений. Ограничение 77^75 разбивает про-
странство решений на множество допустимых решений (П^77>) и множество
недопустимых решений (77>75) Аналогично этому ступенчатая функция произ-
водительности П (N) определяет еще одно разбиение пространства решений на
допустимые [П^П (/V)] и недопустимые [П>П (N)] решения, при которых дан-
ный уровень производительности 77 не может быть достигнут при заданном чис-
ле процессоров N Наконец, линия /7=4 также делит пространство решений на
допустимые (ГОТ5=0,98) и недопустимые (ГОТ<0,98, или /V>4) решения.
Множество допустимых относительно всех заданных ограничений решений
называется допустимым множеством. На рис. 16.3, а и б допустимое множество!
обозначено заштрихованной областью. В связи с введенным понятием задача вы-
бора сводится к поиску решения (7V, /7)тах в допустимом множестве, в котором
достигается максимум чистой стоимости (общая стоимость .минус стоимость):
ЧС(А/, 77) = ОБС (77)—С (/V).
212
Один из способов найти (N, /7) шах, часто называемое оптимальным реше-
нием, состоит в рассмотрении множества точек (N, П), имеющих одинаковую
чистую стоимость или линию уровня чистой стоимости
ЧС (N, П) = ОБС (П) — С (N) = const.
(16.3)
На рис. 16.3,с, б показаны некоторые линии уровня. Различие наклонов линий
объясняется различием в функциях общей стоимости ОБС (П). На рис. 16.3, а
единица обработки (сообщ./с) стоит 2 тыс. долл., или ОБС (77) =2/7, на
рис. 16.3,6 — стоит 4 тыс. долл., или ОБС (77) =4/7.
Рис. 16.3. Задача выбора:
а — с ограничением ОБС (77) =277; б — с ограничением ОБС (/7) =4/7
Для этих двух случаев воспользуемся уравнением (16.3):
на рис. 16.3, а ЧС (N, П)=2 77—(80+10 7V)=const,
на рис. 16.3,6 ЧС (N, П)=4 П— (80+10 W)=const.
В области допустимых решений (N, П), часть которых показана на рис. 16.3,
Формулам соответствуют семейства параллельных линий. Среди них имеются ли-
нии, определяющие оптимальное решение (N, /7)шах.
213
Принципиально важно, что обозначенное символом О оптимальное решение
(N, /7)Шах лежит на линии максимальной чистой стоимости, имеющей точки в дсн.
пустимом множестве. Так, на рис. 16.3, а решение (N, П) = (2,72) является оптИ
мальным, а линия уровня, проходящая через нее, имеет наибольшее значение]
ЧС=44. На рис. 16.3, б это же решение не является оптимальным, так как ее ли-
ния уровня ЧС=188, хотя и дает максимальное значение, но не содержится в
допустимом множестве.
16.6. ОБЩИЙ СЛУЧАЙ ЗАДАЧИ ВЫБОРА РЕШЕНИЙ С ОГРАНИЧЕНИЯМИ
Приведенный выше пример является частным случаем общей задачи выбора
оптимального решения с ограничениями (рис. 16.4). Математическая формули-
ровка задачи состоит в следующем:
Выбрать значения переменных Xi, х2, .... хп, максимизирующие целевую
функцию f (Xi, х2, ... хп) и удовлетворяющие ограничениям
Si (М. хг>- , *п) < К;
§2 (•*! > Х2 , - - . , Хп) < Ь2;
(16-4)
Sni (-*-1» х2 ’ » хп) bm
Для наглядности на рис. 16.4 указаны только две переменные Xi и х„.
Каждая точка (хь хг, .., хп) называется решением, а множество допустимых 1
решений называется пространством решений. При т=3 функции ограничений
g;(xi, х2...xn)^bi, i=l, 2, 3,
Рис. 16.4. Задачи оптимизации с ограничениями
214
изображены на рисунке как функции двух переменных х, и х„. Решения, лежа-
-цие за пределами ограничений, называются недопустимыми решениями. Реше-
ния, лежащие внутри ограничений, называются допустимыми решениями. Мно-
жество допустимых решений называется допустимых множеством.
Целевая функция f(xlt х2...хп) может быть изображена набором линий
фиксированного значения этой функции, или линиями уровня целевой функции:
f(xt, Х2, .... xn)=v.
Тогда, как и в приведенном выше примере СОС, оптимальное решение (хи
х2 Xn)max и оптимальное значение Vmax целевой функции в задаче выбора
удовлетворяют следующим необходимым и достаточным условиям оптимально-
сти решения:
1. (*i, хг. ..xn)max является допустимым решением, принадлежащим линии
уровня f (Х|, Х2, . . ., Хп) =*Vmax.
2. Если v>Vmax то ее линия уровня f(xj, х2.xn)=v не содержит ни
одного допустимого решения.
В некоторых случаях задача выбора ограничена таким образом, что нет ни
одного допустимого решения, удовлетворяющего всем ограничениям. Такая
ситуация называется недопустимой задачей выбора. Например, добавление огра-
ничения
f(X|, х2..Xn)5=VS
в рассматриваемую на пне. 16.4 задачу выбора превратило бы ее в недопустимую.
16.7. ПРИМЕНЕНИЕ I ИНЖЕНЕРНОМ ПРОГРАММИРОВАНИИ
Приведем некоторые типичные задачи инженерного программирования, для
которых могут оказаться по гезными : 'етодч математической оптимизации.
Задача выбора оптимальной конфигурации аппаратно программного обеспе-
чения в технико-экономическом обосновании систем обработки информации.
В таких задачах требуется выбрать конфигурацию аппаратно- программного обес-
печения, которая давала бы максимальную чистую стоимость при ограничениях
на ресурсы, число исполнителей, удобства и приемлемую производительность
(см. [110, 279] и др.).
Задача выбора оптимальной сети ЭВМ, состоящих из процессоров, запоми-
нающих устройств и каналов связи, обеспечивающих максимальную пропускную
способность при выполнении ограничений на ресурсы или время ответа или исполь-
зующих минимальные ресурсы при ограничениях на пропускную способность и
время ответа и Т. п [134, 174].
Задачи выбора оптимальных вычислительных алгоритмов для выполнения
различных функций обработки информации, например сортировки, поиска, рас-
пределения памяти и т. п., минимизирующие время вычислений при выполнении
ограничений на доступную память, или наоборот [151, 175 —177].
16.8. МЕТОДЫ МАТЕМАТИЧЕСКОЙ ОПТИМИЗАЦИИ
Задача выбора оптимального решения представлена выше как математиче-
ская задача. Для определенного класса таких задач существуют алгоритмы
поиска оптимального решения (или определения неразрешимости задачи) В этом
параграфе представлен пример одного из наиболее общих математических мето-
дов оптимизации — линейное программирование, кратко рассмотрена задача нели-
нейного программирования Существует большое число публикаций с подробным
изложением алгоритмов, специальных случаев и развития тех или иных методов
оптимизации [2С0, 321].
Линейное программирование. Если целевая функция / есть линейная функ-
ция переменных хь х2..хп
f (X!, х2,..., хп) =Cj Xj ]-с2 х2+ ... +со х„
215
п ограничения gi также являются линейными функциями, то задача выбора пт,,
мального решения называется задачей линейного программированияОна фипЗ
мулируется так:
Выбрать значения переменных хь х2, ..., х„,
МИНИМИЗИРУЮЩИХ С1Х1 + С2Хг4- . .- + СпХп,
при ограничениях ацх1+а12х2+ .. +а1пхп^д1;
О21Х1+се22х2+ ... -f-o2nXn^b2;
OmlXj Ч"Пг,12Х2+ ... -f-dmnXjt Jibin',
...................
х^О, х2^0, .. ., Хп^О.
Пример линейного программирования. В качестве примера применения ме- J
тодов математической оптимизации сформулируем задачу линейного программиро-
вания и найдем ее решение. Отдел программного обеспечения одной фирмы рас- J
полагает штатом 16 аналитиков и 24 программистов, а для разработки ПО имеет
15 ч машинного времени в день. Фирма специализируется в разработке иденти
ных программных систем — систем обработки текстов (СОТ) и систем управленв
процессом । 2УП) — и имеет непрерывный поток заказов на каждый тип систем
Проект СОТ требует для разработки труда двух аналитиков, шести прогоамми-
стов и 3 ч машинного времени в день и обеспечивает прибыль в 20 тыс. долл
Разработка СУП требует тр^да четырех аналитиков, двух программистов и 3 ч I
машинного времени в день и дает прибыль в 30 тыс. долл.
Фирма постоянно планирует свою работу на следующий год и хотела бы
иметь «твет на вопрос:
Сколько систем того или иного сорта она должна разработать при имеющих-1
ся ограничениях на рабочую силу и машинное время для обеспечения максималь-
ной прибыли?
Ниже дана пятишаговая последовательность вопросов, отвечая на которые
фирма может решить основной вопрос. Отметим ее схожесть с пятишаговой пг
следовательностью вопросов, которую использовала администрация журнала
^Scientific American: в удачном варианте системы обработки подписки (см. гл. 1). ,
Шаг 1. Какова целевая функция? В данном примере объектом оптимизации
является прибыль.
Шаг 2. Какие зависящие от разработчика атрибуты влияют на целевую I
функцию1^ Существует много способов влияния на целевую функцию, но не ice
они подвластны фирме. Например, .если бы каждый покупатель решил платить
фирме вдвое больше за разработанную систему, то это благоприятно повлияло бы 1
на доход фирмы. Тем не менее в условиях конкурентной борьбы такое решение
фирмой не контролируется. Фирма может регулировать влияющими на целевую
функцию переменными:
X] — число разрабатываемых СОТ,
х2 — число разрабатываемых СУП.
Шаг 3. Чем диктуются ограничения на множество выборов? Фирма могла •
бы иметь неограниченный доход, если бы могла принять неограниченное число I
заказов на СОТ и СУП. Но фирма располагает ограниченным числом анали™ков,
программистов и часов машинного времени. К примеру, так как каждое задание I
на СОТ требует привлечения двух аналитиков, задание на СУП — четырех ана-1
литиков, а у фирмы имеются лишь 16, то ограничение на аналитикол имеет вид
2 Xi+4 x2s£I6.
.* Понятия «Линейное программирование» и «Программирование ЭВМ» про-
исходят от одного и того же значения глагола «программировать»: определить
последовательность операций. Основным побуждающим мотивом развития ме-
тода линейного программирования, сформулированного Данцигом в 1947 г., был
поиск способа выполнения огромного чгсла ручных операций, связанных с зада-
чей материально-технического обеспечения во время второй мировой войны [81].
216
Диалогично этому ограничения на программистов и машинное время будут иметь
пЯп неравенств
б Xi + 2 x2s£24; 3 Х)+3 x2s£15.
Существуют два дополнительных ограничения — число заданий на СОТ и СУП
Яе может быть отоицательным:
XjjgsO и х2^0.
Шаг 4. Как зависит целевая функция от переменных^ Так как фирма мо-
жет иметь 20 тыс. долл, дохода на каждую СОТ и 30 тыс. долл, на каждую СУП,
То общий доход Д выражается зависимостью
Д=20 х-4-30 х2.
Шаг 5. Какое решение обеспечивает оптимально! значение целевой функ-
ции? Во-первых, заметим, что группировка Bcev соотношений приводит к задаче
линейного программирования, аналогичной по форме уравнению (16.4):
выбрать значения переменных х1 и х2,
максимизирующие Д=20 Xj+ЗО xa,
при ограничениях 2 Х]+4 х2^16;
6 X|+2 x2s^24:
3 Xi+3 х2^15;
Xi5=0, х2^0.
Существует много различных методов решения задачи линейного программи
рования. Наиболее общий алгоритм симплекс-метода [81] основывается на матрич-
но-зекторных операциях, которые обычно применяются при обращении матриц или
решении систем линейных уравнений. В данной главе приводится графическое ре-
шение задачи с использованием необходимых и достаточных условий оптималь-
ности решения, рассмотренных в разд. 16.2.
На рис. 16.5 показаны ограничения как функции переменных Xi и х2. Так
определяют допустимое множество (заштрихованная область на рис. 16.5 или
16.6) переменных решения, удовлетворяющих всем ограничениям Затем (см.
рис. 16.6) изображают линии постоянного дохода, или линии уровня:
20 Х|+30 х2=const.
Рис. 16.5. Ограничения в задаче линейного программирования и допустимое
множество
217
Оптимальной линией уровня на рис. 16.6 является линия
20 *1 + 30 х2=130.
Оптимальная точка определяется значениями Xi = 2 и х2=3 и удовлетворяет не
обходимым и достаточным условиям оптимальности решения:
1. (xi, х2) шах— (2, 3) есть точка, принадлежащая линии уровня 20 Xj >о
+30 X2='Vmax.
2. Если v>Vmax, то ее линия уровня 20 х<+30 x2=v не содержит ни одной
допустимой точки.
Итак, ответом на задачу фирмы является задание на разработку двух СОТ и
трех СУП, обеспечивающих доход в 130 тыс. долл.
Рис. 16.6. Линии уровня в линейном программировании и оптимальное решение
В процессе решения сделан ряд предположений, которые практически обычно
не выполняются, например:
порграммисты и аналитики меняются ролями от проекта к проекту;
могут возникнуть неучтенные факторы или нелинейные зависимости для эко-
номических показателей, обусловленные масштабом работы при выполнении ряда
сходных заданий;
некоторые программисты или аналитики, не принимающие участия в опти-
мальном решении (при Xi=2 и х2=3 число занятых программистов 6 Xj+2 х2=
= 18, а 6 программистов становятся безработными), могут быть немедленно
переориентированы на какую-либо другую работу.
Такие допущения являются зачастую настолько спорными, что всегда необ-
ходимо добавлять еще два шага в процесс решения задачи линейного программи-
рования или другой задачи математической оптимизации.
Шаг 5а. Насколько устойчиво оптимальное решение относительно предполо-
жений, принятых во время анализа? Существуют ли альтернативные решения,
обеспечивающие хорошие результаты при достаточном согласовании предполо-1
жений?
Шаг 6 Ведет ли выполнение какого-либо шага к пересмотру предыдущих
шагов? Если да, то повторить все предыдущие шаги.
Эти вопросы рассматриваются далее в гл. 17.
Нелинейное программирование. В реальных задачах принятия решений ог-
раничения или (и) целевые функции, как правило, являются нелинейными, н тогда
методы линейного программирования оказываются непригодными. Задачи опти-
мального планирования проектов ПО могут иметь существенно нелинейные целе-
вые функции, зависящие от предельных сроков, составления годовых балансовых
218
В задачах оптимального распределения нелинейность производственной
может быть обусловлена величиной участка инвестирования, высоким
отдачи или величиной участка сокращения отдачи, рассмотренными
оТчегов или, например, связанные с запуском искусственного спутника. При ре-
1пен“Ч задач сетевого планирования часто имеют дело с нелинейными функциями
тарифа. ° '
фу! КЦИИ
уровнем
в ГЛ. 1 1-
Рис. 16.7 Задача нелинейного программирования с многими максимумами
Методы решения задач нелинейного программирования в общем случае зна-
чительно сложнее методов лилейного программирования. Иногда алгоритмы реше-
ния задач нелинейного программирования не сходятся, либо сходятся к неопти-
мальному решению. Последнее обстоятельство является следствием того, что нели-
нейная целевая функция может иметь несколько локальных максимумов (см
рис. 16.7). Алгоритмы нелинейного программирования обычно основываются на
пошаговом продвижении вдоль локального градиента (направления наибольшего
возрастания). Так, если на рис. 16.7 начальной точкой движения является х, то
алгоритм приводит к локальному максимуму g (х) =30, причем алгоритм не га-
рантирует, что этот локальный максимум является наибольшим (глобальны::
максимумом). Если бы на рис. 16.7 поиск начался с точки х', то алгоритм
привел бы к глобальному максимуму g (х) =40. Поэтому при решении задачи не-
линейного программирования алгоритм запускается с нескольких начальных точек,
определяемых по некоторым предварительным данным об исследуемой области.
16.9. ВОЗМОЖНОСТИ И ОГРАНИЧЕНИЯ МЕТОДОВ МАТЕМАТИЧЕСКОЙ
ОПТИМИЗАЦИИ
Существует несколько практических ограничений для программиста, приме-
няющего методы математической оптимизации. При математической формулировке
практических задач требуется делать предположения (например, о линейности,
о пренебрежении факторами, не поддающимися количественной оценке), которые
часто рудно оправдать. Для больших задач определение оптимального решения
может быть слишком дорогостоящим ме-
роприятием. Некоторые алгоритмы, осо-
бенно при решении задач нелинейного
программирования, могут либо не схо-
диться, либо сходиться к локальному
Максимуму, отличному от глобального.
Кроме того, иногда для практиче-
ских применений лучше выбрать не опти-
мальное решение, находящееся на краю
Резкого спада целевой функции (как
точка х-10 на рис. 16.8), а неоптималь-
иое, зато менее рискованное (точка
*=6).
Тем не менее результаты математи-
ческой оптимизации часто стоят затрат на
Рис. 16.8. Оптимум при наличии рис-
ка
219
их получение. Даже если не выбирать математически оптимальное решение, з»'.
ние его и того, что оно дает, оказывается очень полезным для принятия праю^Н
ского решения.
Большинство методов математической оптимизации обеспечивают качествен
ную оценку чувствительности решения к исходным данным задачи либо позволяв
легко его получить вариацией входных параметров и повторным прогоном алгц.
ритма.
Наконец, главным значением метода оптимизации с ограничениями являете
концептуальная помощь в постановке задачи, ее решении и принятии конкретное#
решения. Он помогает выяснить многие вопросы (Что является целью оптимиза-
ции? От каких переменных зависит решение? Какие переменные зависят от разра-
ботчика?), встречающиеся при разработке ПО. В качестве примера в следующей
главе рассматривается процесс системного анализа одной общей модели методов
оптимизации с ограничениями.
ГЛАВА 17
СИСТЕМНЫЙ АНАЛИЗ И ОПТИМИЗАЦИЯ С ОГРАНИЧЕНИЯМИ
Системный анализ является основой методов анализа однотипных последовав
тельностей альтернативных решений в рамках данной проблемы. Методы систем-
ного анализа широко применяются на этапе анализа осуществимости ЖЦПОД
На этом этапе основной задачей является выбор конкретной системы ПО, подле-
жащей разработке, из большого числа возможных проектов.
С помощью системного анализа это число кандидатов ограничивается до не-
скольких единиц, которые должны быть затем проанализированы более подробно
с тем, чтобы из них выбрать наиболее подходящий. Изложенный в предыдущей
главе метод оптимизации с ограничениями дает хорошую концептуальную осно-
ву для понимания приемов системного анализа.
17.1. ПРИМЕР
Ниже приведена последовательность шагов системного анализа. Они пример-
но те же, что и рассмотренные при изучении примера с журналом «Scientific
American» в гл. 1 и примера линейного программирования в предыдущей. Здесь
они сформулированы в более общем виде и конкретизируются на примере СОС
специального типа: системы резервирования авиабилетов.
1. Что является объектом оптимизации или каких целей необходимо
достичь?
Этот вопрос помогает отсортировать цели конкретной разрабатываемой си-
стемы (цели системы) от более общих целей (глобальных целей) в исследуемой
области и от целей альтернативных систем (глобальных альтернатив).
Для СОС резервирования авиабилетов целями системы являются: резерви-
рование и аннулирование билетов, выдача справок о рейсах, пассажирах, наличии
мест и т. п. Кроме того, СОС должна работать быстро, точно и надежно, быть,
полезной и удобной как для пользователей, так и сотрудников аэрофлота.
Необходимо также придерживаться таких глобальных целей, как достаточ-
ный уровень дохода, благожелательное отношение со стороны пользователей!
удовлетворительные темпы развития ’. Однако сама по себе СОС не может обес-
печить требования такого рода, поэтому эти цели не являются для нее прямыми.
Указанные глобальные цели являются также целями альтернативных систем, та-
ких как система управления авиационной техникой или модель прогнозирования
заявок пассажиров. Для таких глобальных альтернатив должно быть преду- |
смотрено их возможное влияние на СОС резервирования авиабилетов, однако их
цели нельзя рассматривать как прямые цели этой СОС.
1 Аналогичные цели у системы коммунальных услуг: достаточный уровень
расходов в рамках бюджета, удобства обслуживания, расширение сферы услуг.
220
Системы управления
учетом азрофлота
Пространство решений
для всех возможных
вариантов систем <
Рис 17-1. Выбор из всех альтернатив
Если рассматривать начальное пространство решений как множество всевоз-
можных разрабатываемых систем, то процесс определения целей конкретной си-
стемы позволяет исключить большое число систем-кандидатов на разработку и
сосредоточить внимание на подмножестве СОС резервирования авиабилетов, пред-
ставляющих интерес в первую очередь, что и отражено на рис. 17.1.
2. Какие решения, влияющие на цели, зависят от разработчика?
Этот вопрос помогает еще более сузить пространство решений, исключая из
рассмотрения:
Системы, при разработке которых должны приниматься решения, не зави-
сящие от разработчика. Так, можно было бы создать более эффективную СОС,
если допустить реорганизацию в системе главной базы данных аэрофлота либо
заменить кассы аэрофлота для упрощения процесса резервирования. В некоторых
случаях полезно провести дополнительные исследования и добиться таких измене-
ний, однако в основном такие изменения нереальны в период разработки системы
(например, если кассы являются правительственными учреждениями).
Характеристики систем, которые не оказывают существенного влияния на
цели. К примеру, можно не обращать серьезного внимания на выбор типа дисп-
лея на пункте резервирования или на способ кодирования сообщений об ошибках
Однако эти вопросы, существенно влияющие на производительность системы,
могут быть отложены лишь до более поздних этапов проектирования и разра-
ботки.
Таким образом, на этом этапе из множества возможных альтернатив системы
остаются только реальные и имеющие практическую значимость, как это пока-
зано на рис. 17.2.
Рис. 17.2. Выбор из системных альтернатив
3. Что ограничивает область выбора?
Этот вопрос еще более ограничивает число оцениваемых альтернатив. Типн%.
ними ограничениями являются:
Условия внешнего сопряжения. К примеру, ограничение 75 сообщ./с, обус.
ловленное возможностями линии связи.
Цели, выраженные как ограничения, которые могут возникнуть в процесс^
согласования целей. Например, ограничение на готовность системы должно быть
не ниже 0,98. Эти ограничения уменьшают число кандидатов на разработку Л
малого допустимого множества (рис. 17.3).
Ограничения
Рис. 17.3. Выделение недопустимых альтернатив
4. Какие критерии должны применяться для оценки оставшихся альтерна-
тив? Как зависят целевые функции от переменных решения, определяющим
альтернативы?
В системном анализе критерии почти всегда включают некоторые меры стои-
мости и эффективности, а нередко их комбинацию для согласования требований
по стоимости и эффективности. В изложенном примере СОС применена очень
простая целевая функция, она основана на понятии чистой стоимости. 13 реальной
системе резервирования авиабилетов целевая (-ые) функция (-и) включает время
ответа, виды обслуживаемых запросов, возможности развития, общественное мне-
ние.
В примере СОС целевая функция может быть изображена семейством линий
уровня, или линий постоянного значения целевой функции, как показано на
рис. 17.4.
5. Какое решение обеспечивает наиболее удовлетворительное значение целе-
вой функции? Насколько устойчиво это решение по отношению к допущениям,
сделанным во время анализа? Существует ли альтернативное решение с удов-
летворительными результатами, более устойчивое относительно сделанных до-
пущений?
222
в рассмотренном примере СОС оптимальным решением одной из задач (см.
„с 16.3, а) было приобретение двух процессоров и работа с производительно-
Ljjo 72 сообщ./с. Если теперь один процессор выходит из строя и система вынуж-
дена функционировать только с одним процессором, производительность падает
до 40 сообщ./с.
Для многих конкретных случаев (система резервирования авиабилетов) та-
кой спад производительности может оказаться неприемлемым, особенно если
среднее время ремонта процессора велико. Таким образом, это решение весьма
неустойчиво по отношению к (необъявленному) предположению, сделанному во
время анализа и означающему, что любой уровень снижения производительности
приемлем.
Среди альтернативных решений можно выбрать путь приобретения третьего
процессора в качестве резервного. При этом номинальная производительность
останется равной 72 сообщ./с вместо 96 сообщ./с при трехпроцессорном варианте
работы системы. Однако линии связи ограничивают производительность обработ-
ки максимальным значением 75 сообщ./с, а дополнительный подключенный про-
цессор снижает надежность с 0,98 до 0,97. Таким образом, анализ устойчивости
приводит к альтернативному решению, которое может оказаться предпочтитель-
нее любого, полученного ранее. Это служит примером заключительного шага ме-
тода системного анализа — итерации.
6. Приводит ли выполнение какого-либо шага к пересмотру предыдущих
шагов? Если да, то повторить их.
17.2. ОБЩЕЕ ОБСУЖДЕНИЕ
Концептуальная модель математической оптимизации помогает ознакомиться
с методом системного анализа с помощью понятий пространства решений, допу-
стимого множества альтернатив, целевой функции.
И наоборот, метод системного анализа помогает правильно построить процесс
математической оптимизации, при этом хорошая постановка задачи и анализ
устойчивости, по крайней мере, так же важны, как и нахождение оптимального
решения.
На рис. .17.5 проведено сравнение методов математической оптимизации и
системного анализа в том виде, как они сформулированы в [246]. Сходство их зна-
чительно, а основными различиями являются следующие:
в системном анализе особое внимание уделяется субъективным качественным
факторам;
системный анализ позволяет обосновать некоторое допустимое, но не опти-
мальное решение.
Эти два положения являются главными предостережениями при использова-
нии методов математической оптимизации. Инженерное программирование связа-
но с таким решением проблем, когда нужна строгая самодисциплина, чтобы не
попасть впросак в погоне за абсолютным математическим оптимумом, помня, что
оптимальное решение может оказаться хуже альтернативного. Эти альтернатив-
ные решения могут быть более устойчивыми относительно допущений, принятых
при моделировании, лучшими по отношению к некоторым нечисловым или опу-
шенным при анализе, но более веским факторам. Если не придерживаться этой
самодисциплины, можно попасть в тупиковые ситуации, как в следующих "при-
мерах:
непригодная система медицинского обслуживания с оптимальным временем
ответа, но с неприемлемой формой общения с пациентами;
отставание по срокам разработки главной системы обороны с оптимальным
Планированием, которое трудно настроить на неизбежную задержку аппаратуры
и отказы в аппаратуре;
223
Математическая оптимизация
Системный анализ [246],
Рис. 17.5. Сравнение методов математической оптимизации и системного ан;
лиз а
система программирования научных расчетов с оптимальным набором тестов,
минимизирующим время проверки всей системы, но утраивающим время генера-
ции эталонных результатов и исходных данных для тестов;
система учета посещаемости городских школ, которая хотя и оптимизирует
результаты, но ценой обострения проблемы местной безработицы.
ГЛАВА 18
СОВМЕСТНОЕ ПРЕДСТАВЛЕНИЕ РАЗНОРОДНЫХ КАЧЕСТВЕННЫХ
ЦЕЛЕЙ
В гл. 13—16 были рассмотрены количественные методы согласо-
вания нескольких различных целей. При этом в гл. 13 и 14 цели
выражались стоимостью в долларах или доходом. В гл. 15 рассмо-
трены другие методы согласования нескольких целей единым без-
размерным показателем. Представление целей количественными
ограничениями рассмотрено в гл. 16. В этих четырех главах (а так-
224
в гл. 17) отмечалось, что численные методы весьма важны, но
опи неприменимы к разноородным качественным целям, часто
встречающимся в инженерном программировании.
Совместное представление таких разнородных целей осложня-
ется двумя главными проблемами, к которым относятся:
1. Нахождение методов представления результатов анализа
принятия решений с повышением наглядности всех факторов и об-
легчением поиска решений на основе представленной информации.
Эта тема обсуждается в данной главе.
2. Нахождение методов согласования решений на основе раз-
нородных показателей. Эта тема включает метод «Дельфы» [145],
которому посвящена гл. 22, методы структурной разработки [ИЗ]
и другие, рассмотрение которых выходит за рамки настоящей кни-
ги (например, анализ поведения [99]).
18.1. ПРИМЕР РАЗРАБОТКИ ОПЕРАЦИОННОЙ СИСТЕМЫ ДЛЯ СОС
(ВАРИАНТ В)
Предположим, что требуется приступить к разработке СОС ва-
рианта В. Она включает разработку специализированной операци-
онной системы с уменьшенными расходами на мультипроцессиро-
вание, что повышает в перспективе номинальную производитель-
ность обработки до 80 сообщ./с.
Из-за плохой характеристики надежности штатной операцион-
ной системы («отказ одного процессора — отказ всей системы»)
необходимо поставить дополнительные цели повышения надежно-
сти и готовности системы путем улучшения метода переключения
и повторного запуска процессоров при отказе одного или большего
их числа. После технического анализа поставленной задачи сдела-
но заключение, что разработка такой системы с дополнительными
переключениями и возможностью повторного запуска потребует
150 тыс. долл, и займет 12 мес. Также определено, что достижение
требуемых надежности и готовности приведет к дополнительным
затратам в 30 тыс. долл.
18.2. СРАВНЕНИЕ СОБСТВЕННОЙ И ЗАКАЗНОЙ РАЗРАБОТОК
Поставщик ТО активно способствует развитию вычислительных
систем и предлагает разработать СОС варианта В за 12 мес. стои-
мостью 135 тыс. долл., с улучшенными качествами системы и
средствами диагностики. Необходимо оценить это предложение не
только с точки зрения стоимости и производительности, но также
с учетом других важных качественных показателей. Среди них:
Подготовка основных специалистов. Если системные програм-
мисты будут подготовлены к работе с системой, то предложение
будет выглядеть очень заманчивым, и наоборот.
Моральное состояние и рост квалификации сотрудников. Полу-
чение заказа на разработку СОС варианта В является стимулом
технического совершенствования. Поэтому, если отдать его па сто-
рону, собственные системные программисты могут почувствовать
225
Я Зак. 628
себя ущемленными и отстать от современного уровня развнтня
распределенных систем обработки данных. В то же время острота
этих проблем зависит от наличия альтернативных заказов, кото-
рые могут быть выполнены ими в этом случае.
Управляемость. Во время разработки новой системы работа ца
старой помогает изыскивать средства повышения качеств новой
операционной системы. Если разработка ведется собственными си-
лами, то улучшение проекта полностью контролируемо. Если же
разработкой СОС варианта В занимаются сторонние исполнители,
то любое изменение проекта осложняется переговорами с подряд’
чиками, имеющимися у них ограничениями, нежеланием вносить
изменения — можно найти другого покупателя, готового приобре-
сти начальный вариант
Простота сопровождения. Разработка СОС завершается не
только собственными силами, но и группой специалистов, которые
будут поддерживать разработку на фазе сопровождения. В про-
тивном случае необходимо либо обучение собственного обслужива-
ющего персонала, либо заключение договора на сопровождение
Выразить подобные показатели оценками в долларах, ограни-
чениями или некоторыми сравнительными оценками, как правило,
не удается, так как ими нельзя охватить весь круг субъективных
факторов и возможных эффектов, определяющих правильный вы-
бор разработчика. Ниже даны некоторые альтернативные методы
представления информации такого рода.
18.3. МЕТОДЫ ПРЕДСТАВЛЕНИЯ
Одним из методов представления является словесное обсужде-
ние данного показателя — насколько каждая альтернатива удо-
влетворяет соответствующему показателю, как было рассмотрено
выше. Просмотрев затем каждый пункт обсуждения, на основании
субъективной оценки можно сделать тот или иной выбор. Этот
путь весьма практичен, если число пунктов и степень их детализа-
ции не слишком велики (рассмотренные выше: подготовка кадров, I
моральное состояние, проблемы роста, управляемость и простота
сопровождения). С увеличением числа пунктов легко запутаться
в деталях.
Если число показателей достаточно велико, необходимо более
кратко представить их для сохранения возможности обзора всех
показателей. Хорошим методом краткого представления является
таблица «за и против», или таблица предпочтения. Например, в
табл. 18.1 все доводы в пользу собственной разработки сгруппиро-
ваны в левой колонке, а в пользу заказа разработки — в правой.
Такая таблица в значительной степени помогает найти решение
Однако при большом числе альтернатив разработок и показателей
таблица становится слишком громоздкой В таком случае показа-
тели целесообразно представить таблицей рейтингов в виде демон- I
страционной матрицы фазы анализа осуществимости, как показа-
но на рис. 18 1. "В
226
1аблица 18.1
Таблица предпочтения альтернатив СОС
Собственная разработка Заказ на разработку
Определение стоимости и сроков разра- ботки подрядчиком Обеспечение служебного роста собствен- ных сотрудников Обеспечение штата специалистов для поддержания системы Более гибкое корректирование проекта системы Меньшая стоимость разработки (135 вместо 150 тыс. долл.) Освобождение собственных сотруд- ников для других задач Обеспечение лучших качеств системы и средств диагностики
Демонстрационная матрица является средством отображения
альтернатив разработок при анализе осуществимости ЖЦПО.
В строках матрицы отражена сравнительная важность различных
показателей для выбора предпочтительного варианта системы. Не-
которые общие показатели представлены на бланке, другие, свойст-
венные только данному проекту, могут быть вписаны в пустые
строки. В первой колонке указывается относительная важность
каждого показателя — от несущественного до решающего — числом
звездочек в клетке. В оставшихся колонках тем же способом отра-
жена относительная важность всех рассматриваемых альтернатив
разработок по всем показателям.
Число звездочек дает наглядное представление об относитель-
ной важности показателя для каждой альтернативы с точностью,
мало отличающейся от точности словесного описания. Иногда мо-
жет возникнуть несколько мнений относительно числа звездочек,
которые могут быть приписаны данным показателю и альтернати-
ве. Даже в этом случае демонстрационная матрица весьма полезна
для принятия решения о важности показателя данной альтерна-
тивы. Если показатель несуществен (например, способность систе-
мы собирать статистику), то безразлично, три или две звездочки
будут приписаны альтернативе в данной строке. Или если все аль-
тернативы оцениваются одним и тем же уровнем важности (напри-
мер, время реакции), то несущественно, две или три звездочки по-
мещаются в этой строке. Таким образом, демонстрационная ма-
трица является очень удобным инструментом обобщения относи-
тельно большого числа показателей (от 5 до 30) и альтернатив (от
2 до 20).
Из рассмотрения продемонстрированных методов представле-
ния можно сделать вывод, что собственная разработка предпочти-
тельней заказной. Однако если ощущаются острая нехватка основ-
ных разработчиков и трудности в наборе новых кадров, то можно
отдать предпочтение альтернативному решению. Определить уро-
вень показателя нехватки кадров, при котором чаша весов склоня-
ется в сторону заказной разработки, составляет сложную задачу,
зависящую от сопоставления субъективных факторов.
8* 227
Шкала рейтингов Показатель Альтернатива
* * * *** • * * Несущественный Возможный Важный Решающий Неприемлемая Средняя Приемлемая Желательная У УУУУ У У У У У ^у~Уу У/ ууУ /j?/#/ / / / / / УУ/ / / / / / ууУ У У У У
1 У/ /УУ//
Стоимость Прибыль, долл. XXX XX XX
Расход, долл. > 1 *ХХ XX XX
Сроки XX XX *
Основной персонал XX X- -XXX
Другое:
Эффективность Функции:
Диагностика X* XX XXX
Характеристика производительности XX XX ххх
Сбор статистики * X* XXX
Выдача результатов XXX XX XX
Время ответа XX XX *Х
Точность -
Простота применения XX XX XX
Простота сопровождения ххх XXX X
Моральное состояние и рост квалификации хх> ххх X
Возможность продажи •
Репутация •
Побочные эффекты (прочее):
Риск Т ехнологичность •
Готовностъ — надежность ххх ** XX
Управляемость ххх X
Прочее:
Рис. 18.1. Демонстрационная матрица для анализа осуществимости
228
. . ОБЩЕЕ ОБСУЖДЕНИЕ КАЧЕСТВЕННЫХ ПОКАЗАТЕЛЕЙ
(5.*-
В практике инженерного программирования важные показате-
ли обычно имеют качественный характер. В общем случае было бы
правильно попытаться дать им численную оценку, имея в виду
следующие два замечания:
подробное рассмотрение необходимо должно приводить к реаль-
ным количественным показателям;
стремление дать более удобную оценку подчеркивает важность
количественных показателей, потому что они легче поддаются об-
работке и учету.
В общем случае показатели эффективности или пользы значи-
тельно труднее представить в количественной форме, чем стоимост-
ные, хотя последние иногда лучше воспринимаются в качественной
форме В табл. 18.2 представлен набор показателей эффектив-
ность— польза, связанных с разработкой информационно-поиско-
вой системы (ИПС) [172]. Эта таблица наглядно показывает труд-
ности численной оценки качественных показателей таких, как, на-
пример, «улучшение компактности записей» или «возможность под-
ключения к ИПС рабочих мест средствами телекоммуникации».
Таблица 18.2
Возможная польза применения информационной системы [172]
Для задач вычисления и печати
Снижение цены вычислений и печати (СЦ)
Повышение точности вычислений (УО — уменьшение числа ошибок)
Способность быстро изменять переменные и значения в вычислительных про-
граммах (ПГ — повышение гибкости)
Значительное повышение скорости вычислений и печати (УСО)
Для задач хранения записей
^Способность «автоматического» сбора данных в записях (СЦ, УСО, УО)
Более полное и систематизированное хранение в записях (СЦ, УО)
Увеличение емкости памяти для хранения записей (СЦ)
Стандартизация хранения записей (СЦ, УСО)
Увеличение плотности записей и данных (СЦ, УСО)
Улучшение защиты данных (УО, СЦ, УКПК)
Улучшение компактности записей (ПГ, СЦ, УС)
Для задач поиска записей
Более быстрый поиск записей (УСО)
Улучшение доступа к большим базам данных (ПГ)
Улучшение корректировки в базах данных (ПГ, СЦ)
Возможность подключения рабочих мест в телекоммуникации (ПГ, УС)
Улучшение методов построения списочных записей (УО, УК)
Возможность контроля и анализа поиска записей (УКПК, УО)
Для системной реструктуризации
Возможность корректировки классов записей (УСО, ПГ, УК)
Возможность пересылки данных больших файлов (УСО, ПГ)
Возможность создания новых файлов сборкой из других (УСО, ПГ)
Для проведения анализа и моделирования
Возможность быстро производить параллельные вычисления (УСО, ПГ, УО)
Возможность моделирования для получения ответа на вопрос «А что, если..?»
(УК, ПГ)
Возможность сбора большого объема данных в различных формах, удобных
Для планирования и принятия решений (УКПК, ПГ)
22 Э
Окончание табл, i
Для управления процессами и ресурсами
Уменьшение необходимости вмешательства обслуживающего персонала в
равление процессами и ресурсами (СЦ)
Улучшение управления процессами, например работой сборочного конвей<
(СЦ, УКПК, УСО, УО)
Улучшенная возможность непрерывного слежения за процессами и доступ)
ми ресурсами (УКПК, УО, ПГ)
Примечание. УСО — увеличение скорости обработки; УКПК — улучшение К1
ства планирования и контроля.
18.5. МЕТОДЫ ПРЕДСТАВЛЕНИЯ КАЧЕСТВЕННЫХ ПОКАЗАТЕЛЕЙ
В начале главы на примере СОС рассмотрены три основных
метода представления результатов оценок качественных показа-1
телей.
1. Краткое описание показателей. Краткое словесное описание
всех альтернатив, один итог по каждому показателю.
Удобный способ представления небольшого числа показателей
(от 2 до 10) для малого числа альтернатив (от 2 до 3).
2. Таблица предпочтения. Таблица подытоживания относительи
но сильных сторон каждой альтернативы. Хороший способ пред-1
ставления для анализа среднего числа показателей (от 2 до 20)
и альтернатив (от 2 до 5). Ключевые моменты отражены в краткой
итоговой форме показателей.
3. Демонстрационная матрица. Матрица рейтингов (от одной1
до трех звездочек) относительной важности каждого показателя и
относительной значимости каждой альтернативы. Годится для
представления довольно большого числа показателей (от 5 до 30)
и альтернатив (от 2 до 10). Ключевые моменты отражены в крат-
кой итоговой форме показателей.
Случаи с еще большим числом показателей и альтернатив уже
не просто поддаются анализу указанными методами *.
1 В работе [37] приводится демонстрационная матрица для анализа 32 альтер-
натив по 15 показателям. Альтернативными являются разработки оборонных си-
стем обработки информации и решение задач управления. В качестве показателен]
использовались следующие: технология проектирования (испытания) системы,
аттестация ПО и системы, своевременность (гибкость), жизнестойкость ТО ЭВМ,
защита данных, качество бортовых ЭВМ, многоканальность, обработка сообще-
ний, анализируемость характеристик систем, мультипроцессорность, наличие спец-
процессоров, деструктуризация системы. Альтернативными являлись СОС, обеспе-
чивающие: боевое дежурство, обнаружение цели и предупреждение, оценку ре
зультатов нападения, действия войск, оценку результатов бомбардировки, завер-
шение конфликта, восстановление, координацию действий нападение — защита,
корректировку планов, моделирование целей (для главного управления стратег»-!
ческими войсками). Аналогичные альтернативы рассматривались для главного
управления тактической авиацией и главного управления ПВО. Рейтинг имел три
уровня. Анализ назначенных рейтингов по строкам и столбцам демонстрационно-’
матрицы дал лишь грубое представление о приоритете в выборе той или иной
системы. Вся совокупность представленной информации слишком велика для оп-
ределения наиболее подходящих проектов или приоритетных разработок. —J
Прим. ред.
230
Таблица 18.3
Сравнение КОМОСТ и ПОСТПО
Показатель Желаемый Приемлем Lift Ожидаемый Рейтинг Важ- ность
к П к п
Стоимость пятилетнего ЖЦПО, тыс. долл. 150 325 179—284 295—430 »*» ♦ ♦ ♦♦
Цена закупки, тыс. долл. 25 75 55 45 ♦♦ ♦♦♦
Стоимость Э и С за 5 лет, тыс. долл 125 х 250 124—229 250—385 ** ♦ ♦♦♦
Точность оценки, % ±20 80% времени ±20 66% времени 72 50—75 ** *
Скрытность информации Собственный контроль Третья сторона Собственный контроль Третья сторона *
Сроки, мес. 3 9 5 1 ** *•
Сопровождаемость Собственный контроль Удвоенные затра- ты Собственный конт- роль Удвоенные затра- ты »** * ♦*
Детализация По этапам, рабо- там, подсистемам, затратам труда и денежных средств По этапам, подси- стемам По этапам, подси- стемам, затратам труда По этапам, неко- торым работам и денежным затра- там ♦ * ♦♦ »♦
• Расширение штатов Собственная экс- пертиза стоимости Основные сведе- ния Потенциальная экспертиза Основные сведе- ния * »♦
ьэ со Примечание. Э и ( КОМОСТ; П ПОСТПО. эксплуатация и с □провождение; *** - желаемое или лучшее ; ** — среднее; * — при емлемое ; К-
«8.6. МЕТОДЫ СОВМЕСТНОГО ПРЕДСТАВЛЕНИЯ КОЛИЧЕСТВЕННЫХ И
КАЧЕСТВЕННЫХ ПОКАЗАТЕЛЕЙ
Существует несколько методов представления разнородных |Д
казателей. Рассмотрим четыре из них. V
Табличные методы. Могут быть использованы различные
ды представления в виде таблиц. Табл. 18.3 демонстрирует одна
пример построения сравнительной оценки собственной разработк,
(КОМОСТ) и покупного пакета ПО (Пакет Оценки СТоимосц
ПО — ПОСТПО). Приведенные данные получены в результат
предварительного анализа различных показателей. Для повышении
наглядности в таблице указаны рейтинги некоторым числом звет
Рис. 18.2. Зависимость уровня важности от стоимости
дочек; в общем случае трудно объединить количественные пока-
затели с рейтингами в одной таблице.
График стоимость — возможность. Другим методом представ-
ления смешанных показателей является сравнение зависимост*#
стоимости от уровня возможностей КОМОСТ и ПОСТПО. Тако*
сравнение показано на рис. 18.2. По вертикальной оси отложены
уровни возможностей (работа модели в последовательные про-
межутки времени, добавление новых функциональных возможнс-
стей), которых можно достичь при соответствующем уровне KanMj
таловложений. Распределение уровней возможностей по оси отр>
жает субъективную относительную оценку каждой возможности
Таким способом представления можно получить некоторый новы®
критерий принятия решения по сравнению с оценкой стоимость -1
эффективность, рассмотренной в гл. 12.
232
Полярные графики или графики Кивиата. Третьим методом
едставлеиия показателей для сравнения КОМОСТ и ПОСТПО
рляется полярный график или график Кивиата *, изображенный
1 рис. 18.3. На этом рисунке проведено сравнение ------
двух альтерна-
dp
на
Рис. 18.3. Полярный график оценки моделей стоимости ПО
тив по всем показателям, представленным на радиальных лучах-
°сях. Они используются как для указания числовых значений (сто-
имость, сроки и точность), так и для указания уровней возможно-
(с градацией: неприемлемый, приемлемый, промежуточный и
Желательный). Лучшей альтернативой является та, которой соот-
1 Первоначально полярные графики были применены в медицине для пред-
ъявления многочисленных параметров диагноза [312]. Они были также успешно
а^РРльзованы некоторыми исследователями для представления оценок работы
ВМ [зо]. Применение полярного графика для оценки характеристик ЭВМ дано
8 ИЮ].
233
ветствует большая область круга, или "'а, которая по форме луЛ
ше приближается к окружности.
Гистограммы. Похожим на предыдущий является метод пред,
ставления результатов оценок на гистограмме. Пример гистограмм
для КОМОСТ и ПОСТПО показан на рис. 18.4.
Рис. 18.4. Сравнение гистограмм
Представление в виде гистограмм по наглядности уступает ме-
тоду полярного графика. Однако построение гистограммы проще и
метод является более гибким: добавление новой характеристики
не требует перестройки гистограммы.
В габл. 18.4 приведены сравнительные данные двух видов СОС.
Попробуйте представить эти данные в виде таблицы предпочтения
полярного графика и гистограмм. Какому виду СОС можно отдать
предпочтение и при каких условиях?
Таблица 18.4
Сравнение характеристик двух вариантов СОС
Показатель Вариант А Вариант В
Стоимость жизненного цик- ла, тыс. долл. Номиналь [ая производи тельность, сообщ./с Надежность Готовность Время разработки, мес. Основной персонал Рост квалификации Управляемость 130 112 0,95 0 976 6 Свободен для других проектов Слабый Через исполнителей 290 180 0,99 0,996 20 Занят для других проектов Значительный Самостоятельный
234
48.7. некоторые предостережения при представлении
и интерпретации разнообразных данных
Выбор масштаба. Первое предостережение — выбор масштаба
представления данных должен быть непредвзятым. К примеру, на
рис. 18.5 изображены две гистограммы для одних и тех же данных
Сроки, годы
Основная стоимость,
100 тыс. долг.
Рис. 18.6
КОМОСТ
ПОСТПО
Рис. 18.7
235
При сравнении по верхним гистограммам КОМОСТ выглядит пре4,
почтительнее, а при сравнении по нижним — ПОСТПО.
Другое предостережение относится к выбору начальной (ил»
конечной) точки шкалы представления. Ошибочный выбор пройд,
люстрирован на рис. 18.6, хотя на гистограммах изображены одщ.
и те же данные.
Повторный учет. Еще одно предостережение относительно пред,
ставления различных вариантов показателей состоит в эффект®
двойного учета. Впечатление от различия по данному показателю
может быть значительно усилено, если рядом поместить два или
три его варианта. Это проиллюстрировано на примере сравнения
двух гистограмм на рис. 18.7.
Введение синонимов для сопровождаемости как дополнитель-
ного показателя приводит к выводу о предпочтительност»
КОМОСТ, тогда как первоначально ПОСТПО выглядит лучше.
ЧАСТЬ ЗВ
УЧЕТ НЕОПРЕДЕЛЕННОСТИ, РИСКА И ВАЖНОСТИ
ИНФОРМАЦИИ
В методах, обсуждаемых в ч. ЗА и ЗБ, предполагается, что можно точно и
определенно установить значения всех показателей (таких, как затраты и произ-
водительность). Однако, особенно в случае оценки затрат на ПО, такое предпо-
ложение не всегда верно и часто приходится сталкиваться с неопределенностями
в оценках затрат и производительности системы, относительно которой необхо-
димо принять решение.
Все рассмотренные в ч. ЗБ методы принятия решений предполагают наличие
полной информации о стоимости и пользе альтернативных систем. К сожалению,
в инженерном программировании полная информация для принятия решений ред-
ко бывает доступной. В этой части рассматриваются методы анализа рисы
(и их значение для экономики инженерного проектирования) (гл. 19) и теория
статистических решений (гл. 20), которые применяются для выработки решения
в условиях неопределенности. Попутно рассматривается значение информации
как основного фактора в программировании и для изделий, предназначенных
для обработки информации.
ГЛАВА 19
УЧЕТ НЕОПРЕДЕЛЕННОСТИ — АНАЛИЗ РИСКА
19.1. ПРИМЕР ВЫБОРА МЕТОДА РАЗРАБОТКИ ОПЕРАЦИОННОЙ СИСТЕМЫ
Предположим, что принято решение о проведении собственной
разработки СОС (вариант В), тогда возникает дополнительная
проблема. Пусть, после анализа различных технических подходов
к разработке операционной системы найдены два наиболее подхо
дящих способа.
236
1. Консервативный метод (КМ), предусматривающий использо-
вание стандартной операционной системы. Это надежный метод,
обеспечивающий, однако, при восьмчпроцессорной конфигурации
ЭВМ максимальную производительность обработки 160 сообщ./с.
2. Радикальный метод (РМ), подразумевающий использование
недавно разработанного метода гипермончтора. Этим методом до-
стигается пиковая производительность в 190 сообщ./с в восьмипро-
цессорной конфигурации. В случае отказа данного метода необхо-
димо перепрограммировать систему, используя консервативный
метод и получая при этом производительность в 160 сообщ./с с до-
полнительными затратами на перепрограммирование 60 тыс. долл.
Потенциальные результаты применения этих методов (а также
основного метода — ОМ, вариант Д) представлены в табл. 19.1 при
условии, что стоимость каждого 1 сообщ./с составляет 4 тыс. долл.
Таблица 19.1
Сравнение методов разработки операционной системы
Характеристика РМ КМ ОМ, Вариант А
Успешный Неус- пешный
Производительность, сообщ./с 190 160 160 120
Доход (4 тыс. долл, за сообщ./с) 760 640 640 480
Основная стоимость, тыс. долл. 260 260 260 130
Общая стоимость, тыс. долл. 260 320 260 130
ЧС, тыс. долл. 500 320 380 350
ЧС в сравнении с ЧС в ОМ, тыс. долл. 150 —30 30 0
Какой метод целесообразно выбрать, основываясь на значении
чистой стоимости? Ясно одно, что консервативный метод лучше
основного. А что можно сказать о радикальном методе? Если ра-
дикальный метод будет применен успешно, усилия будут щедро
вознаграждены. В противном случае существует опасность поте-
рять 30 тыс. долл, по сравнению с затратами в ОМ (вариант Д).
19.2. ПРАВИЛА ВЫБОРА РЕШЕНИЙ ПРИ ПОЛНОЙ НЕОПРЕДЕЛЕННОСТИ
Задача выбора РМ или КМ, когда ничего неизвестно о шансах
на успех РМ, называется задачей выбора при полной неопределен-
ности.
Существует несколько правил выбора из нескольких альтерна-
тив, когда:
результат или выигрыш зависит от конкретного выбора;
для конкретного выбора известен выигрыш по всем альтерна-
тивам;
вероятность конкретного выбора неизвестна.
237
Таблица 19.2 представляет собой матрицу выигрышей в задаче
выбора для рассмотренного примера В ней определен выигрыш
(как чистая стоимость в сравнении со стоимостью в ОМ) для каж-
дой альтернативы и каждой ситуации, которые могут возникнуть
в действительности.
I а б л и ц а 19.2
Матрица выигрышей в тыс. долл, задачи выбора
операционной системы
Альтернатива Конкретный выбор
благоприятный неблагоприятный
РМ км 150 30 —30 30
Правила выбора применяются в зависимости от оптимистиче-
ского или пессимистического отношения к конкретному выбору.
Наиболее пессимистичным является следующее правило.
Правило максимина — определить минимальный выигрыш по
каждой альтернативе. Выбрать альтернативу с наибольшим мини-
мальным выигрышем.
В табл. 19.2 минимальный выигрыш для РМ есть — 30, а мини-
мальный выигрыш для альтернативы КМ есть 30. По правилу мак-
симина следует выбрать КМ.
Правило максимина работает надежно: чтобы ни случилось,
гарантирована прибыль в 30 тыс. долл, по сравнению с вариантом
А. Тем не менее это правило полностью игнорирует потенциально
высокий выигрыш метода РМ в благоприятном случае. Даже если
матрица выигрышей (в тыс. долл.) будет иметь вид
Альтернатива Благоприятный выбор Неблагоприятный выбор
РМ 1 000 000 29
км 30 30
то по правилу максимина следует выбрать КМ.
Наиболее оптимистичным является следующее правило.
Правило максимакса — определить максимальный выигрыш для
каждой альтернативы. Выбрать альтернативу с наибольшим мак-
симальным выигрышем.
По табл. 19.2 правило максимакса определяет выбор РМ. Од-
нако и это правило не является приемлемым. Даже если матриц
выигрышей будет иметь вид
238
Альтернатива Благоприятный выбор Неблагоприятный выбор
РМ 31 — 1 000 000
км 30 30
то по правилу максимакса следует выбрать по-прежнему РМ.
Существует правило, учитывающее относительную величину
выигрыша.
Правило Лапласа, или правило равной вероятности, — опреде-
лить математическое ожидание выигрыша для каждой альтернати-
вы в предположении, что все возможности равновероятны, и вы-
брать конкретный метод с наибольшим значением математическо-
го ожидания.
Если в рассматриваемом примере допустить, что все случаи
равновероятны, то значение математического ожидания (МО) 1
для РМ равно 0,5-150+0,5-(—30) =60, а для КМ равно 30.
В данном случае необходимо выбрать РМ
Это правило является хорошим только при условии, что все
случаи равновероятны, а это практически бывает редко. Оно не
учитывает также скрытых ловушек, например дублирования ситуа-
ций. Предположим для примера, что «неблагоприятный» случай
подразделяется на два состояния ut и и2 (скажем, щ— падение
производительности из-за гипермонитора и и2 — из-за уменьшения
надежности). Тогда матрица выигрышей и значения МО будут
следующими:
Альтернатива Благоприятный выбор и( Значение МО
РМ 150 —30 30 30
км 30 30 —30 30
Хотя ситуация в действительности не изменилась, переобозначе-
ние возможных исходов изменило значения МО, а следовательно,
и рекомендуемый выбор.
Существует несколько других правил выбора в условиях пол-
ной неопределенности, но все они обладают недостатками того или
иного сорта, ограничивающими их применение. Относительно всех
правил можно сказать, что они дают некоторую основу для приня-
тия решения в условиях полной неопределенности, а их недостатки
в конечном счете всегда выявляются. Главный вывод, который
Можно сделать из сказанного, состоит в том, что условия полной
неопределенности затрудняют принятие хорошего решения.
1 Если имеется событие с л возможными результатами, значения которых
суть vIt v2, ..., vn и вероятности появления которых равны pi, Рч, ..., рп, то мате-
матическое ожидание события определяется так: MO=piVi+pjv2-f- ... +p>«vn.
239
19.3. ЭКСПЕРТНЫЕ ОЦЕНКИ ВЕРОЯТНОСТИ
Один из методов преодоления влияния полной неопределенности
состоит в получении экспертных оценок вероятностей по каждой
альтернативе. Эти оценки могут быть уточнены результатами ус-
реднения групповых оценок или методом «Дельфы» [145] (см.
гл. 22).
Предположим, что такими методами получена вероятность 0,4
для благоприятного случая РМ Тогда можно сравнить значения
МО:
для РМ: 0,4-150+0,6- (—30) =42;
для КМ: 0,4-30+0,6-30= 30
и отдать предпочтение выбору РМ.
Соответствующий метод называется интервальным анализом.
Он подразумевает введение параметров, характеризующих неоп-
ределенность, и тогда значение МО становится функцией этих па-
раметров, как показано на рис. 19.1 '. Здесь точка разделения за-
висит от значения вероятности,
равного 0,333. Если имеется
уверенность, что вероятность
благоприятной ситуации с ги-
пермонитором больше 0,333, то
выбор падает на РМ, в против-
ном случае — на КМ.
Заметим, что приведенные
ранее правила выбора явля-
ются частными случаями рас-
смотренного. Правилу макси-
мина соответствует самая левая точка Вер (благопр.) =0, прави-
лу максимакса соответствует самая правая точка Вер (бла-
гопр.) =1, а правилу Лапласа, или правилу равной вероятности,
соответствует средняя точка Вер (благопр.) =0,5.
Рис. 19.1. Интервальный анализ
19.4. ОБЩЕЕ ОБСУЖДЕНИЕ ПРАВИЛ ВЫБОРА ПРИ ПОЛНОЙ
НЕОПРЕДЕЛЕННОСТИ
Задача принятия решения при полной неопределенности состоит
в выборе одной из нескольких альтернатив в условиях, рассмотрен-
ных в разд. 19.2.
Выше определены и обсуждены основные правила выбора —
правила максимина и максимакса, правило Лапласа или равной
вероятности, — проиллюстрированы оптимистичность и пессими-
стичность, а также сильные и слабые стороны каждого подхода.
’ Строятся линии, соответствующие МО=р-30+(1—р)-30 и МО=р-150+
+ (1—р) (—30) на интервале изменения р от 0 до 1. Пересечение линий разде-
ляет интервал р на две области, которые помогают принять решение о методе
разработки. — прим. ред.
240
Все они имеют слабые места. Для каждого правила существу-
ет классы ситуаций, в которых назначается противоестественный
йЛи бессмысленный выбор ’.
L.5. ЗНАЧЕНИЕ ИНФОРМАЦИИ
Неудивительно, что после такого обсуждения правил появляет-
ся недоумение и возникают мысли:
не виден способ применения подобных правил в практике ин-
женерного программирования. Необходимо найти. лучший подход;
или
нет удовлетворения от подобной ситуации. Чтобы принять ре-
шение в этих условиях, необходимы более глубокие знания по
существу дела.
Так выражается фундаментальная потребность, обусловливаю-
щая главную причину существования профессии программиста:
потребность в информации, помогающей человеку принять лучшее
решение. Вообще говоря, все модели — АСУ, ИПС, САП (система
автоматизации программирования), системы автоматического те-
стирования — появились благодаря желанию исследователей, за-
тратив деньги на обработку информации, получить хорошую по-
мощь при выработке решений. В следующей главе основное вни-
мание будет уделено экономическому значению информации, в
особенности при принятии решений в инженерном программиро-
вании.
19.6. ИСПОЛЬЗОВАНИЕ ЭКСПЕРТНЫХ ОЦЕНОК ВЕРОЯТНОСТЕЙ
Один из путей накопления информации для принятия решений
в инженерном программировании состоит в извлечении ее из
экспертных оценок вероятностей. Эта информация очень полезна
и получить ее не слишком сложно. Имеются некоторые практиче-
ские проблемы, связанные с тем, что наиболее квалифицированные
эксперты причастны к самой технике или ее обслуживанию. Это
порождает некоторые преувеличения экспертных оценок в сторону
завышения или занижения. Именно по этой причине чаще всего
используется метод группового оценивания.
Имеется также некоторая польза от применения бригадного
метода. Участие коллектива в получении экспертной оценки приво-
дит к лучшему ее пониманию и влиянию на судьбу проекта. Этот
метод рассматривается в разд. 22.2.
19.7. ФУНКЦИИ ПОЛЕЗНОСТИ
Понятие функции полезности часто вводится при использовании
метода оценивания по М.О для принятия решений. Для иллюстра-
ции ее назначения предположим, что необходимо оценить две воз-
можности:
1 То же самое можно сказать и о других правилах принятия решения при
Полной неопределенности, например, о правиле Гурвица или о правиле минимакса
Штрафа [1881
241
реализовать проект, гарантирующий выигрыш 60 тыс. долл.}
реализовать проект, дающий выигрыш 150 тыс. долл, в 50% слу.
чаев или проигрыш 30 тыс. долл, в остальных случаях. Какой
возможности отдать предпочтение?
Несмотря на то что оба проекта оцениваются одним и тем же
значением МО (см. с. 239), практически всегда выбор падает на
первый. В основном это объясняется тем, что легче воспринимает-
ся различие между выигрышем 60 тыс. долл, и проигрышем 30 тыс.
долл., нежели различие между выигрышами 60 тыс. долл, и
150 тыс. долл.
На рис. 19.2 представлены примеры функции полезности, полу-
ченные в результате опроса двух групп руководителей проектов.
Они выражают предпочтения для различных степеней риска [58].
Один руководитель из группы 1, например, дал значение ожидае-
мой полезности в -|-2 единицы для перспективы приобретения
1 млн. долл, и значение —5 единиц для перспективы потери 1 млн.
долл. Таким образом, если бы руководителю предоставили воз-
можность выбора между получением 1 млн. долл, с 60%-ными
шансами или потерей 1 млн. долл, с 40%-ными шансами, он бы
отказался от проекта, так как ожидаемая полезность
0,6-2 + 0,4- (—5) = 1,2—2,0 = —0,8
была бы меньше нуля. Боязнь потерь подсказывает ему такое ре-
шение, несмотря на то, что значение МО выигрыша положительно:
0,6-1 млн. долл. + 0,4- (—1 млн. долл.),=0,4 млн. долл.
Чтобы принять данный вариант, руководитель должен быть
уверен, что значение ожидаемой полезности положительно; это в
данном случае означает вероятность успеха, равную, по крайней
мере, 5/7 или 71,4%.
242
(9.8. ПРЕДПОСЫЛКИ ДЛЯ ИНЖЕНЕРНОГО ПРОГРАММИРОВАНИЯ
Основные предпосылки, продиктованные рис. 19.2, для инжене-
ра-программиста, заключаются в следующем:
для большинства руководителей проектов страх потерь значи-
тельно сильнее возможности получения выгоды. Поэтому не сле-
дует ожидать от них действий на основе значения МО, взвешива-
ющего прибыли и потери.
В то же время функции полезности часто в достаточной степе-
ни линейны (см. рис. 19.2). В таком случае значение МО (которое
выражается линейной зависимостью) является хорошим прибли-
жением и может использоваться для выработки решений в усло-
виях риска.
Функции полезности у различных экспертов могут быть различ-
ными и похожими. Например, руководители из группы 2 страшатся
потерь больше, чем руководители из группы 1.
Не всегда удается предсказать функции полезности, которые
(см. рис. 19.2) являются результатами экспериментальной провер-
ки гипотезы о том, что руководители исследований (группа 2) в
значительно большей степени опасаются потерь, чем руководите-
ли промышленных предприятий (группа 1). В действительности
это не так.
Функции полезности в большинстве случаев зависят от многих
частных факторов: нужда в деньгах, одобрение, безопасность, уве-
ренность, волнение, служебное отношение и т. п., которые меняют-
ся с течением времени и влияют на конкретные функции полез-
ности.
ГЛАВА 20
ТЕОРИЯ СТАТИСТИЧЕСКИХ РЕШЕНИЙ И ЦЕННОСТЬ
ИНФОРМАЦИИ
20.1. МЕТОД ПРОТОТИП^
В предыдущей главе была проанализирована проблема выбора
радикального или консервативного метода разработки специали-
зированной операционной системы для СОС. Было найдено, что
она представляет собой задачу выбора в условиях неопределен-
ности (см. табл. 19.2).
Также была показана трудность поиска хорошей альтернативы
при полном отсутствии информации о возможных исходах. Нако-
нец, было сделано заключение о том, что такая информация могла
бы дать значительный экономический эффект при решении задач
выбора в условиях неопределенности.
В таком контексте рассмотрим идею построения прототипа,
реализующего основные функции гипермонитора, существенно по-
вышающего риск для радикального метода. Допустим, что за
243
10 тыс. долл, можно провести разработку, испытать и оцени гь
прототип с тем, чтобы установить пригодность концепции гиперу( I
нитора в конкретных применениях, и что этот прототип может бы,I
разработан в приемлемые сроки.
При благоприятном исходе, т. е. в случае, если прототип по Д
тверждает правильность концепций, можно продолжить разработя
ку промышленной версии операционной системы в соответствии Я
концепциями гипермонитора. Выигрыш в этом случае составит’
150 тыс. долл, с вычетом 10 тыс. долл, затрат на прототип, или
J40 тыс. долл При неблагоприятном исходе (прототип оказывает-
ся неудачным) необходимо продолжить разработку операционн! и
системы стандартными методами. В этом случае выигрыш будет
равен 30 тыс. долл, за вычетом 10 тыс. долл., т. е. 20 тыс. долл.
Если эти два варианта равновероятны, то математическое ожида-
ние выигрыша будет составлять
0,5-'140 тыс. долл. + 0,5-20 тыс. долл. = 80 тыс. долл.
20.2. МАТЕМАТИЧЕСКОЕ ОЖИДАНИЕ ДОХОДА ПРИ ПОЛНОЙ
ИНФОРМАЦИИ
Сравним МО дохода и полезности для метода прототипа с со-
ответствующими значениями для РМ и КМ. Применяя функцию
полезности (рис. 20.1) в предположении равной вероятности ис-
ходов, получим следующие результаты:
Метод МО дохода, тыс. долл. МО полезности
РМ 60 0
км 30 5
Прототип 80 11.5
244
Затрачивая 10 тыс. долл, на получение информации о действи-
тельном положении вещей, можно повысить МО дохода на 20 тыс.
долл, по сравнению с его значением при первоначальном выборе
Если повысить затраты на получение такой информации даже до
30 тыс. долл., результат все еще будет положительным. Таким об-
разом, можно сказать, что МО дохода при полной информации о
методах разработки равно 30 тыс. долл.
20.3. УЧЕТ НЕПОЛНОЙ ИНФОРМАЦИИ
В общем случае не представляется возможным получить пол-
ную информацию о действительном положении вещей методом раз-
работки прототипа или другими методами повышения знаний о
конечном продукте. Существует два источника неопределенности,
которые могут быть выражены вероятностями:
Р (ИР|НС) (читается: «вероятность ИР при условии НС») —
вероятность того, что исследование (И, т. е. прототип) приводит
к выбору радикального (Р) метода при условии, что в действи-
тельности этот метод окажется неудачным (НС — неблагоприят-
ный случай),
Р (ИР|БС) — вероятность того, что исследование приводит к
выбору радикального метода при условии, что он действительно
оказывается удачным (БС — благоприятный случай).
Вероятность Р (ИР|НС) обычно отличается от нуля, так как
прототип не всегда может удовлетворительно воспроизводить неко-
торые технические детали или может оказаться весьма приближен-
ной моделью промышленной системы. Таким образом, прототип
может и подтвердить выбор радикальной альтернативы, хотя в
действительности концепция гипермонитора может оказаться не-
удачной. Вероятность Р (ИР|БС) обычно не равна 1,0, поскольку
прототип может содержать ошибки, которые будут ликвидированы
в промышленной системе. Это означает существование вероятно-
сти того, что прототип продемонстрирует непригодность гипермони-
тора и подтвердит тем самым выбор консервативной альтернативы,
тогда как на самом деле радикальная может оказаться удачной.
20.4. ПРИМЕР
Допустим, что в результате исследований прототипа стоимостью 10 тыс. долл,
получены следующие значения для неопределенностей:
Р(ИР|НС) =0,20, Р(ИР|БС) =0,90.
Для выбора консервативной (К) или радикальной (Р) альтернативы вычис
лим МО дохода МОД (ИР, ИК) в результате исследования прототипа. В вычис-
лениях МО примем, что альтернативы равновероятны, т. е. Р(БС) =Р(НС) =0,50.
Тогда получим:
МОД(ИР, ИК)=Р(ИР) (выигрыш радикальной альтернативы)+
+Р(ИК) (выигрыш консервативной альтернативы) =
= Р(ИР) [Р(БС|ИР) -150 тыс. долл.+Р(НС|ИР),- (—30 тыс. долл.)] +
-|-Р(ИК)-30 тыс. долл.
245
В это» формуле использованы неопределеньь™1 вероятности: Р(ИР), Р(ИЬ
Р(БС1ИР) и .°(НС|ИР). Известны из постановки задачи соотношения-
Р(БС) =Р(НС) =0,50; Р(Ио|НС) =0,20; Р(ИР|БС) =0,90.
20.5. ФОРМУЛА БАЙЕСА
Знание значений величин в уравнении (20.1) и основных соот-
ношений теории вероятностей позволяет получить конечный резуль-
тат. Основные соотношения таковы:
Р(ИР) =Р(ИР|БС) -Р(БС)+Р(ИР|НС) -Р(НС); (20.2)
Р(И\) = 1—Р(ИР); (20.3)
Р(БС|ИР)=Р(ИР|БС)-Р(БС)/Р(ИР); (20.4)
Р(НС|ИР) = 1—Р(БС|ИР). (20.5)
Уравнение (20.2) соответствует тому, что могут быть два
случая выбора радикальной альтернативы после исследования про-
тотипа:
1. Выбор радикального метода, когда он действительно явл -
ется успешным. Вероятность этого равна Р(ИР|БС)-Р(БС).
2. Выбор радикального метода, когда он в действительности
приводит к неудаче. Вероятность этого равна Р(ИР|НС)-Р(НС).
Уравнение (20.2) устанавливает равенство вероятности выбора
радикального метода сумме вероятностей двух взаимоисключаю-
щих случаев.
Уравнение (20 3) дополняет (20.2). Оно объясняет два случая
выбора, в которых исследование прототипа приведет к консерва-
тивной альтернативе. Вероятность консервативной альтернативы
равна единице минус вероятность радикальной альтернативы.
Уравнение (20.4) выражает вероятность благоприятного исхода
при радикальном методе при условии, что исследование прототипа
привело к его выбору, и определяется отношением
Р (БС I ИР)_ ? (выб°Ра РМ в случае его удачного завершения)
Р (выбора РМ)
Уравнение (20.4) является частным случаем формулы Байеса
и основным для определения МО дохода при использовании несо-1
вершенного прототипа для выбора предпочтительного метода раз-
работки системы.
Подставляя известные значения в уравнения (20.2) — (20.5),
получаем искомые вероятности для вычисления МО дохода по фор-
муле (20.1):
Р(ИР) = 0,500,00 + 0,50-0,20=0,55;
Р(ИК) = 1—0,55=0,45;
Р(БС|ИР) = 0,50-0,90/0,55=0,82;
Р(НС|ИР) = 1—0,82=0,18:
МОД(ИР, ИК) = 0,55(0,82-150 тыс. долл. 4- 0,18 (—30 тыс.
долл.)] + 0,45-30 тыс. долл. =
=0,55-117,6 тыс. долл. + 13,5 тыс. долл. =
=78,2 тыс. долл.
246
Так как наибольшее МО дохода1, полученное без разработки
прототипа, равно 60 тыс. долл, при использовании радикального
метода, то МО дохода при неполной информации, обеспечиваемой
исследованием прототипа, равно 18,2 тыс. долл. Хотя информация
и неполная, эта величина превышает 10 тыс. долл., которые затра-
чены на разработку прототипа.
20.6. МАКСИМИЗАЦИЯ ОЖИДАЕМОЙ ЧИСТОЙ СТОИМОСТИ
ПРИ РАЗРАБОТКЕ ПРОТОТИПА
Для определения чистой стоимости при различных затратах на
разработку прототипов, обеспечивающих различные уровни на-
дежности предсказания результатов, можно воспользоваться фор-
мулой Байеса. Этот метод в сжа-
том виде представлен в табл. 20.1
и на рис. 20.2. Поясним на при-
мере. Затрачивая 20 тыс. долл, на
разработку прототипа, можно по-
высить надежность результатов
исследований, устранить несколь-
ко источников неопределенности,
уменьшить Р(ИР|НС) до 0,10 и
повысить Р(ИР|БС) до 0,95.
В таком случае ожидаемый доход
МО чистой
прототипа
тыс. долл.,
составит 86,8 тыс. долл, а МО Рис. 20.2. Сравнение
дохода от информации, получен- стоимости и стоимости
ной при исследовании прототипа,
составит 26,8 тыс. долл. Чистая стоимость составит 6,8
т. е. меньше, чем при построении прототипа за 10 тыс. долл.
В данном случае лучшим решением являются затраты 10 тыс.
долл, на разработку прототипа. Меньшие затраты не обеспечивают
Таблица 20.1
Сравнение МО чистой стоимости и стоимости прототипа
Стоимость прототипа, тыс. долл. Р(ИР|НС) Р(ИР|БС> МО дохода, тыс. долл. МО дохода от инфор- мации, тыс. долл. МО чистой стои- мости при раз- работке прото- типа, тыс. долл.
0 0,30 60,0 0 0
5 0,30 0,80 69,3 9,3 4,3
10 0,20 0,90 78,2 18,2 8,2
20 0,10 0,95 86,8 26,8 6,8
1- 30 0,00 1,00 90,0 30,0 0
1 Строго говоря, вместо МО дохода здесь следовало бы вычислять МО полез-
ности. Но так как вид уравнений и окончательные выводы одинаковы, для упро-
щения используется МО дохода.
247
удовлетворительного выигрыша, а большие обеспечивают большую
информацию дорогой ценой, что тоже приводит к уменьшению вы-
игрыша.
20.7. ФОРМАЛЬНОЕ ОПРЕДЕЛЕНИЕ МО ДОХОДА ОТ ПОЛНОЙ
ИНФОРМАЦИИ
Определения. Дадим общую формулировку задачи принятия
решения при неопределенности
Пусть дан набор т альтернатив Ль А2, ..., Ат:
в ситуации, имеющей п возможных состояний Si, S2, ..., Sn,
вероятности которых равны P(St), P(S2), .. P(Sn),
значения выигрышей от выбора альтернативы Аг в состоянии
Sj задаются матрицей выигрышей
Sx s2 ... sn
Л! V12 ... Vin
лг V21 Vw v2n
Лщ Vml Vm2 ... Vmn.
Выбрать альтернативу с максимальным МО выигрыша. В такой
формулировке выигрыш может выражаться в долларах, единицах
показателей качества, функции полезности или в других единицах.
В гл. 19 рассмотрены методы решения этой задачи при отсут-
ствии какой-либо информации о действительном положении вещей.
На основании экспертных оценок вероятностей каждого состояния
вычислим МО дохода (МОД) при выборе каждой альтернати-
вы Л,-:
МОД (Лг) =Р (SO Уг1 ДР (S2) vi2 +... +р (Sn) vin
и выберем альтернативу с максимальным МО:
МОДотс.ивф = max [Р (Sx)+... + Р (Sn)Vin]. (20.6)
i=
При наличии полной информации для каждого случая выберем
альтернативу с максимальным выигрышем:
МОДполн.инф = Р(SO ( max Vn) +...4-Р (Sn) ( max Vin). (20.7)
7=1,.. ,m i = l.m
Тогда МО дохода от полной информации
МОДПИ =МОДполн.инф-(МОД)отс.инф. =
- 2 P(Sj)( max Vs0- max V P(S7)Vy. (20.8)
f= 1 i = 1j
Иллюстрация. Вернемся к примеру выбора СОС для двух аль-
тернатив (здесь Л1 и Л2) с двумя возможными состояниями: БС
(благоприятный случай) и НС (неблагоприятный случай) и с рав-
ными вероятностями состояний:
24В
Альтернатива Выигрыш
5,=БС S,=HC
.4, (РМ) 150 —30
А2 (КМ) 30 30
р (Si) 0,5 0,5
В этом случае имеем
МОДотс.инф = max [0,5 150 + 0,5 - (—30); 0,5 • 30 + 0,5 - 30] =
—max [60; 30] = 60;
МОДполн.инф = 0,5тах(150; 30)+ 0,5 max (-30; 30) =
= 0,5-150+ 0,5-30 = 90;
МОДПИ =90 — 60 = 30.
20.8. МО ДОХОДА ОТ НЕПОЛНОЙ ИНФОРМАЦИИ
Если исследования обеспечивают полную информацию для за-
дачи выбора, всегда можно рекомендовать альтернативу, максими-
зирующую выигрыш. При этом рекомендуемые в результате иссле-
дований альтернативы ИА,- связаны с состояниями Sj следующими
соотношениями:
Р(ИАг |S7-) = 1,0, если At максимизирует для состояния Sf,
Р (ИAf |.$7)-= 0, 0 в противном случае.
На практике рекомендация альтернативы ИА,-' основана на не-
полной информации о состояниях. Так, для каждой альтернативы
Aj и состояния Sj вероятность Р(ИА,-|53) отражает степень воз-
можного отклонения рекомендаций от идеального случая (0,0 или
1,0) для соответствующей комбинации А, и S3. Сумма вероятностей
Р(ИА1|53) по всем состояниям S3 должна равняться 1,0, т. е.
2 Р(ИАг|£7.) = 1, 0,/=!,...,«. (20.9)
!=1
Общее выражение для МО дохода в решении задачи выбора
альтернативы среди ИА1, ИА2, ..., ИАт имеет вид:
МОД(ИАП ИА2,..., ИАга)= 2 ^(ИАа х
Х = 1
X МОД (выигрыш ОТ принятия ИА£) —
т Г п 1
= 2 ^(ИАг) 2 Р(5у|ИАг)Уу • (20.10)
«=1 L/=i J
В примере СОС (где ИА, являются ИР и ИК, a Sj суть БС и
НС) для вычисления МОД (ИАЬ ИА2, ..., ИАт) необходимы об-
249
щие формулы для вычисления Р(ИА,) и Р(5;|ИА,) по известным
значениям P(Sj) и P(I4A,|Sj). Эти формулы имеют вид
Р (ИА,-) = 2 Р А* । S>) Р (S/)’ <?0-10
Р (Sj | ИАг) = Р (ИА; | S,) Р (Sj)/P (ИА,-). (20.12)
Уравнение (20.12) представляет собой общий вид формулы
Байеса.
20.9. ПРОЦЕДУРА ОПРЕДЕЛЕНИЯ ДОХОДА ОТ ИНФОРМАЦИИ
С помощью выведенных выше формул можно описать процеду-
ру определения дохода от информации, зависящую от глубины ис-
следований (простой прототип, детальный прототип, моделирова-
ние, анкетирование и т п.) и обеспечивающую наилучшее соотно-
шение между затратами на выполнение исследований и доходами
от результатов применения полученной при этом информации. Она
состоит в следующем.
1. Сформулировать набор альтернатив методов разработки ин-
формационной системы At, Az, . .., Ат
2. Определить всевозможные ситуации Sb S2, . . Sn, влияющие
на результат применения методов.
3. Определить элементы У,, матрицы выигрышей, где Уц —
выигрыш от применения метода А, в случае Sj.
4 Определить вероятности Р (Sj) каждой ситуации Sj.
5. Вычислить А4ОДотс.инф, А4ОД полп.инф и МОДПИ по форму-
лам (20.6) — (20.8).
6. Если величиной МОДПИ можно пренебречь, то не стоит те-
рять время и усилия на дополнительные исследования. В этом
случае следует выбрать метод, обеспечивающий наибольшее
МОДотс.инф, и приступить к его реализации. Перед этим, правда,
можно оценить чувствительность МОДПИ к основным параметрам
и пересмотреть проведенные исследования.
7. Если МОДПИ значительна, то она дает грубую 1 верхнюю
оценку допустимых затрат на исследование ситуаций. В этих пре-
делах определить наиболее обещающий тип исследований и его
оценочную стоимость СД
8. Для каждого типа исследований определить Р(ИА;|5Д —
вероятность того, что оно приведет к рекомендации альтернативы
Ai в ситуации Sj
9. Вычислить МОД от использования информации, полученной
при исследовании с номером k, МОД (Иь) по уравнениям
(20.10) — (20.12).
1 Это объясняется наличием сопутствующих достоинств исследований: накоп-
ленный опыт, концептуальная проверка, анализ чувствительности, заинтересован-
ность пользователя и заказчика и т. п., которые не учитываются при количествен-
ном вычислении чистой стоимости.
250
10. Вычислить чистую стоимость по каждому исследованию
ЧС(И,) = МОД(ИЛ)-СЛ.
' II. Выбрать наиболее предпочтительный метод исследований,
основываясь на следующих данных:
а) какова относительная чистая стоимость от применения ис-
следования?
б) все ли значения чистой стоимости положительны?
в) будут ли готовы результаты исследований к заданному сро-
ку, чтобы помочь в выборе альтернативы?
г) какова относительная значимость проведения исследований?
20.10. ПРИМЕНЕНИЕ ПРОЦЕДУРЫ ОПРЕДЕЛЕНИЯ ДОХОДА ОТ ИНФОРМАЦИИ
В ИНЖЕНЕРНОМ ПРОГРАММИРОВАНИИ
Приведенная процедура помогает решению многих ключевых
проблем выбора в инженерном программировании следующего
типа.
Сколько средств необходимо затратить на получение дополни-
тельной информации и аналитические исследования для выбора
решения?
В инженерном программировании наиболее важными являются
следующие четыре проблемы.
1. Какие средства надо затратиь на фазе исследования осущест-
вимости проекта (анкетирование и опрос пользователей, планиро-
вание мероприятий, концептуальный анализ, моделирование, про-
гнозирование спроса, распределение заданий), прежде чем остано-
вить свой выбор на конкретном варианте проекта?
2. Какие средства надо затратить на анализ альтернативного
изделия (распределение заданий, расчленение работ, сквозной кон-
троль, анализ производство — закупка и аренда — потребление),
прежде чем остановить свой выбор на конкретном изделии?
3. Какие средства надо затратить на анализ риска (имитация,
исследование прототипа, изучение взаимодействий с пользователя-
ми, распределение заданий, моделирование, анализ чувствитель-
ности), прежде чем конкретизировать требования на изделие и
пути реализации проекта?
4. Какие средства надо затратить на верификацию и подтвер-
ждение (выработка требований к ВП, проектирование ВП, выра-
ботка требований к тестированию, доказательство правильности
программ, критическое тестирование, реальные испытания), преж-
де чем приступить к эксплуатации программного изделия?
20.11. РУКОВОДСТВО ПО ПРОЦЕДУРЕ ОПРЕДЕЛЕНИЯ ДОХОДА
ОТ ИНФОРМАЦИИ
Так как описанные ситуации часто встречаются в инженерном
программировании, процедура дает весьма удобный пошаговый
метод решения проблем выбора путем проведения необходимого
251
анализа и логического обоснования выбранного решения по срав-
нению с другими подходами.
Процедура определения дохода от информации не является
жестко зафиксированным рецептом. Некоторые шаги включают
экспертную оценку трудно определимых величин. Особенно это
относится к величине выигрыша на шаге 3, вероятности конкретной
ситуации на шаге 4 и условной вероятности Р (HAj|S3) на шаге 8
В большинстве случаев можно ограничиться менее формальной
версией этой процедуры.
Даже неформальный метод оказывает большую услугу, посколь-
ку он объединяет основные принципы устранения общих серьезных
ошибок, часть из которых рассматривается в следующем разделе.
Ниже приведены основные принципы для метода определения
дохода от информации с рекомендациями, при каких обстоятельст-
вах следует увеличивать затраты для получения полной информа-
ции при выборе предпочтительной конкретной альтернативы.
Обстоятельство 1.
Существуют привлекательные альтернативы с большим диапа-
зоном изменения выигрыша, зависящего от критических ситуаций.
Если дипазон изменений невелик, можно остановиться на одной из
привлекательных альтернатив без риска значительных потерь.
Обстоятельство 2.
Вероятность возникновения критических ситуаций является
значительной. В противном случае опять можно сделать выбор без
особого риска. Вероятность ситуаций с чрезвычайно большой раз-
ницей в выигрышах должна быть ниже, чем с меньшей разницей.
Обстоятельство 3.
Исследования должны обеспечивать высокую вероятность точ-
ного определения конкретной критической ситуации. Иначе иссле-
дования не уменьшают существенно степень риска потерь из-за
принятия неверного решения.
Обстоятельство 4.
Затраты на исследования и сроки их проведения не должны
уменьшать чистую стоимость, обусловленную применением их ре-
зультатов. Мало толку в результатах, если расходы на их получе-
ние превышают выигрыш или они получены слишком поздно.
Обстоятельство 5.
Выполняемые исследования приводят к дополнительным резуль-
татам. Иногда можно оправдать дополнительные исследования
приобретенным опытом, сплочением коллектива, установлением
тесных контактов с заказчиком или подтверждением проекта.
20.12. ОШИБКИ, ОБНАРУЖИВАЕМЫЕ МЕТОДОМ ОПРЕДЕЛЕНИЯ ДОХОДА
ОТ ИНФОРМАЦИИ
Учет обстоятельств, сформулированных в предыдущем разделе,
способствует устранению некоторых серьезных ошибок в инженер-
ном программировании. Ниже приведены часто встречающиеся
ошибочные рекомендации.
252
Ошибка 1.
Для исследования осуществимости, сложного ПО, работающего
в реальном масштабе времени, необходимо всегда применять мо-
делирование. И действительно, в таких случаях моделирование ча -
сТо играет важную роль. Тем не менее многие модели приводят к
напрасной трате усилий в соответствии с вышеуказанными реко-
мендациями. Некоторые модели практически бесполезны, посколь-
ку не помогают определять множество входных воздействий (см
обстоятельство 3). Некоторые из них требуют длительных разрабо-
ток, и результаты моделирования получают через неделю после
принятия решения относительно метода разработки или после за-
вершения проверки ключевых моментов проекта (см. обстоятель-
ство 4).
Ошибка 2.
Необходимо всегда разрабатывать ПО дважды. Из руководст-
ва следует, что прототип (двойная разработка) является полезным
инструментом. Однако обычно уже существуют прототипы разра-
батываемого ПО и построение нового прототипа ничего нового не
дает (см. обстоятельства 1 и 2).
Ошибка 3.
Разработка ПО обязательно должна проводиться методом свер-
ху — вниз. Строго говоря, этот метод не позволяет проектировать
модуль более низкого уровня до полной разработки модулей верх-
него уровня, поскольку их частичное изменение из-за ошибки обыч-
но приводит к большим затратам на переработку программ высо-
кого уровня. Обстоятельства 1 и 2 в таком случае рекомендуют
проведение дополнительного анализа степени риска на фазах ана-
лиза требований и проектирования изделия.
Ошибка 4.
Каждый участок программы должен быть проверен на коррект-
ность. Доказательство правильности программ остается дорого-
стоящим мероприятием, хотя оно полностью вытекает из обстоя-
тельства 3. По обстоятельствам 1 и 2 применение методов доказа-
тельства правильности рекомендуется в тех случаях, когда цена
неверного функционирования ПО слишком высока, например в
случаях возможной потери жизни, риска для национальной без-
опасности, финансового краха. Если же эта цена мала, то не сле-
дует применять метод доказательства правильности для получения
Дополнительной информации (см. обстоятельство 4).
Ошибка 5.
Проверка номинальных режимов является достаточной Эта
ошибка прямо противоположна ошибке 4. Если цена ошибки в ПЭ
высока, было бы опрометчиво исключать проверку ПО в экстре-
мальных режимах или проводить строгую верификацию программ.
20.13. КРАТКОЕ ЗАКЛЮЧЕНИЕ
Другая полезная функция метода определения дохода от ин-
формации — дать ответ на вопрос, поставленный в разд. 15.6: «Как
253
определить достаточность анализа оценки стоимость — эффектна
ность?». Изложенные выше обстоятельства обеспечивают надеж
ный путь к первичному ответу, процедура определения дохода от
информации целиком определяет более детальную последовательЛ
ность шагов для выявления необходимого объема и области тща-
тельного анализа стоимость — эффективность.
Наконец, стоит еще раз подчеркнуть ценность информации для
более качественного принятия решения при выборе методов раз-
работки ПО и информационных систем.
Например, в области разработки СОС для системы резервиро.
вания авиабилетов можно было бы учитывать запросы пассажиров.
Пять руководящих принципов (обстоятельств) помогают упорядц
чить оценку этой возможности. Так, обстоятельство 1 требует опре-
деления того, как эта информация повлияет на выигрыш в перспек-
тиве (предсказание сезонной загрузки авиалиний и улучшение рас-
писания полетов, предоставление пассажирам их любимых мест н
блюд для повышения удобств во время полета и обеспечения по-
вторных заказов на билеты и т. п.). Другие обстоятельства помо-
гают оценить МО выигрыша от информации такого сорта.
254
ЧАСТЬ 4
ИСКУССТВО ОЦЕНИВАНИЯ СТОИМОСТИ ПО
В ч. 1 и 2 этой книги были обсуждены основное назначение и
структура ЖЦПО, а также были представлены базовая и проме-
жуточная КОМОСТ для оценивания величины и распределения за-
трат, необходимых для разработки программного изделия и его
сопровождения в течение жизненного цикла. В ч. 3 было показано,
каким образом эти методы можно было бы объединить с общими
методами экономики для получения ряда методик инженерного
программирования при принятии основных решений по проблемам
ЖЦПО.
Часть 4 возвращает нас к оцениванию стоимости ПО. Главная
ее цель — дать более подробные сведения в этой области. В этой
части представлены детальная КОМОСТ — наиболее точная и пол-
ная из иерархии моделей, а также принципы построения КОМОСТ
высших уровней. Здесь же приведены основные средства, методы и
информация, существенные для практического управления стои-
мостью ПО и ее оценивания. Кроме того, в этой части дан обзор
состояния искусства оценивания стоимости ПО и указаны темы
дальнейших исследований, которые улучшили бы понимание во-
проса и точность оценок стоимости.
Часть 4 состоит из трех подчастей. Часть 4А (гл. 21 и 22) рас-
крывает практические аспекты оценивания стоимости ПО Часть
4Б посвящена детальной КОМОСТ, а ч. 4В — оцениванию стоимо-
сти ПО как средства более эффективного управления ЖЦПО.
ЧАСТЬ 4А
МЕТОДЫ И ПРОЦЕДУРЫ ОЦЕНИВАНИЯ СТОИМОСТИ ПО
Наличие хорошей модели оценивания стоимости ПО еще не га-
рантирует получения хороших оценок стоимости. Как и любая
другая модель, связанная с ЭВМ, модель оценивания стоимости
работает по принципу «что посеешь, то и пожнешь»: если будет
заложен недостаточный объем данных или неточно определены рей-
тинги атрибутов, то и полученные оценки стоимости будут соответ-
ствующими.
Отсюда можно сделать два главных вывода:
255
1. Необходима методика работы с моделью оценивания стон»,
сти ПО, которая поможет определить набор входных данных хл
модели стоимости, соответствующий поставленным целям. В гл. gj
приводятся семь шагов такого процесса. Два из них обосновывав
необходимость использования нескольких методов оценивания
экспертную оценку, алгоритмическую модель, оценку по аналогу
и т. д., а также сравнения и взаимного уточнения полученных раз.
личными методами результатов.
2. Для контроля использования алгоритмических моделей оце
нивания стоимости ПО необходимо применять другие методы
В гл. 22 представлены основные альтернативные методы, в частно-
сти эффективный расширенный метод «Дельфы», и сравнительная
оценка их сильных и слабых сторон.
ГЛАВА 21
СЕМЬ ОСНОВНЫХ ШАГОВ ОЦЕНИВАНИЯ СТОИМОСТИ ПО
Для получения надежной оценки стоимости ПО необходимо
сделать гораздо больше, нежели просто подставить в готовую фор-
мулу числовые значения и получить результат. В этой главе опи-
сывается семишаговый процесс оценивания, который свидетельст-
вует, что сама эта работа является минипроектом и, следовательно,
должна планироваться, подвергаться контролю и выполняться до
конца.
Соответствующими шагами являются:
1) формулировка целей;
2) планирование требуемых данных и ресурсов;
3) уточнение требований к ПО;
4) возможно более полная проработка деталей;
5) использование нескольких независимых методов и средств;
6) сравнение и взаимное уточнение оценок;
7) плановый учет.
Каждый из этих шагов подробно обсуждается в разд. 21.1—21.7.
21.1. ШАГ 1: ФОРМУЛИРОВКА ЦЕЛЕЙ
При оценивании стоимости ПО много усилий может быть за-
трачено впустую на сбор информации и получение оценок пара-
метров, не имеющих отношения к действительно необходимым
оценкам. Однажды, например, для обоснования решения об ориен-
тации проекта на различные модели ЭВМ было проведено чрезвы-1
чайно тщательное оценивание такой возможности. Для принятия
же решения требовалась только основная оценка стоимости пере-1
носа, и поэтому, когда было принято решение отказаться от пере-1
хода на различные модели ЭВМ, большая часть проделанной рабо-
ты и тщательного анализа пропали даром. Очень важно поэтому в
качестве первого шага сформулировать цели оценивания стоимости!
и руководствоваться этими целями для определения уровня дета-
256
дзации и затрат, требуемых для выполнения последующих шагоь.
Цели и фазы, или уровень знаний. Главным фактором, который
домотает установить цели оценивания стоимости, является теку-
щая фаза ЖЦПО. Она в большой степени соответствует уровню
знаний о ПО, стоимость которого оценивается, а также уровню ре-
шений, принимаемых по результатам оценивания.
Фазы и контрольные этапы
Рис. 21.1. Точность оценивания стоимости ПО по фазам
Рисунок 21 1 иллюстрирует точность, с которой могут быть по-
лучены оценки стоимости ПО, представленную в виде функции фа-
зы ЖЦПО (горизонтальная ось), или уровень знаний о проделан-
ной работе над ПО. Указанный на рис. 21.1 уровень неопределен-
ности относится к компоненту ПО, реализующему взаимодействие
человека и машины. Когда впервые рассматриваются альтернатив-
ные понятия для новой прикладной программы, оценки ее стоимо-
сти могут отличаться от конечного значения примерно в 4 раза в
ту или другую сторону *. Такой диапазон оценок обусловлен уров-
нем неопределенности на данном этапе знаний о конечном виде
продукта. Для компонента ПО, связанного с взаимодействием че-
1 Это значение определялось субъективно и предназначалось для представле-
ния 80 %-ного доверительного интервала, т. е. «в рамках четырехкратной ошибки
в 80 % случаев».
9 Зак 628 257
ловека и машины, например, на данном этапе неизвестны ни кат
юрия пользователей (клерки, специалисты по ЭВМ, среднее звено
управления и т. д.), ни классы данных (предварительно стреда!,
тированные или нет, численные или текстовые, цифровые или ана-
логовые), с которыми будет работать эта система. До тех пор пока
эти неопределенности не будут сняты, коэффициент 4 для отклоне-
ния стоимости не вызывает удивления.
Эта неопределенность уменьшается, как только завершаете!
фаза анализа осуществимости и фиксируется конкретный принцип
функционирования. На этом этапе отклонения от оценок в обе сте-
роны уменьшается до коэффициента 2 Этот диапазон вполне
объясним, поскольку еще не уточнены такие детали, как конкрет-
ный язык запросов пользователей или специальные функции, реа-
лизуемые микропроцессором интеллектуального терминала. Эти
вопросы будут разрешены во время разработки спецификаций тре-
бований на ПО и тогда можно оценить стоимость ПО с точностью
до коэффициента 1,5. После завершения их разработки и подтвер-
ждения проектных спецификаций, изделия будут решены такие
вопросы, как структура внутренних данных программного изделий
и конкретные методы буферизации обмена между терминальным
микропроцессором и центральными процессорами, с одной стороны,
и между микропроцессором и устройством управления дисплеем —
с другой. В это время оценка должна быть точной до коэффициен-
та 1,25. К оставшимся источникам неопределенности относятся
конкретные алгоритмы управления многопрограммной работой, об-
работки ошибок, инициализации и завершения сеансов работы
и т. д. ’. Эти вопросы будут решены к концу фазы детального про-
ектирования, но и тогда сохранится остаточная неопределенность
порядка 10%, связанная с тем, насколько хорошо программиста
понимают спецификации, в соответствии с которыми они должны
кодировать программу. (Сюда же относится такой фактор, как
текучесть кадров на фазах разработки и тестирования.)
Следствия оценивания. Основной вывод, вытекающий из
рис. 21.1, состоит в необходимости быть последовательным при оп-
ределении целей оценивания для различных компонентов програм-
много изделия. Если понимание взаимодействия человека и маши-
ны находятся, например, на уровне принципов функционировг ния,
то работа по определению и оцениванию стоимости переноса на
уровне детального проекта, как правило, окажется пустой тратой
сил. (Ситуация, когда стоимость переноса на порядок больше сто-
имости компонента ПО, реализующего взаимодействие человека
и машины, является исключением.)
В общем случае необходимо достигать сбалансированного на-
бора целей оценивания, который бы давал примерно одинаковую
абсолютную величину уровня неопределенности для всех компо-
’ При коэффициенте 1,25 (80 ... 125 %) хороший руководитель проекта мо-
жет обычно сделать оценивание затрат на разработку ПО самовыполняемыы
(см. гл. 32).
258
нентов ПО. Пусть, например, оценка стоимости компонента ПО,
связанного с взаимодействием человека и машины, составляет
1000 тыс. долларов и определена на уровне спецификаций требова-
ний на ПО (скажем, от 667 тыс. до 1500 тыс. долл). Если при этом
стоимость переносимого компонента составляет примерно 500 тыс.
долл., то мы вправе определить ее на уровне понятий функциони-
рования, поскольку диапазон ее оценки (250 тыс. ... 1000 тыс.
долл.) имеет примерно то же значение, что и диапазон оценки сто-
имости компонента обеспечения взаимодействия человека и ма-
шины.
Другое следствие оценивания — каждая оценка стоимости дол-
жна сопровождаться указанием степени ее неопределенности.
Относительная и абсолютная оценки. В других ситуациях оце-
нивание стоимости переноса может оказаться необязательным да-
же на уровне понятий функционирования. Предположим, например,
что оценивают стоимость закупки или разработки компонента ПО,
причем стоимость переноса в обоих случаях примерно одинакова.
Тогда для принятия решения о закупке или разработке оценки сто-
имости переноса вообще не нужны. Конечно, на каком-либо после-
дующем этапе потребуется оценка стоимости всего жизненного
цикла, включая оценку стоимости переноса, но полученные к этому
времени знания о системе упростят их получение
Главный момент здесь — это убедиться в том, что цели оцени-
вания согласованы с запросами человека, принимающего решение
на основе полученных оценок *. Таким образом, здесь рассматрива-
ются те же вопросы (обеспечение баланса стоимости получения
информации со значением этой информации для человека, прини-
мающего решение), которые рассматривались в гл. 20.
Оптимистические и консервативные оценки. Часто при анализе
стоимости с целью решения дилеммы закупки или разработки ком-
понентов ПО либо дилеммы разработки системы или отказа от
этого уже на ранней стадии анализа становится ясно, что наиболее
вероятным его результатом будет принятие некоторого конкретно-
го решения. В таком случае можно пересмотреть цели, чтобы по-
пытаться продемонстрировать следующее:
даже при использовании консервативных предположений отно-
сительно варианта А и оптимистических предположений относи-
тельно варианта В первый более выгоден.
Такой пересмотр целей имеет два основных преимущества. Во-
первых, он повышает уверенность в правильности сделанного выбо-
ра. Во-вторых, существование оптимистических и консервативных
предположений часто облегчает оценивание стоимости. Можно бы-
ло бы предположить, например, что потенциально адаптируемый
компонент ПО полностью адаптируем (оптимистическое предполо-
жение) или полностью неадаптируем (консервативное предположе-
1 Общий подход к использованию информации о стоимости в задачах приня-
тия решений дан в работе [111J.
259
ние), вместо того, чтобы анализировать адаптируемость для опр€.
деления корректирующего коэффициента адаптации.
По отношению к целям оценивания это означает, что по мере
работы их необходимо пересматривать и изменять, когда это ста-
новится выгодным (т. е. можно начать с цели определения оценки
с точностью уровня спецификации требований, но при дальнейшем
анализе перейти к цели определения оценки с точностью уровня
понятий функционирования).
Краткие рекомендации. В заключение приведем три главные
рекомендации по определению целей получения стоимостных
оценок:
1. Согласуйте цели оценивания с потребностями в информации,
способствующей принятию решений. (Абсолютные оценки для пла-
нирования затрат труда и ресурсов, относительные оценки для вы-
бора «или — или», оптимистические или консервативные оценки
для повышения уверенности в правильности выбора.)
2. Сбалансируйте точности оценок стоимости для различных
компонентов системы. Это означает, что абсолютная величина уров-
ня неопределенности для каждого компонента должна быть при-
мерно одинаковой, если в процессе принятия решения все компо-
ненты имеют одинаковый вес.
3. Постоянно возвращайтесь к целям оценивания и изменяйте
их, когда это необходимо. Следствием этой рекомендации являет-
ся то, что бюджетные решения, принимаемые на ранних фазах,
должны влиять лишь на следующую фазу. Как только подтвер-
жденный проект изделия закончен, полный бюджет разработки мо-
жет быть установлен без особого риска.
21.2. ШАГ 2: ПЛАНИРОВАНИЕ ТРЕБУЕМЫХ ДАННЫХ И РЕСУРСОВ
Очень часто можно услышать следующий диалог:
Взъерошенный администратор: «Получено предложение, кото-
рое должно быть подписано к полудню, так как мы можем доста-
вить его вечерним самолетом в Вашингтон. Вы можете быстро сде-
лать для меня оценку стоимости ПО?»
Эксперт по стоимости ПО: «Когда Вы хотите это получить???»
Обычно такой диалог (и множество аналогичных ему) ведет к
чрезвычайно неточной оценке стоимости ПО, которая становится
основой утвержденного задания (обычно недооцененного) для мно-
гих ничего не подозревающих разработчиков ПО, заслуживающих
лучшей участи.
Если работа по оцениванию стоимости ПО рассматривается как
минипроект, то она автоматически учитывается при разработке
плана проекта на ранней стадии. В табл. 21.1 приводится простая
общая форма плана проекта, которая естественным образом пере-
носится на минипроект оценивания стоимости.
Этот миниплан совсем не должен быть четким и подробным
документом, особенно если работа по оцениванию невелика. Но
даже неформальный предварительный список пометок для самого
260
таблица 21.1
рлан минипроекта оценивания стоимости ПО
1. Цель. Зачем должна быть получена оценка’
2. Результаты и сроки. Что предполагается получить в результате оценива-
ния и к какому сроку?
3. Ответственность. Кто ответствен за каждый этап? Где исполнители со-
бираются выполнять свою работу организационно? территориально?
н 4. Процедуры. Как предполагается выполнять работу? Какие средства и
методы оценивания стоимости будут использоваться? (см. гл. 22).
5. Требуемые ресурсы. Сколько данных, времени, денежных средств,. затрат
груда и т- Д- необходимо для выполнения этой работы?
6. Предположение. При каких условиях есть надежда получить указанные
оценки, имея перечисленные выше ресурсы (наличие основного персонала, ма-
шинного времени, данных пользователя)?
себя (зачем, что, кто, где, как, сколько и почему) по этой работе
часто будет предохранять от серьезных неприятностей руководите-
ля и тех разработчиков ПО, которые должны будут работать в
соответствии с полученными оценками. Пример плана оценивания
стоимости ПО для исследования осуществимости системы автома-
тизированного управления движением скоростного транспорта при-
водится в табл. 21.2.
Таблица 21.2
План оценивания стоимости ПО системы скоростного движенчя
1. Цель
Помочь в определении осуществимости управляемой с помощью ЭВМ систе-
мы скоростного движения для метрополитена.
2. Изделия и сроки
01.02.84. План оценивания стоимости.
15.02.84. Первый запуск модели стоимости.
22.02.84. Завершающий запуск модели стоимость
Завершение экспертных оценок.
29.02.84. Итоговый отчет по оцениванию стоимости, объединение и уточнение
экспертных и модельных данных. Точность в рамках коэффициента 2.
3. Ответственность
Исследование по оцениванию стоимости: исполнитель.'
Обеспечение модели стоимости: отдел прикладного ПО
Эксперты по оцениванию (2): отдел системного анализа
4. Процедуры
Для проекта будет использоваться модель СТОИМПО, с анализом чувстви-
тельности к сильно влияющим на стоимость атрибутам.
Эксперты для сопоставления данных будут контактировать с персоналом
соответствующих организацией в Сан-Франциско и Вашингтоне.
5. Требуемые ресурсы:
Исполнитель: 2 человеко-недели.
Эксперты по оцениванию: 3 человеко-дня каждый.
ЭВМ: 200 долл.
6. Предположения:
Глобальных изменений в спецификацию системы, датированную 15 января
1984 г., вноситься не будет.
Авторы спецификаций ответят на вопросы по размерам системы.
261
21.3. ШАГ 3: УТОЧНЕНИЕ ТРЕБОВАНИЙ К ПО
Если неизвестно, о разработке каких изделий идет речь, то и
точно оценить стоимость их разработки, по-видимому, нельзя. От
сюда следует, насколько важно иметь набор максимально недву
смысленных спецификаций на ПО (с точностью до ограничений
обусловленных целями оценивания).
Лучший способ определить, насколько оцениваемой является
спецификация на ПО, — это выяснить, насколько она тестируема.
Спецификация тестируема в такой степени, в какой кто-либС
может построить ясный тест, дающий ответ «да» или «нет» и опре.
деляющий соответствие разрабатываемого ПО данной специфика-
ции. Для тестируемости спецификация должна быть конкретной,
недвусмысленной и обладать по возможности количественными
характеристиками. Ниже приводятся примеры спецификаций, не
являющихся тестируемыми:
ПО должно обеспечивать взаимодействие с соответствующими
подсистемами;
ПО должно быть устойчивым;
ПО должно разрабатываться в соответствии с общепринятыми
стандартами;
ПО должно обеспечивать необходимую обработку во всех пре-
дусмотренных режимах,
использование машинной памяти должно быть оптимальным с
учетом дальнейшего расширения ПО;
ПО на 99,9999% должно гарантировать защиту информации
(или надежность, готовность к работе, человеческую безопасность,
когда эти термины еще не определены);
ПО должно гарантировать точность, достаточную для управле-
ния полетом;
ПО должно обеспечивать ответы на запросы о состоянии сбыта
в реальном масштабе времени.
Эти утверждения хороши как цели, но из-за неточности фор-
мулировок не могут служить основой для соответствующего теста
или точной оценки стоимости. Ниже приводятся более тестируемые
варианты последних двух требований.
ПО должно вычислять координаты самолета со следующей точ-
ностью:
±50 футов в горизонтальной плоскости;
±20 футов в вертикальной плоскости.
Время ответа системы не должно превышать:
для запросов типа А — 2 с; I
для запросов типа Б — 10 с;
для запросов типа В —2 мин;
причем, запросы типов А, Б, В подробно определены в специ-
фикациях.
Во многих случаях даже эти варианты требований будут недо-
статочно тестируемыми без дополнительных уточнений, например:
Относятся ли ограничения «±50 футов» и «не более 2 мин» к
262
среднему квадратическому отклонению, 90%-ному доверительному
интервалу или являются абсолютными?
Включаются ли время ответа задержки терминала, линий связи
или только время обработки ЭВМ?
Таким образом, для устранения неопределенности и неоднознач-
ности спецификаций, а также для обеспечения их тестируемости
часто требуется много дополнительных усилий. Однако такие за-
траты обычно хорошо окупаются по следующим соображениям:
так или иначе, но это придется сделать на фазе тестирования;
более раннее решение этих вопросов намного сократит расходы,
количество противоречий и неудач на более поздних этапах;
раннее выполнение этой работы позволит получить более точ-
ные оценки стоимости.
Во многих случаях невозможно убедиться в тестируемости всех
требований к ПО (см. обсуждение в разд. 4 3), или это потребует
больших затрат, чем нужно для реализации целей оценивания.
В таких случаях имеет смысл документировать любые предполо-
жения, сделанные при оценивании стоимости разработки ПО, осо-
бенно если это были оптимистические или консервативные предпо-
ложения (см. шаг 1).
21.4. ШАГ 4: ВОЗМОЖНО БОЛЕЕ ПОЛНАЯ ПРОРАБОТКА ДЕТАЛЕЙ
«Возможно» в данном случае означает «насколько это согласу-
ется с поставленными целями оценивания стоимости» в соответст-
вии с разд. 21.1. В общем случае, чем более тщательно будут сде-
ланы оценки, тем более точными они будут по следующим трем
основным причинам:
1. Как свидетельствует рис. 21.1 и соответствующее обсужде-
ние, более подробное исследование приводит к лучшему понима-
нию технических аспектов разрабатываемого ПО.
2. В соответствии с законом больших чисел, чем больше число
частей оцениваемого ПО, тем меньше отклонение итоговой оценки.
Если переоценка стоимости одной большой части ПО составляет
20%, то и ошибка в определении стоимости всего ПО составит
примерно столько же. Если же эта часть будет разделена на
10 малых, то недооценка даже большей их части будет компенси-
роваться переоценкой оставшихся, приводя к значительно меньшей
итоговой ошибке.
3. Чем тщательнее продумываются функции, выполняемые си-
стемой, тем меньше вероятность упустить стоимость некоторых
малозаметных компонентов ПО.
Для иллюстрации п. 3 на рис. 21.2 приводятся результаты экс-
периментов, в котором две бригады специфицировали и реализо-
вали небольшое (2000 ЧИК) программное изделие (ранняя диало-
говая версия детальной КОМОСТ, выполненная как групповой
проект инженерного программирования [45]). Наиболее примеча-
тельным на рис. 21.2 является то, что реальные вычисления по
Модели стоимости представляют лишь 2% всех исходных строк
263
кода в одном изделии и 3%—в другом. Большая часть остадВ
ных строк кода связана с реализацией менее заметных компоне*'
тов ПО, таких как обработка вспомогательных сообщений, обрД
ботка ошибок и пересылка данных. При оценивании стоимости ц
размера ПО такие функции часто упускают из виду, что являетсч
одной из главных причин недооценки стоимости ПО. Налицо силы
ная тенденция сосредоточивать внимание на наиболее заметных,
основных компонентах ПО и недооценивать или вообще забывать
второстепенные.
Рис. 21.2. Что делает программное изделие?
Представляет определенный интерес проверка гипотезы о том,
что распределение исходных строк кода в соответствии с гисто-'
граммой, приведенной на рис. 21.2, одинаково для всех изделий
ПО. В этом можно убедиться, построив аналогичные распределе-
ния для других изделий.
О размере ПО. Было бы удобно иметь такую формулу оценки
размера ПО, которая могла бы выразить, например, следующее.
Если в разрабатываемой операционной системе (ОС) такие-то
функции реализуются в полном объеме, такие-то в минимальном, а
такие-то не реализуются вообще, то оценка размера ОС составит
11±2 КЧИК.
К сожалению, количественная сторона инженерного программи-
рования не достигла такого уровня, чтобы хотя бы приблизиться к
подобным формулам. И не очевидно, что когда-либо этот идеал бу-
дет достигнут. Посвятив достаточно много времени сопоставлению
размеров данных и программ, ими представляемых, а также за-
264
^олдованному кругу поисков упрощенной формулы размера, соот-
ветствующий опыт можно было бы обобщить с помощью некоторых
аналогий.
1. Решение задачи автоматизации оценивания размера ПО об-
ладает многими чертами решения задачи автоматизации програм-
мирования. Например, и там, и там требуется достаточно подроб-
ная спецификация желаемого ПО для того, чтобы выяснить, что
некоторая часть ПО не будет подлежать оценке или соответственно
разработке. Наличие такой спецификации открывает длинный путь
получения оценки размера ПО.
2. Получение формулы для оценки размера ПО во многом сход-
но с определением формулы для оценки объема литературного
произведения. Обе относятся к изделиям с потенциально неограни-
ченными уровнями детализации, которые трудно представить в
виде, пригодном для оценивания размера. Например, рассмотрев
задачу определения оценки числа страниц в литературном произ-
ведении, в котором:
четыре основных персонажа, чьи судьбы тесно переплелись;
20 более или менее эпизодических персонажей;
три различных места действия;
действие разворачивается в течение двух лет;
пять подробных экскурсов в прошлое,
Вы начинаете относиться с большим уважением к проблеме оце-
нивания ПО. Это чувство может усилиться при знакомстве с рабо-
той [298] по оцениванию размера данных. В этом эксперименте
шести бригадам было предложено разработать одну и ту же про-
грамму (решение линейных уравнений методом исключения Гаус-
са), но при различных целях оптимизации. Как показано в
табл. 21.3, различные программы, реализующие одну и ту же функ-
цию, отличались по размеру в 5 раз.
Таблица 21.3
Цель бригады: оптимизировать Размер программы t ЧИК Человеко- часы Производи- тельность, чик/чч
Размер программы 33 30 1,1
Требуемую память 52 74 0,7
Ясность программы 90 40 2,2
Время выполнения 100 50 2,0
Затраты на разработку 126 28 4,5
Наглядность выводимых данных 166 30 5,5
В то же время задача оценивания размера ПО не обладает все-
ми аспектами задачи автоматизации программирования или оце-
нивания объема литературного произведения, так что есть некото-
рая надежда на прогресс в этой области. В настоящее время, од-
нако, детальному исследованию каждого компонента ПО для по-
лучения точной оценки его размера альтернативы нет.
265
Наиболее вероятно, что самый продуктивный подход к пробны
ме оценивания размера ПО связан с классификацией приложен^»
разработки (например, компиляторы, инструментальные средства ь
т. п.; см. также табл. 27.9).
Оценивание размера в системе ПЕРТ. Одним из следствий прв,
веденного выше обсуждения оценивания размера ПО является то
что необходимо быть осторожным, чтобы задача оценивания >а
мера не показалась проще, чем это есть на самом деле. Одним ш
методов, который, к сожалению, не учитывает этого, является м^,
тод оценивания размера в системе ПЕРТ [244]. Простейшая версия
метода состоит в оценке двух величин:
а — наименьший возможный размер ПО (скажем, 22 КЧИК).
b = наибольший возможный размер ПО (скажем, 64 КЧИК)'
В этом случае статистические уравнения системы ПЕРТ оцени-
вают ожидаемый размер ПО как
МО = (а + Ь) /2 = 43 КЧИК
со стандартным отклонением оценки * 1
о=(Ь — а)/6=7 КЧИК.
Это означает, что в 68% случаев действительный размер ПО
должен попадать в интервал 36 ... 50 КЧИК и примерно в 32%
случаев — в интервал 22 . 36 КЧИК или 50 ... 64 КЧИК.
Эти формулы основаны на предположении о нормальном рас>
пределении размера в пределах от а до Ь. Тем не менее каждый,
кто знаком с практикой современного программирования, понима-
ет, что если b есть 64 КЧИК, так как это максимальное помещаю-
щееся в память ЭВМ число команд, то со значительной больше#-
вероятностью, чем 16%, конечный размер ПО будет лежать в ин-
тервале 50 ... 64 КЧИК.
Несколько лучший метод в системе ПЕРТ (см. [244]) основан
на использовании бета-распределения и на раздельном оценивания
конкретных компонентов ПО. В данном случае для каждого ком-
понента определяются три величины:
а, — наименьший возможный размер компонента ПО;
— наиболее вероятный размер этого компонента;
bi — наибольший возможный размер этого компонента.
Уравнения системы ПЕРТ оценивают ожидаемый размер ПО
МО, и стандартное отклонение о, для каждого компонента как
МОг = (а{ -j- 4mf 4- bi)/6\ о, = (bt —af)/6.
Тогда оценка всего размера ПО (МО) и стандартное отклоне-,
ние (оМО) составят:
п / п \1/2
МО= у MOit аМО-=1 у of )
- »=1 \<=1 /
1 Эти формулы основаны на том, что нижняя и верхняя оценки а и Ь пред-
ставляют собой пределы 3 о (трехкратное стандартное отклонение) распределения
вероятности действительного размера ПО. Для нормального распределения веро-
ятности это означает, что действительный размер ПО будет находиться между J
и Ь в 99,7 % случаев.
266
Пусть, например, оценивается размер ПО, которое будет раз-
рабатываться для микропроцессорного кассового аппарата с объе-
мом памяти 64 Келов. Промежуточные оценки отдельных компо-
рентов и полные оценки ПО для этой разработки приводя гея в
табл. 21.4.
Таблица 21.4
Пример использования метода оценивания размера
в системе ПЕРТ (оценки даны в тыс. команд)
Компонент ai mi bi мо4
Расчеты 6 10 20 11 2,33
Отображение 4 7 13 7,5 1,5
Редактирование ввода 8 12 19 12,5 1.83
Табулирование 4 8 12 8 1,33
Всего 22 37 64 39 oMO= = 3,6
Этот метод оценивания несколько лучше, поскольку он требует
более продуманного разбиения ПО на компоненты и оценивания
наиболее вероятных размеров каждого компонента наряду с их
верхней и нижней границами. Но даже и в этом случае вычисление
оМО в большой степени некорректно, так как предполагает, что
оценки не занижены или не завышены. Опыт, однако, показывает,
что «наиболее вероятные» оценки имеют тенденцию группировать-
ся в большей степени в области нижней, а не верхней границы а
действительные размеры изделия группируются в области верхней
границы, что приводит к существенному занижению результатов
оценок в системе ПЕРТ.
В примере (см. табл. 21.4) значения оМО свидетельствуют о
том, что в 68% случаев действительный размер ПО микропроцес-
сорного кассового аппарата будет иметь значение между 35,4 и
42,6 Келов, а размеры е интервале 49,8 ... 6ч Келов встретились
бы только в 0,15% случаев. И снова современный опыт подсказы-
вает, что эти большие обьемы будут встречаться значительно чаще,
чем в 0,15% случаев.
Причины недооценки размера ПО. Проблема недооценки раз-
мера ПО является главным препятствием для получения точных
оценок стоимости. Модели стоимости ПО, как и другие модели,
связанные с ЭВМ, работают по принципу «что посеешь, то и по-
1 Бс тьшинство людей в оценке ^наиболее вероятного! раз (ера ПО следуют
не арифметической, а геометрической прогрессии или еще более пессим„стичгской
по отношению к границам опенке. Так, при заданных нижней и верхней границах
16 и 64 КЧИК в качестве снаг. более вероятной» сценки с большей вероятностью
выбирается среднее геометрическое значение 32 КЧИК, а не среднее арифметиче-
ское значение 40 КЧИ*. и очень редко в качестве (наиболее вероятной» оценки
выбирается значение 48 КЧИК или больше.
267
жнешь»: вводя заниженные оценки размера, получаем занижа
ные оценки стоимости.
Предыдущее обсуждение формул оценки размера ПО убежд
ет, что магических формул для решения этой задачи не существу<
При отсутствии такой формулы важно понять основные источню
недооценки размера ПО, так как только установив их природу, ,
можно устранить.
Рис. 21.3. Точность выполнения намеченных сроков
для главных этапов
Современный опыт показывает, что существует три главных
причины недооценки размера ПО.
1. В основном человек оптимистичен и хочет нравиться окру-\
жающим. Каждому хотелось бы, чтобы ПО было малым по разме-
ру и простым. Высокие оценки ведут к конфликтным ситуациям,
которых, как правило, стараются избежать. Это относится не толь-
ко к оцениванию размера ПО. На рис. 21.3, заимствованном из
[17], приводится сопоставление оценочных и фактических значе-
ний времен завершения разработки примерно для 100 официаль-
ных проектов Министерства обороны США, свидетельствующее об
устойчивом «факторе оптимизма», приблизительно равном 1,33.
2. Человек склонен не полностью использовать предыдущий
опыт. Исходя из распределения исходного кода, например, в соот-
ветствии с гистограммой, приведенной на рис. 21.3, можно прийти
к выводу, что люди хорошо помнят о постоянных прикладных
функциях разрабатываемого ПО, т. е. о 2.. .3% размера изделия.
268
I а б .1 и u a 21.5
Преобладание вспомогательных программ для очень больших систем
Оценки для систем
Тип программ Safeguard П5]. К слов Safeguard [277], КЧИК BMD-STP [88]. КМК TSQ-73 [15]. КМК Awacs [15]. КМК Sage [260], КМК Типичная, очень боль- шая систе- ма, кчик
Функциональные 653 789 276 20 280 200 100
Вспомогательные, одноразовые 630 100+ 30 100
(сопровождение и диагностика) (0,96) (0,13+) (1.50) (1,0)
Вспомогательные, разработки 913 532 525 40 1190 430 150
(компиляторы, инструментальные средства, утилиты) (1.40) (0,67) (1.90) (2,00) (4,24) (2,15) (1.5)
Вспомогательные, многоразовые 835 840 751 5 244 430 150
(моделирование, редактирование данных, обучение) (1.28) (1.06) (2.72) (0,25) (0,87) (2,15) (1.5)
Всего 2378 1472+ 1276+ 75 1434 860+ 400
Нефункциональные (3.64) (1.87+) (4,62+) (3,75) (5,12) (4,30+) (4.0)
Всего 3031 2261 + 1552+ 95 1747 1060+ 500
Примечание. (*) — размер функциональных программ умножается на х; у+ — размер не меньше, чем у: КМК — тысяча разрабо-
танных выполняемых машинных команд.
о
связанных с вычислениями, и гораздо хуже о большом размерЛ
вспомогательного ПО, которое также должно быть разработаноЯ
3. Как правило, люди не знакомы со всем объемом работы
Это' фактор, совместно с предыдущим, приводит к недооценке вто-
рое гепенных компонентов разрабатываемого ПО, а также скрытых
частей любого изделия. Хорошим примером этого является сильная
тенденция недооценивать размер вспомогательного ПО, который
для больших ОС обычно в 3 ... 5 раз больше размера функцио-
нальной части. Некоторые типичные размеры для больших ОС при-
водятся в табл. 21.5. Хотя для разных проектов оценки размера
даны в различных единицах, а для одного и того же проекта
(Safeguard) налицо различие двух оценок, общий характер резуль-
татов вполне устойчив. Как показывает последний столбец табли-
цы, типичная, очень большая (500 КЧИК) ОС будет содержать
всего лишь около 100 КЧИК проблемно-ориентированных про-
грамм, 1СЭ КЧИК программ, обеспечивающих диагностику и со-
провождение технической и системно-зависимой частей, 150 КЧИК
программ, обеспечивающих разработку (компилят >ры, инструмен-
тальные средства, утилиты и т. д.), и, наконец, 150 КЧИК проб-1
лемно-ориентированных обслуживающих программ (моделирпва-1
ние, преобразование данных, обучение).
В итоге, следовательно, нет прямого пути оценивания размера
ПО; нет альтернативы исследованию того, что должно выполнять
ПО, исследованию причин стремления к недооценке размеров ПО
осознанному, реалистическому применению знаний при оценивании
размера ПО.
21.5. ШАГ 5: ИСПОЛЬЗОВАНИЕ НЕСКОЛЬКИХ НЕЗАВИСИМЫХ МЕТОДОВ
И СРЕДСТВ
В гл. 22 будут обсуждены основные классы методов, пригодных
для оценивания стоимости ПО. К ним относятся:
1) алгоритмические модели;
2) экспертные оценки;
3) метод аналогий;
4) закон Паркинсона,
5) метод конкурентных цен;
6) метод сверху — вниз;
7) метод снизу — вверх.
Основными выводами гл. 22 являются: ни один из методов не
превосходит другой во всех отношениях; сильные и счабне сторо-
ны этих методов дополняют друг друга.
Важно поэтому использовать сочетание методов, избегая сла-
бостей каждого конкретного метода и объединяя их сильные сто-
1 Аналогичнэя недооценка присуща оцениванию работы по созданию ПО
(см. разд. 22 7).
270
роны. Превосходный пример практического опыта исследования и
применения комбинаций методов оценивания стоимости ПО при
заключении крупного контракта на разработку ПО приводится
в [182].
21.6. ШАГ 6: СРАВНЕНИЕ И ВЗАИМНОЕ УТОЧНЕНИЕ ОЦЕНОК
Наиболее значимым аспектом использования нескольких неза-
висимых методов оценивания стоимости является возможность ис-
следовать причины расхождения соответствующих результатов.
Так, если по методу снизу— вверх оценка стоимости ПО составля-
ет 4 млн. долл., а по методу снизу—вверх — 7 млн. долл., то
можно было бы попробовать выяснить причины такого расхожде-
ния, выделяя в каждом случае компоненты стоимости и подробно
анализируя их различия.
Можно обнаружить, например, что метод снизу — вверх упус-
кает из вида работы, выполняемые на системном уровне, т. е. такие,
как комплексирование, управление конфигурацией и контроль ка-
чества, в то время как метод сверху—вниз учитывает эти компо-
ненты, но упускает те, которые связаны с постпроцессорной обра-
боткой и учитываются в оценке по методу снизу — вверх. После-
довательное уточнение этих двух оценок может привести к более
реальной оценке 8 млн долл., а не к произвольной компромиссной
оценке между 4 и 7 млн. долл. Таким образом, важно не только
получить независимые оценки, но и исследовать причины их рас-
хождения 1.
Феномен «оптимизм — пессимизм». Есть две основные причины
последовательного уточнения оценки стоимости: феномен «опти-
мизм — пессимизм» и феномен «главного столба в палатке».
При оценивании многокомпонентных изделий часто можно обна-
ружить очень похожие компоненты с поразительно различными
оценками стоимости одной команды. Нередко это происходит из-за
личных склонностей, приводящих одних людей к весьма оптими-
стичным, а других—к весьма пессимистичным оценкам стоимости.
Часто также эти различия обусловлены конкретной ролью и по-
буждениями личности. Коммерческий директор, чье вознагражде-
ние связано с заключением договора, вероятнее всего будет опти-
мистом. Руководитель проекта, ответственный за выполнение кон-
тракта в рамках бюджета, с не меньшей вероятностью окажется
пессимистом.
Поэтому важно предусмотреть некоторое перекрытие оценок
компонент ПО, полученных разными людьми, и калибровать отно-
сительный оптимизм и пессимизм разных экспертов.
1 Необходимость исследования различий оценок является главной причиной
конструктивности алгоритмической модели стоимости. Конструктивная оценка лег-
ко и просто объяснима. С другой стороны, не существует способа сравнения оце-
нок, полученных посредством алгоритмической модели стоимости, с иными типами
оценок. Конструктивность является первостепенной целью КОМОСТ.
271
Феномен «главного столба в палатке». В большинстве много."
компонентных оценок есть один или два компонента, чьи стоимо-
сти доминируют над стоимостью всех остальных компонентов (по-
добно главным столбам палатки), часто составляя основную стои-
мость всего ПО *. В таких случаях особенно важно более подробно
исследовать стоимость этих компонентов по сравнению со стоимо-
стью других и последовательно уточнить их.
Рассматриваемые компоненты, как правило, наибольшие по
размеру и их сложность часто переоценивается. Во-первых, люди
склонны проводить параллель между размером и сложностью, в
то время как большинство моделей стоимости (включая КОМОСТ)
определяют сложность как наследуемый атрибут кода, который не
зависит от размера. Во-вторых, человек склонен считать сложно-
стью компонента сложность наиболее трудной его части. Большие
компоненты часто содержат большое число простых частей кода,
сложность которого легко переоценивают. Обе эти тенденции не-
обходимо иметь в виду при проверке и уточнении оценки стоимости.
Некоторые полезные при проверке вопросы. При проверке оцен-
ки стоимости ПО, на которой будет основан бюджет разработки,
важно получить ясное представление о ее обоснованности и степе-
ни оптимизма, заложенного в оценку. Если с учетом фазового гра-
фика, приведенного на рис. 21.1, рассматривать оценку, как отно-
сительно правильную оценку уровня спецификации требований
(в пределах ошибки в 1,5 раза), а она в действительности окажет-
ся оценкой уровня анализа осуществимости (в пределах четырех-
кратной ошибки), то впоследствии, вероятно, придется столкнуть-1
ся с некоторыми неприятными неожиданностями и последующим
пересмотром бюджета. Вероятно, можно столкнуться с аналогич-
ными неожиданностями, если принять оптимистическую оценку
(вблизи нижней границы кривой на рис. 21.1) в качестве бюджет-
ной оценки проекта.
Ниже приводятся некоторые контрольные вопросы, ответы на
которые помогут убедиться в относительной правильности оценки
стоимости ПО (т. е. выявить смещение оценки влево или вправо на
рис. 21.1).
1. Как изменилась бы оценка стоимости, если бы
а) произошло большое изменение во взаимодействии человек —
машина, в передаче данных, в системе учета и т. д.?
б) необходимо было обеспечить более широкие возможности '
системы (запросы к базе данных, сопровождение и диагностика,
анализ изменений и т. д.) ?
в) оценки рабочей нагрузки увеличились в 2 раза?
г) нужно было выполнить работу на другой (меньшей, распре-
деленной и т. д.) конфигурации ЭВМ?
2. Предположим, что бюджет на 20% меньше (больше). Как
это повлияло бы на изделие?
1 Часто такие оценки подчиняются закону, который в этом контексте выра-
жается как «80 % стоимости заключено в 20 % компонентов».
272
3. На какие компоненты разбивается стоимость подсистемы
(взаимодействия с пользователем, управления базой данных, уп-
равления процессами и т. д.)?
Если ответы на такие вопросы расплывчаты и носят общий ха-
рактер (типа «О, это не оказало бы сильного влияния на стои-
мость») или не сопровождаются каким-либо обоснованием («Эта
дополнительная возможность обошлась бы Вам в 200 тыс. долл»),
то рассматривать эти оценки следует как весьма предварительные,
которые могут сильно измениться, как только будет уточнено ПО.
Далее приводятся некоторые проверочные вопросы, ответы на
которые помогут взвесить относительный оптимизм оценки стои-
мости ПО (т. е. расположение по вертикали в соответствии с
рис. 21.1).
1. Как согласуются с опытом следующие понятия:
а) оценивание размеров подсистем;
б) рейтинги стоимостных атрибутов;
в) стоимость одной команды;
г) предположения относительно адаптации заказного ПО, ос-
новного персонала и т. д.?
2. Производился ли анализ стоимости риска? Если да, то какие
места наиболее критичны и как это учитывается?
3. Предположим, что средств для правильного выполнения этого
анализа достаточно. Какой суммой следовало бы располагать?
21.7. ШАГ 7: ПЛАНОВЫЙ УЧЕТ
С самого начала работы над проектом ПО важно вести посто-
янный учет данных о его действительной стоимости и развитии и
сравнивать эти данные с оценками. Важность этой работы объясня-
ется следующими причинами.
1. Несовершенство исходных данных для оценивания ПО (оцен-
ки размера, рейтинги стоимостных атрибутов). Если в проекте об-
наружится различие между оценкой стоимости и ее действитель-
ным значением, которое может быть объяснено уточнением стои-
мостных атрибутов, руководителю проекта важно пересмотреть
оценки стоимости, учитывая новую информацию, чтобы обеспечить
более реальную основу для дальнейшего управления проектом.
2. Несовершенство методов оценивания ПО. При длительном
процессе уточнения следует сравнивать оценки с действительными
значениями и использовать эти результаты для улучшения методов
оценивания.
3. Некоторые проекты недостаточно хорошо соответствуют мо-
дели оценивания (например, стоимость пошаговой разработки при
поэтапном разбиении). В этом случае важны и быстрая обратная
связь проект-руководство, и долговременная обратная связь для
улучшения модели при любых расхождениях оценок и соответству-
ющих действительных значений.
4. Проекты ПО имеют тенденцию к изменению: добавляются но-
вые компоненты, разделяются, перераспределяются по области
273
действия и объединяются непредсказуемым образом уже сущее .
вующие. И опять руководителю проекта необходимо идентифицц
ровать эти изменения и выполнять реалистичное обновление оце_
нок стоимости.
5. Программное обеспечение является развивающейся обла-
стью. Все методы оценивания основываются на опыте предшеству.
ющих разработок, которые не могут обладать чертами структур,
ного программирования, использовать автоматизированные инстру.
ментальные средства, языки спецификаций, микропроцессоры или
распределенную обработку данных. В этом случае и для ближай-
Рис. 21.4. Схема стоимость — сроки —
этапы для базового проекта ПО встроен-
ного типа размером 32 КЧИК
ми данными — это схема стоимость
ших, и для перспективных
целей важно осознать отли-
чия, обусловленные этой
причиной, и учесть их в
улучшенных оценках проек-
та и в самих методах оце-
нивания.
Подробное рассмотрение
методов реализации управ-
ления и планирования про-
ектов ПО приводится в гл
32. Простой метод осуществ-
ления схемы стоимость -J
сроки — этапы иллюстриру-
ется ниже.
Схема стоимость — сро-
ки — этапы. Простой, но
очень полезный метод срав-
нения оценок с фактически-
— сроки—этапы. В качестве
примера на рис. 21.4 используются характеристики проекта базо-
вого ПО встроенного типа размером 32 КЧИК- На этой схеме да-
на оценка числа месяцев и человеко-месяцев, требуемых для до-
стижения четырех главных контрольных точек проекта:
анализ требований к ПО — АТПО (4,5 мес., 18 ЧМ);
анализ проекта изделия — АПИ (9,3 мес., 60 ЧМ);
завершение автономной отладки — ЗАО (15,9 мес., 18 ЧМ);
анализ приемки программ —АПП (18,5 мес., 248 ЧМ).
Исходя из этих оценок, руководитель проекта может отмечать
реальные сроки и стоимости при достижении соответствующих кон-
трольных точек на схеме. Если налицо существенное различие
между оценками и действительными значениями, то это послужит
основанием для исследования причин такого расхождения и приня-
тия соответствующих корректирующих мер.
Например, три возможные точки А, В и С, отмеченные на
рис. 21.4, представляют проекты, в которых завершение этапа АПИ
произошло в точках время — стоимость, существенно отличающих-
ся от значений оценок (9,3 мес. и 60 ЧМ).
274
На проект А было затрачено примерно столько же средств,
сколько и предусматривалось, но точки АПИ он достиг значитель-
н0 раньше графика. Этот проект обеспечен кадрами значительно
лучше, чем обычно для таких проектов. Это могло произойти из-за
возможности легко разделить изделие на ряд частей, над которы-
ми могли работать больше аналитиков, чем обычно принято для
такого изделия. В этом случае руководитель проекта может пере-
смотреть оценки обычным сдвигом проектного графика. С другой
стороны, это могло стать следствием желания использовать боль-
шее число людей как можно раньше, и контрольная точка АПИ
может оказаться не столь удовлетворительной, как ей следовало
бы быть ’. Это один из случаев, когда руководителю проекта сле-
дует провести дополнительные исследования, прежде чем двигать-
ся дальше.
Для достижения АПИ в проекте В потребовалось время, при-
мерно равное предусмотренному при меньших по сравнению с пла-
нируемыми затратах. Это может произойти из-за упрощения рабо-
ты (меньше работы по определению требования работы к ПО, но
больше времени затрачено на пересмотр контракта). В этом случае
руководитель проекта может повторно оценить наименьшую стои-
мость завершения. Или это может означать, что существуют про-
блемы, связанные с подбором штатов, и точка АПИ достигнута не
полностью. В таком случае руководитель проекта снова нуждается
в проведении исследований.
В проекте С для достижения точки АПИ затрачено больше
времени и труда. Это может произойти по любой из пяти причин,
обсуждавшихся в начале раздела. И опять, руководителю проекта
необходимо выявить, какие причины вызвали несоответствие, пре-
жде чем соответственно изменить схему для оставшейся части про-
екта.
Г Л А В А 22
АЛЬТЕРНАТИВНЫЕ МЕТОДЫ ОЦЕНИВАНИЯ СТОИМОСТИ ПО
Для оценивания стоимости ПО используются следующие ме-
тоды.
1. Алгоритмические модели. В этих методах применяются алго-
ритмы вычисления оценок стоимости ПО в виде функций некото-
рого числа параметров, представляющих основные стоимостные
факторы. Примером алгоритмической модели является КОМОСТ.
2. Экспертные оценки. Этот метод предполагает обсуждение с
одним или группой экспертов факторов и оценок стоимости ПО,
возможно с привлечением механизма экспертного согласия, напри-
мер метода «Дельфы».
1 См. табл. 4.1 со сводкой требований к проекту ПО для завершения АПИ.
275
3. Метод аналогий. В этом методе используется оценка разра.
ботки одного или нескольких завершенных проектов. По аналогии
с фактическими затратами на их разработку оценивается стоя
мость сходного нового проекта.
4. Закон Паркинсона. В соответствии с законом Паркинсона
(«Любая работа стремится захватить все доступные ресурсы»)
оценка стоимости приравнивается стоимости всех используемых
ресурсов.
5. Метод конкурентных цен. Оценка стоимости в этом метода
приравнивается цене, необходимой для победы в конкурентной
борьбе за получение заказа (или приоритета выхода на рынок с
новым, изделием).
6. Оценивание методом сверху — вниз. Полная оценка стоимости
проекта выводится по глобальным характеристикам программного
изделия. Эта оценка затем распределяется между различными ком-
понентами.
7. Оценивание методом снизу — вверх. Вначале оценивается
работа по каждому компоненту ПО, а результаты суммируются дл I
получения оценки всей работы.
Далее обсуждаются сильные и слабые стороны каждого из пе-
речисленных методов. Глава завершается некоторыми советами о
применениях этих методов.
22.1. АЛГОРИТМИЧЕСКИЕ МОДЕЛИ
Для оценивания стоимости ПО применяются следующие наибо-
лее общие алгоритмы:
линейные модели;
мультипликативные модели;
аналитические модели;
табличные модели;
комбинированные модели.
Каждый из этих видов последовательно обсуждается ниже, в
заключение приьедена сводка достоинств и недостатков алгорит-
мических моделей *.
Линейные модели. Оценки стоимости по линейным моделям
представляются в виде
Затраты = а0 -j- ах хг + ап хп,
где %1, ...,. :п — переменные стоимостных факторов;
во, ..., ап — последовательность коэффициентов, полученных в
результате обработки данных по завершенным проектам. Стои-
мость разработки получается умножением вычисленных затрат на1
цену единицы затрат.
Этот вид модели был использован в большом исследовании по
оцениванию стоимости ПО, проведенном в середине 60-х годов]
[223]. В этом исследовании было рассмотрено более 100 важный
1 Конкретная модель стоимости обсуждается в разд. 29.7.
276
стоимостных факторов по 169 проектам ( настоящему времени это
самая большая выборка данных). Полученная по этим данным
линейная модель содержала 13 параметров, средняя оценка соста-
вила 40 ЧМ, а стандартное отклонение — 62 ЧМ — это весьма не-
точный результат. Самый главный вывод из такой неточности со-
стоит в том, что существует большое число нелинейных факторов,
влияющих на стоимость ПО, и линейная модель успешно работать
не может.
Мультипликативные модели. Оценки стоимости в таких моделях
представляются в виде
3 атраты = а0 • аХ1 - ахг •... • а„п,
где Xi, ..., хп — по-прежнему переменные стоимостных факторов
и ао, ..., ап — последовательность коэффициентов, полученных в
результате обработки данных по завершенным проектам.
Этот вид модели был использован в [291] с переменными, при-
нимающими значения— 1, 0 и 1, а в [147] с переменными, прини
мающими значения 0 и 1. Мультипликативная модель работает до-
статочно точно, если параметры слабо зависимы (иначе возникает
проблема двойного учета стоимости или эффект взаимного влия-
ния). Ограничение набора значений для переменных вызвано не-
устойчивостью модели. Оценка стоимости может принимать толь-
ко дискретные значения. Например, оценка по [147] умножается на
1,83* = 1,83, если существует конкурирующая разработка техниче-
ского обеспечения ЭВМ, и на 1,83°= 1,® в противном случае, а
промежуточных значений коэффициента не существует
Аналитические модели. Оценки стоимости таких моделей имеют
вид
Затраты =/(jq,..., хп),
где xi, ..., хп — переменные стоимостных факторов; f — некоторая
математическая функция, отличная от линейной и мультиплика-
тивной. Например, модель в [141] имеет вид
Затраты = т), N.2 N log2 т],2Sp2-
где t]i — число различных операторов программы; т]2— число раз-
личных операндов; т]=т)1+т]2; Л'2— общее число всех операндов
в программе; S=18 по оценке; N — общее число всех операторов
и операндов.
В качестве другого примера можно рассмотреть модель [243],
которая имеет вид
5и = Сь№/3^/3,
где 5И — размер программного изделия; Сь — константа; /С — за-
траты на разработку в человеко-годах; tp— время разработки в
годах.
Аналитические модели содержат небольшое число переменных,
следовательно, они не учитывают целый ряд факторов, которые
часто оказывают решающее влияние на стоимость ПО.
277
Табличные модели. Такие модти представляют собой ряд таб-
лиц, связывающих значения пере₽нных стоимостных факторов со
значениями затрат на разработкуПО или с коэффициентами для
оценки затрат. Модель, в [11] со'оит из простой таблицы разме-
ром 3X3, связывающейй затраты иуда на разработку с продолжи-
тельностью проектирования и слжностью проекта. В модели из
[313] затраты на разрааботку опекаются по таблице в зависимо-
сти от типа, сложности и новизнь ПО. В модели из [33] оценка
производительности заввисит от тиа ПО и коэффициента, задавае-
мого таблично и зависящего отгаких факторов, как язык про-
граммирования, размер • проекта, ео новизна и т. п.
Табличные модели о»бычно прон'Ы для применения и понимания,
легко могут быть изменсены при мйификгции факторов. Некоторые
трудности применения "табличногсметода связаны с числом пере-
менных стоимостных фзакторов: мпое число переменных приводит
к упущению важных фоакторов, г больное число переменных —к
необозримости таблиц ин сложностях построения при незначитель-
ном объеме фактическмго материна.
Комбинированные мдодели. В тих моделях одновременно ис-
пользуются все выше п- еречисленвш виды зависимостей затрат на
разработку ПО и переменных стимостпых факторов. Модели из
[118] и [244] (см. раздг. 29.7) явлются примерами комбинирован-
ных моделей. (Некотоорые детад! модели из [244] описаны в
[243].) Комбинированн1ыми моде.'! ми являются также модель из
[43] и КОМОСТ.
Преимуществом ком бинированРЙ модели является применение
наиболее подходящей фоункционалной формы для оценивания сто-
имости каждого компонсента ПО. равные трудности использования
комбинированных модс„лей
ручного применения (в
связан со сложностями изучения и
ручного применения (в частностиэтим обосновано появление ба-
зовой и промежуточной КОМОСТнаряду с детальной КОМОСТ),
а также с большими уссилиями и рачительным требуемым факти-
ческим материалом для построени таблиц.
Основные достоинстЕва и недосатки алгоритмических моделей.
По сравнению с другитми метода!И оценивания алгоритмические
модели имеют ряд преипмуществ. Спи объективны и не подвержены
влиянию таких факторсов, как стрмление к победе, желание луч-
ше выглядеть в условиях конкуренции или отвращение к проекту.
Они повторяемы, и чер«ез неделю «а тот же вопрос они дадут та-
кой же ответ. Эти моделли эффектйны и обеспечивают анализ чув-
гтвительности. Они скотнцентриройли в себе предыдущий опыт.
В то же время у алп'оритмичесрх моделей имеются и недостат-
ки. Поскольку они построены на осюве данных предыдущих проек-
тов, остается открытым вопрос о щавомерности переноса опыта на
новые проекты, которые используот новые методы и архитекту-
ру ЭВМ или применяютгся в новьпобластях. Эти методы также не
учитывают конкретных условий, характеристик исполнителей и
:оответствия разработчиков плана1 работ. Кроме этого, невозмож-
но предусмотреть точноость входное данных для расчетов оценок.
22.2. ЭКСПЕРТНЫЕ ОЦЕНКИ
Методы экспертной оценки заключаются в консультации с од-
ним или несколькими экспертами, которые проводят оценку стои-
мости ПО, используя свой опыт и знание проекта. Эти методы, не-
смотря на свои недостатки, удачно дополняют алгоритмические
модели. Из достоинств экспертных оценок следует отметить воз-
можность указать зависимость использования опыта прошлых раз-
работок от новых методов, архитектуры ЭВМ, областёй примене-
ния, предусмотренных в будущих проектах. Эксперт может учес гь
также индивидуальные возможности и взаимодействие разработ-
чиков или другие уникальные стороны проекта.
К недостаткам экспертной оценки следует отнести зависимость
ее от компетенции и объективности эксперта, который может
оказаться пристрастным, оптимистичным, пессимистичным или не-
знакомым с основными аспектами проекта. Трудно выбрать золо-
тую середину между быстро полученной оценкой одного эксперта
(своевременной, эффективной, но трудно проверяемой и разумно
обьяснимой) и строгой, хорошо документированной оценкой в ме-
тоде группового согласия (тщательно обоснованной и проанализи-
рованной, но требующей длительной проработки, а также трудно
повтсримой через некоторое время, особенно когда спецификации
проекта отчасти изменены).
Методы группового согласия. Из-за множества различных инди-
видуальных особенностей эксперта (оптимизм, пессимизм, жела-
ние добиться успеха или понравиться, политические соображения)
предпочтительным является метод оценивания несколькими экспер-
тами. Существует много путей объединения индивидуальных оце-
нок в единую. Один путь состоит в получении средних или средин-
ных оценок. Это быстрый метод, но он может выдать не очень точ-
ный результат из-за возможности выбросов значений отдельных
оценок.
Другой метод состоит в проведении совещания группы экспер-
тов для формирования единой оценки. Этот метод имеет общее пре-
имущество отсеивания оценок, связанных с неосведомленностью,
но обладает двумя недостатками. Во-первых, одна группа экспер-
тов мэжет повлиять на оценки другой группы своим красноречи-
ем и напористостью. Во-вторых, группа экспертов может попасть
под влияние авторитетной личности или политической ситуации.
Метод «Дельфы» [145] позволяет избежать указанных недо-
статков. Метод разработан в 1943 г. для предсказания событий
(название метода соответствует названию города, в котором нахо-
дился древнегреческий оракул) и с тех пор применялся как метод
экспертного согласия при планировании и для оценки стоимости.
Шаги процедуры применения стандартного метола «Дельфы» при-
ведены в табл. 22.1. Для оценивания стоимости ПО и факторов
метод применялся в [267].
279
Таблица 22.1
Стандартный метод «Дельфы» для оценивания стоимости
1. Координатор знакомит каждого эксперта со спецификацией ПО и фор-
мой записи оценок.
2. Эксперты анонимно заполняют формы. Они могут задавать вопросы ко-
ординатору, но не должны обсуждать вопросы друг с другом
3. Координатор подготавливает краткий отчет в форме запроса экспертам
для следующего шага итерации оценки (см рис. 22.1)
Проект: Операционная система
Дата: 21. 06. 83
Оценки после первой итерации
/Ваша оценка /'Средняя оценка
, ® X [х] X X
-i------1------.-----=------1------1-----J_______. I '
20 40 60 80 100
Дайте, пожалуйста. Вашу оценку для следующей итерации: 35 ЧМ
Приведите, пожалуйста, какие-либо обоснования перед оцениванием:
Это выглядит как стандартная операционная система управления процессом^ Бригада раз-
работчиков имеет большой опыт работы с такими системами,‘с этой, разработкой труднос-
тей не будет. *
Рис. 22.1. Типичная форма представления итерационного метода «Дельфы»
4. Эксперты опять анонимно заполняют формы, и процесс повторяется до
получения удовлетворительного результата.
5. В течение всего процесса оценивания никакого группового обсуждения
не производится.
Эксперимент по применению метода «Дельфы» для оценивания
стоимости ПО. В 1970 г. был проведен эксперимент по определению
сравнительных характеристик методов «Дельфы» и группового со-
гласия при оценивании стоимости ПО [107]. Четырем группам бы-
ла предложена одна и та же спецификация ПО (разрабатываемого
для информационной системы ВВС), реализация которой фактиче-
ски потребовала 489 ЧМ. Две группы использовали метод «Дель-
фы», другие две группы в течение полудня проводили совещание.
Первые две группы добились впечатляющих результатов по сходи-
мости последовательных оценок, однако окончательные результаты
менее точны, чем результаты двух других групп, как показано в
табл. 22.2.
Таблица 22.2
Метод Эксперимент А Эксперимент В Фактическое значение
«Дельфы» Группового согласия 217 485 1090 655 489
280
Таблица 22.3
Расширенный метод <Дельфы>
1. Координатор предоставляет каждому эксперту спецификации ПО и фор-
му записи оценки.
12. Координатор созывает групповое совещание, на котором эксперты вместе
с координатором обсуждают спорные вопросы.
3. Эксперты анонимно заполняют формы.
4. Координатор готовит и вносит в форму краткие итоги оценивания (за
исключением записей обоснования форма аналогична форме в стандартном ме-
тоде «Дельфы», см. рис. 22.1).
5. Координатор созывает групповое совещание экспертов, концентрируя
особое внимание на пунктах с большим разбросом оценок.
'6. Эксперты вновь анонимно заполняют формы, и процедура повторяется
с 4-го по 6-й шаг необходимое число раз.
Чрезвычайная точность результатов, полученных методом группо-
вого согласия в эксперименте А, служит примером того, как непра-
вильными действиями могут быть достигнуты хорошие результаты
(возможно, что это просто совпадение). В группе главенствовал
эксперт, который настойчиво предлагал решение по закону Пар-
кинса (см. разд. 22.4): «В наличии имеется 20 человек, которые
будут заняты полностью два года, и тогда либо они закончат про-
ект за два года, либо не закончат его никогда». Это привело груп-
пу к очень близкой оценке 485 ЧМ, но последующая попытка при-
менить такой подход привела к довольно неточным результатам.
Расширенный метод «Дельфы». При рассмотрении результатов
этого эксперимента было сделано заключение, что процедура с об-
ратной связью в методе «Дельфы» не обеспечивает экспертов
информацией для сопоставления собственных оценок с оценками
других экспертов. Этот факт привел к формулировке другого мето-
да, названного расширенным методом «Дельфы» и кратко пред-
ставленного в табл. 22.3.
Расширенный метод «Дельфы» применялся во многих исследо-
ваниях и работах по оцениванию стоимости [39]. Он успешно со-
четает преимущества свободного обсуждения экспертов и аноним-
ных оценок в методе «Дельфы».
22.3. МЕТОД АНАЛОГИЙ
Оценивание по аналогии состоит в рассмотрении одного или не-
скольких завершенных проектов и получении оценки нового проек-
та по аналогии с фактическими данными завершенных проектов.
Это эквивалентно методу оценивания сходства и различия [313].
Например, можно рассуждать так: Этот генератор отчетов о
влиянии окружающей среды в штате Орегон похож на разработан-
ный за 1200 тыс. долл, в прошлом году для штата Флорида. В си-
стеме для штата Орегон приблизительно на 30% типов отчетов
больше, чем в системе для штата Флорида, следовательно, к ука-
занным затратам необходимо добавить 360 тыс. долл. С другой
стороны, в новом проекте будут использованы те же разработчики,
281
следовательно, можно уменьшить оценку приблизительно на 20%, I
или 240 тыс. долл., чтобы учесть время, затрачиваемое на освоение
существа дела. Можно сэкономить еще приблизительно 20% на
использовании некоторых готовых модулей генератора отчетов, что
составляет 240 тыс. долл. Таким образом, стоимость, вероятно, бу-
дет равна
1200 тыс. долл. + 360 тыс. долл. — 240 тыс. долл. —
— 240 тыс. долл. = 1080 тыс. долл
Оценивание по аналогии может быть проведено либо на уровне
всего проекта, либо на уровне компонентов. Оценивание на уровне
всего проекта имеет то преимущество, что при этом рассматрива-
ются все стоимостные факторы (в том числе стоимость комплекси-
рования компонентов), а преимущество оценивания на уровне ком-
понентов заключается в более подробном рассмотрении сходства и
различий нового и завершен шх проектов.
Главным достоинством оценивания по аналогии является то,
что оно основывается на реальном опыте проектирования. Этот
опыт может быть изучен для выделения специфических отличий в
новом проекте и их вероятного влияния на стоимость. Главный
недостаток заключается в неясности того, в какой мере предыду-
щие проекты являются образцами ограничений, методов, штатов
исполнителей и выполняемых функций для нового проекта.
22.4. ОЦЕНКА ПО ПАРКИНСОНУ
Закон Паркинсона гласит: «Любая работа стремится захватить
все доступные ресурсы». Оценка по Паркинсону формулируется
так:
Программное обеспечение управления полетом должно быть
реализовано на ЭВМ с объемом памяти 65 536 слов, следователь-
но, его размер будет приблизительно составлять 65000 слов. Оно
должно быть разработано за 18 мес. имеющимися десятью испол-
нителями, следовательно, работа потребует затрат труда приблизи-
тельно в 180 ЧМ.
В некоторых случаях оценка по Паркинсону оказывается ис-
ключительно точной. Обычно это те случаи, когда оценка предо-
ставляет дополнительные время и средства для продолжения рабо-
ты, пока не исчерпается бюджет, и тогда ПО объявляется закон-
ченным. Даже и в этих случаях остается неясным, правильно ли
использованы разработчики проекта.
Существуют другие примеры чрезвычайно неточного\оценива-
ния по Паркинсону. Так, в приведенном выше примере оценки ПО
управления полетом допущена ошибка, поскольку ко времени окон-
чания проекта был добавлен еще один вычислитель с объемом па-
мяти 65 536 слов для размещения 127 000 слов разработанного ПО,
что потребовало 32 мес. и 550 ЧМ.
Оценку по Паркинсону не рекомендуется применять. Такая
оценка приводит к порочной практике разработки ПО.
282
22.5. ОЦЕНИВАНИЕ МЕТОДОМ КОНКУРЕНТНЫХ ЦЕН
Вот два примера оценки стоимости в условиях конкуренции:
Известно, что модель стоимости некоторого проекта дает оцен-
ку 2 млн. долл., и ни один эксперт не верит, что его можно осуще-
ствить менее чем за полтора миллиона. Известно также, что заказ-
чик располагает лишь одним миллионом на разработку ПО, значит,
эту сумму и надо предложить в качестве цены. Следуя этому фик-
сируется данная оценка стоимости, и делается все, чтобы она вы-
глядела правдоподобной.
Необходимо обязательно заявить об этом изделии на националь-
ной конференции по вычислительной технике в июне следующего
года, а сейчас уже сентябрь. Значит, для подготовки ПО остается
9 месяцев.
Метод конкурентных цен обеспечил большое число заказов на
ПО многим программистским фирмам. Почти все они к настояще-
му времени освободились. Неизбежным результатом явилось то,
что деньги и сроки кончились раньше, чем завершилась работа, от-
ношения испорчены, принимаются компромиссные решения отно-
сительно поставки ПО, и многие программисты затратили массу
усилий, чтобы спасти работу от полного провала.
Основной причиной того, что метод конкурентных цен продол-
жает применяться, является недостаточная мощность методов оце-
нивания стоимости, невозможность заказчиков и разработчиков
уверенно различать правдоподобную оценку и конкурентную. Од-
ной из основных целей КОМОСТ и является осуществление такого
разделения оценок. Возможно, что КОМОСТ и дает заниженную
оценку, но только потому, что не совсем объективно определены
рейтинги стоимостных атрибутов, а это поправимое дело.
22.6. ОЦЕНИВАНИЕ МЕТОДОМ СВЕРХУ — ВНИЗ
При оценивании методом сверху — вниз общая оценка стоимо-
сти проекта выводится из глобальных свойств программного изде-
лия. Затем общая стоимость расчленяется между различными ком-
понентами. Этот метод может хорошо сочетаться с любым из рас-
смотренных методов, которые тоже могут расцениваться как оце-
нивание методом сверху — вниз.
Главное преимущество метода состоит в возможности концент-
рации внимания на общесистемном уровне. Оценивание основыва-
ется на опыте полностью завершенных проектов, поэтому фактиче-
ски не будут упущены из вида оценки работ системного уровня, на-
пример комплексирования, разработки документации для пользо-
вателя, управления конфигурацией и т. п.
Главными недостатками оценивания методом сверху — вниз яв-
ляются: невозможность выявления сложных технических проблем
на нижних уровнях, что может привести к повышению стоимости;
часто упускаются из вида необходимые для разработки компонен-
2&
ты; оценка менее стабильна по сравнению с многокомпонентной
оценкой, в которой отдельные ошибки могут компенсировать друг
друга [313].
22.7. ОЦЕНИВАНИЕ МЕТОДОМ СНИЗУ — ВВЕРХ
При получении оценки методом снизу — вверх стоимость каж-
дого компонента ПО оценивается раздельно, часто лицом, выпол-
няющим разработку данного компонента. Затем стоимости компо-
нентов суммируются для получения общей стоимости всего изде-
лия. Оценивание методом снизу — вверх дополняет оценивание
методом сверху — вниз, так что недостатки одного метода перехо-
дят в преимущества другого.
Например, оценка снизу — вверх охватывает стоимости каж-
дого компонента, упуская многие части стоимости общесистемного
уровня (комплексирования, управления конфигурацией, контроля
качества, управления проектом), связанные с разработкой ПО в
целом. В результате получаются заниженные оценки.
По сравнению с оцениванием методом сверху — вниз оценива-
ние методом снизу — вверх требует больших усилий, но это явля-
ется и его преимуществом. В частности, оценивание каждой части
работы ответственным за ее выполнение лицом полезно по двум
соображениям:
1. Каждая оценка будет основана на более точном понимании
деталей требуемой работы.
2. Каждая оценка будет подтверждена обязательствами испол-
нителя работы.
Более того, оценка снизу — вверх устойчивой, так как ошибки
в оценках компонентов могут компенсировать друг друга.
Самым эффективным способом учета общесистемного уровня
при получении оценки снизу — вверх является представление зада-
ния на ПО в виде СПР, которая содержит не только компоненты,
но и общесистемные работы (см. рис. 4.6, а, б). Неточность оценок
работ общесистемного уровня может быть вызвана необходимостью
знания размеров и природы компонентов, которые необходимо оце-
нивать одновременно с общесистемными работами.
Метод единичных задач оценивания стоимости ПО. Традицион-
ным методом оценивания стоимости ПО и наиболее часто применя-
емым при оценивании методом снизу — вверх является метод еди-
ничных задач. В этом методе разработка компонента ПО подразде-
ляется на единичные задачи. Затраты труда на единичную задачу
оцениваются самим разработчиком компонента, а результаты оце-
нивания суммируются для получения общей оценки затрат на ком-
понент ПО (см. пример на табл. 22.4).
Главное преимущество метода такое же, как у метода оценива-
ния снизу — вверх: он помогает понять суть требуемой работы,
конкретно планировать свою работу, оставляя свободу действий
разработчику. Такие оценки обеспечивают обоснование и базис
284
Таблица 22,4
Пример бланка планирования единичных задач
I КОМПОНЕНТ: Обновление запасов
2. РАЗРАБОТЧИК: Фамилия ДАТА. 08.02.82
Фаза Единичная задача Человеко- Дни Сумма
Планирование и разработ- ка требований Разработка требований к ком- понентам Разработка плана 5 1 6
Проектирование изделия Проектирование изделия Набросок руководства пользо- вателю Планирование отладки 6 3 1 10
Детальное проектирование Детализация на ЯПП* Определение данных Процедуры и данные отладки Полное руководство пользова- телю 4 4 2 2 12
Кодирование и автономная отладка Кодирование Результаты автономной отлад- ки 6 10 16
Комплексирование и испы- тания " Проектная документация Обеспечение комплексирования 4 5 9
Общая сумма * ЯПП — язык проектирована я программ. 53
для планирования и управления всем проектом (см. гл. 32). Глав-
ные трудности метода связаны с тем, что упускается из вида стои-
мость общесистемного уровня и еще два источника стоимости:
1 Эпизодические проектные работы, которые могут добавить от
30 до 50% общих затрат труда на выполнение работ, перечислен-
ных на бланке планирования задач (см. табл. 22.4). На рис. 22.2
представлено распределение затрат на работы по двум малым про-
ектам прикладного ПО [45]. Оно показывает, например, что чте-
ние, анализ, совещания и согласования отнимают 40% затрат
труда на разработку.
2. Эпизодическая деятельность, не связанная с проектом, кото-
рая может добавить еще от 30 до 50% общих затрат труда на про-
ектные работы. На рис. 22.3 показаны результаты изучения хроно-
метража работы 70 программистов [20], подтверждающие, что
приблизительно 30% рабочего времени программиста отдано дея-
тельности, не связанной с проектом: обучение, личные дела, об-
щение и т. п.
285
Рис. 22.2. Что представляет собой проект ПО? Распределение по работам за-
трат труда на проект
Рис. 22.3. Чем заняты программисты?
286
Таблица к рис. 22.3
Деятельность
разговоры или слуша-
ние, %
Разговор с руководите-
лем, %
Телефонные разговоры,
%
Чтение, %
Письмо (черчение), %
Отсутствие, %
Хождение, %
Разное, % ________
14
13
2
2
35 29
17
1
2
4
2
3
4
Всего, %
Эти трудности должны рассматриваться не как фундаменталь-
ные недостатки метода единичных задач, а как соображения, кото-
рые необходимо учитывать при оценивании затрат. Этот метод
весьма продуктивен для получения оценки малых проектов ПО.
22.8. КРАТКОЕ СРАВНЕНИЕ МЕТОДОВ
В табл. 22.5 сконцентрированы относительные достоинства и не-
достатки методов оценивания стоимости. На основании таблицы
можно сделать следующие главные выводы:
ни один из методов не может быть признан лучшим во всех от-
ношениях;
методы Паркинсона и конкурентных цен неприемлемы и не
обосновывают оценки стоимости ПО;
достоинства одних методов восполняют недостатки других, и
наоборот (особенно это относится к алгоритмической модели и
экспертной оценке, оценкам сверху—вниз и снизу — i ерх).
Важно, таким образом, применять комбинацию методов, срав-
нивать результаты оценивания и находить последовательное при-
ближение к достоверной оценке. Конкретная комбинация методов
зависит от целей оценивания (например, оценка сверху — вниз
полезна для грубого прогностического оценивания, оценка снизу —
вверх — для детального оценивания при планировании). Эффек-
тивной комбинацией методов является следующая:
оценивание методом сверху — вниз с использованием мнения
нескольких экспертов и оценки по аналогии, когда имеются данные
по завершенным проектам;
оценивание методом снизу — вверх с использованием алгорит-
мических моделей, для которых оценки на уровне компонентов
предоставляются разработчиками;
287
1 а б л иц a 22.5
Достоинства и недостатки методов оценивания стоимости ПО
Метод Достоинства Недостатки
Алгоритмическая мо- дель Экспертная оценка Оценивание по ана- логии Закон Паркинсона Метод конкурентных цен Оценивание методом сверху — вниз Оценивание методом снизу — вверх Объективность, повторяе- мость, анализируемость формул Эффективность, удобство для анализа чувствительно- сти Объективность проверки на основе прошлого опыта Возможность учета пред- ставительности группы, взаимодействий, уникаль- ных факторов Основано на прошлом опы- те Корреляция с некоторым Опытом Часто обеспечивает заклю- чение контракта Внимание обращено на об- щесистемный уровень Эффективность Более детальное обоснова ние Большая устойчивость Поощрение индивидуаль- ных обязательств Субъективность исходных данных Включение в оценку уни- кальных факторов Ориентировка на прошлый опыт Зависимость от участников экспертизы Тенденциозность, некото- рая несогласованность оце- нок Отсутствие прошлого опы- та Оправдание порочной прак- тики Обычно приводит к боль- шим перерасходам Менее детальное обоснова- ние Малая устойчивость Упущение общесистемного уровня Требуются большие затра- ты
Сравнение и приближение двух оценок. Представленная в гл. 8
и 9 промежуточная КОМОСТ на уровне компонентов может быть
использована для получения оценок снизу — вверх и по алгоритми-
ческим моделям. Однако часто более детальная модель с большим
числом уровней иерархии оказывается более эффективной. Обес-
печить требуемый уровень может детальная КОМОСТ, которая
рассматривается в следующей главе.
ЧАСТЬ 4Б
ДЕТАЛЬНАЯ КОМОСТ
Несмотря на высокую эффективность промежуточной КОМОСТ
(см. гл. 8 и 9) для большинства случаев оценки стоимости ПО ос-
новные два ее ограничения могут оказаться существенными, осо-
бенно при детальном оценивании стоимости в крупных проектах
ПО:
288
оценка распределения затрат труда по фазам может оказаться
яеточной;
применение для многокомпонентного изделия может оказаться
очень трудоемким.
Две главные возможности детальной КОМОСТ, представлен-
ной в гл. 23—27, направлены на устранение этих ограничений про-
межуточной КОМОСТ.
1. Фазовые коэффициенты затрат труда. В промежуточной
КОМОСТ распределение затрат труда по фазам зависит исключи-
тельно от размера изделия. На практике такие факторы, как тре-
буемая надежность, опыт в прикладной области, диалоговая
разработка ПО, на одних фазах играют значительно большую
роль, чем на других. В детальной КОМОСТ для каждого стоимост-
ного атрибута обеспечивается набор коэффициентов. Эти коэффи
циенты используются при определении общих затрат труда, необ-
ходимых для завершения каждой фазы.
2. Трехуровневая иерархия изделия. В промежуточной КОМОСТ
для различных компонентов изделия могут применяться различные
рейтинги стоимостных факторов. Если несколько компонентов
сгруппированы в подсистему с практически одинаковыми рейтин-
гами стоимостных факторов, то покомпонентная обработка будет
утомительной и необязательной. В детальной КОМССТ эта пробле-
ма решается обеспечением трехуровневой иерархии изделия, в
которой:
факторы, меняющиеся от модуля к модулю, рассматриваются
на уровне модулей;
факторы, меняющиеся не так часто, рассматриваются на уров-
не подсистемы',
такие факторы, как размер всего изделия, рассматриваются на
уровне системы.
Кроме того, в детальную КОМОСТ включены некоторые допол-
нительные возможности, как, например, процедура корректировки
распределения сроков разработки по фазам. Для некоторых воз-
можностей, таких как оценка сроков завершения разработки и
оценка распределения затрат труда по работам, детальная
КОМОСТ использует те же методы, что промежуточная и базовая
КОМОСТ.
В гл. 23 представлен набор обобщающих таблиц и процедур
для использования Формы Иерархического Оценивания ПО
(ФИОПО) детальной КОМОСТ и пример ее пошагового запол-
нения.
Главы 24—27 посвящены детальному обсуждению каждого из
15 стоимостных атрибутов, включая коэффициенты затрат труда,
определения рейтингов, эталонные данные и современное состоя-
ние искусства оценивания для каждого стоимостного атрибута.
В гл. 24 рассмотрены атрибуты программного изделия: требуе-
мая надежность ПО, размер базы данных, сложность изделия.
Глава 25 посвящена атрибутам ЭВМ ограничению по быстродей-
Ю Зак. 628
289
ствию и оперативной памяти, изменяемости виртуальной машины Я
а также циклу обращения к ЭВМ. В гл. 26 рассмотрены атрибуты
исполнителей: квалификация аналитиков и программистов и их
опыт работы в данной прикладной области, с виртуальной маши- I
ной, а также с данным языком программирования. Глава 27 посвя- I
щена атрибутам проекта ПО: использованию практики современ-
ного программирования, инструментального ПО и требуемым сро-
кам разработки ПО.
Д е последние главы ч. 4Б посвящены трем взаимосвязанным
вопросам:
Насколько справедливо утверждение, что КОМОСТ учитывает
все существенные стоимостные факторы ПО? В гл. 28 приведен ряд]
критериев оценки пригодности стоимостной модели ПО по отноше-1
нию к этим критериям и обсуждены основные факторы, не вошед-
шие в КОМОСТ.
Насколько хорошо оценки КОМОСТ согласуются с фактически-
ми данными В гл. 29 рассмотрена база данных КОМОСТ, состоя-
щая из 63 завершенных проектов, приведены результаты сопос^ав- I
ления оценок КОМОСТ и фактических данных, а также обсужде- I
на полная КОМОСТ с точки зрения критериев оценки, приведенных I
в гл. 28.
Как использовать КОМОСТ на конкретном предприятии? Ис-
пользование КОМОСТ наиболее эффективно при некоторых пред-
варительных затратах на ее настройку на конкретные условия 1
предприятия. В гл. 29 обсуждены способы реализации такой на-
стройки.
ГЛАВА 23
КРАТКОЕ ОПИСАНИЕ И ПРИНЦИПЫ РАБОТЫ ДЕТАЛЬНОЙ
КОМОСТ
23.1. ВВЕДЕНИЕ
В гл. 21 и 22 было отмечено, что солее подробный учет деталей
при оценивании стоимости приводит к более точной оценке. Деталь-
ная КОМОСТ обеспечивает эффективное уточнение и обработку
подробных предварительных оценок.
Иерархия модуль — подсистема — система. Она достигается
путем трехуровневой иерархической декомпозиции оцениваемого
изделия ПО. Низший уровень, уровень модуля, характеризуется
числом исходных команд в модуле и теми стоимостными фактора-
ми, которые варьируются на низшем уровне: сложностью модуля (
и возможностью адаптации существующих программ, а также ква-
1 Для заданного изделия указанная виртуальная машина представляет обой
комплекс технических и программных средств (ОС, СУБД и т. д.), предназначен-!
ных для выполнения поставленных задач.
290
Проект: СТУДЗДН
Аналитик: Фамилия
Дата: 7.12. 61
ГГПС
Изделие
Атрибуты ЭВМ
ФПИ
ФДП
ФКАО
ФКИ
ЗАПРОС
Подсис-
тема
ЭЧИК
3700
121
122J
И
И
ТНПО
1.0
РБД
1.0
ОБ
ОП
ИВМ
ЦО
Исполнители
И
[2Й
L291
КА
ОРП
псп
1.0
1.0
2600
1700
УТИЛИ-
ТЫ
8000
Всего ЭЧИК
28.4
0,95
0,90
0,85
0,80
чм„„„
o.bs
0,90
0.86
0,80
Тип-
PecnpOCT|M-x-z
КОРРЕ КТ
Проект
Ю?
иис
282
(ЭЧИК ЧМ1„„„
0,95
0,90
0.85
0,80
1.0
0,75
0,90
0,90
0,85
0,75
0,90
0,90
0,85
1.0
0,75
0,60
0,85
0,85
1.0
0,95
0,90
О.ВЗ
0,98
0,95
0.90
0,85
0,52
0,58
0,53
0,41
2,0
3,2
5,5
2,5
б,о
6,0
5,0
5,5
1,0
1,9
2,9
1,0
тыс.
долл.
6,8
36,5
544
10
ККЗ
ПС
чмоц
чмкор
ВСЕГО
СРЕДН
тыс. долл.
ч.я
6,0
9,5
14.6
6,6
0,75
0,80
0,85
0,85
0,95
0.90
0,83
0,98
0,95
0,90
0,85
0,52
0.58
0,53
0.41
2.4
4,1
1,9
0.7
2,2
0,8
6.0
5,0
5,0
Б.Б
4.г
7
11.0
4/-
5.1
26,6
510
10
1.0
0,95
0,90
0,83
0,98
0,95
0,90
0,85
0,93
0,81
0,69
0,56
0,7
0,7
2,5
1.2
0,7
5,0
5,0
5,5
5,5
3,6
5,6
9,4
3,8
4,2
22,2
405
13
Фазовые
коэффициенты
ФПИ 0,16
ФДП 0,25
ФКАО 0,40
ФКИ 0,19
Всего
16,1
84,3
ФПИ
ФДП
ФКАО
ФКИ
13,7
22,0
34,9
13,7
2,4
4,4
6,8
2,5
ЧМ Сроки тыс. долл.
497^
мес.
11 ЭЧИК
Рис. 23.1. Форма иерархического оценивания ПО уровня подсистемы
лификацией программиста, знанием им языков программирования
и виртуальной инструментальной машины.
Второй уровень, уровень подсистемы, характеризуется осталь-
ными стоимостными факторами (ограничением на время выполне-
Проект: СТУДЗАН
(з) № ПС (Z) № МОД (Е) Модуль (б) ЭЧИК (Z) ККА (м) сиз (пГ) КП
1 ЗАПРЕД 1800 100 1,0 1,0
1 2 ПОИСК 700 100 0,83 0.83 0.83
1 3 вывод 1200 100 0,85 0,85 0,85 0,85 1,20 1,20 1,20
1 Всего 3700
2 1 КОРРЕД 1700 100
2 2 МОДИФ 900 100 0,85 0.85 0.85 0,85 1.20 1,20 1,20
2 Всего 2600
3 1 Всего УТИЛИТЫ 1700 34 0,70 0,70 0,70 0,70 1,20 1,20 1.20
*
292
пия и объем памяти ЭВМ, квалификацией аналитика, использова-
нием инструментального ПО, требуемыми сроками разработки
и т. д.), которые варьируются от подсистемы к подсистеме, но по-
стоянны для всех модулей одной подсистемы.
.Аналитик: Фамилия
Дата:______________
ОРВМ Cz) ОРЯП ККЗ мод О ЧМНО„ ЧМкор Доля, %
1.0 1,0 1,0 1,0 1,0 1,0 1,0 1,6 2.6 1,2 1,0 1.6 2.6 1.2 0,5 0,9 1,4 0,5 15 27 42 15
0,90 0,90 0.90 0,90 0,98 0,92 0,92 0,90 0.73 0,69 0,69 0,4 0,6 1.0 0.5 0,4 0.4 0.7 0.3 0,2 0,2 0.4 0.1 22 22 45 12
1,05 1,05 1,15 1,15 1,05 1,10 1,10 0,89 1,12 1,29 1,29 0,7 1,1 1.7 0,8 0,6 1,2 2.2 1,0 0.3 0.7 1.2 0,4 12 27 46 15
2,0 3,2 5,5 2,5 1.0 1.8 3,0 1.0 15 26 44 15
1,0 1,0 1,0 1,0 1,0 1.5 2,4 1,1 1.0 1,5 2,4 1,1 0.5 0.9 1,3 0,5 16 28 40 16
1,05 1,05 1,15 1/15 1,05 1,10 1,10 0,89 1,12 1,29 1,29 0,5 0,8 1,3 0,6 0,4 0,9 1,7 0,8 0,2 0,5 0.9 0.3 11 26 47 16
1,4 2,4 4,1 1,9 0,7 1.4 2,2 0,8 14 27 43 16
1,05 1,05 1,15 1,15 1,05 1,10 1.10 0,74 0,93 1.06 1,06 1,0 1,5 2.4 1,1 0,7 1,4 2.5 1.2 0.7 1,1 1.7 0.7 17 26 40 17
Рис. 23.2. Форма иерархического оценивания ПО уровня модуля
293
На высшем уровне, уровне системы, использ} ются основные
интегральные соотношения проекта, такие как уравнения номи-
нальных затрат труда и плановых сроков, с разбиением их по
фазам.
Коэффициенты затрат труда. Трехуровневая иерархия является
одним из двух ыаьпыл отличий детальной КОМОСТ от промежу-
точной. Другое отличие состоит в использовании зависящих от фа-
зы коэффициентов, более точно отражающих влияние стоимостных
факторов на распределение затрат труда по фазам. Например,
низкий уровень знаний в прикладной области приводит к дополни-
тельным затратам труда на ранних фазах; в дальнейшем, по мере
ознакомления бригады с прикладной областью, связанные с преж-
девременным началом работы, ошибками или изучением дополни-
тельных возможностей, затраты уменьшаются. Аналогично боль-
шое воемя ответа ЭВМ играет относительно малую роль на фазах
выработки требований и проектирования, но на фазах кодирова-
ния и отладки оно отнимает большую часть времени разработчиков.
Для каждого стоимостного атрибута в детальной КОМОСТ име-
ется набор таблиц, в которых для каждого рейтинга стоимостных
атрибутов приведены коэффициенты затрат труда, отражающие
влияние атрибутов на каждой основной фазе разработки. Содер-
жимое каждой из таблиц рассматривается в гл. 24—27.
Процедуры детальной КОМОСТ. Оставшаяся часть этой главы
посвящена списанию работы детальной КОМОСТ с помощью форм,
таблиц и процедур, используемых для получения оценки стои-
мости.
В р азд. 23.2 представлена Форма Иерархического Оценивания
ПО (ФИОПО), состоящая из двух частей и применяемая для оце-
нок по детальной КОМОСТ. В разд. 23.3 даны пошаговые проце-
дуры заполнения ФИОПО и краткий обзор таблиц коэффициен-
тов затрат труда детальной КОМОСТ. В разд. 23.4 приведен при-
мер использования ФИОПО и процедур оценивания стоимости
проекта ПО информационной системы студенческой занятости.
23.1 ФОРМА ИЕРАРХИЧЕСКОГО ОЦЕНИВАНИЯ ПО
На рис. 23.1 и 23.2 представлены составные части ФИОПО, от-
носящиеся соответственно к уровням подсистемы и модуля и ис-
пользуемые при оценивании по детальной КОМОСТ. Применение
этой формы демонстрируется на примере информационной систе-
мы студенческой занятости (СТУДЗАН), состоящей из трех под-
систем.
1. Подсистема ЗАПРОС, в которой студент или наниматель мо-
жет запросить в базе данных информацию о наличии работ или
студентов для нахождения интересующей пары работа — студент.
Подсистема ЗАПРОС состоит из модуля ввода и редактирования
запроса ЗАПРЕД, модуля пофайлового поиска ПОИСК и модуля
сообщений результатов запроса ВЫВОД.
294
2. Подсистема КОРРЕКТ осуществляет добавление, исключе-
ние или изменение информации в базе данных о наличии работ
или студентов. Подсистема КОРРЕКТ состоит из модуля ввода и
редактирования корректирующей информации КОРРЕД и модуля
модификации файла МОДИФ
3. Подсистема УТИЛИТЫ. Эта подсистема состоит из различ-
ных вспомогательных обслуживающих компонентов: резервирова-
ния, загрузки или передачи содержимого файла, некоторых простых
проверок целостности и сохранности, некоторых возможностей сбо-
ра, анализа и выдачи статистических данных.
После ознакомления с процедурами заполнения ФИОПО и
таблиц детальной КОМОСТ на примере СТУДЗАН будет показа-
но, как с их помощью можно получить оценки, представленные на
рис. 23.1 и 23.2.
23.3. ПРОЦЕДУРЫ ЗАПОЛНЕНИЯ ФИОПО
В табл. 23.1 представлен набор процедур заполнения ФИОПО
для получения оценок стоимости по детальной КОМОСТ. Эти про-
цедуры организованы таким образом, чтобы можно было по воз-
Таблица 23.1
Процедуры заполнения ФИОПО
1 В форму для подсистем (ПС), составляющих систему ПО, занести в
столбцы 1 и 2 соответственно номер и наименование каждой подсистемы.
2. В форму для модуля (М) по каждой определенной на шаге 1 подсистемы
и каждого модуля, входящего в подсистему, в столбец 3 заносится номер под-
системы, в столбец 4 — номер модуля в подсистеме и в столбец 5 — наименова-
ние модуля. После внесения -данных всех модулей подсистемы выделить допол-
нительную строку для подсчета итоговых данных по подсистеме (если она состо-
ит из нескольких модулей). В случае необходимости можно использовать не-
сколько М-форм (или ПС-форм).
3. В М-форму в столбец 6 занести размер каждого модуля — эквивалентное
число исходных команд (ЭЧИК). Если модуль является результатом адаптации
существующей программы, то вычислить ККА, используя уравнения, приведен-
ные в конце таблицы, и занести его в столбец 7. Сложить все ЭЧИК для каж-
дой подсистемы и занести результат в итоговую строку.
4. В ПС-форму в столбец 8 занести значение ЭЧИК. Сложить итоговые
ЭЧИК для всей системы и занести результат в строку 9.
5. В ПС-форме обозначить тип разработки системы и вычислить номиналь-
ные затраты труда ЧМВОм, необходимые для разработки системы, используя со-
ответствующее уравнение затрат труда, приведенное в конце таблицы. Резуль-
тат занести в строку 10.
6. Вычислить номинальную производительность (ЭЧИК/ЧМ)ВОм=ЭЧИК/
1Мном и занести в строку 11 ПС-формы.
7. По табл. 6.8 получить распределение затрат труда по фазам РАЗБф как
Функцию размера всей системы в ЧИК. Разделить фазу программирования на
фазу детального проектирования (ФДП) и фазу кодирования и автономной от-
ладки (ФКАО). Занести величины РАЗБф в таблицу 12 ПС-формы.
8. Для каждого модуля вычислить распределение номинальных затрат труда
по фазам ЧМНом, ф= [ЭЧИК-РАЗБф]-г-{(ЭЧИК/ЧМ)ном], взяв ЭЧИК из столб-
ца 6, РАЗБф из таблички 12 и (ЭЧИК/ЧМ)вом из строки 11. Результаты зане-
сти в столбец 13 М-формы.
КП
9. Для каждого модуля определить рейтинги стоимостных атрибутов СИЗ.
. ОРВ'М и ОРЯП. Используя значения рейтингов определить коэффициенты
295
затрат труда по фазам для атрибутов из табл. 23.2 и занести их в соответству-
ющие столбцы М-формы (с 14-го по17-й). Коэффициенты, равные 1,0, могут
быть опущены.
10. Перемножить коэффициенты в столбцах 14—17 по каждой строке и по-
лучить корректирующий коэффициент затрат труда ККЗ для модуля по каждой
фазе. Результаты поместить в столбец 18 М-формы.
11. Для каждого модуля и каждой фазы умножить номинальные затраты
труда на модуль ЧМном, ф из столбца 13 на соответствующий ККЗМ из столбца
18 и получить скорректированные затраты труда ЧМмод, ф на уровне модуля.
Результат поместить в столбец 19.
12. Для каждой подсистемы и каждой фазы сложить оценки затрат труда
ЧММОд ф для всех модулей подсистемы, а результаты поместить в столбец 19
итоговой строки М-формы соответствующей подсистемы.
13. Для каждой подсистемы занести итоговые затраты труда ЧМмод, ф в
столбец 20 ПС-формы.
14. Для каждой подсистемы определить рейтинги стоимостных атрибутов,
указанных в столбцах 21—31 ПС-формы. Используя эти рейтинги, определить
по табл. 23.3 коэффициенты затрат труда и занести их в соответствующие
столбцы. Коэффициенты, равные 1,0, можно опустить.
15. Перемножить коэффициенты из каждой строки столбцов 21—31 для по-
лучения корректирующего коэффициента затрат труда по подсистеме ККЗПС
для каждой фазы. Результат занести в столбец 32.
16. Для каждой подсистемы и каждой фазы умножить скорректированную
оценку затрат труда на модуль ЧМмод, ф из столбца 20 на соответствующий
ККЗПС и получить полностью скорректированную оценку затрат труда для
каждой подсистемы ЧМОЦ. ф. Результат занести в столбец 33 ПС-формы.
17. В ПС-форме сложить оценки затрат труда ЧМОЦ. ф для всех подсистем
и получить фазовые оценки для всей системы. Суммируя затем системные оцен-
ки по фазам, получить общую оценку затрат труда для системы. Поместить эти
пять оценок в низ столбца 33.
18. Вычислить оценочный срок разработки системы, используя приведенные
в конце таблицы соответствующие уравнения. Результат занести в низ столбца
34 ПС-формы.
19. Для каждой подсистемы по каждой фазе в столбец 34 ПС-формы ука-
зать оценочные ставки разработчиков (тыс. долл./ЧМ). Умножая эти ставки на
соответствующие оценки затрат труда из столбца 33, получить денежную оценку
стоимости каждой фазы и подсистемы. Результаты занести в столбец 35.
20. Для каждой фазы сложить оценки стоимости всех подсистем (столбец
35) и получить оценки стоимости всей системы по фазам. Эти пять оценок поме-
стить в низ столбца 35.
21. Для каждой подсистемы сложить оценочные затраты труда по каждой
фазе (столбец 33) и поместить результирующие оценки в подстроки 1, 5, 9 (ЧМ)
столбца 36 ПС-формы. Аналогично вычислить общую денежную оценку каждой
подсистемы из оценок стоимостей (столбец 35) и результаты поместить в под-
строки 2, 6, 10 столбца 36.
22. Для каждой подсистемы вычислить оценочную производительность в
ЭЧИК/ЧМ (по данным колонки 8 и соответствующих строк колонки 36) и зане-
сти результат в подстроки 3, 7, 11 (ЭЧИК/ЧМ) столбца 36. Аналогично вычис-
лить стоимость команды (по данным столбца 8 и соответствующей подстроки
столбца 36), результаты поместить в подстроки 4, 8, 12 столбца 36 ПС-формы.
23. По ПС-форме вычислить оценку производительности в ЭЧИК/ЧМ (по
строке 9 и нижней строке колонки 33) для всей системы и поместить ее в под-
строку ЭЧИК/ЧМ нижней части столбца 36. Аналогично вычислить стоимость
команды для системы (по каждой строке столбца 35 и строке 9) и занести ее в
подстроку (долл./ЭЧИК) нижней части столбца 36
24. Для каждого модуля и каждой фазы умножить скорректированные за-
траты (ЧМ)мод, ф из столбца 19 М-формы на корректирующий коэффициент
затрат труда соответствующей подсистемы ККЗПС (столбец 32 ПС-формы) и
получить оценки затрат труда ЧМОЦ. ф для каждого модуля. Результаты поме-
стить в столбец 37 М-формы.
25. Для каждой подсистемы и каждой фазы сложить оценки ЧМОЦ. ф из
296
столбца 37 М-формы для всех модулей подсистемы и поместить результаты в
итоговую строку столбца 37. Сравнить эти результаты с оценками ЧМ для под-
систем в столбце 33 ПС-формы. Они должны быть равны. Незначительное от-
клонение в последнем знаке может возникнуть из-за округления. В противном
случае произошла ошибка в вычислениях, которые следует повторить.
Уравнения адаптации [см. (8.1), (8.2)]
ККА=0,4 -(доля изменения проекта)+0,3 • (доля изменения кода) +
+0,3-(доля затрат на комплектование);
ЭЧИК=АЧИК-ККА/100
Уравнения номинальных затрат труда и сроков (КОМОСТ, см. табл. 8.1)
Тип разработки Номинальные затраты труда Срок разработки
Распространенный Полунезависимый Встроенный ЧМном=3,2 кэчик1-05 ЧМном=3,0 кэчик1-’2 ЧМном=2,8 КЭЧИК1-20 СР=2,5-ЧМ°-38 СР=2,5-ЧМ®’ЗБ СР=2,5-ЧМ«-32
Таблица 23.2
Коэффициенты затрат труда на уровне модуля для разных фаз
Атрибут j Рейтинг ФПТИ ФДП ФКАО ФКИ ► F1TUI свое значение
сиз Очень низкий Низкий Номинальный Высокий Очень высокий Сверх высокий 0,70 0,85 1,00 1,15 1,30 1,65 0,70 0,85 1,00 1,15 1,30 1,65 0,70 0,85 1,00 1,15 1,30 1,65 0,70 0,85 1,00 1,15 1,30 1,65 0,70 0,85 1,00 1,15 1,30 1,65
КП Очень низкий (15%) Низкий (35%) Номинальный (55%) Высокий (75%) Очень высокий (90%) 1,00 1,00 1,00 1,00 1,00 1,50 1,20 1,00 0,83 0,65 1,50 1,20 1,00 0,83 0,65 1,50 1,20 1,00 0,83 0,65 1,43 1,17 1,00 0,86 0,70
ОРВМ Очень низкий (^1 мес.) Низкий (4 мес.) Номинальный (1 год) Высокий (>3 года) 1,10 1,05 1,00 0,90 1,10 1,05 1,00 0,90 1,20 1,15 1,00 0,90 1,30 1,15 1,00 0,90 1,21 1,10 1,00 0,90
ОРЯП Очень низкий (< 1 мес.) Низкий (4 мес.) Номинальный (1 год) Высокий (Js3 года) 1,02 1,00 1,00 1,00 1,10 1,05 1,00 0,98 1,20 1,10 1,00 0,92 1,20 1.Ю 1,00 0,92 1,14 1,07 1,00 0,95
Примечание. ФТПИ — фаза проектирования требований к изделию; ФДП — фа-
за детального проектирования; ФКАО — фаза кодирования и автономной отладки; ФКИ —
Фаза комплексирования и испытаний; Д/П— размер базы данных/размер программ.
297
Таблица 23.3
Коэффициенты затрат труда уровня подсистемы для разных фаз
Атрибут Рейтинг ФПТИ ФДП ФКАО ФКИ Итоговое значение
Изделия: ТНПО РБД ЭВМ: ОБД ОП ИВМ ЦО Исполни- телей: 1 КА ОРП Проекта: ПСП иис ОСР Очень низкий Низкий Номинальный Высокий Очень высокий Низкий (Д/П<10) Номинальный (10^Д/П<100) Высокий (lOOsgfl/IK 1000) Очень высокий (Д/11^1000) Номинальный (=£150%) Высокий (70%) Очень высокий (85%) Сверхвысокий (95%) Номинальный (^50%) Высокий (70%) Очень высокий (85%) Сверхвысокий (95%) Низкий Номинальный Высокий Очень высокий Низкий (интерактивный) Номинальный (СВО<4 ч) Высокий (4 ч^СВО<12 ч) Очень высокий (СВО^12 ч) Очень низкий (15%) Низкий (35%) Номинальный (55%) Высокий (75%) Очень высокий (90%) Очень низкий (^4 мес.) Низкий (1 год) Номинальный (3 года) Высокий (6 лет) Очень высокий (53= 12 лет) Очень низкий Низкий Номинальный Высокий Очень высокий Очень низкий Низкий Номинальный Высокий Очень высокий Очень низкий (уменьшение 75%) Низкий (уменьшение 85%) Номинальный (100%) Высокий (увеличение 130%) Очень высокий (увеличение >=160%) 0,80 0.90 1,00 1,10 1,30 0,95 1,00 1,10 1,20 1,00 1,10 1,30 1,65 1,00 1.05 1,20 1,55 0,95 1,00 1,Ю 1,20 0,98 1,00 1,00 1,02 1,80 1,35 1,00 0,75 0.55 1,40 1,20 1,00 0,87 0,75 1,05 1,00 1,00 1,00 1,00 1,02 1,00 1,00 0,98 0,95 1,10 1.00 1,00 1.10 1,15 0,80 0,90 1,00 1,10 1,30 0,95 1,00 1,05 1,10 1,00 1,10 1,25 1.55 1,00 1.05 1,15 1,45 0,90 1,00 1,12 1,25 0,95 1,00 1,00 1,05 1,35 1,15 1,00 0,90 0,75 1,30 1,15 1,00 0,90 0 80 1,10 1,05 1,00 0,95 0,90 1,05 1,02 1.00 0,95 0.90 1,25 1.Ю 1,00 1,10 1.15 0,80 0,90 1,00 1,10 1,30 0,95 1,00 1,05 1,10 1,00 1,10 1,25 1,55 1,00 1,05 1,15 1,45 0,85 1,00 1,15 1,30 0,70 1.00 1.Ю 1,20 1,35 1,15 1,00 0,90 0,75 1,25 1,10 1,00 0,92 0.85 1,25 1,10 1,00 0,90 0,80 1,35 1,15 1,00 0,90 0,80 1,25 1,Ю 1,00 1,00 1,05 0,60 0,80 1,00 1,30 1,70 0,90 1,00 1,15 1,30 1,00 1,15 1,40 1,95 1,00 1.Ю 1,35 1,85 0,80 1,00 1,20 1,40 0,90 1,00 1,15 1,30 1,50 1,20 1,00 0,85 0,70 1,25 1.Ю 1,00 0,92 0,85 1,50 1,20 1,00 0,83 0,65 1,45 1.20 1,00 0,85 0,70 1,25 1,10 1,00 1,00 1,05 0,75 0.88 1.00 1,15 1,40 0,94 1,00 1,08 1,16 1,00 1,11 1,30 1,66 1,00 1,06 1,21 1,56 0,87 1,00 1,15 1,30 0,87 1,00 1,07 1,15 1,46 1,19 1,00 0,86 0,71 1,29 1,13 1,00 0,91 0,82 1,24 1,10 1,00 0,91 0,82 1,24 1.Ю 1,00 0,91 0,83 1,23 1,08 1,00 1,04 1.Ю
Примечание. СВО — среднее время ответа.
298
можности легко и непосредственно вручную получать оценку стои-
мости на данном уровне детализации. Криме того, поскольку про-
цедуры довольно длинны, а пользователь может пожелать запро-
граммировать их на ЭВМ, такая организация позволяет достаточ-
но последовательно реализовать их алгоритмически.
В процедурах используется набор таблиц, коэффициентов за-
трат труда, которые для каждого рейтинга стоимостного атрибута
показывают его значимость на каждой основной фазе разработки
ПО. Коэффициенты затрат по каждому стоимостному атрибуту на
уровне модуля приведены в табл. 23.2, а на уровне подсистемы — в
табл. 23.3. Происхождение этих таблиц объясняется в гл. 24—27.
23.4. ИНФОРМАЦИОННАЯ СИСТЕМА СТУДЕНЧЕСКОЙ ЗАНЯТОСТИ. ПРИМЕР
ИСПОЛЬЗОВАНИЯ ДЕТАЛЬНОЙ КОМОСТ
Обзор проекта. Информационная система студенческой занято-
сти (СТУДЗАН) будет реализована на средней универсальной
ЭВМ, ориентированной в основном на пакетную обработку. Техни-
ческие средства ЭВМ, операционная система, компилятор и средст-
ва файловой обработки и генерации отчетов, использ5емые в
СТУДЗАН, достаточно однородны, в системе есть много полезных
средств, облегчающих разработку ПС. В процессе эксплуатации не
накладывается ограничений на время выполнения и объем опера-
тивной памяти, также не требуется особо высокий уровень на-
дежности. Размер информационной базы данных по работам и сту-
дентам не очень велик.
Проект начинается с фазы планирования и выработки требова-
ний. Для получения оценки требуемых затрат труда и сроков раз-
работки используется детальная КОМОСТ с несколькими незави-
симыми экспертными оценками. Руководитель проекта не думает
серьезно отклоняться от оценочных сроков разработки.
Руководитель проекта собирается работать в стиле «демокра-
тичного Главного Программиста», лично выполняя весь предвари-
тельный анализ и осуществляя совместно с остальными програм-
мистами анализ и проектирование программируемых модулей. Он
собирается сам запрограммировать модуль ПОИСК—наименьший
из всех модулей, но требующий глубочайшего понимания основ
операционной системы и системы управления данными — и быть
главным ответственным лицом за комплексирование и отладку. ‘
Один из программистов, участвующий в проекте, достаточно
квалифицированный и опытный, будет разрабатывать модули ЗА-
ПРЕД и КОРРЕД. Остальные три модуля — ВЫВОД, МОДИФ и
УТИЛИТЫ — менее сложны. Несколько новых проходящих прак-
тику программистов скоро присоединятся к группе, и одному или
двум из них будет поручена работа над этими модулями.
Пошаговое оценивание. Ниже приводится обсуждение пошаго-
вого заполнения ФИОПО (см. рис. 23.1 и 23.2) при оценивании
стоимости, затрат -руда и сроков, предусмотренных на разработку
299
Шаги 1 и 2. В формах для подсистем (ПС-форма) и модулей
(М-форма) обозначаются все подсистемы и модули. Дополнитель-
ные итоговые строки для подсистем добавляются в М-форме после
занесения названий всех модулей каждой подсистемы (за исклю-
чением подсистемы УТИЛИТЫ, состоящей из одного модуля).
Шаг 3. Размер каждого модуля заносится в столбец 6 и вычис-
ляются размеры каждой подсистемы (ЗАПРОС: 3700 ЭЧИК-
КОРРЕКТ: 2600 ЭЧИК; УТИЛИТЫ: 1700 ЭЧИК). Подсистем!
УТИЛИТЫ является адаптацией 5000 ЧИК существующего ПО с
25%-ным изменением кода и 30%-ными затратами на комплекси-
рование, что дает:
ККА = 0,4-25+0,3-50+0,3-30=34;
ЭЧИК = 5000-34/100=1700.
Шаг 4. Размеры подсистем переносятся в столбец 7 ПС-формы
Полный вычисленный размер изделия СТУДЗАН равен 8000
ЭЧИК.
Шаги 5 и 6. Номинальные затраты труда равны 3,2-81,05=
=28,4 ЧМ, а номинальная производительность — 8000/28,4=
=282 ЭЧИК/ЧМ.
Шаг 7. В данном случае для определения распределений по фа-
зам не требуется интерполяция по табл. 6.8.
Шаг 8. Например, вычислим ЧМНОм.ср для модуля КОРРЕД по
четырем фазам:
ФПИ : ЧМном фпи — 1700 ЭЧИК-1,16 282 ЭЧИК/ЧМ = 1,0 ЧМ;
ФДП : ЧМном фдп = - 1700 ЭЧИК-0,25 282 ЭЧИК/ЧМ = 1,5 ЧМ;
ФКАО: ЧМНом фкао = 1700 ЭЧИК-0,40 282 ЭЧИК/ЧМ - = 2,4 ЧМ;
ФКИ : ЧМном фки = - 1700 ЭЧИК-0,19 282 ЭЧИК/ЧМ = 1,1 ЧМ.
Шаг 9. Для модуля ЗАПРЕД рейтинги всех стоимостных факто-
ров на уровне модулей являются номинальными. Модуль ПОИСК,
программируемый руководителем проекта, получает меньший ко-
эффициент затрат труда, поскольку квалификация и опыт руко-
водителя уменьшают номинальные затраты труда на разработку
этого модуля. Заметим, что знание руководителем языка програм-
мирования уменьшает затраты труда лишь на фазе кодирования и
автономной отладки, а также на фазе комплексирования и испы-
таний, но не дает реального эффекта на более ранних фазах.
Шаг 10. Корректирующие коэффициенты затрат труда для мо-
дуля ЗАПРЕД равны 1,0 по каждой фазе, поскольку все рейтин-
ги модуля являются номинальными. Значение этого коэффициента,
например, на фазе комплексирования и испытаний разработки мо-
дуля ПОИСК равно
0,83-0,90-0,92=0,69.
300
Шаг 11. Скорректированные затраты труда по фазам для мо-
дуля ЗАПРЕД являются номинальными. Для модуля ПОИСК на
фазе комплексирования и испытания квалификации и опыт руко-
водителя проекта приводят к снижению оценки необходимых за-
трат труда с 0,5 ЧМ до 0,69-0,5 ЧМ = 0,3 ЧМ.
Заметим, что модули КОРРЕД и УТИЛИТЫ имеют одно и то
же распределение номинальных затрат труда по четырем фазам:
0,7; 1,4; 2,4; 1,1. Модуль КОРРЕД не имеет номинального рейтин-
га уровня модуля, поэтому на данном шаге распределение по фа-
зам остается прежним. Для модуля УТИЛИТЫ низкие рейтинги
квалификации и опыта программиста ведут к увеличению затрат
труда на последних фазах: 0,7; 1,4; 2,5; 1,2.
Шаг 12. Общая оценка затрат труда на этом шаге для подси-
стемы ЗАПРОС на фазе проектирования изделия равна 1,0+0,4+
+ 0,6=2,0 ЧМ. На фазе детального проектирования она равна:
1,64-0,4+1,2=3,2 ЧМ. Поскольку подсистема УТИЛИТЫ состоит
только из одного модуля, дополнительных итоговых подсчетов не
требуется.
Шаг 13. Итоговые затраты труда по подсистемам переносятся
из М-формы в ПС-форму (столбец 20, между столбцами 32 и 33).
Шаг 14. Три подсистемы изделия СТУДЗАН очень сходны по
атрибутам уровня подсистемы. Большая часть рейтингов номиналь-
на, а некоторое снижение стоимости объясняется стабильностью
виртуальной машины (низкий рейтинг ИВМ), лежащей в основе
разработки, и широким использованием вспомогательного приклад-
ного ПО и современной практики программирования. Подсистема
УТИЛИТЫ имеет номинальные рейтинги стоимостных атрибутов
«квалификация аналитика» и «знание прикладной области», в то
время как ЗАПРОС и КОРРЕКТ обладают для этих стоимостных
атрибутов высокими рейтингами. Это находит отражение в выводе
руководителя проекта о том, что его квалификация и опыт должны
быть главными факторами при анализе и разработке подсистемы
ЗАПРОС и КОРРЕКТ и не играть такой роли для подсистемы
УТИЛИТЫ. Действительно, если анализ и разработка каждой под-
системы будут осуществляться совместно людьми разной квалифи-
кации, то для коэффициентов затрат труда будут использоваться
некоторые интерполированные значения.
Шаг 15. Для подсистем ЗАПРОС и КОРРЕКТ общие значения
ККЗ на подсистему одни и те же. Заметим, что их совокупный
эффект проявляется в уменьшении почти на 50% оценки требуемых
затрат труда по сравнению с номинальными, причем наибольшее
снижение затрат происходит на фазе комплексирования и испы-
таний.
Шаг 16. Окончательные оценки затрат труда находят умноже-
нием скорректированных оценок уровня модуля (таких как 2,0 ЧМ
Для подсистемы ЗАПРОС на фазе проектирования изделия) на
соответствующие ККЗ подсистем (равные 0,52 для тех же усло-
вий), получая окончательную оценку в 1,0 Ч.
301
Шаг 17. Полная оценка для всего проекта СТУДЗАН равна
16,1 ЧМ— чуть больше половины оценки номинальных затрат тру,
да 28,4 ЧМ, Распределение по фазам корректируется коэффициен-
тами затрат труда следующим образом (табл. 23.4):
Таблица 23.4
Фаза Начальное РАЗБ Скорректированное РАЗБ
ФТПИ 0,16 2,4/16,1=0,15
ФДП 0,25 4,4/16,1=0,27
ФКАО 0,40 6,8/16,1=0,42
ФКИ 0,19 2,5/16,1=0,16
Шаг 18. Итоговая оценка сроков разработки; 2,5-16,1°-3®=
= 7,2 мес.
Шаг 19. Оценочная оплата труда для подсистем ЗАПРОС н
КОРРЕКТ на фазе проектирования изделия выше из-за главной
роли в них более высоко оплачиваемого руководителя проекта.
Они также выше на фазе комплексирования и испытаний из-за
ожидаемого повышения окладов. Оценки стоимости включают при-
близительно 100% накладных расходов, которые являются типич-
ными для программистских организаций [238].
Шаг 20. Оценочная полная оплата труда за разработку системы
СТУДЗАН — 84 300 долл. Распределение оплаты по фазам (0,16;
0,26; 0,41; 0,16) несколько ближе к номинальному, чем это было
для распределения затрат труда.
Шаги 21 и 22. Для подсистемы ЗАПРОС получаются следую-
щие оценки: затраты трупа на разработку — 6,8 ЧМ, стоимость
разработки — 35 500 долл., производительность — 3700 ЭЧИК/
6,8 ЧМ = 544 ЭЧИК/ЧМ, цена команды — 35 500 долл./3700
ЭЧИК = 10 долл./ЭЧИК.
Шаг 23. Оценочная производительность для всего проекта
СТУДЗАН — 8000 ЭЧИК/16,1 ЧМ = 497 ЭЧИК/ЧМ, а цена коман-
ды — 84 300 долл./8000 ЭЧИК = 11 долл./ЭЧИК.
Шаг 24. Для ЗАПРЕД оценочные затраты труда по фазам:
ФПИ: 0,52-1,0 ЧМ=0,5 ЧМ; ФДП: 0,58-1,6 ЧМ=0,9 ЧМ;
ФКАО: 0,53-2,6 ЧМ = 1,4 ЧМ; ФКИ: 0,41-1,2 ЧМ = 0,5 ЧМ.
Шаг 25. Для подсистемы ЗАПРОС итоговые данные по модулям
на каждой фазе дают следующие результаты — 1,0; 1,8; 3,0; 1,0 ЧМ.
Сравнением с вычисленными значениями на уровне подсистемы в
столбце 33—1,0, 1,9; 2,9; 1,0 ЧМ — осуществляется проверка в пре-
делах ожидаемой точности, обусловленной ошибками округления.
Для этого примера справа добавляется итоговый столбец, по-
казывающий результрующее распределение затрат труда по фа-
зам для каждого модуля и подсистемы. Заметим, что для модуля
ПОИСК, разработанного руководителем проекта, более высокая
доля затрат труда (22%) относится к проектированию изделия, а
более низкая доля (11%) — к комплексированию и испытанию.
302
23.S. ВЫЧИСЛЕНИЕ СКОРРЕКТИРОВАННЫХ СРОКОВ РАЗРАБОТКИ
Как было показано в предыдущем разделе, коэффициенты вно-
сят изменения в распределение затрат труда по фазам, несколько
отличающееся от номинального. Ясно, что эти изменения должны
найти отражение и в изменении номинального распределения про-
ектных сроков. Это достигается корректирующими вычислениями
сроков, описанными ниже.
Процедура корректировки сроков. Шаг 1. Определить номи-
нальные доли сроков разработки, относящихся к ФПИ, ФП и ФКИ,
с помощью интерполяции значений из табл. 6.8. Назовем эти коэф-
фициенты (/?фпи)иом, (Афп)11ОМ И (^фки)ном- (Соответствующие
номинальные доли проектируемых затрат труда (Зфпи)ном»
(Зфдп)ном» (Зфкао)ном и (Зфки)ном уже определены и указаны
в табличке 12 ПС-формы ФИОПО.)
Шаг 2. Определить скорректированные доли затрат труда на
фазах ФПИ, ФДП, ФКАО и ФКИ по оценочным значениям, взя-
тым из нижней части столбца 33 ПС-формы. Назовем эти доли
ЗфПИ, ЗфДП, ЗфКАО. И ЗфКИ.
Шаг 3. Определить пропорциональные изменения в распреде-
лении проектных сроков в соответствии с изменениями в распреде-
лении затрат труда на проектирование и вычислить скорректиро-
ванные доли распределения сроков:
FФПИ = (^ФПи)цом’ Зфпи/(3фпи)ном’
Гфп = (F Фп)ном • (ЗфДП + ЗфКАо)/[(ЗфДп)ном + (ЗфКАо)номК
^ФКИ = (^ФКи)ном • Зфки/(Зфки)ном*
Шаг 4. Поскольку скорректированные доли распределения сро-
ков в сумме могут отличаться от 1,0, вычислить нормирующий мно-
житель
Ан = ^фпи + АФП + Гфки-
Шаг 5. Разбить скорректированный срок полной разработки Ср
(из нижней части столбца 34 ПС-формы) по фазам в соответствии
с нормированными долями:
Сфпи = (Ср) (F фпи)
Сфп = (Ср) (F<t>ri)/Fn;
Сфки = (Ср) (/?фки)//’’н-
Пример. Рассмотрим применение процедуры корректировки сро-
ков на примере информационной системы СТУДЗАН.
Шаги / 2. Из табл. 6.8 находим доли номинального распре-
деления сроков проектирования:
(f®nH)HOM = 0,19; (^фпКом = 0,59;
(Афки)ном- 0Д2.
303
Доли номинального и скорректированного распределения за.
трат труда следующие:
(Тфпи)ном — 0,16; Зфпи =2,4/16,1 —0,15;
(Тфдп)ном = 0,25; Зфдп = 4,4/16,1=0,27;
(Тфкао)ном — 0,40; Зфкло = 6,8/16,1 =0,42;
(Тфки)ном = 0,19; 3 фки = 2,5/16,1 =0,16.
Шаги 3 и 4. Пропорциональные изменения в распределении
проектных сроков и итоговый нормирующий множитель вычисля-
ются следующим образом:
Гфпи = 0,19-0,15/0,16 = 0,18;
ГФП = 0,59 • (0,27 + 0,42)/0,25 + 0,40 = 0,63;
ГФКи = 0,22-0,16/0,19 = 0,19;
FH=l,00.
Шаг 5. Скорректированная оценка срока разработки: С =
7,2 мес. Итоговые скорректированные оценки сроков по фазам
вычисляются так:
Сфпи =7,2-0,18/1,00 = 1,3 мес.
СФП = 7,2-0,63/1,00 = 4,5 мес.
Сфки =7,2-0,19/1,00 = 1,4 мес.
Для проверки вычислить сумму этих сроков, которая равна
|тем же 7,2 мес.
23.6. ОБСУЖДЕНИЕ
Распределение затрат труда по фазам. Главной дополнитель-
ной возможностью детальной КОМОСТ, отличающей ее от базо-
вой и промежуточной моделей, является обеспечение лучшего ба-
зиса для детального планирования штата разработчиков в зависи-
мости от профессионального уровня, необходимого для успешного
завершения каждой фазы разработки ПО. Проекты с очень высо-
кими требованиями к надежности или жесткими ограничениями на
ТО потребуют больших затрат труда на комплексирование и испы-
тание, проекты же, разработчики которых имеют очень .малый
опыт в прикладной области, потребуют больших затрат на проек-
тирование изделия.
Таким образом, вместо единственного распределения затрат
труда по фазам, основанного лишь на размере изделия и типе раз-
работки (как в промежуточной КОМОСТ), или единственного
семейства кривых рэлеевского распределения уровня привлекаемых
разработчиков, в детальной КОМОСТ учитываются изменения в
распределении по фазам, обусловленные и другими стоимостны-
ми атрибутами. В гл. 24—27 приводятся таблицы (по одной на
каждый атрибут), отражающие различия в работах по проектиро-1
04
ванию из-за различия рейтингов соответствующего стоимостного
атрибута. Эти таблицы являются одной из попыток продемонстри-
ровать конструктивность модели стоимости, объясняющей в тер-
минах проекта выдаваемые результаты.
Зависимость оценок детальной КОМОСТ от конкретных дан-
ных проекта, имеющихся в базе данных КОМОСТ, представлена в
гл. 29. Эти результаты показывают, что коэффициенты обычно
обеспечивают значительную близость распределения затрат труда
по фазам к реальному.
Предельный случай распределения по фазам. Чтобы продемон-
стрировать чувствительность детальной КОМОСТ, на рис. 23.3 и
23.4 приведен пример вычислений для экстремального случая ги-
потетического проекта, рейтинги стоимостных факторов которого
подобраны специально для обеспечения наибольшей возможной
доли затрат труда в разработке на фазе комплексирования и ис-
пытания. Рейтинги выбраны следующим образом:
ТНПО .............................очень высокий
РБД ..............................очень высокий
ОБД.................................сверхвысокий
ОП................................сверхвысокий
ИВМ...............................очень высокий
ЦО................................очень высокий
КА................................очень низкий
ОРП............................. . очень высокий
ПСП .............................. очень низкий
ИИС............................... очень низкий
ОСР............................... очень низкий
СИЗ .................................номинальный
КП................................очень низкий
ОРВМ.............................. очень низкий
ОРЯП.............................. очень низкии
Вероятность возникновения такого проекта также очень мала,
однако поучительность примера состоит в демонстрации предельно-
го влияния коэффициентов детальной КОМОСТ.
Проект, рассматриваемый в примере, имеет средние размеры
(32 КЧИК) разработки встроенного типа со следующим номиналь-
ным распределением затрат труда по фазам:
. Проектирование изделия.....................18%
Детальное проектирование...................26%
Кодирование и автономная отладка .... 28%
Комплексирование и испытание...............28%
После оценивания затраты по каждой фазе модифицированы с
учетом предельных значений рейтингов стоимостных атрибутов
согласно детальной КОМОСТ. В результате распределение выгля-
дит следующим образом:
Проектирование изделия......................2%
Детальное проектирование....................7%
Кодирование и автономная отладка .... 18%
Комплексирование и испытание...............73%
305
Д»Т»
Проект: Комплексирование и испытание
Аналитик: фамилия
ФПИ
ФДП
ФКАО
ФКИ
О @ Подсис- тема ® ЭЧИК Изделие Атрибуты ЭВМ Исполнители Проект ® ККЗ ПС ^Мкор / © ® тыс. долл. ЧМ ® тыс. долл. Всего СРЕДН
© тнпо @ РБД ® ОБ оп ® ИВМ @ Цо @ КА ® ОРП ПСП иис ОСР
1 Подсис- тема 32,000 1,30 1,30 1.30 1,70 1,20 1,10 1,10 1,30 1,65 1,55 1,55 1,95 1,55 1,45 1,45 1,85 1.20 1,25 1,30 1,40 1,02 1,05 1,20 1,30 1,80 1,35 1,35 1,50 0,75 0,80 0,85 0,85 1.05 1,10 1.25 1,50 1,02 1,05 1,35 1,45 1,10 1.25 1,25 1,25 5,01 6,58 12,1 50,3 36 86 117 117 180 566 1420 5885
Тип: _ (jo) Встроенная © 3ZOOO Всего ЭЧИК © Фазовые коэффициенты ФПИ ФДП ФКАО ФКИ Всего 180 566 1420 5885 21, 7% 18% 73%
179 ЧМном
ФПИ ФДП ФКАО ФКИ 18 26 28 28
179 (ЭЧИК/ЧМ) ном 8051 •
ТЫС. ДОЛЛ.
Рис. 23.3. Форма иерархического оценивания уровня подсистемы. Комплексиро-
вание и испытания с высоким рейтингом
Проект: Комплексирование ^испытание с высоким рейтингом Аналитик: фамилий Дата:
ФПИ
ФДП
ФКАО
ФКИ
© №ПС N’ мод © Модуль ЭЧИК © ККА сиз © КП ОРВМ ОРЯП ® ККЗ мод ® чмн0М ® чмКОр © чмоа Доля, %
1 1 Модуль 32,000 100 1.0 1.0 1.50 1.50 1,50 1,10 1.10 1.30 1,30 1,02 1.10 1.20 1,20 1,12 1,82 2.34 2,34 32 47 50 50 36 86 117 117
Рис. 23.4. Форма иерархического оценивания уровня модуля. Комплексирование
и испытания с высоким рейтингом
Если подсчитать скорректированные сроки и начертить оконча-
тельные относительные уровни числа исполнителей по‘сравнению
с номинальным распределением по фазам, получится диаграмма,
изображенная на рис. 23.5. Подавляющая часть как времени, так
и затрат труда в экстремальном случае на этой диаграмме отно-
сится к фазе комплексирования и испытаний.
Этот пример является искусственным предельным случаем и не
следует пытаться организовать проект подобным образом (хотя
некоторые проекты оказывались катастрофически близки к этому).
Дополнительное преимущество детальной КОМОСТ состоит еще и
Программирование
Г--------------------
-Программирование
1,00
0,75
0,50
ФПИ
Проектирование
изделия
0,25
Комплексирование
и испытания
Комплексирование
и испытания
Номинальное--------
Комплексирование-----—
И испытание с высо-
ким рейтингом
J_!_L L.I_Illi
10 20 30 40 50 60 70
J_____I
80 90 100
Доля времени разработки, %
Рис. 23.5. Сравнение номинального и предельного распределений в детальной
КОМОСТ
в том, что она заостряет внимание на том, почему нельзя действо-
вать подобным образом.
Другие компоненты детальной КОМОСТ. Два других компонен-
та детальной КОМОСТ являются теми же, что и промежуточной.
Затраты труда на сопровождение находят как функцию опреде-
ленных в детальной КОМОСТ затрат труда на разработку, годово-
го уровня изменений программ и коэффициентов стоимостных ат-
рибутов для затрат труда на сопровождение (см. разд. 8.5), вы-
численных по промежуточной КОМОСТ. Модифицированный
коэффициент затрат труда для ПСП (см. табл. 8.8) применяется,
как и раньше, к размеру всего проекта.
Распределение работ вычисляется как функция размера про-
екта и типа разработки по таблице распределения работ в базовой
КОМОСТ (см. разд. 7.2).
308
Детальная КОМОСТ отличается от базовой и промежуточной
возможностью оценки затрат труда, необходимых на фазе плани-
рования и выработки тоебований. Для вычисления поправок к но-
минальной доле затрат труда на фазе планирования и выработки
требований в детальной КОМОСТ используются коэффициенты
затрат труда на фазе проектирования изделия, взятые из табл. 6.8.
Таблица 23.5
Обзор иерархии КОМОСТ
Оцениваемая величина КОМОСТ
базовая | промежуточная детальная
Затраты труда на ! (тип, КЧИК), f (тип, кчик, 15 f (тип, КЧИК, 15
разработку ЧМр см. табл. 6.1 стоимостных фак- торов), см. табл. 8.1, 8 2 стоимостных фак- 8.1, 23.2. 23.3 -оров), см. таб 1.
Сроки разработки /' (тип, ЧМр), см. абл. 6.1 Как в базовой мо- дели Как в базовой мо- дели
Затраты труда на f (ЧМр, КПГИ). ) (ЧМр, КПГИ. Как в промежу-
сопровождение см. (5.6) 15 стоимостных факторов), см. (5.6), табл. 8.2, 8.7, 8.8 точной модели
Иерархия изделия Вся система ФОК система — компоненты и про- цедуры, см. табл. 9.1 ФИОПО систе- ма — подсисте- ма — модуль и процедуры. См. табл. 23.1
Распределение за- /' (тип, КЧИК), Как в базовой мо- f (тип, КЧИК,
трат труда по фа- зам см. табл. 6.8 дели 15 стоимостных атрибутов), см. табл. 6.8, 23.2,23.3
Распределение f (тип, КЧИК), Как в базовой мо- t (базовое распре-
сроков по фазам см. табл. 6.8 дели деление сроков, детальное распре- деление затрат труда), табл 6.8, разд. 23.5
Распределение f (тип, КЧИК), Как в базовой мо- Как в базовой мо-
проектных работ см. табл. 7.1—7.3 дели дели
Доля затрат на f (тип, КЧИК), Как в базовой мо- f (тип, КЧИК, 15
фазе анализа тре- бований см. табл. 6.8 дели стоимостных атри- бутов), см. табч. 6.8, 23.2, 23.3
Краткий обзор иерархии КОМОСТ. В табл. 23.5 подытожены
сходства и различия по всем трем уровням иерархии КОМОСТ (ба-
зовая, промежуточная и детальная). Кроме того, в ней указано,
какие конкретно таблицы и уравнения используются на данном
уровне иерархии моделей при вычислении каждой оценки (затра-
ты труда и сроки разработки, затраты на сопровождение, распреде-
ление затрат труда, сроков и работ по фазам).
309
ГЛАВА 14
АТРИБУТЫ ПРОГРАММНОГО ИЗДЕЛИЯ КАК СТОИМОСТНЫЕ
ФАКТОРЫ ДЕТАЛЬНОЙ КОМОСТ
24.1. ТРЕБУЕМАЯ НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (ТНПО)
Надежность программного обеспечения Н определяется как ве-
роятность удовлетворительного выполнения возложенных на него
функций при следующем его запуске или в следующий интервал
времени выполнения. Надежность можно вычислить, зная:
функциональный профиль ПО — распределение вероятности в
пространстве возможных входных данных, характеризующее вы-
борки каждого элемента входных
данных при следующем запуске
ПО или в следующий интервал
времени его выполнения;
точный смысл выражения
«удовлетворительно выполняет
возложенные на него функции».!
Задав эту информацию, можно
получить несмещенную оценку Н
с минимальным разбросом, если
выполнить следующие действия
[53]:
выбрать любые N элементов
входных данных в соответствии с
распределением функционального
профиля;
осуществить N запусков ПО
или его выполнение в течение W
Рис. 24.1. Выборка из области вход- интервалов времени;
ных данных для измерения надеж- используя критерий удовлетво-
ности ПО рительности функционирования,
определить число успешно выпол-
ненных запусков или число правильно отработанных интервалов
времени (обозначим это число через М);
вычислить Н = M/N.
Рисунок 24.1 иллюстрирует этот процесс.
Если бы перечисленные выше шаги были легко осуществимы на
практике, то вычисленное значение Н для программных изделий
можно было бы использовать в качестве стоимостного атрибута
детальной КОМОСТ. К сожалению, выполнить эти вычисления не-
легко по следующим основным причинам:
пространство входных данных невероятно велико;
и без того очень сложная проблема функционирования ПО в
рабочих условиях является частным случаем проблемы выявления
функционального профиля ПО;
310
чрезвычайно трудно обеспечить представительный набор слу-
чайных входных данных, что может подтвердить каждый, сталки-
вающийся с обычными неожиданностями при тестировании про-
граммных изделий;
как правило, выявление сбоя ПО приводит к его исправлению,
что в какой-то степени сводит на нет результаты, относящиеся к
исходному ПО.
Большинство современных попыток оценки Н основывается на
тестовых данных для ПО. Их, в целом плохие на сегодняшний
день, результаты (см., например, [281]) в основном обусловлены
тем, что тестирование является не слишком хорошим приближени-
ем процесса «случайной выборки в соответствии с функциональ-
ным профилем» [286]. Лучшие на сегодня результаты [215, 217]
получены на основе данных по ошибочному функционированию
промышленных систем реального времени и систем с разделением
времени, в которых последовательность входных данных является
хорошим приближением случайной выборки, соответствующей
функциональному профилю.
Опыт показывает, что для детальной КОМОСТ вполне доста-
точно использовать рейтинг стоимостного атрибута ТНПО, а при
оценивании взаимосвязи между повышением надежности ПО и по-
вышением его стоимости в качестве основы использовать косвен-
ные, а не прямые данные.
Рейтинги и коэффициенты затрат. В табл. 23.3 представлены
коэффициенты затрат в детальной КОМОСТ на разработку ПО в
зависимости от требуемой надежности подсистемы ПО. В деталь
ной КОМОСТ требуемая надежность может меняться от одной
подсистемы ПО к другой, отражая ситуацию, в которой для одних
подсистем (таких как ОС или основная подсистема) может требо-
ваться более высокая надежность, чем для других (таких как об-
служивающее ПО или постпроцессорная подсистема). Однако тре-
буемая надежность от модуля к модулю в рамках одной подсисте-
мы меняться, как правило, не будет.
Коэффициенты полных затрат (см. табл. 23.3) вычислены по
фазовым коэффициентам затрат с учетом веса фазы: проектиро-
вание изделия 15%, детальное проектирование 30%, кодирование
и автономная отладка 30%, комплексирование и испытания 25%.
Эти коэффициенты и служат коэффициентами затрат, используе-
мыми для атрибута ТНПО в промежуточной КОМОСТ.
Шкала рейтингов для атрибута ТНПО с типичными примерами
соответствующих устройств или систем (приведены в скобках)
выглядит следующим образом:
Очень низкий .... При сбоях ПО разработчикам необходимо ис-
править соответствующую ошибку (макетный об-
разец печатающего устройства, управляемого го-
лосом, или имитационная модель ПО на фазе
анализа его осуществимости)
Низкий............ При сбоях ПО п >льзователь легко восполняет
потери (модель долгосрочного планирования или
модель прогнозирования погоди)
311
Номинальный . . . Сбой ПО приводит к умеренным потерям, од-
нако ликвидация последствий сбоя осущес~вля
ется без чрезмерных усилий (информационные си
стемы и системы управления запасами)
Высокий............. Сбой ПО может привести к серьезным финан-
совым убыткам или причинить неудобства боть
шому числу людей (системы банковского учета,
или системы распределения электроэнергии)
Очень высокий ... Результатом сбоя ПО могут стать смертельное
случаи (системы войскового управления или си-
стемы управления ядерным реактором)
Некоторые подробности, относящиеся к функциональной значи-
мости шкал рейтинга ТНПО, обсуждались в гл. 8 при описании
промежуточной КОМОСТ. Основное отличие атрибута ТНПО в
детальной и промежуточной КОМОСТ состоит в зависимости коэф-
фициентов затрат от фазы работы над проектом. Как видно из
табл. 23.3, дополнительные затраты, требуемые для достижения
высокой надежности (или уменьшение затрат, требуемых для
обеспечения более низкой надежности), примерно одинаковы для
первых трех фаз и значительно выше (ниже) для фазы комплек-
сирования и испытаний. Графически это изображено на рис. 24.2.
Рис. 24.2. Распре-
деление коэффи-
циентов затрат
труда по фазам
для атрибута
ТНПО
Изменения в работе над проектом, соответствующие рейтингам
атрибута ТНПО. Некоторые из причин, объясняющих изменение
коэффициентов затрат в детальной КОМОСТ, даны в табл. 24 1.
В ней приводятся отличия в работе над проектом, которые будут
вызваны увеличением или уменьшением требуемой надежности и
которые в свою очередь приведут к более высокой или более низ-
кой стоимости проекта.
Так, например, достижение очень высокой надежности приведе!
к 30% дополнительных затрат на фазе планирования и специфи-
кации требований и на фазе проектирования изделия. Эти затраты
312
Таблица 24.1 Изменения в работе над проектом на разных фазах, обусловленные требуемой надежностью ПО
Анализ требований и проектирование изделия Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Очень низкий рейтинг
Меньше подробностей Меньше верификации Миним>м УК и КК, проек- тов руководств для пользо- вателя, планов тестирова- ния ^Минимальный АПИ Основная информация по про- екту Минимум УК и КК, проектов руководств для пользователя, планов тестирования Неформальный сквозной конт- роль проекта Отсутствие процедур тестиро- вания Минимальные тестирование ветвей программы и контроль стандартов Минимум УК и КК Минимальные нестандартное тестирование и тестирование ввода-вывода Минимум руководств для поль- зователя Отсутствие процедуры тестиро- вания Много нетестируемых требова- ний Минимум УК и КК Минимальные тестирование пиковых режимов и нестан- дартное тестирование Минимум рабочей документа- ции
Низкий рейтинг
Основные информация и верификация Основные УК и КК, стан- дарты, проекты руководств для пользователя, планы тестирования Умеренная детализация Основные УК и КК, проекты руководств для пользователя, планы тестирования Минимум процедур тестирова- ния Частичные тестирование вет- вей программы и контроль стандартов Основные УК и К К, руковод- ства для пользователя Частичные нестандартное те- стирование и тестирование ввода-вывода Минимум процедур тестирова- ния Много нетестируемых требова- ний Основные УК и КК, руководст- ва для пользователя Частичные тестирование пико- вых режимов и нестандартное тестирование
СР
Окончание табл. 24.1
Номинальный рейтинг
Номинальные верификация и подтверждение проекта ------------------
Высокий рейтинг
Детальные верификация,
УК и КК, стандарты, АПИ,
документация
Детальные планы и про-
цедуры тестирования
Детальные верификация, УК и
КК. стандарты, КАП, докумен-
тация
Детальные планы и процедуры
тестирования
Детальные процедуры тестиро-
вания, УК и КК, документация
Широкое применение нестан-
дартного тестирования
Детальные процедуры тестиро-
вания, УК и КК, документация
Широкое применение нестан-
дартного тестирования и тести-
рования пиковых режимов
Очень высокий рейтинг
Детальные верификация,
УК и КК, стандарты, АПИ,
документация
Независимые верификация
и подтверждение
Очень детальные планы и
процедуры тестирования
Детальные верификация, УК и
КК, стандарты, КАП, докумен-
тация
Очень строгий сквозной конт-
роль проекта
Сверхдетальные планы и про-
цедуры тестирования
Независимые верификация и
подтверждение
Независимые верификация и
подтверждение
Детальные процедуры тестиро-
вания, УК и КК, документация
Очень строгий сквозной конт-
роль кода
Очень широкое применение не-
стандартного тестирования
Сверхдетальные процедуры те-
стирования, УК и КК, доку-
ментация
Очень широкое применение не-
стандартного тестирования и
тестирования пиковых режи-
мов
Очень широкое применение не-
стандартного тестирования и
тестирования пиковых режи-
мов
Независимые верификация и
подтверждение
пойдут на верификацию детальных требований и проекта изделия,
а также на более детальное планирование контроля качества (КК)
и управления конфигурацией (УК), определение стандартов изде-
лия, анализ проекта изделия (АПИ), разработку документации на
изделие и критический анализ проекта (КАП). Кроме того, для
проекта могут потребоваться затраты, связанные с организацией
независимых верификации и подтверждения (НВП) и более де-
тальными планами и процедурами тестирования.
Достижение очень высокой надежности приведет также к 70%
дополнительных затрат на фазе комплексирования и испытаний.
На этой фазе помимо дополнительных забот о КК, УК и аналогич-
ной работе потребуется много затрат, связанных с тестированием
пиковых режимов для проверки устойчивости ПО, а также, воз-
можно, математической верификацией ПО. Дополнительные затра-
ты на тестирование пиковых режимов могут включать затраты на
экстремальные объемы подлежащих обработке входных данных,
непредусмотренные распределения этих данных (такие, как точки
разрывов и экстремумов), экстремальные уровни частоты ошибоч-
ных входных данных, нарушения предположений о функциониро-
вании (например, протоколов пользователя), происшедшие или
имитированные сбои технического обеспечения, использование ПО
необученным штатом или, наоборот, экспертами.
Для иллюстрации сказанного попробуйте, например, опреде-
лить распределение затрат для проекта большого (128 КЧИК)
встроенного ПО, если номинальное распределение затрат по фа-
зам для него составляет: проектирование изделия 18%, детальное
проектирование 25%, кодирование и автономная отладка 26%,
комплексирование и испытания 31%, — и требуется очень высокий
уровень надежности этого ПО.
Сравнение с фактическими данными. Самый простой путь ана-
лиза соответствия коэффициентов затрат в КОМОСТ фактическим
данным по проектам ПО состоит в исследовании производитель-
ности разработки проекта как функции рейтинга проекта для за-
данного стоимостного атрибута *. Это соответствие для атрибута
ТНПО показано на рис. 24.3, причем для простоты используются
коэффициенты полных затрат в промежуточной КОМОСТ.
Результаты довольно неубедительны. Согласование между
очень высокой, а также высокой требуемой надежностью и низкой
производительностью разработки проекта отчетливо видно, но это-
го не наблюдается для более низких рейтингов атрибута ТНПО.
Это очевидно по поведению средних значений производительности
для различных рейтингов (стрелки на рис. 24.3). Главная причина
неполного соответствия состоит в том, что на атрибут ТНПО слож-
ным образом влияют другие стоимостные факторы. Например, не-
которые проекты базы данных КОМОСТ с очень низкой требуемой
надежностью характеризуются относительно низкой производи-
1 Это основной тип анализа, проведенного в работе [291] для проектов базы
Данных фирмы IBM.
315
тельностью разработки, так как были выполнены аналитиками и
программистами весьма низкой квалификации при очень малом
использовании практики современного программирования (под-
робные данные по этим проектам приводятся в табл. 29.1).
Для получения более четкого представления о влиянии требуе-
мой надежности на производительность разработки нужно устра-
• {1250}
всэ
700
Б00
Б00
400
низким Низкий цельный
---1_______I_______1__
0,80 0,90 1,00
i
’ П
I Высокий Очень высокий
__________I I
1,10 1,20 1,30 1,40
Коэффициент затрат в КОМОСТ
Рис. 24.3. Корреляция производительности разработки проекта и требуемой на-
дежности при различных рейтингах атрибута ТНПО
нить, насколько это возможно, влияние на производительность дру-
гих стоимостных атрибутов. Лучший путь устранения этих влия-
ний состоит в вычислении так называемого коэффициента идеаль-
ных затрат. С использованием для простоты коэффициентов пол-
ных затрат в промежуточной КОМОСТ он определяется следую-
щим образом.
При вычислении затрат ни разработку данного проекта (П) пс-|
пользуется стандартная процедура для промежуточной КОМОСТ с
одним исключением: при анализе стоимостного атрибута не учиты-
вается коэффициент затрат. Назовем эту оценку ЧМ(П, С А). Тогда
316
для каждого проекта и данного стоимостного атрибута коэффици-
ент идеальных затрат КИЗ (П, С А) определяется как коэффици-
ент, который (при использовании промежуточной КОМОСТ)
сделал бы оценку затрат на разработку данного проекта равной
оценке фактических затрат на нее: ЧМ(П, факт), то есть
КИЗ (П, СА) = 451 (П’ фа?т ) . (24.1)
ЧМ(П,СА)
Рис. 24.4. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ТНПО
В качестве примера рассмотрим проект базы данных КОМОСТ
(Проект 1, табл. 29.1), который потребовал фактических затрат
на разработку ЧМ (1, факт.) = 2040 ЧМ. Если при оценке затрат
по промежуточной КОМОСТ в 2218 ЧМ учесть коэффициент затрат
0,88, являющийся результатом низкого рейтинга ТНПО, то резуль-
татом будет оценка
ЧМ (1, ТНПО) =(.2218_1М = 2520 ЧМ.
0,88
317
Тогда коэффициент идеальных затрат для Проекта 1 и атрибу-
та ТНПО
КПЗ (1, ТНГ1ОР ЧМ(1,факт) =2040 ЧМ ^0,81,
' ЧМ (1, ТНПО) 2520 ЧМ
т. е. не слишком отличается от коэффициента затрат промежуточ-
ной КОМОСТ.
Зная коэффициенты идеальных затрат, можно определить вли-
яние стоимостных факторов на проект и сопоставить эти коэффи-
циенты с коэффициентами затрат в КОМОСТ для данного стои-
мостного атрибута. Результаты для стоимостного атрибута ТНПО
привсдятся на рис. 24.4. В отличие от неубедите, .ьных результатов,
приведенных на рис. 24.3, эти результаты показывают прекрасное
согласование коэффициентов затрат в КОМОСТ (показаны круж-
Рис. 24.5. Спектр уровней верификации и подтвержде-
ния
ками) и коэффициентов идеальных затрат в КОМОСТ для атрибу-
та ТНПО данного проекта, о чем говорят средние значения хоэф-
фициенгов (стрелки на рис. 24.4) для каждого рейтинга атрибута
ТНПО Согласование не является совершенным, но дает, тем не
менее, достаточную уверенность в том, что коэффициенты затрат в
КОМОСТ для атрибута ТНПО имеют приблизительно правильные
значения и верно отражают функцию рейтинга стоимостного атри-
бута. (Если бы модель была совершенна, то коэффициент идеаль-
ных затрат для каждого проекта был бы равен соответствующему
коэффициенту затрат в КОМОСТ, и все точки на рис. 24.4 нахо-
дились бы внутри кружков.)
Обсуждение. Очень мало существующих моделей оценивания
стоимости ПО учитывают фактор требуемой надежности. Две из
них, описанные в работах [43] и [118], являются правильными и
имеют основной рейтинг, в определенной степени связанный с
ТНПО. Некоторые эксперименты с моделью из работы [118] дали
разброс производительности (отношение наибольшего коэффици-
318
ента полных затрат к наименьшему для данного стоимостного ат-
рибута проекта) для основного рейтинга примерно от 6 до 9 (см.
рис. 29.10). Это"” разброс существенно выше соответствующего раз-
броса производительности для КОМОСТ от 1 до 1,87 (в соответст-
вии с табл. 23.3 значение 1,87 получено делением коэффициентов
полных затрат для очень высокого и очень низкого рейтингов:
Анализ
Требований
(15%)
Анализ
кода (18%)
Анализ
уравнений (12%)
Тестиро-
вание
(20%)
Расширен ^^сопровождение инструментальных
Руководство и отчетность (24%)
I t t I f t 1 ! t ill
1 23456789 10 11
Время, ЫШ
Рис. 24.6. Пример распределения затрат на НВП
что общий характер изменения
с характером изменения коэффи-
Рис. 24.7. Производственная функ-
ция надежности ПО
1,40/0,75). вероятнее всего, наблюдаемое отличие обусловлено
другими факторами, включенными в основной рейтинг.
На рис. 24.5 [НЗ] показано,
стоимости работ по НВП сравним
циентов затрат в КОМОСТ. Дей-
ствительно, очень высокий рей-
тинг требуемой надежности в
КОМОСТ соответствует обычно-
му уровню ВП *, для которого
коэффициент полных затрат в
КОМОСТ равен 1,40 в отличие
от значения 1,20, даваемого ри-
сунком. Отличие объясняется
в основном тем, что лица, зани-
мающиеся НВП, не обязаны ис-
правлять обнаруженные ошибки,
а также тем, что в таких условиях
разработчики уделяют больше
внимания выявлению ошибок.
На рис. 24.6 [143] приводится распределение затрат на НВП
по фазам для обычного уровня ЕП. Этот рисунок свидетельствует
о приблизительном согласовании с распределением по фазам в
КОМОСТ, за исключением более низкого уровня затрат на фазе
комплексирования и испытаний. И опять, отличие в основном объ-
ясняется дополнительными затратами разработчика на исправле-
ние обнаруженных ошибок, которые имеют наиболее высокий уро-
вень на фазе комплексирования и испытаний (см. рис. 24.2).
1 Экстремальный уровень ВП .вязан с выполнением ПО таких функций, как
управление ядерным реа «тором. Такой уровень требуемой надежности выходит
за рамки возможностей КОМС'СТ.
319
Производственная функция надежности ПО. В идеальном слу-
чае хотелось бы иметь производственную функцию надежности в
виде, приведенном на рис. 24.7 Эго позволило бы связать достиже-
ние желаемой надежности ПО с затратами, требующимися для ее
достижения.
Хотя достигнуть такого идеала чрезвычайно трудно, недавно
были получены некоторые результаты, которые даюг хорошее пред-
ставление о характере такой производственной функции, а также
подтверждают сложность достижения конечного идеала.
Модель привнесения и устранения ошибок ПО. Наилучшей из
известных в настоящее время концептуальной моделью, представ-
ляющей характер производственной функции надежности ПО, яв-
ляется модель привнесения и устранения ошибок ПО (рис. 24.8) |.
Остаточные
ошибки ПО
Ошибки документирования (15 ошибок/КЧИК)-
Общий поток ошибок. __________________ ________________2
60 ошибок/КЧИК Ошибки кодирования
(15 ошибок/КЧИК)
Процент
устраненных
ошибок
Стоимость (С)
Автоматизированный
анализ требований
НВП
требований
С
Модели-
рование
Натурные испытания
Рис. 24.8. Модель привнесения и устранения ошибок ПО
Она показывает, что процесс разработки ПО можно рассматривать
как привнесение определенного количества ошибок на каждом
этапе воплощения программного изделия (спецификация требова-
ний, проектирование, кодирование, документирование) и последо-
вательные действия по устранению ошибок (автоматический ана-
лиз требований, независимые верификация и подтверждение тре-
бований, моделирование и т. п.), каждое из которых имеет харак-
терную производственную функцию, связывающую степень устра-
нения ошибок с затратами, требуемыми для выполнения такой
работы. При этом можно выбрать объем вложений средств в каж-
дый из этапов устранения ошибок и определить результирующий
уровень ошибок в ПО, оставленных на последний э^ап работы по
устранению ошибок.
1 Эта модель аналогична модели «резервуара и трубы» [163], в которой ошиб-
ки проходят в резервуар через различные трубы источников ошибок, а затем
извлекаются оттуда через различные трубы устранения ошибок.
320
Таблица 24.2
Привнесение и устранение ошибок при разработке ПО
Источник
Выполняемая операция [286] [ [45]
[165]
Привнесенные ошибки
Общий поток, число ошибок/КЧИК 30...35 40.. 80 65...85
Разделение по операциям, %: разработка требовании — 10 8... 10
функциональное проекта- 15 , 55 15...20
рование логическое проектирование 20 25...35
кодирование 30 35 25
документирование и т. п. 35 17...20
Устраненные ошибки Функ- Логи- Коди-
цио- ческие рева-
наль- ные ния
Применение автоматизиро- ванных средств анализа требо- ваний 63*
Анализ функциональных спе- цификаций 50 45...60
Моделирование 21
Использование языка проек- тирования 32
Применение стандартов про- ектирования 29
Анализ логических специфи- каций 40 50 50...60
Сквозной контроль логики модулей 60 70 58
Сквозной контроль кода мо- дулей 65 75 70 63
Проверка согласования кода со стандартом 20
Анализ внедрения 14
Автономная отладка 10 10 25 | 73
Функциональное тестирова- ние 20 25 55
Тестирование компонентов 15 20 65 | 46 50
Тестирование подсистем 15 15 55
Тестирование систем 10 10 40 46 50
♦ Из работы [31].
Ц Зак. 628
321
Кривая стоимости исправления ошибок по фазам (см. рис. 4.2)
показывает, что относительная стоимость исправления ошибок воз-
растает на более поздних фазах разработки ПО.
В табл. 24.2 представлены результаты сопоставления трех ис-
следований потоков привнесения и устранения ошибок при разра-
ботке ПО [45, 165, 286]. Данные работы [286] представляют собой
результат ретроспективного анализа нескольких тысяч отчетов
по проблемам ПО больших проектов. Работа [165] позволила полу-
чить данные для большого числа проектов фирмы IBM, я данные
из [45] характеризуют два небольших (2 КЧИК) изделия, разра-
ботанных по одной и той же полной спецификации. В таблице ука-
зан только полный процент устранения потенциальных ошибок при
исчерпывающем применении каждого метода их устранения и не
дано никакой информации об относительной стоимости этих мето-
дов или форме их производственной функции. Возможно, наилуч-|
шими характеристиками обладают производственные функции
сквозного контроля кода и автономной отладки, воспроизведенные
на рис. 24.9.
Рис. 24.9. Производственные функции сквозного контроля кода и автономной от-
ладки
Данные рис. 24.9 достаточно хорошо подтверждаются другими
исследованиями, которые дают отдельные точки функций устране-
ния ошибок, в основном для сквозного контроля кода и автономной
отладки. Результаты этих исследований сведены в табл. 24.3 с
включением данных, приведенных на рис. 24.9 и обозначенных как
данные Проекта А. Производительность программирования Проек-
та А составляла примерно 4 ЧИК/ЧЧ. Поэтому производительно-
сти автономной отладки 5 ЧИК/ЧЧ в табл. 24.3 соответствуют за-
траты на программирование 80% на рис. 24.9 и т. д.
Картина поведения производственной функции надежности ПО.
В конечном итоге следует построить производственные функции
для других работ по устранению ошибок и их предупреждению и
тем самым завершить показанную на рис. 24.8 картину. Это по-
зволит выбирать желаемые объемы вложений в различные меро-
приятия и определять результирующий уровень остаточных ошибок
в ПО в единицах (число ошибок)/КЧИК- Существующие методы
322
Таблица 24.3
Эф« активность устранения ошибок
Вид работы Источник Производи- тельность, чик/чч Устранение ошибок, %
Сквозной контроль [164] 10...48 70
кода [219] 10 38
[45] 20 89
Проект А 120 41
30 64
[74] 25 50...60
Автономная отладка [164] 18...40 20 после сквоз- ного контроля
[219] 24 36
Проект А 20 40
10 68
5 89
[74] 10 50...60
Доказательство пра- вильности программ [208] 50...500* Очень высокое, но не 100%
* В ДОЛЛ./ЧИК.
оценивания надежности (см. [98, 217]) при ряде пре/положений
позволяют по оценке уровня остаточных ошибок в ПО получить
оценку надежности ПО. Кроме того, используя простейшую меру
надежности (число обнаруженных ошибок)/(КЧИК в год), можно
экстраполировать остаточные ошибки на предсказываемое время
жизни программного изделия [255].
Трудности завершения картины поведения производственной
функции наоеулности ПО. Процесс построения производственной
функции усложняется тем, что каждый метод устранения ошибок
эффективен в большей степени только для одних классоь ошибок и
в гораздо меньшей степени — для других. В силу этого, пока неиз-
вестна относительная эффективность устранения ошибок каждого
конкретного класса для отдельных производственных функций, по-
лучить общую производственную функцию их суперпозицией
нельзя.
Пример такого осложнения дан в работе [219] по исследова-
нию сквозного контроля кода и хорошо виден из табл. 24.3. Затра-
ты 1 ЧЧ на сквозной контроль 10 ЧИК, обеспечивающие 38% уст-
ранения ошибок, гораздо менее эффективны, чем затраты на сквоз-
ной контроль по другим данным, приведенным в той же таблице.
Наиболее вероятное объяснение отличий заключается в том, что
первая программа, взятая для примера, содержала ряд значитель-
но более тонких ошибок, чем выявляется в большей части приклад-
ного ПО [132, 221].
Еще одним примером служит попытка объединить производст-
венные функции для сквозного контроля и автономной отладки
(рис. 24.9). Эта попытка наткнется на совпадение некоторых клас-
сов ошибок:
11-
323
Сквозной контроль Автономная отладка
Обнаруживает
Очевидные программные промахи, Очевидные программные промахИ
логические ошибки логические ошибки
Белые пятна разработки Численные приближения
Ошибки интерфейса Динамические ошибки в программе
Пропущенные участки
Ошибки в спецификациях
Обнаруживает
Численные приближения Белые пятна разработки
Динамические ошибки в программе Ошибки интерфейса
Ошибки в спецификациях
Пропущенные участки
Эти два метода прекрасно дополняют друг друга для различ-
ных классов ошибок, но точно совпадают по наиболее общему
классу логических ошибок и очевидных программных промахов.
Итак, разработка общей производственной функции будет нелегка,
так как увеличение вложений средств в применение обоих методов
приведет к увеличению числа ошибок, выявляемых обоими мето-
дами.
Другим усложняющим обстоятельством является относительная
серьезность ошибок, которая должна учитываться при любой стра-
тегии распределения вложения средств в работу по устранению
ошибок. В [259], например, показано, что ошибки в документации]
в среднем приводят к гораздо менее серьезным последствиям, чем
другие ошибки.
Хотя сопоставление стоимости ПО и надежности является слож-
ным вопросом, имеется ряд полезных исследований и источников
данных, помогающих понять суть дела. Так, в работе [286] прово-1
дится анализ, показывающий относительную эффективность при-
менения методов устранения ошибок для разнообразных их клас-
сов, а в работе [44] дается относительная оценка требований к ПО
и методов верификации и подтверждения проекта, а также стои-
мостной эффективности этих методов при устранении различных
классов ошибок. Значительная информация по относительной ча-
стоте ошибок в программах различных классов, относительной
серьезности вызванных ими последствий, а также относительной
эффективности устранения ошибок рядом методов содержится в
работах [23, 62, 104, 153, 224, 259, 301].
Для получения ясного представления о связи стоимости ПО и
его надежности остается проделать еще много важной работы.
Некоторые из наиболее существенных ее направлений рассматри-
ваются в конце этой главы, как темы для дальнейших исследо-
ваний.
24.2. РАЗМЕР БАЗЫ ДАННЫХ (РБД)
На количество затрат, требуемых для разработки программно-
го изделия, безусловно, влияют размер и сложность базы данных.
Однако специальные атрибуты базы данных, влияющие на стои-
324
мость программного изделия, охарактеризовать чрезвычайно труд-
но. В настоящее время большинство работ по мерам сложности ПО
относится к сложности программ, а не данных. Многие модели
оценивания стоимости ПО полностью исключают влияние базы
данных программного изделия, учитывая в качестве параметра его
размера только число выполняемых команд.
Разработчики ПО не слишком развивают общую методику по
определению влияния размера базы данных. Так, например, в од-
ном исследовании стоимости ПО был использован параметр «коли-
чество классов элементов в базе данных». Его значения, получен-
ные по нескольким проектам с примерно аналогичными базами
данных, изменялись в диапазоне 3 ... 1 000 000. В результате уточ-
нений некоторые отличия в интерпретации этого параметра были
устранены, но осталось еще столько нерешенных и неясных вопро-
сов, что данный параметр был отвергнут как кандидат на роль
стоимостного атрибута.
Подход КОМОСТ состоит в том, что учитывается влияние толь-
ко размера базы данных;
общий объем данных, собираемых в базе данных, характеризу-
ется стоимостным атрибутом РБД;
структура базы данных влияет на увеличение числа исходных
команд, разработанных для программного изделия ’;
сложность обработки данных характеризуется стоимостным ат-
рибутом СИЗ (см. разд. 24.3) по шкале возрастающей сложности
операций.
Такой подход лучше предыдущих попыток учета влияния базы
данных в КОМОСТ. Однако чтобы установить это точно, необхо-
димо провести еще много дополнительных исследований, собрать
множество данных и сделать соответствующий анализ.
Рейтинги и коэффициенты затрат. В табл. 23.3 приводятся ко-
эффициенты затрат в детальной КОМОСТ на разработку ПО в за-
висимости от относительного размера разрабатываемой базы дан-
ных. Соответствующие рейтинги определяются следующим отно-
шением:
д/ц Размер базы данных, байт или символ
Размер программы, ЧИК
где под размером базы данных понимается объем собираемых и
запоминаемых не в оперативной памяти (т. е. на лентах, дисках,
барабанах, в пузырьковой памяти и т. п.) данных за время процес-
са приемки ПО пользователем. Распределение по фазам коэффи-
циента затрат труда для различных рейтингов атрибута РБД при-
водится на рис. 24.10.
В табл. 24.’4 приводятся изменения в работе над проектом, обус-
ловленные изменением размера базы данных. Отличия в планиро-
1 И даже здесь необходим дополнительный совет: для программ на языке
Кобол количество невыполняемых исходных строк кода для параметра ЧИК
в КОМОСТ следует учитывать введением коэффициента 1/3.
325
Таблица 24.4
Изменения в работе над проектом на разных фазах,
обусловленные размером базы данных
Анализ требований и проектирование изделия Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Низкий рейтинг (Д/ПС10)
Простые проектирование и
проверка базы данных
Простой интерфейс ТО и
ПО
Более простые планы тести-
рования
Минимум УК базы данных
и документации
Простые проектирование и про-
верка базы данных
Меньше работы по контролю
данных в программе
Более простые планы тестиро-
вания
Минимум УК базы данных и
документации
Простая разработка базы дан-
ных
Меньше работы по контролю
данных в программе
Меньше работы по сбору дан-
ных
Минимум УК базы данных и
документации
Меньше работы по тестирова-
нию и приемке базы данных
Простое комплексирование ко-
да и базы данных
Меньше работы по сбору дан-
ных
Минимум УК базы данных и
документации
Номинальный рейтинг (10 Д/П < 100)
Без изменений
Высокий рейтинг (100 Д/11 <. 1000)
Сложные проектирование и
проверка базы данных
Простой интерфейс ТО и
ПО
Больше работы по плани-
рованию тестирования
Больше работы по УК и
документированию базы
данных
Сложные проектирование и
проверка базы данных
Больше работы по контролю
данных в программе
Больше работы по планирова-
нию тестирования
Больше работы по УК и доку-
ментированию базы данных
Более сложная разработка ба-
зы данных
Больше работы по контролю
данных в программе
Больше работы по сбору дан-
ных
Больше работы по УК и доку-
ментированию базы данных
Больше работы по тестирова-
нию и приемке базы данных
Сложное комплексирование ко-
да и базы данных
Больше работы по сбору дан-
ных
Больше работы по УК и доку-
ментированию базы данных
Появление функций администратора базы данных ------------------------------•--------------------------------------►
Очень высокий рейтинг (Д/П ^1000)
'Большая степень перечисленных выше изменений — ----------------------------------------------------------—-------
вании базы данных, в комплексировании кода и базы данных, а
также в верификации являются главными причинами того, что пер-
вая и последняя фазы имеют большее изменение коэффициента
затрат, чем две средние фазы.
Сравнение с фактическими данными. Основываясь на проведен-
ном в разд. 24.1 анализе сопоставления коэффициентов затрат для
атрибута ТНПО в КОМОСТ и результатов проектов базы данных
КОМОСТ, будем использовать коэффициент идеальных затрат
(24.1) в качестве основы для аналогичного сопоставления по атри-
буту РБД. Напомним, что коэффициент идеальных затрат КИЗ(П,
РБД) для каждого проекта (П)—это коэффициент затрат для
атрибута РБД, который сделал бы для этого проекта оценку за-
трат по промежуточной КОМОСТ в человеко-месяцах в точности
равной действительному количеству человеко-месяцев, потребовав-
изделия
Фаза
Рис. 24.10. Распределение коэффициентов затрат по фазам для атрибута РБД
шемуся на осуществление проекта, в предположении, что все
остальные коэффициенты затрат в промежуточной КОМОСТ сохра-
няют значения, определенные рейтингами их атрибутов.
На рис. 24.11 приводятся значения КИЗ(П, РБД) для проек-
тов базы данных КОМОСТ и значения коэффициентов полных за-
трат в промежуточной КОМОСТ для четырех рейтингов атрибута
РБД. Как и для атрибута ТНПО, наблюдается хорошее согласова-
ние коэффициентов затрат в КОМОСТ (показаны кружками) и
данных по проектам, особенно по отношению к средним значениям
КИЗ(П, РБД) (показаны стрелками) для каждого рейтинга РБД.
Обсуждение. Таблица 23.3 предназначена просто для учета пол-
ного размера разрабатываемой базы данных, которая перед прием-
кой заполняется и проверяется. Учет сложности структур данных
реализуется в КОМОСТ включением операторов данных в число
исходных команд, а также использованием шкалы возрастающей
сложности операций (см. разд. 24.3).
О влиянии этого фактора известно относительно мало. В рабо-
те [147] указывается, что его влияние второстепенно, но количест-
Низкий Номи- Высокий Очень высокий
нальный
Рис. 24.11. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута РБД
венных данных не приводится, а в работе [6] этот фактор рассма-
тривается как важный, но оценки его влияния также нет. В рабо-
те [291] приведено максимально достижимое значение коэффици-
ента увеличения производительности1 для фактора «количество
классов элементов в базе данных на 1000 строк кода», равное 1,73.
В КОМОСТ МКУП= 1,16/0,94= 1,23.
М.З. СЛОЖНОСТЬ ПРОГРАММНОГО ИЗДЕЛИЯ (СИЗ|
Рейтинги и коэффициенты затрат. В табл. 23.2 приводятся коэф-
фициенты затрат в детальной КОМОСТ на разработку ПО для раз-
личной сложности разрабатываемого модуля, а в табл. 8.4 показа-
1 В книге рассматриваются только те атрибуты изделия, ЭВМ, исполните-
лей и проекта, которые могут увеличить производительность разработки или
сопровождения ПО. Поэтому влияние соответствующего фактора на производи-
тельность характеризуется коэффициентом увеличения производительности
(КУП) по сравнению с существующей производительностью. Этот коэффициент
изменяется в зависимости от рейтинга атрибута и находится на отрезке 1
МК^П. Далее в качестве максимально достижимого значения КУП указыва-
ется значение МКУП. — Прим ред.
328
но изменение рейтингов в зависимости от типа операций, главным
образом выполняемых модулем: управляющих, вычислительных,
связанных с управлением устройствами или данными. Для каждо-
го типа модуля в табл. 8.4 приводится шкала возрастающей слож-
ности операций, которая соответствует очень низкому, низкому, но-
минальному, высокому, очень высокому и сверхвысокому рейтин-
гам сложности модуля.
Так, например, вычислительный модуль, состоящий исключи-
тельно из простых выражений, таких как A=B-j-C* (D—Е),
имел бы очень низкий рейтинг. Если бы модуль содержал более
сложные выражения типа SQRT (В** 2 — 4.0*71*0, то ему был
бы приписан низкий рейтинг.
Обычной таблицы, указывающей на изменения работ над про-
ектом (обусловленные разными рейтингами для данного атрибу-
изделмя
Фаза
Рис. 24.12. Распределение коэффициентов затрат труда по фазам для атрибута
СИЗ
та), не приводится. Увеличение сложности изделия ведет к равно-
мерному увеличению всей работы над проектом. Это влияние пока-
зано на рис. 24.12, представляющем равномерное распределение по
фазам коэффициентов затрат для атрибута СИЗ.
Сравнение с фактическими данными. Как и раньше, в ^качестве
основы для сравнения с результатами проектов будем использовать
Для каждого проекта (П) коэффициент идеальных затрат КИЗ(П,
СИЗ).
На рис. 24.13 приводятся значения КИЗ(П, СИЗ) для проектов
базы данных КОМОСТ и значения коэффициентов затрат в
КОМОСТ (показаны кружками) для шести рейтингов атрибута
СИЗ. Согласование коэффициентов затрат в КОМОСТ и средних
значений КИЗ(П, СИЗ) (показаны стрелками) опять достаточно
хорошее, исключая сверхвысокий рейтинг, для которого нашлась
только одна точка из данных. Без дополнительных точек для
сверхвысокой сложности предлагать какой бы то ни было пере-
329
смотр коэффициента затрат для сверхвысокой сложности было бы
преждевременно.
Обсуждение. Некоторые из более ранних моделей стоимости
ПО имели только один коэффициент затрат, который был связан с
общей сложностью или трудностью выполняемой работы. Возмож-
но, лучшей из этих моделей была модель, описанная в работе [223]
и основанная на исследовании 169 проектов ПО (рис. 24.14). Что- |
Рис. 24.13. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута СИЗ
бы использовать этот рисунок для оценивания, следовало бы снача-
ла оценить свой проект как, скажем, более сложный, чем 80%
проектов, для которых построен рисунок. В этом случае из рисунка
было бы видно, что новый проект занял бы 7 ЧМ для разработки
1000 объектных команд.
Основная практическая трудность такой модели состоит i том
что оценивание рейтингов основывается на совершенно субъектив
ном мнении. Так, если бы один эксперт оценил проект, как имею
щий сложность 80%, а другой — 60%, то для третьей стороны не
330
Рис. 24.14. Интегральное распределение
нормы программирования для 169 про-
грамм
нашлось бы способа определить, кто более точен, хотя соответству-
ющие оценки затрат отличались бы почти в 2 раза.
В своей попытке ограничить субъективный подход при оцени-
вании затрат КОМОСТ для фактора сложности следует модели из
работы [43], используя:
рейтинг сложности на уровне модуля, а не подсистемы или си-
стемы;
разбиение возможно большего числа источников разброса про-
изводительности по отдельным стоимостным факторам, не завися-
щим от стоимостного атрибута сложности (например, ограничения
по быстродействию и по оперативной памяти, требуемая надеж-
ность и т. п.);
шкалу рейтинга, приведен-
ную в табл. 8.4, для получения
возможно более объективного
рейтинга сложности.
Результирующий МКУП в
КОМОСТ, обусловленный раз-
личной сложностью, составля-
ет 2,36. Этот коэффициент
существенно меньше, чем
МКУП=4 ... 6,67 для модели
из [11] и 6 ... 7 для моде-
ли из [Н8]. Более поздняя
версия первой из этих моделей
[12] имеет МКУП=2 ...4 для
языка ассемблера и 4 ... 6 для
языков более высокого уровня
в зависимости от типа про-
граммы. Модель из работы
[313] показала относительно
малый диапазон изменения
МКУП, обусловленный изме-
нением сложности: 1,42 ... 1,53.
следствием большой равномерности распределения выборки про-
ектов по типам. Модель из работы [307] характеризуется МКУП
для атрибута СИЗ, равным 12, но так как сложность определяется
на уровне модулей, то для всего изделия МКУП изменяется зна-
чительно меньше. Исследование факторов, влияющих на произво-
дительность [267], неожиданно показало небольшую положитель-
ную корреляцию между сложностью применения ПО и производи-
тельностью его разработки (-]-1 по шкале от —7 до -|-7). Модель
из работы [80] имеет МКУП=1,5 для СИЗ на уровне модуля и
1,2 для СИЗ более высокого уровня, а МКУП для атрибута СИЗ
в модели из работы [139] составил 1,5.
Меры сложности. Для оценивания сложности ПО были введены
меры сложности [97, 141, 196, 302]. Это позволило добиться опре-
деленных результатов, но не было достаточным для установления
корреляции сложности с производительностью, чтобы использовать
Весьма вероятно, что это является
331
эти меры в качестве атрибута модели стоимости. (Этот момент
будет обсуждаться далее в гл. 28.)
Некоторая предварительная исследовательская работа показы-
вает, что корреляция этих мер сложности и шкалы сложности,
приведенной в табл. 8.4, положительна, но не очень велика. Ука-
занные меры не очень чувствительны к относительному объему за-
трат на анализ, потребовавшихся для программирования модулей
с более высокими или болёе низкими рейтингами по шкале
КОМОСТ.
24.4. ТЕМЫ ДЛЯ ДАЛЬНЕЙШИХ ИССЛЕДОВАНИЙ
А. Проект А, являющийся основой для построения производственных функций
устранения ошибок при сквозном контроле кода и автономной отладке (рис. 24.9),
был большим программным проектом для встроенной ЭВМ, предназначенным для
аэрокосмических исследований. Проверьте гипотезу, что соответствующие произ-
водственные функции не зависят от типа проекта, путем сбора аналогичных дав
ных по другим проектам и сравнения результатов Основываясь на полученных
результатах, постройте производственную фикцию. Некоторые относящиеся к это-
му вопросу данные приведены в работе [62].
Б. Выполните работу по определению производственных функций для таких
методов, как
сквозной контроль требований;
сквозной контроль проекта;
доказательство программы;
моделирование, использование контрольных листов, прототипирование и дру-
гие методы ВП проекта и требований, анализ которых дан в работе [44];
тестирование ветвей программы, символическое тестирование и другие мето-
ды, анализ которых дан в работе [153];
автоматизация проверок, таких как проверка согласования кода со стандар-
том и анализ внедрения изделия, обзор которых проведен в работах [252, 253];
дублирование кода, сквозной контроль базы данных и другие методы, рас-
смотренные в работе [128].
В. Установите взаимосвязь между количеством календарного времени или
времени выполнения программы, используемым для тестирования программного
изделия, и затратами на тестирование. Используйте эту взаимосвязь для по-
строения производственных функций устранения ошибок, основываясь на данных,
приведенных в работах [216, 224, 286].
Г. Одним из необходимых шагов для принятия решений при изучении соотно
шения стоимость — надежность ПО является введение соответствующей меры,
отражающей относительную серьезность последствий ошибок ПО. Наиболее эф-
фективным современным подходом к этому вопросу явилось использование меры
нормализованного времени исправления ошибки Т при выплате премий группе
сопровождения ПО в соответствии с условиями контракта. Каждый появившийся
сбой ПО характеризовался продолжительностью П, и серьезностью последствий
С,, измеряемой по следующей шкале:
С,-=10 000 для сбоев, влияющих на весь космический флот;
I 000 для сбоев, влияющих на один космический аппарат;
100 для сбоев, влияющих на анализ экспериментальных данных
10 для второстепенных сбоев (таких как неправильная распе-
чатка);
1 для тривиальных сбоев (опечатка в тексте).
Нормализованное время исправления ошибки для заданного периода вычисля
лось как
Т =
332
Эта мера оказалась весьма действенной как стимул обеспечения надежного сопро-
вождения ПО. (И эффективно использовалась для поощрения группы сопровож-
дения ПО.)
Разработайте и исследуйте более общие меры для учета относительной серьез-
ности последствий ошибок при анализе надежности ПО и в производственных
функциях.
Д. Предложите улучшенные меры для оценивания влияния размера базы дан-
ных и сложности изделия. Исследуйте их применимость в широком диапазоне
прикладных областей ПО, включая распределенные базы данных. Исследуйте
корреляцию этих мер с затратами на разработку ПО и базы данных.
Е. Соберите и проанализируйте данные по работе, связанной с адаптацией
существующих баз данных к новым применениям. Обобщите корректирующий
коэффициент адаптации (ККА) в КОМОСТ для учета влияния адаптации базы
данных и вычислите его для собранных данных.
Ж. Выполните исследования, подобные приведенным в работах [77, 78, 282]
по проверке гипотезы о наличии корреляции между производительностью разра-
ботки ПО и мерами сложности, описанными в работах [97, 141, 196, 302], когда:
меры сложности сильно скоррелированы с производительностью разработки
(больших, малых, системных, прикладных) проектов ПО;
меры сложности сильно скоррелированы со шкалами рейтинга СИЗ
в КОМОСТ;
меры сложности представляют лучшую оценку производительности по сравне-
нию со шкалами рейтинга СИЗ в КОМОСТ.
Хороший обзор вопросов, касающихся сложности ПО, дан в работе [76].
ГЛАВА 25
АТРИБУТЫ ЭВМ КАК СТОИМОСТНЫЕ ФАКТОРЫ ДЕТАЛЬНОЙ
КОМОСТ
2S.1. ОГРАНИЧЕНИЕ ПО БЫСТРОДЕЙСТВИЮ (ОБД)
Рейтинги и коэффициенты затрат. В табл. 23.3 приводятся коэф-
фициенты затрат на разработку ПО в детальной КОМОСТ в зави-
симости от ограничения по быстродействию, установленного для
подсистемы ПО. Рейтинг представляет собой долю ожидаемого вре-
мени выполнения этой подсистемы по отношению к доступным
ресурсам времени выполнения, выраженную в процентах. Здесь не
приводятся данные, соответствующие ситуациям, в которых долж-
но быть использовано свыше 95% ресурсов времени выполнения.
Зависимость коэффициента затрат от фазы для различных рейтин-
гов атрибута ОБД представлена на рис. 25 1. В табл 25.1 показа-
ны изменения в работе над проектом, обусловленные различным
ограничением по быстродействию. Наиболее высокий рост стоимо-
сти разработки ПО на фазе комплексирования и испытаний в ос-
новном связан с более высокой стоимостью обнаружения ошибок,
вызванных ограничениями по быстродействию, и их исправления.
Сравнение с фактическими данными. Как и при сравнении ре-
зультатов для проектов базы данных КОМОСТ с коэффициентами
затрат в КОМОСТ при заданной надежности, проведенном в
Разд. 24.1, сравнение обсуждаемых в этой главе атрибутов ЭВМ
проводится с использованием коэффициентов идеальных затрат,
333
Анализ Детальное Кодирование Комплексирование
требований и проекти- и автономная и испытания
проектирование рование отладка
изделия
Рис. 25.1. Распределение коэффициентов затрат труда по фазам для атрибут:
ОБД
определенных по уравнению (24.1). Для атрибута ОБД по каждо-
му проекту (П) коэффициент идеальных затрат КИЗ(П, ОБД) —
это коэффициент затрат времени, который точно уравнял бы затра-
ты на проект в человеко-месяцах, оцененные по промежуточной
КОМОСТ, с реальными затратами человеко-месяцев, потребовав-
шихся на проект, в предположении, что все остальные коэффици-
енты затрат в промежуточной КОМОСТ сохраняют значения, оп-
ределенные рейтингами соответствующих атрибутов.
На рис. 25.2 приводятся значения КИЗ(П, ОБД) для проектов
базы данных КОМОСТ и значения коэффициентов затрат для раз-
личных рейтингов атрибута ОБД по каждому проекту. И снова
налицо довольно хорошее согласование коэффициентов в КОМОСТ
(показаны кружками) и средних значений КИЗ(П, ОБД) (показа-
ны стрелками) для каждого рейтинга. Для высокого рейтинга ко-
эффициент идеальных затрат расположен значительно ниже соот-
ветствующего реального коэффициента в КОМОСТ, но если в
группу проектов с высоким рейтингом включаются проекты со
смешанными рейтингами, расположенными около высокого, то ко-
эффициент идеальных затрат очень близок к соответствующим
коэффициентам в КОМОСТ.
Обсуждение. В этом разделе обсуждаются как фактор ограни-
чения по быстродействию, так и фактор ограничения по оператив-
ной памяти (ОП), которые тесно связаны. Исходными данными о
влиянии этих стоимостных атрибутов стали результаты анализа 34
проектов ПО управления авиационным оборудованием (рис. 25.3)
[308]. По результатам анализа была построена кривая, связываю-
щая относительную стоимость одной команды с быстродействием
ТО и органичениями по памяти (рис. 25.4) [309]. В 1971 г. исследо-
331
Таблица 25.1
Изменения в работе над проектом на разных фазах,
обусловленные ограничением по быстродействию
Анализ требований
и проектирование изделия
Детальное проектирование
Кодирование
и автономная отладка
Комплексирование
и испытания
Номинальный рейтинг (<С5О%)
Без изменений----------------------------------------------------------------------------------------------------
Высокий рейтинг (70%)
Добавляются анализ, мо-
делирование, построение
прототипов, подтверждение
Сложные требования к уп-
равлению ресурсами при
проектировании
Более сложные планы и
процедуры тестирования
Добавляются анализ, модели-
рование, построение прототи-
пов, подтверждение
Сложные требования к управ-
лению ресурсами при проекти-
ровании
Более сложные планы и про-
цедуры тестирования
Добавляется анализ
Более сложные организация
данных и кодирование при про-
граммировании и отладке
Сложные подпрограммы
управления ресурсами
Тщательное управление бюд-
жетом времени выполнения
Более сложные процедуры те-
стирования
Более трудные отладка, ис-
правление, правильное исправ-
ление
Добавляются функции измере-
ния времени выполнения
Тщательное управление бюд-
жетом времени выполнения
Очень высокий рейтинг (85%)
Большая степень перечисленных выше изменений ----------------------------
Сверхвысокий рейтинг (95%)
Гораздо большая степень перечисленных выше изменений
Рис. 25.2. Коэффициенты идеальных затрат и коэффициенты затрат в КОМССТ
для различных рейтингов атрибута ОБД
вангя ВВС США [37] позволили получить дополнительные данные
(окружности на рис. 25.4) по проектам ПО для ТО с весьма низки-
ми возмсжностями. Как показано на рисунке, эти данные согласу-
ются с приведенной кривой.
220
5 200
Ей 180
160
140
120
„ТО
е: «о
О о
80
? 60
О
40
Ограничение Ограничение
по быстро- по быстро-
действию или действию и
оперативной оперативной
памяти памяти
Без
ограничений
Рис. 25.3. Данные о влиянии ограничения на ТО
Рис. 25.4. Влияние ограничений по быстродействию и оперативной памяти на
стоимость ПО:
О—данные из работы £3091; О — влияние ОБД (КОМОСТ); Л — влияние ОП (КОМОСТ
336
Впоследствии в других исследованиях и работах по моделиро-
ванию стоимости (например, [118, 263]) были получены аналогич-
ные результаты. В первой работе использовалась модель оценива-
ния стоимости ПО, основанная на кривой (очень похожей на при-
веденную на рис. 25.4) оценивания влияния ограничений на ТО
(см. рис. 29.9).
Анализ, проведенный в работе [238], показывает, что модель,
связывающая возможности и стоимость ТО (или производственная
функция), описывается выражением
Стоимость = а-(возможности) Ь, где 6=0,67 ... 0,90
(для линейной модели 6=1,0, а по закону Гроша 6=0,5).
Раздельное влияние факторов ограничения по быстродействию
и оперативной памяти на производительность разработки ПО от-
ражено в табл. 25.2.
1 а б л и ц а 25.2
Изменения МКУП разработки ПО при ограничениях на ТО
Источник Влияние ОБД Влияние ОП
[313 [33 [147 [59 [80 [291 [118 КОМОСТ 3,00 3,33-6,67 1,33-1,77 1,60 1,25 1,37-1,77 См. рис. 29.9 1,66 1,43 7,00 1.25 2,03 1,56
Изменение производительности, рассмотренное в работе [59],
чрезвычайно трудно объяснить. Таблицы, приводимые в этой рабо-
те, начинаются с коэффициента затрат 0,0 для разработки ПО без
ограничений; подразумевается, что такое ПО может быть реализо-
вано с нулевой стоимостью. При построении табл. 25.2 предпола-
галось, что эти таблицы начинались с коэффициента 1,0.
Диапазоны изменения производительности разработки проектов
ПО [291]. Результаты, приведенные в этой работе, тоже трудно
объяснить. Весьма важно, тем не менее, в них разобраться, так
как они основаны на очень тщательной и обоснованной выборке
данных и хорошо проанализированы *. В исследуемой базе данных
ограничения по быстродействию и памяти для 60 проектов подраз-
делены на минимальные, средние и жесткие. Усредненная произ-
водительность разработки в ЧИС/ЧМ для каждой группы проек-
тов с заданным рейтингом приводится на следующей странице1 2.
1 Относительно деталей проектов доступна только фрагментарная информа-
ция. Ясно, что конкурирующие фирмы, разрабатывающие ПО, заинтересованы
в нераспространении большей части экономической информации.
2 В число исходных строк включена неизвестная доля строк с коммента-
риями.
337
Ограничения:
По оперативной памяти
По быстродействию
минимальные средние
391 277
303 317
жесткие
193
171
Таким образом, полный диапазон изменения производительно-
сти для этих атрибутов может быть недооценен из-за того, что про-
екты с наиболее жесткими ограничениями на ТО усредняются в
общей категории «жестких». И наоборот, диапазоны изменения
производительности могут быть переоценены из-за того, что вли-
яния ограничений по быстродействию и памяти тесно переплетены
с влиянием всех других стоимостных факторов. В силу этого труд-
но отделить влияние на производительность, оказываемое ограни-
чениями по быстродействию и памяти, от влияния других стоимост-
ных факторов, тем более, что они зависят от характеристик аппа-
ратуры.
В табл. 25.3 отражен другой подход [55], согласно которому
Таблица 25.3
Усредненные данные для проектов из работы [291] в зависимости
от размера проекта и ограничения по быстродействию
Размер проекта, требования к ограничениям Число про- ектов Затраты, ЧМ 1 Продолжи- тельность разработки проекта, мес. Максималь- ный штат исполните- лей, ЧИ Число ис- ходных строк кода, тыс. Ограничение по быстро- действию Производи- тельность, ЧИС/ЧМ
Малый, менее жесткие Средний, менее жесткие Средний, более жесткие Большой, наиболее же- сткие Всего или среднее 8 24 19 8 60 26 84 312 2486 468 8 12 16 43 17 5 8 23 71 21 15 30 80 165 62 1,1 1,7 2.6 2,9 2,0 576 357 256 66 132
Таблица 25.4
Усредненные данные для проектов из работы [291]
в зависимости от области применения
Область применения Число проектов Число исход- ных строк кода, тыс.‘ Затраты, ЧМ • ® •S Л а Штат испол- нителей, ЧИ Производи- тельность, ЧИС/ЧМ
Продоля о о га ь К <я « J3 CL Ч га о и 0J сЧ о. Ф t- О. С s
Пакетная обработка 13 27 69 10 8 391
Модели и интерпретаторы 9 77 214 19 14 359
Интерактивный поиск информации 13 78 232 13 19 336
Управление процессами 6 9 49 7 9 190
ОС специального назначения Интерактивное или оперативное управление в реальном масштабе 13 58 568 25 28 101
времени 6 143 2420 31 65 59
338
Таблица 25.5
Диапазоны изменения производительности разработки проектов
базы данных из работы [2911 при воздействии различных факторов
Фактор Характеристика фактора. Усредненная производительность по выборке, ЧИС/ЧМ Диапазон изменения производи- тельности, ЧИС/ЧМ
максималь- ная средняя минимальная
Сложность взаимодействия < нормаль- Нормальная > нормаль-
с заказчиком НОЙ НОЙ
500 295 124 376
Участие пользователей в Отсутствует Небольшое Большое
определении требований 491 267 205 286
Изменения проекта про- Небольшие Большие
граммы по просьбе заказчи- 297 196 101
ка
Опыт работы заказчика в Отсутствует Небольшой Большой
области проекта 318 340 206 112
Опыт и квалификация раз- Низкие . Средние Высокие
работчиков 132 257 410 278
Доля программистов-раз- <25% 25 .50% >50%
работчиков, принимавших 153 242 391 238
участие в проектировании
функциональных специфи-
каций
Предыдущий опыт работы Минималь- Средний Высокий
с объектной ЭВМ ный
146 270 312 166
Предыдущий опыт исполь- Минималь- Средний Высокий
зования языков программи- ный
рования 122 225 385 263
Предыдущий опыт работы Минималь- Средний Высокий
в даннъй прикладной обла- ный
сти для проектов с анало- 146 221 410 264
гичными или большими раз-
мерами или сложностью
Отношение среднего разме- <0,5 0,5 0,9 >0,9
ра штата разработчиков к 305 310 173 132
продолжительности разра-
ботки проекта, чел./мес.
Параллельная разработка Не имеется Имеется
ТО 297 177 120
Доступ к инструментальной 0% 1-25% >25%
ЭВМ открыт по специаль- 226 274 357 131
ному запросу
Доступ к инструментальной 0...10% 11-85% >85%
ЭВМ закрыт 303 251 170 133
Необходимость обеспече- Не имеется Имеется
ния скрытности характери- 289 156 133
стик ЭВМ и 25% программ
и данных
Применение структурного 0-33% З4...66% >66%
программирования 169 — 310 141
Применение сквозного 0....33% 34-66% >66%
контроля кода и проекта 220 300 339 119
Применение разработки ме- О....ЗЗ% 34 66% >66%
тодом сверху — вниз 196 237 321 125
339
Окончание табл. 25.5
ч Фактор Характеристика фактора. Усредненная производительность по выборке, ЧИС/ЧМ Диапазон изменения производи- тельности, ЧИС/ЧМ
максималь- ная средняя измерения
Использование бригад о....зз% 34—66% 66% 189
главного программиста Общая сложность разраба- 219 <средней — 408 >средней
тываемого кода 314 Средняя 185 129
Сложность прикладной об- <средней >средней 181
работки 349 345 168
Сложность схемы програм- < средней Средняя >средней 80
МЫ 289 299 209
Общие ограничения на про- ектирование программы Минималь- ные Средние Жесткие 127
293 286 166
Ограничения проекта про- граммы по оперативной па- Минималь- ные Средние Жесткие 198
мяти 391 277 193
Ограничения проекта про- граммы по быстродействию Минималь- ные Средние Жесткие 132
302 317 171
Доля кода, выполняемого <10% 10...4С % >40%
в реальном масштабе вре- мени или в режиме интер- активной обработки, или же при жестких ограничениях на время выполнения 279 337 203 76
Доля кода, не связанногос о...зз% 34-66% 67... 100% 79
вычислениями и программа- ми форматного ввода-выво- 188 311 267
да Доля кода, требующего раз- 0-90% 91-99% 100% 106
работки 159 327 265
Количество классов элемен- 0...15 16. 80 >80 141
тов в базе данных на 1000 строк кода 334 243 193
Количество страниц доку- 0...32 33...88 >88 125
ментации на 1000 строк разрабатываемого кода 320 252 ‘95
уменьшение производительности связано с жесткими ограничени-
ями по быстродействию (в данном случае классифицируемыми по
шкале от 1 до 3) и с большими размерами проекта и изделия. Тем
не менее трудно судить, насколько низкая (66 ЧИС/ЧМ) произво-
дительность для «больших проектов с жесткими требованиями»
обусловлена влиянием ограничений по быстродействию и насколь-
ко — влиянием размера проекта.
Анализ этих данных, проведенный в работе [55] и иллюстриру-
емый табл. 25.4, свидетельствует о достаточно сложной ситуации.
Для некоторых областей применения (ОС специального назначения
и интерактивное или оперативное управление в реальном масшта-
бе времени) низкая производительность разработки и большой
340
размер ПО сильно скоррелированы. В то же время системы управ-
ления процессами характеризуются относительно низкой произво-
дительностью разработки и малыми размерами ПО, ч го говорит о
серьезном влиянии на производительность других стоимостных фак-
торов (таких, как ограничения на ТО) независимо от размеров
проекта.
С аналогичными трудностями выделения влияния взаимосвя-
занных факторов придется столкнуться при анализе других стои-
мостных факторов КОМОСТ (например, использования практики
Рис. 25.5. Распределение коэффициентов затрат труда по фазам для
ОП
атрибута
современного программирования) Полный набор диапазонов изме-
нения производительности для данных из работы [291] приводится
в табл. 25.5.
25.2. ОГРАНИЧЕНИЕ ПО ОПЕРАТИВНОЙ ПАМЯТИ |ОП]
Рейтинги и коэффициенты затрат. В табл. 23.3 приводятся
коэффициенты затрат на разработку ПО в зависимости от жестко-
сти ограничения по оперативной памяти, установленного для под-
системы ПО. Под оперативной памятью понимается запоминающее
устройство с прямым произвольным доступом (память на магнит-
ных сердечниках, интегральных схемах или магнитной проволоке).
Сюда не входят такие запоминающие устройства, как барабаны,
Диски, ленты и пузырьковая память.
Рейтинг характеризуется той долей оперативной памяти, кото-
рая, как ожидается, будет использоваться подсистемой ПО. В при-
341
Таблица 25.6 Изменения в работе над проектом на разных фазах, обусловленные ограничениями ло оперативной памяти
Анализ требований и проектирование изделия Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Низкий рейтинг (^50%)
Высот Добавляются ана- лиз, моделирова- ние, построение прототипов, под- ш рейтинг (70%) Добавляется ана.1 Более сложные к данных при прог Тщательный конт тппнпй памяти низ y-J
одирование и организация эаммировании и отладке золь использования опера-
Более сложные тестовые драйверы, измерения, ди- агностика
Очень высокий рейтинг (85%)
Большая степень перечисленных выше изменений----------------------------1
Сверхвысокий рейтинг (95%)
Гораздо большая степень перечисленных выше изменений--------------------J
водимых таблицах не учитываются ситуации, в которых должно
быть использовано свыше 95% доступного объема оперативной па-
мяти. Распределение коэффициента затрат по фазам для различ-
ных рейтингов атрибута ОП изображено на рис. 25.5.
В табл. 25.6 показаны изменения в работе над проектом, обу-
словленные различными рейтингами атрибута ОП. Наибольшее
увеличение стоимости на фазе комплексирования и испытаний в
основном связано с большей стоимостью тестирования (например,
при одновременном размещении в оперативной памяти самого кода
и тестовых драйверов) и исправления ошибок.
Сравнение с фактическими данными. Как и раньше, в качестве
основы для сопоставления будем использовать коэффициент иде-
альных затрат КИЗ(П, ОП) для каждого проекта (П) базы дан-
ных КОМОСТ.
На рис. 25.6 приводятся значения КИЗ(П, ОП) для проектов
^азы данных КОМОСТ и значения коэффициентов полных затрат
КОМОСТ (показаны кружками) для четырех рейтингов атрибу-
та ОП.
Согласование коэффициентов затрат в КОМОСТ и средних
значений КИЗ (П, ОП) (стрелки на рис. 25.6) не столь хорошее,
как для других стоимостных атрибутов КОМОСТ. Данные по про-
ектам указывают, что более подходящими были бы меньшие зна-
чения для коэффициентов затрат при очень высоком рейтинге атри-
бута ОП и большие значения для коэффициентов затрат при сверх-
высоком рейтинге атрибута ОП. Тем не менее отличия не слишком
342
2,40
2,3 I
Рис. 25.6. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ОП
велики, и существующие коэффициенты затрат для атрибута ОП
сохранены в интересах стабильности настоящей модели. Аналогич-
ные исследования проводились в предыдущем разделе.
В качестве иллюстрации к обсуждению атрибутов ОБД и ОП
предлагается ответить на следующий вопрос. Пусть номинальное
распределение затрат по фазам для среднего (8 КЧИК) проекта
ПО полунезависимого типа составляет: проектирование изделия
17%; детальное проектирование 26%; кодирование и автономная
отладка 35%; комплексирование и испытания 22%. Каким было бы
распределение затрат для проекта, если бы он имел сверхвысокий
уровень ограничений по быстродействию и оперативной памяти?
25.3. ИЗМЕНЯЕМОСТЬ ВИРТУАЛЬНОЙ МАШИНЫ (ИВМ)
Рейтинги и коэффициенты затрат. В табл. 23.3 приведены коэф-
фициенты затрат на разработку ПО в зависимости от степени из-
меняемости виртуальной машины, являющейся базовой для разра-
батываемой подсистемы ПО. Для заданной подсистемы ПО базо-
вая виртуальная машина представляет собой комплекс аппаратно-
программного обеспечения, который используется этой подсистемой
для выполнения своих задач. Например:
если разрабатываемая подсистема — эго ОС, то базовая виртуальная маши-
на — это ТО ЭВМ:
если разрабатываемая подсистема является системой управления базой дан-
ных (СУБД), то базовая виртуальная маш ша состоит, как правило, из ТО ЭВМ
и ОС;
343
если разрабатываемая подсистема ориентирована на работу с базой Данны*
прикладного назначения, то базовая виртуальная машина часто состоит из тп
ЭВМ, ОС и СУБД;
кроме того, базовая виртуальная машина включает компиляторы или ассемб-
леры всех языков, на которых написана подсистема ПО.
Ясно, что разработка любой из этих подсистем потребует боль-
ших затрат, если соответствующая виртуальная машина подверга-
ется текущим изменениям.
Рейтинги ИВМ определяются уровнем относительной частоты
глобальных и локальных изменений, которым подвергается базо-
вая виртуальная машина. Степень изменений определяется следу-
ющим образом: глобальное изменение существенно влияет пример-
но на 10% разрабатываемых подпрограмм; локальное измене-
ние — примерно на 1%. Распределение коэффициентов затрат по
фазам для различных рейтингов атрибута ИВМ изображено на
рис. 25.7.
1.40
1,30
Й 1.20
»-
I 1.10
i 1'00
S 0,90
0,80
Рейтинг
ИВМ
Рис. 25.7. Распре-
деление коэффи-
циентов затрат
труда по фазам
для атрибута
ИВМ
!_______
Комплекси-
рование и
испытания
______!___________I____________I
Анализ Детальной Кодирование
требований проекти- и автономная
И проектиро- рованис отладка
вание изделия
В табл. 25.7 показаны изменения в работе над проектом, обу-
словленные различной степенью изменяемости виртуальной маши-
Таблица 25.7
Изменения в работе над проектом на разных фазах,
обусловленные изменяемостью виртуальной машины
Анализ требований и проектирование изделия Детальное проектирование Кодирование и автономная отладка Ко мп лексирование и испытания
Низкий рейтинг
Меньше работы по анализу соотношения ТО/ПО и подтверждению------------►
Меньше изменений интерфейса, ошибок работы по управлению
конфигурацией----------------------------------------------------------.>
Меньше переработки планов тестирования---------------------------------».
Меньше изменяемых
компонентов, подле-
жащих комплекси-
рованию
344
Номинальный рейтинг
Без изменений----------------------------------------------------------►
Высокий рейтинг
Больше работы по анализу соотношения ТО/ПО и подтверждению -------------г
Больше изменений интерфейса, ошибок, работы по управлению конфигурацией
Больше переработки планов тестирования --------------------------------►
Больше изменяемых
компонентов, подле-
жащих комплекси-
рованию
Возможны разработка и использование эмуляторов ТО----------------------►
Очень высокий рейтинг
Большая степень перечисленных выше изменений---------------------------►
Проблемы, связанные с многократными изменениями -----------------------►
Рис. 25.8. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
Для различных рейтингов атрибута ИВМ
345
ны. Наибольшее увеличение стоимости на фазе комплексирования
и испытаний в основном вызвано более высокой стоимостью внесе-
ния изменений и исправлений ошибок на последних фазах разра-
ботки.
Сравнение с фактическими данными. На рис. 25.8 приводятся
значения коэффициента идеальных затрат КИЗ (П, ИВМ) для
проектов в базе данных КОМОСТ и значения коэффициентов пол-
ных затрат в КОМОСТ (показаны кружками) для четырех рейтин-
гов атрибута ИВМ. Согласование коэффициентов затрат в КО-
МОСТ и средних значений КИЗ (П, ИВМ) (показаны стрелками)
отличное.
Рис. 25.9. Распределение коэффициентов затрат труда по фазам для атрибута
ЦО
Обсуждение. Связанный с изменяемостью виртуальной машины
МКУП составляет 1,49. В работе [291] для фактора «параллельно
разрабатываемое техническое обеспечение» (опять, возможно,
включая влияние взаимодействующих факторов) указывается ана-
логичный коэффициент, равный 1,62. В модели из работы [147]
для фактора «первое ПО, разрабатываемое на центральном про-
цессоре» приводится МКУП=1,82, а в модели из работы
[118] для фактора «техническое обеспечение, разрабатываемое
параллельно» используется коэффициент корректировки сложности
+ 0,3, что в основном соответствует МКУП=1,4. Ни в одной из
других опубликованных работ фактор изменяемости виртуальной
машины не учитывается.
346
25.4. ЦИКЛ ОБРАЩЕНИЯ К ЭВМ (ЦО)
Рейтинги и коэффициенты затрат. В табл. 23.3 представлены
коэффициенты затрат на разработку ПО в зависимости от продол-
жительности времени ответа ЭВМ, установленной бригадой, разра-
батывающей подсистему. Рейтинги выражаются средними значе-
ниями времени ответа (СВО) в часах (время, прошедшее с момен-
та передачи задания разработчиком на запуск до момента получе-
ния им результатов запуска). Исключением является рейтинг для
непосредственной интерактивной разработки, которая выполняется
в диалоговом режиме с помощью индивидуального терминала раз-
работчика с временем ответа для простых операций от 0 до 5 с.
Распределение коэффициента затрат по фазам для различных
рейтингов атрибута ЦО изображено на рис. 25.9.
Т а б л и ц.а 25.8
Изменения в работе над проектом на разных фазах,
обусловленные изменением цикла обращения к ЭВМ
Анализ требований
и проектирование
изделия -
Детальное.
проектирование
Кодирование и ав-
тономная отладка
Комплексирование
и испытания
Низкий рейтинг ^интерактивная обработка)
Более быстрое редактирование текстов------------:----------------------->
Интерактивное моделирование,
построение прототипов
Интерактивная отладка-----------------------
Номинальный рейтинг (пакетная обработка, <4 ч)
Без изменений-----------------------------------------------------------►
Высокий рейтинг (пакетная обработка, 4... 12 ч)
Более медленные
моделирование и
построение про-
тотипов
Более медленные
моделирование и
работа с языком
проектирования
программ
Более медленные
компиляция, те-
стирование, отлад-
ка, использова-
ние инструмен-
тальных средств
Более медленные
компиляция, те-
стирование, отлад-
ка, использова-
ние инструмен-
тальных средств
Очень высокий рейтинг (пакетная обработка, >12 ч)
Большая степень перечисленных выше изменений----------------------------—
В табл. 25.8 показаны изменения в работе над проектом, обус-
ловленные различными рейтингами атрибута ЦО. Наибольшее со-
кращение затрат за счет интерактивной разработки на фазе коди-
рования и автономной отладки в основном объясняется редактиро-
ванием исходного кода и отладкой на уровне модулей, которые со-
ставляют преимущественную часть работы на этой фазе
1 Похоже, что современные и будущие интерактивные системы, основанные на
возможностях пословной обработки, приведут к еще большему сокращению
затрат на фазах анализа требований и проектирования изделия.
.347
Сравнение с фактическими данными. На рис. 25.10 приводят-!
значения КИЗ (П, ЦО) для проектов базы данных КОМОСТ и ки
эффициентов полных затрат в КОМОСТ (показаны кружками)
для четырех рейтингов атрибута ЦО. Согласование коэффициен-
тов затрат в КОМОСТ и средних значений КИЗ (П, ЦО) (показа-
ны стрелками) не столь хорошее, как хотелось бы. Например, сред-
нее значение КИЗ для 21 проекта при использовании интерактив-
Рис. 25.10. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ЦО
ной разработки ПО (низкие рейтинги ЦО) составляет 0,93, а не
0,87 (коэффициент полных затрат в КОМОСТ). Невольно возника-
ет желание увеличить коэффициенты затрат в КОМОСТ для низ-
кого рейтинга атрибута ЦО (в ранней версии модели они были
больше), но существующие коэффициенты в данном случае сохра-|
няются в интересах стабильности модели и согласования с другц-|
ми данными, которые обсуждаются ниже.
Обсуждение. Влияние интерактивного программирования на
производительность разработки ПО служит предметом обширных
исследований. Ранние исследования, итог которых подведен в ра-
348
боте [262], показали среднее улучшение производительности коди-
рования и автономной отладки, составляющее 20%. С 1970 г. были
разработаны улучшенные интерактивные системы, которые предо-
ставили более широкие возможности диалогового программиро-
вания. Результаты нескольких последних опытных исследований
обобщены в работе [162]. Эквивалентные коэффициенты затрат,
определенные в этих исследованиях в основном для задач кодиро-
вания и автономной отладки, составили 0,47; 0,50; 0,56 и 0,62.
При интерпретации приведенной выше картины возникает ряд
трудностей. В последних исследованиях влияние фактора ЦО сме-
шивается с влиянием усовершенствованных возможностей инстру-
ментальных средств (фактор ИИС). Трудно оценить также время,
которое программист тратит на ожидание результатов пакетной
обработки (около 16% по данным работы [250]) и которое продук-
тивно могло бы использоваться для выполнения других работ, та-
ких как документирование или разработка других частей кода,
особенно в условиях большого проекта. Имеется также работа, не
относящаяся к программированию (руководство, планирование
комплексирования и испытаний, подтверждение качества) и выпол-
няемая даже на фазе кодирования и автономной отладки, на кото-
рую интерактивное программирование сильного влияния не ока-
зывает. Не удивительно поэтому, что современные модели оцени-
вания стоимости используют меньшие коэффициенты затрат при
использовании интерактивного программирования, чем приведен-
ные выше. Ниже приводятся коэффициенты затрат, используемые
в современных моделях:
Модель Кодирование и авто- номная отладка Весь проект
См. 33] 0,54 0,875
См. 147] 0,83
См. 80] 0,80
См. 307] 0,75
КОМОСТ 0,70 0,87
Исследования влияния длительных времен ответа ЭВМ редки.
В работе [291] сообщается, что диапазон значений коэффициентов
затрат для двух факторов, отражающих ограничения доступа к
ЭВМ, составил 1,58 ... 1,78. Модель из работы [147] объединяют
три мультипликативных фактора, учитывающих взаимосвязанное
влияние:
Разработчика, использующего ЭВМ с другими возможностями .1,43
Разработки ПО там, где оно будет эксплуатироваться...................1,39
Инструментальной ЭВМ, отличной от объектной.........................1.25
Общее влияние всех трех факторов.....................................2,48
Общее влияние всех трех факторов кажется завышенным.
Модель из работы [307] включает следующие коэффициенты
затрат для различных циклов обращения к ЭВМ при пакетной об-
работке:
349
Больше одного обращения в сутки .... 0,8
Одно обращение в сутки....................1»0
'Меньше одного обращения в сутки < . . .1,2
Модель из работы [80] дает значение коэффициента затрат 1,1
при превышающем 4 ч времени ответа в пакетном режиме. Модель
из работы [139] имеет МКУП=1,46 для времени ответа от мгно-
венного до 12 ... 24 ч.
Некоторые исследования показывают, что легкость доступа к
ЭВМ еще не гарантирует увеличения производительности, так как
может стимулировать программирование методом проб и ошибок,
а также концентрировать внимание на тактике, а не на стратегии
разработки программ. Например, обзор [123] исследования произ-
водительности разработки ПО показал отрицательную корреляцию
между производительностью и расстоянием от программиста до
ЭВМ. В эксперименте по интерактивному программированию и ре-
шению проблем [36] было показано, что разработчики с неограни-
ченным интерактивным доступом к ЭВМ получали более плохие
результаты, чем те, терминальная клавиатура которых блокирова-
лась на короткий промежуток времени после выдачи результатов
текущего запуска. Типичным комментарием последних было: «Мне
не слишком нравится блокировка, но она дала мне время поду-
мать». Другие аналогичные результаты обсуждаются в работе
[274].
Методы хорошего программирования предусматривают развитие
современных систем интерактивной разработки ПО: развитие кол-
лективного интерактивного доступа, использование мощных ин-
струментальных средств, поддержка практики современного про-
граммирования. Такое направление в будущем еще больше затруд-
нит разделение влияния факторов ЦО, ПСП, ИИС в КОМОСТ, но
облегчит достижение более высокой производительности разработ-
ки ПО. Другая вероятная тенденция в будущем — это уменьшение
коэффициентов затрат в КОМОСТ для фаз анализа требований и
проектирования изделия за счет большей интеграции средств обес-
печения программирования и обработки слов в системах интерак-
тивной разработки, что позволит улучшить работу на этой фазе, ее
контроль и последовательное уточнение.
Пример. Представляет интерес следующее приближение при расчете полных
затрат для атрибута ЦО:
ЧМ= (ЧМ)„„Ы(0,99+0,4УСВО),
где СВО — среднее время ответа ЭВМ, ч. Используя это уравнение, можно вычис-
лить сокращение общих затрат^ требуемых на разработку проекта ПО, в резуль-
тате возможного уменьшения СВО.
15.5. ТЕМЫ ДЛЯ ДАЛЬНЕЙШИХ ИССЛЕДОВАНИЙ
А. Соберите и проанализируйте данные по влиянию атрибутов ОБД, ОП,
ИВМ и ЦО на конкретные виды работ над проектом ПО, указанные в табл. 25.1,
25.6, 25.7 и 25.8 соответственно.
Б. Сделан ряд попыток охарактеризовать значение информации, обрабатывае-
мой ЭВМ, с точки зрения ее своевременности [91, 103, 137, 173, 207]. Исходя из
350
этих исследований и результатов гл. 25, разработайте методы оценивания соотно-
шения между общей стоимостью аппаратно-программной системы и значением
быстро обрабатываемой (или новой) информации для конкретной области приме-
нения. Оцените этот метод, использовав его для соответствующей прикладной об-
ласти.
В. Разработка ПО для микропроцессоров содержит много потенциальных
проблем, связанных с ограничениями по быстродействию и оперативной памяти.
Сформулируйте и проанализируйте экономичность и стратегии разработки ПО для
микропроцессоров с помощью больших инструментальных ЭВМ и дальнейшей экс-
плуатации этого ПО. Оцените стратегии такой разработки по их экономичности,
исходя из реального использования.
Г. Системы с виртуальной памятью позволяют разработчику ПО работать без
ограничений по оперативной памяти, но часто за счет снижения производительно-
сти используемого ТО. Исследуйте соотношения между ограничениями на ТО и
стоимостью ПО для систем с виртуальной памятью.
Д. Методы разбиения программы на модули и «упрятывания» информации
[233] позволяют минимизировать влияние изменяемости виртуальной машины за
счет заблаговременного выделения характеристик этой машины, которые будут
изменяться с наибольшей вероятностью, и «упрятывания» информации о них в от-
дельный модуль. Затем при изменении этих характеристик, пересмотру будет под-
лежать только этот модуль. Поставьте эксперимент по определению степени со-
кращения дополнительной стоимости, обусловленной изменяемостью виртуальной
машины, при использовании этих методов.
Е. Прежние исследования пакетного и интерактивного режимов работы пока-
зали, что обеспечение интерактивной разработки ПО требует значително больших
(40... 50 %) ресурсов ЭВМ, чем обеспечение пакетной обработки. Поставьте
эксперимент по определению того, наблюдается ли это еще в настоящее время.
ГЛАВА 26
АТРИБУТЫ ИСПОЛНИТЕЛЕЙ КАК СТОИМОСТНЫЕ ФАКТОРЫ
ДЕТАЛЬНОЙ КОМОСТ
26.1. КВАЛИФИКАЦИЯ АНАЛИТИКОВ (КА)
Рейтинги и коэффициенты затрат. В табл. 23.3 указаны пять
рейтингов квалификации аналитиков, разрабатывающих одну из
программных подсистем. Для каждого рейтинга приводится набор
коэффициентов, определяющих, во сколько раз должно быть уве-
личено номинальное значение затрат труда на каждой фазе для
учета различий в квалификации аналитиков по сравнению с номи-
нальной квалификацией.
Пример. Предположим, что затраты труда бригады аналитиков номинальной
квалификации на разработку некоторой подсистемы ПО оцениваются в 10 ЧМ для
каждой из основных фаз. Допустим также, что решено заменить этих специали-
стов бригадой высококвалифицированных аналитиков. В таком случае с помощью
коэффициентов из табл. 23.3 можно определить, что оценки затрат труда при по-
добной замене составят 7,5 ЧМ для анализа требований и проектирования изде-
лия, 9,0 ЧМ для детального проектирования, 9,0 ЧМ для кодирования и автоном-
ной отладки и 8,5 ЧМ для комплексирования и испытаний.
Главные причины уменьшения трудоемкости отражены в
табл. 26.1, где показаны различия в работе на каждой фазе, обус-
351
Таблица 26.1
Изменения в работе над проектом на разных фазах,
обусловленные изменением квалификации аналитиков
Анализ требований н проектирование изделия Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Очень низкий рейтинг (15 процентилей)
Больше проблем, связанных с установлением интерфейса и общением----------->.
Меньшая эффективность работы ---------------------------------------------Я
Больше ошибок и из- Больший объем доработок требований и проектов си-
менений решений стем, больше ошибок при доработках ----------------------ь-
Менее эффективное взаимодействие с программистами
Больше проблем, свя-
занных с отладкой и
испытаниями
Низкий рейтинг (15 процентилей)
Средняя степень перечисленных выше изменений -----------------------------►
Номинальный рейтинг (55 процентилей)
Без изменений-------------------------------------------------------------►
Высокий рейтинг (75 процентилей)
Меньше проблем, связанных с установлением интерфейса и общением-----------*-
Большая эффективность работы ---------------------------------------------►
Меньше ошибок и из- Меньший объем доработок требований и проектов
менений решений систем, меньше ошибок при доработках ---------------------„
Более эффективное взаимодействие с программиста-
ми -----------------------------------------------►
Меньше проблем, свя-
занных с отладкой V
испытаниями
Очень высокий рейтинг (90 процентилей)
Большая степень перечисленных выше изменений------------------------------►
ловленные изменением квалификации занятых в этих работах
аналитиков. Так, сокращение (на 25%) затрат труда на анализ
требований и проектирование изделия объясняется тем, что высо-
коквалифицированные аналитики будут работать более эффективно
и затратят меньше времени на разрешение проблем, связанных с
установлением интерфейса и общением, а также на изменение ре-
шений и исправление ошибок, чем бригада аналитиков номиналь-
ной квалификации.
В используемой модели предполагается, что при создании ПО
бригада аналитиков выполняет следующие работы:
весь объем разработки и подтверждения требований, предвари-
тельных спецификаций проекта и соответствующих планов отлад-
ки и испытаний;
консультирование на фазах детального проектирования, ко-
дирования и автономной отладки с целью пояснения программи-
стам спецификаций и их доработки в случае необходимости;
352
основной объем комплексирования и испытаний.
Кроме того, модель позволяет аналитикам при разработке про-
екта выполнять функции программистов.
В табл. 23.3 рейтинги выражены в процентилях распределения
квалификации всех аналитиков программных проектов. При опре-
делении фактических рейтингов необходимо рассматривать следу-
ющие основные факторы:
способность к анализу;
эффективность и тщательность выполнения работы;
способность к общению и сотрудничеству.
При оценивании квалификации аналитиков эти факторы дол-
жны иметь приблизительно одинаковый вес. Кроме того, оценка не
должна включать опыт работы аналитиков, поскольку он учитыва-
ется другими факторами, и должна основываться на квалификации
аналитиков как единой бригады, а не как отдельных исполнителей.
Анализ Детальное Кодирование и Комплекси-
требований и проекти- автономная рование и
проектирова- рование отладка испытания
ние изделия
Рис. 26.1. Распре-
деление коэффи-
циентов затрат
труда по фазам
для атрибута КА
Как и в случае таблиц зависимости номинальной производитель-
ности разработки программного проекта от его размера, можно с
помощью интерполяции вычислять промежуточные значения коэф-
фициентов затрат труда. Распределение этих коэффициентов по
фазам для различных рейтингов атрибута КА представлено на
рис. 26.1.
Сравнение с фактическими данными. На рис. 26.2 значения
КПЗ (П, КА) [см. уравнение (24.1)] по проектам базы данных
КОМОСТ сопоставлены с используемыми в КОМОСТ для пяти
рейтингов КА коэффициентами затрат труда на всю программную
разработку (показаны кружками). Из рисунка видно, что для
каждого рейтинга соответствие коэффициентов в КОМОСТ и сред-
них значений КИЗ (П, КА) (показаны стрелками) вполне удовле-
творительно. Лишь при очень низкой квалификации единственное
значение КИЗ гораздо больше соответствующего коэффициента в
КОМОСТ (2,09 по сравнению с 1,46), однако для изменения коэф-
фициентов в КОМОСТ собранных данных недостаточно.
12 Зак 628 353
Рис. 26.2. Коэффициенты идеальных затрат и коэффициенты в КОМОСТ для
различных рейтингов атрибута КА
Обсуждение. В КОМОСТ МКУП для всего проекта равен 2,06
из-за изменения квалификации аналитиков (от очень низкой до
очень высокой). Это значение может показаться довольно низким
в свете следующих фактических данных:
максимальное значение отношения производительностей труда
опытных программистов, участвовавших в экспериментах по срав-
нению режимов пакетной обработки и разделения времени, соста-
вило 26 [262];
отношение производительностей труда при разработках проек-
тов фирмы IBM, проводимых персоналом с высокими и низкими
опытом и квалификацией, доходило до 3,11 [291];
в трудах семинара по затратам на ПО [6] сообщается о том.
что типичное значение МКУП, обусловленное действием человече-
ского фактора, составляет 5,0.
Однако приведенные данные вполне объяснимы, если принять
во внимание и другие стоимостные факторы КОМОСТ, связанные с
характеристиками исполнителей:
354
за счет квалификации программистов производительность труда
может возрасти в 2,03 раза. С учетом же и квалификации анали-
тиков можно достичь общего увеличения производительности в
4,18 раза;
в КОМОСТ входят три фактора, связанные с опытом исполни-
телей (в скобках указывается значение МКУП для соответствую-
щего фактора): опыт работы в прикладной области (1,57), с вир-
туальной машиной (1,34) и с языком программирования (1,20).
Общий коэффициент увеличения производительности с учетом всех
этих факторов может составить 2,52;
совместное действие факторов квалификации и опыта может
повысить производительность труда в 10,53 раза (4.18X2.52). Это
означает, что повышение квалификации исполнителей от очень
низкой до очень высокой, а также их опыта — от очень малого до
очень большого позволило бы уменьшить затраты труда на проект
в 10,53 раза.
Кроме того, следует отметить, что коэффициенты в КОМОСТ
вовсе не предназначены для учета предельных значений производи-
тельности труда исполнителей. Приведенные в этом разделе рейтин-
ги и коэффициенты затрат труда не применимы к оцениванию труда
аналитиков с квалификацией ниже 15 или выше 90 процентилей.
Поэтому, например, при исключительно высокой квалификации
исполнителей (такой, как у описанной в работе [21] бригады глав-
ного программиста, достигшей производительности 600 ЧИК/ЧМ
для проекта размером 80 000 ЧИК) оценки по КОМОСТ затрат
труда будут несколько завышенными.
26.2. ОПЫТ РАБОТЫ В ДАННОЙ ПРИКЛАДНОЙ ОБЛАСТИ (ОРП|
Рейтинги и коэффициенты затрат труда. В табл. 23.3 приведены
коэффициенты затрат труда в зависимости от опыта работы брига-
Рис^ 26.3. Распределение коэффициентов затрат труда по фазам для атрибута
12*
355
g? Таблица 26.2
Изменения в работе над проектом на разных фазах, обусловленные изменением ОРП
Анализ требований
и проектирование изделия
Детальное проектнррвание
Кодирование и автономная
отладка
Комплексирование
и испытания
Большая трудоемкость плани-
рования отладки и испытаний
Больший объем сбора данных
и их изучения
Более трудоемкий анализ
Более частое изменение реше-
ний
Больше ошибок, исправлений
требований
Очень низкий рейтинг (^4 мес.)
Большая трудоемкость плани- Большая трудоемкость плани-
рования отладки и испытаний рования отладки и испытаний
Немного больший объем сбора
данных и их изучения
Немного более частое измене-
ние решений
Больше исправлений требова-
ний, предварительного проекта
Немного больший объем сбора
данных и их изучения
Немного более частое измене-
ние решений
Немного больше ошибок
Больше исправлений треоова-
ний, проекта
Немного большая доработ-
ка плана и процедур испы-
таний
Больше исправлений требо-
ваний, проекта
Низкий рейтинг (1 год)
Средняя степень перечисленных выше изменений ---------------------------
Номинальный рейтинг (3 года)
Без изменений ----------------------------------------------------------
Высокий рейтинг (6 лет)
Меньшая трудоемкость плани-
рования отладки и испытаний
Меньший объем сбора данных
и их изучения
Менее трудоемкий анализ
Менее частое изменение реше-
ний
Меньше ошибок, исправлений
требований
Меньшая трудоемкость плани-
рования отладки и испытаний
Немного меньший объем сбо-
ра данных и их изучения
Немного менее частое измене-
ние решений
Немного меньше ошибок
Меньше исправлений, требова-
ний, предварительного проекта
Меньшая трудоемкость плани-
рования отладки и испытаний
Немного меньший объем сбо-
ра данных и их изучения
Немного менее частое измене-
ние решений
Немного меньше ошибок
Меньше исправлений требова-
ний, проекта
Немного меньшая доработ-
ка плана и процедур испы
таний
Меньше исправлений тре-
бований, проекта
Большая степень перечисленных выше изменений
Очень высокий рейтинг (^12 лет)
ды в данной прикладной области. Используемые в таблице рей-
тинги определяются средним стажем работы бригады в аналогич-
ных прикладных областях: очень низкий ^4 мес., низкий 1 год,
номинальный 3 года, высокий 6 лет, очень высокий ^12 лет или
повторная разработка.
Рис. 26.4. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ОРП
Распределение по фазам коэффициентов затрат труда для раз-
личных рейтингов атрибута ОРП представлено на рис. 26.3.
В табл. 26.2 показаны различия в проектных работах, обуслов-
ленные изменением ОРП. Согласно приведенным данным больший
разброс коэффициента затрат труда на ранних фазах является
следствием более сильных различий в расходах на обучение в на-
чале проекта.
Сравнение с фактическими данными. На рис. 26.4 значения
КПЗ (П, ОРП) по проектам базы данных КОМОСТ сопоставлены
с используемыми в КОМОСТ для пяти рейтингов ОРП коэффици-
ентами затрат труда на всю программную разработку (показаны
кружками). Из рисунка видно, что для каждого рейтинга соответ-
357
ствие коэффициентов в КОМОСТ и средних значений КИЗ (П,
ОРП) (показаны стрелками), как правило, вполне удовлетвори-
тельное. Лишь для высокого рейтинга среднее значение КИЗ (П,
ОРП) несколько меньше приемлемого значения, однако надлежа-
щее изменение КИЗ только в одном из проектов с этим рейтингом
привело бы соеднее значение в соответствие с коэффициентом в
КОМОСТ.
Обсуждение. Результаты современных исследований моделей
оценки затрат на ПО, относящиеся к максимально достижимым
коэффициентам увеличения производительности труда для атрибу-
та ОРП, подытожены ниже:
Источник мкуп Источник МКУП
[313] 1,46... 1,65 [118] 1,70
[33] 2,05 [80] 1,20
[307] 3,00 КОМОСТ 1,57
[291] 2,81
в
Относительно данных работы [291] следует вновь заметить, чтс
ней МКУП в общем случае не являются независимыми. Они
обычно больше МКУП из других работ, поскольку часто учитыва-
ют, как указывалось в разд. 25.1, влияние других факторов.
Помимо приведенных табличных данных следует упомянуть в
о различиях в оценках влияния опыта работы в данной прикладной
области на производительность труда. Так, в работе [267] влияние
фактора «опыт работы программиста с аналогичными функцио-
нальными программами» считается одним из наиболее существен-
ных и оценивается рейтингом +5 по шкале [—7, +7]. В то же
время результаты работы [160] указывают на очень слабую зави-
симость производительности труда от опыта.
26.3. КВАЛИФИКАЦИЯ ПРОГРАММИСТОВ (КП|
Рейтинги и коэффициенты затрат труда. В табл. 23.2 приведены
коэффициенты затрат труда в зависимости от квалификации про-
граммистов. Используемые в таблице рейтинги выражены в про-
центилях распределения квалификации всех бригад программи-
стов. При определении фактических рейтингов необходимо рассма-
тривать следующие основные факторы:
способность к программированию;
эффективность и тщательность выполнения работы;
способность к общению и сотрудничеству.
При оценивании квалификации программистов эти факторы
должны иметь приблизительно одинаковый вес. Кроме того, оцен-
ка не должна включать опыт работы программистов, поскольку он
учитывается другими факторами, и должна основываться на ква-
лификации программистов как единой бригады, а не как отдель-
ных исполнителей.
358
Распределение по фазам коэффициента затрат труда для раз-
личных рейтингов атрибута КП представлено на рис. 26.5.
I____________I___________I____________I________
Анализ Детальное Кодирование и Комплекса-
Требований и проекти- автономная рован ие и
лроектиро- рование отладка испытания
вание
изделия
Рис. 26.5. Распределение коэффициентов затрат труда по фазам для атрибута
КП
В табл. 26.3 показаны различия в проектных работах, обуслов-
ленные изменением КП. В частности, данные этой таблицы свиде-
тельствуют об отсутствии на фазах анализа требований и проек-
тирования изделия каких-либо различий, вызванных изменением
квалификации программистов, поскольку до фазы детального про-
ектирования программирование практически не ведется.
Таблица 26.3
Изменения в работе над проектом на разных фазах,
обусловленные изменением квалификации программистов
Анализ требо-
ваний и проек-
тирование
изделия
Детальное
проектирование
Кодированной
автономная
отладка
Комплексирование
и испытания
Очень низкий рейтинг (15 процентилей)
Отсутствуют
Менее эффективное взаимодействие с аналитиками----------->-
Меньшая эффектив-1
ность работы I
Больше ошибок, изменений решений-------------------------►
Больший объем доработок детально-
го проекта, больше ошибок при до-
работках
Больший объем дора-
боток кода и доку-
ментации, больше
ошибок при доработ-
ках
359
Низкий рейтинг (35 процентилей)
Отсутствуют Средняя степень перечисленных выше изменений ------------------J
Номинальный рейтинг (55 процентилей)
Отсутствуют
Отсутствуют
Высокий рейтинг (75 процентилей)
Более эффективное взаимодействие с аналитиками----------J
Большая эффект™ 1
ность работы
Меньше ошибок, изменений решени'.-----------------------J
Меньший объем доработок детально-
го проекта, меньше ошибок при дора-
ботках
Меньший объем до
работок кода и доку-
ментации, меньше
ошибок при дораб' т
ках
Отсутствуют
Очень высокий рейтинг (90 процентилей)
Большая степень перечисленных выше изменений ------------г
Рис. 26.6. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута КП
360
Сравнение с фактическими данными. На рис. 26.6 значения КИЗ
(П, КП) по проектам базы данных КОМОСТ для пяти рейтингов
КП сопоставлены со значениями используемых в КОМОС Г коэф-
фициентов затрат труда на всю программную разработку (показа-
ны кружками). Из рисунка видно, что для каждого рейтинга соот-
ветствие коэффициентов затрат труда в КОМОСТ и средних значе-
ний КИЗ (П, КП) (показаны стрелками) вполне удовлетворитель-
ное. Лишь при очень низкой квалификации программистов значение
коэффициента в КОМОСТ (1.42) и среднее значение КИЗ (1.62)
согласуются недостаточно хорошо, однако, поскольку на этот рей-
тинг приходится только три проекта, для изменения коэффициентов
в КОМОСТ, по-видимому, нет оснований.
Обсуждение. Изменение МКУП в зависимости от КП уже рас-
сматривалось раньше. Важно отметить, что влияния КА и КП до-
полняют друг друга на разных фазах. Так, основные различия в
производительности, обусловленные изменением КА, приходятся на
фазу анализа требований и проектирования изделия, а на послед-
них трех фазах различия менее ощутимы, в то время как различия
в КП проявляются сильно и почти исключительно именно на по-
следних трех фазах.
В программном проекте достоинства одной из бригад (анали-
тиков или программистов) могут в значительной степени компек
сировать недостатки другой, в то время как при одинаковом уров-
не квалификации ее влияние на проект существенно усиливается.
Поучительно проследить по данным приводимой ниже таблицы, как
эти эффекты моделируются в КОМОСТ:
Рейтинги Суммарный коэффициент затрат труда
КА КП Анализ тре- i бований и | проектиро- вание изде- лия Детальное 5 S si <u и s о X Q.C5 “ (Q Кодирование и автономная отладка Комплекси- рование и испытания Вся рачра- бо.ка
Очень Очень Очень Очень НИЗКИЙ низкий высокий высокий Очень низкий Очень высокий Очень низкий Очень высокий 1,80 1,80 0,55 0,55 2,02 0,88 1,12 0,<*9 2,02 0,88 1,12 0,49 2,25 0 98 1,05 0,-*6 2,04 1,04 1,02 0,49
26.4. ОПЫТ РАБОТЫ С ВИРТУАЛЬНОЙ МАШИНОЙ (ОРВМ)
Рейтинги и коэффициенты затрат труда. В табл. 23.2 приведе-
ны коэффициенты затрат труда в зависимости от опыта работы
бригады с виртуальной машиной. Под виртуальной машиной здесь,
как и в разд. 25.3, понимается комплекс ТО и ПО (ЭВМ, ОС,
СУБД), используемый программами при выполнении задач. По-
этому язык программирования не является частью виртуальной
машины и его влияние на разработку будет рассмотрено отдельно
в разд. 26.5.
361
Таблица 26.4
Изменения в работе над проектом на разных фазах,
обусловленные изменением ОРВМ
Анализ требований и проектирование изделия Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Очень низкий рейтинг (^1 мес.) Большая трудоемкость анализа интерфейсов виртуальной машины и прикладной области, больше ошибок
гиучение вир i уш/шнии Планирование пере- носа инструменталь- ных средств Больший объем доработок, болг ботках Перенос инструментальных средств Большая трудоемкость документир Низкий рейтинг (4 мес.) иГПРНИКП RKIT1TP НЧМРПРМНЙ ,ше ошибок при дора- Болыпая трудоем- кость достижения требуемой эффектив- ности ования Я
Номинальный рейтинг (1 год)
Меньшая трудоемкого области, меньше ошиб Высокий рейтинг (>3 года) анализа интерфейсов виртуальной эк Меньший объем доработок, меньп ботках Меньшая трудоемкость документ машины и прикладной ле ошибок при дора- ирования ► Меньшая трудоем- кость достижения требуемой эффектив- ности
Используемые в таблице рейтинги определяются средним опы-
том работы бригады с виртуальной машиной, намечаемой к исполь-
зованию: очень низкий 1 мес., низкий 4 мес., номинальный 1 год,
высокий ^3 года
. Распределение по фазам коэффициентов затрат труда для раз-
личных рейтингов атрибута ОРВМ представлено на рис. 26.7.
В табл. 26.4 показаны различия в проектных работах, обуслов-
ленные изменением ОРВМ.
Сравнение с фактическими данными. На рис. 26.8 значения
КИЗ (П, ОРВМ) по проектам базы данных КОМОСТ сопоставле-
ны с используемыми в КОМОСТ для четырех рейтингов ОРВМ ко-
эффициентами затрат труда на всю программную разработку (по-
казаны кружками). Из рисунка видно, что для каждого рейтинга
соответствие коэффициентов затрат труда в КОМОСТ и средних
значений КИЗ (П, ОРВМ) (показаны стрелками) вполне удовле-
362
творительное. Лишь для очень низкого рейтинга среднее значение
КИЗ заметно больше коэффициента в КОМОСТ, однако выбоока
из трех экспериментальных точек не дает веских оснований для
изменения коэффициентов в КОМОСТ.
Рис. 26.7.
DPBM
вание изделия
Распределение коэффициентов
затрат труда по фазам для атрибута
Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
Рис. 26.8. Г’ ;:
Чля различных рейтингов атрибута ОРВМ
363
Обсуждение. Многие модели не включают фактора, соответст-
вующего опыту работы с виртуальной машиной. Данные же для
тех моделей, в которых подобный фактор учитывается, таковы:
для фактора «первое ПО для процессора» [147] МКУП=1,92
и является наибольшим среди коэффициентов для всех других фак-
торов в этой модели;
для фактора «опыт предыдущей работы с эксплуатируемой
ЭВМ» [291] МКУП=2,14, что, как уже указывалось ранее в ана-
логичных случаях, может частично являться следствием влияния
других факторов;
коэффициент увеличения затрат труда для фактора «новое ТО»
[118] равен приблизительно 1,2;
для атрибута ОРВМ в КОМОСТ МКУП—1,34.
26.5. ОПЫТ РАБОТЫ С ЯЗЫКОМ ПРОГРАММИРОВАНИЯ (ОРЯП|
Рейтинги и коэффициенты затрат труда. В табл. 23.2 приведены
коэффициенты затрат труда в зависимости от опыта работы брига-
ды с языком программирования. Используемые в таблице рейтин-
ги определяются средним опытом работы бригады с языком про-
граммирования, намечаемым к использованию: очень низкий
^1 мес.; низкий 4 мес.; номинальный 1 год; высокий ^3 года.
Распределение по фазам коэффициентов затрат труда для раз-
личных рейтингов атрибута ОРЯП представлено на рис. 26.9.
1,40 г-
g. 1.зо -
СТ I
" 1.20-
X
Ш
5 1.00-
S
-&
-& ы°-
* 0,90-
Рейтинг ОРЯП
Очень низкий
Низкий
Номинальный
Высокий
I
Анализ^
Требований и
проектирова-
ние изделия
I -
Детальное Кодирование
гроектира-» «автономная
ванио отладка
I
Комплекси-
рование и
испытания
Рис. 26.9. Распределение коэффициентов затрат труда по фазам для атрибута
ОРЯП
В табл. 26.5 показаны различия в проектных работах, обуслов-
ленные изменением ОРЯП.
Сравнение с фактическими данными. На рис. 26.10 значения
КПЗ (П, ОРЯП) по проектам базы данных КОМОСТ сопоставле-
ны с используемыми в КОМОСТ для четырех рейтингов ОРЯП
коэффициентами затрат труда на всю программную разработку
(показаны кружками). Из рисунка видно, что для каждого рейтин-
га соответствие коэффициентов затрат труда в КОМОСТ и средних
значений КИЗ (П, ОРЯП) (показаны стрелками) вполне удовлё-
364
Таблица 26.5
Изменения в работе над проектом на разных фазах,
обусловленные изменением ОРЯП
Анализ требований и проектирование изделия Детальное проектирование Кодирование и авто- номная отладка Комплексирование и испытания
Очень низкий рейтинг (^1 мес.)
Вол ып а я трудоем - Исправление боль- шего числа оши- бок
кость изучения, боль- ше ошибок, измене- ний решений
Исправление несоответствии проекта и языка программи- рования
Перенос инструментальных средств > | Большая трудоемкость документирования Низкий рейтинг (4 мес.) Г' поппаа СТОПРПЬ ПРПРППГ ПРППЫУ АТЧТТНР 1ПМРИРППИ Ъ.
Отсутствуют Номинальный рейтинг (1 год) —->- Высокий рейтинг (^3 года) Меньше исправлений несоответствий проекта и языка программирования МрИМПЯЯ ТПЦППРМкПГТИ ППКг’МРЙТИПППЯИКЯ W
Меньше ошибок, из- менений решений Исправление мень- шего числа оши- бок
творительное. Лишь для очень низкого рейтинга, как и в случае
атрибутов КП и ОРВМ, среднее значение КИЗ существенно боль-
ше коэффициента в КОМОСТ, однако выборка из трех эксперимен-
тальных точек (фактически данных по тем же трем проектам, что и
для ОРВМ) не дает веских оснований для изменения коэффициен-
тов в КОМОСТ.
Обсуждение. Хотя большинство исследований указывают на
важность опыта работы с языком программирования как стоимост-
ного фактора, большинство моделей его не включают. Данные же
для тех моделей, в которых этот фактор учитывается, таковы:
для атрибута ОРЯП [291] МКУП=3,14, что, как указывалось
в разд. 25.1, частично объясняется влиянием других факторов;
коэффициент затрат труда для фактора «новый язык» [118] ра-
вен приблизительно 1,2-
для атрибута ОРЯП в КОМОСТ МКУП = 1,20.
26.6. ОБЩЕЕ ОБСУЖДЕНИЕ АТРИБУТОВ ИСПОЛНИТЕЛЕЙ
Количественная оценка производительности труда традиционно
была более точной в тех ситуациях, когда от исполнителей требо-
валось лишь механическое выполнение некоторых операций (на-
365
пример, при работе на буровой установке или кчавишном перфо,
раторе, или при сборке автомобиля). Поскольку же работа индХ
неров-программистов не сводится к механическому повторению оп-
ределенных действий, то оценивание нужно проводить, учитывая
специфику инженерного программирования и руководствуясь Здра-
вым смыслом.
В данном разделе обсуждаются основы оценивания атрибутов
исполнителей и определения их влияния на производительность
Рис. 26.10. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ОРЯП
труда при разработке ПО. Соответствующие темы можно разбить
на три группы:
1. Рейтинги атрибутов, определение которых оказывается не
столь простым, как это могло бы показаться из приведенных в
этой главе шкал рейтингов.
2. Исследования атрибутов исполнителей, результаты которых
позволяют лучше осознать возникающие при разработке ПО про-
блемы повышения производительности труда и оценивания стои-
мости.
336
3. Сбор и анализ данных, в результате которых формируются
список типичных ошибок и главные принципы учета психологиче-
ских аспектов инженерного программирования. Их важно иметь в
виду, планируя и проводя эксперименты и наблюдения при разра-
ботке ПО.
Рейтинги квалификации исполнителей. В КОМОСТ шкалы рей-
тингов квалификации аналитиков и программистов даются в про-
центилях гипотетического (одномерного) распределения квалифи-
кации всех аналитиков программных проектов и всех программи-
стов. В действительности же на практике нужно считаться со сле-
дующими обстоятельствами:
такого одномерного распределения не существует. Квалифика-
ции аналитиков и программистов являются существенно многомер-
ными атрибутами и должны оцениваться относительно им гнно той
совокупности умений и знаний, которая необходима для выполне-
ния конкретной работы. На высокую сложность такой ситуации
указывает, в частности, отчет [4] ;
отсутствуют методы достаточно надежного измерения квалифи-
кации аналитиков и программистов. В частности, существующие
средства оценивания способностей и измерения степени заинтере-
сованности в лучшем случае обнаруживают лишь очень слабую
связь с квалификацией аналитиков или программистов [194, 274,
296];
важно оценить не среднюю квалификацю отдельных аналити-
ков или программистов, а реальную квалификацию бригады анали-
тиков или программистов. Тем самым подразумевается учет ^аких
факторов, как сплоченность коллектива, способность к общению и
предпочтению интересов бригады личным интересам. (В работе
[296] содержится много примеров и принципов эффективной рабо-
ты инженеров-программистов, а также поучительных примеров не-
эффективной организации груда.)
Для получения достоверной оценки квалификации разработчи-
ков ПО (знания программирования, способности к общению и т. п.)
необходимо определить степень заинтересованности бригады. Сле-
дует, однако, констатировать отсутствие удовлетворительной шка-
1ы оценок заинтересованности, несмотря на крайнюю важность ее
учета в рейтингах квалификации, используемых для прогнозирова-
ния производительности труда.
В практике инженерного программирования полезно считать
шкалырейтингов квалификации относительными и настраиваемы-
ми. Действительно, в условиях конкретной организации такие шка-
лы, специально на нее ориентированные, имеют больший смысл,
е шкалы КОМОСТ, общие для всех программных проектов. Ис-
ользование специализированных шкал является также менее
ескураживающим, чем неконкретизированные утверждения, что,
нитКаТЬ] пР°Фессиональнь,й уровень данной бригады можно оце-
к ь в процентилей. (Методы настройки и адаптации КОМОСТ
условиям конкретной организации приводятся в разд 29.9).
367
Рейтинги опыта исполнителей. Рейтинги КОМОСТ для опыта
работы в прикладной области, с виртуальной машиной и языком
программирования измеряются в календарных единицах. Однако
для их определения необходимо правильно оценивать соответствие
чистого стажа работы и характеристик проекта. При этом необхо-
димо иметь в виду два главных соображения:
1. Опыт работы именно с теми аспектами прикладной области,
виртуальной машины или языка программирования, которые свя-
заны с предстоящим проектом. Так, три года разработки в пакет-
ном режиме программ обработки документации вряд ли стоит осо-
бенно учитывать, если рассматриваемый проект требует детального
знания средств, связанных с телеобработкой и работой сети ЭВМ
2. Объем знаний и навыков, усвоенных из опыта Здесь нужно
учитывать, что у некоторых специалистов объем знаний и навыков
может быть в несколько раз больше, чем у других, имеющих тот
же стаж работы.
Как и в случае оценивания квалификации, важно оценить ре-
альный опыт именно бригады. Например, если только двум или
трем членам бригады предстоит заниматься необычными аспекта-
ми сетевых протоколов, то при оценивании опыта необходимо рас-
сматривать опыт работы в этой области лишь этих членов бригады
Исследования атрибутов исполнителей. Потенциальный диапа-
зон индивидуальных различий в программной разработке лучше
всего показан на рис. 26.11, где подытожены результаты сравни-1
тельных исследований эффективности программирования в пакет-
ном режиме и в режиме разделения времени [135]. Для исключе-
ния индивидуальных различий к указанному исследованию были
привлечены только опытные специалисты со стажем программиро-
вания от 2 до 11 лет. Несмотря на это, результаты сравнения слабо
заметны на фоне широкого диапазона показанных на рисунке раз-
личий в индивидуальной производительности труда. Действитель-
но, сочетание отношений производительностей кодирования (18: 1)
и отладки (28 : 1) дало в этом эксперименте общее отношение про-
изводительностей труда 26 : 1. Кроме того, в проведенном экспери-1
менте наилучшая и наихудшая производительности наблюдались у
двух программистов с наибольшим стажем работы (11 лет). Ана-
логичное отношение производительностей труда (16: 1) было так-
же зафиксировано при сравнительном исследовании эффективно-
сти работы в условиях учебного заведения в режимах разделения
времени и пакетной обработки. Необходимо, однако, отметить, что
в обоих исследованиях широкий диапазон изменения производи-
тельности труда был обусловлен небольшим числом крайних слу-1
чаев, а используемый в КОМОСТ диапазон изменения квалифика-1
ции 15 ... 90 процентилей характеризуется отношениями произво-
дительности труда от 3 : 1 до 5 : 1.
Некоторая полезная информация относительно корреляции опы-
та работы в прикладной области, с языком программирования и
общего опыта программирования была получена при исследовании
главных факторов увеличения производительности труда в вычис-
368
.пительном центре при обработке экономической информации в
пакетном режиме с использованием Кобола [63]. При этом коэф-
фициент корреляции опыта обработки экономической информации
с опытом использования Кобола составил 0,977, а с общим опытом
программирования — 0,963. Если бы такие значения коэффициен-
та корреляции были типичными для всех организаций, то не было
бы необходимости во введении в КОМОСТ самостоятельных атри-
бутов ОРП, ОРВМ и ОРЯП. Однако, как можно увидеть при
рассмотрении или анализе рейтингов базы данных КОМОСТ, хотя
корреляция между различными атрибутами опыта работы доволь-
но высока, она недостаточна, чтобы оправдать исключение этих
атрибутов. Тем не менее результаты упомянутых исследований
свидетельствуют о возможно-
сти учета подобных корреля-
ций в практике отдельных вы-
числительных центров с целью
приспособления к их условиям
упрощенных версий КОМОСТ.
Некоторые соображения по
сбору и анализу данных. При
планировании и проведении
экспериментов и наблюдений
с участием разработчиков ПО
необходимо иметь в виду глав-
ные принципы и типичные
ошибки, выявленные в резуль-
тате исследования психологи-
ческих аспектов инженерного
программирования. Достаточ-
но полный список типичных
Рис. 26.11. Влияние человеческого фак-
тора на производительность труда в
программной разработке
ошибок, которых необходимо
избегать, приводится ниже (за
более полной информацией можно обратиться к работе I[296]):
1. Необоснованное использование собственного опыта.
2. Формулирование выводов на основе слишком узкого класса
[наблюдений.
3. Неправильный выбор изучаемых переменных или недостаточ-
ность информации для определения существенных переменных.
4. Вмешательство в наблюдаемые явления.
5. Получение слишком большого объема данных, не обеспечи-
вающих достаточной информации.
6. Излишнее ограничение условий экспериментов.
7. Чрезмерная зависимость от использования новичков в каче-
стве испытуемых.
8. Недостаточное внимание исследованию групповых эффектов
и группового поведения.
9. Изучение только простых для измерения аспектов.
10. Необоснованный выбор точности.
369
11. Ошибочное расширение области применимости заимствован-
ных результатов.
Полезные рекомендации по проведению психологических экспе-
риментов можно найти в работе [60]. Важные сведения относитель-
но использования этих рекомендаций приводятся также в работах
[212, 262, 274, 296].
ГЛАВА 27
АТРИБУТЫ ПРОЕКТА КАК СТОИМОСТНЫЕ ФАКТОРЫ ДЕТАЛЬНОЙ
КОМОСТ
27.1. ПРАКТИКА СОВРЕМЕННОГО ПРОГРАММИРОВАНИЯ (ПСП)
Рейтинги и коэффициенты затрат. В табл. 23.3 приводятся зна-
чения коэффициентов затрат на разработку ПО для различных
рейтингов атрибута ПСП. Практика современного программирова-
ния предусматривает использование таких методов, как:
1. Нисходящие анализ требований и проектирование изделия —
разработка требований к ПО и его проектирование путем последо-
вательного иерархического уточнения нужд и целей пользователя
при обработке информации. Обсуждавшееся в гл. 4 расширение
этого метода включает также пошаговую разработку, построение
прототипов и написание предварительной документации.
2. Структурированное описание проекта изделия — использова-
ние модульного иерархического описания проекта (языка проекти-
рования программ, структурных схем), согласованного со струк-
турным кодом (см. п. 5).
3. Нисходящая пошаговая разработка — выполнение детальных
проектирования, кодирования и комплексирования путем последо-
вательного иерархического уточнения структуры ПО.
4. Сквозные проверки или контроль проекта и кода — выполне-
ние заранее запланированного тщательного исследования деталь-
ного проекта и кода каждой единицы ПО.
5. Применение структурного кода — использование модульных
иерархических структур управления, основанных на малом числе
базовых структур управления, каждая из которых имеет только
одну точку входа и одну точку выхода.
6. Привлечение к работе библиотекаря программ — участника
проекта, ответственного за функционирование созданного архива
и системы управления компонентами ПО.
Методы современного программирования подробно описаны Е
ряде книг и статей, например в [156, 210, 317]. С перечисленными
выше методами часто связана не рассматриваемая здесь, но учи-
тываемая в атрибуте ИИС библиотека программной поддержки.
Привлечение к работе над проектом бригады главного программи-
рования дает совершенно разные результаты: с первоклассным
370
главным программистом производительность может быть очень вы-
сокой, а с плохим — чрезвычайно низкой.
Рейтинги атрибута ПСП определяются совокупностью методов
современного программирования, применяемых при разработке ПО,
и относительным опытом использования этих методов бригадой
проектирования:
Очень низкий .... Ни один из методов не используется
Низкий.................Начальное, экспериментальное исполь-
зование некоторых методов
Номинальный .... Достаточный опыт использования боль-
торых методов
Высокий................Достаточный опыт использования боль-
шинства методов
Очень высокий .... Повседневное использование всех мето-
дов
Распределение по фазам коэффициента затрат для различных
рейтингов атрибута ПСП показано на рис. 27.1.
Требований и проекти- и автономная рование и
Проектирование рование отладка испытания
изделия
Рис. 27.1. Распределение коэффициентов затрат труда по фазам для атрибута
ПСП
В табл. 27.1 представлены изменения в работе над проектом,
обусловленные различной степенью использования ПСП. Из таб-
лицы, например, видно, почему большая часть выгод, получаемых
от использования ПСП, приходится на фазу комплексирования и
испытаний: применение ПСП позволяет избежать ошибок или выя-
вить их на ранней стадии, когда исправление ошибок обходится
гораздо дешевле.
Сравнение с фактическими данными. На рис. 27.2 приводятся
значения коэффициента идеальных затрат КИЗ (П, ПСП), опреде-
ленного в разд. 24.1 для проектов базы данных КОМОСТ, и коэф-
фициентов полных затрат в КОМОСТ (показаны кружками) для
371
Таблица 27.1 Изменения в работе над проектом на разных фазах, обусловленные различной степенью использования практики современного программирования
Анализ требований и проектирование изделия Детальное проектирование Кодирование и автономная отладка Комплексирование и испытания
Очень низкий рейтинг
Больше исправлений ошибок в требованиях
Меньше работы по анализу и под- Больше исправлений ошибок в проекте изделия Проект труднее исправить и модифицировать: ошибки в
тверждению тре- бований и провер- ке системы Меньше первич- ной документации Средняя степень пе исправлениях Меньше затрат на сквозной конт- роль проекта Низкий эечисленных выше из Номиналы Больше исправлений екта и ошибок в ко/ Больше работы по п рованию Больше работы по с Больше переработки УК Меньше затрат на сквозной конт- роль кода Меньше работы по созданию заглу- шек рейтинг менений 1ый рейтинг детального про- овторному тести- озданию тестов документации и Гораздо больше исправлений оши- бок системного уровня ,
Высокий рейтинг
Больше затрат труда на верифи- кацию и под- тверждение тре- бований и проек- та изделия Больше первич- ной документа- ции Большая степень п Меньше исправлен ошибок в исправл Больше затрат на сквозной конт- роль проекта Очень выс еречисленных выше и ий ошибок в проекте ениях Меньше исправлены и детальном проекте Меньше ошибок в и< Меньше работы по рованию Меньше работы по с Меньше переработке УК Больше затрат на сквозной конт- роль кода Больше работы по созданию за- глушек экий рейтинг изделия; меньше ошибок в коде вправлениях товторному тести- озДанию тестов документации и Меньше исправле- ний ошибок си- стемного уровня
372
высокий нальный
Рис. 27.2. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ПСП
пяти рейтингов атрибута ПСП. Согласование коэффициентов за-
трат в КОМОСТ и средних значений КПЗ (П, ПСП) (показаны
стрелками) очень хорошее. Поскольку влияние всех остальных ат-
рибутов КОМОСТ устранено, такое согласование характеризует
хорошее влияние практики современного программирования на
производительность разпаботки ПО, по крайней мере, для исполь-
зованной выборки (63 проекта базы данных КОМОСТ).
Обсуждение. Написано большое число работ, указывающих на
значительный рост производительности разработки, достигаемый
за счет внедрения методов современного программирования. В слу-
чае применения ПСП трудно учесть (даже в большей степени, чем
Для других факторов) прирост производительности, вызванный
привлечением более квалифицированных специал истов, применени-
ем лучшего инструментального ПО, улучшением управления. Н.
же представлены результаты обобщения данных по ряду разпа-
боток [40]:
373
Фирма- разработчик Прикладная область Число проектов Среднее число исходных команд, тыс. Среднее значение КУП
IBM Различные <20 2...500 1,67
Hughes Программы реаль- ного времени 2 10 2,00
McAuto 73 Программы обра- ботки документа- ции 2 3 0,69
McAuto 74 Программы обра- ботки документа- ции 4 6 1,25
Снижение производительности (0,69) явилось следствием недо-
статочной подготовки разработчиков и неправильного использова-
ния некоторых методов современного программирования. Коэффи-
циент увеличения производительности в КОМОСТ, равный 1,51,
получен в предположении, что раньше были проведены соответст-
вующие обучение, подготовка и постепенное введение методов
современного программирования.
Впоследствии был проведен более обширный анализ базы дан-
ных фирмы IBM [291]. Приведенные ниже диапазоны изменения
КУП относятся к проектам, при разработке которых каждый из
указанных методов ПСП использовался меньше 66 и меньше 33%
времени разработки:
Структурное программирование ..... 1,78
Сквозной контроль проекта и кода . . . .1,54
Нисходящая разработка......................1,64
Бригада главного программиста..............1,86
На эти данные могут оказывать взаимное влияние все методы
ПСП 1 и несомненно оказывают влияние указанные методы.
Таким образом, приведенные выше цифры, представляют собой
результаты совместного влияния этих четырех методов современ-
ного программирования, которые обычно используются вместе.
Наибольшее изменение производительности при использовании
бригады главного программиста может быть связано также с дей-
ствием другого эффекта: бригады главного программиста чаще ис-
пользуются в разработках малых, а не больших проектов, и произ-
водительность при разработке малых проектов выше (см.
табл. 25.3) [55].
Совсем недавно в работе [66] отмечалось увеличение произво-
дительности разработки ПО за счет применения ПСП в 1,44 раза,
1 Самый последний анализ [52] взаимного влияния данных из работы [291]
свидетельствует о том, что использование ПСП привело к улучшению производи-
тельности как для малых, так и для больших проектов, причем существенно боль-
шее улучшение было достигнуто для больших проектов. Этот анализ показал
также, что использование ПСП уменьшает отрицательное влияние других стоимо-
стных факторов, таких как сложность проекта и ограничения, накладываемые ТО.
в работе [240] — в 1,48 раза, а в работе [119] — в 1,58 раза. В ра-
боте [54] содержится много информации о влиянии различных
методов современного программирования на ряд характеристик
разработки ПО для большого проекта (микроклимат в коллективе,
управление разработкой, сопровождение и т. п.), но нет количест-
венных оценок улучшения производительности. В аналогичном ис-
следовании использования ПСП [33] для пяти проектов приводят-
ся следующие значения отношения фактическая производитель-
ность /оцененная производительность: 1,08; 1,18; 2,31; 5,05 и 6,41,
но не ясно, до какой степени эти результаты обусловлены несовер-
шенством применяемой модели оценивания стоимости.
Результаты опросов об использовании ПСП. Особый интерес
представляют результаты недавнего опроса примерно 800 пользо-
вателей об использовании и оценивании ими методов современно-
го программирования [140]. Отношение пользователей к использо-
ванию различных методов современного программирования харак-
теризуется табл. 27.2, свидетельствующей о том, что структурное
Таблица 27.2
Результаты опроса об использовании отдельных методов
современного программирования
Метод Как вы используете новые методы программирования? Всего ответов
Число ответов
Отвер- гаете Присмат- риваетесь Применя- ете
Бригада главного программиста 134 307 224 665
Сквозная проверка 51 288 307 646
Нисходящее проектирование 43 329 332 704
Структурное программирование Иерархические ввод — обработка — вы- 37 351 412 800
вод 139 278 188 605
Привлечение библиотекаря 109 286 237 532
Интерактивное программирование 86 320 280 686
программирование и нисходящее проектирование наиболее призна-
ны (около 50% пользователей их применяют и менее 10% отверга-
ют) в отличие от методов бригады главного программиста и иерар-
хических ввода — обработки — вывода (около 33% пользователей
применяют и свыше 20% отвергают).
В табл. 27.3 приводятся оценки предполагаемого влияния ПСП
на различные характеристики программного изделия и ЖЦПО. Из
нее следует, что наибольшее влияние ПСП оказывает на качество
кода и раннее обнаружение ошибок. Влияние на производитель-
ность труда программистов и стоимость сопровождения сугубо по-
ложительное, причем примерно в 30% ответов отмечается «значи-
тельное улучшение» и примерно в 50% — «некоторое улучшение».
375
Таблица 27.3
Результаты опроса о влиянии ПСП на характеристики программного
изделия и ЖЦПО
Рассмотрите только те новые методы программирования, которые Вы включил)
в колонку «Применяете» (см. табл. 27 2). Каково их влияние на каждую из
следующих характеристик?
Характеристика Число ответов Всего ответов
Значи- тельное улучшение Некоторое улучшение Не влияет Ухудше- ние
Оценивание проекта или уп- равление им 63 204 206 8 5П
Контакт с пользователями 8! 227 252 3 571
Организационная стабиль- ность 47 193 303 10 553
Точность проектирования 166 297 107 3 573
Качество кода 206 287 94 2 589
Раннее обнаружение ошибок 213 276 87 4 58С
Производительность програм- мистов 165 350 80 6 601
Время или стоимость сопро- вождения 178 272 108 11 569
Микроклимат в коллективе программистов или аналитиков 108 292 160 20 580
Таблица 27.4
Результаты опроса о потенциальном повы'пении
производительности при использовании ПСП
Рассмотрите только те методы, которые вы отметили в кспонке «Применяете»
(см. табл 27.2). Если бы они использовались с максимальной отдачей, а имею-
щийся штат разработчиков продолжал бы заниматься той же работой, то произ-
водительность разработок стала бы:
Ответы Число ответов Всего ответов
Ниже достигнутого уровня 8
Той же самой 152
На 0...10% выше достигнутого уровня 153 658
На 1О...25% выше достигнутого уровня 264
На 25...50% выше достигнутого уровня 82
На 50—100% ьыше достигнутого уровня 18
Более чем в 2 раза выше достигнутого уровня 1
Как показывает табл. 27.4, увеличение производительности в
-соответствии с табл. 27.3 представляет только часть потенциально
достижимого улучшения производительности, обусловленного при-1
менением ПСП. В этой таблице содержится ответ пользователя на I
вопрос: «Какого дальнейшего улучшения производительности
могли бы вы ожидать, если бы использовали выбранные вами ме- I
тоды современного программирования с максимальной целесооб- I
376
разностью?». Результаты показывают, что примерно 40% пользо-
вателей могли бы реализовать увеличение производительности в
диапазоне 10 ... 25%, а примерно 12 —-в диапазоне 25 ... 50%.
В целом результаты обзора согласуются с потенциальным об-
щим ростом производительности на 51%, установленным по 63 про-
ектам базы данных КОМОСТ.
Использование ПСП и упорядочение разработки ПО. Данные
табл. 27.3 о влиянии ПСП на микроклимат в коллективе програм-
мистов и аналитиков (19% — значительное улучшение, 50% —не-
которое улучшение, 28% — не влияет и 3% —ухудшение) должны
быть приятным сюрпризом для ряда лиц, предсказывающих про-
тивоположный результат. В работе [180], например, изложен тезис
(основанный на многочисленных мнениях и относительно малочис-
ленных данных), что внедрение ПСП было бы попыткой руководст-
ва упорядочить работу программистов и подавить в них творче-.
ское начало. Несомненно, были случаи административного введе-
ния ПСП среди программистов, и еще есть необходимость изуче-
ния этого направления внедрения ПСП.
27.2. ИСПОЛЬЗОВАНИЕ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ (ИИС)
Рейтинги и коэффициенты затрат. В табл. 23.3 и на рис. 27.3
приводятся значения коэффициентов затрат на разработку ПО для
различных рейтингов ИИС. Определяются пять рейтингов обеспе-
чения инструментальными средствами:
Очень низкий . Базовые средства микропроцессора
Низкий.................................. Базовые средства мини-ЭВМ
Номинальный.............................Средства мощной мини-ЭВМ или базовые средст-
ва универсальной ЭВМ
Высокий................................ Средства мощной универсальной ЭВМ
Очень высокий ... Средства супер-ЭВМ
Рис. 27.3. Распре-
деление коэффи-
циентов затрат
труда по фазам
для атрибута
ИИС
377
В табл. 27.5 приводится классификация типичных инструмен-
тальных средств, доступных для каждого рейтинга. При определе-
нии эквивалентного рейтинга использования инструментальных
средств, которые могут быть объединением средств, соответствую-
щих разным рейтингам, необходимо обладать определенным уме-
Таблица 27.5
Шкала рейтингов использования инструментальных средств
Очень низкий Ассемблер Базовый компоновщик Средства пакетной отладки
Низкий Компилятор ЯВУ Микроассемблер Простой оверлейный компоновщик Языково-независимый монитор Пакетный редактор исходных текстов Базовые библиотечные средства Основные средства базы данных
Номинальный Операционная система реального времени или разделения времени Система управления базой данных Расширенный оверлейный компоновщик Интерактивные средства отладки Простая библиотека программной поддержки Интерактивный редактор исходного текста
Высокий Операционная система с виртуальной памятью Средства проектирования базы данных Средства анализа и измерения параметров про- цесса выполнения программы Библиотека программной поддержки с базовыми средствами УК Анализатор внедрения .ПО Анализатор схем программ Базовый редактор текстов-
Очень высокий Полная библиотека программной поддержки со средствами УК Полная система комплексного документирования Система управления проектами Язык и анализатор спецификации требований Расширенные средства проектирования Автоматизированная система верификации Средства специального назначения: кросс-компиляторы, эмуляторы систем команд, средства дисплейного форматирования, средст- ва обработки сообщений, средства управления вводом данных, средства преобразования и т. и.
нием. Кроме того, при определении соответствующего рейтинга
ИИС важно уметь разобраться в качестве и степени интеграции
этих инструментальных средств.
В табл. 27.6 представлены изменения в работе над проектом,
обусловленные различными рейтингами ИИС. Наибольшее сокра-
щение затрат за счет применения инструментальных средств на по-
378
Таблица 27 6
Изменения в работе над проектом на разных фазах,
обусловленные использованием инструментальных средств
Анализ требований
и проектирование
изделия
Детальное
проектирование
Кодирование
И автономная
отладка
Комплексирование
и испытания
Очень низкий рейтинг
Больше затрат на моделирование и построение прототипов ------------------►
Больше ошибок в проекте и требованиях; более трудные
их обнаружение и исправление
Больше ошибок в коде и базе дан-
ных; более трудные их обнаружение
исправление
Больше затрат на УК и КК, доку-
ментирование и тестирование
Больше затрат на
компоновку и ис-
пытание подси-
стем
Низкий рейтинг
Средняя степень перечисленных выше лзменений--------------------------->-
Номинальный рейтинг
Без изменений ---------------------------------------------------------►
Высокий рейтинг
Меньше затрат на обработку текстов ------------------------------------►
Более легкие моделирование и построение прототипов ____________________*.
Меньше ошибок в проекте и требованиях; более легкие их
обнаружение и исправление
Сокращенные за-
траты на проекти-
рование (приме-
нение ЯПП)
Меньше ошибок в коде и базе дан-
ных; более легкие их обнаружение и
исправление
Меньше затрат на
компоновку и ис-
пытание подси-
стем
Очень высокий рейтинг
Большая степень перечисленных выше изменений
Меньше затрат на обновление проекта и требований
Меньше затрат на
спецификации про-
екта и требова-
ний
Сокращенные затраты на управление; более быстрое решение проблем управле-
ния
Более легкая реализация функций специального
назначения
следних фазах разработки частично обусловлено более ранним
устранением ошибок и частично — большими количеством и мощ-
ностью инструментальных средств.
379
Сравнение с фактическими данными. На рис. 27.4 приводятся
значения КИЗ (П, ИИС) для проектов базы данных КОМОСТ и
значения коэффициентов полных затрат (показаны кружками) для
пяти рейтингов атрибута ИИС. Для промежуточных рейтингов со-
гласование коэффициентов затрат и средних значений КИЗ (П,
Рис. 27.4. Коэффи-
циенты идеальных
затрат и коэффици-
енты затрат в
КОМОСТ для раз-
личных рейтингов ат-
рибута ИИС
ИИС) (показаны стрелками) очень хорошее. Налицо некоторое
расхождение для крайних (очень высокого и очень низкого) рей-
тингов, но оно основано на слишком малом числе данных, чтобы
стать причиной изменения коэффициентов затрат в настоящее
время.
Обсуждение. Помимо проведенного выше анализа проектов ба-|
зы данных КОМОСТ, к настоящему времени имелось относитель-1
но мало подтверждений влияния инструментальных средств на сто-
имость ПО и производительность его разработки. По шкале —7 ..
...7 такой фактор влияния на производительность разработки ПО.'
как доступность инструментальных средств, в обзоре '[267] оцени*]
вался значением +5. Проверка методом «Дельфы» [39] экономии
потенциальных затрат при использовании инструментальных!
средств (см. [211]) для очень большого проекта, предназначенного
для обработки деловой документации, дала среднюю оценку эко-
номии 17% для разработки и 22% для сопровождения (с разбро-1
380
сом оценки 11 ... 24% для разработки и 10 ... 31% для сопровож-
дения). Различные группы разработчиков ПО, перешедшие в по-
следнее время с проектов микропроцессорного ПО, хорошо осна-
щенных инструментальными средствами универсальных ЭВМ, на
слабо оснащенные проекты, оценили типичную потерю производи-
тельности в 33%.
Для анализа семейства ЭВМ, используемого армией США, по-
строена кривая [279, 280], связывающая производительность раз-
работки ПО и долю доступной программной поддержки. По этой
кривой МКУП = 1,93 при изменении программной поддержки в ин-
тервале 30 ... 70 процентилей и 2,66 — для интервала 20 ... 80 про-
центилей. В работе [279] эта кривая использовалась для оценива-
ния стоимостных атрибутов ЖЦПО и ТО семейства ЭВМ военного
назначения. Возможности базовых инструментальных средств каж-
дой ЭВМ оценивалисп в процентилях (см. табл. 27.7), а вклад
стоимости ЖЦПО определялся по кривой из работы [279].
Производственная функция инструментальных средств. Табли-
ца 27.7 представляет интерес и с точки зрения объема и стоимости
программной поддержки, так как содержит типовую стоимость (в
ценах 1978 г.) поставки промышленных версий каждого средства.
Таблица 27.7
Инструментальные средства в исследовании семейства ЭВМ
военного назначения
Инструментальные средства Стоимость, тыс. долл. Стоимость для данно- го рейтин- га. тыс. долл. Общая стоимость, тыс. долл.
Очень низки Ассемблер Базовый компоновщик Средства пакетной отладки Языково-независимый монитор й рейтинг 135 130 50 50 .365 365
Низкий Макроассемблер Простой оверлейный компоновщик Компилятот ЯВУ Пакетный редактор исходных текстов Языкове- независимый монитор Полная библиотека рейтинг 800 210 1000 100 210 100 2420 2785
Номинальнь Расширенный оверлейный компоновщик Средства интерактивной отладки Интерактивный редактор исходных тек- стов ОС реаль юго времени или разделения времени Система управления ба?ой данных Средства изменения формата 1й рейтинг 500 500 130 3500 4200 100 8930 11715
381
Высокий рейтинг
Средства проектирования базы данных 1150
ОС реального времени, разделения вре-
мени или с виртуальной памятью 2800
Автоматизированные производство и те-
стирование ПО 1000
Средства контроля стандартов 90
Средства проектирования тестов 400
Средства анализа и инструментальные
средства разработки тестов 280
Контр >ллер тестовых данных 140
Генератор тестовых данных 350
Система обработки текстов 630 6840 18 565
Очень высокий рейтинг
Имитатор систем ЭВМ I 420
Имитатор команд 350
Имитатор общецелевых систем 1 700 1470 20 035
Эта информация может, кроме того, использоваться для определе-
ния производственной функции, связывающей уровень улучшения
производительности разработки ПО (по коэффициентам затрат в
Рис. 27.5. Производствен-
ная функция разработки
инструментальных средств
как зависимость увеличе-
ния производительности,
обусловленного тсгэтьзо-
ванием инструмен-альных
соедств, от вложений в их
разработку
КСМОСТ) с уровнем вложений в обеспечение инструментальными
средствами новых ЭВМ (по общей стоимости, увеличенной на оцен-
ку стоимости средств, перечисленных для предыдущих рейтингов).
Такая производственная функция изображена.на рис. 27.5.
Другие инструментальные средства. Производственная функция
инструментальных средств (см. рис. 27.5) включает, помимо базо-
вых средств поддержки, описанных в работе [279] и перечислен-
ных в табл. 27.7, некоторые другие инструментальные средства.
К ним относятся:
средства поддержки процесса разработки ПО типа средств УК;
средства трассировки требований и средства управления [251
252];
средства, расширяющие обслуживание ОС или программ спе-
циального назначения: процессоры таблиц решений, средства фор-
матирования дисплеев, управления данными или поддержки свя-
зи [154];
382
Таблица 27 8
Компоненты полного окружения системы программирования на языке Ада
Уровень окружения Компонент
МОСЛА (соответству- ет высокому рейтингу в КОМОСТ) ПОСЛА (соответствует очень высокому рейтин- гу в КОМиСТ; Редактор текстов Печать «красивого» текста 1ранслятор Компоновщики Загрузчики Анализатор статического использования Средства динамического анализа Подпрограммы обслуживания связи с терминалом Администратор файлов Интерпретатор команд Средства управления конфигурацией Редактор программ на языке Ада Система документации Система управления проектами Система управления конфигурацией Система измерения параметров процесса выполне- ния программы Система отчетов об ошибках Средства спецификации требований Средства проектирования Средства верификации программ (если это возмож- но) Трансляторы Интерпретаторы команд
средства выполнения или обеспечения многих общих програм-
мных функций, таких как функции обработки текстов по фильтра-
ции потоков данных, работа с файлами, сортировка, распознавание
образов, редактирование и форматирование [171].
Эти инструментальные средства способствовали появлению ос-
новной разработки министерства обороны США «Stoneman» [57]
по определению полного окружения системы программирования
на языке Ада. Этот документ основан на концепции единой базы
данных, которая действует как архив всей информации, связанной
с проектом ПО, и соответствующих инструментальных средств,
поддерживающих создание, модификацию, анализ, преобразование,
отображение, связь, выполнение и сопровождение объектов в этой
базе данных.
Полное окружение системы программирования на языке Ада
(ПОСЛА) подразделяется на ряд уровней:
Уровень 0 Базовое аппаратное и программное обеспечение
Уровень 1 Ядро ПОСЛА или БОСПА, которое пре ютав-
ляет базу данных,' обеспечивает связь модулей и
программную поддержку в период исполнения
программ, написанных на языке Ада, а также ис-
пользование программных средств ПОСЛА и
служит интерфейсом меж iy виртуальной маши-
ной и инструментальными средствами более вы-
сокого уровня
383
Уровень 2
Уровень 3
Минимальное ПОСЛА, или МОСЛА, которое
обеспечивает базовые средства, необходимые для
всех разработок программ на языке Ада
Ряд специальных средств, расширяющих
МОСПА
Компоненты, включенные в МОСПА и типичное ПОСПА, пере-
числены в табл. 27.8. Они в достаточной степени соответствуют
используемым в КОМОСТ инструментальным средствам с высо-
ким и очень высоким рейтингами (см. табл. 27.5). Важно подчерк-
нуть, что качество и концептуальная целостность набора инстру-
ментальных средств являются, по крайней мере, столь же важны-
ми, как и количество инструментальных средств в этом наборе.
Хорошие примеры описаний удачно объединенных инструменталь-
ных средств даны в работах [94, 285, 310].
27.3. ОГРАНИЧЕНИЕ СРОКОВ РАЗРАБОТКИ [ОСР]
Рейтинги и коэффициенты затрат. В табл. 23.3 представлены
значения коэффициентов затрат в зависимости от рейтингов огра
ничения сроков разработки, установленных для бригады разработ-
чиков подсистем ПО. Рейтинги определяются как уменьшенные или
ние изделия
Рис. 27.6. Распределение коэффициентов затрат труда по фазам для атрибута
ОСР
увеличенные сроки разработки, выраженные в процентах от но-
минальных сроков разработки проекта. Номинальный срок разра-
ботки проекта определяется уравнениями базовой КОМОСТ:
СР=2,5-ЧМ°-38 (распространенный тип),
СР=2,5-ЧМ°-35 (полунезависимый тип),
СР=^2,5-ЧМ°-32 (встроенный тип),
где ЧМ—число человеко-месяцев от начала фазы проектирования
до конца фазы комплексирования и испытаний; СР (срок разра-
ботки) — соответствующее число месяцев. Уменьшение сроков раз-
384
работки ниже 75% от номинальных в КОМОСТ считается невоз-
можным.
Распределение по фазам коэффициентов затрат для различных
рейтингов атрибута ОСР показано на рис. 27.6.
В табл, 27.9 приводятся отличия в реализации разработки, обус-
ловленные различными рейтингами ограничения сроков разработ-
Таблица 27.9
Изменения в работе над проектом на разных фазах,
обусловленные ограничениями сроков разработки
Анализ требований
и проектирование
изделия
Детальное
проектирование
Кодирование
и автономная
отладка
Комплексирование
и испытания
Очень низкий рейтинг [сильное уменьшение (75%)]
Более короткий период затрат труда на работу (управление) и т. п.
Больше проблем с интерфейсом (больше людей работает параллельно)
Больше нерешенных Больше работы по разрешению отложенных проблем
проблем откладыва- уКОрОЧеннь1й КАП | Большая избыточность тестов
стся на будущее '
Больше исправлений ошибок в спецификациях, ошибок
в исправлениях, больше УК
Большее обеспечение вспомогательным персоналом -------------------------->
Низкий рейтинг [среднее уменьшение (85%)]
Средняя степень перечисленных выше изменений----------------------------->
Номинальный рейтинг (100%)
Без изменений------------------------------------------------------------►
Высокий рейтинг [среднее увеличение (130%)]
Более длительный период затрат труда на работу (управление) и т п.
Более высокая вероятность повторного рассмотрения проблем --------------->.
Более тщательное планирование, под- [ Меньше исправлений ошибок, ошибок
тверждение | в исправлениях, меньше УК
Очень высокий рейтинг [сильное увеличение (^160%)]
Большая степень перечисленных выше изменений----------------------------->
км. При уменьшении сроков разработки (очень низкий и низкий
рейтинги) увеличиваются затраты на последних фазах разработки.
В основном это происходит потому, что из-за нехватки времени на
ранних фазах разработки решение большего количества вопросов
откладывается на последние ее фазы. При увеличении сроков раз-
работки (высокий и очень высокий рейтинги) увеличиваются затра-
ты на ранних фазах, так как имеется больше времени для тщатель-
ного планирования, разработки спецификаций и подтверждения.
13 Зак. 628
385
Сравнение с фактическими данными. На рис. 27.7 приводятся
значения КИЗ (П, ОСР) для проектов базы данных КОМОСТ и
коэффициентов полных затрат (показаны кружками) для пяти
рейтингов атрибута ОСР. Согласование коэффициентов затрат
КОМОСТ и средних значений КИЗ (П, ОСР) (показаны стрелка-
ми) не столь хорошее, как хотелось бы. Это выглядит как строгое
указание на то, что коэффициенты затрат- для атрибута ОСР в
КОМОСТ должны быть выше.
Рис. 27.7. Коэффициенты идеальных затрат и коэффициенты затрат в КОМОСТ
для различных рейтингов атрибута ОСР
Тем не менее без дополнительных или более достоверных дан-
ных по этому вопросу трудно обосновать увеличение коэффициен-
тов затрат в других проектах ПО. Коэффициент полных затрат для
очень низкого (75% от номинального) рейтинга, равный 1,23, по-
лучен в предположении, что средняя нагрузка на человека при
уменьшении срока разработки увеличится в 1,23/0,75=1,64 раза.
Более высокий коэффициент затрат при очень низком рейтинге
ОСР означает, что человек мог бы воспринять даже более высокую
нагрузку, чем увеличенная в 1,64 раза по сравнению с номиналь-
ной. Однако это до крайней степени ухудшило бы возможность
координации различных частей проекта.
Обсуждение. В приведенных таблицах предполагается, что ру-
ководство проекта заранее знает о любом требуемом уменьшении
или увеличении сроков разработки и в состоянии вести планирова-
ние и управление проектом наиболее выгодным, с точки зрения
стоимости, путем по отношению к номинальным срокам разработ-
ки. При увеличении сроков разработки это преимущественно при-
водит к большим затратам времени меньшей группой проектиров-
щиков на тщательные разработку и подтверждение требований к
ПО и спецификаций проекта, составление планов тестирования и
изготовление эскизных руководств для пользователей.
Для уменьшения сроков разработки есть ряд путей, с помощью
которых руководство может добиться некоторого ускорения раз-
работки за счет увеличения стоимости *:
обеспечить сверхподготовку программистов и группы тестиро-
вания к работе в прикладной области, на ЭВМ и с ПО сопровож-
дения;
закупить дополнительное техническое обеспечение (терминалы,
ЭВМ) для обеспечения более быстрого кодирования, контроля и
тестирования;
привлечь сильный вспомогательный персонал;
приобрести автоматизированные средства и обучить разработ-
чиков их использованию;
обеспечить сверхдетальные расчленение программы на модули
и спецификации интерфейса для обеспечения максимального парал-
лелизма в работе;
отложить на время несущественные документирование и тести-
рование.
Тем не менее есть предел сокращению сроков разработки с по-
мощью привлечения большего числа персонала и приобретения
оборудования. Этот предел приходится примерно на 75% номиналь-
ного срока разработки.
Аналогичные данные и исследования. Согласование базовых
уравнений КОМОСТ для сроков разработки с данными по проек-
там и другими уравнениями оценки сроков разработки обсужда-
лось в разд. 6.4.
В работе [243] дается следующая зависимость затрат от ми-
нимального времени разработки 7разр в годах для отдельного про-
екта ПО:
где К — полные затраты в человеко-годах, а с = 14 ... 15. Приве-
дя годы к месяцам и взяв с = 14,5, получим
Тразр = 2,15-ЧМ1/з.
1 Это верно только в начале проекта. Проекты, в рамках которых пытаются
сократить сроки разработки за счет увеличения штата в середине проекта, будут
развиваться по закону Брукса [51]: «Если программный проект не укладывается
в сроки, то добавление рабочей силы только задержит его окончание».
13*
387
Эта формула дает сокращение срока разработки примерно до 86%,
в то время как по формуле КОМОСТ (коэффициент 2,5) получаем
75%.
Анализ других баз данных по проектам, по-видимому, подтвер-
ждает оценку 75% в качестве предела сокращения сроков разра-
ботки (см. рис. 27.8). По данным из работы [243] из 19 точек толь-
Рис. 27.8. Опытные данные по срокам разработки ПО:
О — [291]; □ — [243]; • — [239]
ко одна лежит ниже 75% и дает уменьшение срока разработки
до 68,4%. Из 37 точек данных из работы [29] (которые, по-види-
мому, представляют собой подмножество данных фирмы IBM, про-
анализированных в работе [291]) только две дают сокращение сро-
ков разработки меньше чем до 75% (59% и 46%). Хотелось бы
больше знать о том. как были достигнуты такие сокращения сро-
ков разработки в этих проектах.
На рис. 27.9 показаны изменения сроков разработки для про-
ектов базы данных КОМОСТ. Только четыре из этих 63 проектов
имеют сроки разработки ниже 75%. Главной особенностью, отлича-
ющей эти проекты, являются малые общие затраты на них: 6, 7, 8
® Пошаговая разработка
0,4 0,5 0,6 0,7
XXX
хххххх
0,В 0,9 1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8
Х2.27
Х2.13
®2,22
®2.05
<адо.
0,75
Т /Г
разр"ном
Рис. 27.9. Изменения сроков разработки для проектов базы данных КОМОСТ
388
и 15 ЧМ. Другими их отличительными характеристиками, по-види-
мому; являются невысокие требования к надежности, высокая ква-
лификация персонала и использование ПСП.
Ках показано на рис. 27.10, влияние уменьшения или увеличе-
ния сроков разработки на стоимость представлено рядом функци-
ональных зависимостей. По данным работы [6] уменьшение или
увеличение сроков разработки на X % приводит к такому же уве-
личению стоимости. Аналогичная зависимость для КОМОСТ идет
более полого в области номинального срока разработки и в направ-
лении увеличения сроков, однако при максимально возможном со-
кращении сроков разработки до 75% от номинального дополнитель-
ные затраты достигают максимума в 23%. Зависимость из работы
Рис. 27.10. Относительные -затраты на неноминальные сроки разработки
[249] аналогична зависимости для КОМОСТ, за исключением то-
го, что в соответствии с ней допускается беспредельное сокращение
сроков разработки, приводящее к очень высокой нагрузке на раз-
работчиков. Уравнение зависимости затрат от сроков разработки
[243]
Затраты = с/Тразр
дает чрезмерно высокую плату за сокращение сроков разработки
и чрезвычайно большое сокращение затрат при их увеличении: на-
пример, удваивание сроков реализации проекта, номинально тре-
бующего 100 ЧМ, привело бы к сокращению требуемых затрат до
100/24=6,25 ЧМ. Хотя данные, приведенные на рис. 27.7, и показы-
вают, что относительные затраты могут быть более чувствительны-
ми к относительному ограничению сроков,- чем дают коэффициен-
ты затрат для атрибута ОСР в КОМОСТ, но они совершенно не
подтверждают чрезвычайно высокую чувствительность затрат к
ограничению сроков разработки по данным работ [243].
389
27.4. ТЕМЫ ДЛЯ ДАЛЬНЕЙШИХ ИССЛЕДОВАНИЙ
А. Проверить гипотезу, что шкалы рейтингов ПСП и ИИС достаточно объектив-
ны, чтобы обеспечивать приемлемый диапазон рейтингов стоимостных факто-
ров.
Б. Проанализировать влияние конкретных методов или групп методов современ-
ного программирования на производительность разработки ПО и такие харак-
теристики, как надежность ПО и микроклимат в бригаде разработчиков (см.,
например, [106, 219] по сквозному контролю; [209] по всем методам ПСП;
[61] по методологии изучения потоков ошибок).
В. Проанализировать влияние бригады главного программиста на производитель-
ность разработки ПО и такие характеристики, как надежность ПО и микро-
климат в бригаде.
Г. Определить сверхвысокий рейтинг атрибута ПСП для таких методов, как
«упрятывание» информации, использование формальных спецификаций, абст-
рактного интерфейса, взаимодействующих последовательных процессов, под-
программ синхронизации процессов, мониторов ресурсов [146], эскизных про-
ектов [157] или других методов, которые кажутся существенными. Эксперимен-
тальным путем выявить соответствующие коэффициенты затрат для сверхвы-
сокого рейтинга.
Д. Проанализировать влияние конкретных инструментальных средств на произво-
дительность разработки ПО и Такие характеристики, как надежность ПО (см.,
например, [286]).
Е. Выполнить детальный анализ соотношений сроки — затраты в КОМОСТ,
а также аналогичных соотношений из работ [133, 243, 249].
ГЛАВА 28
ФАКТОРЫ, НЕ УЧИТЫВАЕМЫЕ В КОМОСТ
В этой главе обсуждаются возможные стоимостные факторы
ПО, которые не учтены в КОМОСТ. К ним относятся:
тип применения;
уровень языка программирования;
другие характеристики программ (сложность, сущность, спе-
цификации) ;
изменяемость требований;
сохраняемость штата разработчиков;
качество управления;
качество взаимодействия с заказчиком;
объем документации;
конфигурация технического обеспечения;
ограничения, связанные с секретностью и безопасностью.
Чтобы показать, почему эти факторы не были включены в
КОМОСТ, представим сначала ряд критериев, полезных для оце-
нивания моделей стоимости ПО и их атрибутов.
Критерии оценивания модели стоимости ПО. Перечисленные
ниже критерии наиболее полезны при определении пригодности
модели стоимости ПО для практических целей оценивания.
1. Определенность. Ясно ли определены для модели те затраты,
которые входят в оценку стоимости, и те, которые этой моделью
не учитываются?
2. Точность. Близки ли оценки стоимости действительным за-
тратам на проекты?
390
3, Объективность. Позволяет ли модель не учитывать такие
трудно контролируемые субъективные факторы, как сложность
при выявлении причин изменения стоимости ПО? Другими слова-
ми, трудно ли добиться от модели получения любого желаемого
результата?
4. Конструктивность. Может ли пользователь пояснить, почему
модель дает именно такие, а не иные результаты? Помогает ли это
пользователю понять работу, выполняемую ПО?
5. Детальность. Легко ли приспосабливается модель к оцени-
ванию программной системы, состоящей из ряда подсистем и бло-
ков? Дает ли она (точное) распределение стоимости по фазам и
видам работ?
6. Устойчивость. Приводят ли малые изменения входных дан-
ных к малым изменениям полученных оценок стоимости?
7. Область применения. Распространяется ли модель на про-
екты ПО, стоимость которых Вам нужно оценить?
8. Простота применения. Достаточно ли просто понять и точно
определить входные данные для модели и работу с ней?
9. Предсказуемость (оабота с неполной информацией). Позво-
ляет ли модель избежать использования информации, которая не
будет хорошо известна до завершения проекта ’?
10. Экономичность. Позволяет ли модель избежать использова-
ния сильно избыточных факторов или факторов, не оказывающих
ощутимого влияния на результаты?
Значение большей части приведенных критериев достаточно
очевидно, однако в разд.’29.8 и работе [43] проводится более под-
робное обсуждение.
Под критерием экономичности подразумевается исключение не-
которых факторов из КОМОСТ, даже несмотря на то, что они иг-
рают существенную роль в определении стоимости проекта. Было
принято решение не учитывать такие факторы (так же как и в
случае необычных значений учитываемых факторов), т. е. сохра-
нить КОМОСТ простой и не пытаться учесть в этой модели нестан-
дартные ситуации. Как правило, если возникнет ситуация подобно-
го рода, то лучше положиться на дальнейший анализ особенностей
проекта, чем на способность общей модели объяснить эту си-
туацию.
28.1. ТИП ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Для большинства моделей оценивания стоимости ПО в качест-
ве стоимостного фактора используются типы ПО, классифицируе-
мые, например, следующим образом:
программы управления, программы ввода-вывода, препроцес-
соры и постпроцессоры, программы управления данными, програм-
мы разделения времени [313];
* Ясно, что этот критерий характерен для цели предсказания стоимости. Для
Других целей, таких как оценивание влияния технологии, могла бы подойти рет-
роспективная модель.
391
вычислительные программы, генераторы отчетов, логические
программы, программы обработки сигналов, программы реального
времени [33].
Попытка учесть такой стоимостный фактор в КОМОСТ была
сделана, но рассматривать ее как удачную было нельзя по следу
ющим причинам:
трудности в точном определении типа ПО (например, все вы-
числительные программы содержат некоторые логические, управ-
ляющие команды или подпрограммы управления данными (см.
рис. 21.2));
наложение других факторов КОМОСТ (таких как сложность,
ограничение по быстродействию и размер базы данных) затрудня-
ет использование мультипликативной модели без двойного учета
их влияния;
трудности в достижении какого-либо соглашения среди опыт-]
ных сотрудников об относительном уровне трудности разработки в
зависимости от типа ПО (некоторые считают вычислительные про-
граммы очень легкими, а другие — очень трудными).
В результате такой фактор, как «тип программного обеспече-
ния» (ТПО), был аннулирован, хотя некоторое его влияние сохра-
нилось в четырех шкалах рейтинга сложности,, не зависящего от
типа ПО, приведенных в табл. 8.4.
Сравнение с фактическими данными. На рис. 28.1 приводятся
значения КИЗ (П, ТПО) для шести типов проектов ПО базы дан-
392
ных КОМОСТ: обработки деловой документации, управления, че-
ловеко-машинного взаимодействия, вспомогательные, научные и
системные.
Исходя из средних значений КИЗ (П, ТПО) (стрелки на
рис. 28.1), можно было бы сделать вывод о том, что КОМОСТ не-
много переоценивает деловое и вспомогательное ПО и немного не
дооценивает ПО управления и человеко-машинного взаимодейст-
вия, чо по сравнению с отклонениями данных по проектам каждо-
го типа это не может служить основанием для того, чтобы в даль-
нейшем отказаться от учета фактора ТПО в КОМОСТ в соответст-
вии с критерием экономичности модели.
28.2. УРОВЕНЬ ЯЗЫКА ПРОГРАММИРОВАНИЯ
В ранней версии КОМОСТ в качестве базового параметра раз-
мера ПО использовался параметр выполняемые машинные коман-
ды (ВМК). В настоящей версии используется параметр число
исходных команд (ЧИК), выбор которого обусловлен следующими
основными причинами:
выяснилось и было подтверждено [224, 291], что число исход-
ных команд сильнее скоррелировано с полными затратами, а объ-
ем затрат на один оператор исходного языка слабо связан с уров-
нем языка программирования (ЯП). (Эта точка зрения обсуждает-
ся далее в разд. 33.4);
в настоящее время подавляющее число специалистов считает
более естественным оценивать размер ПО в ЧИК, а не в ВМК-
Учитывая широкий разброс коэффициента расширения поограммы
(число ВЛ’.К на одну выполняемую исходную команду) в зависи-
мости от языка, ЭВМ и типа ПО, гораздо лучше пользоваться не-
посредственно понятием ЧИК, чем вводить дополнительный источ-
ник разброса результатов оценивания из-за оценивания числа вы-
полняемых исходных команд и использования некоторого предпо-
лагаемого коэффициента расширения для определения числа ВМК,
которое должно использоваться в модели. В табл. 28.1 приводятся
Таблица 28.1
Коэффициент расширения по данным трех раоот
Язык (64] 1313] 1249]
Фортран 6...7 : 1 4...6 : 1 4...8 : 1
Кобол 5:1 4...6 : 1 2.5...3.5 : 1
ПЛ/1 5: 1 — 7,5... 13 : 1
П асктль 8:1 5.. 7: 1 3...5 : 1
АПЛ 12: 1 .
ПЛ/S 2,5: 1 — —.
Джовиал и 3...5: 1 3...5 1
Си 3: 1
CMS-2 — — 2.5...3.5: 1
393
некоторые типичные значения и диапазоны изменения коэффици-
ентов расширения. Отличие данных работ [291] и [313], вероятно,
объясняется тем, что в работе ([313] ПО содержит больше про-
грамм, ориентированных на машины с длиной слова более 32 бит,
а также более мощной системой команд. С учетом развития ПО
для мини-ЭВМ и микро-ЭВМ, написанного на языке высокого
уровня (ЯВУ), следовало бы, вероятно, считать средний коэффи-
циент расширения превышающим коэффициенты расширения, при-
веденные в [291] *;
Рис. 28.2. Коэффициенты идеальных затрат для различных языков программи- I
рования
использование параметров ВМК затрудняет учет относитель-
ных затрат, требуемых для описания данных, операторов форма-
тирования и других невыполняемых частей программы. Введение
понятия полных машинных слов, составляющих программу, стира-
ет грань между программами с большими областями простых дан-
ных и программами с областями более сложных данных и команд.
Использование понятия общего числа исходных команд в качестве ।
базового приводит к минимальным аномалиям в соответствии раз-
мера программы количеству интеллектуальных и административ-1
ных усилий, требующихся для ее разработки.
Сравнение с фактическими данными. На рис. 28.2 приводятся
значения КПЗ (П, ЯП) для проектов базы данных КОМОСТ, раз-
1 Кроме того, по мере развития прямого или интерпретируемого выполнения
программ, написанных на ЯВУ, параметр ВМК становится все более туманным. I
394
деленных в зависимости от используемого языка программирова-
ния: язык ассемблера, Фортран, Кобол, Джовиал, ПЛ/1, Паскаль
и другие ЯВУ.
Исходя из средних значений КИЗ (П, ЯП) (стрелки на
рис.28.2), можно было бы предположить, что КОМОСТ несколько
переоценивает ПО, написанное на языке ассемблера и Коболе, но
этого еще недостаточно, чтобы модифицировать саму модель.
Анализ этого явления позволил установить устойчивую пере-
оценку программ, написанных на Коболе. Эта аномалия явилась
следствием большого числа исходных команд, обусловленного
включением большого числа часто избыточных, невыполняемых
исходных операторов. В настоящее время такое положение в
КОМОСТ исправляется тем, что треть исходных операторов языка
Кобол считаются невыполняемыми.
28.3. ДРУГИЕ ХАРАКТЕРИСТИКИ ПРОГРАММ: СЛОЖНОСТЬ, СУЩНОСТЬ,
СПЕЦИФИКАЦИИ
Многие критикуют использование так или иначе подсчитанного
числа команд в качестве характеристики программы, используемой
для оценивания стоимости ПО. Аргументацией служит аналогия с
попыткой оценить стоимость автомобиля по его общей массе или
общему количеству деталей, из которых он состоит. Один из под-
ходов к оцениванию стоимости ПО состоит в привлечении ряда
факторов, которые помогут установить относительную трудность
разработки различных видов команд или групп команд (модулей):
модули, ограниченные по памяти, сложные вычислительные моду-
ли и т. п. Такой подход, учитывающий «веса» команд, принят в
КОМОСТ.
Другой подход состоит в использовании иных, чем число команд,
характеристик. Несколько таких характеристик были опробованы,
но, как правило, их использование приводит к еще более сложным
проблемам нечувствительности оценок стоимости ПО, чем исполь-
зование числа команд. Некоторые характеристики рассматрива-
ются ниже.
Меры сложности. Такие меры являютс i попыткой определить
некоторые более фундаментальные характеристики программ ЭВМ,
которые будут служить основой для предсказания стоимости, тре-
буемой для разработки этих программ. Основными мерами слож-
ности в настоящее время являются:
1. Мера Холстеда [141]:
V—(Nt + Лг2) log2 (t]i +Т]2).
где т)1, т)2 — число уникальных операторов и операндов в програм-
ме соответственно; Jvb N2— общее число операторов и операндов
в программе соответственно.
Уравнение затрат Холстеда выглядит следующим образом:
Затраты — .
36Ч2
395
2. Цикломатическая мера Маккейба i[196]:
V=e—n-f-2 р,
где е, п и р — параметры графа управления программы: е — число
ребер (связей), п — число вершин (узлов), р — число связанны-
компонентов программы.
Была проделана определенная работа для установления связи
этих мер с количеством затрат, требуемых для разработки или со-
провождения программы [73, 77, 78, 102, 142, 209, 282]. В основ-
ном результаты показали (особенно для меры Холстеда), что:
имеется достаточнс хорошая связь между каждой мерой и чи-
слом команд в программе;
отсутствуют какие-либо данные о значительном превосходстве
какой-либо из этих мер' над характеристикой «число команд» при
предсказании затрат на разработку больших (более 1000 ЧИК)
программ *.
Обе эти меры нечувствительны к таким факторам, как личный
опыт, ограничения на ТО, а также использование инструменталь-
ных средств и практики современного программирования, а ведь
все они оказывают существенное влияние на затраты по разработ-
ке ПО. Кроме того, эти меры мало знакомы людям, непосредствен-
но занятым оцениванием размеров программы и, как правило, тре-
буют привлечения атрибутов программы, которые плохо известны
до окончания этапа кодирования. Таким образом, при рассмотрении
трех основных критериев пригодности модели оценивания стоимо-
сти ПО — экономичности, простоты применения - и предсказуемо-
сти — в КОМОСТ выбрана характеристика «число команд», а не
какая-лиСо из рассмотренных мер.
Число программных понятий. Предпринимались некоторые по-
пытки использовать в качестве характеристики программ при оце-
нивании стоимости их разработки число программных понятий
(подпрограмм, записей, входных и выходных данных, файлов). Ни
одна из этих попыток большого успеха не имела, в основном, из-за
неточности используемой терминологии:
не делается попыток провести грань между малым и большим,
между простым и сложным применительно к таким понятиям, как
подпрограмма, запись и т. д.;
отсутствуют хорошие, точные определения того, что входит в
понятие подпрограммы, записи и т. д.
Таким образом, на практике любое из этих понятий (скажем,
подпрограмма) может быть подразделено на несколько понятий
(или любая группа подпрограмм может быть переопределена как
самостоятельная подпрогпамма) способом, существенно влияющим
на характеристики программ, причем объем работы, которую не-
1 Тем не менее, некоторые последние исследования показали, что меры Холсте-
да и Маккейба значительно лучше, чем ЧИК, скоррелированы с количеством
времени работы за терминалом (исключая не связанное с терминалом время об-
думывания), требуемого для программирования малых (10 .... 40 ЧИК) про-
пимм [270].
396
обходимо выполнить для разработки ПО, практически не меняется.
Поэтому по отношению к таким критериям пригодности модели,
как определенность и объективность, использование числа этих по-
нятий в качестве характеристики программы при оценивании стои-
мости ее разработки менее чем удовлетворительно.
Тем не менее для разработок с весьма универсальным спект-
ром применения эти понятия могут дать некоторое полезное пред-
ставление о предварительной оценке затрат на разработку ПО.
Наилучшей работой в этом направлении является работа [8], в
которой предложен подход, основанный на использовании меры
Рис. 28.3. Корреляция числа исходных строк кодовой программы и затрат на
разработку ПО
«точка функции», являющейся линейной комбинацией чисел вхо-
дов, выходов, запросов и файлов. ч
Число элементов спецификаций. Некоторые работы были по-
священы установлению связи между объемом затрат на разработ-
ку ПО и числом элементов спецификаций, таких как:
параграфы в спецификации требований на ПО;
вхождения слова «должно» в спецификации требований на ПО;
строки языка проектирования программ в спецификации про-
екта ПО;
элементы структурных диаграмм или блок-схем иерархических
ввода — обработки — вывода в спецификации проекта ПО.
Эти попытки привели к тем же проблемам, связанным с неточ-
ностью используемой терминологии, что и для понятий «число под-
397
программ, записей и т. д.». Данная характеристика не использова-
лась в КОМОСТ и с точки зрения удовлетворения таким критери-
ям пригодности модели, как определенность и объективность.
Применение «числа исходных команд* для оценивания размера
программы. Дальнейшее обоснование использования «числа исход-
ных команд» в качестве базовой характеристики при оценивании
стоимости ПО приводится на рис. 28.3, свидетельствующем о силь-
ной корреляции между числом исходных строк кодовой программы
(ЧИСК) и общим числом человеко-месяцев, потребовавшимся на
разработку ПО (коэффициент корреляции А?=0,85). Соответству-
ющая выборка данных для более чем 400 проектов взята из базы
данных, описанной в работе [224]. Хотя такие характеристики, как
ЧИСК и общее число человеко-месяцев, имеют широкий разброс
для выборки данных, приведенной на рис. 28.3, объем выборки при-
дает гораздо больше уверенности в правильности использования в
качестве характеристики программы при оценивании стоимости ПО
именно ЧИСК или ЧИК, а не какой-либо альтернативной харак-
теристики.
Конечно, следует быть осторожным, чтобы не ввести разработ-
чиков в соблазн писать больше строк кода, чем того требует при-
менение изделия. Вообще, общее стремление ускорить выполнение
работы плюс такая практика, как установление бюджета опера-
тивной памяти и тщательная проверка кода, минимизируют пред-
намеренное увеличение кода с целью получения завышенных цифр
производительности. Тем не менее широкий разброс количества
строк кода по отношению к поставленным целям, продемонстриро-
ванный в работе [298] и описанный в разд. 21.4, свидетельствует
о легкости, с которой может расти число строк кода для реализа-
ции одной и той же функции.
28.4. ИЗМЕНЯЕМОСТЬ ТРЕБОВАНИЙ
Изменяемость требований (ИТ), или количество изменений в
требованиях к ПО между началом и концом работы над проектом,
является существенным фактором, влияющим на стоимость ПО.
Например, для одной разработки ПО системы радарного обнару-
жения [263] стоимость ПО возросла в 4 раза из-за того, что ПО
должно было разрабатываться заново в связи с изменением требо-
ваний к нему. В этом примере ПО, которое было разработано до
того, как радар был точно описан, имело коэффициент повторной
разработки 318% (33 тыс. команд было разработано и 105 тыс.
команд пришлось аннулировать) из-за изменений во взаимодейст-
вии с радаром и в требованиях к обработке данных.
Ранняя версия КОМОСТ включала фактор изменяемости тре-
бований для учета влияния повторной разработки ПО, Однако это
сделало конечные оценки чрезвычайно чувствительными к весьма
субъективно и неточно определяемому параметру, значение которо-
го не было известно до завершения всего проекта. В дальнейшем
из-за затруднений, связанных с критериями объективности, опреде-
398
Ленности и предсказуемости, этот фактор из КОМОСТ был исклю-
чен. Таким образом, оценка по КОМОСТ предсказывает число че-
ловеко-месяцев, требуемых для разработки ПО и определяемых
текущими спецификациями требований. При изменении требований
спецификация и оценка стоимости могут и должны быть пересмо-
трены *.
Таблица 28.2
Коэффициенты затрат при изменяемости требований
Рейтинг Переработка проекта, обусловленная изменением требований Коэффициент затрат
Низкий Номинальный Высокий Очень высокий Сверхвысокий Без существенной переработки Малые, некритичные изменения направ- лений работы Средние, случайные изменения направ- лений работы Частые средние или случайные глобаль- ные изменения направлений работы Глобальные, частые изменения направ- лений работы 0,91 1,00 1,19 1,38 1.62
Сравнение с фактическими данными. В настроенной версии
КОМОСТ пока еще сохраняется фактор изменяемости требований,
служащий для нормализации проектов, в процессе разработки ко-
торых были отклонения от среднего уровня изменяемости требо-
ваний.
Коэффициенты затрат, используемые для учета изменяемости
требований при настройке по законченным проектам, представле-
ны в табл. 28.2. Эти коэффициенты по фазам не изменяются.
На рис. 28.4 приводятся значения КПЗ (П, ИТ) для проекта
базы данных КОМОСТ и значения коэффициентов затрат в КО-
МОСТ (показаны кружками). Согласование коэффициентов за-
трат в КОМОСТ и средних значений КИЗ (П, ИТ) (показаны
стрелками) достаточно хорошее, хотя есть некоторое указание на
то, что коэффициенты затрат в КОМОСТ могли бы быть несколько
меньше.
28.5. СОХРАНЯЕМОСТЬ ШТАТА РАЗРАБОТЧИКОВ
Первоначально сохраняемость штата разработчиков (СШРЪ
предполагалось включить в КОМОСТ. Однако в итоге этого не
произошло по следующим основным соображениям:
трудно точно определить такой фактор, учитывая, что во многих
проектах предполагается запланированная смена штата, связан-
1 Определенная изменяемость требований неизбежна. Например, по данным
выборки около 1 000 000 команд ПО, разработанного в течение года по требова-
ниям фирмы IBM, было установлено, что в среднем проект во время работы над
ним претерпевает 25 % изменений в требованиях к ПО [64].
399
ная с этапностью работы, использованием специалистов, привле-
чением временного персонала и т. п.;
возникают примерно аналогичные проблемы удовлетворения
критерию предсказуемости, как и в случае использования фактора
изменяемости требований, поскольку нелегко заранее предсказать
критичность проблем текучести кадров;
неожиданно, но подавляющая часть данных для проектов базы
данных КОМОСТ указывает на среднюю текучесть кадров, сильно
Рис. 28.4. Коэффициенты идеальных затрат в КОМОСТ для различных рейтин-
гов фактора ИТ
затрудняя установление влияния этого фактора на стоимость ПО.
Таким образом, при оценивании по КОМОСТ предполагается,
что проект (аналогично большинству проектов) будет иметь сред
нюю текучесть кадров и что любой, необычный в этом смысле про-
ект, будет вносить свои собственные корректировки в оценки по
КОМОСТ. Одним из способов реализации такой корректировки
служит использование рейтингов атрибутов КА и КП, которые дол-
жны отражать реальные возможности бригады разработчиков.
Сравнение с фактическими данными. На рис. 28.5 приводятся
значения КИЗ (П, CHIP) для проектов базы данных КОМОСТ при
низком, номинальном и высоком рейтингах сохраняемости штата
400
разработчиков. Средние значения КИЗ (П, СШР)(стрелки на
рис. 28.5) показывают значительно меньшие отклонения от 1,0,
чем можно было бы ожидать Основное объяснение этого заключа-
ется в том, что большая доля влияния фактора СШР учитывается
Рис, 28.5. Коэффициенты идеальных затрат для различных рейтингов фактора
СШР
в рейтингах атрибутов КА и КП. Это мешает сделать какой-либо
вызод о влиянии СШР по рис. 28.5. В то же время общий опыт
работы над проектами показывает, что этот фактор гораздо более
критичен, чем это следует из рис. 28.5.
►28.6. КАЧЕСТВО УПРАВЛЕНИЯ
Плохое управление может увеличить стоимость ПО быстрее лю-
бого другого фактора. Каждое из приводимых ниже дезорганизую-
щих действий часто приводит к удваиванию стоимости разработки:
L подбор для работы над проектом слабых специалистов или не-
правилоное их сочетание;
[ дублирование поставленных задач или уменьшение числа испол-
нителей, усложняющее решение задач;
дезорганизация штата необоснованно плохими условиями тру-
да и недостатки в вознаграждении за хорошую работу;
привлечение большого числа людей для работы над проектом
С Е четкого распределения их обязанностей;
401
недостатки в обеспечении необходимыми ресурсами (машин-
ным временем, терминалами, линиями связи, тестовыми данными,
вспомогательным ПО);
недостатки в утверждении требований к ПО и спецификаций
проекта, а также в раннем выяснении и разрешении вопросов, свя-
занных с высокой степенью риска.
Несмотря на большой разброс стоимости1, в КОМОСТ не ис-
пользуется фактор качества управления, но вместо этого предпола-
гается, что оцениванию подвергается хорошо организованный про-
ект. Это сделано по следующим главным причинам:
рейтинги качества управления нелегко определить;
качество управления трудно предсказуемо заранее. Если из-
вестно, что кандидат на роль руководителя проекта плох, следует
подыскать другого;
порочной является практика поддержки плохого руководителя
путем предоставления ему дополнительных ресурсов для заверше-
ния работы по сравнению с теми, что получил бы хороший руко-
водитель;
наиболее важно то, что предсказания качества управления и
стоимости могут оказаться самовыполняемыми. В КОМОСТ пред-
полагается, что работа над проектом будет хорошо организована,
и поэтому в помощь руководителю проекта будут предоставлены
средства и стандарты высшего качества для обеспечения хорошего
качества управления и получения оценки стоимости проекта по
КОМОСТ (см. гл. 32).
Сказанное здесь не освобождает руководство от заботы о под-
боре кадров. Для хорошо организованных проектов оценка по
КОМОСТ содержит определенный резерв, так как модель настрое-
на не по идеальным проектам.
28.7. КАЧЕСТВО ВЗАИМОДЕЙСТВИЯ С ЗАКАЗЧИКОМ
Слабое руководство со стороны заказчика ПО или плохое вза-
имодействие заказчика и разработчика также могут вызвать боль-
шое увеличение стоимости ПО. Каждое из следующих действий
заказчика часто приводит к удваиванию стоимости ПО:
предложение слишком быстрого графика работ (см. гл. 27),
который может вынудить к использованию большого штата разра-
ботчиков до того, как работа станет понятной;
нежелание заблаговременно определить требования к ПО или
рост непонимания между заказчиком и разработчиком, что вызо-
вет разработку неправильного изделия;
частое изменение направлений работы над проектом, вызванное
необходимостью изменений требований к ПО, взаимодействия за-
1 В настоящее время отсутствуют исследования, позволяющие установить
влияние качества управления на производительность. Одной из причин этого яв-
ляется то, что для плохо организованных проектов редко удается получить до-
статочно данных об опыте их разработок.
402
казчика и разработчика, используемых средств или штата разра-
ботчиков.
Несмотря на возникающие при этом отклонения в стоимости,
фактор качества взаимодействия с заказчиком в КОМОСТ не вклю-
чается по той же основной причине, что и для фактора качества
управления: это могло бы привести к негативным самовыполняе-
мым предсказаниям и вознаграждению за плохую работу.
28.8. ОБЪЕМ ДОКУМЕНТАЦИИ
Документация во всех своих формах содержит большую долю
общей стоимости ПО. Анализ, проведенный в разд. 31.6, показы-
вает, что примерно 51 ... 54% работы над проектом имеет своим
непосредственным конечным продуктом некоторую документацию,
и только 34% —код. Тем не менее, очень трудно ввести для оцени-
вания стоимости такой фактор, как объем документации, что обу-
словлено следующими причинами:
большое количество проектной документации, такой как хоро-
шие спецификации и планы тестирования, в действительности ве-
дет к экономии средств;
автоматизированные средства (генераторы перекрестных ссы-
лок, диаграммы пстоков, генераторы отчетов) могут давать боль-
шой объем документации при малых затратах на чее;
обилие документации плохого качества можно получить гораздо
дешевле, чем малые объемы хорошей документации;
документация в действительности не самостоятельна, а явля-
ется неотъемлемой частью хорошей практики разработки ПО.
По этим причинам фактор объема документации в КОМОСТ не
включен. Однако некоторое влияние документации в КОМОСТ
все-таки учитывается:
предварительная документация (ранние проработки планов про-
екта, спецификаций, руководств) включается в базовый ЖЦПО
(см. разд. 4.4) и учитывается в оценках затрат на ранних фазах
разработки;
в распределениях работ, приведенных в табл. 7.1, 7.2, 7.4,
{учитываются затраты, требуемые на разработку руководств по
применению, эксплуатации и сопровождению.
В разд. 31.6 проводится дальнейшее обсуждение оценивания
объема документации.
28.9. КОНФИГУРАЦИЯ ТЕХНИЧЕСКОГО ОБЕСПЕЧЕНИЯ
Влияние конфигурации ТО на стоимость ПО в большой степени
учитывается в следующих атрибутах:
в ИИС (табл. 23.3 и 27.6) учитывается влияние вспомогатель-
ного ПО для двух тдоов ЭВМ (ТЭЗМ): мини- и микро-;
в ИВМ (табл. 23.3) учитываемся влияние нестабильного или не-
надежного базового аппаратно-программного обеспечения;
в СИЗ (табл. 23.2 и 8.4) учитывается влияние, обусловленное
Дополнительной сложностью систем распределенной обработки.
403
Сравнение с фактическими данными. На рис. 28.6 приводятся
значения КИЗ (П, ТЭВМ) по проектам базы данных КОМОСТ для
четырех типов ЭВМ: микро-, мини-, средних и универсальных. За
исключением малой выборки по проектам для микро-ЭВМ, средние
значения КИЗ (П, ТЭВМ) (показаны стрелками) достаточно близ-
ки к 1,0, чтобы исключить конфигурацию ТО как дополнительный
фактор КОМОСТ.
23.10. ОГРАНИЧЕНИЯ, СВЯЗАННЫЕ С СЕКРЕТНОСТЬЮ И БЕЗОПАСНОСТЬЮ
Секретность и безопасность информационных систем могут на-
лагать дополнительные ограничения на разработку ПО, которые
ведут к увеличению его стоимости. Некоторые из них уже учтены в
существующих атрибутах КОМОСТ:
в ЦО (табл. 23.3) учитывается влияние ограниченного доступа
в ЭВМ;
в ТНПО (табл 23.3) учитывается влияние повышенных требо;
ваний к надежности ПО
Некоторые другие ограничения в стандартных атрибутах КО-
МОСТ не учитываются:
ограничения, налагаемые дополнительными требованиями к из-
делию (наличие грифа секретности, обеспечение функционального
контроля);
404
ограничение доступа к документации и дополнительное управ-
ление этой документацией.
Так как дополнительные ограничения в жесткой форме относи-
тельно редки (но даже и в случае их действия увеличение стоимо-
сти составляет, как правило, только 10% проектной стоимости), то
они в КОМОСТ не учитываются для обеспечения экономичности
модели. В случае исключительных проектов с жесткими ограниче-
ниями на безопасность или секретность для учета этих факторов в
стоимости следует предусматривать увеличение затрат на 5 ...
...10%.
ГЛАВА 29
ОЦЕНИВАНИЕ КОМОСТ
29.1. ВВЕДЕНИЕ
В этой главе КОМОСТ оценивается по рассмотренным в гл. 28
критериям оценивания стоимостной модели ПО. В ней также пред-
лагается методика освоения КОМОСТ. Для оценивания точности
КОМОСТ используются данные 63 завершенных проектов ПО и
проводится сравнение оценок для этих проектов, полученных с по-
мощью базовой, промежуточной и детальной КОМОСТ, с фактиче-
скими данными по затратам, срокам, распределениям по фазам и
работам. Так как промежуточная и детальная КОМОСТ характе-
ризуются каждая семнадцатью параметрами (размером, типом и
пятнадцатью стоимостными атрибутами), то 63 выборки представ-
ляют собой обоснованный тест на достоверность модели. Однако,
так как каждый параметр зависит от коэффициентов затрат для
различных рейтингов и многие из указанных выборок используют-
ся для настройки модели, важно иметь также некоторую информа-
цию о последовательности работ, проводимых для настройки и оце-
нивания КОМОСТ, а также получения прогностических оценок.
Настройка и оценивание КОМОСТ. Первоначальная версия
КОМОСТ была основана на обзоре существующих моделей стои-
мости, опыте работы по двухуровневому методу «Дельфы», в кото-
рой участвовало 10 руководителей программных проектов, оцени-
вавших коэффициенты затрат для различных стоимостных атрибу-
тов, и на опыте работы с моделями, описанными в работе [289].
Первоначальная модель КОМОСТ настраивалась только на про-
стых видах разработок ПО и опробовалась на 12 сложных проек-
тах. Окончательная модель была оценена по 36 совершенно оди-
наковым образцам проектов, предназначавшихся главным образом
для аэрокосмических исследований, и показала хорошее совпадение
оценок и фактических данных.
Однако расширение базы данных до 50, а затем и до 56 проек-
тов показало на недостаточность использования простых видов раз-
405
работок для объяснения различий между проектами. Тогда были
разработаны три вида модели, опробованные на 56 проектах, что
в итоге потребовало незначительной корректировки коэффициен-
тов затрат. Впоследствии в базу данных были добавлены еще
7 проектов (1979 г.). Дальнейшего оценивания КОМОСТ больше не
проводилось.
Статистический анализ. Настройка и оценивание КОМОСТ сла-
бо опираются на методы статистических исследований. Попытка
применения этих методов к оцениванию стоимости ПО и рассмо-
трение аналогичных попыток других исследователей показали, что
программирование является слишком простым, а зависимость сто-
имости ПО от исследуемых факторов — слишком сложной, чтобы
стандартные статистические методы могли обеспечить значительное
улучшение результатов, и что наилучшие результаты могут быть
достигнуты использованием эмпирических подходов при построе-
нии функциональных зависимостей, которые лучше всего отража-
ют природу взаимосвязи стоимостных атрибутов и позволяют опре-
делить характеристики жизненного цикла программного обеспе-
чения.
Здесь будет уместен пример. При анализе набора из 88 моду-
лей программного изделия [289] была предпринята попытка срав-
нить производительность, измеряемую в ЧИК/ЧМ, с ее оценками
для сложных модулей и различных возможностей программистов.
Обнаружены значительная отрицательная корреляция между про
изводительностью и сложностью, значительная положительная кор-
реляция между производительностью и рейтингом возможности и
отсутствие какой-либо корреляции между сложностью и рейтингом
возможности.
Дальнейшие исследования показали, что главная причина со-
стояла в приписывании экспертами больших возможностей испол-
нителям, работающим с более сложными модулями, а не наоборот.
После обнаружения этого были определены понятие взвешенной
команды (число команд, умноженное на относительный рейтинг
сложности) и соответствующее понятие взвешенной производитель-
ности и получена прекрасная корреляция между взвешенной про-
изводительностью и рейтингом сложности. От этого простого по-
нятия взвешенной производительности довольно просто перейти к
понятию взвешенной производительности, входящей в коэффициент
идеальных затрат, определенный в разд. 24.1.
Таким образом, статистический анализ используется здесь толь-
ко в представлениях средних значений и стандартных отклонений.
Однако КОМОСТ и ее база данных представляют собой заманчи-
вые объекты для исследования методом статистического анализа.
29.2. БАЗА ДАННЫХ КОМОСТ
В табл. 29.1 приведены характеристики 63 проектов базы дан-
ных КОМОСТ и их относительные оценки по КОМОС Г.
406
Таблица 29.1
База данных КОМОСТ
Атрибуты изделия Атрибуты ЭВМ
PN Type Year I ANG RELY DATA CPIX AAF TIME STOR VIRT TURN TYPE
1 BUS 72 COB B8 1 16 70 1.0 1.0 1.06 1.15 1 07 MAX
2 BUS 76 COB 88 1 16 85 85 1.0 1.06 1 0 1.07 MAX
3 BUS 77 PLI 1 0 1.16 85 1.0 1.0 1.0 87 .94 MID
4 BUS 79 COB 75 1 16 70 .76 10 1.0 87 to MID
5 BUS 69 FTN 88 94 10 1.0 1.0 1.0 87 1 0 MAX
6 BUS 74 PLI 75 1 0 85 1.0 1.0 1 21 1 0 1.0 MID
1 BUS 79 COB 75 1 0 1 0 1.0 1 0 1 0 87 87 MAX
В CTL 73 MOL 1.15 94 1.30 1.0 166 1 56 1 30 1 0 MIN
9 CTL 78 FTN 1 15 94 130 1.0 1 30 1 21 1 15 1 0 MIN
to CTL 75 MOL 1 40 94 1 30 63 111 1 56 1 0 1 07 MIN
11 CTL 76 MOL 1 40 94 1 30 63 1.11 1 56 1 0 1 07 MIN
12 CTL 78 JOV 1.15 94 1.30 1 0 1.11 1 06 1 0 1 0 MIN
13 CTL 7B FTN 1.15 94 1 30 96 111 106 1 15 1 0 MID
14 CTL 77 MOL 1 15 94 1.65 1.0 1 30 1 56 1 15 1 0 MIC
15 CTL 76 MOL 1.40 94 1 30 1.0 1 30 1 06 1 15 87 MIN
16 CTL 75 MOL 1 40 10 1 30 60 1 30 1.56 1.0 87 MIN
17 CTL 77 MOL 1.40 10 130 53 1.30 1 56 1 0 87 MIN
1В HMl 70 FTN 1.15 1 16 1 15 1.0 1 30 1.21 1 0 1 07 MAX
19 HMI 78 FTN 1 15 108 1.0 84 111 1 21 87 94 MAX
20 HMl 74 JOV 1 40 1 08 1 30 .96 111 1.21 1 15 1 07 MAX
21 HMI 77 PLI 1.0 1 16 1 15 1.0 1 06 1.14 87 87 MAX
22 HMl 76 JOV 1 15 1.0 1.0 92 1.27 1 06 1.0 1 0 MAX
23 HMI 78 HOL 1.15 1.0 1.0 96 1 08 1 06 1.0 1 0 MAX
'24 HMI 79 FTN 88 to 85 1.0 1 06 1 06 1.0 87 MIN
25 HMI 78 JOV 1 15 1.16 1.30 1.0 1 15 1 06 1 0 87 MAX
26 HMI 77 HOL 94 1.0 85 1.0 1.07 1 06 1.15 1 07 MAK
27 HMI 77 FTN 1 15 94 1.15 1.0 1.35 1 21 1.0 87 MIN
28 HMl 72 MOL 1 15 1 08 1 30 1.0 111 1 21 1 15 1 07 MIN
29 HMI 79 FTN 88 1 0 1.0 1.0 1.0 1.0 1.0 1 0 MAX
30 HMI 79 PSC 88 1.0 1.0 1.0 1.0 1.0 1 0 1 0 MAX
31 SCI . 75 MOL 1.40 1 08 1.0 81 1.48 1 56 1.15 1 07 MIN
32 SCI ’ 72 FTN 88 1 08 85 .67 1.0 1.0 1.0 1.0 MAX
33 SCI 76 FTN 1.40 1 08 1 30 96 1 48 1 56 1 15 94 MIN
34 SCI 77 FTN 1 15 1 08 10 96 1 06 10 1.0 87 MIN
35 SCI 68 MOL 75 94 1 30 1.0 1.06 1 21 1.15 1.0 MID
36 SCI 79 FTN 88 1 08 85 81 1.0 1 0 87 87 MAX
37 SCI 78 FTN 88 94 70 56 1.0 1 06 1 0 1.0 MIN
38 SCI 77 PLI 1.0 10 1 15 1 0 1.0 1.0 87 87 MAX
39 SCI 64 FTN 1.0 1.0 1 15 10 1.0 1.0 87 1.0 MAX
40 SCI 74 MOL 1.0 94 130 B3 1.0 1.0 1.0 87 MIN
41 SCI 76 FTN 68 94 1.0 1.0 1.0 1 0 87 87 MAX
42 SCI 78 FTN 88 1 04 1.07 43 1.0 1 06 87 1 07 MAX
43 SCI 78 FTN 1 00 1.04 1.07 98 1.0 1 21 87 1 07 MAX
44 SCI 78 FTN 88 104 1 07 98 1 06 1 21 87 1 07 MAX
45 SCI 77 FTN 88 1.04 1.07 91 1.0 1 06 87 1.07 MAX
46 SCI 78 FTN 88 104 1 07 78 1.0 1 06 87 1 07 MAX
47 SCI 78 FTN 75 94 1 30 1.0 1.0 1.0 87 87 MAX
48 SUP 76 FTN .88 94 85 67 1.0 1.0 87 1.0 MAX
49 SUP 76 JOV 1.0 1.0 85 1.0 1.0 1.0 1 0 .87 MID
50 SUP 76 MOL 1.15 1.0 1.0 1.0 1 30 1 21 1 0 87 MIN
51 SUP 70 COB 83 1.0 1.0 1.0 1 0 1.0 1.0 1 15 MAX
52 SUP 71 MOL 58 94 85 1.0 1.0 1 06 1.15 1.0 MIN
53 SUP 78 MOL 88 94 1.15 1.0 1.11 1 21 1.30 1.0 MIC
54 SUP 78 FTN 1.0 94 1.0 1.0 1.0 1 06 1.15 87 MIC
55 SUP 72 FTN .88 94 70 1.0 1.0 1.0 87 87 MAX
56 SYS 71 MOL 1 15 94 1 30 1.0 1 30 1.21 1.0 1.0 MAX
57 SYS 74 MOL 1.0 94 1 15 .87 1.11 1 21 1 30 1.0 MIN
58 SYS 76 MOL 1 40 94 1.30 1.0 166 1 21 1 0 1.0 MIN
59 SYS ?7 HOL 1.0 94 1 15 .90 1 06 1 06 1 0 .87 MID
60 SYS 73 MOL 1 15 94 1 30 1.0 111 1 06 1.0 1.0 MAX
61 SYS 78 PSC 1.0 94 1 15 1.0 1.0 1.0 .87 .87 MAX
62 SYS 78 MOL 88 94 1.30 1.0 1.11 1 21 1 15 1.0 MIC
63 SYS 79 MOL 1.0 94 1.15 1.0 1.0 1.0 1.0 .87 MIN
407
PN Атрибуты исполнителей Атрибуты проекта MODE TOT KDSI ADJ KDSI
A LAP ALXP PC,АР VEXP LEXP CDNT MODP TOOL SCED RVOL II
1 1 19 1 13 1 17 1 10 1.0 NOM 1.24 1.10 1.04 1.19 2.72 E 113 113
2 1 0 91 1.0 90 .95 NOM 1.10 1.0 1.0 1.0 .84 E 293 249
3 86 82 .86 .90 .95 NOM .91 .91 1.0 1.0 .34 SD 132 132
4 1 19 .91 1.42 1.0 .95 NOM 1.24 1.0 1.04 1.19 1.17 ORG 60 46
5 1 0 1.0 .86 .90 .95 NOM 1.24 1.0 1.0 1.0 .66 ORG 16 16
6 1 46 1.0 1-42 .90 .95 Hl 1.24 1.10 1.0 1.19 2.22 ORG 4.0 40
7 1.0 1.0 1.0 .90 .95 HI .91 .91 1.0 1.0 .40 ORG 6.9 69
в 71 .91 1.0 1.21 1 14 NOM i’.io 1.10 1.08 1.3B 7.62 E 22 22
9 .86 1.0 .86 1 10 1.07 NOM .91 1.0 1.0 1.19 2.39 E 30 30
10 .66 .82 .86 .90 1.0 NOM 1.0 1.0 1.0 1.3B 2.38 E 29 1B
11 .86 .82 .86 .90 1.0 NOM 1.0 1.0 1.0 1.38 2.38 E 32 20
12 .86 .82 .86 1.0 .95 NOM .91 1.0 1.08 1.19 1.12 E 37 37
13 71 1.0 .70 1.10 1.0 HI .82 1.0 1.0 1.0 .85 E 25 24
14 .86 1.0 70 1.10 1.07 NOM 1.10 124 •J .23 1.19 5.B6 SD 3.0 30
15 .86 1.13 .86 1.21 1.14 NOM .91 1.0 1.23 1.19 363 E 39 39
16 .86 1.0 .86 1.0 1.0 NOM 1.0 1.0 1.0 1.19 2.81 E 6.1 3.7
17 .В6 .82 .86 1.0 1.0 NOM 1.0 1.0 1.0 .91 1.78 E 3.6 1.9
1В 86 1.0 1.0 1.0 1.0 10 1.24 1.10 1.08 1.19 3.89 E 320 320
19 71 .91 1.0 1.0 1.0 NOM .91 .91 1.0 1.0 .73 E 1150 966
20 71 -В2 1.08 1.10 1.07 NOM 1.24 1.0 1.08 1.19 3.85 SD 299 287
21 .В6 1.0 1.0 1.0 1.0 Hi .91 .91 1.0 1.0 .86 E 252 252
22 .86 .82 .86 .90 1 0 HI .91 1.0 1.23 1.0 .94 E 118 109
23 Л6 .82 .86 .90 1.0 LO 1.0 1.0 1.23 1.0 .89 E 77 75
24 1.0 1.29 1.0 1 10 95 NOM .82 .83 1.0 1.0 .70 SD SO 90
25 .86 1.0 .В6 1.10 1.0 NOM .82 .91 1.08 1.62 1.95 E 3B 38
26 .86 1.0 .В6 1 10 1.0 NOM ..91 1.10 1.08 1.19 1.16 E 4B 48
27 1.0 1.0 1.0 1.0 1.0 Hl .82 1.10 1.08 1.19 2.04 E 9.4 94
2В .86 1.0 .86 1.10 1.07 NOM 1.10 1.10 1.0 1.0 2.81 ORG 13 13
29 1.10 1.29 .86 1.0 1.0 HI .91 .91 1.23 .91 1.00 SD 214 2 14
30 1.0 1.29 .86 1.0 1.0 HI .91 .91 1.23 .91 .91 SD 1.98 1 98
31 .85 JB2 .86 1 10 1.07 NOM 1.0 1.0 1J> 1.0 3.14 E 62 50
32 71 JB2 1.0 1.0 1.0 NOM 1.10 1.10 1.0 1.0 .57 SD 390 261
33 -8в ..82 .86 .90 1 0 HI .91 .91 1.0 1.0 2.26 E 42 40
34 1.0 1.0 1.0 1.0 1.0 NOM .91 1.10 1.23 1.19 1.76 E 23 22
35 1.0 S1 1.0 1.10 1.0 NOM 1.24 1.24 1.0 1.19 263 E 13 13
36 1 19 1.0 1 17 .90 .95 NOM 1.0 .91 1.04 1.0 68 SD 15 12
37 В6 .82 .86 1.0 1 0 NOM 1.0 1.0 1.0 St 34 ORG 60 34
38 71 .91 1.0 .90 95 NOM .82 .91 1.0 1.0 35 ORG 15 15
39 71 .82 70 1.0 95 HI .91 1.10 1.0 1.0 .39 ORG 6.2 62
40 .66 82 1 17 1.0 1.0 NOM 1.10 1.0 1.0 1.0 96 ORG 3.0 2.5
41 1.0 .82 70 .90 .95 HI .91 .91 1.0 1 0 .25 ORG 5.3 5.3
42 .86 1.0 .93 .90 .95 Hi .95 .95 1.04 1.0 .63 ORG 45.5 19.5
43 .86 1.0 1.0 .90 .95 HI 1.0 1.0 1.04 1.0 .96 ORG 28„6 28
44 1.0 1.0 1.0 .90 .95 HI .1.10 1.0 1.04 1.0 1.14 ORG 30.6 30
45 1.0 1.0 1.0 90 95 HI 1.0 .95* 1.Q4 4.0 .82 ORG 35 32
46 1.0 1.0 .86 .90 95 -JOM 10 1.0 1.04 1.0 .74 ORG 73 57
47« 71 82 70 110 1.07 NOM 1.10 1.0 1.04 10 .38 ORG 23 23
4В 1 19 .91 1.17 .90 .95 NOM 1.10 10 1.04 1.09 .83 SD 464 311
49 .71 1.0 .70 1.10 1.0 Hl .82 .91 1.0 1.19 .36 SO 91 91
50 .86 1.0 .86 1 10 1.0 NOM 1.0 1.0 1.0 1.19 1.52 E 24 24
51 1 19 1.0 1.42 1.0 .95 LO 1.24 1.10 1.04 138 3.18 ORG 10 10
52 10 1.0 1.0 1.10 1.07 NOM 1.24 1.10 1.0 138 1.90 ORG 8.2 6.2
53 71 1.0 .70 1.10 1.07 NOM 1.0 1.10 1.06 3.0 1.15 SD 5.3 53
54 10 82 1.0 1.0 .95 HI .91 1.10 1.0 3.19 .93 ORG 4.4 4.4
55 86 82 1.17 .90 .95 NOM 1.10 1.0 1.0 1.0 .34 ORG 6.3 6.3
56 86 .91 1.0 1 10 107 NOM 1.10 1.10 1.08 1.36 3.68 E 27 27
57 1 О 1.0 1.0 1.10 1.07 LO 1.10 1.10 1.23 UO 3.32 E 17 15
58 71 82 70 .90 S5 NOM .91 1.0 1.0 1.0 1.09 *E 25 25
59 1 0 10 Ю 10 1 0 NOM .91 1.0 1.0 .91 87 ORG 23 21
ео 86 113 .86 1 10 107 NOM 1.10 1.10 1.08 1.19 2.53 ORG 6.7 6.7
61 86 1 0 86 90 1 0 HI .82 1.0 1.0 1.0 .45 ORG- 28 28
62 78 82 70 121 1 14 NOM .91 124 1.0 10 1 15 SD 91 9.1
63 71 82 86 10 10 NOM .82 1.0 1.0 1.0 39 E 10 10
ОБОЗНАЧЕНИЯ, ИСПОЛЬЗОВАННЫЕ в ТАБЛ. 29.1
1 PN 2 Type Порядковый номер проекта Тип проекта
408
PN ЧМ П ADS1 ММ Месяцы Детальная КОМОСТ Базовая Докумен- КОМОСТ тация
NOM EST ACT Е-А А EST ACT Е-А А
EST Е-А А ММ п EST Е/А КРР РР TKDSI
1 614 2218 2040 9 55 29 48 40 2286 12 750 1047 51 2.0 18
2 2102 1770 1600 11 156 27 36 25 1760 10 1905 2702 1.69 115 39
3 711 245 243 1 543 17 15 13 24В 2 715 711 2.93 10.4 79
4 178 212 240 12 192 20 36’ -44 207 -14 205 134 Л6 0.8 13
5 59 39 33 18 485 ' 94 9 4 за 15 50 44 1.34 0.15 9
6 13.7 30 43 -30 93 10.4 12 -13 30 30 19 10.3 .24 —
7 24 9.8 8 22 862 55 4 38 10.2 28 20 1В 2.28 O.S 72
в 114 869 1075 •19 20 23 30 -23 994 -В 141 147 .14
9 166 397 423 -6 71 17 18 —6 395 -7 177 213 .50 1.1 37
10 90 214 321 -33 56 16 30 -47 21В -32 135 115 .36 7.0 241
11 102 243 218 11 92 14 24 -42 248 14 91 131 .60 5.2 162
12 213 238 201 18 164 14 12 17 237 18 179 274 1.36 4.0 10В
13 127 108 79 37 304 10.1 10 1 106 34 93 163 2.07 1.1 44
14 10.3 60 73 -18 41 11.2 12 -7 64 -12 12 10.3 .14 0.05 17
15 14.3 52 61 -15 64 9.3 15 -38 51 -16 17 18 .30 0.7 179
16 13.5 38 40 -5 92 8 1 10 -19 39 -2 14 17 .43 0.5 82
17 6.0 10.7 9 19 211 5.1 6 -15 10.9 21 5.1 7.8 .86 0.3 83
18 2840 11056 11400 -3 28 50 72 -31 12380 9 2931 3652 .32 100 31
19 10694 7764 6600 18 146 42 40 5 7699 17 9041 13749 2.08 31.4 27
20 1698 6536 6400 2 45 54 51 6 7571 18 1662 1698 .27 18 0 60
21 2132 1836 2455 -25 103 30 60“ -50 1864 -24 2855 2741 1.12 3.0 12
22 780 733 724 1 151 21 16 31 728 1 770 1003 1.39. 19.5 165
23 498 443 539 -18 139 19 16 19 445 -17 606 640 1.19 14.9 194
24 463 326 453 -28 199 21 28 -25 337 -26 647 463 1.02 1.S 17
25 220 430 523 -18 73 19 39- -51 433 -17 268 283 .54 4.7 124
26 292 339 387 -12 124 17 19 -11 341 -12 334 375 .97 4.0 аз
27 41 89 88 -5 107 10.5 12 -12 82 -7 43 53 .60 —— —•
28 47 133 98 36 133 14 20 -30 143 46 35 35 .36 ——
2Э 7.0 7.0 7.3 -4 293 5.0 2 150 7.0 —4 7.3 7.0 .96 .14’ 65
50 6.4 5.8 5.9 -2 336 4.7 2 135 5.9 0 6.5 6.4 1.08 .13 66
31 306 .962 1063 -10 47 23 24 -4 1057 -1 339 394 .37 2.0 за
□2 1527 869 702 24 372 25 24 4 668 24 1232 1527 2.18 3.5 3
33 234 529 605 -13 66 19 24 -21 543 -10 268 301 .50 30 71
34 114 201 230 —14 96 14 12 17 201 -14 131 147 .64 67 291
35 61 161 82 96 159 10.2 10 2 162 90 31 7В .95 0.1 8
36 49 33 55 -40 218 10.2 12 -15 34 -38 61 49 .89 0.3 .20
37 130 44 47 Г (т 723 108 24- -55 44 6 138 97 2.07 1.4 23
38 55 20 12 67 1250 6.4 5 2В 20 67 34 41 3 43 — —•
39 22 8.4 8 5 775 5.5 9* 39 83 4 21 16 204 0.5 В!
40 84 8 1 8 1 312 5.5 9 -39 8.0 0 8.3 6.3 .79 — —
41 18.4 47 6 -22 883 4.9 5 2 4.9 -18 24 14 230 — —
- 42 72 46 45 2 433 10 6 В1 31 46 2 71 54 1.21 1.4 31
43 106 102 ВЭ 23 337 13.4 14 1 -5 102 23 86 79 .96 1 7 59
44 114 130 87 49 345 13.6 139 -2 120 47 76 85 .98 1.8 59
45 122 100 106 —6 302 14 7 12.3 20 100 - 6 129 91 .06 1 25 36
46 223 166 126 32 452 15.7 16.1 -2 164 30 170 167 1.33 26 36
47 86 33 •36 -В 639 9.8 22.2 -56 32 -11 95 65 1 79 — —
48 1858 1542 1272 21 244 31 44 -30 1519 19 1533 1858 1.46 10.0 22
49 469 168 156 8 503 15 10 -17 170 8 433 469 3 01 5.5 60
50 127 193 176 10 136 13 12 8 194 10 116 163 .93 1.1 46
51 36 114 122 -7 82 16 34 -53 115 -6 38 27 .22 , —
52 29 55 41 17 174 10.8 14 -23 56 19 25 22 .47 —- —
53 194 22 14 57 379 6.3 6 -5 22 57 12 194 1 39 003 6
54 15 14 20 30 220 7.8 7 11 14 -30 22 11 4 .57 008 .8
55 22 75 18 - 58 350 7.5 12 -38 7.4 -59 53 16 6 .92 — —
5t> 146 537 958 -44 2В 22 24 -8 ’ 570 -41 260 188 .20 1.5 56
57 72 239 237 1 63 14 24* -42 247 4 71 93 39 — —
58 133 145 130 12 192 11 9 12 1 143 10 119 171 1 32 3.0 120
59 78 68 70 3 300 13 *6 -19 68 -3 ВО 59 84 —
60 23.6 60 -57 5 1 че т*6 12 3 61 7 23 18 31 0.1 15
61 106 47 . 50 6 560 : * t ?0 11 48 -4 111 79 1 59 0.4 14
62 36 4? 38 1? 239 S9 14 36 41 В 33 36 95 0.2 22
63 44 17 15 ' 13 667 54 4 40 17 13 . 38 57 ЗАО о.з 30
BUS CTL HMI SCI Обработка деловой документации Управление процессами Человеко-машинное взаимодействие Научные применения
409
SUP
SYS
3 Year
4 LANG
COB
PLI
FTN
MOL
JOV
HOL
PSC
5 RELY
6 DATA
7 CPLX
8 AAF
9 TIME
10 STOR
11 VIRT
12 TURN
13 TYPE
MAX
MID
MIN
MIC
14 ACAP
5 AEXP
16 PCAP
17 VEXP
18 LEXP
19 CONT
NOM
HI
LO
20 ‘.'.ODP
21 TOOL
22 SCED
23 RVOL
24 П
25 MODE
E
SD
ORG
26 TOT KDS1
27 ADJ KDSI
28 NOM
29 EST
30 ACT
31 E—A
A
32 ADSI
MM
33 EST
Вспомогательное ПО (инструментальные средства, ути.штн
и т. п.)
Системное ПО (операционные системы, компиляторы и т. п.)
Год (последние две цифры календарного года разработки)
Язык (используемый в проекте исходный язык программирова-
ния)
Кобол
ПЛ/1
Фортран
Машинно-ориентированный язык
Джовиал
Язык высокого уровня
Паскаль
ТНПО (требуемая надежность программного обеспечения)
РБД (размер базы данных)
СИЗ (сложность программного изделия)
ККА (корректирующий коэффициент адаптации)
ОБД (ограничение по быстродействию)
ОП (ограничение пз оперативной памяти)
ИВМ (изменяемость виртуальной машины)
ЦО (цикл обращения к ЭВМ)
Тип используемой в разработке ЭВМ
Большая ЭВМ (типа IBM 370/155 или более мощная)
Средняя ЭВМ (типа IBM 370/135 или более мощная)
Мини-ЭВМ
Микро-ЭВМ или микропроцессор
КА (квалификация аналитика)
ОРП (опыт работы в данной прикладной области)
КП (квалификация программиста)
ОРВМ (опыт работы с виртуалиной машиной)
ОРЯП (опыт работы с языком программирования)
СШР (сохраняемость штата разраб >тчиков)
Текучесть 10 ... 30%
Текучесть более 30%
Текучесть менее 10%
ПСП (практика современного программирования)
ИИС (использование инструментальных средств)
ОСР (ограничение сроков разработки)
ИТ (изменяемость требований)
Произведение коэффициентов затрат труда для проекта
Тип разработки ПО
Встроенное
Полунезависимое
Распространенное
ОБЩ КЧИК (общее число исходных команд, тыс.)
СКОРР КЧИК (скорректированное КЧИК = (ОБЩ КЧИК)Х
Х(ККА;)
НОМ ЧМ (номинальные затраты труда, вычисленные по номи-
нальному уравнению затрат в зависи чости от типа разработки
(см. табл. 8.1 или 23.1))
ОЦ ЧМ (оценка затрат труда по промежуточной КОМОСТ для
проекта: СЦ ЧМ=(НОМ ЧМ) П)
ФАКТ ЧМ (фактические затраты труда на разработку проекта)
Ошибка в оценке = Ю0[|(ОЦ ЧМ) — (ФАКТ ЧМ)]/(ФАКТ ЧМ)
Производительность = (СКОРР КЧИК)/(ФАКТ ЧМ)
ОЦ ВМ {оценка времени разработки в месяцах, вычисленная по
ФАКТ ЧМ и уравнению _poi;e>B разработки в зависимости от
типа разработки)
410
34 ACT ФАКТ M (фактическое время разработки в месяцах)
35 Е—А Ошибка в оценке =100 [(ОЦ ВМ)— (ФАКТ М)]/(ФАКТ М)
“А
36 EST ОЦ ДК (оценка ЧМ пс детальной КОМОСТ с учетом рейтингов)
37 Е—А Ошибка в оценке= ЮО[(ОЦ ДК) — (ФАКТ ЧМ)]/(ФАКТ ЧМ)
“А-
38 ММ Параметр нормализованных затрат= (ФАКТ ЧМ)/П (см.
рис. 8.4)
39 EST ОЦ БК (оценка ЧМ по базовой КОМОСТ с использованием ос-
новного уравнения для скорректированнсг э КЧИК (см.
табл. 6.1))
40 Е/А Оценка по базовой КОМОСТ отношения (ОЦ БК)/(ФАКТ ЧМ)
41 КРР КЧСД (число страниц документации по проекту с включением
кодовых листингов, тыс.)
42 РР Отношение числа страниц документации к числу исходных
TKDSI команд = 1000 (КЧСД)/(ОБЩ КЧИК)
Были приложены значительные усилия для того, чтобы инфор-
мация в базе данных КОМОСТ была согласованной и чтобы поня
тия разработки, человеко-месяца, проекта и -ЧИК были согласова-
ны с предположениями, высказанными в разд. 5.2, определениями,
данными в табл. 4.1, и структурой подразделения работ, показан-
ной на рис. 4.6. Значительное внимание уделено исключению из ба-
зы данных некоторых характеристик проектов для сохранения их
анонимности.
29 .3. СОПОСТАВЛЕНИЕ ОЦЕНОК ЗАТРАТ НА РАЗРАБОТКУ С ФАКТИЧЕСКИМИ
ДАННЫМИ
На рис 6.4, 8.3 и 29.1 проведено сравнение оценок затрат на
разработку ЧМОЦ и фактических данных ЧМфакт для базовой, про-
Рис 29.1. Сравне-
L ние оценок затрат
по детальной
КОМОСТ с фак-
k тическими данны-
ми для различных
I типов проектов:
О — распространен-
ный тип; х — полуне-
зависимый тип; А —
встроенный тип
411
о
О о
х . °
А х
А А О о
1 - ДДДДДДоДДхАоАхоАо Аоххд
—1____1_1—1—1__11_111_1t 1 I_1_1LU1_1_। iLU1_1ш1—1_1_1_1_- -
-90 70 50 30 10 0 10 30 50 70 90 120 200 300
-80 -60 40 20 20 40 60 80 100 150 250
Относительная ошибка, %
Рис. 29.2. Распределение ошибок в оценках затрат по базовой КОМОСТ для
различных типов проектов:
О — распространенный тип; х — полунезависимый тип; А — встроенный тип
межуточной и детальной КОМОСТ соответственно. Из результатов
сравнения следует, что:
промежуточная и детальная КОМОСТ являются более точными,
чем базовая КОМОСТ;
детальная КОМОСТ не намного лучше промежуточной для оце-
нивания общих затрат на разработку.
Эти выводы станут более ясными после рассмотрения рис. 29 2,
29.3 и 29.4, на которых представлены гистограммы относительных
ошибок в оценках по базовой, промежуточной и детальной КО-
МОСТ соответственно. Относительная ошибка определяется как
отношенние (ЧМОЦ — ЧМфакт)/ЧМф„кт. Распределение относитель-
ной ошибки для базовой КОМОСТ показывает значительный раз-
брос, в то время как распределения относительных ошибок для про-
Относительная ошибка, %
Рис. 29.3. Распределение ошибок в оценках затрат по промежуточной КОМОСТ
для различных типов проектов;
О — распространенный тип; х — полунезависимый тип; А — встроенный тип
412
Рис. 29.4. Распределение, ошибок в оценках затрат по детальной КОМОСТ для
различных типов проектов:
О — распространенный тип; х — полунезависимый тип; А — встроенный тип
межуточной и детальной КОМОСТ имеют меньший разброс и поч-
ти подобны.
Гистограммы на рис. 29.2—29.4 отражают также влияние типа
разработки. В оценках по промежуточной и детальной КОМОСТ
не наблюдается значительного влияния типа разработки, чего
нельзя сказать об оценках по базовой КОМОСТ.
29.4. СОПОСТАВЛЕНИЕ ОЦЕНОК СРОКОВ РАЗРАБОТКИ
С ФАКТИЧЕСКИМИ ДАННЫМИ
На рис. 6.6 проведено сравнение оценок сроков разработки по
КОМОСТ с фактическими данными. Видно, что оценки по КО-
МОСТ являются достаточно точными для традиционных разрабо
ток ПО, но очень занижены для пошаговых разработок. Это под-
тверждается гистограммами относительных ошибок, представлен-
ными на рис. 29.5. Анализ распределения ошибок в оценках сроков
разработки позволяет сделать следующие выводы:
1. Уравнения сроков разработки дают завышенные сроки про-
ектирования пошаговых разработок.
2. Оценки являются точными для обычных разработок (в пре-
делах 20% от фактических данных в 58% случаев).
3. Хотя некоторые проекты завершены за более короткие, чем
номинальные оценочные сроки, только для четырех проектов из 63
необходимо сжатие сроков, чтобы они оказались в пределах
75-процентной границы (см. разд. 27.3).
Наилучший подход к оцениванию сроков пошаговых разработок
предусматривает:
1. Оценивание общего срока и его распределения по фазам для
всего проекта. Срок завершения фазы проектирования определяет
начальную часть срока пошаговой разработки.
413
8
о
о о
о о ох
X X О X о
А о А х о А о Л
оАхААААХОА
L 75-процентная
• граница
о i
I
1 |-о о А А А А X А А А А А А.Ах А о А|о А 135 150
—1 1 1—1 1 1—1 1 1—I—1 1—1 1' I I 1 1 .111 । I-т j т т । t I I I
—55—45 -35 —25 -15 -5 0 5 15 25 35 45 55 65
-60 -50-40 -30 -20 -10 Ю 20 30 40 50 60 70
Относительная ошибка, %
Рис. 29.5. Распределение ошибок в оценках сроков разработки по КОМОСТ для
различных типов проектов:
О _ распространенный тип; х — полунезависимый тип; А — встроенный тип; АО — по-
шаговая разработка
2. Оценивание общего срока и его распределения по фазам для
каждого шага разработки. К полученному сроку по каждому ша-
гу разработки добавляется часть, равная продолжительности фазы
программирования. При оценивании последнего шага разработки
к итоговому сроку, кроме продолжительности фазы программиро-
вания, добавляется еще продолжительность фазы комплексирова-
ния и испытаний.
На рис. 29.6 жирными линиями показаны части сроков поша-
говой разработки.
Рис. 29.6. Оце
Весь проект Расширение 1 Расширение 2 Расширение 3 Проектирование Программирование Комплексирование изделия f и испытания кивание сро- ков пошаговой разработки: ФПИ — фаза про- ектирования из- делия, ФП — фаза программирова- | ния, ФКИ — фаза комплексирования и испытаний
ФПИ ФП | ФПИ, ФКИ ФП , ФКИ
I " 1 ФПИ ! ФП , ФКИ ,
г 1 1
29.5. СОПОСТАВЛЕНИЕ ОЦЕНОК РАСПРЕДЕЛЕНИЯ ЗАТРАТ ПО ФАЗАМ
С ФАКТИЧЕСКИМИ ДАННЫМИ
Количество данных по проектам менее всего пригодно для оце-
нивания распределения затрат по фазам, оно более пригодно для
получения общих оценок. В табл. 29.2 приведены оценки распреде-
ления затрат по основным фазам разработки, полученные с помо-
щью промежуточной и детальной КОМОСТ, и соответствующие
фактические данные.
Данные табл. 29.2 представлены также графически на рис. 29 7
по каждому проекту и по каждой фазе. Из анализа рисунка мож-
но сделать следующие выводы:
414
1. Все изменения в распределении затрат в зависимости от раз-
мера и типа проекта (например, на фазе комплексирования и ис-
пытаний) в основном совпадают для оценок по детальной КОМОСТ
и фактических данных.
2. Наблюдается приемлемое совпадение оценок по детальной
КОМОСТ и фактических данных на многих фазах.
3. Имеются существенные расхождения оценок и фактических
данных по некоторым проектам. Частично это объясняется слож-
ностью точного определения фаз (например, плохо просматривает-
ся граница между детальным проектированием и кодированием и
автономной отладкой). По крайней мере, в одном случае (значи-
тельное недооценивание детальной КОМОСТ затрат на комплек-
сирование и испытания для малых проектов распространенного ти-
па) модель могла бы быть улучшена; более поздние исследования
показали, что работа по документированию в процессе комплекси-
рования и испытаний увеличивает затраты несколько больше, чем
предсказывает КОМОСТ.
Таблица 29.2
Сопоставление оценок распределения затрат по фазам
с фактическими данными
Номер проекта Проектирование изделия Детальное проектирование Кодирование и отладка Комплексирова- ние и испытания
ПРОМ ДЕТ ФАКТ ПРОМ ДЕТ ФАКТ ПРОМ ДЕТ ФАКТ ПРОМ ДЕТ ФАКТ
18 18 8 Встроенный, оче 5 I 25,5 I 14 нь 6oj 15 гыиой z 25 гроект 20 25 32,5 58 55
19 18 17 15 24 26 25 24 19 20 34 38 40
21 18 23 18 25,5 28 23 25 18 22 32,5 31 37
Встроенный, средний проект
8 18 6 8 26 15 25 29 27 17 27 52 50
9 18 16 18 26 21 20 28 29 26 28 34 38
50 18 18 15 25 24 20 29 21 30 | 27 37 35
Полунезависимый, малый проект
29 I 17 I I 23 1 19 1 27 | 1 29 1 29 1 37 1 34 1 1 33 1 19 1 14 1 19
30 | 17 | 23 1 23 | 27 | | 29 1 28 | 37 1 35 | 1 31 | 19 1 13 | 18
Распространенный, средний проект
59 1 1 16 I 1 21 1 I5 1 24 I | 27 1 30 1 39 1 32 1 1 25 1 21 1 20 1 I 25
61 1 1 16 1 1 25 I 24 1 24 | , 30 1 34 | 38 1 30 | 1 24 | 22 1 15 | 1 18
Распространенный, малый проект
39 I 16 I 19 1 25 1 25 1 | 25 1 30 1 41 1 41 1 1 30 1 18 1 15 1 1 15
40 | 16 I 13 1 ю 1 26 1 29 1 24 1 42 1 39 | 1 42 | 16 1 19 1 1 24
Примечание. ПРОМ — оценка по промежуточной КОМОСТ, ДЕТ — оценка по Де-
альвой КОМОСТ. ФАКТ — фактические данные.
415
30
20
10
60
50
40
30
20
10
X X ® и 9
п5 0 □ □ 0 п п а
X с О
О X
J-J 1 1 1 1 'I г 1_1 LL
20
10
30 20 I «а» 0ПП бо 4U1 •а 0 0 X X а п о X "8 / 1
10 * 1—1 I .. X I 1 I I । 1 1 1 I А
8* Й Q X
п □ а X X о f
.1 1 1 X 0 LI- I !_U_ U- 1_!
§
°D ° Q
и@ 9 °
Хх *
Рис. 29.7. Сравнение
оценок распределения
затрат по фазам разра-
ботки с фактическими
данными:
® — фактические затраты, %;
□ — оценка по промежу-
точной КОМОСТ (грубая
оценка); х — оценка по де
тальной КОМОСТ (тонкая
оценка)
________III III It II II
Номер проекта 1819 21 8 Э 50 2930 5961 3440
Тип и размер Встроенный, Встроен- Попунеза- Распрост- распрострв'
проекта очень ны„, В1гимь'й, раненный, ценный,
большой средний малый средний малый
Другим способом контроля точности КОМОСТ является сопо-
ставление заимствованных из различных источников данных в
табл. 29.3, которая содержит распределения затрат по фазам. Судя
по таблице, оценки по КОМОСТ достаточно хорошо согласуются с
фактическими данными, но еще далеки от идеальных.
29.6. СОПОСТАВЛЕНИЕ ОЦЕНОК РАСПРЕДЕЛЕНИЯ ЗАТРАТ ПО РАБОТАМ
С ФАКТИЧЕСКИМИ ДАННЫМИ
Если оценивание распределения затрат по фазам затруднено
отсутствием данных или невозможностью точного определения гра-
ниц фазы, то еще более проблематичным является оценивание рас-
пределения затрат по работам. В табл. 29.4 проведено сравнение
данных из табл. 7.1 и фактических данных для очень больших про-
ектов встроенного типа с номерами 19 и 21 в базе данных КО-
МОСТ, а также данных из табл. 7.2 и фактических данных для
малых проектов полунезависимого типа с номерами 29 и 30 в базе
416
Таблица 293
Распределение затрат в процентах по фазам для различных проектов
Тип и размер проекта Источник Планирова- ние и разра- ботка 'ре- бований Проектиро- вание изде- лия Детальное проектиро- вание Кодирование и автономная отладка 5x5 х £ 4> Ж « Ж ® 3 о К с
Встроенный, очень шой боль- [35] [35] [51] Ь77] [34] 39 30 33 25 45 14 20 17 21 15 47 50 50 54 40
Три проекта базы ных КОМОСТ Встроенный, не большой Три проекта базы ных КОМОСТ Распространенный, НИЙ Т.ва проекта базы ных КОМОСТ дан- очень дан- сред- дан- [313] [79] [ИЗ] [313] .313] [124] [201] 12 7 28 13 18 14 X-> 43 44 44 '-V-* 38 21 20 21 16 43 22 32 22 20 24 19 28 26 37 50 24 44 34 29 41 38 28 30 18 29 22
Распространенный, -> |>1П Два проекта базы ных КОМОСТ ма- дан- [124] 12 34 17 27 34 36 20 20
Фигурная скобка указывает суммарное значение для соседних колонок.
данных КОМОСТ. Главные выводы, вытекающие из сопоставле-
ния приведенных данных, состоят в следующем:
1. Различия между оценками и фактическими данными в зави-
симости от размера и типа проекта весьма незначительны.
2. Имеются и существенные различия, часто которых объясня-
ется неточностью определений понятия работы, а часть — особен-
ностями проектов. Кроме того, некоторые различия вызваны тем,
что не установлена зависимость оценки распределения затрат по
работам от типа проекта и стоимостных атрибутов. Большие затра-
ты на анализ требований и документирование связаны с примене-
нием в четырех рассмотренных проектах методов интерактивного
человеко-машинного ьзаимодействия. Малые затраты на програм-
мирование в проектах 19 и 21 объясняются применением интерак-
тивного программирования. Большие затраты на верификацию и
подтверждение в проекте 19 связаны с высокими требованиями к
надежности программ. Однако вывод о том, что распределение за-
трат по работам существенно зависит от стоимостных атрибутов,
еще требует подтверждения.
14 Зак. 628 417
Таблица 29.4
Сопоставление оценок распределения затрат по работам с фактическими
данными для различных проектов базы даннных КОМОСТ
Работа Планирование и разработка требований Проектирование изделия Програ ммиро- вание Комплексиро- вание и испытания
Очень большие проекты встроенного типа
Общие затраты на фазе, % Анализ требо- ваний Проектирова- ние изделия Программиро- вание Планирование отладки Верификация и подтвержде- ние Управление проектом КК и УК Документиро- вание Оценка П19 П21 Малые прое Оценка П19 П21 20 15 18 10 16 12 42 33 43 14 12 10 8 8 5 10 13 10 7 6 11 2 3 3 7 9 6 кты полунезавис Оценка П19 П21 45 45 45 3 3 7 6 7 12 55 42 35 8 11 8 12 15 14 5 7 9 6 7 5 5 8 10 имого типа Оценка П19 П21 35 40 37 2 2 4 4 3 7 48 40 35 5 8 4 20 25 23 6 5 10 8 9 7 7 8 10
Общие затраты на фазе, % Анализ требо- Оценка П29 ПЗО Оценка П29 ПЗО 23 19 23 Оценка П29 ПЗО 63 62 59 Оценка П29 ПЗО 14 19 18
ваний Проектирова- 48 40 50 12,5 22 10 4 5 8 2,5 3 1
ние изделия Программиро- 16 26 13 41 35 46 8 16 12 5 6 3
вание Планирование 2,5 1 0 12 10 4 51,5 48 46 33 24 36
отладки Верификация 2,5 2 4 4,5 2 2 4 2 3 2,5 0 0
и подтвержде- ние Управление 6 7 3 6 9 10 7 10 8 32 35 32
проектом 15,5 13 17 13 11 14 7,5 7 9 8,5 10 10
КК и УК Документиро- 3,5 2 3 3 0 1 7 2 3 8,5 3 3
вание 6 8 10 8 11 13 9 11 8 8 19 15
418
Некоторые данные и оценки распределения затрат по работам
рассмотрены в работах [124, 164 и 313]. Оценки по КОМОСТ в це-
лом согласуются с этими данными, но существенно отличаются от
приведенных в работе [139] данных, которые чрезвычайно зани-
жают затраты на проектирование и завышают затраты на отладку.
29.7. ДРУГИЕ МОДЕЛИ ОЦЕНИВАНИЯ СТОИМОСТИ ПО
В разд. 29.8 будет проведено оценивание КОМОСТ по рассмо-
тренным выше критериям с учетом современных требований к
точности оценивания стоимости ПО. Но прежде рассмотрим другие
модели оценивания стоимости ПО. В табл. 29.5 показано, как атри-
Таблица 29.5
Атрибуты, используемые в различных моделях оценивания стоимости ПО
Атрибут Модель
1 2 3 4 5 6 7 8 КОМОСТ
Исходные команды X X X V
Объектные команды X X X X
Атрибуты раз- Число подпрограмм Число единиц данных X X X X
мера Число форматов выдачи Документация Число исполнителей X X X X
Тип X X X X X X X
Сложность X X X X
Атрибуты про- граммы Язык программирования Повторное использова ИИС X X X X X X X X
Требуемая надежность Ограничение по быстро- X X
действию X X X X х X X
Атрибуты ЭВМ Ограничение по памяти Конфигурация ТО X X X X X X X X
Параллельная разработ- ка ТО Возможности исполните- X X X X X
ЛЯ X X X
Атрибуты ис- Постоянство штатов X
полнителей Опыт работы с ТО Опыт работы в данной X X X X X X X
прикладной области Опыт работы с языком X X X X X X X
программирования Использование инстру- X X X X X
ментальных средств X X X X X
Связь с заказчиком X X
Атрибуты про- екта Разработка требований Изменяемость требова- X X X
НИЙ X X X X X X
Сроки Безопасность X X X X
Доступ к ЭВМ X X X X X
Перенос X X X
4*
419
буты размера, программы, ЭВМ, исполнителей и проекта исполь-
зуются при оценивании стоимости ПО по этим моделям.
Модель 1 [223] основана на анализе 104 атрибутов 169 проектов ПО фирмы
System Development, проведенном в середине 60-х годов. Это самая лучшая мо-
дель с точки зрения использования линейной функции для оценивания затрат
труда. Полученная статистическими методами функция имеет вид:
ЧМ=—33,63 Рейтинг
4- 9,15 (недостатки требований) 0...2
4-10,73 (устойчивость проекта) 4- 0,51 (доля вычислительных команд) 4- 0,46 (доля команд выборки из памяти) 4- 0,40 (число подпрограмм) 0...3
4- 7,28 (язык программирования) 0...1
—21,45 (обработка деловой документации) 0...1
4-13,53 (независимая программа) 0...1
4-12,35 (первая программа на ЭВМ) 0...1
4-58,82 (параллельная разработка ТО) 0...1
-j-30,61 (использование случайного доступа) 0...1
4-29,55 (различные пользователи, целевое ТО) 0...1
4- 0,54 (количество командировок исполнителей) А
—25,2 (разработка военной организации) 0...1
В скобках указаны атрибуты.
Оценка затрат по 169 проектам составляет в среднем 40 ЧМ со стандартным
отклонением 62 ЧМ, что говорит о малой точности предсказания. Более того, ис-
пользование модели с нулевыми рейтингами дает отрицательную оценку — 33 ЧМ;
переход от ЯВУ на язык ассемблера увеличивает затраты труда на 7 ЧМ незави-
симо от размеров проекта. Самым убедительным возражением является нелиней-
ная зависимость оценки от многих стоимостных атрибутов.
Модель 1 можно рассматривать как информационную базу для построения
будущих моделей оценивания стоимости ПО. Большую помощь в получении
оценок стоимости и контроле их правильности оказывает распределение нормы
программирования, данное на рис. 24.14 и относящееся к рассматриваемой базе
данных. Эта база данных легла в основу модели 4 и модели, описанной в рабо-
те [224].
Модель 2 [313]. Сущность этой модели отражает рис. 29.8, на котором пред-
ставлено семейство кривых стоимостей ПО, выраженных в виде зависимости
стоимости одной объектной команды в долларах от относительной трудности ее
разработки, новизны применения (новое и старое) и типа проекта. Модель целе-
сообразнее всего использовать для оценивания компонентов ПО. Так, модуль из
1000 объектных команд нового ПО управления данными средней сложности
(50 %) оценивается в 46 000 долл., или 46 долл, на одну объектную команду.
Эта модель предназначена для проектов оперативного управления, работаю
щих в почти реальном времени, и не точна для проектов других типов. Кроме
того, модель может быть использована для оценивания распределения затрат по
фазам и работам.
Модель 3 [243], [244] предназначена для оценивания стандартного програм-
много изделия и основана на анализе ЖЦПО с помощью распределения Рэлея.
Модель макрооценки основных затрат описывается следующим выражением:
5и=СкК*/3^/3, (29 1)
где —число исходных команд; К—затраты на ЖЦПО за один год; tp — вре-
мя разработки, год; Ск — «технологическая константа», являющаяся функцией
состояния современной практики программирования, ограничений на ТО, личного
опыта, интерактивности разработки и других факторов; Ск=4984 для разработки
1973 г. и Ск= 10040 для разработки 1978 г. Требуемые затраты на разработку
оцениваются в 40 % от затрат на ЖЦПО.
Распределение Рэлея взято в модели 3 для нахождения компромисса между
затратами и сроками, что уже обсуждалось в разд. 27.3. Распределение Рэлея
420
обеспечивает получение точных результатов для одних проектов и весьма неудов-
летворительно для других, в частности для пошаговых разработок (см. разд. 4.4
5.6 и 6.5). Модель 3 включает в стоимость ПО оценку стоимости ЭВМ и сетевого
планирования.
Модель 4 [147] является развитием модели 1. Многие модели подобного типа
применяются в различных областях, например модель общего назначения, кото-
рая описывается выражением
ЧМ = 5,288-КЧИК1'047, для КЧИК > 10;
14
ЧМ=2,060-КЧИК*-047 П/у, ДЛЯ КЧИК<10. (29.2)
7=1
Коэффициенты затрат h приведены в табл. 29.6.
Эта модель не устойчива вблизи КЧ]
fi (при учете фактора «первая програм-
ма, разработанная на процессоре»
к оценке затрат добавляется 92% от
общих затрат с учетом данного фактора).
Модель 5 [118] является стандарт-
ной макромоделью и применялась внача-
ле для оценивания стоимости ПО, ис-
пользуемого в аэрокосмических исследо-
ваниях. Модель постепенно улучшалась,
увеличивалось число учитываемых фак-
торов, среди которых были и такие, как
число ЭВМ, число исполнителей и дру-
гие факторы со сложно оцениваемыми
рейтингами.
Рис. 29 8. Зависимость стоимости одной
объектной команды от относительной
трудности ее разработки в модели 2:
Типы программ; УП — управление процесса-
ми, ВВ — ввод-вывод, ПП — пре/пост/процес-
соры, ВЧ — вычислительные, УБ — управле-
ние базами данных
= 10 и при изменении коэффициентов
Относительная трудность разработки, %
В модели 5 используются те же соотношения, что и в КОМОСТ, и учиты-
ваются факторы ограничения на ТО, показанные на рис. 29.9 и 29.10 [314],
представляющих собой зависимости стоимости ПО от ограничений на ТО, ос-
новного рейтинга и рейтинга сложности. Для основных рейтингов типичны сле-
дующие значения:
1,0 Наземные системы
1,2 Наземные системы военного назначения
1,4 Военный транспорт
1,6 Гражданская авиация
1,8 Военная авиация
2,0 Космические летательные аппараты без экипажа (автоматические)
2,5 Космические летательные аппараты с экипажем (пилотируемые)
В модели 5 предусматриваются также расчет распределений затрат по фа-
зам и работам, анализ чувствительности алгоритмов расчета и ежемесячное на-
копление данных по затратам и срокам разработки ПО.
Модель 6 [291]. В литературе даны только частичные сведения об этой моде-
ли. Она основана на базе данных, представленной в разд. 25.1. В одной из версий
модели оценивается производительность труда по 29 атрибутам (см. табл. 25.5):
29
z= у
£= 1
Веса IT. определяются по формуле
lTi-0,5 logic (СТ?),,
421
Таблица 29.6
Коэффициенты затрат в модели 4 для малых программ
(менее 10 000 исходных команд)
Фактор fl । Фактор учтен?
Да | Нет
Специальный дисплей h 1.П 1,00
Детальная разработка эксплуатацион- ных требований ft 1,00 1,11
Изменение эксплуатационных требова- ний fs 1,05 1,00
Операции в реальном времени h 1,33 1,00
Ограничение по памяти процессора h 1,43 1,00
Ограничение по быстродействию про- цессора fs 1,33 1,00
Первая программа, разработанная на процессоре h 1,92 1,00
Параллельная разработка ТО fs 1,82 1,00
Сравнение пакетной обработки и обра- ботки с разделением времени ft 1,83 * 1,00
Использование ЭВМ с другими свойст- вами /10 1,43 1,00
Разработка операционного окружения /11 1,39 1,00
Инструментальная ЭВМ отличается от объектной /12 1,25 1,00
Разработка более одного операционного окружения /13 1,25 1,00
Доступ программиста к ЭВМ /14 Ограничен Неограни- чен 1,00 0,90
где (СП){—средняя производительность труда при высоком и низком рейтингах
для it-го стоимостного атрибута (например, (7/7=376 ЧИК/ЧМ для атрибута
сложности интерфейса). Рейтинг Xi принимает значения —-1, 0 или +1 соответ-
ственно для низкого, среднего или высокого рейтингов.
Основная трудность использования модели связана с неопределенностью за-
висимости производительности от взаимодействия атрибутов между собой (см
Рис. 29.9. Влияние ограничений на ТО в модели 5
'ис. 29.10. Зависимость стоимости ПО от основного рейтинга и рейтинга слож-
ости в модели 5
разд. 25.1). Весьма важны используемые в этой модели данные по оцениванию
сроков, стоимости ЭВМ и норм документации.
Модель 7 г33] подобна КОМЭГТ во многих отношениях. Она оценивает затра-
ты труда в ЧМ зависящих от ЧИК. используя следующие основные отношения
производительности (в ЧМ/1000 операторов) при решении различных задач:-
Математические................................6
Обработки записей.............................8
Логические...................................12
Обработки сигналов...........................20
Реального времени .......................... 40
Затраты труда (в %) следующим образом распределяется по фазам:
Разработка требований ....................... 5
Проектирование и разработка спецификаций 25
Подготовка программ .... ... 10
Проверка программ.............................25
Комплексирование и испытания..................25
Системная отладка................. . . 10
Все эти данные используются для получения общих затрат труда с учетом коэф-
фициентов, представленных в табл. 29.7.
Вызывает удивление, что о модели сообщалось в докладе, принтжающем зна-
чение оценивания стоимости; при этом отмечалось, что польза может быть полу-
чена только от применения методов современного программирования. В резуль-
Таблица 29.7
Коэффициенты для оценивания затрат труда в модели 7
Фактор Разработка требований Проектиро- вание и раз- работка спе- цификаций Подготовка программ Проверка программ Комплекси- рование и испытания Системная отладка
1 Новое внедрение существующего ПО 0,2 0,2 0,8 0,8
2 Авторский надзор по контракту с 0,7 0,9
покупателем
3. Число программистов: 0,2
1...2 (возможна интерполяция) 0,5 0,8 0,2
6...1С 1,0 1 9 1.0 1,0 1 0
более 20 6.0 3.3 1,2 3,0 3,0
4. ЯВУ (промышленный компилятор) 5 Макроязык для кодирования форм 0,3 0,3 0,9 0,2 0,9
документов 6. Диалоговый ввод программ и дан- 0,9
ных 0,9 0,9
7. Диалоговая отладка 8. Инструментальные средства отлад- 0,6
ки 1,4 1,4
9 Опыт программирования инженер-
но-технических задач:
малый 2,0 3,0 1,5 1.5
средний 1,0 1,0 1,0 1,0
большой 0,6 0,5 0,8 0,7
Примечание. Если в таблице отсутствует значение, то подразумевается коэффи-
циент. равный 1,0.
423
таге такого i тношенги к модели оценки неко, орь'х проектов фирмы Boeing отли-
чались от фактических данных в 5. 6 раз. Здесь сыграли роль переоценка фак-
тора ПСП в одних проектах, в другчх — завышение коэффициента затрат труда,
учитывающего число исполнителей, и отсутствие коэффициента, учитывающего
использование ЯВУ Мотель 7 вначале была рекомендована в справочник прави-
тельства США, но впоследствии перестала применяться.
Модель 8 [59] содержит большое число соотношений для оценивания стоимо-
сть ПО, которые сложны в применениях. В ней используются независимый пара-
метр «число форматов выводов» и таблица коэффициентов затрат труда.
Модели 9 [19]. Эта метамодель основана на точных статистические методах
построенья ypai “еньй и вычисления коэффициентов затрат подобно тому, как это
делае.с: в КОМОСТ
1. Исходный параметр — размер изделия. Уравнения наилучшего приближения
строятся по даннь м проектов и ип.еют вид:
Затраты=д (Размер)ь+с.
2. Другие атрибуты проекта используются для вычисления поправочных коэф-
фициентов в уравнении затрат.
Модель 9 учитывает составной рейтинг общей метэдологии (МЕТ), общей
сложности (СЛОЖИ) и общего опыта разработок. Этот рейтинг учитывается
в формуле ошибки ОШ при оценивании затрат:
Затраты=ОШ[а (Размер)ь+е],
ОШ=</ (МЕТ) +е (СЛОЖИ) +f.
Коэффициенты уравнения вычислялись по данным 18 проектов одинакового типа
в лаборатории программного обеспечения НАСА. В результате получены следую-
щие уравнения:
ЧМразр=ОШ [0,73+ (ЭЧИК)’-,6+3,5],
ОШ=—0,035(МЕТ)+0,98, или
ОШ=—0,036 (МЕТ)+0,009 (СЛОЖИ)+0.80.
Первое уравнение для ОШ было псгтроено с относительной погрешностью
25 .. 16 %, а второе — с относительной погрешностью 15 %.
29.8. ОЦЕНИВАНИЕ КОМОСТ ПО КРИТЕРИЯМ
В этом разделе КОМОСТ оценивается по критериям хорошего
качества модели с учетом современных требований к точности оце-
нивания и в сравнении с рассмотренными выше моделями. Основ-
ными критериями оценивания модели являются критерии, приве-
денные в гл. 28. Рассмотрим их подробнее.
1. Определенность Как только начаты работы по оцениванию
затрат на ПО для распределения бюджета, сразу возникает не-
сколько вопросов: «Включаются ли в оценку затраты на управле-
ние? Какой анализ необходимо провести? Какие подготовительные
работы и операции нужно провести на ЭВМ? Какие функции вы-
полняются при комплексировании и испытаниях? Какими должны
быть управление и сопровождение?» Также возникают вопросы от-
носительно исходных понятий: «поставляемый», «команды», «слож-
ность» и т. п.
В некоторых моделях, например в моделях 6, 8 и 9, предусма-
триваются объективные определения исходных и итоговых поня-
тий, а в других моделях они определены недостаточно точно.
В КОМОСТ по мере возможности предусмотрены определения
основных понятий и количественных характеристик в достаточно
общем виде без ограничений общности модели или разнообразия
проектов ПО. В частности, определения включают понятия фазы,
424
работы и структуры подразделения работ (см. разд. 4.5 и 4.6),
модели и исходных предположений ( см. разд. 5.2), а также деталь-
ной шкалы рейтингов стоимостных атрибутов (см. гл. 24—27).
2. Точность. Как уже отмечалось выше, ошибка в оценках на
20% наблюдалась для 68% проектов базы данных КОМОСТ при
оценивании по промежуточной КОМОСТ и для 70% проектов при
оценивании по детальной КОМОСТ.
Точность КОМОСТ согласована со своей базой данных и по
сравнению с другими моделями является, вероятно, лучшей, по-
скольку размер базы данных достаточно велик, а ее содержание
использовалось для определения всех коэффициентов и параметров
модели. Поэтому не удивительно, что оценки по КОМОСТ весьма
близки к фактическим данным, но этого не наблюдается для дру-
гих моделей. Имеется уверенность в том, что КОМОСТ можно бу-
дет применять и для оценивания будущих проектов ПО (пока еще
не завершены проекты, оцененные по КОМОСТ, кроме двух малых
проектов, оценки для которых совпали с фактическими данными).
Гораздо труднее судить о точности КОМОСТ при получении
распределений затрат по фазам и работам из-за малого числа дан-
ных по фактическим проектам. В утешение можно сказать, что
имеющейся точности достаточно для оценивания влияния различ-
ных атрибутов на стоимость ПО или распределения затрат по фа-
зам и работам.
3. Объективность. Идеальная модель стоимости характеризует-
ся одним стоимостным атрибутом — сложностью, и каждому завер-
шенному проекту приписывается рейтинг сложности в полном со-
ответствии с наблюдаемой производительностью. Таким образом,
модель обусловливается предыдущим опытом. Однако поскольку
рейтинг сложности абсолютно субъективен, то невозможно опреде-
лить его пригодность для будущих проектов Таким образом (и это
подтверждено на многих моделях) при оценивании очень легко
получить любой желаемый результат.
В КОМОСТ предусматриваются различные меры по ограниче-
нию влияния такого субъективного фактора, как сложность:
применение рейтингов сложности на уровне модулей предпочи-
тается их применению на уровне подсистем и систем;
выявление как можно большего числа источников изменения
производительности и их представление в виде отдельных стоимо-
стных факторов, не зависящих от стоимостного фактора сложности
(например таких факторов, как время выполнения программы,
ограничение по памяти, требуемая надежность и т. п.);
использование только шкалы рейтингов, приведенной в табл. 8.4
без привлечения других шкал.
Некоторый прогресс в ограничении влияния субъективных фак-
торов достигнут и в других моделях, например в моделях 3 и 5.
4. Конструктивность. Как указывалось в гл. 21 и 22, при прак-
тическом оценивании стоимости важно сбалансировать алгоритми-
ческие модели с экспертными оценками и оценками исполнителей
Разработок. Различные модели показывают разные результаты,
425
но всегда необходимо ясно представлять, почему одни оценки ниже
фактических, а другие выше. Это же относится к пониманию того,
почему различные рейтинги приводят к различным результатам.
Для поиска ответов на эти вопросы и повышения точности оце-
нивания можно обратиться к таблицам рейтингов (см. гл. 23), учи-
тывающих влияние различных стоимостных факторов на оценку
работ. В целом обнаружено, что такие таблицы способствуют бо-
лее глубокому пониманию работы над ПО пользователями модели.
Полное понимание работы над ПО нужно не для того, чтобы
повесить на него ярлыки с ценами. Первоначальная цель КОМОСТ
в том и состояла, чтобы добиться улучшения понимания работы
над ПО с помощью модели оценивания стоимости его разработки.
5. Детальность. Как отмечалось в разд. 21.4, для моделей оце-
нивания стоимости требуется больше подробных данных, чтобы
обеспечить получение более точных оценок. В основном это связано
с тем, что:
сбор подробных данных позволяет большему, числу людей
разобраться в работе над ПО;
добавление новых подробных данных приводит к тому, что на-
чинает действовать закон больших чисел, увеличивающий точность
конечного результата и уменьшающий различия в оценках. По
этой причине структура КОМОСТ и создана иерархической: от
простой макромодели для получения грубых оценок по базовой
КОМОСТ до микромоделей для получения точных оценок по про-
межуточной и детальной КОМОСТ. Модель 2 тоже является эф
фективной микромоделью и, так же как и модель 8, позволяет по-
лучить детальное распределение затрат по фазам и работам.
6. Устойчивость. Для некоторых моделей, например модели 4,
существуют границы применимости или имеется двойное толкова
ние некоторых входных данных [43]. В КОМОСТ подобные ограни-
чения устранены введением многоуровневых рейтингов для стои-
мостных атрибутов и возможностью интерполяции коэффициентов
затрат.
7. Область применения. Некоторые модели предназначаются для
применения в конкретных областях, например для создания очень
больших проектов ПО, проектов аэрокосмического назначения или
обработки деловой документации. В таких случаях очень трудно
очертить точные границы применимости моделей. Другие модели,
например модель 6, предназначены для очень широкого примене-
ния. КОМОСТ может найти применение при разработке програм-
мных проектов для обработки деловой документации, управления
процессами, человеко-машинного взаимодействия, решения науч-
ных задач, а также проектов вспомогательного и системного ПО;
основной ее недостаток—невозможность применения для малых
проектов с размером менее 2000 ЧИК, для которых получаются
неточные оценки.
8. Простота применения. Модель почти бесполезна, если она
трудна для понимания или применения, если она сложна, напри-
мер, в оценивании стоимости системы, являющейся композицией
426
подсистем. Этого нельзя сказать о стандартных моделях 3 и 5, ко-
торые легки для понимания и применения. В этом отношении
иерархическая структура КОМОСТ относительно проста в приме-
нении.
9. Предсказуемость. Одна из проблем практического использо-
вания модели, описанной в работе [141], состоит в том, что еще до
ее применения необходимо знать размер исходного текста програм-
мы. Обычно число операторов или операндов точно не известно во
время оценивания стоимости. Однако работающие модели, конечно,
включая и КОМОСТ, обычно имеют дело с прогнозируемыми ве-
личинами, которые могут быть достаточно хорошо определены в
самом начале разработки проекта (см. разд. 21.4).
10. Экономичность. Модель тем экономичней, чем меньше вход-
ных данных для нее требуется. Например, в модели, описанной в
работе [291], отдельно учитывается влияние таких методов совре-
менного программирования, как разработка сверху — вниз, приме-
нение структурного кода и использование проверок. В этой моде-
ли важно различать методы, а для практического оценивания про-
ектов достаточно указать фактор «использование ПСП».
Вначале критерий экономичности при оценивании КОМОСТ
учитывался следующим образом:
было показано, что каждый из атрибутов оказывает сложное
влияние на производительность разработки ПО (см. гл. 24—27);
некоторые стоимостные атрибуты были забракованы с целью
уменьшения затрат на оценивание (см. гл. 28).
Однако в КОМОСТ может учитываться больше атрибутов, чем
требуется для конкретного применения. Например, состав исполни-
телей опытного внедрения существенно зависит от опыта работы
в данной прикладной области, с языком программирования и вир-
туальной машиной; поэтому можно учитывать только один общий
фактор — опыт исполнителей — вместо трех отдельных факторов,
что будет рассмотрено подробнее в следующем разделе.
29.9. НАСТРОЙКА КОМОСТ ПЕРЕД ВНЕДРЕНИЕМ
Для большинства случаев оценивания стоимости ПО КОМОСТ
является достаточно хорошей моделью. Однако может потребо-
ваться и специальная настройка модели для обеспечения точности
и простоты использования определенной версии КОМОСТ в кон-
кретном случае. Можно назвать следующие основные случаи, ког-
да производится настройка модели:
уточнение уравнений номинальных затрат в соответствии с
имеющимся опытом разработки ПО;
объединение или исключение лишних стоимостных атрибутов;
введение новых стоимостных атрибутов, имеющих значение для
данного применения модели (например, это могут быть атрибуты,
связанные с обеспечением безопасности или секретности).
Рассмотрим подробнее все эти случаи.
427
Уточнение уравнений номинальных затрат. По различным при-
чинам уравнения номинальных затрат для трех стандартных вер-
сий КОМОСТ могут не подходить для какого-либо конкретного
применения модели. Основные причины этого заключаются в сле-
дующем:
рейтинги стоимостных атрибутов КОМОСТ могут не соответст-
вовать тем стандартам, которые использовались при настройке
КОМОСТ. Это, прежде всего, может коснуться таких стоимостных
атрибутов, как надежность ПО, квалификация и опыт аналитиков
и программистов, практика современного программирования. В та-
ком случае шкалы рейтингов могут быть соответствующим образом
изменены, что часто сопровождается уточнением коэффициентов в
уравнениях номинальных затрат для тех моделей, которые должны
использоваться в конкретном случае;
смысл понятий «поставляемые», «исходные команды», «разра-
ботка» или «человеко-месяц», может быть истолкован по-другому,
чем это принято в КОМОСТ. Простейшим решением этого вопроса
также является уточнение коэффициентов в уравнениях номиналь-
ных затрат;
обычно тип конкретной разработки находится где-то между
стандартными типами разработок. Это также требует уточнения
коэффициентов в уравнениях номинальных затрат в соответствии
с имеющимся опытом разработки ПО.
Рассмотрим основные способы настройки моделей и приведем
соответствующие примеры.
Уточнение множителя. Проще всего учесть имеющийся опыт
при настройке КОМОСТ можно установлением наиболее подходя-
щего типа разработки и уточнением множителя в уравнении за-
трат методом наименьших квадратов по данным существующих
разработок.
Предположим, что на предприятии ведутся разработки програм-
мных проектов распространенного типа. Определим множитель с
в уравнении КОМОСТ для номинальных затрат:
ЧМ = с-КЧИК1’05 П (КЗ), (29.3)
где П (КЗ) — произведение коэффициентов затрат для соответст-
вующих рейтингов стоимостных атрибутов или корректирующий
коэффициент затрат (дальше для краткости просто П).
Предположим, что предприятие завершило разработку проектов
Рь ..., рп с соответствующими размерами этих проектов КЧИКь
КЧИКг, - - КЧИКп, корректирующими коэффициентами затрат
Пь ..., П„ и фактическими затратами на разработки ЧМЬ ..., ЧМП.
Тогда поиск значения с приводит к решению системы линейных
уравнений
ЧМ1с-КЧИК|’с5П1,
ЧМ2 = с«КЧИК2*05П2, (29.4)
ЧМп = с°КЧИКА*05Пп,
428
которая решается минимизацией суммы квадратов ошибок
3= 2 [с-КЧИКЬ05ГЬ—ЧМ,]2. (29.5)
1 = 1
Обозначив КЧИКг*-50 П, через Q,-, получим
5= 2 [cQf — ЧМ;]2.
i = i
Оптимальное_ значение с (с) вычисляется приравниванием произ-
водной dS/dc нулю и решением уравнения относительно с:
0-^-=2$ RQ,—4MJQ1,
de
или
0= 2 (Fq? -4M,Q;),
»=i
откуда
2 ЧМг(?г
с = ~п------. (29.6}
.2 Q?
I — 1
Аналогичные выкладки могут быть выполнены для проектов
встроенного или полунезависимого типов с показателями 1,20 и
1,12 соответственно.
Пример. Предположим, что на предприятии завершена разра-
ботка проектов распространенного типа; данные по пяти проектам
приведены в табл. 29.8. Поскольку фактические затраты на пред-
приятии выше оценки по КОМОСТ, то и оптимальный коэффициент
Таблица 29.8
Уточнение множителя в уравнении затрат по данным
разработок пяти проектов
Номер проекта кчик,. ni чмоц 4Mf <2,- 4M;Q; <2?
1 5 0,75 13 15 4 60 16
2 10 1,00 36 44 11 484 121
3 20 0,80 59 60 19 1140 361
4 30 1,00 114 140 36 5040 1296
5 40 0,70 108 133 34 4522 11 246 1156 2950
429
должен быть больше, чем с = 3,2. Расчеты по данным, приведен-
ным в таблице, дают
S
- 1=1
---------------
1 <2.?
11 246
2950
3,81.
Таким образом, окончательное уравнение затрат для данного
предприятия имеет вид
ЧМ = 3,81 КЧИК1 05П (КЗ).
Уточнение уравнений для новых типов разработок. Метод на-
именьших квадратов может использоваться не только для вычис-
ления множителей в уравнении, но и для получения показателя
степени как характеристики типа разработки, свойственного дан-
ному предприятию:
ЧМ=с-КЧИКьП (КЗ). (29.7)
В качестве первого шага преобразуем это уравнение и затем
прологарифмируем обе его части (здесь используется десятичный
логарифм, хотя можно использовать и натуральный):
с-КЧИКь=ЧМ/П,
log с + ft log (КЧИК) = log (ЧМ/П). (29.8)
Таким образом, если предприятие завершило разработку про-
ектов pi, . . ., рп с размерами КЧИК1, ..., КЧИКп, корректирующи-
ми коэффициентами Пь . .., Пп и фактическими затратами ЧМЬ
. .., ЧМП, то оптимальные параметры уравнения затрат с и b полу-
чаются из решения системы уравнений
logc+Mog (K4HK)i=log (ЧМ/П)Ь
log с Н- b log (КЧИК)г = log (ЧМ/П)2,
.................................... (29,9)
log с + ft log (КЧИК)п = log (ЧМ/П)„,
которая решается минимизацией суммы квадратов ошибок в равен-
ствах (29.9).
Оптимальные значения с и ft могут быть определены решением
уравнений
До log с + Gjft = d0,
gi log с + a2ft = di, (29.10)
где значения ao, <Ц, a2, d0 и dt вычисляются по формулам:
a0 = n,
fli= 2 log (КЧИК),, <4=2 log(4M/n)£,
<=> ,= 1
«2= 2 [log(K4H.K)fF, dx= 2 log (ЧМ/П), log (КЧИК),.
«=1 i=l
430
Окончательные выражения для определения с и b имеют вид:
log ~с= а2^°—fll“1 а^<^1—ai^e
аоа2—а? а0а2—а\
Пример. Результаты вычислений по данным из табл. 29.9:
log с (7-92) (9»25)~(6,08) (11,82) =() 53.
К (5) (7,92)—(6,08)2 ’ ’
Е=3,39; F=(5)(21,82)-(6,08)(9,25) =
(5) (7,92)—(6,08)2
Таким образом, новый тип разработки, свойственной данному пред-
приятию, характеризуется уравнением затрат
ЧМ = 3,39-КЧИК1,0ВП (КЗ).
Таблица 29.9
Уточнение показателя в уравнении номинальных затрат
по данным разработок пяти проектов
Номер проекта (КЧИК)г ni чмг ;iog (КЧИК), [log(K4HK)z]« log(4M/n). log(4M/n>zx X log(K4HK)
1 5 0,75 15 0,70 0,49 1,30 0,91
2 10 1,00 44 1,00 1,00 1,64 1.64
3 20 0,80 60 1,30 1,69 1,88 2,44
4 30 1,00 140 1,48 2,18 2,15 3,18
5 40 0,70 133 1,60 Oj—6,08 2,56 а2=7,92 1,28 d0=9,25 3,65 <4=11,82
Некоторые предостережения относительно уточнения уравнений
для новых типов разработок. Необходимо быть очень предусмотри-
тельными при уточнении уравнений по малому числу завершенных
проектов, как это было показано на примерах. Оптимальные значе-
ния сий весьма чувствительны к относительно небольшим измене-
ниям данных по проектам. Например, если значение ЧМ в проек-
те 1 табл. 29.11 увеличить до 18, то в результате вычислений полу-
чим уравнение
ЧМ = 4,3-КЧИК‘-02П (КЗ),
а если значение ЧМ будет равно 12, то уравнение примет вид
ЧМ=2,46 - КЧИК1 Л9П (КЗ).
Процесс уточнения множителя с является более стабильным.
Так, если значение ЧМ в проекте 1 изменился с 18 на 12, то мно-
житель с изменится незначительно в пределах 3,81 ... 3,82.
Ниже даются некоторые советы, о которых следует помнить при
настройке КОМОСТ и особенно при уточнении уравнений затрат
для новых типов разработок.
431
I. Следует убедиться, что данные по завершенным проектам по
возможности максимально согласованы между собой.
2. Если фактические данные относятся к разработкам разных
типов, то уточнение уравнений затрат нужно проводить отдельно
для каждого типа.
3. Если известны данные только менее чем по 10 проектам, то
надо выбрать одну из стандартных версий КОМОСТ и уточнить
коэффициент в уравнении затрат только для нее, а не для всех
версий.
4. Следует убедиться, что стоимость проектов, использованных
для настройки модели, будет оцениваться с помощью этой модели.
Объединение, исключение или введение стоимостных атрибутов.
Многие предприятия имеют существенно одинаковые типы разра-
боток, конфигурации ЭВМ или используемые виртуальные маши-
ны и языки программирования. Как результат этого стоимостные
атрибуты ОРП, ОРВМ и ОРЯП практически всегда имеют одина-
ковые рейтинги (см., например, [63]). В таком случ'ае предприятие
может объединить эти три атрибута в один — профессиональный
опыт (ПРОП), используя общий коэффициент затрат (табл. 29.10).
Таблица 29.10
Коэффициенты затрат для атрибута ПРОП
Стаж работы ОРП ОРВМ ОРЯП ПРОП Стаж работы ОРП ОРВМ ОРЯП ПРОП
1 мес. 1,29 1,21 1,14 1,78 3 года 1,00 0,90 0,95 0,86
4 мес. 1,29 1,10 1,07 1,52 6 лет 0,91 0,90 0,95 0,78
1 год 1.13 1,00 1,00 1.13 12 лет 0,82 0,90 0,95 0,70
Подобное объединение может быть произведено и для других атри-
бутов, например для ПСП и ИИС. Другие примеры таких объеди-
нений можно найти в работе [19].
Исключению подлежат те атрибуты, рейтинги которых одина-
ковы для всех проектов, разрабатываемых предприятием. Напри-
мер, если предприятие характеризуется слабым интерактивным
взаимодействием, средней изменяемостью виртуальной машины и
значительным использованием инструментальных средств по всем
проектам, то соответствующий коэффициент для пересмотренного
уровня затрат по проектам распространенного типа будет равен
3,2-0,87-1,00-0,91=2,53.
Введение новых стоимостных атрибутов (например, связанных
с обеспечением безопасности или секретности) приводит к опреде-
лению нескольких рейтингов стоимостных атрибутов и их учету в
коэффициентах идеальных затрат.
432
29.10. ТЕМЫ ДЛЯ ДАЛЬНЕЙШИХ ИССЛЕДОВАНИЙ
А. Провести корреляционный и кластерный анализы рейтингов для различных
стоимостных атрибутов.
Б. Проверить гипотезу о различии между типами разработок и группами рейтин-
гов стоимостных атрибутов.
В. Проверить гипотезу о влиянии различных стоимостных атрибутов на распреде-
ление затрат по работам и фазам.
ЧАСТЬ 4В
ОЦЕНИВАНИЕ СТОИМОСТИ И УПРАВЛЕНИЕ
ЖИЗНЕННЫМ ЦИКЛОМ ПО
Правильное оценивание стоимости ПО не является са-
моцелью, а скорее способствует более эффективному управлению
ЖЦПО. В ч. 4В раскрывается несколько важных тем об исполь-
зовании КОМОСТ в течение ЖЦПО: рассматриваются методы
оценивания стоимости сопровождения ПО (гл. 30) и общей стоимо-
сти ПО на протяжении всего жизненного цикла (гл. 31), предла-
гаются методы использования полученных оценок стоимости для
улучшения планирования и управления (гл. 32) и, наконец, об-
суждается проблема повышения производительности разработки
ПО (гл. 33).
General Telephone ВВС США,
and Electronics управление и
контроль (№2)
Рис. 30.1. Стоимости разработки и сопровождения ПО в крупных организациях
Рис. 30.2. Стоимости разработки и сопровождения для 487 проектов, предназ-
наченных для обработки деловой документации
433
ГЛАВА 30
ОЦЕНИВАНИЕ СТОИМОСТИ СОПРОВОЖДЕНИЯ ПО
30.1. ВВЕДЕНИЕ
Большая часть материалов по оцениванию стоимости ПО (как
в этой книге, так и в других публикациях) касается в основном
оценивания стоимости разработки ПО, т. е. затрат на период от
разработки спецификаций требований до приемных испытаний ПО.
Однако основная часть стоимости ПО приходится на сопровожде-
ние ПО после его разработки: сохранение эксплуатационных харак-
теристик ПО и улучшение этих характеристик в течение всего жиз-
ненного цикла.
Стоимость сопровождения ПО составляет 50 ... 75% от общих
затрат на ЖЦПО. На рис. 30.1 [41] показано распоеделение затрат
на протяжение 10-летнего ЖЦПО для различных проектов. Из
рис. 30.2, иллюстрирующего распределение затрат на разработку
и сопровождение, полученное в результате анализа фактических
данных по 487 проектам, видно, что в среднем отношение затрат на
разработку и сопровождение ПО составляет 0,47 ... 0,53.
Хотя на сопровождение ПО приходится существенная часть сто-
имости всего ЖЦПО, довольно мало известно о самом процессе
сопровождения и факторах, влияющих на его стоимость. В этой
главе рассмотрено применение КОМОСТ для оценивания стоимости
сопровождения ПО.
30.2. МОДЕЛЬ СОПРОВОЖДЕНИЯ ПО
Определения. Сопровождение ПО определяется как процесс та-
кого изменения существующего и эксплуатируемого ПО, при ко-
тором сохраняется неизменность его первоначальных функций. При
таком определении исключаются из понятия «сопровождение ПО»
следующие типы работ:
существенные перепроектирование и переработка нового про-
граммного изделия (больше 50% нового кода), выполняющего в
основном те же самые функции;
проектирование и разработка значительных программных паке-
тов (более 20% исходных команд существующего изделия), требу-
ющие некоторого перепроектирования существующего изделия;
изменения в системе обработки данных, модификация базы
данных.
В понятие «сопровождение ПО» включаются следующие ра-
боты:
перепроектирование и переработка малых (меньше 50% нового
кода) порций существующего программного изделия;
проектирование и разработка малых программных пакетов, тре-
бующие некоторого перепроектирования существующего програм
много изделия;
|*34
изменение кодов программного изделия, документации или
структуры базы данных.
Сопровождение ПО может быть классифицировано по двум ос-
новным категориям:
обновление ПО, приводящее к изменению функционального на-
значения программного изделия;
исправление ПО, не затрагивающее функционального назначе-
ния программного изделия.
В свою очередь, исправление ПО классифицируется по трем ос-
новным подкатегориям [283]:
корректирующее сопровождение (обработка, локализация или
исправление ошибок в программах);
адаптивное сопровождение (приспособление к новому окруже-
нию);
совершенствующее сопровождение (улучшение характеристик
или эксплуатационной надежности).
Все эти категории учитываются при оценивании затрат на со-
провождение с помощью КОМОСТ. Кроме того, все предположе-
ния, относящиеся к модели разработки ПО (см. разд. 5.2), целиком
переносятся на модель сопровождения за одним исключением: в
оценку стоимости сопровождения включается оценка стоимости ра-
бот по анализу требований, производимому в процессе сопровожде-
ния (см. рис. 4.6, б).
Оценивание затрат на сопровождение ПО. Основное предполо-
жение, лежащее в основе модели сопровождения ПО, состоит в том,
что стоимость сопровождения определяется такими же стоимост-
ными атрибутами, как и стоимость разработки ПО. Параметр, ис-
пользуемый для определения эквивалентного размера сопровож-
даемого программного изделия, называется коэффициентом пере-
счета годовых изменений (КПГИ) и представляет долю исходных
команд, которые подвергаются изменениям в течение обычного го-
да, а также в результате обновления или дополнения.
Если все затраты по каждому стоимостному атрибуту являются
такими же, как и при разработке, то результирующие годовые за-
траты труда на сопровождение
ЧМГ.С= 1,0-КПГИ-ЧМразр. (30.1)
Однако эти оценки по промежуточной и детальной КОМОСТ могут
изменяться по следующим причинам:
рейтинги стоимостных атрибутов для сопровождения могут от-
личаться от аналогичных рейтингов для разработки (например,
из-за влияния обучения, замены исполнителей и т. п.);
стоимостные атрибуты ТНПО и ПСП характеризуются различ-
ными коэффициентами затрат на сопровождение (табл. 30.1) и на
разработку.
В таких случаях коэффициенты затрат на разработку умножа-
ются на корректирующий коэффициент затрат на сопровождение
(ККЗс). Тогда годовые затраты на сопровождение
435
Таблица 30.1
Коэффициенты затрат на сопровождение
Размер изделия. КЧИК Рейтинг
очень низкий низкий номиналь- ный высокий очень высокий
Любой 1 1,35 Атрибут ТНПО I 1,15 | 1.0 0,98 0,90
2 1,25 Атрибут 1,12 псп 1,00 0,90 0,81
8 1,30 1,14 1,00 0,88 0,77
32 1,35 1,16 1,00 0,86 0,74
128 1,40 1,18 1,00 0,85 0,72
512 1,45 1,20 1,00 0,84 0,70
ЧМГ.С = 1,0- КПГИ • ЧМном • ККЗС, (30.2)
где ЧМном вычисляется по уравнению номинальных затрат в зави-
симости от общего числа исходных команд1 программного изделия:
ЧМном = 3.2-КЧИК105 (распространенный тип),
= 3,0-КЧИК1,12 (полунезависимый тип),
= 2,8• КЧИК1,20 (встроенный тип).
Коэффициент пересчета годовых изменений может быть одинако-
вым для системы в целом или для различных ее компонентов (под-
систем или модулей), для каждого из которых можно воспользо-
ваться уравнением (30.2), а затем просуммировать затраты для по-
лучения общей оценки затрат труда на сопровождение.
4Mr.ci = КПГИ,- • 4M„OMi - ККЗсг, (3G.3)
ЧМГ.С= S 4Mrci.
i=l
Примеры применения этих соотношений для получения оценок
затрат на сопровождение приведены в разд. 5.8 для базовой
КОМОСТ и в разд. 9.5 для промежуточной КОМОСТ.
Измененные коэффициенты затрат. Эти коэффициенты приведе-
ны в табл. 30.1, из которой видно, что увеличивающийся вклад в
обеспечение надежности ПО и использование ПСП при разработке
ПО имеют высокую отдачу на этапе сопровождения. Обсуждение
этих коэффициентов проведено в разд. 8.5.
1 Общее число исходных команд может отличаться от эквивалентного числа
исходных команд, используемого в вычислениях стоимости разработки, и может
включать корректирующий коэффициент адаптации.
436
30.3. СРАВНЕНИЕ С ФАКТИЧЕСКИМИ ДАННЫМИ
Оценка годовых затрат на сопровождение, ЧМ г_
Рис. 30.3. Сравнение оценок затрат на со-
провождение с фактическими данными
На рис. 30.3 проведено сравнение оценок годовых затрат на
сопровождение (полученных по промежуточной КОМОСТ) с фак-
тическими затратами на сопровождение 24 проектов базы данных
КОМОСТ. Эти проекты включают 14 проектов, для которых рей-
тинги стоимостных атрибутов одинаково пригодны для разработ-
ки и сопровождения (точки на рис. 30.3) и 10 проектов, для кото-
рых рейтинги не известны (квадратики на рис. 30.3). Для этих
10 проектов оценки годовых затрат на сопровождение были получе-
ны в предположении, что коэффициенты затрат одинаковы для
разработки и сопровождения.
Представленные на
рис. 30.3 результаты показы-
вают достаточно хорошее
совпадение оценок и факти-
ческих данных. При этом
совпадение несколько хуже
для проектов с одинаковы-
ми коэффициентами затрат
(квадратики).
На рис. 30.4 приведены
значения коэффициентов
идеальных затрат по каждо-
му проекту; вместо коэффи-
циента 1,0 в уравнении
(30.2) можно использовать
другое подходящее значение
для получения оценки, хоро-
шо совпадающей с фактиче-
скими данными. Например,
среднее значение КИЗ (по-
казано стрелкой), равное
1,09, позволило бы получить более точные результаты, чем значе-
ние 1,0. Однако различие столь мало, что для простоты было сохра-
нено значение 1,0.
Среднее значение
I.
-----«4—м—--------------------------1—1—1 «1 1 •-
0,40 0,60 0,80 1,00 1,20 1,40 1,60 2.22 2,50
Коэффициент идеальных затрат, оценки годовых затрат на сопровождение
Рис. 30.4. Распределение коэффициентов идеальных затрат для модели сопро-
вождения
30.4. ДРУГИЕ МОДЕЛИ ОЦЕНИВАНИЯ СТОИМОСТИ СОПРОВОЖДЕНИЯ
Эти модели основаны на простых линейных соотношениях, в
которые входят три основных параметра: стоимость разработки,
размер изделия и число изменяемых команд.
437
Отношение стоимостей сопровождения и разработки. Это отно-
шение (С/Р) используется для оценивания стоимости всего жизнен-
ного цикла сопровождения. Если отношение С/Р определено по
фактическим или оценочным данным, то затраты труда на сопро-
вождение
ЧМс=(С/Р)ЧМразр. (30.4)
Например, для изделия размером 32 КЧИК требуется 100 ЧМ
на разработку и при С/Р = 2,0 (т. е. 67% затрат на сопровожде-
ние) 200 ЧМ на сопровождение.
В модели 3 (см. разд. 29.7) используются отношение С/Р = 1,5
(соответственно 60% затрат на сопровождение и 40% —на разра-
ботку) и «хвост» распределения Рэлея для оценивания затрат на
сопровождение. В некоторых работах приводятся отношения С/Р,
равные 0,67 (или 40% затрат на сопровождение) [51] и 4,5 (или
82% затрат на сопровождение) для прикладного ПО [280].
Отношение перфокарт-на-исполнителя. Это отношение связано
с давно известным положением: «Каждый исполнитель сопровож-
дения ПО может обслуживать четыре ящика с перфокартами».
(Ящик перфокарт содержит 2000 карт, или приблизительно 2000
исходных команд вместе с комментариями.) Вместо числа 4 мож-
Таблица 30.2
Отношение перфокарт-на-исполнителя при сопровождении ПО
Источник Тип ПО (КЧИК/ЧИ)с
КОМОСТ (очень низкий рейтинг) [314] [Ю9] КОМОСТ (рейтинг 25 про- центилей) [79] [139] [ЮО] [136]. [136] КОМОСТ (рейтинг 50 про цеитилей) [165] КОМОСТ (рейтинг 75 про- центилей) [79] КОМОСТ (очень высокий рейтинг) Аэрокосмического назначе- ния Аэрокосмического назначе- ния Реального времени Реального времени Обработки деловой доку- ментации Обработки деловой доку- ментации, ЯВУ Обработки деловой доку- ментации, моя Обработки деловой доку- ментации, 487 проектов Вспомогательное 3 8 10 10 10...30 12 20 20 22 25 32 36 30... 120 132
438
но рассматривать число 3 или 7, или другое число из указанного
диапазона, и это позволит примерно оценить число исполнителей
сопровождения.
Рассмотренное отношение обычно выражается в (КЧИК/ЧИ)С,
тогда число исполнителей ЧИС для сопровождения изделия разме-
ром КЧИКразр оценивается как
ЧИ ___ КЧИКразр
‘ 0 ' (КЧИК/ЧИ)С
(30.5)
Годовые затраты труда на сопровождение
ЧМГ.С = 12 ЧИС.
Таким образом, для изделия размером 32 КЧИК с отношением
(КЧИК/ЧИ)С= 16 потребуется 32/16=2 исполнителя сопровож-
дения и годовые затраты труда на сопровождение составят 12-2=
Рис. 30.5. Влияние языка про-
граммирования на число ис-
полнителей сопровождения
ПО:
ф — машинно-ориентированный
язык (МОЯ): — язык высокого
уровня (ЯВУ)
= 24 ЧМ. В табл. 30.2 приведен достаточно широкий диапазон от-
ношений перфокарт-на-исполнителя. Изменения значений этого
отношения обусловливаются прежде всего его зависимостью от
типа применяемого ПО.
Другой очень важный аспект, нашедший отражение в данных
табл. 30.2, проявляется в зависимости приведенных отношений От
языка программирования (ЯВУ или МОЯ [136]). Программа на
МОЯ получается в результате компиляции программы на ЯВУ на
язык ассемблера (с коэффициентом увеличения числа команд по
сравнению с числом команд на ЯВУ от 2,5 до 15, см. табл. 28.1).
Это частично объясняет тот факт, что стоимость сопровождения
программ на МОЯ выше стоимости сопровождения программ на
ЯВУ. Результаты сравнения числа исполнителей сопровождения
программ, написанных на ЯВУ и МОЯ, показаны на рис. 30.5.
Отношение, характеризующее производительность сопровожде-
ния. Отношение (ЧИК/ЧМ)Изм представляет собой среднее число
команд, которые могут изменяться за человеко-месяц зо время со-
провождения, и может быть использовано для оценивания затрат
на сопровождение изделия размером ЧИКразр с помощью коэффи-
циента пересчета годовых изменений:
ЧИКВЗМ/Г = клги - чикраар,
439
чм-= (чик;Х~- (306)
Так, изделие размером 32 КЧИК с КПГИ = 0,1 и производитель-
ностью сопровождения (ЧИК/ЧМ)Изм=200 будет иметь
ЧИКизм/г = 0,10-32 000 = 3200 и
ЧМГ.С = 3 200/200= 16 ЧМ.
Ниже приведены результаты усреднения данных по 487 проек-
там обработки деловой документации [185]:
Размер программы............... 48,0 КЧИК
Изменение числа команд в год . 4,4 КЧИК
КПГИ 4,4/48,0=0,092
ЧИс................................... 1,52
(КЧИК/ЧИ)С......................... 48/1,52=32
(ЧИК/ЧМ)из„................. 4400/(2X1.52) =241
Другие значения КПГИ и (ЧИК/ЧМ) изм для сопровождения ПО с
низким, средним и высоким рейтингами приведены в табл. 30.3
[47]. С помощью этих данных можно определить, насколько про-
граммное изделие является простым или сложным, а также полу-
чить оценку общих годовых затрат труда на сопровождение ПО в
ЧМгс, используя уравнение (30.6) и соответствующие значения
КПГИ и (ЧИК/ЧМ).изм.
Сравнение с данными КОМОСТ. Рассмотренные выше отноше-
ния полезны лишь для приближенного оценивания затрат на со-
провождение ПО, а большой диапазон их изменения (из-за чувст-
вительности к другим стоимостным факторам) делает их непри-
годными для планирования ЖЦПО, в соответствии с которым
должны приниматься конкретные бюджетные обязательства.
Диапазоны изменения этих отношений представлены в
табл. 30.4. Средние значения отношений для проектов базы данных
КОМОСТ ниже аналогичных средних значений для проектов,
предназначенных для обработки деловой документации [185]. Эти
расхождения в основном отражают различия в типах ПО и пред-
ставлены в табл. 30.5.
Таблица 30.3
Производительность сопровождения
Рейтинг Тип ПО (ЧИК/ЧМ)иэи КПГИ
Низкий Ввода-вывода (для универсальной ЭВМ) 500 0,15
Средний Вычислительные и логические, обра- ботки сигналов 250 0,05
Высокий Обслуживания файлов, ввода-вывода в реальном времени, использования базы данных и ее изменения 100 0,01
440
Таблица 30.4
Диапазон изменения параметров, характеризующих
сопровождение ПО по проектам базы да. иных КОМОСТ
Параметр Рейтинг
низкий 25 про- центилей средний 75 про- центилей ВЫСОКИЙ
(КЧИК/ЧЧ)с 3,2 10 25 36 132
1ИК/ЧМ)изм 36 88 164 250 1238
КПГИ 0,01 0,05 0,08 0,20 0,40
Другое назначение табл. 30.4 состоит в использовании приве-
денных в ней данных для проверки правильности параметров, по-
лученных при анализе процесса сопровождения ПО. В среднем
Рис. 30.6. Интегральное
распределение отноше-
ния перфокарт-на-испол-
нителя
один исполнитель может сопровождать программу размером 50
КЧИК. Из рис. 30.6 видно, что значение 50 (КЧИК/ЧИ)С соответ-
ствует 85% проектов в базе данных КОМОСТ.
30.5. ОБЩАЯ ХАРАКТЕРИСТИКА СОПРОВОЖДЕНИЯ ПО
Производственная функция сопровождения. Сопровождение ПО
так же характеризуется производственной функцией, которая уста-
навливает связь объема производства с затратами, как это было
рассмотрено в разд 11.2 для разработки ПО. Типичная производ-
ственная функция сопровождения ПО показана на рис. 30.7.
Участок инвестирования включает работы по сопровождению,
которые могут быть выполнены при условии, что программа не вы-
ходит из строя; в программе устраняются ошибки, обеспечиваются
приспособление к изменениям программного окружения (ТО, ОС,
главная база данных, входные данные) и обязательные усовершен-
ствования (например, обновление требований).
Участок высокой отдачи включает учет первичных запросов
пользователей, первичное повышение эффективности программы,
ее надежности и улучшение документации, а также учет вторич-
ных запросов пользователей, еще обеспечивающие прибыль.
Участок сокращения отдачи включает, как и для разработки
ПО (см. рис. 11.5), бесконечные доработки по улучшению про-
441
и
Таблица 30.5
Данные по сопровождению проектов ПО1
Проект: Сравнение оценок и фактических данных: |
Атрибуты
Атрибуты ЭВМ
Аналитик:_______
Атрибуты Ат[ ибут, I
исполнителей проекта
Дата:
PROJ. NO TYPE LANG. KDSI Mode -J о cc RELY (*) DATA @ i CPLX (a?) Ш @ HOIS VIRT @ (?) NURI ACAP AEXP @ PCAP (5) X LU > LEXP @ МГ2Р (g) TOOL (5) SCED (S) EAF @ MM NOM (§) О < MM EST (£) MM ACT (g)
1 BUS 72 COB 113 E 1.0 0,88 1,i5 о.ав -— VO 1.13 1,0 1.10 1.39 1.24 1.0 1.04 2.59 2,72 814 0.05 105 156 -33
3 BUS 77 PLI 132 sr 1,0 c.86 — 1.0 0.8b 0, t5 0.91 0.43 0.34 711 0.04 12.2 17 2
14 CTL 77 MOL 30 SB 1.0 1.19 олТ 1.15 1,0 t.15 — 1.0 1,10 1|O 1.07 1.12 1.10 1.0 1,13 2.57 5.86 Ю.З 0,15 4.© 6 -33
22 HMl 76 JOV 118 E — 0.85 0.91 1.0 1,23 0,71 0,94 858 0.33 2C1 180 12
23 hmi 78 HOL 77 E — 1.0 1,23 0.72 0.89 514 0.25 93 120 -22
28 HMI 72 MOL 13 ORG t,o 1.15 — 1,14 1,10 2,53 2,81 47 0,12 14 8 75
32 SCI 72 FTN 390 SB 1.15 0.88 1,0 0.71 — 0.90 1.0 0,95 1,0 1.19 1,10 1.0 1,10 0,88 0.57 2394 cog 169 IRC -10
38 SCI 77 PLI 15 ORG — 0.76 0.82 0,32 0,35 55 0.33 5.8 4 45
39 SCI £4 FTN 6.2 ORG — 0,90 1.0 0.89 0,91 0.34 0,39 22 0,40 Ъ,о 2.4 25
51 SUP 70 COB 10 ORG 1,0 1.38 U5 0.88 — 0.91 1.0 0,00 1.0 1.30 1.24 1.0 1,04 2.48 3.18 36 0,03 2.7 3 -10
1 Использованные в таблице обозначения в основном совпадают с обозначениями в
табл. 29.1; отличия рассмотрены в разд. 30.6 — Пррм. ред.
Таблица 30.5 (окончание)
Проект: Сравнение оценок и фактических санных: 11 Аналитик:-------Дата*»» —
Атрибуты Атрибуты
Атрибуты изделии Атрибуты ЭВМ исполнителей проекта
PRO J. NO ТУРЕ YR LANG. KDSi Mode @ О u UJ cc DATA (w) CP LX (®) 0 Ш s H STOR @ VIRT @ TURN (3) ACAP @ AEXP @ PCAP (B) VEXP (S LEXP @ MODP @ TOOL (5) SCED @ EAF (5) Mmkjm (§) ’ ACT (g) MM EST (§) MM ACT (§)
SI sup 71 MOL 8.2 ORE 1.0 1.15 1, О 1.17 1.3o 1.0 1.74 29 0,05 2.5 3 -17
i.ia 0.88 1.15 1.0 1.24 1.1 о «.90
56 SYS 71 MOL 27 E 1.0 0.98 0.87 0,82 1. О 1. C 1.16 1.0 1.47 146 0,025 5,4 12 -55
1.38 1.15 1.0 0,91 1.40 to? 1.Ю 1.08 S.68
5S SYS 7C MOL 25 E 1.10 t.o 1.0 0,86 1.63 133 0.05 10,8 12 -10
1,4o 0.71 0.70 0.91 1.09
18 HMi 70 FTN S20 £ 1.0 0,98 1.0 0,91 1.17 0.9© 0.95 1.43 l.o 1.0 2.86 2840 0,10 8t2 9oo -10
I.W 1.15 0.86 1.0 1.0 1.0 f.O 1.24 1.10 I.o8 3.89
Итоговые данные MM DEV
Ml RUS 7C COB so 3 CO 0.06 48 12 so
М2 BUS 77 COR 100 48o o,o8 38 36 6
МЛ 8115 77 COR 65 273 O.oi 2.7 6 -55
М4 CTL 75 MOL 26 288 0.07 2c 18 11
М5 HMl 74 FTM 2 04 2250 ©,2c 450 156 4o
Мб SCI 76 FTN 12 4-G о.ЗЗ 15 A 150
М7 sci 77 FTN 42 281 QO24 6.7 5.9 14
М8 SCI 7Я FTN 176 877 0,10 Й8 70 26
му SCI 78 FTN 25 4o 0.2o 8 2o -6©
мк SYS 76 MOL 65 1H5 0.06 C7 . 72 -7 m
443
^рамм (перезапись плохо структурированных, но отлаженных моду-
лей и т. п.). Все это еще приносит прибыль, но уже меньше той,
которую могли бы дать вложения затрат на первых участках.
Динамика сопровождения ПО. Вопрос о размере затрат решает-
ся организацией-пользователем в соответствии с ее возможностями
и желанием производить затраты на том или ином участке произ-
водственной функции. Методы количественного и качественного
Инвестирование
Высокая отдача | Сокращение
। отдачи
Вторичные улучшении
20 40 60 80 100
Бюджет на сопровождение ПО, %
Рис. 30.7. Производственная функция сопровожде-
ния ПО
экономического анализа, рассмотренные в ч. 3, могут помочь в по-
лучении прибыли, но ими нельзя подменить здравый смысл.
Как только некоторая организация определяет свой уровень со-
провождения программного изделия, в особенности большого из-
делия, социальная, экономическая и политическая инерция орга-
низации затрудняет осуществление значительных изменений в
уровне затрат или режиме работы. В некоторых случаях увеличе-
ние вложений на первом участке производственной функции или
значительное увеличение вложений, обусловленных расширяющим-
ся или изменяющимся рынком программных изделий, может вы-
звать дестабилизацию или переориентацию организации. Однако в
444
большинстве случаев работа по сопровождению все-таки находит-
ся в предсказуемом равновесии.
В работах [29, 183, 316] подробно излагается эволюционная ди-
намика сопровождения ПО и формулируются «законы эволюции
больших программ», которыми являются:
1. Постоянные изменения. Большая программа подвергается по-
стоянным изменениям или постепенно становится менее полезной
(в соответствии с рис. 30.7 это означает, что все большие програм-
мы имеют неочевидный участок инвестирования).
2. Увеличение сложности. По мере увеличения числа изменений
в большой программе увеличивается ее сложность, если не прово-
Рис. 30.8. Динамика сопровождения ОС/360
дится работа по ее сопровождению. Хорошим примером является
динамика сопровождения ОС/360 (рис. 30.8) [29], к которой вы-
двигались требования на изменение все большего числа модулей,
что порождало все большее число побочных эффектов.
3. Основной закон эволюции больших программ. В процессе
эволюции больших программ реализуется циклическое саморегу-
лирование общих атрибутов проекта и системы.
4. Постоянство темпов работы. Общий темп выполнения боль-
шого программного проекта статистически инвариантен. (При этом,
как отмечалось выше, возможны исключения, связанные с сущест
венными изменениями требований или нарушениями непрерывно
сти, как, например, при периодических запусках космических лета-
тельных аппаратов с экипажем.)
5. Сохранение документации. Для надежности и планируемой
эволюции большой программы ее версии должны выпускаться по
возможности без изменения документации (и с минимальным вре-
445
менем между выпусками версий; см. обсуждение изменяемости вир-
туальной машины в разд. 25.3).
Распределение затрат труда по работам в период сопровожде-
ния. Хотя полезный участок производственной функции сопровож-
дения ПО, представленной на рис. 30.7, не может быть определен
количественно, некоторые ее участки могут быть разумно оценены
в стоимостном отношении. Благодаря исследованию 48' проектов
обработки деловой документации (см. работу [185]) теперь
имеется более ясная картина распределения затрат на сопровожде-
ние ПО.
Рис. 30.9. Распределение затрат труда на сопровождения ПО
Рис. 30.10. Распределение затрат на учет запросов пользователей
На рис. 30.9 показано типичное распределение затрат труда на
сопровождение по основным категориям: обновлению и исправле-
нию. Для корректирующего сопровождения ПО, обычно основной
части бюджета на сопровождение, требуются относительно неболь-
шие затраты (21,7%). Таким образом, отсутствие ошибок при раз-
работке ПО не устраняет необходимости в наличии больших
средств на сопровождение ПО.
Основные затраты (41,8%) приходятся на обновление прогоамм
(учет запросов пользователей). На рис. 30.10 показано распределе-
446
ние затрат труда, связанных с обновлением программ, касающимся
обработки записей. Видно, что гибкость структуры данных и воз-
можности генерации сообщений играют важную роль в повышении
эффективности сопровождения ПО.
Представленное на рис. 30.9 распределение затрат по работам
является ключом к определению затрат на отдельных участках про-
изводственной функции сопровождения ПО. Значительная доля
затрат (40 ... 50%) приходится на участок инвестирования. С точ-
ки зрения планирования ЖЦПО из сказанного можно сделать
вывод о важности сопровождения ПО. На каждый доллар, который
тратится на разработку ПО, должен быть предусмотрен еще один
доллар на сопровождение. Для долгоживущей программы сопро-
вождение требует меньших затрат, чем разработка. Некоторые по-
лезные сведения о практических методах сопровождения ПО мож-
но получить из работ [131, 229].
30.6. ДАННЫЕ ПО СОПРОВОЖДЕНИЮ ПРОГРАММНЫХ ПРОЕКТОВ
В табл. 30.5 представлены данные по программным проектам,
которые подтверждают правильное гь модели сопровождения. Они
относятся к четырнадцати программным проектам базы данных
КОМОСТ (см. табл 29.1) и к десяти дополнительным проектам,
для которых известны только конечные данные по разработке и со-
провождению.
По четырнадцати проектам определены все характеристики с
использованием варианта ФОК КОМОСТ (см. разд. 9.5). Отличия
от стандартной формы состоят в следующем-
Номер
колонки
1 Номер проекта в базе данных КОМОСТ (см. табл. 29.1), тип, год
разработки и язык
3 Этот коэффициент используется для исключения атрибута ИТ (из-
меняемость требований) при сопровождении; его влияние учитыва-
ется с помощью коэффициента пересчета годовых изменений
19 Корректирующий коэффициент адаптации
20 Номинальные затраты труда на сопровождение, ЧМЯОЫ, и затраты
труда на разработку, ЧМра3р
21 Коэффициент пересчета годовых изменений
22 Оценка годовых затрат труда на сопровождение, ЧМ,. с, оц
23 Фактические годовые затраты труда на сопровождение, ЧМГ. с, факт
24 Относительная ошибка, (ЧМГ. с, оц, ЧМГ. <. факт)/ЧМг. с, факт, %)
По десяти проектам приведены затраты на разработку (колон-
ка 20). Они используются для оценивания зато ат на сопровожде-
ние по формуле
ЧМГ.С.ОЦ=ЧМра3р - КПГИ.
В этих вычислениях предполагается, что рейтинги стоимостных
атрибутов для разработки и сопровождения совпадают. Такое, ко-
447
нечно не совсем верное, решение приведет к разбросу результатов
(по двум проектам в 2,5 раза).
В заключение следует отметить, что производственные функции
сопровождения нуждаются в уточнении. Необходимо также учиты-
вать такие факторы, как использование библиотек программ, раз-
работка дополнительных машинных команд, переработка базы
данных пользователя, построение абстрактной базы данных, что
улучшает методы сопровождения.
Различное влияние на сопровождение ПО оказывают и другие
факторы:
языки программирования [97, 136] ;
количество и качество документации [272];
частота использования программного изделия [1];
приближение пользователя к системе обработки данных [185].
ГЛАВА 31
ОЦЕНИВАНИЕ СТОИМОСТИ ЖИЗНЕННОГО ЦИКЛА ПО
31.1. ВВЕДЕНИЕ
Первоначально стоимость ЖЦПО складывалась из стоимостей
разработки, сопровождения и адаптации существующего ПО. Од-
нако на стоимость ЖЦПО большое влияние могут оказывать пере-
нос и опытное внедрение ПО, обучение, стоимость ЭВМ, публика-
ции, перевозка и т. п., о стоимости которых известно еще мало.
В этой главе обобщаются имеющиеся данные и приводятся соот-
ношения, позволяющие оценить стоимость ЖЦПО.
31.2. СООТНОШЕНИЯ ДЛЯ ОЦЕНИВАНИЯ СТОИМОСТИ ПЕРЕНОСА ПО
Стоимость переноса ПО может быть очень важным компонен-
том стоимости ЖЦПО. По оценкам Главного контрольно-финансо-
вого управления США стоимость переноса ПО, использованного
правительством США в 1977 г., составила около 450 млн. долл.
[121].
Определения. В оценку по КОМОСТ входит стоимость переноса
ПО, который складывается из работ, указанных в структуре под-
разделения работ, приведенной на рис. 4.6, б: перенос программ,
баз данных и документации; подтверждающие проверки и прием-
ные испытания переносимого ПО; описание итогов переноса. В сто-
имость переноса ПО не входят стоимости оборудования, демонстра-
ции по эксплуатации, обучения, сопровождения программного из-
делия, адаптируемого в новых версиях операционных систем, эво-
люционных изменений в основной базе данных или изменений в
числе устройств управления магнитными лентами или терминалами.
Основными этапами переноса, которые требуют затрат, явля-
ются [228]:
448
1. Анализ возможностей: анализ состояния используемого ПО,
документирование всех аспектов переноса существующего ПО,
определение наилучшего подхода к переносу.
2. Планирование переноса: преобразование ПО, переносимого
на ЭВМ с новой конфигурацией; установление сроков переноса;
разработка критериев правильности переноса и планов проверки.
§. Подготовка переноса: получение и подтверждение данных
для проверки, подготовка вспомогательных устройств для перено-
са (трансляторов, устройств сравнения, программ передачи фай-
лов и т. п.), ассемблирование переносимых программ.
4. Перенос программ, данных и документации; управление кон-
фигурацией ЭВМ и контроль качества.
5. Комплексирование и испытания устройств, подсистем, систе-
мы ПО и программы тестирования.
Более подробное описание этих этапов дано в работе [228].
Соотношения для оценивания стоимости переноса. При оцени-
вании стоимости переноса ПО в КОМОСТ перенос рассматривает-
ся как частный случай адаптации существующего ПО к новым при-
менениям. При этом определяется эквивалентное число исходных
команд (ЭЧИК), которое используется далее вместо ЧИК во всех
соотношениях для оценивания стоимости. Значение ЭЧИК вычис-
ляется аналогично тому, как это делалось при рассмотрении адап-
тации ПО (см. разд. 8.8).
Чтобы получить оценку затрат на перенос, корректирующий
коэффициент адаптации (ККА) увеличивается на коэффициент
планового увеличения переноса (КПУП) для учета дополнительной
стоимости этапов анализа возможностей и планирования переноса,
не включаемой в оценку затрат на адаптацию. Рейтинг КПУП за-
висит от содержания этих этапов:
Рейтинг Анализ возможностей и планирование переноса
КПУП
О Отсутствуют
1 Установление сроков простого переноса, разработка плана приемки
2 Установление сроков детального переноса, разработка планов про-
верки и приемки
3 Дополнительный анализ кодов и данных
4 Подготовка основной документации на существующую систему
5 Подготовка подробной документации на существующую систему
После вычисления корректирующего коэффициента переноса
ККП = ККА + КПУП (31.1)
можно рассчитать эквивалентное число исходных команд:
ЭЧИК = ЛЧИК-ККП/100. (31.2)
Значение ЭЧИК может быть использовано для вычисления сто-
имости переноса по уравнениям затрат базовой, промежуточной
или детальной КОМОСТ с учетом соответствующих рейтингов. При
этом следует воспользоваться таблицей коэффициентов затрат
(см. табл. 30.1), которая лучше всего отражает трудности перено-
15 Зак. 628
449
Прос<Т.^П|рЙ1ве программы анализа схемы
Дата: 01.01.84
Изделие
ЭВМ
Исполнители
Аналитик: Фамилия
Проект
© Компо- нент ЭЧ ) ЛК О ККА 0 ТНПО © РБД © сиз О ОБД © ОП © HBrv © ЦО ® КА © ОРП © КП ® ОРВМ © ОРЯП © ПСП © ИИС ® ОСР ® ККЗ © г X S т г1; У > а S У (221 I S "У S У о © с с S у ь долл./ЭЧИК ©
, ЕСАР 10 6 21 Высок 0.98 Высок, 1.15 Высок. 1.06 — — — Очень высок 0.82 — Зыпок О.9С1 Высок. 0,90 — — — 0,84 38 32 —
2. —
3. — —
4. — —
б. — —
6. — —
7. — —
8. — —
9. — —
10. — —
11. 10 5 O6i 'ее ЭЧИК Итого 32
12. 38 ЧМиом Тил разработки: Распространенный Сроки, мес.
276
13.
(ЭЧИК/ЧМ) ном
Рис. 31.1. Оценивание стоимости переноса программы анализа электронной схемы
са ненадежного, плохо структурированного и плохо документиро-
ванного ПО.
Пример. В качестве примера получим оценку стоимости переноса программы
анализа электронной схемы размером 50 КЧИК, написанной на Фортране, с ЭВМ
Univac 1110 на ЭВМ IBM 3033. Предположим, что программа имеет оверлейную
структуру и размер машинного слова изменяется с 36 на 32 бита. Для повышения
эффективности программы требуется некоторое ее перепроектирование, например,
ДИП=15 (некоторые изменения в оверлейной структуре, численных алгорит-
мах и логике);
ДИК=30 (изменения кода в два раза превышают изменения проекта);
СИП = 10 (изменения в комплексировании, связанные с изменениями в овер-
лейной структуре)
Для таких изменений КПУП—3. Следовательно,
ККА=0,4-15+0,3-30+0,3-10= 18,
ККП= 18+3=21,
ЭЧИК=50 000-21/100= 10 500.
Затраты на перенос программы указаны на бланке для поком-
понентной оценки (БПКО) промежуточной КОМОСТ (рис. 31.1).
Для большинства стоимостных атрибутов использованы номиналь-
ные рейтинги, высокие ретийнги использованы для ТНПО, СИЗ,
ОП, ОРВМ и ОРЯП и очень высокие — для ОРП.
Итоговая оценка затрат на перенос 32 ЧМ является несколько
завышенной, но еще удовлетворительной и близкой к средней оцен-
ке 26 ЧМ.
31.3. СРАВНЕНИЕ ОЦЕНОК СТОИМОСТИ ПЕРЕНОСА С ФАКТИЧЕСКИМИ
ЗАТРАТАМИ
На рис. 31.2 проведено сравнение оценок затрат на перенос с
фактическими затратами по девяти проектам.
Другие модели и данные по переносу. Существует еще очень
мало данных и моделей для оценивания стоимости переноса ПО.
Хороший анализ этого вопроса проведен в работе [228], где рас-
смотрена модель для оценивания различных компонентов стоимо-
сти переноса ПО и даны наглядные примеры оценивания. В каче-
стве примера в табл. 31.1 приведены обобщенные значения произ-
водительности переноса ПО, полученные с помощью указанной
модели при использовании КОМОСТ.
Таблица 31.1
Производительность переноса ПО
Доля кодов, переносимых вручную. % 1228] КОМОСТ
Размер программы, кчик долл./ЧИК ЧИК/ЧМ чик/чм ККП
0...10 30 1,70 1823 3750 8
10...25 15 2,83 1095 1500 20
25...50 9 3,12 993 750 40
15*
451
В КОМОСТ производительность переноса оценивается следую-
щим образом. При типичном значении производительности разра-
ботки ПО (ЧИК/ЧМ)р1.зр = 300 и использовании соотношения
ККП/100 = ЧМп,ЧМра3р = (ЧИК/ЧМ)ра3р/(ЧИК/ЧМ)п
получаем
(ЧИК/ЧМ)п=300/(ККП/100)=30000/ККП.
Можно отметить довольно плохое совпадение оценок по КОМОСТ
и данных из работы [228], но р: схождение находится в пределах
изменения входных данных. Основное преимущество в подходе,
принятом для КОМОСТ, состоит в том, что изменение оценок хо-
рошо согласуется с изменением числа переносимых команд.
В работе [228] содержится также и другая полезная инфор-
мация для оценивания стоимости переноса ПО’
Распредзление исполнителей
(по оплате), %
Распределение затрат, %
Распределение работ
(по времени), %
7 (управленческий персонал)
76 (технический персонал)
7 (вспомога>ельный персонал)
10 (сл> жащие)
60 (исполнители)
25 (ЭВМ)
15 (прочее)
25 (по хготовка)
15 (передача)
50 (тестирование)
10 (опытное внедрение)
Другой подход к оцениванию стоимости переноса ПО и дру-
гие статьи расходов описаны в работе [89]. Этот подход класси-
фицирует различные этапы переноса ПО (обновление документа-
ции, изменение ТО и ОС, повышение надежности и т. п.) и предо-
ставляет функциональные зависимости для оценивания стоимости
переноса с помощью параметров, полученных в результате стати-
стического анализа данных по опытному внедрению ПО в прави-
Оценка по КОМОСТ, ЧМ
Рис. 31.2. Сравнение оценок за-
трат на перенос с фактическими
данными
тельственных учреждениях и про-
мышленности. В эти зависимости
входят число исходных команд,
которые должны быть перенесе-
ны, доли затрат труда системно
го программиста, главного и
младшего программистов, участ-
вующих в работах по переносу
программ различного типа, и про-
изводительность изменения ПО
различными исполнителями. В
табл. 31.2 приведены значения про-
изводительности изменения кода
ПО для различных исполнителей.
Недавно завершено подроб-
ное изучение методов оценивания
стоимости переноса ПО, прове-
денное Федеральным центром
Таблица 31.2
Производительность изменения кода ПО, ЧИК/ЧМ*
' Исполнитель Тип ПО
Прикладные программы Операционные системы Компиляторы
Системный аналитик Главный програм- мист Рядовой програм- мист 1460 (1090 1810) 1520 (1200 1840) 1140 (880... 1400) 940 (670... 1230) 940 (650... 12501 550 (290 ..820) 590 /360...820)
* Приводятся средние тервал. значения, в скобках указан ЭО^процентный доверительный ин-
переноса ПО США [152]'. В результате дана полная классифика-
ция и проведен сравнительный анализ различных методов оцени-
вания стоимости переноса ПО. Хо^я предложенная модель еще не
полностью проверена и подтверждена, полученные при ее исполь-
зовании оценки вполне обоснованы и применимы в достаточно
широком диапазоне характеристик программных изделий!
31.4. ОЦЕНИВАНИЕ СТОИМОСТИ ОПЫТНОГО ВНЕДРЕНИЯ (ПОСТАВКИ)
ПО И ОБУЧЕНИЯ
Определения. В стоимость опытного внедрения ПО включается
стоимость работ по комплексированию ПО для обеспечения требу-
емого сочетания характеристик ПО, оборудования, персонала и
процедур, выполняемых ОС пользователя. В стоимость опытного
внедрения не включается стоимость установки ЭЗМ (обычно со-
ставляющая примерно 3% от затрат на приобретение ТО), но вклю-
чается стоимость планирования, контроля и документирования
внедрения. В опытное внедрение входят:
ориентация пользователя;
ознакомление пользователя с моделью ЭВМ, версиями ОС и
СУБД, языком управления заданием, типами и числом периферий-
ных устройств, интерфейсами устройств и системы и т. п.;
подготовка к эксплуатации базы данных;
испытание возможностей ПО на оборудовании пользователя;
выявление ошибок, корректировка документации и консуль-
тации;
проверка отчетности после опытного внедрения.
Документирование опытного внедрения достаточно подробно
описано в работе [149].
Стоимость обучения применению программ включается в стои-
мость обучения пользователей, персонала, обслуживающего ЭВМ,
и операторов подготовки данных, а также исполнителей сопровож-
дения ПО, если они не являются одновременно и разработчиками.
Стоимость обучения разработчиков учитывается в коэффициенте
453
затрат, отражающем опыт разработчика в прикладной области,
работе с виртуальной машиной, языком программирования.
В стоимость опытного внедрения не включается стоимость ра-
бот, связанных с участием пользователей в процессах опытного
внедрения и обучения (например, стоимость обучения обслужива-
ющего персонала). Однако при определении стоимости проекта в
целом указанные компоненты должны обязательно учитываться.
Модели и данные о стоимости опытного внедрения и обучения.
Эти данные весьма скудны и разбросаны по различным источни-
кам. В табл. 31.3 собраны данные из базы данных КОМОСТ. За-
Таблица 31.3
Стоимость опытного внедрения ПО и обучения
Тип ПО Число проектов Доля от затрат на разработку. %
Внедрение Обучение
Прикладные программы для общецелевых ЭВМ 4 0; 0; 0,2; 0,6 0; 10; 1,2; 3
Прикладные программы
для специальных ЭВМ 3 0,2; 0,5; 0,8 2; 0; 2,7
Программы управления процесса-
МИ
для новых ЭВМ 3 3; 3; 4 1,3; 1,3; 1,9
Программы поддержки человеко- машинного взаимодействия:
3 одинаковых внедрения 1 8 6
5 одинаковых внедрений 1 6 3
16 одинаковых внедрений 1 18 7
3 различных внедрения 1 20 6
8 различных внедрений 1 14 8
траты на опытное внедрение и обучение классифицированы по ти-
пам ПО и выражены в процентах от затрат на разработку ПО.
По данным работы [124] затраты на опытное внедрение состав-
ляют 2,3% от затрат на разработку ПО для ВВС США. Из них
1,8% затрат расходуется на контроль в процессе эксплуатации и
подтверждение, 0,3%—на координацию пользователей и 0,2% —
на подготовку системы к работе. Для модели из работы [59] за-
траты на опытное внедрение составляют 2,5 ... 7,5% от затрат на
разработку ПО.
Рекомендуемые процедуры оценивания. Так как стоимости опыт-
ного внедрения и обучения пользователей варьируются в широких
пределах, рекомендуется разделять эти стоимостные компоненты и
производить их оценку отдельно, но с учетом работ по управлению
и вспомогательных работ.
31.5. ОЦЕНИВАНИЯ СТОИМОСТИ ЭВМ В РАЗРАБОТКЕ ПО
Используемое при разработке ПО машинное время изменяется
в широком диапазоне и зависит от большого числа факторов. Авто-
ру книги в первый день его работы программистом в 1955 г. было
сказано:
454
Мы платим за ЭВМ 600 долл, в час, Вам платим 2 долл, в час,
и Вам следует это учитывать в своей работе.
Хотя такие высказывания вначале способствовали выработке
хороших привычек предварительных проверок, планирования от-
ладки и предварительного анализа задания до программирования,
это также порождало плохие привычки экономии микросекунд,
вставления «заплаток» в код и т. п., что через годы отучило авто-
ра от таких рекомендаций балансирования стоимостей ТО и ПО.
Такие высказывания, по-видимому, больше относятся к вопросам
использования разделения времени, средств автоматизации и прак-
тики современного программирования. Очень трудно получить
соотношения для оценивания стоимости машинного времени, в ко-
торых бы были учтены все возможные ситуации, встречающиеся
при разработке ПО.
Существующие данные и соотношения для оценивания. Данные
и соотношения для оценивания стоимости машинного времени, ис-
пользуемого при разработках ПО, связаны с тремя отношениями:
Таблица 31 4
Отношения для оценивания стоимости машинного времени
Источ- ник Тип ПО Размер программы чмв/кчик ЧМВ/ЧМразр сэвм/счм, %
[108] 1313] Общего назначения Человеко-машинного взаимодействия Средний и большой Большой 17 20...30 2...3 20—25
[13] [21 [33] [79] 1136] Конкретного назна- чения Специального назна- чения Реального времени Системное, большие ЭВМ Системное, малые ЭВМ Общего назначения Реального времени без моделирования Реального времени с моделированием Общего назначения Любой г > » Средний Любой > 1 14 100 40 20 6 8 12 1 V 14 3 4
1147] То же > 4„5 6
1164] » Малый 0,2...2 0,15-1,5
Промежу- точный Средний Большой Очень . большой 0.5...4 1...10 5...I00 10 .200 0.24...2 0.3...3 0,8—16 1—20 10—34
[291] [59] > » Любой 2—4
455
ЧМВ/КЧИК — количество часов машинного времени на тысячу
исходных команд,
ЧМВ/ЧМразр — количество часов машинного времени на челове-
ко-месяц разработки,
СЭВМ/СЧМ — стоимость ЭВМ к стоимости человеко-месяца раз-
работки.
В табл. 31.4 приведены значения этих отношений из различных
источников. Данные сильно различаются; достаточно сказать, что
отношение ЧМВ/КЧИК изменяется от 15 до 20, а отношение
ЧМВ/ЧМ — от 3 до 4 [164].
Данные о машинном времени в базе данных КОМОСТ В базе
данных КОМОСТ информация об указанных отношениях содер-
жится только для 17 из 63 проектов (табл. 31.5). Можно заметить
х
X X N N С
X NX XX DX.NNNN
1 I I I I I I I I I I_I_I_!_1_l__i
00,5 1 2 3 4 6 8 10 15 20 3040608010Q120
Рис. 31.3. Гистограмма от-
ношения ЧМВ/КЧИК для
проектов базы данных
КОМОСТ:
X — большие, D — средние; N—
мини-. С — микро-ЭВМ
ЧМВ/КЧИК
Таблица 31.5
Отношения для оценивания стоимости машинного времени в базе данных
Тип ЭВМ Рейтинг ОБД Рейтинг ЦО Тип ПО
МАХ Номинальный Низкий BUS
МАХ > SCI
МАХ » SYS
МАХ Номинальный BUS
МАХ > > SCI
МАХ > SUP
МАХ » Высокий BUS
МАХ Высокий От низкого до но- HMI
минального
MID Номинальный Номинальный BUS
MIN > Низкий SCI
MIN От номиналыного » HMI
ДО высокого
MIN Высокий Номинальный CTL
MIN > > SYS
MIN Очень высокий Низкий SUP
MIN То же Номинальный CTL
MIN Сверхвысокий » SYS
MIC Высокий » SYS
• Условные обозначения соответствуют использованным в табл. 29.1.
456
m
о
D
X X
X X NN
XNNXXNXNN C
J - I I I_I I I । 1 I ।_I I I 1-1—1—1
0 0,51 2 3 4 6 8 1015 2030406080100120
4MB/4Mpa3p
Рис. 31.4. Гистограмма от-
нооегия ЧМВ/ЧМраэр для
проектов базы данных
КОМОСТ:
X — большие. D — средние. N —
мини-. С — микро-ЭВМ
некоторые тенденции в изменении данных, что гораздо лучше вид-
но на гистограммах (рис. 3'1.3 и 31.4).
Основные тенденции состоят в следующем:
значительно больше машинного времени расходуется на шльх
ЭВМ, если судить об этом по отношениям ЧМВ к ЧИК и ЧМ;
больше машинного времени тратится на разработки ПО реаль-
ного времени, чем на разработки ПО общего назначения;
отношение ЧМВ/ЧМразр изменяется в большем диапазоне, чем
отношение ЧМВ/КЧИК-
Рекомендуемая процедура оценивания. Для оценивания стоимо-
сти машинного времени рекомендуется использовать данные
табл. 31.6, с помощью которой можно:
1) определить тип ЭВМ и характеристики проекта (например,
ПО и ТО системы управления процессами на базе мини-ЭВМ);
2) определить отношение ЧМВ/ЧМразр (например, 9);
3) определить ЧМразр с помощью КОМОСТ (например,
150 ЧМ) ;
КОМОСТ*
Номер проекта КЧИК ЧМраар ЧМВ чмв/кчик ЧМВ/ЧМразр
7 6,9 8 2 0,3 0,25
38 15 12 2,3 0,15 J.2
61 28 50 12 0,4 0,2
5 16 33 92 6 2,8
39 6,2 8 30 4,8 3,8
48 311 1272 2758 8,9 2,2
2 249 1600 10 000 40 6,7
19 966 6600 14 000 14 2,1
6 4 43 107 27 2,5
40 2-5 8 8 3,2 1,0
24 90 453 2400 27 5,3
12 37 201 2000 54 10,0
57 15 237 1500 100 6,3
50 24 176 330 14 1,9
9 30 423 3500 117 8,3
58 25 130 1600 64 12,3
62 9,1 38 800 88 21,0
457
Таблица 31.6
Значения отношения ЧМВ/ЧМра3р
для оценивания стоимости
машинного времени
Характеристики проекта
н тип ЭВМ
чмв/чмраар
Применение разделения
времени, средние и ма-
лые программы
Большие ЭВМ
Средние ЭВМ
Мини-ЭВМ
Применение пакетной
обработки, большие и
очень большие програм-
мы
ТО и ПО системы ре-
ального времени
Большие ЭВМ
Средние ЭВМ
Нини-ЭВМ
Микро-ЭБМ
0,2
0,6
1,5
3,0
3,0
f ,0
S.0
18,0
Рис. З1.о. Распределение машинного
времени при разработке ПЭ
4) вычислить ЧМВ = ЧМразр-ЧМВ/ЧМРазр (150X9=1350 ча-
сов машинного времени);
5) используя полученное значение ЧМВ, определить требуемое
число приобретаемых или арендуемых ЭВМ и соответствующую
стоимость покупки или аренды (в нашем примере более подходя-
щей является покупка мини ЭВМ, которая поставляется как часть
системы управления процессами);
6) определить критическую ситуацию при использовании ЭВМ
на фазе отладки программ (например, тяжелая фаза определяется
по рис. 3'1.5 и характеризуется множителем 2,2. В рассматривае-
мом случае расход машинного времени составляет 2,2-1350/15=
= 198 ЧМВ/мес.);
7) сравнить полученные результаты с опытными данными и про-
извести корректировку. Конечно, данные табл. 31.6 основаны на
малом объеме информации, но они неплохо согласуются с отно-
шениями, приведенными в табл. 31.4.
Распределение машинного времени. Требуемое машинное время
определяется на всем протяжении ЖЦПО и характеризуется кри-
вой, приведенной на рис. 31.5. Она аналогична кривой, полученной
в работе [239], но имеет два небольших отличия:
более пологая кривая означает, что отладка при разработке
осуществляется в основном методом сверху — вниз;
не равное нулю число обращений к ЭВМ в начале разработки
означает использование ЭВМ при планировании и проектировании
При пошаговой разработке кривая распределения машинного
времени будет еще более пологой.
168
31.6. ОБЪЕМ ДОКУМЕНТАЦИИ ПРИ РАЗРАБОТКЕ ПО
Стоимость документирования представляет собой часть стоимо-
сти разработки, а не является добавкой к ней. И это вполне согла-
суется с подходом к разработке, при котором применяется предва-
рительное документирование (см. разд. 4.4), когда документация
используется как спецификация изделия и проекта, а не появля-
ется в конце разработки проекта. Важно также заведомо опреде-
лить объем документации для правильного планирования проекта.
Нормы документации. Объем документации по программному
изделию пропорционален размеру изделия в ЧИК. В табл. 31.7
Таблица 31.7
Нормы документации
м X к С Ь о 5 Атрибуты ПО । чсд/кчик чч*/чсд
Специ- фика- ции Руко- водст- ва Планы Всего
1291] [224] КОМОСТ [116] [166] [45] 25 процентилей 50 » 75 > 25 » 50 » 75 » 25 » 50 » 75 » Пять проектов распро- страненного типа 2 КЧИК 8 КЧИК 32 КЧИК 128 КЧИК 512 КЧИК Спецификации, планы Руководства Две программы разме- 6 10 18 20 18 34 13 17 27** 69** 167** 24 54 127 19 39 80 30...60 64 3.2...5 1,8—2,2 1.5
[108,213] ром 2 КЧИК Подготовка чернового варианта Проверка Редактирование Исправление Общая подготовка тек- ста Перепечатка Подготовка иллюстра- ций 40 10 14 64 100...350 1.7 1,6-2,7 0,4 0.2 0,8 3,0-4,1 0,4...0,5 4
• Человеко-час.
*• Включая листинги исходных программ.
представлены некоторые опубликованные данные по нормам доку-
ментации (числу страниц документации (ЧСД) на тысячу исход-
ных команд для готового программного изделия). Ниже приводят-
ся некоторые комментарии к этой таблице.
459
Обработка деловой документации (В)
I ° ,в в । в । I I |в в I ' | | ' 1 ,
О 10 20 30 40 50 би 70 80 90 100 150 200 250 300
Рис. 31.6. Интегральное распределение
норм докук еч^ации для проектов базы
данных КОМОСТ
Управление процессами (С)
С
С_______с с_______________с________с с с с_____________
Рис. 31.7. Распределение норм дс-'умен-
Поддержка человеко-машинного тации в зависимости от типа • ПО для
взаимодействия -(М) проектов базы данных КОМОСТ
М М М М МММ М МММ
s Научные исследования (S >
SSSSS SSS S
Вспомогательное ПО (Г)
и и и и и
Системное ПО (V)
и у Общая гистограмма
и Y S S и S
SYMYSS S М. Y
SMCUYSC S S С* МММ
в,в в S мм в. с и м.м м,в в,с . |С ,СС, С, S .
0 10 20 30 40 0 60 70 - 80 90 100 150 200 250 300
Нормы документации, ЧСД/КЧИК
I. Существуют самые разные определения ЧСД.
В работе [291] в ЧСД включаются листинги программ, а в pa-
re [224] используются другие определения. В КОМОСТ, а так-
: в работах [45, 116] в ЧСД не входят листинги и блок-схемы
□грамм, полученные на ЭВМ.
2. Нормы различной документации в основном согласуются.
,нако нормы в [166] несколько занижены, а в [108] значительно
Среднее значение
250
Очень Низкий Номиналы Высокий Очень
низкий ный высокий
Рейтинг-TH ПО
Рис. 31.8. Зависимость норм документации от тре-
буемой надежности ПО для проектов базы данных
КОМОСТ
3. Нормы документации существенно зависят от характеристик
проекта. Данные, полученные в работах [224, 291], и данные для
КОМОСТ различаются в 4 ... 6 раз.
Природа этих различий исследуется на рис. 31.6, 31.7 и 31.8.
На рис. 31.6 показано интегральное распределение норм докумен-
тации. Рисунок 31.7 иллюстрирует зависимость норм документа-
ции от типа ПО. Видно, что ПО обработки деловой документации,
вспомогательное и системное ПО имеют относительно низкие нор-
мы документации, а ПО управления процессами и поддержки че-
ловеко-машинного взаимодействия имеют высокие нормы доку-
ментации.
461
На рис. 31.8 показана зависимость норм документации от тре-
бований надежности ПО: высокие требования к надежности при-
водят к высоким нормам документации (для очень надежных из-
делий требуется разработка более детальных спецификаций и под-
робных планов отладки). Высокими нормами документации харак-
теризуются проекты, разрабатываемые по правительственным за-
казам.
Таким образом, проблема оценивания норм документации так
же сложна, как и проблема оценивания затрат на ее разработку,
и это плодотворная область для дальнейших исследований.
Затраты на документирование. В табл. 31.7 содержатся некото-
рые данные для оценивания затрат на разработку документации.
Конечно, дать точную оценку очень сложно. Можно оценить затра-
ты на написание, проверку, планирование и т. п., но оценить твор-
ческую деятельность по разработке документа почти невозл ожро.
Разброс данных в таблице весьма широк, но для получения прием-
лемых оценок затрат можно воспользоваться следующими значе-
ниями скорости разработки документации:
малые проекты, руководства для больших проектов —
2 ЧЧ/ЧСД;
спецификации и планы больших проектов — 4 ЧЧ/ЧСД.
Таким образом, грубая оценка затрат на документирование при
норме 50 ЧСД/КЧИК и скорости 3 ЧЧ/ЧСД такова:
3 ЧЧ/ЧСД-50 ЧСД/КЧИК=150 ЧЧ/КЧИК.
или примерно 1 ЧМ на I КЧИК программного изделия.
Другие интересные результаты получены при сравнении затрат
на документирование (при разработке проекта с предварительным
документированием) с затратами на разработку проекта без пред-
варительного документирования (т. е. на кодирование). В табл. 31.8
приведены результаты такого сравнения для среднего программно-
го проекта размером 32 КЧИК- Поразительно, что половина затрат
Таблица 31.8
Затраты на документирование и кодирование проекта, %
Первичное изделие Работы Тип проекта
Распрост- раненный Встроенный
Докум вйт Анализ требований, проектирование изделия, планирование отладки, ве- рификация и подтверждение, управ- ление проектом, половина работ по программированию 54 51
Программа Половина работ по программирова- нию, верификация и подтверждение, коплексирование, отладка 34 34
Документ и программа Управление проектом, управление конфигурацией, контроль ка зства 12 15
462
на программный проект тратится на документирование и только
треть — на кодирование. Если предположить, что остаток делится
поровну, то на документирование тратится 60 ... 61% затрат, а на
кодирование — 39 ... 40%.
31.7. ДРУГИЕ КОМПОНЕНТЫ СТОИМОСТИ ЖЦПС
Кроме рассмотренных компонентов стоимости ЖППО (затрат
на разработку, поддержание, перенос, опытное внедрение, обуче-
ние, ЭВМ, документирование) имеются еще и другие, важные для
ЖЦПО компоненты стоимости, наиболее значительными из кото-
рых являются конторские затраты, составляющие 3 ... 4 % от об-
щих затрат. При оценивании стоимости по КОМОСТ учитываютс я
затраты труда профессиональных исполнителей и таких исполни-
телей, как библиотекари программ, но не учитыгаются конторские
затраты, которые не имеют прямого отношения к работам над про-
ектом и частично входят в накладные расходы. Кроме того, учет
этих затрат затрудняется большой сложностью структуры подраз-
деления работ в КОМОСТ.
Средние оклады конторских служащих составляют примерно
40% от средних окладов разработчиков проекта. Так как к работе
над проектом привлекается 7 ... 10% конторских служащих, то до-
полнительные затраты, связанные с оплатой их труда, составляют
2,8... 4%
Остальные компоненты стоимости ЖЦПО составляют только
0,5% от общей стоимости разработки ПО, но их все-таки следует
учитывать по следующим причинам:
они moi ут быть гораздо больше для некоторых проектов (на-
пример, стоимость перевозки и связи для проектов с большой тер-
риториальной разбросанностью),
если их не предусмотреть, то разработка проекта может затор-
мозиться (например, из-за отсутствия модемов, дисков, програм-
ных изделий)
Ниже перечислены дополнительные компоненты стоимости
ЖЦПО, приведенные р работе [70].
1. Конторские затраты.
2 Переменные затраты на исполнителей. Сверхурочная работа,
пенсия, паем, перемещение, образование, заключение и прекраще-
ние контрактов ит п.
3. Переменные затраты на ЭВМ. Опытное внедрение, сопровож-
дение в процессе эксплуатации, страхование, затраты на специаль-
ное оборудование: терминалы, устройства управления, устройства
ввода данных и т п.
4. Затраты на конторское оборудование. Пишущие машинки,
телефоны, хранилища машинных носителей, письменные столы,
стулья, картотеки и т. п.
5. Затраты на программное изделие. Покупка, арендование,
лицензирование, сопровождение компонентов, утилит, инструмен-
тальных средств ПО и т. п.
463
6. Затраты на снабжение. Магнитные ленты, диски, бланки, пер-
фокарты, бумага, копировальная лента, канцелярские принадлеж-
ности и т. п.
7. Затраты на связь. Плата за линии и специальное оборудова-
ние: модемы, мультиплексоры, кабели, соединители и т. п.
8. Затраты на удобства. Арендование помещения, электричество,
кондиционирование, отопление, вода, налоги, амортизация, уборка,
ремонт, страхование, охрана, противопожарные мероприятия и т. п.
9. Прочие затраты. Перевозка, почтовые расходы, печатание,
консультирование, покупка книг, подписка на периодические изда-
ния, служба посыльных, перестановка оборудования и т. п.
31.8. ТЕМЫ ДЛЯ ДАЛЬНЕЙШИХ ИССЛЕДОВАНИЙ
А. Исследовать влияние следующих стоимостных факторов при
переносе ПО:
язык программирования,
количество и качество документации,
сходство конфигураций ЭВМ.
Б. Предложить модель для оценивания стоимости переноса ба-
зы данных.
В. Предложить модель для оценивания стоимости машинного
времени в разработках ПО.
ГЛАВА 32
ПЛАНИРОВАНИЕ ПРОГРАММНОГО ПРОЕКТА И УПРАВЛЕНИЕ ИМ
32.1. ВВЕДЕНИЕ
Оценивание стоимости ПО как самовыполняемое предсказание.
Самое замечательное свойство оценивания стоимости разработки
ПО заключается в том, что если оценка стоимости разработки ПО
находится в пределах 20% от «идеальной» оценки, то хороший ру-
ководитель может превратить это в самовыполняемое предска-
зание.
Степенями свободы, позволяющими руководителю проекта это
делать, являются обычные компоненты простоя в типичной рабо-
чей неделе программиста. На рис. 22.3 эти компоненты простоя —
обучение, индивидуальные и общие занятия — составляют около
30% общего времени работы программиста.
Первое, что может сделать руководитель проекта для стимули-
рования членов бригады к соответствующему перераспределению
времени простоя, это установить промежуточные этапы и оценить
их бюджеты и сроки. В связи с этим выявляются два феномена,
которые приводят к сокращению времени простоя и совокупно ре-
ализуют самовыполняемое предсказание. Первый из них закон
Паркинсона [231]:
464
«Нет такой работы, которой было бы нельзя занять любое
заданное число исполнителей».
Таким образом, если оценки стоимости и сроков для какого-то
этапа больше идеальных оценок, то закон Паркинсона указывает,
что люди будут использовать дополнительное время для учебы, ин
дивидуальных занятий, посещения почты и т. п., так что фактиче-
ские затраты на завершение поэтапной работы над проектом будут
почти равны оцениваемому бюджету. Второй феномен является в
некоторой степени обратным законом Паркинсона:
Эффект штурмовщины: «По мере приближения срока
окончания работы энергия и затраты на ее выполнение
резко возрастают».
Эффект штурмовщины рассматривается неформально во мно-
гих ситуациях. На рис. 32.1 приведены некоторые данные по двум
малым проектам с тремя основными этапами: планирование и ана-
лиз требований (ПАТ), анализ проекта изделия (АПИ) и прием-
ные испытания [45]. Видно, что эффект штурмовщины сильно за-
держал оба проекта, пики графиков почти совпадают, а каждый
последующий пик выше предшествующего. Эффект штурмовщины
заставляет перераспределять время простоя исполнителей таким
образом, что начальные оценки бюджета и сроков по каждому эта-
пу становятся самовыполняемыми предсказаниями.
Таким образом, с определенным набором этапов и хорошим на-
бором методов планирования и управления способный руководи-
тель проекта может выполнить достаточно хорошо оцененный про-
ект в сроки и в пределах бюджета. Однако если оценки являются
неточными, то руководитель проекта будет исключать простои
Рис. 32.1. Эффект штурмовщины для двух малых программных проектов:
•------бригада 1; —-— бригада 2
465
исполнителей постоянным пересчетом бюджета и сроков, все чаще
вызывая штурмовщину и порождая серьезные долговременные про-
блемы, связанные с ухудшением морального состояния исполните-
лей, снижением их технического мастерства и увеличением текуче-
сти кадров.
Синер1изм оценивания стоимости ПО и управления проектом
ПО. Описанный выше эффект самовыполняемого предсказания
является только одним примером синергизма, обеспечиваемого
сочетанием эффективных методов оценивания стоимости 110 и
эффективных методов планирования ПО и управления им. Имеют-
ся еще две области проявления синергизма:
эффективные планирование и управление обеспечивают полу-
чение данных по распределению времени, затрат и стоимости для
рассматриваемых проектов ПО. Эти данные помогают пересмо-
треть модель оценивания стоимости ПО для получения характери-
стик проектов;
возможность эффективного оценивания стоимости ПО способст-
вует лучшему управлению проектом, позволяя определять требуе-
мые ресурсы для нрачильного выполнения работы (например, вре-
мя и затраты на ранних фазах для правильного анализа требова-
ний и проекта) и получать распределения затрат по фазам и рабо-
там, что служит основой для планирования и управления
32.2. ОСНОСЫ ПЛАНИРОВАНИЯ И УПРАВЛЕНИЯ ПРОГРАММНЫМ
ПРОЕКТОМ
На рис. 32.2 показана общая структура планирования проекта
ПО и управления им. Каждый из пронумерованных на рисунке ша-
гов описан ниже.
1. Необходима организационная структура для топ>, чтобы рас-
ходы на проект соответствовали оцененному распределению затрат
по фазам и работам. Такую возможность дает структура подразде-
ления работ (СПР), определенная в разд. 4.7.
2. Оценки по КОМОСТ требуемого календарного времени раз-
работки проекта по фазам обеспечивают отправную точку' для фор-
мирования сетевого графика Метод сетевых графиков позволяет
определить время решения задач проекта, проанализировать кри-
тические пути проекта, а также предсказать действительный спо-
соб улучшения проектирования по этапам. Все это подробнее
рассмотрено в разд. 32.3.
3. Поскольку определено! стоимость, затраты и сроки по каждой
задаче проекта, можно установить три первые составляющие плана
ресурсов, необходимые для разработки проекта. Первая — план
численности исполнителей для каждого элемента СПР помесячно
(время может исчисляться и неделями для малых, и кварталами
для больших проектов).
4. Цругая составляющая плана ресурсов —план-график работ
(ПГР). Для каждого элемента СПР заполняется бланк ПГР, со-
держащий:
466
Определение
фазовых работ
Оценивание
по КОМОСТ
Планирование распределения
работ по времени
Пересмотр
сетевого графика
Итоговый бланк
планирования задачи
И
Бюджет
Приведенные
стоимости
по этапам
План-график
работ
Приведен
ная стой
мость .
Пересмотр
СПР
План численности
исполнителей
Работа
Итого
На обработку
Итого
-J
Бюджет рабочего
времени
Карта времени
В
С
Ч
П
Итого
S СЦУОЗ
Рабо
чее
вре-
мя
Карта загрузки
исполнителей
Сборник единиц
разработки
Де-
неж-
ные
затра
'янв!п
Итоговая сводка
проектных расходов
СПР Элемент Бюд- Факти-
жет чески
S1
Этапы
Г рафик бюджет —
сроки — этапы
Денежные
затраты
Итоговая запись приведенной
стоимости
аАПП
/*АПИ
^/Фасширения
'атпо
СПР Элемент Приведенная Рас-
стои мость ходы
Поэтапные
денежные
затраты
S
S1
Я
Ф
М
А
м
и
я
Рис. 32.2. Структура планирования программного проекта и управления им
вид выполняемой работы,
сроки завершения главных этапов работы,
обеспечиваемые зак-зчиком ресурсы для завершения работы
исполнителем.
5. Последняя составляющая плана ресурсов — набор итоговых
бланков планирования задач (ИБПЗ, см. разд. 32.5), которые со-
467
держат нижние границы сроков выполнения отдельных работ над
проектом и предназначены для системы приведенной стоимости
(см. шаг 10).
6. Для нормального развития проекта, над которым начинается
работа, необходимы общее выполнение карты времени или ее экви-
валента, содержащего записи о времени выполнения закодирован-
ных элементов СПР, и ведение записи о ходе выполнения проекта
каждым членом бригады, для чего используется сборник единиц
разработки (СЕР) (см. разд. 32.4).
7. План численности исполнителей, разработанный на шаге 3,
обеспечивает сопоставление распределений исполнителей и време-
ни. Фактические человеко-часы проектных работ определяются по
карте времени, которая может быть использована для таких сопо-
ставлений и для управления проектом на уровне исполнителей.
8. Необходимые для проектных работ деньги могут быть сопо-
ставлены с плановыми затратами из записей в сводке расходов на
проект, составленной системой калькуляции работ.
9. Записи, полученные на шагах 7 и 8, могут использоваться
для обоснования проекта, но они не отражают хороших и плохих
сторон проекта. Вывод об этом можно сделать, объединяя сведе-
ния о расходах и ходе проектирования. Базирующимся на главных
этапах проекта (АПИ, АПТ и т. п.) простым примером сопоставле-
ния является график бюджет—сроки — этапы (ГБСЭ).
10. ГБСЭ хорошо отражает расходы для малых проектов, но
это не так для больших и сложных проектов. Для больших проек-
тов эффективным методом сопоставления является использование
системы приведенной стоимости (СПС), которая сравнивает рас-
ходы на проект и текущие приведенные стоимости на промежуточ-
ных этапах; по этим стоимостям вычисляется суммарная приведен-
ная стоимость (см. разд. 32.5). Конечно, рис. 32.2 несколько идеа-
лизирован из-за фиксации бюджета, элементов СПР, сетевого гра-
фика и ПГР. На практике все они подвержены изменениям, и ста-
новится целесообразным использовать средства автоматизации
СПС.
32.3. МЕТОДЫ ПЛАНИРОВАНИЯ СРОКОВ ВЫПОЛНЕНИЯ ПРОЕКТА
Сетевой график 1 — это граф, узлы которого представляют ра-
боты (их связывают со сроками выполнения), а дуги — отношения
предшествования пары работ. Так, если дуга соединяет узлы А и
В, то работа А должна быть завершена до начала работы В.
На рис. 32.3 приведен пример сетевого графика, представляю-
щего полный набор работ по созданию ПО. Видно, например, что
подготовка данных для отладки длится 2 мес., должна завер-
1 В математике под сетевым графиком понимают ациклический ориентирован-
ный граф, который состоит из набора узлов (или вершин) и ориентированных
дуг (пары вершин), не образующих циклических путей.
468
шиться до начала работы по испытанию изделия и не может на-
чаться до завершения разработки требований и плана отладки.
Построение сетевых графиков. Многие считают это простым де-
лом. Представим неформальную процедуру построения сетевого
графика, изображенного на рис. 32.3.
Шаг 1. Вычертить узел, именуемый Конец.
Шаг 2. Выявить работы, которые завершают проект. Наимено-
вание работ дополнить временами их выполнения. Пример дан на
рис. 32.4, а.
Шаг 3. Для построенного набора работ определить, нужны ли
дополнительные работы, чтобы убедиться, что имеющиеся работы
уже завершены. Если да, то добавить их к предшествующим ра-
ботам. Например, работа по испытанию изделия добавляется, если
кодирование уже завершено, что и представлено на рис. 32.4, б.
Рис. 32.3. Простой сетевой график программной разработ-
ки
Шаг 4. Повторить операции шага 3. На рис. 32.4, в дополни-
тельными работами являются проектирование, подготовка данных
для отладки и испытание изделия.
Шаг 5. Если все работы в сответствии с шагом 4 добавлены, то
возвращаемся к шагу 3, в противном случае переходим к шагу 6.
В рассматриваемом примере был возврат к шагу 3. Такой итера-
ционный процесс в примере завершается на третьем возврате к
шагу 5. Переход к шагу 6 произойдет тогда, когда сетевой график
примет вид, показанный на рис. 32.4, г.
Шаг 6. Вычертить узел Начало, соединив его со всеми сущест-
вующими узлами, которые не имеют входных дуг. В примере таки-
ми узлами являются разработка -требований и планирование от-
ладки. Этот шаг завершает построение сетевого графика (см.
рис. 32.3).
Как практически и все математические модели, сетевые графи-
ки также не точны в отражении состояния дел с проектированием
ПО. Например, полное документирование не может завершиться,
469
пока ведется кодирование. 1аким образом, имеются работы, кото-
рые трудно представить в сетевом графике. Вообще же сетевые
графики являются полезным приближением к процессу разработ-
ки ПО, их целесообразно использовать при планировании и управ-
лении.
Рис. 32.4. Сетевой график после шагов
гов 5, 3, 4, 5, 3, 4, 5 (г)
1 и 2 (а), ш„га 3 (б), шага 4 (в) и ша-
Анализ критического пути. В сети на рис. 32.3 отражено:
минимальное время для завершения проекта;
не укладывающиеся в это минимальное время критические ра-
боты.
Критические работы находятся иа пути (или наборе путей
между узлами Начало и Конец), который называется критическим
путем (путями). Критический путь — это самый продолжительный
по ремени выполнения работ путь.
470
Определение критического пути. Рассмотрим простейшую про-
цедуру определения критического пути:
1. Пометить узел Начало (0, 0).
2 Для всех непомеченных узлов N с помеченными предшествующими узлами
вычислить наибольшее время окончания работы в узле N:
SN— max [fj], (32.1)
teP(N)
где PIN) —набор предшествующих узлов из N. Вычислить соответствующее вре-
мя окончания работы: Fx=Sx+Dj;t где Dk — время выполнения работы в узле
N. Пометить узел У парой (Sw, f.v).
3. Повторять шаг 2 до тех пор, пока не будут исчерпаны вге непомеченные
узлы.
При этом постепенно помечаются все узлы i сети парами чисел
(Si, Fi), представляющими возможные времена начала и конца
работы в узле i. На рис 32.5, а приведены результаты двух итера-
ций шага 2 этой процедуры. Шаги процедуры осуществляются по-
следовательно вдоль всех путей до тех пор, пока не будут помече-
ны все узлы. Окончательный результат и критический путь пред-
ставлены на рис. 32.5, б. Минимальное время до завершенья про-
екта определяется пятнадцатью месяцами.
Определение последнего срока начала работы и времени про-
стоя. Показанный на рис. 32.5, б критический путь ставит два до-
полнительных вопроса, на которые необходимо ответить
Каким-может быть самый последний срок начала каждой ра-
боты, который не повлияет на общий срок окончания проекта?
Велико ли время простоя в общей продолжительности выполне-
ния каждой работк? То есть, если работа начинается как можно
раньше, то какой может быть продолжительность выполнения ра-
боты, чтобы это не повлияло на общий срок окончания проекта?
Ответить на эти вопросы можно только после применения про-
цедуры определения последнего срока начала работы.
1. Поместить узел Конец начальными и конечными сроками, установленными
после выполнения процедуры определения критического пути так, что
(Sf, Ff).
2. Для всех непомеченных узлов N с поме генными предшествующими узлами
вычислить последний возможный срок окончания работы
F^= min [S,-], (32.2)
ieS(N)
где S (W) — набор предшествующих узлов из N.
Вычислить соответствующий последний срок начала S'k = F'n-Dn,
где Dn — время выполнения работы в узле N. Пометить узел парой (S'к, F'n).
Вычислить время простоя для этой работы
LN=Sfj—9n (или LN=F^—FNy
3. Повторять шаг 2 до тех пор, пока не будут исчерпаны все непомеченные
узлы.
После применения процедуры вычисления критического пути
(см. рис. 32.5, б) с помощью ь горой процедуры вычисляются поме-
471
щаемые под каждым узлом i пары (S'.-, F'i), которые представля-
ют собой времена последних сроков начала и окончания работы в
узле I.
Результат применения процедуры показан на рис. 32.6, на кото-
ром отражено другое свойство критического пути: пометки под и
над узлами вдоль критического пути совпадают, времена простоев
(0,3) (3,7)
я)
6)
Рис. 32.5. Определение критического пути после двух (а) и пяти (б) итераций
в работе вдоль критического пути равны нулю. (Фактически это
составляет основу алгоритма определения критического пути.)
Предпосылки для планирования и управления. Информация о
критическом пути и времени прсстоя дает ряд важных предпосы-
лок для планирования и управления, что проиллюстрировано ниже
на примере разработки проекта ПО.
1. Потери времени можно использовать для задержки начала
работы или для увеличения сроков ее выполнения (или для того и
другого). Например (см. рис. 32.6), испытания изделия можно про-
вести с третьего до восьмого месяца, а работу по подготовке дан-
472
ных для отладки — с девятого до десятого месяца, и, следователь-
но, эти работы можно поручить одному исполнителю. В другом ме-
сте сети, где указано документирование, которое проводят с вось-
мого до тринадцатого месяца, можно снизить затраты или удовле-
творить пожелания исполнителя, или отдать предпочтение кодиро-
ванию, чтобы оттянуть документирование.
2. Если сроки выполнения какой-либо работы на критическом
пути увеличить на X единиц времени, то сроки выполнения всего
проекта увеличатся на эти X единиц. Например, если проектирова-
ние произвести за 6 мес., а не за 4, то время разработки проекта
будет составлять 17 мес. вместо 15.
3. Если критический путь существует, то можно сократить сро-
ки выполнения всего проекта путем сокращения сроков выполнения
отдельных работ на этом пути. Сокращение сроков выполнения
проекта таким образом выявит новый критический путь. Так, на
рис. 32.7 представлена сеть, в которой первоначальное время кри-
тического пути сокращено с 15 до 12 мес. за счет уменьшения сро-
ков проектирования с 4 до 3 мес. и кодирования с 4 до 2 мес. Одна-
ко дальнейшее уменьшение времени проектирования невозможно,
потому что другой путь станет критическим.
Если существует несколько критических путей, проблема сокра-
щения сроков выполнения всего проекта становится более сложной.
Вообще же,-сократить сроки выполнения проекта можно уменьше-
нием времени выполнения работ, относящихся ко всем критиче-
ским путям (например, сокращением времени выполнения работы
Рис. 32.6. Определение последнего срока начала работы
по испытаниям изделия на рис. 32.7). В то же время сокращение
сроков выполнения проекта можно осуществить одновременным
уменьшением времени выполнения работ, находящихся на незави-
симых критических путях (например, работ по проектированию и
разработке драйверов тестов).
473
Конечно, можно выполнить простейшие указания разд. 27.3 о
реализации сроков проектирования ПО. Если проектирование тре-
бует шесть месяцев вместо четырех, то в принципе требуемые на
весь проект 15 мес. можно оставить, сократив сроки кодирования
с четырех месяцев до двух. Но на практике добавление исполните-
лей в середине проекта приведет к задержке в выполнении всего
проекта.
Изменения и расширения сетевого графика. Имеются более об-
щие сетевые графики, в которых дуги представляют работы, а уз-
лы— завершенные этапы. Такое представление имеет некоторое
преимущество, но сложно в применениях и толковании подразуме-
ваемых работ, которые могут быть представлены узлом в рассмо-
тренных сетевых графиках.
Некоторые более значительные (или более сложные) расшире-
ния сетевого графика разработаны в связи с учетом вероятностных
Рис. 32.7. Сокращение критического пути
оценок времени выполнения работ, компромиссов между стоимо-
стью и сроками и других более сложных условий на дугах или в
узлах (например, начало новой работы определяется условием за-
вершения т работ из п имеющихся). Некоторые обсуждения при-
роды, возможностей и ограничений таких сетевых графиков даны
в работе [305].
Структуры данных и алгоритмов обработки сетевых графиков
являются примерами широкого класса используемых в вычисли-
тельном деле структур данных и алгоритмов, среди которых мож-
но указать алгоритмы топологической сортировки, кратчайшего
пути в графе, структуры деревьев и т. п. (см. [150, 151]).
Другим полезным вариантом сетевых графиков, используемых
для управления проектом, является сеть работа—ответственность,
показанная на рис. 32.8. Она выявляет взаимную зависимость ра-
бот и ответственность за управление каждой работой. А это важно
для повышения действенности планирования проекта. Когда можно
определить «Как верификация и подтверждение зависят от подго-
474
товки данных для отладки?» или «Кто отвечает за подготовку дан-
ных?», то при планировании внимание концентрируется в нужном
месте. Например, если поставить себя на место руководителя работ
по верификации и подтверждению, то можно понять необходимость
получения достоверной информации о проекте, чтобы начать эф-
фективную подготовку данных для отладки.
Карты Ганта. Другой весьма подходящий метод для последо-
вательного представления проектных работ в виде календарного
графика — это метод карт Ганта, на которых главные этапы работ
показываются треугольниками. Развитие и ход работ указываются
на карте расстановкой треугольников, соединенных отрезками
прямых.
Рис. 32.8. Сеть работа — ответственность
На рис. 32.9 показан пример такой карты. Если рассматривать
эту карту в графе, соответствующей дате 15 марта 1984 г., то мож-
но увидеть: этап разработки требований завершится через две
недели, и работа по проектированию начнется через две недели
При рассмотрении карты на 15 апреля 1984 г. хорошо видны рабо-
ты, от которых зависят верификация и подтверждение: планирова-
ние отладки уже выполнено две недели назад, а разработка драй-
веров тестов началась также две недели назад.
Сравнение карты Ганта и сетевого графика. Основная трудность
такого сравнения заключается в невозможности установления зави-
симости между различными работами. По карте Ганта невозможно
выявить отставание по времени в планировании отладки на 15 ап-
эеля или отставание работ для критического пути. По сетевому
графику отставание можно обнаружить, чтобы затем усилить ра-
боту дополнительными исполнителями. Поэтому отсутствие зави-
симости работ на карте Ганта может привести к серьезным труд-
ностям в управлении. Например, если можно компенсировать от-
475
ставание в планировании отладки и совместить его с работами по
разработке драйверов тестов и подготовке данных для отладки, то
можно оттянуть сроки разработки требований и совместить работы
по проектированию и кодированию.
Ясно, что сетевой график стимулирует более полное планирова-
ние, чем карта Ганта, которая вынуждает особо осмысливать как
взаимную зависимость работ, так и время выполнения различных
Рис. 32.9. Карта Ганта для планирования программного проекта
работ пересмотра взаимной зависимости работ, что часто являет-
ся достаточно сложным делом (например, при установлении зави-
симости между документированием, проектированием и кодирова-
нием) .
Карта Ганта имеет некоторые преимущества по сравнению с
сетевым графиком. Ее проще и легче разработать и обновить. Она
содержит информацию о состоянии проекта и календарном плане,
а этого нет в сетевом графике (правда, существует расширение
сетевых графиков, в котором отражаются состояние проекта и ка-
лендарный план, но они значительно сложнее для применения).
Вообще же карта Ганта предпочтительнее при простых зависимо-
стях между работами, а сетевые графики предпочтительнее для
проектов со слоящими зависимостями между ними.
476
32.4. СБОРНИК ЕДИНИЦ РАЗРАБОТКИ — СРЕДСТВО ДЕТАЛЬНОГО
ПЛАНИРОВАНИЯ И УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПО
90-процентный синдром. Проектирование ПО часто должно
иметь эффективный макроуровень планирования и управления, по-
тому что на микроуровне не видно динамики проекта. Часто трудно
определить ход проекта по результатам завершения отдельных ра-
бот. На рис. 32.10 показан типичный график оценивания завершен-
ности проекта, выполненного несколько лет назад. Этот график
состоит из ряда понедельных записей хода проекта, выполняемого
программистами в течение 12 недель. В конце пятой недели про-
граммист оценивает по такому графику завершенность работ на
90 /о (обычно это расценчвается так, что после кодирования и ком-
пилирования еще остается устра-
нить незначительные дефекты, и
программа готова).
Часто руководитель такого
программиста, замечая 90-про-
центную завершенность, начина-
ет обсуждать с ним новую про-
грамму, в то время как вся брига-
да занята комплексированием
подпрограмм. Потом обнаружи-
вается, что через неделю намечен-
ная работа не может быть сдела-
на (хотя теперь оценка завер-
шенности составляет уже 95%),
и руководитель должен вернуть
программиста к прежней работе
и договариваться с бригадой ком-
плексирования об отсрочке нача-
Рис. 32.10. График оценивания за-
вершенност" программного проекта
ла их работы. После нескольких недель такой работы исполнители
перестают понимать друг друга, а процесс управления начинает
разваливаться. Это сказывается в дальнейшем и на следующих
работах.
Сборник единиц разработки (СЕР). Это формализованный
блокнот программистов, который должен использоваться всегда,
чтобы избежать 90-процентного синдрома [157, 306]. С помощью
СЕР удается добиться следующих целей разработки ПО и управ-
ления проектом:
обеспечить упорядоченный и последовательный подход в раз-
работке каждой единицы программного изделия;
предусмотреть обозримое место для единообразного хранения
всех единиц документирования и кодирования;
помочь разработчику в приобретении навыков установления
этапов разработки единиц программного изделия;
обеспечить улучшение обозримости управления и контроля про-
цесса разработки единицы программного изделия.
477
Рисунок 32.11 иллюстрирует сущность СЕР содержание его
разделов и их связь с различными этапами ЖЦПО. Каждый СЕР
устанавливает конец фазы проектирования изделия, которая под-
Осуществимость
Планирование
и разработка
требований
Проектирование
изделия
Сборник
единиц |
эазработки№И
контролера
Блокнот
на одну
единицу
6. Перечень
проблем
7. Заметки
8. Комментарии
Специфи-
кация из-
делия(пер-
вичная)
6. Перечень
проблем
7. Заметки
*8. Комментари)
После '
заполне
ния
4. Кодирование
единицы
5. Результаты
^тладки
О. Бланк плани-
эованин и сроки
1 Требования
к единице .
2. Описание •
проекта
3. Планирование
отладки
единицы
О. Бланк плани-
рования и сроки
1. Требования
к единице у •
2. Описание •
проекта
3. Планирование
СЕР 1
Сборник
единиц
разработки №1
отладки
единицы
4. Кодирова-
ние единицы
5. Результаты
гладки
Детальное
проектирование
Кодирование
отладка
Испытания
изделия
Комплексиро
ванне
контролера
Т Эксплуатация j
и сопровождение
Специфи-
кация изде
лил (окон-
чательная!
СЕР №
Рис. 32.11. Сборник единиц разработки
разделяет программное изделие на единицы 1 и формирует общий
план их разработки. В то же время каждый СЕР содержит специ-
фикацию требований (раздел 1) и общие спецификации проекта
1 Размер единицы программного изделия варьируется в зависимости от раз-
мера и типа всего программного изделия. Небольшой проект распространенного
типа для опытных разработчиков может состоять из больших единиц (1000 ЧИК),
в то время как больший проект встроенного типа для неопытных разработчи-
ков— из малых единиц (100... 300 ЧИК). Каждая единица пр< граммного изде-
лия выполняет хобую хороц определенную функцию, обозримую с точки зре-
ния требований к ПО; гребуег только одного исполнителя разработки; является
удобной для проверки разработ тиком
478
(раздел 2), взятые из первичной спецификации изделия, по которой
определялась единица.
Сборник единиц разработки — это принадлежность программи-
ста-аналитика, который является разработчиком и хранителем
сборника на фазах детального проектирования, кодирования, ав-
тономной отладки и комплексирования. Он же разрабатывает де-
тальный проект единицы (усовершенствование первичного проек-
та в разделе 2), план автономной отладки (раздел 3) и кодирова
ние единицы (раздел 4). Если отладка единицы завершена удовле-
творительно, то результаты отладки заносятся в раздел 5 (отдель-
но необходимо сохранять распечатки больших массивов данных с
результатами отладки). Последний шаг в процессе разработки еди-
ницы состоит в завершении разработки спецификаций требований и
проекта в разделах 1 и 2, которые затем сливаются с такими же
разделами других СЕР для формирования общей спецификации
конечного изделия (см. рис. 32.11).
Оставшиеся разделы СЕР предназначены для дальнейшего сбо-
ра информации о состоянии единицы. В разделе 6 хранятся запи-
си о всех проблемах, возникающих при разработке единицы, вклю-
чая проблемы, возникающие на этапах комплексирования и испы-
таний изделия. Раздел 7 должен содержать записи и заметки, ко-
торые имеют отношение или влияют на содержание единицы
Раздел 8 содержит комментарии и любые отклики на эти коммен-
тарии, сформированные в результате анализа всех записей.
Бланк планирования. Организация и содержание СЕР обеспе-
чивают проект средствами упорядочивания, тщательного докумен-
тирования разработки и контроля в процессе кодирования единиц
программного изделия. Данные, способствующие обозримости про-
цесса разработки ПО и позволяющие избегать 90-процентного син
дрома, первоначально обеспечиваются использованием бланка пла-
нирования.
На рис. 32.12 показан пример заполнения бланка планирования
для программы РЕДАКТОР системы централизованного управле-
ния оборудованием и запасами (СЦУОЗ). Бланк используется сле-
дующим образом:
1. Разработчик единицы и его Контролер обсуждают взаимосо-
гласованные сроки разработки. Обычно это означает, что они со-
гласны с датой, к которой Разработчик получит требования к еди-
нице, первичные спецификации проекта и начнет работу (1 октяб-
ря 1982 г., см. рис. 32.12), с датой, к которой будут получены ре-
зультаты отладки в соответствии со спецификациями (1 января
1983 г.), и с датой, к которой он подготовит документацию по еди-
нице (1 апреля 1983 г.).
2. Разработчик сам определяет сроки промежуточных этапов,
состав работ, время своего отпуска и т. п. Таким образом, Разра-
ботчик планирует завершение разработки спецификации кодов к
1 ноября 1982 г., планирования отладки единицы к 15 ноября
1982 г., кодирования единицы к 1 декабря 1982 г. Такое самостоя-
тельное планирование дает Разработчику возможность управлять
474
своей работой и выполнять обязательства по каждому этапу, по-
скольку он сам их определил и никто ему этого не навязывал.
3. Как только Разработчик проходит каждый из этапов, он по-
мещает результаты в СЕР, вписывает даты и расписывается. Если
результаты этапа удовлетворительны *, то ответственный Контро-
Бланк планирования сборника единиц разработки
Проект: СЦУОЗ
4
Единица: РЕДАКТОР (расширение 1 > Разработчик: Фамилия
Подпрограммы: РЕДВ, РЕДСКАН, ДОБАВЛ, ИСКЛ, РЕДОШ
Раздел Наименование Планиру- емая дата Дата Окончания Разработчик Контролер
1 Требования к единице । IDh/il loltlii Фамилия ' Фамилия
2 2а. Подготовка iDlilei Й/l/SZ
вание 26. Кодирова- единицы ние iifi/n Sohllil cxf.s.
2 в. Сдача 4/1/83
3 Планирование отладки единицы 11//5/8Z nhtlii
4 Кодирование единицы llIlKl llIlMl
5 Результаты отладки 1I1/S3
6 Перечень проблем
7 Заметки
8 Коюшптарии контролера
Рис. 32.12. Заполнение бланка планирования
лер ставит дату и расписывается. В противном случае Контролер
встречается с Разработчиком и обсуждает с ним требуемые дора-
ботки. (Например, Разработчик завершил кодирование на несколь-
ко дней раньше, а с планированием отладки несколько задер-
жался.)
Такие записи в бланке планирования более эффективны по
сравнению с простыми указаниями о завершении работ. Если Раз-
работчику, например, представилась возможность задержать план
1 Процесс оценивания результатов кодирования включает несколько типов
структурированных проверок текстов прогпаим [106, 320]
480
отладки на большее число дней, тогда могут возникнуть следующие
ситуации:
Разработчик может просто охладеть к своей работе или может
приложить дополнительные усилия к планированию отладки и вой-
ти вновь в требуемые сроки (штурмовщина).
Разработчик может найти помощь у кого-либо (например, у
бригады верификации и подтверждения для уточнения данных по
отладке) или пойти к Контролеру за помощью, что проще, когда
этапы разработки единицы никем не установлены.
Разработчик может не осознавать важности завершения про-
граммной единицы в сроки, и тогда Контролер укажет ему просто,
что еще имеется время на исправление ситуации.
В итоге СЕР обеспечивает обозримость эффективного планиро-
вания и управления проектом. Кроме того, он снабжает многие
этапы разработки полезной информацией.
32.5. СОПОСТАВЛЕНИЕ РАСХОДОВ НА КОНТРОЛЬ И РАЗВИТИЕ
ПРОЕКТА. СИСТЕМА ПРИВЕДЕННОЙ СТОИМОСТИ
Задачи контроля и управления всем проектом. Оценивание
программного проекта и управление разработкой будут способст-
вовать его развитию, если все идет по плану. Однако для больших
проектов наблюдаются значительные отклонения от планов. Одни
части проекта завершаются с опозданием на многие человеко-меся-
цы по сравнению с предсказанными сроками, для других требуется
увеличение запланированных затрат. Необходимо пересматривать
системные требования, производить перераспределение людских
ресурсов. Главные исполнители могут заболеть, повыситься в дол-
жности или уйти в отпуск. Штаты некоторых бригад плохо укомп-
лектованы, в то время как штаты других бригад укомплектовыва-
ются очень быстро. Внешние события иногда приводят к задерж-
кам в сроках (например, наличие оборудования, одобрение пользо-
вателя), а иногда появляется неожиданная возможность (напри-
мер, обнаруживается существующее ПО за подходящую цену).
При столкновении с такой неразберихой возрастающего откло-
нения от основного плана у заказчика и руководителя проектом
часто возникают проблемы обеспечения общего развития проекта
и, в частности, перед ними ставится задача оценивания затрат на
завершение работы. Здесь возникает два вопроса, на которые не-
обходимо ответить:
Произведен ли перерасход на проект из-за того, что проекти-
рование было легче предполагаемого и программирование может
начаться раньше, и тогда потребуется меньше времени и денег на
завершение проекта?
Произведен ли перерасход на проект из-за того, что проектиро-
вание было сложнее предполагаемого и программирование прежде-
временно отвлечет большое число программистов, и тогда работы
по завершению проекта потребуют значительно больше времени и
денег?
6 Зак. 628
481
В середине проектирования большого изделия на вопросы по-
добного рода трудно ответить, особенно когда обнаруживается,
что'характеристики изделия можно улучшить.
Концепция приведенной стоимости и итоговый бланк планиро-
вания задач. Наилучшим методом оценивания текущего поле жения
и стоимости завершения большого сложного проекта является под-
ход, основанный на концепции приведенной стоимости [7]. В систе-
ме приведенной стоимости под приведенной стоимостью понимает-
ся общая стоимость завершения всех этапов разработки отдельных
частей проекта. После завершения этапов можно получить приве-
денную стоимость проекта, которую можно сравнить с планируе-
мыми затратами, а также определить пути развития проекта. От-
ношение расходов и приведенной стоимости можно использовать
дЛя прогнозирования стоимости завершения проекта.
На рис. 32.13 показано заполнение типового итогового бланка
планирования задач (ИБПЗ) для системы централизованного уп-
равления оборудованием и запасами (СЦУОЗ). В табл. 32.1 рас
Таблица 32.1
Обозначения, использованные в итоговом бланке планирования задач______
1. Код проекта. Кодовое обозначение проекта
2. Проект. Сокращенное название проекта
3. Компонент. Часть проекта, для которого составлен ИБПЗ
4. Дата. Дата начала заполнения ИБПЗ
5. Элемент СПР. Работа из СПР, которую охватывает ИБПЗ
6. Предприятие-исполнитель. Предприятие, ответственное за выполнение ра-
боты
7. Руководитель. Ответственный исполнитель работы
8. Номер ПГР. Код проектной работы в соответствии с СПР
9. Номер задачи Порядковый номер задачи в ИБПЗ
10. Элемент СПР. Элемент СПР для указанной задачи
11. Задача. Наименование задачи
12. Тип ПС Тип приведенной стоимости для данной задачи:
ЭТ — ПС, суммируемая по отдельным этапам задачи;
ГЭ — ПС, суммируемая по главным этапам задачи
13. Срок. Указываются этапы по карте Ганта и приведенные стоимости их
завершения (числа над треугольниками)
14. Суммарная ПС. Приведенная стоимость для данной задачи
15. Текущая ПС. При~еденная стоимость к текущей дате
16. Текущая ПС СПР. Приведенная стоимост! к текущей дате для элемен-
та СПР
17. Расходы. Текущие расходы «ля элемента СПР
18. Итоговая помесячная приведенная стоимость по всем задачам
19. Итоговые помесячные расходы по всем задачам
20. Итоговая суммарная приведенная стоимость по всем задачам ИБПЗ
21. Итоговая текущая приведенная стоимость по всем задачам ИБПЗ
22. Итоговые текущие расходы по всем задачам ИБПЗ
шифрованы обозначения, использованные в ИБПЗ, в котором от-
ражены разработка , и комплексирование программ СЦУОЗ: РЕ-
ДАКТОР, ОБНОВЛ и ОБОРУД.
Задача 1 на рис. 32.13 представляет разработку и комплекси-
рование Расширения 1 программы РЕДАКТОР, которая рассма-
тривалась при заполнении бланка планирования в СЁР (см.
482
Итоговый бланк планирования задач Бланк_1_на 3_стр,
© Код проекта:.В142 (7 Проект: СЦУОЗ 0 Работа: Программирование ©ДЭта. 01.01.83
(5) Элемент CnP:S2AiS3B1 S3C (б) Предприятие-исполнитель; Название ©Руководитель Фамилия © Номер ПОР. В142-022
® © © © ® © ©
Номер задачй Элемент СПР Задача Тип ПС Год Месяц 1982 Октябрь | Ноябрь Декабрь 1983 Январь Февраль Март Апрель | >х га 5 Июнь Июль Август Сентябрь Октябрь Ноябрь Декабрь Приведенная стоимость Расходы
Общая Теку щая Текущая для элемен- та СПР
1 S3A РЕДАКТОР (прогр, расш. 1) эт 2 2 7,0 3,0
‘d 1 а г
2 S3A РЕДАКТОР (прогр. расш. 2) ЭТ 6 5 5 22,0 6,0
1г> V V
3 S3A РЕДАКТОР (прогр. расш, 3) эт 1 12 10 । 44,0 0,0 9,0 13,1
г V
4 S3B ОЬНОВЛ (прогр, расш, 1} эт 6 5 5 s5 1 22,0 16,0
D 0 т
5 S3B ОБНОВЛ (прогр. расш, 2) эт 2 3 к 11,0 3,0 19,0 16,2
Z
б S3C ОБОРУД (прогр, расш, 1) эт 5 5 5 f, 20,0 15,0
D J кс т
7 S3C ОБОРУД (прогр. расш. 2) эт т5 / 5 f. 20,0 0,0 15,0 20,3
С Т L
8
9 •
Приведенная Итого X стоимость Q9) Расходы 13л' 14,Р 11,0 12,2 19,0 17,6 46, С U 43,0 49,6
Рис. 32.13. Итоговый бланк птанирования задач © . © @
дого элемента СПР и бюджет. Вообще это делают, но не обяза-
тельно.
Если элемент СПР имеет существенный перерасход по абсолют-
ным и относительным оценкам, тогда требуется корректировка
работы.
Обсуждение. Прежде всего обратим внимание на то, что расхо-
ды несколько превышают приведенную стоимость. Это происходит
из-за того, что продолжительность работ на некоторых этапах
больше запланированной, а это, как правило, требует дополнитель-
ных расходов. Некоторые методы вычисления приведенной стоимо-
сти позволяют преодолеть такую трудность использованием поло-
вины приведенной стоимости в начале каждого этапа работы, а
половины — в конце или распределением приведенной стоимости по
всему периоду. Однако это может слишком усложнить систему
приведенной стоимости. Поэтому лучше всего использовать самый
простой способ оценивания приведенной стоимости.
Для малых проектов с незначительными изменениями в процес-
се разработки легко применять систему приведенной стоимости,
но ее влияние на управление таким проектом относительно мало.
Для больших и сложных проектов с частыми изменениями система
приведенной стоимости обеспечивает прекрасную возможность уп-
равления проектом, но это требует затраты дополнительных усилий.
При этом возникает необходимость в автоматизации вычисления
приведенной стоимости для больших проектов.
ГЛАВА 33
ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ РАЗРАБОТКИ ПО
Решая проблему оценивания стоимости ПО, необходимо обра-
титься к еще более важной проблеме повышения производительно-
сти разработки ПО. Часто некоторые заблуждаются, что повыше-
ние производительности разработки ПО может интерпретировать-
ся как процесс внедрения методов современного программирования
и допускается возможность повышения производительности на
50% благодаря внедрению этих методов. Однако можно показать,
что:
эффективное повышение производительности разработки ПО
достигается далеко не одним внедрением методов современного
программирования;
учитываемые в КОМОСТ стоимостные атрибуты и коэффициен-
ты затрат позволяют выявить факторы, способствующие эффектив-
ному повышению производительности разработки ПО;
организации, занимающиеся обработкой данных, могут увели-
чить производительность разработки и сопровождения ПО на 100%
за 3 ... 4 года и на 400% за 6 ... 8 лет;
производительность разработки может быть повышена еще
больше за счет более широкого использования готового ПО.
486
На рис. 33.1 представлена общая картина относительного повы-
шения производительности разработки ПО, обеспечиваемого раз-
личными стоимостными атрибутами КОМОСТ. Для каждого атри-
бута показан диапазон изменения коэффициентов увеличения про-
изводительности, разработки ПС (КУП), границы которого опреде-
ляются отношениями коэффициентов затрат для наименьшего и
Диапазон изменения производительности разработки ПО
Рис. 33.1. Диапазоны изменения ксэфЛициентов увеличение производительности
разработки ПО для различных стоимостных атрибутов в КОМОСТ
наибольшего рейтингов данного стоимостного атрибута. Так, на-
пример, при равенстве всех других факторов бригада программи-
стов и аналитиков, характеризующаяся рейтингом 90 процентилей,
будет работать в 4 раза производительнее, чем бригада, характе-
ризующаяся рейтингом 15 процентилей ’.
Эти диапазоны изменения КУП позволяют определить пути на-
ибольшего повышения производительности разработки ПО. Кроме
того, так как в КОМОСТ коэффициенты затрат входят в оценку за-
1 Здесь объединены диапазоны изменения КУП для возможностей аналитиков
(2,06) и программистов (2,03) в общий диапазон измененья КУП бригады 4,18.
487
трат мультипликативно, то соответствующее увеличение общей
производительности обеспечит мультипликативную прибыль. Этот
эффект является ключом к ускоренному повышению производитель-
ности разработки ПО.
Важность повышения производительности разработки ПО. Ос-
новной причиной того, что повышение производительности разра-
ботки ПО стало острой проблемой, является увеличивающийся
спрос на новое ПО, не согласующийся с имеющимися возможно
стями традиционных подходов. Растущий спрос на ПО выражает
экономическую целесообразность введения автоматизации в про-
мышленности, торговле и обслуживании.
В качестве примера на рис. 33.2 показан рост спроса на ПО,
выраженного в миллионах команд ЭВМ, по четырем проектам ос-
воения космического пространства в США, начиная с 1 млн команд
для проекта «Меркурий» и кон-
чая 40 млн. команд для проек-
та «Спейс шаттл» [251, 278].
Основная причина роста
объема ПО для проекта «Спейс
шаттл» — автоматизация вспо-
могательных работ по подго-
товке и сопровождению запус-
ков и по эксплуатации всего
оборудования, что исключило
набор дополнительных 20000
работников. В результате раз-
работки КО значительно сок-
ратилось количество обслужи-
вающего персонала, но значи-
тельно увеличился объем ПО.
Годовой рост спроса на новое ПО за последние 16 ... 20 лет
освоения человеком космического пространства составил 20 ...
26% Это, вероятно, выше общего роста спроса на ПО в США, хо-
тя в соответствии с данными работы [238] годовой рост составля-
ет 24%. По данным работы [56] к 199С г. потребуется 1 500 000
программистов, т. е. в три раза больше, чем в 1980 г. Это соответ-
ствует 12% годового роста спроса на персонал, связанный с раз-
работкой и сопровождением ПО.
Годовой прирос'1' разработчиков ПО в общем оценивается в 3 ...
4% [93], [214], хотя в работе [238] указываются более правдо-
подобные цифры 13 ... 14%. Ежедневное увеличение производи-
тельности разработки ПО, оцениваемой числом новых кодов объ-
ектной ЭВМ, разрабатываемых за один человеко-месяц, в среднем
составляло 8 ... 9% в 60-х годах [38]. Предположение о сохране-
нии такого темпа до 1985 г. не оправдалось: более поздние оценки
дали 3% [93] или 5 ... 6% [214].
Отношение к оцениванию стоимости ПО. Значительный интерес
к оцениванию стоимости ПО поддерживается желанием планиро-
вать проекты ПО и управлять ими, а также стремлением к контро-
Рис. 33.2. Рост спроса на ПО
488
лю большего числа стоимостных атрибутов проекта. Образно гово-
ря, стоимостные атрибуты являются теми «кнопками», которые
могут быть установлены в соответствующие положения, обеспечи-
вающие повышение производительности разработки ПО. Ясно, что
некоторые стоимостные атрибуты (например, тип программной
разработки) неуправляемы, однако большинство атрибутов, по
крайней мере, частично управляемы, и это может быть использова-
но для увеличения производительности разработки ПО. Например,
даже размер разрабатываемого ПО является управляемым, что мо-
жет приводить к впечатляющему снижению цены ПО. Вместо по-
купки программного изделия можно воспользоваться существую-
щими программами для адаптации их к новым условиям. Это обес-
печит выполнение адаптированными программами требуемых
функций и не помешает добавлению новых команд в ПО.
Производительность разработки и человеческие факторы. Даль-
нейшее рассмотрение проблемы увеличения производительности
разработки ПО заключается в установлении баланса между жиз-
ненным циклом программного изделия и жизненным циклом про-
граммистов. Другими словами, необходим баланс материально-
экономического понятия работы как деятельности, которая увели-
чивает денежную стоимость изделия, и социально-экономического
понятия работы как деятельности, помогающей человеку формиро-
вать свой характер. Недопустима рутинизация процессов разоабот-
ки ПО по сценарию, предложенному в работе [180].
Рутинизация в организации программных проектов может вре-
менно увеличить производительность разработки, но затем оказы-
вает на нее длительное негативное воздействие. В то же время это
порождает в людях потерю интереса к профессиональному росту,
к целям предприятия, приводит к утрате способности ориентиро-
ваться в новой ситуации и потере квалификации инженера-програм-
миста.
К счастью, цели эффективной разработки ПО и стремления раз-
работчика продвинуться по службе не являются конфликтными.
В заключение можно выделить некоторые ключевые моменты в
повышении производительности разработки и сопровождения ПО.
Серьезной проблемой 80-х годов будет проблема повышения
производительности, разработки для большинства систем обработ-
ки данных. Спрос на новое ПО значительно превышает возможно-
сти программистов создавать это ПО.
Производительность разработки и сопровождения для большин-
ства систем обработки данных можно увеличить в два раза за 3 ...
4 года и в пять раз за 6... 8 лет. Этого можно достичь только при
условии создания программы увеличения производительности раз-
работки и сопровождения ПО. Однако никто не должен ожидать
получения немедленных результатов.
Стоимостные атрибуты и. коэффициенты затрат в КОМОСТ мо-
гут обеспечить естественные основы для выработки и применения
стратегии повышения производительности разработки ПО. Как
видно из рис. 33.1, помимо практики современного программирова-
489
ния имеются очень большие возможности увеличения производи-
тельности разработки ПО. В частности, правильное использование
возможностей бригады программистов, обеспечение их заинтере-
сованности и хорошее управление могут дать наибольшую отдачу.
Лучшей программой увеличения производительности разработки
является та, в которой учитываются как жизненный цикл програм-
много изделия, так и жизненный цикл его разработчиков.
Еще большего повышения производительности разработки про-
грамм, чем от использования указанных выше факторов, можно
добиться применением существующего ПО. Более подходящей ме-
рой оценивания производительности при использовании существу-
ющего ПО, чем ЧИК/ЧМ, является функциональность ПО на еди-
ницу затрат.
Невозможно добиться значительного повышения производитель-
ности разработок без полной поддержки высшего руководства. Ру-
ководство может, например, дифференцированно повышать зар-
плату, отстранять неподходящих исполнителей, обеспечивать
соблюдение дисциплины, отстаивать интересы разработчиков при
установлении заказчиком нереальных сроков или изменений тре-
бований.
Самый лучший путь в реализации программы повышения про-
изводительности разработки ПО — назначение исполнителей та-
кой программы. Исполнители должны отвечать за определение,
оценивание и подготовку пути повышения производительности раз-
работки. Они могут также участвовать в оценивании стоимости
программных изделий, сборе статистических данных и анализе де-
ятельности, связанной с разработкой ПО.
Еще одно замечание заслуживает особого внимания. При повы-
шении производительности разработки ПО недопустимо смешение
средств и результатов. Увеличение производительности не является
самоцелью. Это средство, помогающее специалистам лучше ис-
пользовать свои способности при работе с данными, обработке ин- *
формации и принятии решений. При этом следует помнить, что
оценивание повышения производительности разработки ПО явля-
ется только одним из многих путей оценивания профессионального
роста специалистов по обработке данных.
1. [Adams, 1980]. E.N. adams, “Minimizing Cost Impact of Software Defects,’’ IBM Research
Report RC 8228, April 1980. \
2. [ADPESO, 1976]. U.S. Navy ADP Equipment Selection Office, “1977 Fortran Compiler Valida-
tion System—Version 1.0: Project History,” Department of the Navy, Washington, DC,
September 1976.
3. [AFIPS-Time, 1971]. A National Survey of the Public's Attitudes Toward Computers, AFIPS
and Time, Inc., November 1971.
4. [AFIPS, 1973]. “AFIPS Programmer Job Description Survey Booklet," AFIPS, 1973. \
5. [Air Force. 1966] Air Force Space and Missile Systems Organization. “Computer Program
Subsystem Development Milestones.” SSD Exhibit 6I-47b, April 1, 1966. \
6. [Air Force, 1974] Proceedings, Government/Industry Software Sizing and Costing Workshop,
U.S. Air Force Electronic Systems Div., Bedford, MA, October 1974.
7. [Air Force, 1978] Cost-Schedule Management of Non-Major Contracts. AFSCP 173-3, U.S.
Air Force Systems Command, Andrews AFB, MD, November 1978
8. [Albrecht, 1979]. AJ. albrecht, “Measuring Application Development Productivity," in
[SHARE-GUIDE, 1979], pp. 83-92.
9- [Alford, 1977]. M.w. alford. “A Requirements Engineering Methodology for Real-Time Pro-
cessing Requirements,” IEEE Trans. Software Engr., January 1977, pp. 60-68.
10. [Atmer, 1966]. F. ARMER, “Computer Aspects of Technological Change, Automation, and
Economic Progress,” P-3478, The Rand Corp., November 1966.
11. [Aron, 1969]. J.D. ARON', Estimating Resources for Large Programming Systems, NATO Science
Committee, Rome, Italy, October 1969.
12- [Aron,1974]. j.d. ARON, The Program Development Process: The Individual Programmer, Addi-
son-Wesley, Reading, MA, 1974.
13. [Aron-Arthur, 1975]. j.d. aron and r.w. Arthur, “Computing Resource Requirements for
Programming Development,” IBM-FSD, Gaithersburg, MD, 1975.
14. [Arvey-Hoyle, 1973]. r.d. arvey and J.C. HOYLE, “Evaluating Computing Personnel,” Data-
mation, July 1973. pp. 69-73.
15. [Asch and others. 1975]. A. Asch and others. DoD Weapon System Software Acquisition and
Management Study. Report MTR-6908, MITRE Corp., Bedford, MA.. June 1975
16. [Auerbach, 1980]. Auerbach Computer Technology Reports, Auerbach Publishers. Inc., 6560
No. Park Dr.. Pennsauken, NJ 08109, periodical.
17- [Augustine. 1979]. N.R. augustine, “Augustine’s Laws and Major System Development Pro-
grams.” Defense Systems Management Review, 1979, pp. 50-76.
18. [Aviation Week, 1970]. “United Drops Univac Contractfor S56 Million Data Sy stem,"Л ria ticti
Week. Feb. 9, 1970. p. 3L
19. [Bailey-Basili. 1981]. J.W. bailey and v.r. BASILT, “A Meta-Model for Software Development
Resource Expenditures,” Proceedings. Fifth International Conference on Software Engineer-
ing. IEEE/ACMZNBS, March. 1981. pp. 107-116.
20. [Bairdain. 1964]. E.F. bairdain, “Research Studies of Programmers and Programming,” 1364.
Unpublished studies, pp. 62, 78, 136, New York.
21- [Baker, 1972]. F.T. BAKER, “Chief Programmer Team," IBM Syst. J„ JI, 1,1972.
22. [Basili-Turner. 1975]. V. basili and A. turner, “Iterative Enhancement: A Practical Tech-
nique for Software Engineering,” IEEE Trans. Software Engr., December 1975, pp.‘ 390-
396.
491
23. [Basili and'others, 1977]. v.r. bash i. m.v. zelkowitz, f.e. mcgarry, r.w. reiter, jk*
w.f: truszkowski, and d.l. weiss, "The Software Engineering Laboratory,” TR-535,
University of Maryland, May 1977.
24. [Basili-Zelkowitz, 1978]. v.r. basili and M v. ZELKOWITZ, “Analyzing Medium-Scale Soft-
ware Development,” Proceedings. Third International Conference on Software Engineering.
IEEE/ACM/NBS, May 1978, pp. 116-123.
25- [Basili-Reiter, 1979]. v.r. basili and r.w. reitfer, jr., “An Investigation of Human Factors
in Software Development," Computer. December 1979, pp. 21-38.
26. [Batdi, 1980]. v.r. ASil.l, Tutorial on Models and Metrics for Software Management and
Engineering. IEEE Catalog No. EHO-167-7, October 1980.
27- [Basili-Beane, 1980]. v.r' basili and J. beane. "Can the Par Curve Help with the Manpower
Distribution and Resource Estimation Problems?” Univ, of Maryland, July 1980.
28, [Basili-Weiss, 1981]. v.r. basili and d.m. weiss, “Evaluation of a Software Requirements
Document by Means of Change Data," Proceedings. Fifth International Conference on
i Software Engineering. IEEE, March 1981, pp. 314—323.
29- [Belady-Lchman. 1979]. i .л. bi.lady and m.m. i ehman, “Characteristics of Large Systems,
in P. Wegner (ed), Research Directions m Software Technology. M.I-T. Press, Cambridge,
MA, 1979.
30. [Bell and others, 1975]. l.E. bell, b.w. boehm. and s. Jeffery (ed), Computer Performance
Evaluation: Report of the 1973 NBS/ACM Workshop, NBS Special Publication 406, U.S,
Government Printing Office, Washington, DC, 1975.
31. [Bell-Thayer, 1976]. Т.Е. BELL and T.A. THAYER, “Software Requirements: Are They Really
a Problem?”, IEEE Proceedings, Second International Conference on Software Engineering.
October 1976; pp. 61-68.
32. [Bell and others, 1977]. T.E. BELL, D.C. BIXLER, and M.E. DYER, “An Extendable Approach
to Computer-Aided Software Requirements Engineering,” IEEE Trans. Software Engr.,
January 1977, pp. 49-59.
33. [Black and others, 1977]. r.k.d. black, r.p. curnow, r. Katz, and M.D. CRAY, BCS Software
Production Data. Final Technical Report, RADC-TR-77-116, Boeing Computer Services,
Inc., March 1977. NTIS No. AD-A039852.
34. [Bloodworth and others, 1979]. J.E. Bloodworth, J.R. ELSTON, and M.H. STIEGLITZ, “Mini-
mizing ALCM Software Life Cycle Cost,” Proceedings, AIAA Second Computers in Aero-
space Conference, October 1979, pp. 23-32.
35- [Boehm, 1970]. B.w. BOEHM, “Some Information Processing Implications of Air Force Space
Missions: 1970-1980,” The Rand Corp., RM-6213-PR, January 1970.
36- [Boehm and others, 1971]. B.w. boehm, m.J. seven, and «.a. Watson, “Interactive Problem
Solving An Experimental Study of 'Lockout* Effects,” Proceedings, 1971 SJCC, AFIPS,
pp. .205-210.
37. [Boehm-Haile, 1972]. B.w. boehm and A C. haile, Information Processing/Data Automation
Implications of Air Force Command and Control Requirements in the I980’s (CCIP-85),
Vol. I: Highlights. Report SAMSO/XRS-71-1, U.S. Air Force Systems Command (NTIS:
AD 900031L), Los Angeles, CA, April 1972.
38. [Boehm, 1973]. b.w. boehm, “Software and its Impact: A Quantitative Assessment,” Datama-
tion, May 1973, pp. 48-59.
39. [Boehm and others, 1974]. b.w. boehm, c.a. bosch, a.s. liddle, and R.w. Wolverton.
The Impact of New Technologies on Software Configuration Management, TRW Report
to USAF-ESD, Contract F19628-74-C-0154, 10 June 1974.
40. [Boehm and others, 1975]. B.w. boehm, c.e. holmes, g.r. katkus, J.p. romanos, r.c.
MCHENRY, and E.K. Gordon, “Structured Programming: A Quantitative Assessment,’*
Computer, June 1975, pp. 38-54.
41. [Boehm, 1976]. B.W. boehm, “Software Engineering,” IEEE Trans. Computers, December
1976, pp. 1226-1241.
42* [Boehm and others, 1978] b.w. bofhm, j R. brown, h. kaspar, m. lipow, cj. macleod.
and MJ. MERRITT, Characteristics of Software Quality. North-Holland, New York, 1978.
43. [Boebm-Wolverton, 1978]. B.w. boehm, and R.w. Wolverton, L^ftware Cost Modeling;
Some Lessons Learned,” Proceedings, Second Software Life-Cycle Management Workshop.
U.S. Army Computer Systems Command, Atlanta, August 1978. Also in Journal of Systems
and Software, 1, 3, 1980, pp. 195-201.
44. [Boehm, 1979]. B.w. boehm, “Guidelines for Verifying and Validating Software Requirements
and Design Specifications,” Proceedings, EuroIFJP Congress. September 1979, pp. 711-
720.
45. [Boehm, 1980]. B.W. BOEHM, “Developing Small-Scale Application Software Products: Some
Experimental Results,” Proceedings, IFIP 8th World Computer Congress, October 1980,
pp. 321-326. See also [Boehm, 1981].
46. [Boehm, 1981]. B.w. BOEHM, “An Experiment in Small-Scale Application Software Engineer*
ing,” JEEE Trans. Software Engr., 1981 (to appear).
47. [Boeing, 1979]. Boeing Co., “Software Cost Measuring and Reporting,” U.S. Air Force-ASD-
Document D18O-22813-1, January 1979,
48. [Boies-Spiegel, 1973]. S.J. BOIES and MJ. SPIEGEL, “A Behavioral Analysis of Programming;
On the Use of Interactive Debugging Facilities,” IBM Technical Report RC-4472, August
1973. (NTIS AD-772127).
49. [Brandon, 1974]. d.h. Brandon, Data Processing Organization and Manpower Planning, Petro*
celli Books, New York, 1974.
50. [Brandon, 1978]. D.H. Brandon, Data Processing Cost. Reduction and Control, Van Nostrand1
Reinhold, New York, 1978.
51T [Brooks, 1975]. Е.Р. Brooks, JR., The Mythical Man-Month, Addison-Wesley, Reading,'MA,.
1975.
52. [Brooks, 1980]. w.d. brooks, “Software Technology Payoff; Some Statistical Evidence,” IBM-
FSD, Bethesda, MD, April 1980, pp. 2-7.
53. [Brown-Lipow, 1975]. J.R. brown and M. LIPOW, “Testing for Software Reliability,” Proceed-
ings, 1975 International Conference on Reliable Software, April 1975, pp. 518-527.
54. [Brown, 1977]. J.R BROWN, “The Impact of Modern Programming Practices on System Devel-
opment,” TRW, Inc., Final Technical Report, RADC-TR-77-121, Griffiss AFB, NY, May
1977.
55. [Brustman, 1978]. K. BRUSTMAN, “Software Cost Estimation: Two Management Perspectives,”
Proceedings, AIAA/TMSA/DPMA Software Management Conference III, 1978, pp. ЮЗ-
108.
56. [Business Week, 1980] “Missing Computer Software,” Business Week. September 1, 1980,
pp. 46-53.
57« [Buxton, 1980]. I. BUXTON. “Requirements for Ada Programming Support Environments:
’Stoneman’,” U.S. Department of Defense, OSD/R&E, Washington, DC, February 1980.
58. [Canada, 1971]. j.r. Canada, Intermediate Economic Analysis for Management and Engineer-
ing. Prentice-Hall, Englewood Cliffs, NJ, 1971.
59- [Carriere Thibodeau, 1979]. w.m. Carriere and R. Thibodeau, “Development of a Logistics.
Softwaie Cost Estimating Technique for Foreign Military Sales,” Report CR-3-839, General
Research Corp., June 1979.
60. [Chapanis, 1959]. a. chapanis, Research Techniques in Human Engineering, Johns Hopkins
Press, Baltimore, MD, 1959.
61. [Chen-Zelkowitz, 1981]. e. chen and M.V. zelkoWitz, “Use of Cluster Analysis to Evaluate
Software Engineering Methodologies,” Proceedings. Fifth International Conference on Soft-
ware Engineering. IEEE, March 1981, pp. 117-123.
62- [Christensen, 1980]. K. Christensen, “Programming Productivity and the Development Pro-
cess,” IBM Santa Teresa Laboratory, TR 03.083, January 1980.
493
63. [Chrysler, 1978]. E. Chrysler, “Some Basic Determinants of Computer Programming Pro-
ductivity,” Comm. ACM, June 1978, pp. 472-483.
64. [Climis, 1979]. T. CLIM1S, “Software Cost Estimation,” presentation at NSIA Software Work-
shop, Buena Park, CA, February 1979.
65. [CODASYL, 1976]. CODASYL Systems Committee, Selection and Acquisition of Data Base
Management Systems, ACM, New York, March 1976.
66. [Comper, 1979]. F.A, comper, “Project Management for System Quality and Development
Productivity,” Bank of Montreal, Montreal, Quebec, 1979. Also in [SHARE-GUIDE,
1979], pp. 17-23.
67 [Congress, 1976]. U.S. Congress, House of Representatives, “Advanced Logistic (ADP) Sys-
tem,” Dept, of Defense Appropriation Bill, 1976, Report No. 94-517, September 25,
1975, pp. 163-165.
68. [Conway, 1968]. M.E. conway, “How Do Committees Invent?” Datamation, April 1968, pp,
28-31.
69. [Cooper, 1975]. J.D. COOPER, “Characteristics of the Average Coder,” personal communication,
May 1975.
70. [Cortada, 1980]. J.W. CORTADA, EDP Costs and Charges, Prentice-Hall, Englewood Cliffs,
NJ, 1980.
71. [Couger-Knapp, 1974]. J.D. couger and R.W. KNAPP, System Analysis Techniques, John Wiley
& Sons, New York, 1974.
72. [Couger-Zawacki, 1978]. J.D. couger and R.A. zawacki, “What Motivates DP Profession-
als?", Datamation, September 1978, pp. 116-123.
73. [Cozzens, 1980]. M. cozzens, “Cost Data Definitions and Collection Program: Final Report,”
TRW, Inc., prepared for National Bureau of Standards, Contract No. EO-AO1-78-3622,
August, 1980.
74. [Crossman, 1979]. T.D. CROSSMAN, "Some Experiences in the Use of Inspection Teams in
Applications Development,” in [SHARE-GUIDE, 1979], pp. 163-168.
75- [Curtis and others. 1978]. в Curtis, s.P. Sheppard, m.a. borst, p milliman, and T. love,
"Some Distinctions Between the Psychological and Computational Complexity of Soft-
ware,” Proceedings. U.S. Army /IEEE Second Software Life Cycle Management Conference,
Atlanta, August 1978, pp. 166-71.
76. [Curtis. 1979]. в. Curtis, “In Search of Software Complexity," Proceedings, IEEE/PINY Work-
shop on Quantitative Software Models. IEEE Catalog No. THOO67-9, October 1979, pp.
95-106.
77- [Curtis and others, 1979а]. в. cuRTts, s.B. Sheppard, p. milliman, m.a. borst, and T. love,
"Measuring the Psychological Complexity of Software Maintenance Tasks with the Hal-
stead and McCabe Metrics," IEEE Trans Software Engr., March 1979, pp. 96-104.
78. [Curtis and others, 1979b], в. curtis, s.b. Sheppard, and p milliman, “Third Time Charm:
Stronger Prediction of Programmer Performance by Software Complexity Metrics," Pro-
ceedings, Fourth International Conference on Software Engineering. September 1979, pp.
356-360.
79. [Daly, 1977]. e.b. daly, “Management of Software Engineering," IEEE Trans Software Engi-
neering. May 1977, pp. 229-242.
80. [Daly, 1979]. E.B. Daly, “Organizing for Successful Software Development," Datamation,
December 1979, pp. 107-120.
81* [Dantzig. 1963]. g.b. dantzig. Linear Programming and Extensions, Princeton University-
Press, Princeton, NJ, 1963.
82. [Datapro, 1980]. Datapro Directory of Software. Datapro Research Corp., 1805 Underwood
Blvd., Delran, NJ 08075, periodical.
83. [Dearden, 1972). J. dearden, “MIS Is A Mirage," Harvard Business Review, January—Febru-
ary, pp. 90-99.
494
84. [Devenny, 1976]. T.J. devenny, "An Exploratory Study of Software Cost Estimating at the
Electronic Systems Division," Thesis No. GSM/SM/765-4, Air Force Institute of Technol-
ogy, Dayton, OH, July 1976.
85- [Dijkstra, 1968]. E.w. dukstra, “The Structure of the THE’ Multiprogramming System,’’
ACM Communications, May 1968, pp. 341-346.
86? [Dijkstra, 1976]. E.w. DUKSTRA, A Discipline of Programming, Prentice-Hall, Englewood Cliffs,
NJ, 1976
87. [DiNardo, 1975]. G.P. DINARDO, “Computer System Performance Factors at Mellon Bank,"
in [Bell and others, 1975].
88. [Distaso and others, 1979]. J.R. distaso, b.f. kohl, k.r. krause, j. w. shively, e.d s i it к 11.
J.T. ULMER, and l.r. vallembois, “Developing Large-Scale Software: The HMD-SIP
Experience,” TRW Software Series TRW-SS-79-01, February 1979.
89- [Dittman, 1980]. J.T. DITTMAN, Transferability Factor Manual. Veterans Administration, Co-
lumbia, MO 65201, March 1980.
90. [Docherty, 1977]. P. DOCHERTY; IFIP 77 panel remarks, in N. French, “DP Deprives Workers
of Job Satisfaction, Europe Studies Show," Computerworld, August 22, 1977, p. 1.
91. [Doherty, 1970]. w. doherty, “Scheduling TSS/360 for Responsiveness," Proceedings, 1970
FJCC. AFIPS, 1970, pp. 97-111.
92. [Doherty-Kelisky, 1979]. w.j. doherty and R.P. kelisky, “Managing VM/CMS for User
Effectiveness," IBM Syst. J. 18, 1, 1979, pp. 143-163.
93- [Dolotta and others, 1976]. T.A. dolotta and others, Data Processing in 1980-85. John
Wiley & Sons, New York, 1976.
94. [Dolotta and others, 1978]. t.a. dolotta, r.c. haight, and j.r. mashey, “The Programmers*’
Workbench,” Bell System Technical Journal, July-August 1978, pp. 2177-2200.
95. [Dowkont and others, 1967]. a'j. DOWKONt, w.a. morris, and t.d. buettell, A Methodology
for Comparison of Generalized Data Base Management Systems: PEGS. Informatics, Inc.,
March 1967.
96. [Drucker,. 1954]. p.F. drucker, The Practice of Management, Harper & Row, New York,
1954.
97. [Dunsmore-Gannon, 1979]. h.e. Dunsmore and j.d. gannon, “Data Referencing: An Empiri-
cal investigation,” Computer, December 1979, pp. 50-59.
98- [Duvall, 1979]. L. DUVALL, “Quantitative Software Models,” Report SRR-1, Data and Analysis
Center for Software, Rome, NY, March 1979.
99. [Elbing, 1978]. A.o. elbing. Behavioral Decisions in Organizations, Scott, Foresman, and Co.,
Glenview, IL, 1978.
100. [Elliott, 1977]. i.r. elliott, “Life-Cycle Planning for a Large Mix of Commercial Systems,”
Proceedings, U.S. Army ISRAD Software Phenomenology Workshop, August 1977, pp.
203-216.
101. [Elshoff, 1976]. j.l. elshoff, “An Analysis of Some Commercial PL/I Programs,” IEEE
Trans. Software Engr., June 1976, pp. 113-120. '
102. [Elshoff, 1978]. j.l. elshoff, “A Review of Software Measurement Studies at General Motors
Research Laboratories," Proceedings. U.S. Army/IEEE Second Software Life Cycle Man-
agement Conference. Atlanta, August 1978, pp. 172-73.
103. [Emery, 1971] j. emery, “Cost-Benefit Analysis of Information Systems,” J. SM1S. 1971.
pp. 16-46 Repnnted in [Couger-Knapp, 1974], pp. 395-425.
104. [Endres, 1975]. A.B. endues, “An Analysis of Errors and Their Causes in System Programs,”
IEEE Trans. Software Engr.. June 1975, pp. 140-149.
105. [Esterling, 1980]. в. esterling, “Software Manpower Costs: A Model," Datamation. March
1980, pp. 164-170.
106. [Eagan, 1976]. M.E. FAGAN, “Design and Code Inspections to Reduce Errors in Program
495
Development,” IBM Syst. J., 15, 3. 1976, pp. 182-211.
107. [Farquhar, 1970]. j.a. Farquhar, “A Preliminary Inquiry Into the Software Estimation Pro-
cess," RM-6271-PR. The Rand Corp., August 1970.
108- [Farr and others, 1965]. l. farr. v. la bolle, and n.e. willmorth, “Planning Guide for
Computer Program Development,” TM-2314/00/00, System Development Corp, May
1965.
109- [Ferens-Harris, 1979]. D.v ferens and R.L. Harris, “Avionics Computer Software Operation
and Support Cost Estimation,” Proceedings. NAECON 79, Dayton OH, May 1979.
110. [Ferrari, 1978]. D. Ferrari, Computer Systems Performance Evaluation, Prentice-Hall, Engle-
wood Cliffs, NJ, 1978.
111. [Fisher, 1971]. G.H. fisher, Cost Considerations in Systems Analysis. American Elsevier, Newr
York, 1971.
112. [Fitz-Enz, 1978]. J. FITZ-ENZ, “Who is the DP Professional?”, Datamation, September 1978,
pp. 124-129.
113. [Fordyce-Weil, 1971]. j.k. fordyce and R. weil. Managing With People, Addison-Wesley,
Reading, MA, 1971.
114. [Formica, 1978]. G. formica, “Software Management by the European Space Agency: Lessons
Learned and Future Plans,” Proceedings, Third International Software Management Confer-
ence, AIAA/RAeS, London, October 1978, pp. 15-35.
J15. [Frank, 1979] w.L. frank, “The New Software Economics,: Parts 1-4,” Computerworld.
January 1979. Also available in book form from the United States Professional Develop-
ment Institute, Inc., Silver Spring, MD, 1979.
116. ' [Freburger-Basili, 1979]. K. freburger and v.r. basili, “The Software Engineering Labora-
tory: Relationship Equations,” Report TR-764, University of Maryland, May 1979.
117-1 [Frederic, 1974]. b.c. Frederic, “A Provisional Model for Estimating Computer Program
Development Costs,” Tecolote Research, Inc., December 1974.
118. [Freiman-Park, 1979]. F.R. freiman and r.e. park, “PRICE Software Model—Version 3:
An Overview,” Proceedings. IEEE-PINY Workshop on Quantitative Software Models, IEEE
Catalog No. THOO67-9, October 1979, pp. 32-41.
119- [Galinier, 1978]. Personal communication from M. Galinier, Univ, of Toulouse, 1978.
120. (GAO, 1977]. General Accounting Office, “Problems Found with Government Acquisition
and Use of Computers from November 1965 to December 1976,” Report FGMSD-77-
14, GAO, Washington DC, March 1977.
121. [GAO, 1977а]. General Accounting Office, “Millions in Savings Possible in Converting Pro-
grams from One Computer to Another,” Report FGMSD-77-34, GAO, Washington, DC,
September 1977.
122- [GAO, 1979]. General Accounting Office, “Contracting for Software Development—Serious-
Problems Require Management Attention to Avoid Wasting Additional Millions,” Report
FGMSD-80-4, GAO, Washington, DC, Nov. 9, 1979.
123. [Gayle, 1971] J.B. GAYLE, “Multiple Regression Techniques for Estimating Computer Pro-
gramming Cost,” J. Systems Mgmt.. February 1971, pp. 13—16.
124- (Gehring, 1976]. p.f. gehring, jr., “A Quantitative Analysis of Estimating Accuracy in Soft-
ware Development," Ph.D. Dissertation, Texas A&M University, August 1976.
125- [Gellerman, 1963]. S.w. GELLERMAN, Motivation and Productivity. American Management
Association Executive Books, New York, 1963.
126-'(Gerhart-Yelowitz, 1976]. s.L. GERHART and L. yelowitz, “Observations of Fallibility in
Applications of Modem Programming Methodologies,” IEEE Trans. Software Engr.. Sep-
tember 1976, pp. 195-207.
127. [Gilb, 1969]. T. SCHARF (GILB), "Weighted Ranking by Levels,” I AG Journal. 2, 1969, pp.
7-23.
128- [Gilb, 1977] т. gilb, Software Metrics, Winthrop Publishers, Cambridge, MA, 1977.
129- (Gilb-Weinberg, 1977’ t. gilb and g.m. weinberg, Humanize. Input. Winthrop Publishers,
Cambridge, MA, 1977.
130. [Gilb, 1979]. Personal Communication from T. Gilb, 1979.
131. [Glass-Noiseux, 1981]. r.l. glass and r.a. noiseux, Software Maintenance Guidebook, Pren-
vce-Hall, Englewood Cliffs, NJ, 1981.
132- [Goodenough-Gerhart, 1975]. lb. goodenough and s.l. gerhart, “Toward a Theory of
Test Data Selection,” IEEE Trans. Software Engr., June 1975, pp. 156-173.
133. [Gordon-Lamb, 1977]. r.l. Gordon and J.c. lamb, “A Close Look at Brooks' Law,” Datama-
tion, June 1977, pp. 81-86.
134. , [Graham, 1978]. g.s. graham (ed), “Special Issue: Queuing Network Models of Computer
System Performance,” ACM Computing Surveys, September 1978, pp. 219-360.
135- [Grant—Sackman, 1966]. E. grant and H. Sackman, “An Exploratory Investigation of Pro-
grammer Performance Under On-Line and Off-Line Conditions," Report SP-2581, System
Development Corp., Septe-nbe 1966.
136. [Graver and others, 1977]. C.A. graver and others, Cost Reporting Elements and Activity
Cost Tradeoffs for Defense System Software, General Research Corp., Santa Barbara, CA,
March 1977.
137. [Gregory-Atwater, 1957]. r.h. Gregory and t.v. atwater, jr., “Cost and Value of Manage-
ment Information as Functions of Age,” Accounting Research. Ъчиагу 1957, pp. 42-70.
138. ' [Grether-Baker, 1972]. w.F. grether and c.A. baker, “Visual Presentation of Information,”
in Human Engineering Guide to Equipment Design, H.P van Cott and R.G. К inkade
(ed). Government Printing Office, Washington, DC, 1972.
139. [Griffin, 1980]. e.l. griffin, “Real-Time Estimating,” Datamation, June 1980, pp 188-198.
14O. ; [GUIDE, 1979. “GUIDE Survey of New Programming Technologies,” GUIDE Proceedings,*
GUIDE, Inc., Chicago, IL, 1979, pp. 306-308.
141. [Halstead, 1977]. m.h. Halstead, Elements of Software Science. Elsevier, New York 1977.
142->rHalsterd, 1978]. m.h. Halstead, “Software Science: A Progress Report,” Broceedings, U.S.
j'.rmy/IEEE Second Software Life Cycle Management Conference, Atlanta, August 1978,
pp. 174-79.
143. . [Hartwick, 1977]. r.d Hartwick, “Software Venricalion and Validation,” Proceedings, AIAA
Third Software Management Conference, Washington, DC, 1977.
144. [Heart and others, 1970]. f.e. heart, r.e. kahn, s.m. ornstein, w.r. Crowther, and
D.c. walden, “The Interface Message Processor for the ARPA Computer Network,”
Proceedings, SJCC 1970, AF.PS, 1970.
145. [Selmer, 1966]. o. HELMER, Social Technology. Basic Dooks, New York, 1966.
146. [Heninger and others. 1978] k.l. heninger, j.w. kali ander, d.l. Pernas, and j.e. shore.
Software Requirements for the A-7E Aircraft, Report 3876, Naval Research Lab., Washing-
ton, DC, November 1978.
147.. [Herd and others, 1977]. j.r. herd, i.n. postak, w.e. russell, and k.r. stev. art, Software
Cost Estimation Study—Study Results, Final Technical’Report, RADC TR -77-220, Vol.
I (of two), Doty Associates; Inc., Rockville, MD, June 1977.
148- [Herzberg and others, 1959]. f. herzberg, в. mausner, and b.b. snyderman, The Motivation
to Work. John Wiley & Sons, New York, 1959.
149. [Hice and others, 1974]. g.f. hice, w.s. turner, and l.i Cashwell, System Development
Methodology, North- lolland, 1974.
150. [Horowitz-Sahni, 1976] E. HOROWITZ and s. SAHNI, Fundamentals of Data Structures, Com-
puter Science Press, Woodland Hills, CA, 1976.
151- [Horowitz-Sahni, 1978] E. horowitz ano s. SAHNI, Fundamentals of Computer Algorithms,
Computer Science Press, Woodland Hills, CA, 1978.
497
152. [Houtz-Buschbach, 1981]. c. HOUtz and т. buschbach, “Review and Analysis of Conversion
Cost-Estimating Techniques,” GSA Federal Conversion Support Center Report No- GSA/
FCSC-81/001, Falls Church, VA, March 1981.
153. [Howden. 1978]. -w.e. howden, “Theoretical and Empirical Studies of Program Testing,”
IEEE Trans. Software Engr., July 1978, pp. 293-297.
154. (IBM. 1977]. IBM Corp.. “Auditability and Productivity Information Catalog: System 370,”
IBM, September 1977.
155. [ICP, 1980]. ICP Directory: Data Processing Management, International Computer Programs,
Inc., 9000 Keystone Crossing, Indianapolis, IN 46240, periodical.
156. [Infotech, 1978]. Structured Programming:Practice and Experience, Infotech International Ltd.»
Maidenhead, England, 1978.
157. [Ingrassia, 1978]. f.s. ingrassia, "Combating the 90% Syndrome,” Datamation, January 1978,
. pp. 171-176.
158- (Ivie, 1977]. E.L. IVJE. “The Programmer’s Workbench: A Machine for Software Development,”
Comm. ACM, October 1977, pp. 746-753.
159 [Jackson, 1975]. m.a. jackson, Principles of Program Design, Academic Press, New York,
1975.
160. [Jeffery-Lawrence, 1979]. D.R. Jeffery and MJ. Lawrence, “An Inter-Organizational Com-
parison of Programming Productivity,” Proceedings. Fourth International Conference on
Software Engineering, IEEE Catalog No. 79 CH 1479-5C, September 1979, pp. 369-377.
161. [Jensen-Tonies. 1979]. r.w. jensen and c.c. tonies, Software Engineering, Prentice-Hall,
Englewood JS'liffs, NJ, 1979.
162. [Jones-Nelson, 1976]. L.c. JONES and d.a. nelson, "A Quantitative Assessment of IBM’s
Programming Productivity Techniques," Proceedings, АСМ/IEEE 13th Design Automation
Conference, June 1976.
163- [Jones, 1975]. T.c. JONES, “Programming Defect Removal,” Proceedings, GUIDE 40, Miami,
FL, May 1975.
164. [Jones, 1977]. T.c. JONES, “Program Quality and Programmer Productivity,” IBM TR 02.764,
28 January 1977.
165- [Jones, 1978]. t.c. jones, “Measuring Programming Quality and Productivity,” IBM Syst.
J.. 17, 7, 1978, pp. 39-63.
166. [Jones, 1979]. T.c. jones, “A Survey of Programming Design and Specification Techniques,”
Proceedings. IEEE Specifications of Reliable Software Conference. March, 1979, pp. 91-
ЮЗ.
167. [Joslin, 1968]. E.D. JOSLIN, Computer Selection, Addison-Wesley, Reading, MA, 1968.
168. [Kanter, 1972]. J.KANTER, Management-Oriented Management Information Systems, Prentice-
Hall, Englewood Cliffs, NJ, 1972.
169- [Kendall-Lamb, 1977]. R.c. kendall and E.c. lamb, “Program Usage Studies,” Proceedings,
GUIDE. May 1977.
170. [Kernighan-Plauger, 1974]. b.w. kernighan and pj. plauger, The Elements of Program-
ming Style. McGraw-Hill, New York, 1974.
171. [Kernighan-Plauger, 1976]. b.w. kernighan and P.J. plauger, Software Tools. Addison-
Wesley, Reading, MA, 1976.
372. [King-Schrems, 1978]. J.L. king and e.L. schrems, “Cost-Benefit Analysis in Information
Systems Development and Operation,” ACM Computing Surveys, March 1978, pp. 19-
34.
173. [Kleijnen, 1980]. J.p.c. KLE1JNEN, Computers and Profits: Quantifying Financial Benefits of
Information, Addison-Wesley, Reading, MA, 1980.
174. [Kleinrock, 1976]. l. kleinrock, Queuing Systems, Vol. 2; Computer Applications, John Wiley
& Sons, 1976.
175? [Knuth, 1969]. D.E. KNUTH, The Art of Computer Programming. Vol. II; Seminumerical Alga-
498
rithms. Addison-Wesley, Reading, MA, 1969."
176*[Knuth, 1973]. d.e. knuth, The Art of Computer Programming. Vol III: Sorting and Searching.
Addison-Wesley, Reading, MA, 1973.
177? [Knuth, 1973а]. D.E. knuth. The Art of Computer Programming. Vol I: Fundamental Algo-
rithms. (2nd ed), Addison-Wesley, Reading, MA, 1973.
178. [Koontz-O’Donnell, 1972]. H. KOONTZ and c. O'DONNELL, Principles of Management: An
Analysis of Managerial Functions (5th ed), McGraw-Hill, New York, 1972.
179, [Kossiakoff and others, 1975]. A. kossiakoff, “DoD Weapon Systems Software Management
Study," Applied Physics Laboratory, The Johns Hopkins Univ., Laurel, MD, Rep. SR-
75-3, June 1975.
180. [Kraft, 1977]. p. kraft, Programmers and Managers: The Routinization of Computer Program-
, ming in the United States, Springer-Verlag, New York, 1977.
181. [Lanergan-Poynton, 1979]. R.G. LANErcan and b.a. poynton, “Reusable Code—The Appli-
cation Development Technique of the Future,’’ in [SHARE-GUIDE, 1979], pp. 127—
138.
182. J [Lasher, 1979]. w. lasher, “Software Cost Evaluation and Estimation: A Government Source
Selection Case Study,” Proceedings. IEEE/PINY Workshop on Quantitative Software Mod-
els. IEEE Catalog No. TH0067-9, October, 1979. pp. 42-55.
183. [Lehman, 1978]. m.m. Lehman, “Laws and Conservation in Large-Program Evolution,” Pro-
ceedings. U.S. Army Second Software Life-Cycle Management Workshop, IEEE Report
78CH-1390-4C, August 1978, pp. 140^145.
184. [Lientz-Swanson, 1978]. B.P. LIENTZ and E.B. SWANSON, “Software Maintenance: A User/
Management Tug-of-War,” Data Management. April 1979, pp. 26-30.
185. [Lientz-Swanson, 1980]. B.P. LIENTZ and E.B. SWANSON, Software Maintenance Management:
A Study of the Maintenance of Computer Application Software in 487 Data Processing
Organizations. Addison-Wesley, Reading, MA, 1980
186-'[Lipow and others, 1977]. M. L1POW, b.b. white, and B.w. BOEHM, “Software Quality Assur-
ance: An Acquisition Guidebook," TRW Software Series, TRW-SS-77-07, November 1977.
187. [Lipow, 1979]. M. lipow, “Prediction of Software Failures," Journal of Systems and Software,
1, 1. 1979, pp. 71-76.
188. [Luce-Raiffa, 1957]. r.d. luce and H. raiffa, Games and Decisions, John Wiley & Sons,
1957
189. [Lundell 1979]. E.D. LUNDELL, jr„ “Software for IBM 4300 May Cost More Than Hardware,”
Computerworld, April 30, 1979, p. 1.
•190. [Maciariello, 1978]. J.A. maciarieLIO, Program-Management Control Systems, John Wiley
& Sons, New York, 1978.
191* [Martin, 1973]. J. martin. Design of Man-Computer Dialogues, Prentice-Hall, Englewood
Cliffs, NJ, 1973.
192-1 [Martin, 1979]. T. martin, “PEARL at the Age of Three,” Proceedings, Fourth International
Conference on Software Engineering. IEEE, September 1979, pp. 100-109.
193. [Maslow, 1954]. a h. maslow. Motivation and Personality, Harper and Row, New York,
1954.
194. . [Mayer-Stalnaker, 1968]. d.b. MAYER and A.w. STALNAKER, "Selection and Evaluation of
Computer Personnel,” Proceedings, ACM National Conference 1968, ACM, 1968, pp. 657—
670. Also in [Weinwurm, 1970], pp. 133-157.
195. [Mayo, 1945]. E. mayo. The Social Problems of an Industrial Civilization, Harvard University
Press, Cambridge. MA, 1945.
196. [McCabe, 1976]. T.J. mccabe, "A Complexity Measure, '’IEEE Trans' Software Engr., Decem-
ber 1976, pp. 308-320.
197. [McCracken, 1980]. d.d. mccracken, A Guide to NOMAD for Applications Development,
499
National CSS, Inc, Wilton, CT, 1980.
198. [McCracken, 1980а]. d.d. mccracken, “Software in the 80s: Perils and Promises,” Computer-
world, September 17, 1980, pp. 5-10.
199- [McCracken, 1981]. D.D. mccracken, “A Maverick Approach to Systems Analysis and De-
sign,” in Systems Analysis and Design: A Foundation for the 1980s, Elsevier-North Holland,
1981.
200. .- [McCue, 1978] C.M. mccue, “IBM Santa Teresa Laboratory—Architectural Design for Pro-
gram Development,” IBM Syst. J., 17, I. i978, pp. 4-25.
201. [McGarry, 1979]. F. mcgarry, “Overview of the Software Engineering Laboratory,” Proceed-
ings, Fourth Summer Software Engineering Workshop, NASA-Goddard, Greenbelt, MD,
November, 1979, pp. 3-16.
202. [McGregor, 1960]. D. mcgregor, The Human Side of Enterprise, McGraw-Hill, New York,
1960.
203. [Meister, 1976]. D. Meister, Behavioral Foundations of System Development, John Wiley &
Sons, 1976.
204. [Merwin, 1978]. r.e. merwin, (ed), “Special Section on Software Management,” IEEE Trans.
Software Engr., July 1978, pp. 307-361.
205. [Metzger, 1973]. P.J. Metzger, Managing a Programming Project. Prentice-Hall, Englewood
Cliffs, NJ, 1973.
206. [Miller, 1956]. g.a. miller, “The Magical Number Seven, Plus or Minus Two: Some Limits
on Our Capability for Processing Information,” Psych. Review, March 1956, pp. 81-97.
207. [Miller, 1968]. r.b. mil-er, “Response Time in Man-Computer Conversational Transactions,"
Proceedings. 1968 SJCC. AFIPS. 1968, pp. 267-277.
208. [Miller, 1980]. e.f. miller, jr., “Survey of Verification and Validation Technology,” Proceed-
ings, NRC/IEEE Conference on Advanced Electrotechnology Applications to Nuclear Power
Plants. IEEE, January 1980.
209» [Milliman-Curtis, 1980]. P. milliman and B. CURTIS, “A Matched Project Evaluation of
Modem Programming Practices,” General Electric Co., RADC-TR-80-6, February 1980.
210. [Mills, 1970]. H.D. mills, “Structured Programming in Large Systems," 1BM-FSD, 1970.
211. [Millstein and others, 1976]. R. millstein and others, “National Software Works. Status
Report No. 1," RADC TR 76-276, U.S. Air Force, September 1976.
212. [Moher-Schneider, 1981]. t. moher and g.m Schneider, “Methods for Improving Controlled
Experimentation in Software Engineering,” Proceedings. Fifth International Conference
on Software Engineering, IEEE, March 1981, pp. 224-233.
213, [Morin, 1973]. l.h. morin, “Estimation of Resources for Computer Programming Projects,”
Master’s Thesis, University of North Carolina, 1973.
214. [Mornsey-Wu, 1979]. J. Morrisey and s.Y wu, “Software Engineering: An Econom c Perspec-
tive,” Proceedings. Fourth International Conference on Software Engineering. IEEE Catalog
No. 79 Ch 1479-5C, September 1979, pp. 412-422.
215. [Musa, 1975]. J.D. Musa, “A Theory of Software Rehabilit. and Its Application,” IEEE Trans.
Software Engr., September 1975, pp. 312-327.
216. [Musa, 1979]. J.D. musa, “Validity of Execution Time Theory of Software Reliability,” IEEE
Trans. Reliability, August 1979, pp. 181-191.
'217. [Musa, 1980]. J.D, musa, “The Measurement and Management of Software Reliability,” IEEE
Trans, Software Engr., to appear, 1981.
21 fi* [Myers, 1976]. c l. MYERS, Software Reliability. John Wiley & Sons, Inc. New York, '1976.
219. [Myers, 1978]. g.J. Myers, “A Controlled Experiment in Program Testing and Cede Walk-
throughs/Inspections,” Comm., ACM, September .978, pp. 760-768.
220. [NASA, 1980]. “Computer Program Abstracts," NASA-COSMIC, Umv. of Georgia, Athens,
GA 30602,.periodical.
221. [Naur, 1969]. P. naur, “Programming by Action Clusters,” BIT 9, 3, 1969, pp. 250-258.
222. [Naur Randell, 1968]. r. naur and B. randell, Software Engineering, NATO Scientific Af-
fails Di.jsioiii. Brasses, Belgium, 1968.
223. [Nelson, 1966]. E.A. nelson, Management Handbook for the Estimation of Computer Program-
ming Costs, AD-A648750, Systems Development Corp., Oct. 31, 1966.
224. 'Nelson, 1978]. R. nelson, Software Data Collection and Analysis at RADC. Rome Air Develop-
ment Center, Rome, NY, 1978
22$. [Norden, 1958]. P.v. norden, “Curve Fitting for a Moi el of Apokied Research and Develop-
ment Scheduling,” IBM J. Rsch. Dev., Vol. 2, No. 3, July 1958.
226. [Norden, 1970]. P v norden, “Useful Tools for Project Management," in Management of
Production. M.K. Starr, ed Penguin Books, Baltimore MD, 1970, pp. 71-101
227. [NTIS, 1980]. National Technical Information Service (NTIS), A Directory of Computer Soft-
ware and Related Technical Reports 1980, NTIS, Dept, of Commerce, 52L5 Port Royal
Rd., Springfield, VA 22161, 1980.
228. [Oliver, 1979]. p. Oliver, “Handbook .or Estimating Convers>on Costs of Large Business
Programs,' ADPESO, U.S. Navy, Washington, DC 20376, February 1979.
229- [Parikh, 1980]. G. parikh (ed). Techniques of Program and System Maintenance. "Lino-tech,
Inc., Lincoln, NB, 1980.
230- [Parker, 1976]. d.b. Parker, Crime by Computer. Scribner's, New York, 1976.
231*'[Parkinson; 1957]. G.N. Parkinson, Parkinson’s Law and Other Studies in Administration.
Houghton-Mifflin, Eoston, Г 957.
232. fPamas, 1976]. d.l. parnas, “On the Design and Development of Program Families,” IEEE
Trans. Software Engr.. March 1976, pp. 1-9.
233. [Pamas, 1979]. D.L. parnas, “Designing Software for Ease of Extension and Contraction,”
IEEE Trans. Software Engr., March 1979, pp. 128-’37.
234. [Parr, 1980]. f.n. parr, “An Alternative to the Rayleigh Curve Mode, for Software Develop-
ment Effort,” 'EEE Trans. Software Engr , May 1980, pp. 291-296
235. [Pas:er, 1981]. d.l. paster, “Experience with Application of Modem Software Management
Controls,” Proceedings. Fifth International Conference on Software Engineering. IEEE,
March 1981, pp. 18-26.
236. [Patrick, 1980]. r.l. Patrick, “Probing Productivity,” Datamation, September 1980, pp. 207-
210.
237. [Peter-Hull, 1969’ ui. peter and R. HULL, The Peter Principle. William Morrow, New York,
1969.
238- [Phister, 1979]. M. phister, jr., Data Processing Technology and Economics. Digital Press,
• Bedford, MA, 1979.
239. [Pietrasanta, 1970]. a.m. pietkasanta, “Resource Analysis of Computer Program System
Development," in [Weinwurm 1970].
240. [Pitched, 1979]. R. pitchell, “The GUID-E Productivity Program,” GUIDE Proceedings.
GUIDE, Inc., Chicago, IL, 1979, pp 783-794.
241. [Putnam, 1976] l.h put“ am, “A Macro-Estimating Methodology for Software Develop-
ment,” Droceedings, IEEE COMPCON 76 Fall, September 1976, pp. 138-143.
242. [Putnam-Wolverton, 1977]. L.H. putnam and R.w. Wolverton, “Quantitative Management:
Software Cost Estimating," IEEE Comp. Soc. First Int'L Compute- Software and Applica-
tions Conf. (COMPSAC 77), IEEE Catalog No. EHO 129-7, Chicago, IL, November
8-11, 1977.
243. [Putnam, 1978]. l.h. putnam, “A General Empirical Solution to the Macro Software Sizing
and Estimating Problem,” IEEE Trnns. Software Engr., July 1978, pp 345-361.
244- [Putnam-Fitzsimmons, 1979]. L.H. putnam and A. FirzsiMi ions, “Estimating Software
501
' Costs,” Datamation. September 1979, pp. 189-198. Continued in Datamation, October
1979, pp. 171-178 i nd November 1979, pp. 137-140.
245-[Putnam. 1980]. “jLIM System Description," Quantitative Software Management, Inc.,
McLean, VA, 1980
246. [Quade, 1968]. e.s. quade, “Principles and Procedures of Systems Analysis," in Systems Analy-
sis and Policy Planning: Applications in Defense. E.S. Quade and W.I. Boucher (cd), Elsevier,
New York, 1968.
247. [Rand, 1957]. a. rand, Atlas Shrugged, Random House, Inc., New York, 1957.
248- [Raskin, 1978]. L. raskin, Performance Evaluation ofMultiple Processor Systems. Report CMU-
CS-78-141, Carnegie Mellon Univ., Pittsburgh, PA, August 1978.
249- [RCA, 1978]. RCA PRICE Systems, “PRICE Softwaie Model: Supplemental Information,”
RCA, Cherry Hill, NJ, March 1978.
250- [Reaser-Carrow, 1975]. J.M. rfaSER and LC. CARROW, “In.er?ctive Programming: Summary
of an Evr'uuiion and Some Management Considerations,” Report USACSC-AT-74-03,
. U.S. Ai my Computer Systems Command, March 1975.
251. [Reifer, 1977]. D.I. reifer, “Software Acquisition Planning for th,. DoD Space Transporta.-or
System (Space Shuttle),” Proceedings, AIAA/DPMA Third Software Management Confer-
ence. Washington, DC, December 1977, pp. 81-90.
'252. [Reifer-Trattner, 1977]. dj. reifer and s. trattner, “A Glossary of Software Tools and
Techniques,” Computer, July 1977, pp. 52-60.
253. [Reifer, 1978]. D.l. reifer, Verification, Validation, and Certification: A Software Acquisition
Guidebook, TRW-SS-78-05, TRW Software Series, September 1978.
254. [Reifer, 1981]. d.j. reifer, “The Software Tools Directory,” Reifer Consultants, Inc., Torrance,
CA, 1981.
255. [Remus-Zilles, 1979]. H. REMUS a id s. zilles, “Prediction and Management of Program
Quality,” Proceedings, Fourth International Conference on Software Engineering, IEEE»
September 1979, pp. 341-350.
256. [Ross-Schoman, 1977]. d.t. ross and k.e. schoman jr., “Structured Analysis for Require-
ments Definnior. ” IEEE Trans. Software Engr.. January 1977, pp. 6-15.
257. [Rosove, 1967]. p e. rosove, Developing Computer-Based Information Systems, John Wiley
& Sons, New York, 1967.
258- [Royce, 1970]. w.w. ROYCE, “Managing the Development of Large Software Systems: Concepts
and Techniques,” Proceedings, WESCON, August 1970.
259. [Rubey and others, 1975]. rj. rubey, j.a. dana, and P.w. biche, “Quantitative Aspects of
Software Validation," IEEE Trans. Softwart Engr., June 1975, pp. 15O-'55.
260- [Sackman, 1967]. H.‘ Sackman, Computers, System Science, and Evolving Society, John Wiley
& Sons, New York, 1967.
261. [Sackman, 1969]. h. sackman, “Experimental Evaluation of Time-Sharing and Batch Process-
ing in Teaching Computer Science,” System De-'elopment Corp., SP-3411, October 1969.
262* [Sackman, 1970]. H. sackman, Man-Computer Problem Solving, Auerbach, Philadelphia, PA,
1970.
263- [Schluier, 1977]. r.g. schluter, “Experience in Managing the Development of Large Real-
Time BMD Sottware Systems,” Proceedings, AIAA/NASA/IEEE/ACM Computers in
Aerospace Conference. Los Angeles, October-November 1977, pp. 168-173.
264. [Schneider, 1977]. John Schneider, iv, A Preliminary Calihrction of the RCA PRICr/S
Software Cost Estimation Model, Air Force Institute of Technology, Dayton, OH, Thesis
No. GSM/SM/77S-15, N^IS No. AD-A046808, September 197”
265- [Schneider, 1978]. v. schneider, “Prediction of Software Effort and Project Duration: Four
New Formulas,” ACM SIGPLAN Notices, June 1978, pp. 49—59.
266. [Schumacher, 1973]. e.f. Schumacher, Small Is Beautiful: Economics as if People Mattered.
5C2
Harper and Row, New Yorfr, 1973.
267. [S'.ott-Simmons, 1974]. R.F. scon md D.B. SIMMONS, "Programmer Productivity and the
Delphi Technique,” Datamation, May 1974, pp. 71-73.
268» [SHARE-GUIDE, 1979]. SHARE, Inc., and GUIDE International, Proceedings. Application
Development Symposium, October 1979, available through cither SHARE or GUIDE Secre-
tary, 111 E. Wacker Dr., Chicago IL 60601. -
269. [Sharp-, 1969]. W.F. sharps, The Economics of Computers, Columbia Universit- Press, New
York, 1969.
270- [Sheppard and others, 19Ь0]. s.B. sheppard, p. milliman, and в. curtis, “Exptnmcata.
Evaluation of On-Line Program Construction,” Proceedings, IEEE COMPSAC 80, October
1980, pp. 505-510.
271. [Sheppard and others, 1981]. s.b. sheppard. e. krevesi, and в. curtis, "The Effects of
Symbology and Spctial Arrangement on the Comprehension of Software Specifications,”
Proceedings. Fifth International Conference on Software Engineering, IEEE, March 1981,
pp. 207-214.
27 2,.[Shneiderman and others, 1977]. в. shneiderman, R. mayer, d. mckky, and p. heller,
"Experimental Investigations of the Utility of Detailed Flowcharts in Programming.”
Comm. ACM, 20, 1977, pp. 373-^81.
273. [Shneiderman, 1979]. B. shneiderman, "Human Factors Experiments in Designing Interactive
Systems,” Computer, December 1979, pp. 9-19.
274. [Shneiderman, 1980]. B. shneiderman, Software Psychology: Human' Factors in Computer
and Infon lotion Systems, Winthrop Press, Cambridge, MA, 1980.
275- [Shoor. 1981]. R. shoor, ed., “Application Packages: Getting the Right Fit,” Computerworld,
January 26, 1981, pp. SR/1-31.
276. [Steel, 1977]. T.B. steel jr., “A Note on Future Trends,” in P.S. Nyborg (ed). Information
Processing in the United States: A Quantitative Summary, AFIPS, Montvale, NJ, 1977.
277. [Stephenson, 1976]. w.E. Stephenson, An Analysis of the Resources Used in Safeguard System
Software Development, Bell Labs., draft paper. August 1976.
278. [Stokes, 1970]. J.c. stokes, “Managing the Developing of Large Software Systems Apollo
Real-Time Control Center,” Proceedings, WESCON 70, August 1970.
279. [Stone, 1978]. H.s. stone, “Final Report: Life-Cycle Cost Analysis of Instruction Set Architec-
ture Standardization for Military CompuUr-Basol Systems,” U.S. Army Research Office,
January 1978.
280. [Stone-Coleman, 1979]. H.s. stone and A. Coleman, “Life-Cycle Cost Analysis of Instruction-
Set Architecture Standardization for Military Computer-Based Systems," Computer,'April
1979, pp 35-47.
281. [Sukert, 1978]. a.n. sukert, “A Four Project Empirical Study of Software Error Prediction
Models,” Proceedings. COMPS/.C 78. Chicago, November 1978.
282. [Sunohara and others, 1981]. T. sunohara, a."Takano, k. uehara, and T. ohkawa, “Pro-
gram Complexity Measure for Software Development Management,” Proceedings, Fifth
International Conference on Software Engineering, IEEE, March 1981, pp. 100-106.
283. [Swanson, 1976]. e.b. swanson, “The Dimensions of Maintenance,” Proceedings, IEEE/ACM
Second International Conference on Software Engmeer.ng, October 1976.
284. [Telchroew-Hershey, 1977]. D. teichroew and E.A. HERSHEY HI, “PSL/PSA: A Computer-
Aided Technique for Structured Documentation and Analysis of Information Processing-
Systems,” ILEE Trans. Software Engr. January 1977, pp. 41-48.
285. [Thacker and others, 1979]. c.p. thicker, e.m. mccreicht, b.w. lampson, r.f. sproull,
and d.r. boggs, “Alto: A Personal Computer,” Xerox Palo Alto Research Center R-port
CSL-79-11, 1979.
533
286. [Thaj:r and others, 1978]. t.a. thayer, m. lipow, and E.c. nelson. Software Reliability:
A Study of Large Project Reality, North-HollanJ. New York. 1978.
287- [Thurber 1976] k.j thurber, Lurge Scale Computer Architecture: Parallel and Associative
Processors, Haydon, Rochelle Park, NJ, 1976.
288. [Townsend, 1970]. R. towns^nd, Up the Organization, Fawcett Publications, Gre^nw.cb, CT,
1970.
289. [TRW, 1973] TRW, Inc., Software Development and Configuration Management Manual,
TRW-SS-73-07, December 1973.
290*[Wagner, 1977]. h.m. wagner, Principles of Operations Research, (2nd ed) Prentice-Hall,
'Englewood Cliffs, NJ 1977.
291. [Walstor.-belix, 1977] c.E. walston and C.P. lELIX, “A Method of Programming Measure-
ment and Estimation,” IBM Syst. J., 16, I. 1977, pp. 54-73.
292. [Walston-Felix, 1977а]. C.E. walston and C.P. FELIX, “Authors’ Response,” IBM Sys: J.
No 4. 1977, pp. 422-423.
293 [Ware and others, 1974]. w.h. ware and others. Records. Computers, and the Rights of Citizens,
M-I-T- Press, Cambridge, MA, 1974.
294. [Warmer, 1974]. J D. warmer, Logical Construction of Programs, Van Nostrand Reinhold,
New York, 1974.
295. [Webster, 1979] Webster's New Collegiate Dictionary, G.&.C. Merriam Co., Springfield, MA,
1979.
296. [Weinberg, 1971]. g.m. weinberg, The Psychology of Computer Programming, Van Nostrand
Reinhold, New York, 1971.
297. [Weinberg, 1972]. g.m. weinberg, “The Psychology of Improved Programming Performance,”
Datamation. November 1972, pp. 82-85.
298. [Weinberg-Schulman, 1974]. g.m. weinberg and E.L. Schulman, “Goais and Performance
in Computer Programming,” Human Factors, 197 S, 16 (1), 70-77.
299. [Weinberg, 1979]. g.m. weinberg, “The Psychology of Change in Development Methodol-
ogy," in [SH ARF-GUtDE, 1979], pp. 93-100.
300. [Weinwurm, 1970]. G.E weinwurm (ed), On the Management of Compute' Programming,
Auerbacl, New York, 1970.
301. [Weiss, 1979]. D.M. weiss, “Evaluating Software Development by Error Analysis: The Data
from the Architecture Research Facility,” Journal of Systems and Software, 1, 1, \979.
pp. 57-70.
302. [Weissma.i, 1974]. L. Weissman, “A Methodology for Studying the Psychological Complexity
of Compute r P'-cgrams,” Technical Report TR-CSRG-37, Computer Systems Research
Grouo, vlmv. of T oronto, 1974. See also ACM SIGPLAN Notices, June 1974, pp. 25-36.
303. [Weizenbaum, 1976], j. weizenb‘UM. Computer Power and Human Reason. W.H. Freeman,
San Francisco, 1976
3O4. ”[Westin-Baker, 1972]. a.f. westin and m.a. baker, Databanks in a Free Society, Quadrangle
Books, New York, 1972
305. [Wiest-Levy, 1977]. j.d. wiest and F.K. levy, A Management Guide to PERT/CPM. Prentice-
Hall, Eng’ewc^d Cliffs, NJ, 1977.
306. [Williams, 1975]. r.d. williams, “Managing the Development of Reliable Software,” Proceed-
ings, 1975 International Conference ott Reliable Software, IEEE'ACM, Apr J 1975, pp?
3-8.
307. [Williamson, 1979]. I.M. WILLIAMSON, “NARDAC Model,” NRL Technical Memorandum
7503-XXX, July 16, 1979.
308- [Williman, 1969]. Л.О. williman, “Autonetics Programming Cost Data, 1969,” personal com-
munication from A.O. Williman, October 1971.
Б04
309- [WiJJiman-O’Donnell, 1970] A.o. williman and c O'Donnell, “Through the Central 'Multi-
processor’ Avionics Enters the Computer Era,” Astronautics and Aeronautics. July 1970.
310- [Wirth. 1981]. N. wirth, “Lilith: A Personal Computer for the Software Engineer,” Proceed-
ings. Fifth International Conference on Software Engineering, IEEE, March 1981, pp. 2-
15.
311. [Withington, 1972]. F.G. withington, The Organization of the Data Processing Function. Wi-
iey-Interscience, New York, 1972.
312- [Wolff, 1970]. H.T. WOLFF, “The Hospital Ward—A Technological Desert." in Instruments
in Working Environments, Adam Hilger, London, 1970.
313. [Wolverton, 1974]. r.w. Wolverton, “The Cost of Developing Large-Scale Software,” IEEE
Trans. Computers, June 1974, pp. 615-636.
314. [Wolverton, 1980]. r.w. Wolverton, “Airborne Systems Software Acquisition Engineering
Guidebook: Software Cost Analysis and Estimating,” U.S. Air Force ASD/EN, Wright-
Patterson AFB, OH. February 1980.
315. [Woodfield and others, 1981]. S.N. Woodfield, h.e. Dunsmore, and v.Y. shen, “The Effect
of Modularization on Program Comprehension,” Proceedings. Fifth International Confer-
ence on Software Engineering. IEEE, March 1981, pp. 215-223.
316- [Woodside. 1980]. c m. Woodside, “A Mathematical Model for the Evolution of Software,"
J. Systems and Software. Vol. 1, No. 4, 1980. pp. 337-345.
317* [Yourdon, 1975]. E. YOURDON, Techniques of Program Structure and Design. Prentice-Hall,
1975.
318. [Yourdon-Constantine, 1978]. e. yourdon and l.l. Constantine, Structured Design (2ml
ed). Prentice-Hall, Englewood Cliffs, NJ, 1978.
319- [Yourdon, 1979]. E.N. YOURDON, Managing the Structured Technologies. Prentice-Hall, Engle-
wood Cliffs, NJ, 1979
320. [Yourdon, 1979а]. E. yourdon. Structured Walkthroughs. Prentice-Hall, Englewood Cliffs,
NJ, 1979.
СПИСОК КНИГ, ПЕРЕВЕДЕННЫХ НА РУССКИЙ ЯЗЫК
42. Боэм Б., Браун Дж., Каспар X. и др. Характеристики качества программного
обеспечения: Пер. с англ. — М.: Мир, 1981.
51. Брукс Ф. П. мл. Как проектируются и создаются программные комплексы:
мифический человеко-месяц. Очерки по системному программированию: Пер.
с англ. — М.: Наука, 1979.
81. Данциг Дж. Б. Линейное программирование, его применения и обобщения:
Пер. с англ. — М.: Прогресс, 1966.
86. Дейкстра Э. Дисциплина программирования: Пер. с англ.—М.: Мир, 1978.
175 . Кнут Д. Е. Искусство программирования для ЭВМ. Т. 2. Получисленные ал-
горитмы: Пер. с англ —М.: Мир, 1977.
176 Кнут Д. Е. Искусство программирования для ЭВМ. Т 3. Сортировка и поиск:
Пер. с англ. — М.: Мир, 1978.
177 . Кнут Д. Е. Искусство программирования для ЭВМ. Т. 1. Основные алгорит-
мы: Пер. с англ. — М.: Мир, 1976.
191 Мартин Дж. Организация баз данных в вычислительных системах: Пер. с
англ. — М.: Мир, 1978.
218. Майерс Г. Дж. Надежность программного обеспечения: Пер. с англ. — М.:
Мир, 1980.
231 Паркинсон С. Н. Закон Паркинсона и другие памфлеты: Пер. с англ. — М.:
Прогресс, 1976.
262. Сакман Г. Решение задач в системе человек — ЭВМ: Пер. с англ. — М.: Мир,
1973.
290. Вагнер Г. М. Основы исследования операций: Пер с англ. — М.: Мир, 1972.
317. Йодан Э. Структурное проектирование и конструирование программ: Пер.
с англ. — М.: Мир, 1979.
505
ОГЛАВЛЕНИЕ
Предисловие редактора перевода . . ............................. 5
Предисловие .........................................................9
Список сокращений......................................... . .16
ЧАСТЬ 1. ВВЕДЕНИЕ .......... 19
Глава 1. Пример системы обработки подписки на журнал .... 20
90
1.1. Прежняя система..............................................77.
1.2. Программное решение .................................... 99
1.3. Результаты программного решения........................ .
1.4. Экономико-программный подход.................................. ™
1.5. Результаты экономико-программного подхода.................... ок
1.6. Общее обсуждение..............................................
Глава 2. Пример системы учета посещаемости городских школ .
2.1. Программные аспекты..........................................
2.2. Экономические аспекты .......................................
2.3. Социальные аспекты................................ . . . .
2.4. Усвоенные уроки .............................................
Глава 3. Цели инженерного программирования........................
3.1. Введение.....................................................
3.2. Определение инженерного программирования.....................
3.3. Тенденции роста стоимости ПО.................................
3.4. Тенденции роста социального воздействия ПО...................
3.5. Разнообразие целей...........................................
3.6. Пример эксперимента [298]....................................
3.7. Разнообразие средств инженерного программирования .
3.8. Структура целей инженерного программирования.................
3.9. Целеориентированный подход в инженерном программировании
ЧАСТЬ 2. КОЛИЧЕСТВЕННАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ПО .
26
26
26
26
27
28
28
29
31
32
33
34
35
37
42
45
Глава 4. Фазы и работы жизненного цикла ПО .
4.1. Введение ... .......................................
4.2. Каскадная модель..............................................
4.3. Экономическое обоснование каскадной модели.................
4.4. Усовершенствование каскадной модели...........................
4.5. Определение фаз жизненного цикла..............................
4.6. Определение фаз и работ.......................................
4.7. Структура подразделения работ.................................
4.8. Сопровождение ПО..............................................
48
48
49
50
53
58
59
62
65
Глава 5. Базовая КОМОСТ...............................................66
5.1. Введение........................................................66
5.2. Определения и предположения.....................................67
5.3. Затраты труда и сроки разработки................................71
5.4. Распределение по фазам..........................................73
5.5. Номинальные характеристики проектов . 74
5.6. Распределение Рэлея.............................................75
5.7. Интерполяция....................................................77
5.8. Оценка затрат на сопровождение ПО...............................79
506
Глава 6. Базовая КОМОСТ и типы разработок
6.1. Введение........................................... . . . .
6.2. Основные уравнения затрат...................... . .
6.3. Три типа программной разработки................................
6.4. Обсуждение уравнений базовой КОМОСТ.......................
6.5. Распределение затрат труда и сроков разработки по фазам ....
Глава 7. Базовая КОМОСТ и распределение затрат по работам .
7.1. Введение .... ............. ......................
7.2. Распределение затрат труда на каждую работу по фазам
7.3. Пример электронной системы платежей . . . .
7.4 Разработка организационных структур проекта ... .
7.5. Обсуждение распределений по фазам и работам.................
7.6. Ограничения базовой КОМОСТ.....................................
Глава 8. Промежуточная КОМОСТ. Оценка на уровне изделия .
8.1. Введение .... ..........................-
8.2. Оценка затрат труда по промежуточной КОМОСТ . ....
8.3. Пример расчета стоимости разработки ПО связи на микропроцессорах
8.4. Пример управления проектом при уменьшении средств для его завер-
шения .... .......................................
8.5. Корректировка оценки еже годных затрат на сопровождение . . . .<
8.6 Пример сопровождения ПО связи на микропроцессорах . -
8.7. Интерполяция и экстраполяция.........................
8.8. Вычисление коэффициента адаптации существующего ПО .
8.9. Обсуждение уравнений промежуточной КОМОСТ
Глава 9. Промежуточная КОМОСТ. Оценка на уровне компонентов
9.1. Введение.......................................................
9.2. Форма для оценки на уровне компонентов.........................
9.3. Использование ФОК для адаптируемого ПО.........................
9.4. Оценка разработки системы обработки сообщений..................
9.5. Оценка сопровождения СОС на уровне компонентов и распределение
по фазам затрат труда и сроков......................................
ЧАСТЬ 3. основы инженерной экономики по..........................
ЧАСТЬ ЗА. АНАЛИЗ СТОИМОСТЬ — ЭФФЕКТИВНОСТЬ ЗАТРАТ ....
Глава 10. Модели производительности системы и эффективности затрат
10.1. Модели производителоности . . . .................
10.2. Оптимальная производительность
10.3. Анализ чувствительности................... ...................
10.4. Модели эффективности затрат.............................. ...
Глава 11. Производственные функции и эффекты масштаба . . . .
11.1. Пример.....................................................
11.2. Определения...................................................
11.3. Дискретные производственные функции...........................
11.4. Основные производственные функции программной разработки
11.5. Положительные и отрицательные эффекты масштаба................
11.6. Отрицательные эффекты масштаба для больших программных проек-
: -IB..............................................................
11.7. Основной способ уменьшения отрицательных эффектов масштаба .
Глава 12. Критерии принятия решения при выборе альтернатив .
12.1. Максимум производительности при ограниченном бюджете
12.2. Минимум затрат при ограничении производительности.............
12.3. Максимум отношения производительности к затратам..............
79
79
80
83
88
94
101
101
102
106
108
111
114
115
115
117
128
130
131
133
134
135
138
142
142
142
148
150
153
;58
160
160
160
163
165
167
170
170
171
172
172
173
173
174
178
178
179
179
507
12.4. Максимум разности эффективности и затрат..................
12 5. Смешанные стратегии . . -
12.6. Общее обсуждение .....................................
ЧАСТЬ ЗБ. АНАЛИЗ МНОГОЦЕЛЕВЫХ РЕШЕНИИ...............................
Глава 13. Предельный анализ чистой стоимости........................
13.1. Пример........................................................
13.2. Сбщее обсуждение предельного анализа..........................
13.3. Пример........................................................
13.4. Некоторые предостережения относительно использования понятия чи-
стой стоимости.................................... . ....
13.5. Стоимость систем обработки данных.............................
Глава 14. Сопоставление текущих и будущих расходов и доходов .
14.1. Пример упрощенного анализа стоимости..........................
14.2. Насчет процентов ............................. . .
14.3. Расчет текущей стоимости................................. ...
14.4. Текущая стоимость серии ротокф денежной наличности ....
14.5. Итоги анализа вариантов аренды и покупки......................
14.6 Сводка понятий и формул для анализа по текущей стоимости .
14 7. Характеристика текущей стоимости .......
14.8. Чувствительность к ставке процента или учетной ставке ...
149. Применение в инженерном программировании ... ...
Глава 15. Показатели качества.......................................
15.1. Пример выбора программного пакета.............................
15.2. Анализ ПО чистой стоимости ...................................
15.3. Анализ по показателю качества.................................
15.4. Общие замечания об использовании анализа по взвешенной сумме для
выбора ТО и ПО..................................................
15.5 С писание процедуры выбора ЭВМ.................................
15.6. Проблемы использования оценочной функции ... . . .
15.7 Проблемы определения весов и рейтингов ....
15.8. Итоги.........................................................
15.9. Реальная эффективность системы как показатель качества
15.10. Свойства показателя РЭС......................................
15.11. Повторный анализ примера выбора СОС ,........................
15.12. Сравнение показателей взвешенной суммы и 'РЭС................
Глава 16. Цели в качестве ограничений
16.1. Пример СОС с отказами.........................................
16.2. Надежность и готовность системы.......................... . .
16.3. Оценка показателя качества.............................
16 4. Выражение целей в качестве ограничений............
16.5. Допустимые множества и линии уровня стоимость—доход .
16 6. Общий случай задачи выбора решений с ограничениями
16.7. Применение в инженерном программировании......................
16.8. Методы математической оптимизации.............................
16.9. Возможности и ограничения метод ж математической оптимизации
Глава 17. Системный анализ и оптимизация с ограничениями
17.1. Пример ... ... . ....................
17.2. Общее обсуждение .... . . .
Глава 18. Совместное представление разнородных качественных целей
18 1. Пример разработки операционной системы для СОС (вариант В) .
18 2. Сравнение собственной и заказной разработок . ......
18.3. Методы предс" явления.................................... . .
18.4. Общее обсуждение качественных показателей ... . . .
180
181
182
183
184
184
184
186
187
187
188
188
188
189
189
190
?90
191
191
191
192
192
193
194
196
197
200
203
205
206
206
207
208
210
210
2Ю
211
212
212
214
215
215
219
220
220
223
224
225
225
226
229
508
18.5. Методы представления качественных показателей ...
18.6. Методы совместного представления количественных и качественных
показателей .......................................................
18.7. Некоторые предостережения при представлении и интерпретации раз-
нообразных данных..............................................
ЧАСТЬ ЗВ. УЧЕТ НЕОПРЕДЕЛЕННОСТИ. РИСКА И ВАЖНОСТИ ИН-
ФОРМАЦИИ ......................................................
Глава 19. Учет неопределенности—анализ риска.......................
19.1. Пример выбора метода разработки операционной системы .
19.2. Правила выбора решений при полной неопределенности ....
19.3. Экспертные оценки вероятности............. ..................
19.4. Общее обсуждение правил выбора при полной неопределенности .
19.5. Значение информации......................................
19.6. Использование экспертных оценок вероятностей.............
19.7. Функции полезности ......................................
19.8. Предпосылки для инженерного программирования.................
Глава 20. Теория статистических решений и ценность информации .
20.1. Метод прототипа . ....................................
20.2. Математическое ожидание дохода при полной информации
20.3. Учет неполной информации . . .. ....................
20.4. Пример .... ................................
'20.5. Формула Байеса..............................................
20.6. Максимизация ожидаемой чистой стоимости при разработке прототипа
20.7. Формальное определение МО дохода от полной информации .
20.8. МО дохода от неполной информации . . . .
20.9. Процедура определения дохода от информации...................
20.10. Применение процедуры определения дохода от информации в инже-
нерном программировании............................................
20.11. Руководство по процедуре определения дохода от информации .
20.12 Ошибки, обнаруживаемые методом определения дохода от информа-
ции ...............................................................
20.13. Краткое заключение .........................................
ЧАСТЬ 4. ИСКУССТВО ОЦЕНИВАНИЯ стоимости по ..... .
ЧАСТЬ 4А. МЕТОДЫ И ПРОЦЕДУРЫ ОЦЕНИВАНИЯ СТОИМОСТИ ПО . .
Глава 21. Семь основных шагов оценивания стоимости ПО
21.1. Шаг 1: Формулировка целей....................................
21.2. Шаг 2: Планирование требуемых данных и ресурсов..............
21.3. Шаг 3: Уточнение требований к ПО .... . .
21.4. Шаг 4: Возможно более полная проработка деталей..............
21.5. Шаг 5: Использование нескольких независимых методов и средств
21.6. Шаг 6: Сравнение и взаимное уточнение оценок.................
21.7. Шаг 7: Плановый учет............................... .
Глава 22. Альтернативные методы оценивания стоимости ПО
22.1. Алгоритмические модели.......................................
22.2. Экспертные оценки..................... .
22.3. Метод аналогий...............................................
22.4. Оценка по Паркинсону .... ...............
22.5. Оценивание методом конкурентных цен ...
22.6. Оценивание методом сверху — вниз ... . .
22.7. Оценивание методом снизу—вверх ... .................
22.8. Краткое сравнение методов..................................
ЧАСТЬ 4Б. ДЕТАЛЬНАЯ КОМОСТ.................... ..................
Глава 23. Краткое описание и принципы работы детальной КОМОСТ
23.1 Введение................................. ..................
23.2. Форма иерархического оценивания ПО.........................
230
232
235
236
236
236
237
240
240
241
241
241
243
243
243
244
245
245
246
247
248
249
250
251
251
252
253
255
255
256
256
260
262
263
270
271
273
275
276
279
281
282
283
283
284
287
288
290
290
294
509
23.3. Процедуры заполнения ФИСПО....................................
23.4. Информационная система студенческой занятости. Пример использо-
вания детальной КОМОСТ..............................................
23 5. Вычисление скорректированных сроков разработки..............
23.6. Обсуждение....................................................
Глава 24. Атрибуты программного изделия как стоимостные факторы
детальной КОМОСТ...............................................
24.1. Требуемая надежность программного обеспечения (ТНПО)
24.2. Размер базы данных (РБД)......................................
24.3. Сложность программного изделия (СИЗ) *........................
24.4. Темы для дальнейших исследований . ....................
Глава 25. Атрибуты ЭВМ как стоимостные факторы детальной КОМОСТ
25.1. Ограничение по быстродействию (ОБД)...........................
25 2. Ограничение по оперативной памяти (ОП)......................
25.3 Изменяемость виртуальной 1 < ь инн (ИВМ).......................
25.4. Цикл обращения к ЭВМ (ЦО)
25.5. Темы для дальнейших исследований..............................
Глава 26. Атрибуты исполнителей как стоимостные фактор” детальной
КОМОСТ..............................................................
26.1 Квалификация аналитиков (КА)............................
26.2. Опыт работы в данной прикладной области (ОРП).................
26.3. Квалификация программистов (КП)...............................
26.4. Опыт работы с виртуальной машиной (ОРБМ)......................
26.5. Опыт работы с языком програм жирования (ОРЯП).................
266. Общее обсуждение атрибутов исполнителей........................
Глава 27. Атрибуты проекта как стоимостные факторы де-альной
КОМОСТ....................... .................. ...
27.1. Практика современного программирования (ПСП) .
27.2. Испотьзование инструментальных средств (ИИС) .
27.3. Ограничение сроков разработки (ОСР)...........................
27 4. ~еыы для дальнейших исследований
Глава 28. Факторы, не учитываемые в КОМОСТ..........................
28 1. Тип программного обеспечения........................
28 2. Уровень языка программирования
28.3 Другие характеристики программ: сложность, сущность, спецификации
28 4. Изменяемость требований.......................................
28.5. Сохраняемость штата разработчиков .... ....
28.6. Качество управления................. .........................
28 7. Качество взаимодействия с заказчиком..........................
28 8. Объем документации . ....... . .
28 9. Конфигурация техническо-о обеспечения . . .............
28 10. Ограничения, связанные с секретностью и безопасностью ...
Глава 29. Оценивание КОМССТ.........................................
29.1. Введение............... ......................................
29.2. База данных КОМОСТ
29.3. Сопоставление оценок затрат на разработку с фактическими данными
29 4. Сопоставление оценок сроков разработки с фактическими данными
29.5. Сопоставление оценок распределения затрат по фазам с ф актически
мн данными.............................................. . .
29.6. Сопоставление оценок распределения затрат по работам с фактически-
ми данными..........................................................
29.7. Другие модели оценивания стоимости ПО.........................
29.8. Оценивание КОМОСТ по критериям................................
29 9. Настройка КОМОСТ перед внедрением ........
29.10. Темы для дальнейших исследований.............................
295
299
,303
304
310
310
324
328
332
333
333
341
343
347
350
351
351
357
358
361
364
365
370
370
377
384
390
ЗСО
391
393
395
398
399
401
402
403
403
404
405
405
406
411
413
414
416
419
424
427
433
510
ЧАСТЬ 4В. ОЦЕНИВАНИЕ СТОИМОСТИ И УПРАВЛЕНИЕ ЖИЗНЕННЫМ
ЦИКЛОМ ПО ....................................... •
Глава 30. Оценивание стоимости сопровождения ПО....................
30.1. Введение........................................ •
30.2. Модель сопровождения ПО . . ....................
30 3. Сравнение с фактическими данными.......................
30.4 Другие модели оценивания стоимости сопровождения .....
30.5. Общая характеристика сопровождения ПО .
30.6. Данные по сопровождению программных проектов.................
Глава 31. Оценивание стоимости жизненного цикла ПО.................
31.1. Введение.....................................................
31.2. Соотношения для оценивания стоимости переноса ПО . . . .
31.3. Сравнение оценок стоимости переноса с фактическими затратами .
31.4. Оценивание стоимости опытного внедрения (поставки) ПО и обучения
31.5. Оценивание стоимости ЭВМ в разработке ПО.....................
31.6. Объем документации при разработке ПО ................
31.7. Другие компоненты стоимости ЖЦПО....................... . .
31.8. Темы для дальнейших исследований.............................
Глава 32. Планирование программного проекта и управление им
32.1. Введение.....................................................
32.2. Основы планирования и управления программным проектом
32.3. Методы планирования сроков выполнения проекта................
32.4. Сборник единиц разработки — средство детального планирования и
управления разработкой ПО..........................................
32.5. Сопоставление расходов на контроль и развитие проекта. Система
приведенной стоимости ................................ .
Глава 33. Повышение производительности разработки ПО ....
Список литературы .... ................................
Список книг, переведенных на русский язык . .............
433
434
434
434
437
437
441
447
448
448
448
451
453
454
459
463
464
464
464
466
468
477
481
486
491
505