|
37 Достижение последовательных подцелей тесно связано с такими подцелями, как верификация и подтверждение, а также управление конфигурацией, которые должны быть достигнуты на каждой фазе ЖЦПО. Требование простого последовательного достижения целей является удобным упрощением. Существуют же ситуации, в которых экономически целесообразно изменить последовательность достижения целей, например при изготовлении прототипа, в пошаговой разработке и т.д. Обоснование каскадной модели, ориентированной на последовательное достижение целей, базируется на двух главных предпосылках: 1. Для получения качественного программного изделия необходимо в любом случае осуществить все подцели на каждом этапе. 2. Любое другое упорядочивание подцелей приводит к созданию менее качественного программного изделия. Относительно первого условия отметим, что несомненно, осуществление подцели кодируемости и всех последующих подцелей (кроме снимаемости) необходимо для получения любого функционирующего изделия. Основной вопрос состоит в том, необходимы ли предыдущие подцели (осуществимость, полнота и непротиворечивость требований, проектируемость изделия и детальная проектируемость). В случае многих небольших и простых программных изделий можно получить приемлемый результат, уделяя относительно мало внимания ранним подцелям, поскольку разработчик и так четко понимает запросы пользователя и все последствия решения легко предсказуемы. Однако подобный неформальный подход часто ведет к весьма неприемлемым результатам, которые обычно можно предвидеть и избежать при тщательном выполнении более ранних подцелей. В крупных и сложных программных проектах, связанных с управлением КА, недостаточное внимание к более ранним подцелям почти всегда приводило к серьезным недостаткам программного изделия и процесса его разработки Это иллюстрируется многочисленными примерами в области аэрокосмической и ракетной техники, например, в открытой печати США приводится информация о том, что в двух больших оперативных системах управления из-за их несоответствия требованиям пользователя объем доработок составил 67% и 95% соответственно и т.д. Анализ этих и других аналогичных случаев приводит к выводу, что рассмотрение ранних подцелей существенно для успешной разработки программного изделия. Кроме этого, более поздние исправления связаны с гораздо более формальным процессом утверждения и контроля изменений, требуют значительного объема работ по подтверждению правильности сделанных изменений В результате совместного действия этих факторов исправление ошибки на фазе сопровождения большого программного проекта обходится |
зей, характеристик, основных алгоритмов и определение условий работы каждого программного компонента (подпрограммы, состоящей менее чем из 100 исходных команд). кодируемость — получение полного верифицированного набора компонентов программы. Достижение последовательных подцелей тесно связано с такими подцелями, как верификация и подтверждение, а также управление конфигурацией, которые должны быть достигнуты на каждой фазе ЖЦПО. Требование простого последовательного достижения целей является удобным упрощением. Существуют же ситуации, в которых экономически целесообразно изменить последовательность достижения целей, например при изготовлении прототипа, в пошаговой разработке и т.д. Обоснование каскадной модели, ориентированной на последовательное достижение целей, базируется на двух главных предпосылках: 1. Для получения качественного программного изделия необходимо в любом случае осуществить все подцели на каждом этапе. 2. Любое другое упорядочивание подцелей приводит к созданию менее качественного программного изделия. Относительно первого условия отметим, что несомненно, осуществление подцели кодируемости и всех последующих подцелей (кроме снимаемости) необходимо для получения любого функционирующего изделия. Основной вопрос состоит в том, необходимы ли предыдущие подцели (осуществимость, полнота и непротиворечивость требований, проектируемость изделия и детальная проектируемость), В случае многих небольших и простых программных изделий можно получить приемлемый результат, уделяя относительно мало внимания ранним подцелям, поскольку разработчик pi так четко понимает запросы пользователя и все последствия решения легко предсказуемы. Однако подобный неформальный подход часто ведет к весьма неприемлемым результатам, которые обычно можно предвидеть и избежать при тщательном выполнении более ранних подцелей. В крупных и сложных программных проектах, связанных с управлением КА, недостаточное внимание к более ранним подцелям почти всегда приводило к серьезным недостаткам программного изделия и процесса его разработки. Это иллюстрируется многочисленными примерами в области аэрокосмической и ракетной техники, например,в открытой печати США приводится информация о том, что в двух больших опера27 тивных системах управления из-за их несоответствия требованиям пользователя объем доработок составил 67% и 95% соответственно [34] и т.д. Анализ этих и других аналогичных случаев [35-37] приводит к выводу, что рассмотрение ранних подцелей существенно для успешной разработки программного изделия. Обоснование второй предпосылки о последовательном достижении под целей процесса разработки следует в основном из данных, приведенных в [44], подытоживающих современный опыт разработки больших проектов, и результаты исследований (для нескольких проектов [45]) зависимости относительной стоимости исправления ошибки (или внесения какоголибо изменения) в ПО от фазы, в которой производятся эти исправления или изменения. Согласно накопленному опыту, если ошибка в требованиях обнаруживается и исправляется на фазе планирования и анализа требований, то ее исправление сводится к сравнительно простым изменениям спецификаций требований. Если же эта ошибка не исправлена до фазы сопровождения, то ее исправление затрагивает больший объем спецификаций, кодов, руководств для пользователя и по сопровождению, а также учебных материалов. Кроме этого, более поздние исправления связаны с гораздо более формальным процессом утверждения и контроля изменений, требуют значительного объема работ по подтверждению правильности сделанных изменений. В результате совместного действия этих факторов исправление ошибки на фазе сопровождения большого программного проекта обходится обычно в 100 раз дороже, чем исправление той же ошибки на фазе анализа требований. Для небольших неформальных проектов обосновать предпосылку 2 сложнее, чем для крупных более формализованных проектов. Главные причины меньшего роста стоимости исправления заключались в следующем: 1) уменьшение размера программы приводит к уменьшению объема исправлений на более поздних стадиях; 2) уменьшение формализованности проекта допускало более простые изменения и исправления, чем для более формализованных проектов. Хотя эффект для небольших проектов менее резко выражен, четырехкратный рост стоимости исправления от фазы анализа требований до фаз комплексирования и отладки говорит в пользу предпосылки 2. Такой рост существенно повышает важность заблаговременной спецификации 28 |