Автоматизированное проектирование информационных систем. Лекция 27

1. Дисциплина «Информационные технологии в экономике» Лекция-27 Автоматизированное проектирование информационных систем

ПЕРМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ЭКОНОМИЧЕСКИЙ ФАКУЛЬТЕТ
Дисциплина
«Информационные технологии в
экономике»
Лекция-27
Автоматизированное проектирование информационных
систем (CASE-технология)
Пермь, 2020

2. Изучаемые вопросы

1. Основные понятия CASE-технологий. Классификация CASEтехнологий. Архитектура CASE-средства.
2. Функционально-ориентированное
проектирование
(диаграммы: функциональных спецификации, потоков
данных, переходов состояний, инфологических моделей
«сущность-связь», структуры программного приложения).
3. Объектно-ориентированное проектирование (диаграммы:
прецедентов использования, классов объектов, состояний,
взаимодействия
объектов,
деятельностей,
пакетов,
компонентов, размещения). Прототипное проектирование
(RAD-технология).
2

3. Основные понятия CASE-технологий

Термин CASE (Computer Aided System/Software Engineering)
используется в довольно широком смысле.
Первоначальное значение термина CASE было ограниченно вопросами
автоматизации разработки только лишь программного обеспечения.
CASE-технологии развивались с целью преодоления ограничений при
использовании структурной методологии проектирования за счет ее
автоматизации и интеграции поддерживающих средств. Основные
сложности включают в себя:
сложность понимания,
высокую трудоемкость и стоимость использования,
трудность внесения изменений в проектные спецификации и т.д.
CASE-технологии только обеспечивают более высокую эффективность
методологий проектирования.
Большинство
существующих
CASE-систем
ориентировано
на
автоматизацию проектирования программного обеспечения.
Наибольшая потребность в использовании CASE-систем испытывается
на начальных этапах разработки, а именно на этапах анализа и
спецификации требований к ИС.
3

4. Основные понятия CASE-технологий

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

5. Основные понятия CASE-технологий

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

6. Классификация CASE-технологий

Современные CASE-системы классифицируются по следующим признакам:
№
1
2
3
Признак
по поддерживаемым
методологиям
проектирования
по поддерживаемым
графическим нотациям
построения диаграмм
по степени
интегрированности
Описание
4
по типу и архитектуре
вычислительной техники
5
по режиму коллективной
разработки проекта
6
по типу операционной
системы (ОС)
функционально (структурно)-ориентированные,
объектно-ориентированные,
комплексно-ориентированные (набор методологий проектирования).
с фиксированной нотацией,
с отдельными нотациями,
наиболее распространенными нотациями.
tools – отдельные локальные средства,
toolkit – набор неинтегрированных средств, охватывающих большинство этапов
разработки ЭИС),
workbench – полностью интегрированные средства, связанные общей базой
проектных данных – репозиторием.
ориентированные на ПЭВМ,
ориентированные на локальную вычислительную сеть (ЛВС),
ориентированные на глобальную вычислительную сеть (ГВС),
смешанного типа.
не поддерживающие коллективную разработку,
ориентированные на режим реального времени разработки проекта,
ориентированные на режим объединения подпроектов.
работающие под управлением MS Windows,
работающие под управлением UNIX,
работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.). 6

7. Архитектура CASE-средства

Верификатор
диаграмм
Графический
редактор диаграмм
Репозиторий
(словарь данных)
Администратор
проекта
Документатор
проекта
Сервис
7

8. Архитектура CASE-средства

Ядром системы является база данных проекта - репозиторий.
Репозиторий содержит информацию об объектах проектируемой ЭИС и
взаимосвязях между ними, все подсистемы обмениваются данными с
ним.
В репозиторий хранятся описания следующих объектов:
проектировщиков и их прав доступа к различным компонентам
системы;
организационных структур;
диаграмм;
компонентов диаграмм;
связей между диаграммами;
структур данных;
программных модулей;
процедур;
библиотеки модулей и т.д.
8

