Валерий Комсков – Введение в профессию бизнес-аналитика. Отправная точка для приобретения опыта (страница 5)

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

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

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 лет назад. Излишняя простота в этом случае не позволяет конкурировать с другими моделями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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