Этапы процесса разработки по.

№5. Основное содержание этапа постановки задачи.

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

• Функциональные требования (функции, которые должна выполнять система);

• Эксплуатационные требования (определение особенности функционирования).

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

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

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

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

№7. Основное содержание этапа проектирования.

Стадия «технический проект». Основной задачей этапа является определение подробной спецификации разрабатываемого ПО.Этап включает:

• Проектирование общей структуры – определение основных компонентов и их взаимосвязей.

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

• Проектирование каждого компонента.

Принято различать два аспекта проектирования:

А) Логическое проектированиевключает те проектные операции, которые непосредственное не зависят от имеющихся технических и программных средств.

Б) Физическое проектирование– привязка к конкретным техническим и программным средствам.

№8. Основное содержание этапа реализации.

Стадия «рабочий проект». Представляет собой процесс поэтапного написания кода программы на выбранном языке программирования, его тестирование и отладку.

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

Причины выполнения новых версий:

• Необходимость исправления ошибок, выявленных в процессе эксплуатации.

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

• Изменение среды функционирования, связанное с появлением новых аппаратных средств и программных продуктов.

№9. Каскадная модель жизненного цикла разработки ПО. Краткая характеристика.

1970-1985 гг. Модель предполагает, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.

Постановка задачи

Анализ

Проектирование

Реализация

Модификация

t0 t1 t2 t3 t4 T

Достоинства:

• Получение в конце каждой стадии законченного набора проектной документации;

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

• Возможность реализации этапов различными исполнителями.

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

Недостатки:

• Неточные спецификации могут привести к пересмотру уже принятых решений, что требует возврата к началу разработки ПО;

• Изменение требований заказчика в процессе разработки приводят к необходимости возврата в начало модели;

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

№10. Модель жизненного цикла разработки ПО с промежуточным контролем. Краткая характеристика.

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

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

Постановка задачи

Анализ

Проектирование

Реализация

Модификация

k

k

k

k

№11. Спиральная модель жизненного цикла разработки ПО. Краткая характеристика.

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

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

Постановка задачи

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

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

• Сократить время появления первый версий программного продукта;

• Заинтересовать большое кол-во пользователей, обеспечивая быстрое продвижение продукта на рынке (бета-тестирование);

• Ускорить формирование и уточнение спецификаций за счет наработки практики использования продукта;

• Уменьшить вероятность морального устаревания системы за время обработки.

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

№12. Изменение жизненного цикла ПО при использовании CASE-технологий.

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

Парадигма Методология/Метод/Нотации/Средства.

Традиционная технология разработки	Разработка с помощью CASE-технологий
Основные усилия - на кодирование и тестирование	Основные усилия - на анализ и проектирование
"Бумажные" спецификации	Быстрое итеративное макетирование
Ручное кодирование	Автоматическая генерация машинного кода
Тестирование ПО	Автоматический контроль проекта
Сопровождение программного кода	Сопровождение проекта

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