9. Архитектура CASE-средства

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

10. Архитектура CASE-средства

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

11. Характеристики современного CASE-средства

№
Характеристика
Описание
1
Наличие базы
проектных
данных, архива
или словаря
СУБД и словари данных обеспечивают высокую степень интеграции данных и
предоставляют широкие возможности для централизованного сбора, хранения и
распределения проектной информации между различными этапами проекта и
выполняемыми операциями.
2
Интерфейсы с
другими CASEсистемами
В процессе проектирования ЭИС могут использоваться различные методологии,
поэтому важно, чтобы используемые CASE-системы предоставляли возможности
для аффективного использования нескольких методов. При этом должна быть
обеспечена терминологическая совместимость различных методологий.
3
Возможности
экспорта/импорта
Спецификации, полученные на этапах анализа, проектирования и кодирования
для одной ЭИС, могут быть использованы для проектирования другой системы.
Повторное проектирование и кодирование могут быть обеспечены при помощи
средств экспорта/импорта спецификаций в различные CASE-системы.
4
Многопользовател
ьский режим
Развитые CASE-системы должны обладать возможностями разделения
полномочий персонала разработчиков и объединения отдельных работ в общий
проект.
5
Открытая
архитектура
Открытая к доступу проектировщиков информация об используемых форматах
файлов и интерфейсах должна позволять безболезненно переходить от одной
CASE-системы к другой.
6
Расширение
новыми
методологиями
Как и любое программное средство, CASE-сисгема должна обладать
возможностью совершенствоваться с учетом появления новых требований или
новых предметных областей.
11

12. Характеристики современного CASE-средства

№
Характеристика
Описание
7
Наличие
графических
средств
поддержки
проектирования
Большинство CASE-систем базируется на графическом отображении
методологий. Графические элементы структурных диаграмм и объекты словаря
должны позволять декомпозировать различные компоненты проекта и
детализировать изображения с той степенью, с какой это необходимо для
понимания проектных решений.
8
Обеспечение
качества
проектной
документации
Возможности CASE-системы анализировать и проверять описания и
документацию на полноту и непротиворечивость, а также на соответствие
принятым в данной методологии стандартам и правилам. В результате анализа
должна формироваться информация, указывающая на имеющиеся
противоречия или неполноту проектной документации, находящейся в архиве
или словаре.
9
Автоматическая
генерация
отчетов о
проектных
решениях
Решения (спецификации), созданные в процессе проектирования, служат
источником документирования системы. Часто возникает потребность
получения твердой копии спецификаций в текстовой или графической форме.
10
Генерация кодов
программ
CASE-системы с жесткой ориентацией на конкретные СУБД должны
обеспечивать возможность генерации программ в среде этих СУБД.
11
Планирование и
управление
проектом
Многие развитые CASE-системы имеют в своем составе средства планирования
и управления проектом. Спецификации, которые используются этими
средствами, представляют собой опорные точки управления, позволяющие
определять сроки разработки.
12

13. Функционально-ориентированное проектирование

Основными
идеями
функционально-ориентированной
CASEтехнологии являются идеи структурного анализа и проектирования
информационных систем.
Они заключаются в следующем:
1. Декомпозиция всей системы на некоторое множество иерархически
подчиненных функций.
2. Представление всей информации в виде графической нотации.
Систему всегда легче понять, если она изображена графически.
В качестве инструментальных средств структурного
проектирования выступают следующие диаграммы:
анализа
и
BFD (Business Function Diagram) ;
DFD (Data Flow Diagram);
STD (State Transition Diagram);
ERD (Entity Relationship Diagram);
SSD (System Structure Diagram).
13

14. Функционально-ориентированное проектирование

