2 Этапы разработки программного обеспечения
Естественно, что отдельный человек не в состоянии полностью осмыслить и построить программное обеспечение большой системы. Для управления ходом разработки больших программных систем выделяются шесть этапов, составляющих цикл разработки (цикл жизни) программного обеспечения:
1) анализ требований, предъявляемых к системе;
2) определение спецификаций;
3) проектирование;
4) кодирование;
5) тестирование:
а) автономное;
б) комплексное;
6) эксплуатация и сопровождение.
Рис. 2.1 — Распределение затрат по этапам разработки
На диаграмме (рис. 2.1) показано приблизительное распределение затрат на реализацию отдельных этапов разработки.
Рассмотрим определение каждого из этих этапов.
2.1 Анализ требований, предъявляемых к системе
На первом этапе, часто неоправданно опускаемом, определяются требования, которые позволяют получить приемлемое решение проблемы. На этом этапе формулируются целевое назначение и основные свойства разрабатываемой программной системы.
Процесс выполнения работ и оформление результатов на этом этапе проработаны гораздо в меньшей степени, чем на других, и в общем случае не являются объектом деятельности профессиональных программистов.
Если предметом разработки является не программная система, а более сложный объект (например, система управления технологическим процессом), включающий программы только в качестве составной части, требования формируются ко всему предмету разработки. В том случае, когда разработка программного обеспечения является самоцелью, обычно используются методы составления исходных описаний. Одним из самых эффективных методов исходных описаний является метод структурного анализа, сущность которого сводится к декомпозиции исходного объекта на его составные части (рис. 2.2).
Рис. 2.2 — Схема декомпозиции системы
Таким образом, создается иерархия связанных подсистем (обязательно непересекающихся).
В общем случае, анализ требований, предъявляемых к системе, должен быть сосредоточен на интерфейсе между человеком (пользователем) и инструментом (ЭВМ). При этом для программных систем можно выделить лишь базовые требования:
время обработки (работы) программы;
стоимость обработки;
вероятность ошибки;
реакция на непредсказуемые действия оператора (защита от дурака и др.).
При декомпозиции требований следует делать различия между жесткими требованиями и требованиями, выполнение которых не является строго обязательным.
Особое внимание следует уделять пространственно-временным ограничениям и средствам системы, которые в будущем могут претерпеть изменения.
К важнейшим требованиям относятся ресурсные требования и затраты на реализацию системы.
Фактически, анализ требований завершается составлением развернутого технического задания на систему, которое в терминологии классического САПР называется аван-проектом.
2.2 Определение спецификаций
На этапе определения спецификаций осуществляется точное описание функций, реализуемых ЭВМ, а также задаются структура входных и выходных данных, методы и средства их размещения. Определяются алгоритмы обработки данных.
Центральным вопросом определения спецификаций является проблема организации базы данных. При этом решается комплекс вопросов, имеющих отношение к структуре файлов, организации доступа к ним, модификации и удалению.
В случае, когда новая система создается на основе существующих, составной частью спецификаций является схема (алгоритм) приведения существующей базы данных к новому формату. Такое преобразование может потребовать разработку специальной программы, которая становится ненужной после ее первого и единственного использования.
Все эти вопросы должны быть отражены в функциональных спецификациях, которые представляют собой документ, являющийся основополагающим в процессе разработки системы, так как содержит конкретное описание последней. Чем подробней составлены спецификации, тем меньше вероятность возникновения ошибок.
В спецификациях должны быть представлены данные для тестирования элементов системы и системы в целом. Это требование является объективным и обязательным, т.к. на данном этапе на параметры тестирования не будет оказывать влияние конкретная реализация системы.
Так как функциональные спецификации описывают принятые решения в целом, данный документ можно использовать для начальных оценок временных затрат, числа специалистов и других ресурсов, необходимых для проведения работ.
В общем случае, спецификации определяют те функции, которые должна выполнять система, не указывая, каким образом это достигается. Составление подробных алгоритмов на этом этапе преждевременно и может вызвать нежелательные осложнения.