Краткое описание этапов каскадного проектирования.

Каскадная модель проектирования СОД.

Выявление потребностей конечных пользователей.     Концептуальный проект.     Архитектура системы.   Логическое проектирование.     Комплексная отладка.     6. Сопровождение.

Пилотный проект

Краткое описание этапов каскадного проектирования.

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

Пример:

d22=f2(d12,d21)=f2(f1(d11),d21)

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

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

Пример: (Инфологическая модель БД в нотации Чена)

Спецификация процессов - входные и выходные данные процессов, а также алгоритмическая связь между ними. Для описания спецификации существуют различные методы: структурированный естественный язык (часто используется), язык проектирования спецификации Flow-Form (визуальные языки).

Концептуальный проект не зависит от архитектуры!!!

Лекция 2

3. выбор архитектуры:

- Модель доступа к данным

- Комплекс технических средств (выбор «железа»)

- Общесистемные пакеты

-Тиражирование данных

4. логическое проектирование

выполняется отражение концептуального проекта в СУБД-ориентированную среду с помощью выбранных оболочек программирования,

логический проект зависит от архитектуры (можно считать временные характеристики)

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

- проста, естественна, имеет некоторую привязку к ГОСТу

Недостатки:

- достаточно продолжительный цикл разработки по времени (система морально устаревает)

- доработка системы связана с большим объемом перепрограммирования (из-за слабого использования CASE-средств)

Результаты исследований Д.Мартина (сер. 80х)

1я диаграмма: распределение ошибок и просчетов по этапам проектирования, выявленных при сопровождении системы

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

3я диаграмма: распределение трудозатрат по этапам проектирования

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

На основании исследований Мартин сформулировал законы:

1. закон неопределенности в информатике:

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

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

3. программисты и проектировщики не учатся на чужих ошибках, а только на своих

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

2. Объединение разнородных СУБД с помощью шлюзов.