Жизненный цикл программы
Итак, мы знаем, что программный продукт является результатом некоего производственного процесса. Этот процесс нужно спланировать, оценить ресурсы, для чего, в свою очередь, требуются более или менее точные спецификации, что же необходимо заказчику. Затем продукт надо спроектировать в виде системы, состоящей из многих компонентов, описать функции этих компонентов и их связи между собой, после чего компоненты нужно запрограммировать, автономно отладить, собрать вместе, провести комплексную отладку, подготовить документацию на систему, обучить пользователей, провести опытную эксплуатацию и организовать сопровождение системы на весь период ее эксплуатации.
Разумеется, это лишь приблизительная схема, которая может варьироваться в широких пределах, но, тем не менее, она дает представление о том, что такое "жизненный цикл программы" (ЖЦП) [4]. Почему "цикл"? Потому что редко разработка развивается столь прямолинейно, хотя одну из первых моделей ЖЦП действительно назвали "водопадная", подчеркивая тот факт, что к предыдущей фазе проектирования вернуться невозможно. Действуя по этой модели, коллектив последовательно разрабатывает проект – от исходной концепции до комплексного тестирования. Модель требует определить опорные точки, в которых будет оцениваться сделанное и решаться вопрос о том, можно ли двигаться дальше. Такой подход хорош для проектов, в которых требования легко формулируются с самого начала, но не годится для сложных, когда требования могут неоднократно меняться. Кроме того, водопадная модель вынуждает готовить огромную массу документации и требует единообразной процедуры оценки результатов на каждом этапе. Эти две особенности часто приводят к синдрому "аналитического паралича", напряженным отношениям между разработчиками, заказчиками и пользователями.
В реальной жизни, конечно же, чисто водопадная модель не применяется. Появляются новые требования заказчиков, изменяется аппаратура, находятся такие ошибки, которые невозможно исправить, не затронув результаты предыдущих фаз и т.д.
Развитие системы – это именно циклическое повторение практически всех фаз, постоянный возврат к предыдущим фазам. Если не принять специальных мер (что, собственно, и является предметом технологии программирования), процесс может стать бесконечным.
Одной из первых практически полезных моделей ЖЦП стала модель создания прототипов. С самого начала разработчики пытаются выделить основные, существенные требования заказчика и реализовать только их в виде работающего прототипа системы. Этот прототип демонстрируется заказчику. Часто бывает, что заказчик в ужасе кричит, что его неправильно поняли, он хотел совсем другого, зато теперь он хоть может внятно сформулировать свои требования, глядя на работу прототипа. Цикл разработки и показа прототипа повторяется несколько раз, пока заказчик не скажет: "Да, это, кажется, то, что мне нужно". Только после этого дорабатываются куски, выброшенные в начале разработки, подготавливается документация, короче, делаются многие вещи, на которые время было бы потрачено зря, если бы их делали для самого первого, неудачного прототипа.
Для небольших систем, особенно для тех, в которых велик процент интерактивных (взаимодействующих с пользователем) компонентов, такая модель работает, хотя каждый раз, когда я про нее рассказываю, мне вспоминается анекдот. Празднуется золотая свадьба. Набежали журналисты, спрашивают: "Как же так, все семьи разваливаются, а вы прожили пятьдесят лет?" Глава семьи отвечает: "Как только мы поженились, сразу договорились, что все важные жизненные проблемы решаю я, а жена не спорит, а остальные – решает жена, а я в них не лез. Так и прожили". Журналисты не унимаются: "А что такое – важные проблемы? Ну, например, назовите проблему, которую Вы решали в последнее время". Глава семьи отвечает: "Ну как же, как же, недельки две назад я долго размышлял, вернется Далай-Лама в Тибет или нет".
В этом анекдоте, как всегда, отображена вся правда жизни. На моей памяти много случаев, когда важные аспекты просто упускались при разработке прототипа, из-за чего позже все приходилось переделывать заново.
Некоторым обобщением модели создания прототипов является спиральная модель, в которой разработка приложения выглядит как серия последовательных итераций. На первых этапах уточняются спецификации продукта, на последующих — добавляются новые возможности и функции. Цель этой модели – по окончании каждой итерации осуществить заново оценку рисков продолжения работ. Программисты часто увлекаются технической сутью выполняемого проекта и не видят общей картины, особенно в части производственных затрат. Нам все кажется, что вот еще немного, еще чуть-чуть, и все проблемы будут решены, но "асфальтовая топь" (по выражению Ф. Брукса[5]) засасывает нас, не давая шансов достичь твердых осязаемых результатов. Один мой знакомый бизнесмен представил эту проблему так: "Вот ты затратил 100 000 долларов, но задачу пока не решил. Нужно сто раз подумать, что лучше — истратить еще столько же, чтобы успешно завершить проект, или через год снова оказаться перед тем же выбором, но тогда уже с риском потерять не 100 000, а 200 000 долларов?"
В силу своей итеративной природы спиральная модель допускает корректировки по ходу работы, что способствует улучшению продукта. При большом числе итераций разработка по этой модели нуждается в глубокой автоматизации всех процессов, иначе она становится неэффективной. На практике у заказчиков и пользователей иногда возникает ощущение нестабильности продукта, так как они не успевают уследить за слишком быстрыми изменениями в нем.
Один очень важный вывод мы можем сделать даже при таком начальном знакомстве с понятием ЖЦП. Собственно программирование не является единственным занятием коллектива, занятого промышленными разработками. Более того, оно не является даже главным, наиболее трудоемким делом. Многие исследования отдают на фазу программирования не более 15-20% времени, затраченного на разработку (сопровождение вообще бесконечно). Может быть, эти цифры заставят вас задуматься о важности и других аспектов образования – от умения найти и обосновать эффективный алгоритм до искусства владения родным языком, как устным, так и письменным.
