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

ВВЕДЕНИЕ

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

Объект исследования –этапы разработки программного продукта.

Предмет исследования – документальное сопровождение этапов жизненного цикла программных средств

Цель исследования данной курсовой работы – этапов разработки программных средств.

Для достижения этой цели в данной работе будут решаться следующие задачи

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

Тема данной работы довольно-таки хорошо рассмотрена различными авторами, среди которых можно отметить следующих: Иванова Г.С., Липаев В.В., Орлов С.А., Голосовский М.С., Гусятников В.Н., Макарова Н.В.

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

ГЛАВА 1. СТРАТЕГИИ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ

В 80-е и 90-е годы в области разработки ПО доминировали две тенденции [1, с.56]:

• Одна тенденция - это быстро растущее количество приложений, в том числе созданных для Web.
• Другая тенденция - это рост количества инструментов и парадигм (проектные подходы, такие как объектно-ориентированный).

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

• Определение процесса разработки ПО

• Управление проектом развития

• Описание целевого ПО

• Проектирование продукта

• Разработка продукта, то есть, его программирование

• Тестирование частей продукта

• Интеграция частей и тестирование продукта в целом

• Поддержка продукта

Система разработки ПО включает в себя процесс, персонал, и проект, и продукт, так называемое четыре «П» (рис. 1).

«Персонал» - люди, которые работают в команде. [12, с.45]

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

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

Рисунок 1 – Система разработки ПО

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

Программирование - это одно из мероприятий, включенных в цикл разработки ПО. [6, c. 55]

Программная инженерия должна охватывать различные типы программ[2, с.89]:

1. Независимое программное обеспечение:

• установлено на одном компьютере; не связано с другим ПО и аппаратными средствами;
• пример - текстовый редактор.

1. Интегрированное программное обеспечение:

• часть уникального приложения внутри технических средств;
• пример - контроллер автомобиля.

1. Программное обеспечение реального времени:

• должны обеспечивать работоспособность в течение небольшого промежутка времени, обычно несколько микросекунд;
• пример - ПО «Радары».

1. Сетевое программное обеспечение

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

Выделяют следующие последовательности разработки: [13, с.156]

1. классическая;
2. итеративная:

• спиральные
• инкрементальные процессы

1.1. Каскадная стратегия разработки программных средств

Классической моделью процесса разработки ПО является каскадная (водопадная) модель, в котором процесс представляет чередования фаз (рисунок 2.): [3, с.22]

• анализ требований,
• проектирование,
• внедрение,
• интеграцию
• тестирование

Рисунок 2 – Каскадная стратегия разработки программных средств

Анализ требований - является фазой сбора требований к продукту. В результате анализа, как правило, получается какой-нибудь текст.

Проектирование описывает внутреннюю структуру продукта. Как правило, такое описание дается в виде графиков и текстов.

Реализация - это программирование. Результатом является реализация кода на всех уровнях. [8, c.34]

Интеграция - это процесс сборки всех отдельных частей изделия.

Иногда процесс водопадной модели расширяют (рис. 3) в него включаются следующие дополнительные фазы.

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

Системное тестирования, которые проходят соответственно части приложения и все приложения в целом.

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

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

- анализ требований заказчика;

- проектирование;

- разработка;

- тестирование и опытная эксплуатация;

- сдача готового продукта.

На первом этапе осуществляется анализ проблемы, которую необходимо решить, однозначно определяются потребности заказчика. Итогом этой стадии является согласованное техническое задание. [9, c.44]

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

Третий этап — реализация проекта. На данной стадии разрабатывается ПО в соответствии тезисами, выработанными на предшествующей стадии. Методы, применяемые для реализации, не принципиальны, а склонны к изменениям, исходя из конкретной ситуации. На данном этапе производится готовый программный продукт. [10, c.86]

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

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

Рисунок 3 – Расширенная каскадная стратегия разработки программных средств

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

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

Существуют два типа итеративных процессов:

• спиральная модель
• итеративная модель.

1.2. Спиральная стратегия разработки программных средств

Здесь фазы «анализ требований - проектирование - реализация – тестирование» выполняются более одного раза.

Это может происходить ввиду нескольких причин. Ключевая из них связана с необходимостью предотвращения рисков. Другой причиной может быть запрос заказчиком прототипа проекта, чтобы получить обратную связь и предложения. Если разработанное ПО довольно громоздко, необходимо выполнить промежуточную интеграцию, не откладывая эту фазу в самом конце, как это предписано водопадной моделью. [15, с.201]

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

Рисунок 4 – Спиральная стратегия разработки программных средств

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

Одна из сложностей состоит в поддержании целостности документации, которую необходимо целиком обновлять и расширять в конце всякой итерации. Так, каждая версия кода должна осуществлять документированный проект и документально соответствовать тем же требованиям. [16, c.55]

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

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

Ключевая проблема данной стратегии – нахождение момента перехода на дальнейшую стадию. [18, c.41] Поэтому целесообразно создать временные рамки на каждую стадию жизненного цикла. Переход проводится по плану, даже если не вся запланированная работа завершена. План формируется на базе статистической информации, приобретенной в предыдущих проектах, и личного опыта разработчиков.

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

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

Недостатки спиральной модели: новизна (нет полной статистики эффективности модели); повышенные требования к клиенту; сложность регулирования и управления временем разработки.