Вопрос 3. Постановка задачи. Оценка осуществимости.

Обычно заказчик выдаёт две-три страницы текста задания и сразу же просит оценить время исполнения заказа и его стоимость. Надо быть сумасшедшим, чтобы с этим согласиться. Не редки случаи, когда целые коллективы ошибаются в пять-десять раз и попадают в кабалу или теряют профессиональную репутацию. Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор на две-четыре недели, с тем, чтобы два-три системных аналитика разобрались в задаче, с помощью каких-то инструментальных средств выполнили декомпозицию системы на компоненты, прикинули возможные объёмы этих компонент и, соответственно, время их реализации. Такая начальная стадия ЖЦП называется "оценкой осуществимости".

Постановка задачи – наиболее творческая часть ЖЦП, которая содержит в себе почти что философские проблемы.

Надо описать поведение разрабатываемой системы. Эта система получает какие-то сигналы из её окружения, поэтому вам надо описать поведение окружения, но окружение само зависит и изменяется под влиянием системы, её сигналов, особенно аварийных.

Разрешают это противоречие с помощью постепенного уточнения поведения, как системы, так и её окружения (т.е. делают декомпозицию).

Декомпозицию необходимо производить обязательно – лишь она позволяет вычислить более-менее реальные сроки реализации.

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

Например, в технологии REAL разработчикам предлагается использовать следующие типы моделей:

1. Диаграмма случаев использования, в которой описываются интерфейсы системы с внешним миром и основные функции системы, которые за эти интерфейсы отвечаю.

2. Диаграмма функций – для каждой основной функции рисуется дерево более мелких функций.

3. Диаграмма объектов, в которой задаётся разбиение системы на независимые объекты, каждый из которых имеет свой алгоритм поведения и локальные данные, необходимые для исполнения алгоритма. Для реализации всей системы, возможно, понадобится много экземпляров однотипных объектов, но в диаграмме объектов рисуются только типы конфигурации экземпляров объектов и их связей.

4. Диаграмма классов. В этой диаграмме на основании рассмотрения различных вариантов диаграмм объектов фиксируются типы объектов, которые могут служить основой для генерации многих экземпляров объектов. Соотношение между классом и объектом в точности такое же, как соотношение между типом и значением в языках программирования. Например, real – это тип, а 3.14 и 2.72 – примеры значений этого типа. В диаграмме классов используются мощные выразительные средства (наследование, агрегирование и т.п.), позволяющие минимизировать диаграмму, повышая тем самым её наглядность.

//1-2 – Пользовательская модель

//3-4 – Структурная модель

//1-4 – все это есть в UML, но в UML нет временнЫх моделей. Можно рассмотреть рекомендацию z.120 (ITU): рисуем вертикально время, нити процессов, сообщения. Полезна также STD диаграмма конечных автоматов (состояния; переходы - по сообщениям) – позволяет специфицировать поведение отдельных объектов. Есть также рекомендация z.100 – SDL диаграмма (обычная блок схема, но с сообщениями (прием + отправка)) – позволяет изображать параллельные процессы, а также избежать ошибок при взаимодействии модулей (когда послали сообщение, а его не ждут). Постановка задачи выдает два документа – 1. четкая спецификация + 2. распределение по времени.