Разработка программных средств

Этапы разработки ПО Рассмотрим на основании ГОСТа 19.102-77. ЕСПД

Табл. 1.     «Стадии разработки, этапы и содержание работ»

Стадии разработки	Этап работы	Содержание работы
Техническое задание (тз)	Обоснование необходимости разработки программы	Ø    Постановка задачи Ø    Сбор исходных материалов Ø    Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Ø    Обоснование необходимости проведения научно-исследовательских работ.
	Научно-исследовательские работы	Ø    Определение структуры входных и выходных данных. Ø    Предварительный выбор методов решения задач. Ø    Обоснование целесообразности применения ранее разработанных программ. Ø    Определение требований к техническим средствам. Ø    Обоснование принципиальной возможности решения поставленной задачи.
	Разработка и утверждение тз	Ø    Определение требований к программе. Ø    Разработка технико-экономического обоснования разработки программы. Ø    Определение стадий, этапов и сроков разработки программы и документации на нее. Ø    Выбор языков программирования. Ø    Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Ø    Согласование и утверждение технического задания.
Эскизный проект	Разработка эскизного проекта	Ø    Предварительная разработка структуры входных и выходных данных. Ø    Уточнение методов решения задачи. Ø    Разработка общего описания алгоритма решения задачи. Ø    Разработка технико-экономического обоснования.
	Утверждение эскизного проекта	Ø    Разработка пояснительной записки. Ø    Согласование и утверждение эскизного проекта
Технический проект	Разработка технического проекта	Ø    Уточнение структуры входных и выходных данных. Ø    Разработка алгоритма решения задачи. Ø    Определение формы представления входных и выходных данных. Ø    Определение семантики и синтаксиса языка. Ø    Разработка структуры программы. Ø    Окончательное определение конфигурации технических средств.
	Утверждение технического проекта	Ø    Разработка плана мероприятий по разработке и внедрению программ. Ø    Разработка пояснительной записки. Ø    Согласование и утверждение технического проекта.
Рабочий проект	Разработка программы	Программирование и отладка программы
	Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
	Испытание программы	Ø    Разработка, согласование и утверждение программы и методики испытаний. Ø    Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Ø    Корректировка программы и программной документации по результатам испытаний.
Внедрение	Подготовка и передача программы	Ø    Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Ø    Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Ø    Передача программы в фонд алгоритмов и программ.

Жизненный цикл программного обеспечения.

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

Модели на основе инженерного подхода

Модель «кодирование–устранение ошибок».

Она описывается следующим образом:

1) поставить задачу;

2) выполнять ее до успешного завершения либо отмены;

3) проверить результат;

4) повторить при необходимости с 1-го шага.

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

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

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

Рис. 1. каскадная модель предусматривала возможность возвращения к предыдущим этапам

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

V-образная модель.

Была предложена именно для того, чтобы устранить недостатки каскадной модели, а название – V-образная, или шарнирная – появилось из-за ее специфического графического представления (рис. 2).

Рис. 2. V-образная модель позволяет гораздо лучше контролировать результат на предмет его соответствия ожиданиям, поскольку сфокусирована на тестировании

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

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

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