1. Предварительный анализ по.

Включает в себя сбор документов, характеризующих ПО, укрупнённое описание ПО (не детализированное) и общую постановку задачи.

В процессе анализа и проектирования желательно ранжировать плани-руемые функции системы по степени важности. Один из возможных вариантов классификации – MoSCoW-анализ (терминология Клегга и Баркера, [8]):

Must have – необходимые функции;

Should have – желательные функции;

Could have – возможные функции;

Won't have – отсутствующие функции

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

Примечание: если применяются средства автоматизации проектирования (CASE-средства), то задачу последовательного внесения изменений берёт на себя это CASE-средство.

2. Рассмотрение и принятие результатов анализа.

Эта задача обычно решается итеративно во взаимодействии проектировщиков и заказчиков (или аналитиков). На этом этапе очень важно определить, что проектировщики правильно понимают описание предметной области и задачи, поставленные перед ними аналитиками. Для этого обычно проводятся совместные семинары, на которых проверяется адекватность модели и предметной области.

Рис. 8.1. Жизненный цикл приложения баз данных

3. Определение критических факторов успеха.

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

4. Оценка системных ограничений.

В качестве часто встречающихся ограничений можно отметить следующие:

• финансовые

• временные

• технические (например, выбор определённой аппаратуры);

• программные (например, выбор определённого программного обеспечения);

5. Определение целевой архитектуры.

Под целевой архитектурой в данном случае понимается архитектура с точки зрения СУБД (однозадачная или многозадачная, архитектура клиент-сервер, параллельный сервер). Выбор архитектуры повлияет в дальнейшем на перечень требуемых аппаратных и программных средств.

6. Определение требований к производительности.

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

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

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

• Режим реального времени. Этот режим является самым сложно реализуемым. В настоящее время (2009 г.) существует только одна СУБД, которая в полной мере отвечает требованиям режима реального времени: СУБД ЛИНТЕР – единственная СУБД отечественного производства (компания РЕЛЭКС, г. Воронеж).