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

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

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

Недостатки каскадной модели:

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

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

Усовершенствование каскадной модели ЖЦ шло по пути разработки стратегий проектирования последовательных версий:

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

2. Эволюционное проектирование: В начале процесса определены не все требования. Требования уточняются в результате испытания очередной версии системы.

3. Макетирование (прототипирование): Последовательность действий такая же, как при эволюционном проектировании, но на каждой итерации создаётся не полноценная версия системы, а её макет, позволяющий отработать некоторые технические решения, а главное, уточнить требования заказчика к следующей версии. Создание макетов требует значительно меньше времени, чем полноценной системы. Когда все требования уточнены, на основе последнего макета и уже имеющихся технических наработок создаётся окончательная версия системы.

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

В настоящее время наибольшее развитие в больших проектах получил так называемый Унифицированный процесс разработки систем (USDP), предложенный в 1998 году и основанный на рассмотренных выше трёх стратегиях и на Универсальном языке моделирования (UML), используемом для фиксации и анализа всех проектных спецификаций.

Методологии проектирования программ

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

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

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

Однако методология модульного программирования не давала ясных рекомендаций по структурной организации модулей и связей между ними. Это сделала методология структурного программирования, победившая в результате широких и острых дискуссий в 1970-е годы.

В узком смысле слова структурное программирование – это «программирование без goto», без оператора перехода, позволяющего передать управление из одной точки программы в любую другую (go to … – перейти к …). Этот оператор с неограниченными «полномочиями» присутствовал в языках программирования высокого уровня до 1970 года (до появления языка Паскаль). Он является наследником машинной команды перехода (в в языке машинного уровня Assembler этой команде соответствует оператор jump – прыжок). Методология структурного программирования требует вместо него использовать такие «структурные» операторы, как последовательность, операторы условного выбора типа if-then-else, операторы цикла while, do-while и for, а также процедуры/функции (с ограниченными операторами перехода continue, break и return). В отсутствие go to все эти операторы имеют одну точку входа и одну точку выхода – одно их важнейших требований структурного программирования.

В широком смысле структурное программирование требует единственности точек входа и выхода для любого модуля, а также ограничивает произвольный доступ к ячейкам памяти, требуя использовать только «структурированные» типы данных вроде массивов, записей, множеств (коллекций), ссылочных структур с их «штатными» способами доступа к элементам. Как мы видим, язык JavaScript (а также родственные ему языки Java, C#) полностью удовлетворяет этим требованиям структурного программирования. В то же время языки С и С++ содержат неограниченный goto и разрешают более свободный доступ к памяти (с целью большей эффективности программ), что сближает их с языками машинного уровня. Структурное программирование требует также избегать использования глобальных переменных, используя передачу данных между модулями только через их параметры, т.е. более контролируемым способом.

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

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

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

Дальнейшим развитием рассмотренных методологий программирования стало объектно-ориентированное программирование и проектирование. При этом подходе модулем может быть не только фрагмент кода или процедура, но и целый программный объект со своими свойствами и методами, используемыми для взаимодействия с другими модулями (модуль взаимодействует с объектом, обращаясь к его свойствам и методам). Как модульная и структурная методологии, объектно-ориентированная методология нашла выражение в объектно-ориентированных языках программирования, к которым, с некоторыми оговорками можно отнести и JavaScript (см. п. 20). Полностью эта методология программирования реализована в языках Java и C#. Методология объектно-ориентированного проектирования реализована в языке спецификаций UML (см. в этом п. выше).