1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ
1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ
ГОСТ 19.102—77 регламентирует стадии и этапы программных разработок в течение всего жизненного цикла. Данный стандарт сформировался на основе анализа удачных и неудачных программных разработок и содержит основные рекомендации по проведению новых разработок. Стандарт уже пережил несколько технологий программирования. При этом, практически не изменяясь, он не являлся тормозом прогресса. Помимо наименований стадий и этапов проектирования ГОСТ 19.102—77 фактически содержит описание аналитико-синтетического эвроритма (алгоритма действий проектировщика с использованием методов анализа и синтеза) по временным этапам проекта.
Стадия проекта — одна из частей процесса создания программы, установленная нормативными документами и заканчивающаяся выпуском проектной документации, содержащей описание полной, в рамках заданных требований, модели программы на заданном для данной стадии уровне, или изготовлением программ. По достижении окончания стадии заказчик имеет возможность рассмотреть состояние проекта и принять решение по дальнейшему продолжению проектных работ. Например, заказчик может принять решение о продолжении работ по одному из согласованных вариантов.
Этап проекта — обычно часть стадии проекта, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей. Иногда выделяют этапы (фазы), которые охватывают несколько стадий. Например, этап проектирования программы включает стадии ЭП и ТП. Описания этапов регламентируют порядок выполнения отдельных видов работ для достижения стадии. Одни и те же виды работ могут продолжаться ряд этапов.
Стадии и этапы разработки программ по ГОСТ 19.102—77 на момент написания книги даны в приложении 1.
Программный документ «Техническое задание» (ТЗ) помимо основных требований к программному изделию содержит проект порядка взаимодействия заказчика и исполнителя по окончании конкретных этапов, т. е. перечень необходимых стадий и этапов и требований к их выполнению. ТЗ может сразу не устанавливать всех требований, которые могут быть уточнены и согласованы с заказчиком на последующих стадиях. Однако сама возможность изменения требований должна закладываться в ТЗ. В ТЗ определяется стратегия выполнения проекта.
«Эскизный проект» (ЭП), как правило, необходим для разработки нескольких альтернативных вариантов реализации будущего изделия и уточнения требований на основе их анализа. Степень проработки при этом должна быть достаточной лишь для достижения возможности сравнения вариантов.
«Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.
«Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.
Стадия «Внедрение» необходима для размножения программной документации в нужном количестве, обучения пользователей, помощи в освоении программы, сопровождения программы.
Научно-исследовательская работа (НИР) может быть самостоятельным этапом. НИР в основном проводится для выявления последних научных достижений с целью их использования в проекте, проверки реализуемости изделия и уточнения отдельных его характеристик.
В соответствии с ГОСТ 19.102—77 допускается исключать стадию ЭП, а в технически обоснованных случаях — стадии ЭП и ТП. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. Это позволяет разумно построить проект конкретной разработки (ход проекта также является объектом проектирования).
Пример 1. Разработка наукоемкой подпрограммы может вестись по следующим стадиям:
• ТЗ (ТЗ основное плюс ТЗ на отдельную НИР);
• ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);
• РП (около месяца);
• внедрение.
Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности — и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.
Пример 3. Требуется создать программные средства, автоматизирующие отдельные виды работ. Разработка такого проекта может проводиться по следующим стадиям:
• ТЗ;
• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;
• РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;
• внедрение.
Пример 4. Разработка таких информационных систем, как САПР или АСУ должна осуществляться в соответствии с соответствующими стандартами. ТП САПР или АСУ может содержать технические задания на разработку отдельных программных изделий. Как правило, такие ТЗ очень конкретны. На этапе РП САПР или АСУ сначала ведется контроль над разработкой программных изделий по всем необходимым для этого стадиям разработки программных изделий, затем проводится совместная проверка всех разработанных программ.
Обычно основанием для заключения договора между заказчиком и исполнителем служит гарантийное письмо заказчика. На основании гарантийного письма составляется договор. Обязательным приложением к договору является ТЗ.
Некоторые отечественные и зарубежные источники предлагают выделять следующие этапы:
1) анализ требований, предъявляемых к системе (системный анализ). (Обычно проводится на основе первичного исследования потоков информации при традиционном проведении работ с фиксацией видов этих работ и их последовательности.);
2) определение целей, достигаемых разрабатываемыми программами;
3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;
4) постановка задачи на разработку новых программ, определение внешних спецификаций (т. е. описаний входной и выходной информации, а иногда и их форм) и способов (алгоритмов, методов) обработки информации;
5) оценка достижения целей разработки (Далее, при необходимости, этапы 1–5 могут быть итеративно повторены до достижения удовлетворительного облика изделия с описанием выполняемых им функций и некоторой ясностью реализации его функционирования.);
6) рассмотрение возможных вариантов структурного построения программного изделия: или в виде нескольких программ, или нескольких частей одной программы; результатом этой работы являются варианты архитектуры программной системы и (или) требования к структуре отдельных программных компонент; организация файлов для межпрограммного обмена данными;
7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;
8) составление и проверка спецификаций модулей;
9) составление описаний логики модулей;
10) составление окончательного плана реализации программ;
11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;
12) комплексное тестирование;
13) разработка эксплуатационной документации на программу;
14) проведение приемо-сдаточных и других испытаний;
15) корректировка программ по результатам испытаний;
16) окончательная сдача программного изделия заказчику;
17) тиражирование программного изделия;
18) сопровождение программы.
Современные технологии проектирования программного обеспечения (ПО) направлены на частичную автоматизацию этапов и на совмещение их во времени с целью сокращения сроков выполнения проектов.
В литературных источниках применяются наименования этапов, которые охватывают ряд приведенных этапов и по времени охватывают даже несколько стадий. Например, этап разработки программы.