Информационная система «Обитель зла. Корпорация «Umbrella»

Development case

Версия 1.1

Дата

Версия

Описание

Автор

05.06.08

1.0

Начальное описание Development Case информационной системы «Обитель зла».

Гришуль Е., Шафоростов Н.

22.06.08

1.1

Изменён состав дисциплин

Гришуль Е., Шафоростов Н.

1. Введение

1.1 Цель

Целью документа является описание процесса разработки Информационной системы «Обитель зла. Корпорация «Umbrella». Данный документ описывает процесс разработки информационной системы на каждой фазе: Начало, Проектирование, Построение и Внедрение. А также то, как применяется RUP в рамках проекта.

1.2 Ссылки

  • Glossary

  • Software Development Plan

2. Development Case

2.1 Модель жизненного цикла

Цикл разработки состоит из 4 фаз: Начало, Проектирование, Построение и Внедрение. Каждая итерация оканчивается вехой, когда подводятся итоги фазы и проводится пересмотр дизайна и кода, а также заканчивается очередной цикл тестирования и выпускается очередной build.

2.2 Дисциплины

Процесс разработки охватывает восемь дисциплин: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management.

2.3 Состав дисциплины

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

2.3.1 Рабочий процесс

В данном разделе описываются все задачи, выполняемые в рамках данной дисциплины. Эта информация в полной мере отражена в разделе Iteration Plans в документе Software Development Plan.

2.3.2 Артефакты

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

Artifacts

Using

Review Details

Tools Used

Templates/ Examples

Incep

Elab

Const

Trans

Поясним:

Столбец

Описание

Содержимое

‘Artifacts’

Название артефакта

Ссылка на артефакт RUP или специфичный артефакт

‘Using’

Описание того, как артефакт используется в цикле разработки

Для каждой из фаз может иметь одно из следующих значений:

  • Must have (обязательный)

  • Should have (желательный)

  • Could have (создается по необходимости)

  • Won't have (не используется)

‘Review Details’

На каком уровне и как должен пересматриваться артефакт

Возможные уровни:

  • Formal-External

  • Formal-Internal

  • Informal

  • None

‘Tools Used’

Необходимые инструменты для создания артефакта

‘Templates/Examples’

Шаблоны/Примеры артефактов

Ссылки на RUP

2.3.3 Замечания к артефактам

В данном разделе приводятся дополнительные требования к использованию артефактов и причины этих требований (например: когда необходимо создавать или обновлять артефакт).

Artifacts

Using

Reason

2.3.4 Отчёты

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

Reports

Using

Templates/Examples

Tools Used

2.3.5 Замечания к отчётам

Комментарии к пункту 2.3.4.

2.4 Классификация артефактов

Артефакты создаются в рамках одной дисциплины. Они классифицируются по степени необходимости следующим образом:

  • Must – артефакт обязательно должен быть создан или уточнен (изменен) на данной итерации (фазе).

  • Should – создание (изменение) артефакта является желательным на данной итерации (фазе).

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

  • Won't - артефакт не используется (не создается и не изменяется) на данной итерации (фазе).

Соседние файлы в папке информационная система umbrella - документы