Этапы (стадии) разработки информационных систем)

Этапы (стадии) разработки ПО

Можно выделить следующие укрупненные этапы разработки ПО с учетом соответствующих стадий разработки по ГОСТ 19.102—77 «Стадии разработки»:

— постановка задачи (стадия «Техническое задание»);

— определение спецификаций (стадия «Эскизный проект»);

— проектирование (стадия «Технический проект»);

— реализация (стадия «Рабочий проект»).

— внедрение

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

Неверно предполагать, что жизненный цикл разработки ПО согласно ГОСТ 19.102- 77 есть последовательное выполнение стадий и этапов, определенных в таблице.

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

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

Деление на этапы является условным и может изменяться при необходимости. Например, тестирование и отладка могут быть частью этапа реализации (или программирования), а могут быть отдельным этапом.

1. На стадии Техническое задание выполняются следующие работы, входящие в состав соответствующих этапов.

1.1. Обоснование необходимости разработки программ:

- постановка задачи;

-- сбор исходных материалов;

- выбор и обоснование критериев эффективности и качества;

- обоснование необходимости проведения НИР.

1.2. Выполнение научно-исследовательских работ:

- определение структуры входных и выходных данных;

- предварительный выбор методов решения задач;

- обоснование целесообразности применения ранее разработанных программ;

- определение требований к техническим средствам;

- обоснование принципиальной возможности решения поставленных задач.

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

- определение требований к программе;

- разработка технико-экономического обоснования разработки программы;

-определение стадий, этапов и сроков разработки программы и документации на нее;

- выбор языков программирования;

- определение необходимости проведения НИР на последующих стадиях;

-согласование и утверждение ТЗ.

Постановка задачи — это процесс формулировки назначения программного обеспечения и основных требований к нему.

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

Этап постановки задачи заканчивается разработкой технического задания с принятием основных проектных решений.

Техническое задание в соответствии со стандартом ГОСТ 19.201—78 «Техническое задание. Требования к содержанию и оформлению» имеет следующие основные разделы:

• введение: наименование и краткая характеристика программного обеспечения;

• основание для разработки;

• назначение разработки: описание функционального и эксплуатационного назначения, спецификации функций;

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

• требования к программной документации;

• технологические требования.

Технологические требования определяют выбор следующих принципиальных решений, влияющих на процесс проектирования программного обеспечения:

• архитектура программного обеспечения;

• пользовательский интерфейс;

• метод программирования;

• язык программирования;

• среда программирования.

Архитектурой программного обеспечения называют описание создаваемого программного обеспечения на уровне его компонентов и связей между ними.

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

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

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

Распространенными являются следующие архитектурные паттерны:

• модель-представление-контроллер (Model-View-Controller, MVC) применяется в системах, ориентированных на обслуживание клиентов;

• паттерн хранилища данных применяется в системах, функционирование которых связано с обработкой большого объема данных (информационные системы, системы управления); архитектура таких систем должна содержать компоненты, генерирующие данные, и компоненты, их обрабатывающие;

• паттерн «клиент-сервер» предусматривает распределение задач между поставщиками и заказчиками услуг. Поставщики (серверы) предоставляют заказчикам (клиентам) определенный набор услуг (сервисов), доступ к которым осуществляется с помощью удаленного вызова соответствующих процедур;

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

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

При процедурном программировании модель построения программы — иерархия множества подпрограмм, при объектно-ориентированном программировании — иерархия множества классов, совокупность обменивающихся сообщениями объектов классов.

При этом простом виде архитектуры программа — это совокупность отдельно компилируемых программных единиц, используемая при решении задач.

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

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

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

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

Различают следующие типы пользовательских интерфейсов:

• примитивные интерфейсы;

• интерфейсы-меню;

• интерфейсы со свободной навигацией;

• интерфейсы прямого манипулирования.

К технологическим требованиям к программному обеспечению относятся:

• выбор метода программирования: процедурный или объектно-ориентированный;

• выбор языка программирования: C++, Java, Python и др.;

• выбор среды программирования: Visual Studio фирмы Microsoft, Embarcadero RAD Studio (включающая Delphi и C++ Builder), Eclipse и др.

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

Основные этапы и содержание работ на стадии Эскизный проект приведены в таблице.

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

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

Спецификации содержат:

• декомпозицию и содержательную постановку задач;

• эксплуатационные ограничения;

• математические методы решения;

• модели программного обеспечения.

2.1. Графическое представление спецификаций

Модели программного обеспечения зависят от технологии программирования (процедурная или объектно-ориентированная).

При процедурном программировании используются следующие модели разрабатываемого программного обеспечения:

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

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

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

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

