Наименование этапа

Основные действия

Результаты

Выявление сущности требований к программному продукту (концептуализация)

1) определить цели апробации концепции и критерии того, что считать благополучным исходом;

2) собрать подходящую команду для разработки прототипа;

3) оценить готовый прототип и принять ясное решение о проектировании конечного продукта или о дальнейшем исследовании. Решение о начале разработки конечного продукта нужно принимать с разумным учетом потенциального риска, выявленного при апробации концепции.

Первичными продуктами концептуализации являются прототипы системы.

Разработка модели требуемого поведения системы (анализ)

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

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

3) если необходимо, сделать описания поведения системы в исключительных ситуациях;

4) для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат);

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

6) внести изменения в словарь данных; включить в него новые классы и объекты, выявленные для каждого сценария, вместе с описанием их ролей и обязанностей.

Результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов

Побочным результатом анализа будет оценка риска: выявление опасных мест, которые могут повлиять на процесс проектирования.

Создание архитектуры для реализации (проектирование).

Архитектурное планирование - охватывает логическую декомпозицию, состоящую в группировании классов, и физическую декомпозицию, состоящую в разбиении на модули и назначении заданий процессорам

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

2) проверить архитектуру созданием действующих релизов, которые частично удовлетворяют семантике нескольких важнейших сценариев, предоставленных анализом;

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

Диаграммы классов и объектов.

Создание архитектуры для реализации (проектирование).

Тактическое проектирование состоит в принятии решений о множестве общих приемов

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

2) для каждого приема составить сценарий, описывающий его семантику. Затем выразить ее в виде исполнимого прототипа, который может быть уточнен и представлен инструментально;

3) документировать каждый принцип и распространить полученные документы, чтобы обеспечить единое архитектурное видение.

Диаграммы классов и объектов

Описания семантики. Сценарии

Создание архитектуры для реализации (проектирование).

Программные релизы закладывают основы архитектурной эволюции системы.

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

2) распределить функциональные точки по релизам так, чтобы последний релиз в серии представлял результирующую систему;

3) определить цели и расписание релизов так, чтобы дать время на разработку и синхронизировать релизы с другими действиями, например, с разработкой документации и полевыми испытаниями;

4) начать планирование задач, учитывая критические места проекта и ресурсы, отведенные на выпуск каждого релиза.

Программные релизы.

План, в котором определены расписание работ, задачи коллектива и оценка риска.

Итеративное выполнение реализации (эволюция);

1) определить функциональные точки, которые попадут в новый релиз, и области наивысшего риска, особенно те, которые были выявлены еще при эволюции предыдущего релиза;

2) распределить задачи по релизам среди членов команды и начать новый микропроцесс. Контролировать микропроцесс, просматривая проект, и проверять состояние дел в важных промежуточных этапах с интервалами от нескольких дней до двух недель;

3) когда потребуется понять семантику требуемого поведения системы, поручить разработчикам сделать прототип поведения. Четко установить назначение каждого прототипа и определить критерии готовности. После завершения решить, как включить результаты прототипирования в этот или последующие релизы;

4) завершить микропроцесс интеграцией и очередным действующим релизом.

Серия исполняемых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели.

Описание поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа системы

Управление эволюцией продукта в ходе эксплуатации (сопровождение).

1) упорядочить по приоритетам предложения о крупных изменениях и сообщения об ошибках, связанных с системными проблемами, и оценить стоимость переработки;

2) составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции;

3) если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения;

4) приступить к разработке следующего эволюционного релиза программы.

Список новых заданий: обнаруженные дефекты и новые требования.