Программное обеспечение и его разработка
Шрифт:
Два класса программного обеспечения:
1. Программное обеспечение проекта.
2. Программное обеспечение как продукция.
а. Программное обеспечение как продукт.
б. Аппаратура с видоизменяемым, гибким программным обеспечением.
в. Аппаратура, сопровождаемая некоторым программным обеспечением.
Дочитав до этого места, некоторые могут воскликнуть: «Конечно, все это очевидно!». Хорошо бы, чтобы это было так. Мне постоянно встречаются люди, совершенно не различающие все эти классы, типы и т. п. Различать же их полезно как при разговорах о программном обеспечении, так и при управлении его разработкой.
Теперь
Жизнь программ состоит из трех фаз:
1. Разработка.
2. Использование.
3. Продолжающаяся разработка (или сопровождение).
Самая трудная фаза — первая, разработка, поэтому на нее приходится тратить больше всего времени. Однако в больших программах стоимость продолжающейся разработки часто (но не всегда) превышает половину суммарных затрат на всю жизнь данной программы.
На фазе использования мы обычно бываем вознаграждены за потраченные усилия, и, если мы правильно провели разработку, использование программного обеспечения пройдет спокойно и гармонично Обратите внимание на то, что фаза продолжающейся разработки проходит параллельно фазе использования. Обратите внимание также и на то, что мы избегаем использовать термин «техническое обслуживание». Для обозначения этой фазы в англоязычных странах в литературе часто используется неправильный термин «maintenance», обозначающий «обслуживание (ремонт)». Обслуживать программное обеспечение не нужно, поскольку никаких неполадок в нем быть не может, а техническое обслуживание и ремонт предполагают наличие неполадок и отказов. Правильно написанные команды не могут вдруг сами собой стать неправильными, как может порваться, отпаяться или замкнуться проводок. Команды не изнашиваются.
Необходимость продолжающейся разработки объясняется двумя причинами. Во-первых, в большой программе всегда имеется некоторое количество ошибок, которые не выявляются при тестировании. В гл.5, в разделе, посвященном тестированию, мы покажем, почему это происходит. Во-вторых, система должна развиваться. Вводится, скажем, новый налог, и приходится изменять программы составления платежных ведомостей.
В слове «обслуживание» есть что-то унизительное. Заниматься обслуживанием чего-то менее престижно, чем разработкой, и многие не чувствуют удовлетворения от этой работы. В то же время в деле программного обеспечения эта сторона требует к себе даже большего уважения, чем первоначальная разработка.
Разработчики, продолжающие следить за системой (а не ремонтировать ее), должны не только подключать новые функции и исправлять хитрые и коварные ошибки, которые ускользнули от внимания группы, начинавшей разработку. Они, кроме того, обычно вынуждены проводить подлинное расследование методов проектирования, которые редко бывают достаточно ясно документированы группой разработчиков.
Причиной специального выделения фазы использования является тот факт, что со многими большими системами постоянно взаимодействует множество людей. Система
В гл.5 мы увидим, что каждой программе присущи 12 различных характеристик. Некоторые из них относятся к использованию, некоторые к разработке, другие же к продолжающейся разработке.
Казалось бы, применяемая нами для обозначения фазы использования жизненного цикла программы терминология не должна порождать никаких дополнительных проблем, но это не так. Некоторые люди называют эту фазу так, а другие иначе.
Некоторые называют эту фазу «операционной» или «эксплуатационной» и говорят об «эксплуатации программного обеспечения». Обычными являются термины «фаза выполнения» или «время выполнения», так же как и термины «рабочая фаза» или «время работы» (рис. 4.2).
Все три фазы можно наблюдать на одной и той же вычислительной машине одновременно. В одной области памяти находится и выполняется программа составления платежных ведомостей — это использование. В другой области памяти работает диалоговый транслятор — идет какая-то разработка. В третьей области группа сопровождения производит какую-нибудь «автоматическую перестройку».
Все это только вносит путаницу! Чтобы добраться до истинного смысла, мы должны осознать, что рассматриваем жизненный цикл программы, а не вычислительной установки! В связи с этим для определения этой фазы совершенно неважно, что кроме нашей программы выполняется одновременно на той же машине.
Для аналогии рассмотрим вопрос разработки молотка, жизненный цикл которого показан на рис. 4.3. В «жизни» молотка отсутствует фаза ремонта. Если он ломается, мы просто берем новый. Отсюда следует, что при изготовлении молотка мы должны учитывать только легкость и простоту использования.
Если же речь заходит о велосипеде, мы сталкиваемся с тем, что в жизненном цикле возникает фаза сопровождения, или «регулировки». Из-за износа нам придется тратить усилия на ремонт, чтобы велосипед снова мог ездить (см. рис. 4.4).
При рассмотрении жизненного цикла административного здания мы сталкиваемся с тем, что нам приходится не только заниматься ремонтом при каких-то неисправностях, но также и капитальной перестройкой, если организация, занимающая это здание, начинает расти или сокращаться и т. п.