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

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

Ограничения

• Не детализирует процессы жизненного цикла в разрезе методов и процедур.

• Не устанавливает требований к документации.

• Не предписывает четких и однозначных схем построения жизненного цикла ПО.

• Не предписывает использование конкретной модели жизненного цикла, методологии, методов, моделей или технических приемов.

Каждая организация сама несет ответственность за выбор!

ГОСТ 34.601–90

Стандарт предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС:

a. Обследование объекта и обоснование необходимости создания АС;

b. Формирование требований пользователя к АС;

c. Оформление отчета о выполнении работ и заявки на разработку АС.

2. Разработка концепции АС:

a. Изучение объекта;

b. Проведение необходимых научно-исследовательских работ;

c. Разработка вариантов концепции АС и выбор варианта, удовлетворяющего требованиям пользователей;

d. Оформление отчета о проделанной работе.

3. Техническое задание:

a. Разработка и утверждение технического задания на создание АС.

4. Эскизный проект:

a. Разработка предварительных проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части.

5. Технический проект:

a. Разработка проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части;

c. Разработка и оформление документации на поставку комплектующих изделий;

d. Разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация:

a. Разработка рабочей документации на АС и ее части;

b. Разработка и адаптация программ.

7. Ввод в действие:

a. Подготовка объекта автоматизации;

b. Подготовка персонала;

c. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

d. Строительно-монтажные работы;

e. Пусконаладочные работы;

f. Проведение предварительных испытаний;

g. Проведение опытной эксплуатации;

h. Проведение приемочных испытаний.

8. Тестирование АС.

9. Сопровождение АС:

a. Выполнение работ в соответствии с гарантийными обязательствами;

b. Послегарантийное обслуживание.

Эскизный, технический проекты и рабочая документация – это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Модели разработки ПО

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

Классические модели разработки

Модель кодирования и устранения ошибок

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

1. Постановка задачи.

2. Создание программы.

3. Тестирование.

4. Анализ результатов тестирования и возможный переход к шагу 1.

Эта модель совсем не актуальна для профессиональной разработки ПО. По таким алгоритмам программисты работали 50–60 лет назад. Излишняя простота в этом случае не позволяет конкурировать с другими моделями.

Каскадная модель или Waterfall

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

В конце каждого этапа создается документация, которая служит входными данными для следующего этапа.

1. Сбор требований. Собираются требования к продукту, который надо разработать (определяем требования заказчика).

2. Анализ требований. Требования анализируются, детализируются, уточняются, обсуждаются, документируются (формируем требования к ПО).

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

4. Разработка. Реализация.

5. Тестирование. Проверка.

6. Внедрение, поддержка. Вывод в промышленную эксплуатацию и перевод на поддержку.

Когда можно использовать каскадную модель:

• для средних и больших проектов, в которых задействованы десятки программистов и несколько разных команд проекта;

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

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

Любая стройка – это пример использования «Водопада» (кейс – проект – стройка – приемка). Также в качестве примера подходит автомобильный конвейер.

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

Поэтому появились расширения модели: каскадная с обратной связью и каскадная с промежуточным контролем.

Каскадная модель с обратной связью

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

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

Каскадная модель с промежуточным контролем

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

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

Модель обладает следующими характеристиками взаимодействия этапов:

• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);

• каждый этап имеет обратную связь с предыдущими;

• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;

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

• результат появляется только в конце разработки, как и в модели «Водопад».

Инкрементная (инкрементальная) модель разработки

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

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

Мы получаем несколько циклов разработки – своеобразный «мультиводопад». Каждый цикл делится на модули, а каждый модуль – на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

Когда можно использовать инкрементную модель:

• для проектов, в которых точное техническое задание прописано уже на старте, а продукт должен быстро выйти на рынок.

Итеративная модель разработки

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

В этом случае создание начинается с реализации части функционала и становится базой для определения дальнейших требований, иными словами, мы получаем так называемый минимально жизнеспособный продукт (Minimum Viable Product). Этот процесс повторяется снова и снова. Версия может быть неидеальной, главное, чтобы она работала. Понимая конечную цель, мы стремимся идти к ней так, чтобы каждый шаг был результативным, а каждая версия – работоспособной.

Когда можно использовать итеративную модель:

• когда важен анализ рисков и затрат;

• в крупных долгосрочных проектах с отсутствием четких требований или вероятностью их динамического изменения;

• при разработке новой линейки продуктов.

На рисунке показана итерационная «разработка» Моны Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй появляются цвета, в третьей добавляются детали и насыщенность, и процесс завершается. В инкрементной же модели функционал продукта наращивается по кусочкам, и продукт составляется из частей. В отличие от итерационной модели, здесь каждый кусочек – целостный элемент.

V-модель разработки

Еще она называется Verification and Validation model – модель верификации и валидации. Это усовершенствованная каскадная модель, в которой заказчик и команда программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. V-модель разработки унаследовала структуру «шаг за шагом» от каскадной модели.

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

Спиральная модель

Ее начали использовать в 1988 году. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее включен анализ рисков и предусмотрена разработка проекта посредством прототипирования.

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

Главные фазы:

1. определение целей, альтернатив, ограничений;

2. анализ, определение и разрешение рисков;

3. фаза разработки и тестирования;

4. планирование новой итерации.