При объектно-ориентированном программировании модели разрабатываемого программного обеспечения основаны на предметах реального мира.

На этапе определения спецификаций требуется разработать модель предметной области программного обеспечения на базе иерархии классов (типов, определенных пользователем), объектной декомпозиции.

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

В настоящее время стандартным средством описания разрабатываемого программного обеспечения с использованием объектно-ориентированного подхода является фактически графический язык UML (Unified Modeling Language, универсальный язык моделирования), разработанный авторами Г. Буч, Д. Рамбо и И. Якобсоном в 1995 г.

Язык UML описывает модель сложной системы в виде специальных графических конструкций (диаграмм).

Диаграмма представляет собой связный граф, вершины которого представляются в виде геометрических фигур, связанных между собой ребрами (дугами).

Все диаграммы используют единую графическую нотацию.

В диаграммах используется 3 типа графических элементов, имеющих различное назначение:

• геометрические фигуры обозначают вершины графа. Их форма строго соответствует определенным элементам языка (класс, вариант использования, состояние, деятельность). Каждой вершине присваивается уникальное имя;

• различные линии (ребра), соединяющие геометрические фигуры (вершины графа) обозначают связи и взаимодействия элементов;

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

Нотация языка UML определяет использование следующих основных видов диаграмм:

• вариантов использования (прецедентов) — описывают основные функции системы;

• классов — описывают классы, их характеристики (поля и операции) и связи между ними;

• кооперации — показывают взаимодействие объектов в процессе реализации варианта использования;

• пакетов — показывают связи наборов классов, объединенных в пакеты;

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

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

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

• развертывания — позволяют связывать программные и аппаратные компоненты системы.

Пример 1

Пример 2

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

Любая модель должна содержать только те элементы, которые определены в нотации языка UML. Каждый элемент может быть использован только в соответствии с назначением и по правилам, определенным в языке.

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

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

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

Каждая модель конкретной программной системы может содержать все или только некоторые типы диаграмм.

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

Основные этапы и содержание работ на стадии Технический проект приведены в таблице.

Содержанием работ на этой стадии является проектирование структуры ПО.

Проектирование — это процесс разработки структурной схемы программного обеспечения с проектированием компонентов и их взаимосвязей.

Методологической основой проектирования программного обеспечения является системный подход.

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

При этом исследование объектов нацелено:

• на раскрытие целостности объекта и обеспечивающих его механизмов;

• выявление многообразных типов связей сложного объекта;

• сведение этих связей в единую теоретическую картину.

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

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

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

Методы структурного анализа основываются на соблюдении следующих правил:

• разбиение системы на уровни абстракции с ограничением числа элементов на уровне;

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

• использование строгих формальных правил записи и условных обозначений — нотаций;

• последовательное приближение к конечному результату.

Основными средствами структурного анализа являются:

• DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна — Сарсона, Йордона — Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;

• STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда — Меллора для проектирования систем реального времени;

• ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера; структурные карты Джексона и (или) Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

• FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;

• SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;

• семейство IDEF (Integration Definition for Function Modeling).

Тип модели программного обеспечения определяется выбранной технологией — методом программирования (процедурный, объектно-ориентированный, компонентный).

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

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

Метод пошаговой детализации применяет нисходящую пошаговую разработку алгоритма, когда на каждом шаге происходит разложение функции на подфункции.

При объектно-ориентированном подходе модель построения программы — это иерархия классов, объектная декомпозиция. В результате декомпозиции получается структурная схема программы, представляющая собой многоуровневую, иерархическую схему взаимодействия экземпляров (объектов) классов. Следующий этап проектирования программного обеспечения заключается в разработке классов и их интерфейсов с описанием элементов-данных и элементов-функций каждого класса. Для проектирования пользовательских интерфейсов используются сложные интерфейсы: меню с иерархической структурой команд, свободная навигация, не привязанная к уровням иерархии (используется в Windows-приложениях).

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

4. Рабочий проект

Основные этапы и содержание работ на стадии Рабочий проект приведены в таблице.

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

Реализация — это процесс создания кода компонентов программного обеспечения на выбранном языке программирования, его тестирования и отладки.

При процедурном подходе реализация заключается в программировании функций и файлов (модулей) с использованием методов структурного программирования функций и программирования «сверху-вниз» (top-down).

Этап программирования задачи выполняется в следующей последовательности:

• программирование функций верхнего уровня схемы;

• программирование функций нижнего уровня схемы и т. д.

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

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

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

Тестирование и отладка являются завершающими этапами процесса реализации программного обеспечения.

Тестирование позволяет обнаружить ошибки, а отладка — их исправить.

