Книга: Программное обеспечение и его разработка

Жизненный цикл программы

Жизнь программ состоит из трех фаз:

1. Разработка.

2. Использование.

3. Продолжающаяся разработка (или сопровождение).

Самая трудная фаза — первая, разработка, поэтому на нее приходится тратить больше всего времени. Однако в больших программах стоимость продолжающейся разработки часто (но не всегда) превышает половину суммарных затрат на всю жизнь данной программы.

На фазе использования мы обычно бываем вознаграждены за потраченные усилия, и, если мы правильно провели разработку, использование программного обеспечения пройдет спокойно и гармонично Обратите внимание на то, что фаза продолжающейся разработки проходит параллельно фазе использования. Обратите внимание также и на то, что мы избегаем использовать термин «техническое обслуживание». Для обозначения этой фазы в англоязычных странах в литературе часто используется неправильный термин «maintenance», обозначающий «обслуживание (ремонт)». Обслуживать программное обеспечение не нужно, поскольку никаких неполадок в нем быть не может, а техническое обслуживание и ремонт предполагают наличие неполадок и отказов. Правильно написанные команды не могут вдруг сами собой стать неправильными, как может порваться, отпаяться или замкнуться проводок. Команды не изнашиваются.

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

В слове «обслуживание» есть что-то унизительное. Заниматься обслуживанием чего-то менее престижно, чем разработкой, и многие не чувствуют удовлетворения от этой работы. В то же время в деле программного обеспечения эта сторона требует к себе даже большего уважения, чем первоначальная разработка.

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

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

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

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

Некоторые называют эту фазу «операционной» или «эксплуатационной» и говорят об «эксплуатации программного обеспечения». Обычными являются термины «фаза выполнения» или «время выполнения», так же как и термины «рабочая фаза» или «время работы» (рис. 4.2).

Все три фазы можно наблюдать на одной и той же вычислительной машине одновременно. В одной области памяти находится и выполняется программа составления платежных ведомостей — это использование. В другой области памяти работает диалоговый транслятор — идет какая-то разработка. В третьей области группа сопровождения производит какую-нибудь «автоматическую перестройку».

Все это только вносит путаницу! Чтобы добраться до истинного смысла, мы должны осознать, что рассматриваем жизненный цикл программы, а не вычислительной установки! В связи с этим для определения этой фазы совершенно неважно, что кроме нашей программы выполняется одновременно на той же машине.

Для аналогии рассмотрим вопрос разработки молотка, жизненный цикл которого показан на рис. 4.3. В «жизни» молотка отсутствует фаза ремонта. Если он ломается, мы просто берем новый. Отсюда следует, что при изготовлении молотка мы должны учитывать только легкость и простоту использования.

Если же речь заходит о велосипеде, мы сталкиваемся с тем, что в жизненном цикле возникает фаза сопровождения, или «регулировки». Из-за износа нам придется тратить усилия на ремонт, чтобы велосипед снова мог ездить (см. рис. 4.4).

При рассмотрении жизненного цикла административного здания мы сталкиваемся с тем, что нам приходится не только заниматься ремонтом при каких-то неисправностях, но также и капитальной перестройкой, если организация, занимающая это здание, начинает расти или сокращаться и т. п.

Мы должны ломать стены, строить новые, переделывать отопительную систему, менять энергосеть и т. д. (см. рис. 4.5).

В связи с этим, если мы предполагаем возможность каких-либо изменений в здании в будущем, то при исходном проектировании здания (и составлении проектных документов) должны позаботиться о том, чтобы текущий и капитальный ремонт проходил без затруднений.

Обратите внимание на то, что при переходе к программному обеспечению (рис. 4.6) мы меняем слова, стоящие на правой нижней линии схемы.

Вместо слова «ремонт» стоят слова «внесение изменений». Слово «строительство» также заменяется словом «разработка».

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

Рис. 4.8 показывает принципиальное отличие жизненного цикла аппаратуры от жизненного цикла программного обеспечения.

На этом рисунке показано, что в процессе разработки аппаратуры есть такие фазы, как фаза производства, фазы повышения технологичности и ремонтопригодности.

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

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

Другая причина того, что работы по облегчению будущего продолжения разработки зачастую не проводятся, заключается в том, что руководство различными фазами обычно проводится разными людьми. Рис. 4.9 показывает, что иногда руководство всеми тремя фазами находится в одних руках. Но это исключения.

Чаще же действует схема, изображенная на рис. 4.10. Имеются три ведущие группы, по каждой фазе своя. Руководители разработки мало заботятся о затратах на сопровождение и проблемах, возникающих на этой фазе.

При разном руководстве создаются условия для возникновения ошибок. Стрелки А на рис. 4.10 направлены в обе стороны, поскольку пользователи должны иметь возможность передавать свои требования разработчикам. Часто они лишены такой возможности.

Разработчики должны сформулировать, что именно может быть использовано в фазе использования и каким образом. Однако во многих случаях этого нельзя достичь без подробных инструкций для пользователей.

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

Смысл стрелки В вполне понятен и ясен, но она обычно игнорируется до тех пор, пока не случится какой-нибудь казус!

Оглавление книги