Диаграммы
функциональных
спецификаций
позволяют
представить общую структуру ИС, отражающую взаимосвязь различных
задач (процедур) в процессе получения требуемых результатов.
Основными объектами являются:
Функция
- некоторое действие информационной системы,
необходимое для решения экономической задачи;
Декомпозиция функции - разбиение функции на множество
подфункций.
Организация
товародвижения на
складе
Приемка товара
Отпуск товара
Ведение базы
данных «движение
товаров»
Инвентарный
контроль
14

15. Функционально-ориентированное проектирование

Диаграммы потоков данных отражают передачу информации от
одной функции к другой в рамках заданной технологии обработки.
Первичные
документы
i2
i1
Товар
Приказ
(распоряжение)
об
инвентаризации
Нормативы
складского
учета С1
Товарно-сопроводительные
документы, накладные,
счета, фактуры
Приходный ордер
Приемка товара
A1
Данные о
приемке товара
Принятый
товар
Расходная
накладная
Р3
Выходные
документы
Накладные,
требования,
лимитно-заборные
карты
Отпуск товара
О1
О2
Оформленны
й товар
А2
Р4
Ведение БД
"Движение
товаров"
Данные об
отгрузке товара
Отгруженый
товар
A3
Р5
Остатки
учетные
(товарные)
Инвентарный
конроль
А4
Кладовщик
Оператор БД
Р6
Оборотная
ведомость
движения
товаров
Ведомость
инвентаризации
Товар на складе
М1
АРМ работника
склада
Менеджер по
инвентаризации
15

16. Функционально-ориентированное проектирование

Диаграммы переходов состояний моделируют поведение системы
во времени в зависимости от происшедших событий (нажатая клавиша,
дата отчетного периода и т.д.).
Ожидание выбора
пункта меню АРМ
работника склада
Пункт
меню
«Приход»
Пункт
меню
«Расход»
Пункт
меню
«Инвентаризация»
Оформление
прихода товаров
Оформление
расхода товаров
Проведение
инвентарного
контроля
Данные о
приходе
Данные об
инвентаризации
Данные о
расходе
a
b
c
Дата
закрытия
периода
d
a!b!c!d
Ведение базы
данных «Движение
товаров»
16

17. Функционально-ориентированное проектирование

Диаграммы
инфологических
моделей
«сущность-связь»
(ER-диаграммы)
ориентированы на разработку базы данных, структура которой не зависит от конкретных
информационных потребностей и позволяет выполнять любые запросы пользователей.
Материал - деталь
ЧТС - рабочий
Профессия - ЧТС
grade
kod_p (FK)
kod_p
name_p
DETAIL
MATERIAL
kod_w
kod_d
kod_m
fio
child
grade (FK)
kod_p (FK)
name_d
norm_t
wage_ob
kod_m (FK)
kol_m
name_m
cost
pnceuse
WORKER
RATES
PROFESSION
tanff
Рабочий - простой
Рабочий - работа
Деталь - работа
WORK
IDLING
data_id
kod_w (FK)
Nlup
kol_id
pay_id
data_r
kod_w (FK)
Nn
Rank
kol_d
kol_hour
overtime
night_h
wage_r
volume_r
kod_d (FK)
Рабочий - брак
WASTE
Деталь - брак
data_id
kod_w (FK)
Naob
kol_b
uder_b
kod_d (FK)
17

18. Функционально-ориентированное проектирование

Диаграмма структуры программного приложения задает взаимосвязь
функций и программных модулей, которые их реализуют: меню, формы,
отчеты и т.д.
Организация
товародвижения на
складе
Приемка
товара
Отпуск товара
Ведение
базы данных
«движение
товаров»
Инвентарный
контроль
PRIXOD
DOKUM
INSERT
VED
SPRAV
DELETE
EDIT
VIEW
18

19. Объектно-ориентированное проектирование