В соответствии с этапами обработки программы (компиляция, компоновка, выполнение) различают следующие группы ошибок:

• синтаксические ошибки, обнаруживаемые компилятором при синтаксическом и семантическом анализе программы;

• ошибки компоновки, фиксируемые компоновщиком (редактором связей) при объединении модулей программы;

• ошибки выполнения, обнаруживаемые операционной системой или пользователем при выполнении программы.

Из всех групп ошибок самыми сложными для тестирования и отладки являются ошибки выполнения программ, а среди них — логические ошибки, имеющие непредсказуемые причины. Так, причинами могут быть ошибки при проектировании программы, разработке алгоритмов, определении структуры данных.

Согласно рекомендациям Microsoft, различают следующие стадии тестирования:

• модульное тестирование, проверяющее небольшие отдельные части программы (циклы, блоки, подпрограммы);

• компоновочное тестирование, проверяющее следующий уровень — программные файлы (модули), объединение, взаимодействие отдельных частей программы;

• системное тестирование, проверяющее полную версию программы, взаимодействие с операционной системой;

• стресс-тестирование, изучающее работу программы при ограниченных системных ресурсах;

• бета-тестирование, позволяющее узнать мнение специалистов-пользователей;

• приемно-сдачное тестирование — приемка пользователями в реальных условиях.

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

Существуют и другие виды тестирования, направленные на проверку различных аспектов корректности кода программы и его соответствия техническому заданию. Отдельной разновидностью можно считать методологию разработки через тестирование (TDD, Test-Driven Development), согласно которой тесты для различных функций программы разрабатываются до создания кода этих функций. Такая методика позволяет сократить объем программного кода и повысить его надежность, но увеличивает затраты на разработку.

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

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

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

Но, безусловно, наиболее эффективными методами являются интегрированные средства отладки, имеющиеся в современных средах программирования. Например, отладчик Visual C++ встроен в среду Visual Studio, имеет свои меню и панели инструментов, которые позволяют выполнять следующие действия:

• установка различных точек прерывания, связанных с кодом, с данными, с сообщением, условных точек прерывания;

• выполнение программы до точки прерывания;

• просмотр в шести окнах отладчика информации о текущем состоянии программы при остановке программы в точке прерывания и при пошаговом выполнении;

• пошаговое выполнение программы с заходом в функции и без захода;

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

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

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

8. Внедрение

На стадии Внедрения осуществляется подготовка и передача ПО и программной

документации для сопровождения и/или изготовления, оформление и утверждение акта о передаче ПО на сопровождение или изготовление, передача ПО в фонд алгоритмов и программ.

Контрольные вопросы:

1. Назовите пять укрупненных этапов разработки ПО согласно рассмотренным материалам (с учетом ГОСТ 19.102-77).

2. Почему начальные стадии жизненного цикла разработки ПО считаются наиболее важными и дорогостоящими с точки зрения исправления ошибок?

3. Какой стандарт регламентирует требования к содержанию и оформлению Технического задания (ТЗ)? Перечислите его основные разделы.

4. Какие три типа принципиальных решений, влияющих на процесс проектирования, определяются в разделе «Технологические требования» ТЗ?

5. Дайте определение архитектуры программного обеспечения.

6. Что такое архитектурный паттерн (шаблон)? Приведите два примера таких паттернов.

7. В чем заключается ключевое различие между процедурным и объектно-ориентированным подходом с точки зрения базовой модели построения программы?

8. Перечислите четыре основных типа пользовательских интерфейсов.

9. Что такое спецификации ПО и каким двум основным требованиям они должны соответствовать?

10. Какие два основных типа моделей программного обеспечения используются на этапе определения спецификаций в зависимости от технологии программирования?

11. Какой графический язык является стандартным средством для описания ПО при объектно-ориентированном подходе?

12. Назовите не менее трех основных видов диаграмм UML и их назначение.

13. Дайте определение проектированию как этапу разработки ПО.

14. Что такое системный подход и на что он нацелен при исследовании объектов?

15. Что такое структурный анализ и на каком основном принципе он базируется?

16. Перечислите три основных графических средства (нотации) структурного анализа (например, DFD, ERD).

17. В чем заключается метод пошаговой детализации, применяемый при процедурном проектировании?

18. На какие три основные группы делятся ошибки в программе в соответствии с этапами её обработки (компиляция, компоновка, выполнение)?

19. Согласно рекомендациям, приведенным в материалах, назовите и охарактеризуйте три стадии тестирования ПО (например, модульное, системное).

20. Что такое защитное программирование и какова его основная цель? Какой компромисс оно предполагает?