Введение в пи 8 лекция (27.10.11)

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

1) Подход пробных разработок:

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

2) Прототипирование:

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

Недостатки:

1)Многие этапы процесса создания ПО, не документируются ну или документация заново переписывается.

2)Системы часто получаются плохо структурированными.

3) Часто требуются специальные средства и технологии разработки ПО.

4) Проблема совместимости.

Разработка ПО на основе ранее созданных компонентов.

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

Этапы процесса создания ПО:

1) Спецификация требований.

2) Анализ компонентов:

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

3) Модификация требований:

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

4) Проектирование системы:

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

5) Разработка и сборка систем.

6) Аттестация системы.

Итерационные модели разработки ПО:

Модель пошаговой разработки:

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

Определение общих требований

Пошаговая детализация требований

Разработка системной архитектуры

Шаг разработки системы

Шаг аттестации

Шаг сборки

Аттестация системы

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

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

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

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

Достоинства данной модели:

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

2) Можно использовать компоненты, полученные на первых шагах разработки, как прототипы.

3) Уменьшается риск общей системы ошибок.

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