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

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

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

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

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

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

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

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

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

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

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

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

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

258 Глава 12

^peдвapu.meльнь^e

замечания о процессе разработки программ

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

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

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