Файл: Основы проектирования программ. Этапы создания программного обеспечения.pdf

Введение

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

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

1. Этапы создания программного обеспечения

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

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

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

1.1. Модели жизненного цикла программного обеспечения

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

---

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

Объектом исследования является программное обеспечение.

Предметом исследования является процесс проектирования программного обеспечения.

Целью работы является исследование процесса проектирования программного обеспечения.

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

1. Изучить модели жизненного цикла создания программного обеспечения.
2. Рассмотреть стандарты и подходы к разработке программных продуктов.
3. Дать характеристику этапам создания программных продуктов.
4. Изучить сущность процесса проектирования программного обеспечения.
5. Описать виды проектирования программного обеспечения.
6. Рассмотреть свойства модели программного продукта.
7. Этапы создания программного обеспечения
8. Модели жизненного цикла программного обеспечения

Процесс создания программного обеспечения – это достаточно сложный и нелинейный процесс. Не существует одного четкого подхода к разработке программного обеспечения. Однако были разработаны стандарты, которые регламентируют этот процесс. К таким стандартам относят российский стандарт ГОСТ 34.601 «Стадии создания автоматизированных систем» и зарубежный стандарт ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

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

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

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

---

Рисунок 1. Структура каскадной модели жизненного цикла программного обеспечения.

Требования к проектируемой АИС определяются на стадии анализа и затем документируются в техническом задании, которое является опорным документом при создании АИС. Каждая стадия каскадной модели должна завершаться выпуском полного комплекта проектной документации, которая включает в себя:

1. Техническое задание;
2. Эскизный проект;
3. Технический проект;
4. Рабочую программу.

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

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

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

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

Итерационную модель также называют моделью с промежуточным контролем или моделью с циклическим повторением фаз. Структура итерационной модели представлена на рисунке 2.

Рисунок 2. Итерационная модель жизненного цикла программного обеспечения.

---

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

Спиральная модель жизненного цикла программного продукта является классическим примером применения эволюционной стратегии разработки программных средств. Модель была разработана Б. Боэмом в 1988. Основу модели составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса макетирования, к которым был добавлен новый элемент – анализ риска, который отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов, которые представлены четырьмя квадрантами спирали. Структура спиральной модели представлена на рисунке 3.

Рисунок 3. Схема спиральной модели жизненного цикла разработки ПО.

Рассмотрим этапы спиральной модели:

1. На этапе планирования осуществляется определение целей, вариантов и ограничений проекта.
2. На этапе анализа риска осуществляется анализ вариантов и распознавание/выбор риска проекта.
3. На этапе конструирования осуществляется разработка программного продукта следующего уровня.
4. На этапе оценивания происходит оценка текущих результатов разработки заказчиком.

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

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

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

---

1.3 Стандарты, регламентирующие процесс разработки программного обеспечения

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

Рекомендуемый состав стадий жизненного цикла программного обеспечения регламентируют стандарты ISO, которые описывают технологические процессы. Стандарт ISO/IEC 12207:2008 «System and software engineering – Software life cycle processes» определяет общую структуру жизненного цикла ПО в виде трехуровневой модели, элементами которой являются процессы, виды деятельности, задачи. Процессы объединены в четыре группы: основные процессы, поддерживающие процессы, организационные процессы, адаптация. Процессы состоят из отдельных видов деятельности.

Стандарт ISO/IEC 15288:2008 «Разработка систем и программного обеспечения – Процессы жизненного цикла систем» рассматривает программно-аппаратную систему как единое целое. Стандарт предлагает рассматривать структуру жизненного цикла ПО как набор групп процессов, каждый из которых описывается набором результатов, и каждый из результатов достигается при помощи набора различных видов деятельности. Эффективность разработки ПО в целом зависит от точности и корректности формулировки требований к программному продукту.

Правила работы с требованиями к программному обеспечению рассматриваются в стандарте IEEE 830-1998 «Recommended practice for software requirements specifications». Стандарт регламентирует состав документации для фиксирования требований к ПО, а также дает определение характеристикам, которыми должен обладать правильно составленный набор требований.

---