Спиральная модель ЖЦПО

Классическая каскадная модель ЖЦПО

При работе с классической каскадной моделью весь ЖЦ разбивается на этапы (Рисунок1.1). Переход к следующему этапу происходит только после завершения всех работ по текущему. Этап заканчивается выпуском проектной документации. Каскадная модель имеет то преимущество, что строгая логическая последовательность выполняемых работ позволяет достаточно точно планировать сроки и затраты на разработку.

Использование каскадной модели удобно в том случае, когда в самом начале разработки

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

Рисунок 1.1

Рисунок 1.2

Каскадная модель хороша при решении сравнительно небольших задач, где каждая часть является

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

Каскадная модель с промежуточным контролем.

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

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

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

- за время разработки может измениться внешняя среда функционирования разрабатываемой системы.

Для преодоления вышеописанных трудностей и решения проблем была создана спиральная модель ЖЦПО.

Спиральная модель ЖЦПО

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

Анализ риска

Анализ Проектирование

Реализация

в1

Адаптация в2

версии Сопровождение

…

продукт

Планирование

следующей

итерации

вn

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

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

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

Тема 1.4 ЖЦПО в соответствии со стандартом ISO/IEC-12207

В настоящее время основным нормативным документом, регламентирующим процессы ЖЦПО является международный стандарт ISO/IEC-12207: 1995 (Information Technology – Software Life Cycle Processes, ISO – International Organization for Standardization – Международная организация по стандартам, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике).

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

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

Каждый процесс разделяется на набор действий, а действия на задачи.

В соответствии со стандартом ISO/IEC-12207 все процессы ЖЦПО разделяются на три группы:

договорной

аспект

аспект

управления

эксплуатация

аспект

эксплуатации

разработка

сопровождение

инженерный

аспект

аспект

Вспомогательные процессы

поддержки

Рисунок 1.3

- основные: приобретение, поставка, разработка, эксплуатация, сопровождение;

- вспомогательные: документирование, управление конфигурацией, обеспечение

качества, верификация, аттестация, совместная оценка, аудит, Разрешение проблемм;

- организационные: управление, усовершенствование, создание инфраструктуры, обучение.

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

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

Тема 1.5 Управление требованиями к системе

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

Затем за работу принимается аналитик. Ему необходимо из этой кучи хлама создать документ, в котором четко сформулированы все требования, предъявляемые к разрабатываемой программной системе. Результатом этой работы является ТЗ, один из основных документов, которыми руководствуется разработчик ПП.

Требование – это условие или характеристика, которым должна удовлетворять система.

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

Требования бывают функциональные и нефункциональные.

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

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

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

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

-требования к реализации, предписывающие применение определенных стандартов, я/п, операционной системы и т.д.

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

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

Управление требованиями представляет собой:

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

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

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

Во многих проектах устанавливаются приоритеты, разделяя все требования к ПП на три категории:

-необходимо выполнить,

-желательно выполнить,

-можно выполнить.

Требования, предъявляемые к разработке, могут быть смоделированы при помощи различного рода диаграмм, но они, как правило, служат для понимания требований, а не для управления ими в динамике. Именно динамическая составляющая управления требованиями вызывает наибольшие трудности, т.к. в процессе разработки могут измениться не только требования к ПП, но и их приоритеты. В настоящее время появились специальные программные системы управления требованиями (Requirements Management Systems, RequisitePro, DOORS). Кроме того, полезно для каждого требования хранить его историю, которая помогает отследить: какие изменения были внесены в требования, кем, когда и почему.

РАЗДЕЛ 2 АНАЛИЗ И ПРОЕКТИРОВАНИЕ ПО

МЕТОДЫ ПРОЕКТИРОВАНИЯ.

В этом разделе мы познакомимся с основными методами проектирования сложных программных систем. Это:

1- структурное проектирование,

2- объектно-ориентированное проектирование,

3- CASE-технологии разработки ПО,

4- ХР – экстремальное программирование.

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

Дата добавления: 2015-10-29