Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
36
Добавлен:
23.03.2015
Размер:
933.38 Кб
Скачать

12. Предварительные замечания о процессе разработки программ

12.1. Жизненный цикл математического обеспечения

До сих пор мы рассматривали спецификацию, реализацию корректность программных модулей. В следующих трех глава обсуждаются вопросы, относящиеся к программам как целостны единицам, а также вопросы, касающиеся разработки программ

Разработка программ обычно разделяется на несколько этапов анализ требований, проектирование, реализация и тестирований производство, модификация и сопровождение. Обычно процёс^ начинается с того, что имеется некто, кого мы будем называв заказчиком, кто хочет, чтобы программа выполняла определенный функции. Иногда эти функции хорошо понимаемы и детально и: точно описаны заранее, однако такое случается весьма редко.; В большинстве случаев заказчики недостаточно хорошо понимают,^ что им нужно от программы. Если даже требуемая функция^ хорошо понимаема, она, вероятно, описана недостаточно точно, чтобы служить базисом для написания программы. Назначение этапа анализа требований как раз и заключается в том, чтобы' изучить требования заказчика и создатьспецификацию требова-, нийдля программы, которая будет в дальнейшем их выполнять.

Спецификация, которая составляется на основании анализа требований заказчика, является исходным пунктом в стадии про­ектирования. На этой стадии разрабатывается удовлетворяющая а данную спецификацию модульная декомпозиция программы. На следующем этапе создаются отдельные модули, после чего про­исходит их тестирование и проверка на соответствие требуемым ' функциям. Как уже говорилость в гл. 9,имеются два вида тестов: : тесты, проверяющие отдельные программные единицы, и инге-гральные тесты, проверяющие все модули вместе.

В лучшем случае интегральное тестирование может показать, что все модули, собранные вместе, удовлетворяют спецификации в ее интерпретации разработчиком. Разработчик может непра­вильно понять спецификацию или забыть выполнить некоторые проверки, или же заказчик в своих требованиях может исходить из какого-либо другого критерия. Такая ситуация, как пра­вило, предполагает наличиеприемочных тестов.Приемочные тесты дают оценку поведения программы, не зависящую от ее внутренней структуры, и обычно составляются организацией, не

1ринимающей участия в разработке и реализации программы. Эни должны включать в себя контрольные тесты, выполняющиеся условиях, приближенных к реальным, а также гесты, получен­ие непосредственно из требований спецификации.

После прохождения программой приемочных тестов ее разра-ютка выходит на стадию производства и становится продуктом, доступным потребителю. Полезное время жизни программы на­чинается именно с этого момента, однако и на этом этапе про­грамма может изменяться. Во-первых, в ней наверняка имеются (незамеченные ошибки, которые должны быть исправлены на про­изводственной стадии. Исправление таких ошибок называется^сопротивлением программы.Во-вторых, требования заказчика 1склонны изменяться. Реакция на эти изменения требует модифи­кации программы.

1Ошибки представляют собой проблему, не исчезающую ни •на одной из стадий разработки. Ошибки, внесенные на ранних ^.стадиях работы, труднее исправлять впоследствии. Ошибка, сделанная на этапе анализа требований к программе, может при­вести к полностью бесполезной программе, поскольку последняя не будет отвечать требованиям заказчика. Если это не обнару­живается вплоть до выполнения приемочных тестов, то приходится выполнять гигантский объем работ по проектированию на этапе проектирования,

^заново

реализации. Ошибка, допущенная

•может привести к появлению неиспользуемых модулей и к неудаче при создании действительно необходимых. В противоположность этому ошибка в модуле, допущенная на стадии реализации, ^относится только к этому модулю и может быть исправлена про­петой его переделкой.

^ Чем раньше будет обнаружена ошибка, тем менее серьезны сбудут последствия. Ошибка, допущенная на стадии анализа тре­бований и обнаруженная на этой же стадии, может потребовать

•Только пересмотра некоторых частей в требованиях спецификации,

Неотметая при этом всю проделанную работу по проектированию ^программы. Аналогично, если ошибка в проектировании обнару-^Жена перед началом реализации программы, то может оказаться 1необходимым пересмотреть часть относящихся к реализации реше­ний, не отбрасывая при этом результатов работы по реализации и тестированию других модулей. Очевидно, что методы и спо-1.собы обнаружения ошибок должны быть ориентированы в первую 'очередь на стадии анализа требований и проектирования, а не Только на стадию реализации. ^ Важно еще раз отметить, что гарантий корректности не су-

•'Шествует, Верификация программы может показать, что про­грамма соответствует своей спецификации, однако на сегодняш-"ний день этого недостаточно, так как ошибки могут быть обна-[Ружены и гораздо позже, в процессе разработки программы.

9 Дисков Б., Гатэг Дж.

Соседние файлы в папке Б. Лисков