Структурная
декомпозиция
ИС
на
основе
объектноориентированного
подхода
отличается
от
функциональноориентированного
подхода
лучшей
способностью
отражать
динамическое поведение системы в зависимости от возникающих
событий.
Модель проблемной области - совокупность взаимодействующих во
времени объектов.
Конкретный процесс обработки информации формируется в виде
последовательности взаимодействий объектов.
Одна операция обработки данных может рассматриваться как результат
одного взаимодействия объектов.
Результат: множество классов объектов с присоединенными методами
обработки атрибутов.
Объектно-ориентированный
подход
моделирование данных и процессов.
предполагает
совместное
19

20. Объектно-ориентированное проектирование

Система объектно-ориентированных моделей в соответствии с нотациями
UML включает в себя следующие диаграммы:
1.
2.
3.
4.
5.
6.
7.
8.
Диаграмму прецедентов использования (Use-case diagram).
Диаграмму классов объектов (Class diagram.
Диаграммы состояний (State chart diagram).
Диаграммы взаимодействия объектов (Interaction diagram).
Диаграммы деятельностей (Activity diagram).
Диаграммы пакетов (Package diagram).
Диаграмму компонентов (Component diagram.
Диаграмму размещения (Deployment diagram).
20

21. Объектно-ориентированное проектирование

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

22. Объектно-ориентированное проектирование

Диаграммы классов объектов отображают статическую структуру классов объектов. Эта
диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов
объектов, статические связи объектов.
Продукт
1
- Код продукта: Численный
- Название продукта: Строковый
- Цена: Денежный
1
Клиент
0...*
1
Запас
Заказ клиента
- Код продукта: Численный
- Текущий запас: Численный
- Порог: Численный
- Минимум: Численный
- Статус: Статус
+ Уменьшение запаса()
+ Увеличение запаса()
+ Анализ запаса()
1
0...*
- Код клиента: Численный
- Название: Строковый
- Адрес: текстовый
- Код клиента: Численный
- Дата: Дата
1
*
Строка заказа
- Код клиента: Численный
- Код продукта: Численный
- Количество: Численный
+ Создание строки заказа()
+ Уничтожение()
+ Выполнение()
+ Откладывание()
+ Оформление()
Корпоративный клиент
Частный клиент
- Расчетный счет: Банковский счет
- ФИО руководителя: Строковый
- ФИО бухгалтера: Строковый
- Лицевой счет: Банковский счет
22

23. Объектно-ориентированное проектирование

Диаграмма состояний отображает поведение объектов одного класса в динамике, связь
состояний объектов с событиями и определяет:
какие типичные состояния проходит объект;
какие события ведут к изменению состояния объекта;
какие действия объект выполняет, когда он получает сообщение об изменении состояния;
как объекты создаются и уничтожаются (входные и выходные точки диаграммы).
Продукт
1
- Код продукта: Численный
- Название продукта: Строковый
- Цена: Денежный
1
Клиент
0...*
1
Запас
Заказ клиента
- Код продукта: Численный
- Текущий запас: Численный
- Порог: Численный
- Минимум: Численный
- Статус: Статус
+ Уменьшение запаса()
+ Увеличение запаса()
+ Анализ запаса()
1
0...*
- Код клиента: Численный
- Название: Строковый
- Адрес: текстовый
- Код клиента: Численный
- Дата: Дата
1
*
Строка заказа
- Код клиента: Численный
- Код продукта: Численный
- Количество: Численный
+ Создание строки заказа()
+ Уничтожение()
+ Выполнение()
+ Откладывание()
+ Оформление()
Корпоративный клиент
Частный клиент
- Расчетный счет: Банковский счет
- ФИО руководителя: Строковый
- ФИО бухгалтера: Строковый
- Лицевой счет: Банковский счет
23

24. Объектно-ориентированное проектирование

В диаграмме взаимодействия объектов отображается последовательность взаимодействий между
объектами, которая отображается в виде стрелки между объектами, которая соответствует событию или
сообщению от одного объекта к другому, вызывающему выполнение метода, реагирующего на событие
(сообщение) объекта. Номер стрелки соответствует номеру события в последовательности.
5.3 Информирование об отложенном заказе
6.1 Удаление заказа
2.1 Ввод данных
Экранная форма
«Заказ»
Экранная форма
«Отложенный заказ»
Кнопка «Удалить»
6.2 Уничтожение
2.2 Оформление
Менеджер
по продажам
5.2 Вывод информации о
недостаточности запаса
1.1 Формирование
заказа
1.2 Создание
строки заказа
Кнопка «Формировать
Заказ"
3.1 Анализ запаса
4.2 Уменьшение запаса
Строка заказ-клиент
4.1 Выполнение
5.1 Откладывание
3.5 Подтверждение заказа
на закупку
Кнопка «Подтвердить
заказ на закупку»
3.2
Создание
заказа на
закупку
3.6 Выполнение
заказа на закупку
Запас
3.7 Увеличение
запаса
Заказ на закупку
3.3 Вывод информации
о заказе на закупку
3.4 Информирование о
заказе на закупку
Менеджер
по закупкам
Экранная форма
«Заказ на закупку»
24

25. Объектно-ориентированное проектирование

Диаграмма деятельностей может отражать взаимодействие объектов из нескольких
прецедентов использования, в частности реализующих отдельно стандартные и
альтернативные пути обработки объектов.
Кнопка
«Формировать
заказ»
Формирование заказа
Менеджер по продажам
Кнопка
«Удалить»
Экранная
форма
«Заказ»
Строка
заказ-клиент
Запас
Заказ на
закупку
Экранная
форма «Заказ
на закупку»
Кнопка
Менеджер по закупкам
«Подтвердить
на закупку»
Создание строки заказа
Ввод данных
Оформление
Анализ
запаса
Создание
заказа на
закупку
Вывод
информаци
и о заказе
на закупку
Информирование о заказе на
закупку
Выполнение заказа на
закупку
Подтвержде
ние заказа
на закупку
Увеличение
запаса
Уменьшени
е запаса
Выполнение
25

26. Объектно-ориентированное проектирование

Диаграмма пакетов позволяет описать распределение классов по пакетам.
Пользовательский
интерфейс
БДинтерфейс
Проблемная
область
Продажа
Закупка
Запасы
26

27. Объектно-ориентированное проектирование

Диаграммы компонентов и размещения отображает зависимости программных
компонентов и топологию расположения компонентов по узлам вычислительной сети.
АРМ отдела продаж
Пользовательский
интерфейс отдела
продаж
Клиентская часть
отдела продаж
Сервер БД
Сервер приложений
Объектная база
данных
Приложение
«Продажа»
Приложение
«Запасы»
Приложение
«Закупки»
27

28. Прототипное проектирование (RAD-технология)

Одним из условий обеспечения высокого качества создаваемых ИС является
активное вовлечение конечных пользователей в процесс разработки
предназначенных для них интерактивных систем, что нашло отражение в
методологии прототипного проектирования. Ядром этой методологии является
быстрая разработка приложений RAD (Rapid Application Development).
Данная технология обеспечивает создание на ранней стадии реализации
действующей интерактивной модели системы, так называемой системыпрототипа, позволяющей:
наглядно продемонстрировать пользователю будущую систему,
уточнить его требования,
оперативно модифицировать интерфейсные элементы:
формы ввода сообщений,
меню,
выходные документы,
структуру диалога,
состав реализуемых функций.
28

29. Прототипное проектирование (RAD-технология) Основные возможности и преимущества

Быстрая разработка
Макрокоманды
Повторное
использование
Более низкая
стоимость
Автоматизированные
инструменты
Более высокое
качество
Вовлечение
пользователей
Лучшее
удовлетворение
требований
пользователей
Меньшая стоимость сопровождения
29

30. Прототипное проектирование (RAD-технология)

Приемы для быстрой разработки приложений RAD :
1. Разработка приложения итерациями.
2. Необязательность полного завершения работ на каждом из этапов жизненного
цикла для начала работ на следующем.
3. Обязательное вовлечение пользователей в процесс проектирования и
построения системы.
4. Высокая параллельность работ.
5. Повторное использование частей проекта.
6. Необходимое применение CASE-средств, обеспечивающих техническую
целостность на этапах анализа и проектирования.
7. Применение средств управления конфигурациями, облегчающее внесение
изменений в проект и сопровождение готовой системы.
8. Использование автоматических генераторов (мастеров).
9. Использование прототипирования, позволяющего полнее выяснить и
удовлетворить потребности конечного пользователя.
10.Тестирование и развитие проекта, осуществляемые одновременно с
разработкой нескольких версий прототипа.
Главная задача – как можно быстрее показать пользователям системы
работоспособный продукт, тем самым активизируя процесс уточнения и
дополнения требований.
30

31. Прототипное проектирование (RAD-технология)

Инструментальные средства
разделить на два класса:
Прототипного
можно
условно
инструменты быстрой разработки приложения в развитых СУБД - класс
DEVELOPER и
интегрированные инструменты быстрой разработки приложений - класс
BUILDER.
К инструментам этих классов
компонентов приложений):
проектирования
генераторы
генераторы
генераторы
генераторы
генераторы
можно
отнести
средства
4GL (генераторы
таблиц базы данных;
форм ввода-вывода;
запросов;
отчетов;
меню.
31

32. Прототипное проектирование (RAD-технология)

Жизненный цикл создания ИС на основе RAD-технологии предполагает после
формирования технического задания и декомпозиции системы независимую
разработку подсистем с последующей сборкой, тестированием и внедрением
комплексной ИС.
Разработка ТЗ
Разбиение системы на подсистемы
Независимая разработка
подсистем по методологии RAD
Сборка и совместное
тестирование
Внедрение
Подсистема 1
Подсистема 2
Подсистема 3
...
Подсистема N
32

33. Прототипное проектирование (RAD-технология)

Существуют два базовых варианта организации технологического процесса проектирования с
использованием систем-прототипов.
U1
В первом варианте создание системыпрототипа используется для лучшей
спецификации требований к разработке
ЭИС, после разработки которых сам
прототип
оказывается
ненужным.
Основным недостатком этот варианта
является неэффективное использование
системы-прототипа, а именно: прототипы
не используются в дальнейшей разработке
ИС после того, как выполнили свою
первую задачу – устранили неясности в
проекте.
Д1
Д2
П1
Разработка
постановки
задачи
П2
Д3
Разработка
системы
прототипа
Д4
Доработка
системы
прототипа
П3
Демонстрация
работы прототипа
П4
Д5
П5
Разработка новой
постановки
задачи
G1
G2
U1
П6
Д6
Разработка
приложения
G3
U2
33

34. Прототипное проектирование (RAD-технология)

Второй
вариант
предполагает
итерационное
развитие
системыпрототипа в готовый для эксплуатации
программный продукт.
Итерации разработки системы-прототипа
включают:
создание/модификацию системы-прототипа,
ее
демонстрацию
пользователю
и
согласование,
разработку новых спецификаций-требований
к системе,
новую модификацию и т.д., пока не будет
создано готовое приложение.
Основным достоинством прототипной
технологии
является
значительное
снижение объема доработок ИС при ее
внедрении, который для традиционных
методов проектирования, как показывает
опыт,
соразмерен
с
затратами
на
первоначальную реализацию.
Д1
П1
Разработка
системы
прототипа
Д2
П2
Демонстрация
работы прототипа
G1
U1
U1
П3
Д4
Д5
Доработка
системы
прототипа
G2
П4
Разработка
новых
спецификаций,
требований
Д6
Д7
П5
Документирование
готового
приложения
G3
34