- •Глава II
- •12. Предварительные замечания о процессе разработки программ
- •12.1. Жизненный цикл математического обеспечения
- •12. Предварительные замечания о процессе разработки программ
- •12.1. Жизненный цикл математического обеспечения
- •12.2. Анализ требований
- •12.3. Пример задачи
- •13.1. Обзор процесса проектирования
- •13.2.1. Вводный раздел
- •13.2.2. Разделы абстракций
- •13.8. Абстракция строки
- •13.9. Обзор и обсуждение
- •14. Этап перехода от проектирования к реализации
- •14.1. Оценка проекта
- •14.1.1. Корректность и эффективность
- •14.1.2. Структура
- •15.2. Выбор подхода
12. Предварительные замечания о процессе разработки программ
12.1. Жизненный цикл математического обеспечения
До сих пор мы рассматривали спецификацию, реализацию корректность программных модулей. В следующих трех глава обсуждаются вопросы, относящиеся к программам как целостны единицам, а также вопросы, касающиеся разработки программ
Разработка программ обычно разделяется на несколько этапов анализ требований, проектирование, реализация и тестирований производство, модификация и сопровождение. Обычно процёс^ начинается с того, что имеется некто, кого мы будем называв заказчиком, кто хочет, чтобы программа выполняла определенный функции. Иногда эти функции хорошо понимаемы и детально и: точно описаны заранее, однако такое случается весьма редко.; В большинстве случаев заказчики недостаточно хорошо понимают,^ что им нужно от программы. Если даже требуемая функция^ хорошо понимаема, она, вероятно, описана недостаточно точно, чтобы служить базисом для написания программы. Назначение этапа анализа требований как раз и заключается в том, чтобы' изучить требования заказчика и создатьспецификацию требова-, нийдля программы, которая будет в дальнейшем их выполнять.
Спецификация, которая составляется на основании анализа требований заказчика, является исходным пунктом в стадии проектирования. На этой стадии разрабатывается удовлетворяющая а данную спецификацию модульная декомпозиция программы. На следующем этапе создаются отдельные модули, после чего происходит их тестирование и проверка на соответствие требуемым ' функциям. Как уже говорилость в гл. 9,имеются два вида тестов: : тесты, проверяющие отдельные программные единицы, и инге-гральные тесты, проверяющие все модули вместе.
В лучшем случае интегральное тестирование может показать, что все модули, собранные вместе, удовлетворяют спецификации в ее интерпретации разработчиком. Разработчик может неправильно понять спецификацию или забыть выполнить некоторые проверки, или же заказчик в своих требованиях может исходить из какого-либо другого критерия. Такая ситуация, как правило, предполагает наличиеприемочных тестов.Приемочные тесты дают оценку поведения программы, не зависящую от ее внутренней структуры, и обычно составляются организацией, не
1ринимающей участия в разработке и реализации программы. Эни должны включать в себя контрольные тесты, выполняющиеся условиях, приближенных к реальным, а также гесты, получение непосредственно из требований спецификации.
После прохождения программой приемочных тестов ее разра-ютка выходит на стадию производства и становится продуктом, доступным потребителю. Полезное время жизни программы начинается именно с этого момента, однако и на этом этапе программа может изменяться. Во-первых, в ней наверняка имеются (незамеченные ошибки, которые должны быть исправлены на производственной стадии. Исправление таких ошибок называется^сопротивлением программы.Во-вторых, требования заказчика 1склонны изменяться. Реакция на эти изменения требует модификации программы.
1Ошибки представляют собой проблему, не исчезающую ни •на одной из стадий разработки. Ошибки, внесенные на ранних ^.стадиях работы, труднее исправлять впоследствии. Ошибка, сделанная на этапе анализа требований к программе, может привести к полностью бесполезной программе, поскольку последняя не будет отвечать требованиям заказчика. Если это не обнаруживается вплоть до выполнения приемочных тестов, то приходится выполнять гигантский объем работ по проектированию на этапе проектирования,
^заново
"иреализации. Ошибка, допущенная
•может привести к появлению неиспользуемых модулей и к неудаче при создании действительно необходимых. В противоположность этому ошибка в модуле, допущенная на стадии реализации, ^относится только к этому модулю и может быть исправлена пропетой его переделкой.
^ Чем раньше будет обнаружена ошибка, тем менее серьезны сбудут последствия. Ошибка, допущенная на стадии анализа требований и обнаруженная на этой же стадии, может потребовать
•Только пересмотра некоторых частей в требованиях спецификации,
•Неотметая при этом всю проделанную работу по проектированию ^программы. Аналогично, если ошибка в проектировании обнару-^Жена перед началом реализации программы, то может оказаться 1необходимым пересмотреть часть относящихся к реализации решений, не отбрасывая при этом результатов работы по реализации и тестированию других модулей. Очевидно, что методы и спо-1.собы обнаружения ошибок должны быть ориентированы в первую 'очередь на стадии анализа требований и проектирования, а не Только на стадию реализации. ^ Важно еще раз отметить, что гарантий корректности не су-
•'Шествует, Верификация программы может показать, что программа соответствует своей спецификации, однако на сегодняш-"ний день этого недостаточно, так как ошибки могут быть обна-[Ружены и гораздо позже, в процессе разработки программы.
9 Дисков Б., Гатэг Дж.