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