Методология SADT (Structured Analysis and Design Technique) представляет собой набор правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

Система SADT имеет три уровня:

1. Функциональная модель.

2. Информационная модель.

3. Динамическая модель.

SADT включает в себя следующие процессы:

1) Сбор информации и анализ информации о предметной области.

2) Документирование полученной информации.

3) Моделирование (IDEFO).

4) Корректура модели в процессе итеративного рецензирования.

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

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

Достоинство методологии SADT - это простота и наглядность. Недостатком методологи SADT является неосуществимость описания процесса изменчивости реакции на изменчивости среды.

В методологии RAD (Rapid Application Development) быстрая разработка приложений достигается благодаря использованию компонентно-ориентированного конструирования и применяется при наличии следующих условий:

· Бюджет проектируемой информационной системы ограничен.

· Нечётко определены требования к информационной системе.

· Требуется реализация проекта информационной системы в минимальные сроки.

· Интерфейс пользователя можно продемонстрировать в прототипе.

· Проект можно разделить на элементы по функциональному назначению.

Методология RAD имеет следующие этапы:

1) Моделирование информационных потоков между бизнес-функциями.

2) Моделирование данных.

3) Преобразование объектов данных, обеспечивающих реализацию бизнес-функций.

4) Генерация приложений.

5) Тестирование и объединение.

Недостатки методологии RAD:

· Для больших информационных систем необходима большая группа разработчиков.

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

· Не используется в случае применения новых технологий.

Применение RAD:

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

· RAD можно использовать только для приложений, делящихся на отдельные модули, и в которых производительность не является важным критерием;

· RAD не используется в условиях технического риска.

Технология RAD обеспечивает максимально короткий цикл разработки информационных систем. При полностью определённых условиях и ограниченной проектной области технология RAD позволяет создать целиком функциональную систему за очень короткое время (от шестидесяти до девяноста дней). Выделяют следующие стадии разработки информационных систем с использованием технологии RAD:

a) Бизнес-моделирование. Между бизнес-функциями моделируется информационный поток. Определяются ответы на следующие вопросы:

1) Какая информация руководит бизнес-процессом;

2) Какая информация генерируется;

3) Кто обрабатывает информацию;

b) Моделирование обработки. Определение преобразования объектов данных, обеспечивающих реализацию бизнес-функций. Создание описания обработки для добавления, модификации, удаления или нахождения (редактирования) объектов данных;

c) Генерация приложения. Предполагается использования методов, ориентированных на языки программирования четвёртого поколения. Вместо создания программного обеспечения с помощью языков программирования третьего поколения, процесс RAD работает с повторно используемыми программными компонентами или создаёт повторно используемые компоненты. Чтобы обеспечить конструирование используются утилиты для автоматизации (средства Computer-Aided Software Engineering, CASE);

d) Тестирование и объединение. Так как применяются повторно используемые компоненты, многие компоненты программ уже протестированы, что уменьшает время тестирования (однако все новые элементы должны быть протестированы).

Методология RUP (Rational Unified Process) - это процесс, направленный на поддержку групповой разработки программных средств. Все участвующие в проекте используют единую базу знаний, единый процесс, единый взгляд на разработку, единый язык моделирования. RUP разрабатывается совместно с Unified Modeling Language (унифицированный язык моделирования) - промышленным стандартом объектно-ориентированного моделирования той же группой разработчиков. RUP - это технологический процесс по созданию программного средства, позволяющий улучшить производительность коллективной разработки путём предоставления для всех этапов жизненного цикла методик выполнения основных видов деятельности, шаблонов документов, инструкций по работе с инструментальными средствами.

Достоинства RUP:

· Это итеративный процесс (Controlled Interactive);

· Предполагает сквозное применение аппарата Use Cases (Use Case Driven);

· Особое внимание уделяется разработке архитектуры (Architecture Centric);

· Включает управление требованиями и изменениями (Requirements Configuration and Change Management);

· Опирается на компонентно-базированную концепцию разработки программных средств (Component Based Development).

· Базируется на визуальном моделировании (Visual Modeling Techniques).

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

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

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

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

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

1.2 Методы и средства проектирования баз данных для информационной системы