- •СОДЕРЖАНИЕ
- •1.1. Основные понятия и определения
- •1.2. Жизненный цикл программных средств
- •2.1. Стратегии разработки программных средств и систем
- •2.1.1. Базовые стратегии разработки программных средств и систем
- •2.1.2. Каскадная стратегия разработки программных средств и систем
- •2.1.3. Инкрементная стратегия разработки программных средств и систем
- •2.1.4. Эволюционная стратегия разработки программных средств и систем
- •2.2.1. Общие сведения о каскадных моделях
- •2.2.2. Классическая каскадная модель
- •2.2.3. Каскадная модель с обратными связями
- •2.2.5. V-образная модель
- •2.3.1. Базовая RAD-модель
- •2.4.1. Общие сведения об инкрементных моделях
- •2.4.2. Инкрементная модель с уточнением требований на начальных этапах разработки
- •2.5.1. Общие сведения об эволюционных моделях
- •2.5.3. Структурная эволюционная модель быстрого прототипирования
- •2.5.5. Спиральная модель Боэма
- •2.5.6. Упрощенные варианты спиральной модели
- •3.1. Классификация проектов по разработке программных средств и систем
- •3.2. Процедура выбора модели жизненного цикла разработки программных средств и систем
- •3.3. Адаптация модели жизненного цикла разработки ПС и систем к условиям конкретного проекта
- •4.1. Модульное проектирование программ
- •4.2. Метод нисходящего проектирования
- •4.2.1. Пошаговое уточнение
- •4.2.2. Кодирование программы с помощью псевдокода и управляющих конструкций структурного программирования
- •4.2.3. Использование комментариев для описания обработки данных
- •4.2.4. Анализ сообщений
- •4.3. Метод восходящего проектирования
- •4.4. Метод иерархического проектирования модулей (метод Джексона)
- •4.4.1. Основные конструкции построения структур данных
- •4.4.2. Построение структур данных
- •4.4.3. Проектирование структур программ
- •4.4.4. Этапы конструирования программы
- •4.5.1. Связность модуля
- •4.5.2. Сцепление модулей
- •5.1. Общие сведения о CASE-технологиях
- •5.2. Методология структурного анализа и проектирования SADT
- •5.2.2. Основные понятия IDEF0-модели
- •5.2.3. Синтаксис диаграмм
- •5.2.4. Синтаксис моделей
- •5.2.6. Процесс моделирования в IDEF0
- •5.3. Информационное моделирование
- •5.3.1. Сущности
- •5.3.2. Атрибуты
- •5.3.3. Способы представления сущностей с атрибутами
- •5.3.4. Классификация атрибутов
- •5.3.5. Правила атрибутов
- •5.3.6. Связи
- •5.3.7. Безусловные связи
- •5.3.8. Условные формы связи
- •5.3.9. Формализация связи
- •5.3.10. Подтипы и супертипы
- •5.3.11. Рабочие продукты информационного моделирования
- •6.1. Эволюция Case-средств
- •6.2. Концептуальные основы Case–средств
- •6.3.1. Поддержка графических моделей
- •6.3.2. Контроль ошибок
- •6.3.3. Организация и поддержка репозитория
- •6.3.4. Поддержка процесса проектирования и разработки
- •6.4. Классификация CASE–средств
- •6.4.1. Классификация по типам
- •6.4.2. Классификация по категориям
- •6.4.3. Классификация по уровням
- •6.5. Инструментальные средства компании Telelogic, предназначенные для автоматизации жизненного цикла программных средств и систем
- •6.5.1. Telelogic DOORS
- •6.5.2. Telelogic TAU
- •6.5.3. Telelogic SYNERGY
- •6.5.4. Telelogic DocExpress
- •6.5.5. Telelogic TAU Logiscope
- •7.2. Реализация процесса документирования в соответствии со стандартом ISO/IEC 15910:1999
- •7.2.2. Выполнение процесса документирования
- •7.2.3. Содержание плана документирования
- •7.2.4. Требования к содержанию спецификации стиля документации
- •ЛИТЕРАТУРА
2.5.Модели жизненного цикла,
реализующие эволюционную стратегию разработки программных средств и систем
2.5.1.Общие сведения об эволюционных моделях
Эволюционные модели поддерживают эволюционную стратегию разработки ПС и систем, при которой в начале жизненного цикла определяются не все требования. Система или программное средство строится в виде
последовательности |
версий. Каждая |
из |
версий |
реализует |
некоторое |
подмножество требований. После реализации |
каждой |
версии |
требования |
уточняются.
Как правило, эволюционные модели базируются на использовании прототипирования.
2.5.2.Эволюционная модель по ГОСТ Р ИСО/МЭК ТО 15271-2002
Один из простейших классических вариантов эволюционной модели
приведен в ГОСТ Р ИСО/МЭК ТО 15271-2002 |
(рисунок 2.14) [6]. |
|
|
|
|||||
В |
данном случае |
разработка |
каждой версии |
программного |
средства |
||||
(системы) выполняется на основе каскадной модели, содержащей четыре этапа: |
|||||||||
разработка требований, проектирование, |
программирование и |
тестирование, |
|||||||
ввод в действие и поддержка приемки. |
|
|
|
|
|
|
|||
При |
разработке |
первой версии |
формулируются |
наиболее |
важны |
||||
(базовые) |
требования |
к |
продукту. На |
основе |
данных |
требований |
разрабатывается и вводится в действие первая версия системы(программного средства).
При разработке каждой очередной версии требования уточняются, при
необходимости |
вводятся |
новые |
или |
изменяются |
уже |
реализован |
требования. На |
основе уточненных требований |
разрабатывается |
и вводится в |
действие очередная версия продукта.
Процесс продолжается, пока все требования не будут окончательно уточнены и полностью реализованы.
38
|
|
|
Версия 1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Програм- |
|
Ввод в |
Разработка |
|
Проекти- |
|
мирование |
|
действие и |
требований |
|
рование |
|
и тестиро- |
|
поддержка |
1 |
|
|
|
вание |
|
приемки |
|
|
|
|
|
|
|
|
|
|
Версия 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Програм- |
|
Ввод в |
Разработка |
|
Проекти- |
|
мирование |
|
действие и |
требований |
|
рование |
|
и тестиро- |
|
поддержка |
2 |
|
|
|
вание |
|
приемки |
|
|
|
|
|
|
|
|
|
|
Версия N |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Програм- |
|
Ввод в |
Разработка |
|
Проекти- |
|
мирование |
|
действие и |
требований |
|
рование |
|
и тестиро- |
|
поддержка |
N |
|
|
|
вание |
|
приемки |
|
|
|
|
|
|
|
Рисунок 2.14 – Вариант эволюционной модели по ГОСТ Р ИСО/МЭК ТО 15271-2002
39
2.5.3.Структурная эволюционная модель быстрого прототипирования
При использовании структурной эволюционной модели быстрого прототипирования система или программное средство строится в вид последовательности прототипов.
Рисунок 2.15 изображает структурную эволюционную модель быстрого
прототипирования, которая |
ориентирована |
на процессы |
и |
работыСТБ |
|
ИСО/МЭК 12207-2003. |
|
|
|
|
|
Начало жизненного |
цикла разработки находится в центре модели. С |
||||
учетом |
предварительных |
требований |
пользователями |
и |
разработчиками |
разрабатывается предварительный план проекта. |
|
|
|||
Затем выполняется быстрый анализ требований к ПС(или |
системе), во |
время которого совместно с пользователями разрабатываютсяумышленно неполные требования. На их основе выполняется укрупненное проектирование, программирование и тестирование системы и ее программных компонентов. Таким образом, реализуется построение исходного прототипа.
После этого начинается итерационный цикл быстрого прототипирования,
содержание |
которого аналогично циклу |
построения |
исходного прототипа |
|
(укрупненное проектирование, |
программирование и тестирование системы и ее |
|||
программных |
компонентов). |
Пользователь |
оценивает |
функционирование |
прототипа. По результатам оценки уточняются требования, на основании которых разрабатывается новый прототип. Этот процесс продолжается до тех пор, пока быстрый прототип окажется удовлетворительным и будет принят
пользователем. |
|
|
|
|
Затем |
осуществляется |
детализированная |
разработка |
системы(или |
программного |
средства), во |
время которой реализуются |
несущественные |
функции системы или ПС, пользовательские интерфейсы и т..пПосле этого выполняется ввод в действие и поддержка приемки системы (ПС). В результате ускоренный прототип становится полностью действующей системой (ПС).
Зачастую данная |
модель применяется в комбинации с |
каскадно |
||
моделью. На начальных этапах разработки используется прототипирование, а |
||||
на последнем (детальная разработка) — этапы каскадной модели с целью |
||||
обеспечения качества и функциональной эффективности системы (ПС). |
|
|||
Недостатки |
структурной |
эволюционной |
модели |
бы |
прототипирования: |
|
|
|
|
1) обычная недостаточность или неадекватность документации по ускоренным прототипам;
40
Приемка прототипа пользователем
Детализированная разработка
Итеративное прототипирование
Быстрый анализ
требований
Ввод в |
|
Проекти- |
действие и |
План |
|
поддержка |
проекта |
рование |
приемки |
|
прототипа |
прототипа |
|
|
|
Програм- |
|
|
мирование и |
|
|
тестирование |
|
|
прототипа |
|
Эксплуатация и сопровождение
Ввод в действие и
поддержка
приемки
Рисунок 2.15 – Структурная эволюционная модель быстрого прототипирования
41
2)вероятность недостаточного качества результирующего ПС(или системы) за счет его создания из рабочего прототипа (при детальной разработке ПС или системы из последнего прототипа может оказаться сложной или невозможной реализация функций, не реализованных при итерационном прототипировании);
3)возможность задержки реализации конечной версии ПС(системы)
при несочетании языка или среды прототипирования с рабочим языком или средой программирования.
2.5.4.Эволюционная модель прототипирования по ГОСТ Р ИСО/МЭК ТО 15271-2002
Встандарте ГОСТ Р ИСО/МЭК ТО15271-2002 [6] приведен пример эволюционной модели, основанной на прототипировании(рисунок 2.16). Данная модель предназначена для разработки небольших коммерческих систем
иадаптирована под требования стандарта ИСО/МЭК 12207.
Основой эффективного применения данной модели жизненного цикла
является |
максимально возможная детализация на ранних этапах проекта |
||
(анализ |
требований |
к |
системе и проектирование системной архитектуры). |
Данные |
этапы выполняются в модели один раз. Однократное выполнение этих |
||
этапов |
достигается |
за |
счет тесных связей разработчиков с пользователями |
проекта. Требования к системе, в первую очередь, функции системы и внешние интерфейсы определяются пользователями в начале ЖЦ, деловые процессы уточняются при проведении пользователем серии оценок прототипов системы.
В данной модели при создании каждой версии ПС использует
прототипирование. При разработке каждого прототипа уточняются требования |
|
||||||
к нему. Затем выполняется программирование прототипа в среде4GL. При |
|
||||||
выполнении данного этапа инструментальная среда 4GL используется в первую |
|
||||||
очередь для быстрого проектирования и |
сборки ,ПСа также |
оперативного |
|
||||
наращивания, изменения |
и |
уточнения |
. ПСЯзыки 4GL осуществляют |
|
|||
частичную автоматическую кодогенерацию ПС. |
|
|
|||||
Проверка и оценка каждого прототипа осуществляется пользователем в |
|||||||
реальной эксплуатационной среде. |
|
|
|
||||
В |
модели |
ЖЦ |
|
определен |
фиксированный |
период |
провед |
прототипирования и произвольное количество итераций.
Разработчик ПС контролирует прототипирование с помощью:
1)установления приоритетов требований к ПС;
2)ужесточения ограничений временного интервала;
3)привлечения конечного пользователя.
Из описания данной модели видно, что при разработке прототипов фактически используется RAD-модель жизненного цикла.
42