25. Задачи фазы развития унифицированного процесса и планирование итераций на этой фазе проектирования

Фаза развития – первая последовательность итераций, в течении которой решаются следующие

задачи:

1. Реализуются и тестируются базовые архитектурные элементы.

2. Изучаются и стабилизируются большая часть требований.

3. Обосновываются и устраняются основные риски.

Фаза развития не является стадией проектирования или подготовки к реализации, как это имеет

место быть в рамках каскадного процесса. На этой стадии создаются не прототипы, а полностью

разрабатывается некоторый фрагмент системы (фрагменты).

Требования и итерации систематизируются в соответствии с рисками, границами и критичностью.

Риск – техническая сложность или другой фактор, например, отсутствие информации о

необходимых затратах или ресурсах.

Границы – определяются все основные части системы.

Критичность – этот параметр говорит о том, что в первую очередь реализуются те функции, которые имеют важное значения для системы.

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

или их отдельные сценарии ранжируются с целью определения приоритетов при реализации. На

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

состоит из 2-4 итераций длительностью от двух до шести недель каждая. Время каждой итерации

жестко фиксируются. Время жестко фиксируется так, чтобы к ее завершению был получен

устойчивый протестированный код. Если некоторые требования не укладываются в сроки

итерации, то они могут быть перенесены на следующую итерацию.

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

26. Моделирование предметной области и основные понятия модели предметной области

Модель предметной области. (МПО)

Модель предметной области отображает основные с точки зрения моделирующего

концептуальные классы понятий предметной области. Каждой итерации соответствует своя модель

предметной области, отражающая реализуемый на данном этапе сценарий прецедентов. Таким

образом МПО эволюционирует в процессе разработки системы. Модель предметной области

связано с моделью проектирования. Особенно программными объектами, относящимися к уровню

предметной области.

Основные понятия МПО отображаются в словаре терминов.

Модель предметной области отображает классы понятий реального мира, а не программные

компоненты. На языке UML модель предметной области представляется в виде набора диаграмм

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

отображать следующие:

1. Объекты предметной области или концептуальные классы.

2. Ассоциации между концептуальными классами

3. Атрибуты концептуальных классов.

В модели предметной области не используются:

1. артефакты программирования (окна, БД) (если не программное средство)

2. Обязанности, методы

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

Концептуальный класс – представление идей или объекта. Его можно рассматривать в терминах

символов, содержания и расширения.

1. Символы – слова или образы, представляющие концептуальный класс.

2. Содержание – определение концептуального класса.

3. Расширение – набор примеров, к которым применим этот концептуальный класс.

Концептуальные классы могут вообще не содержать атрибутов и играть в предметной области

чисто поведенческую, а не информационную роль.

Если некоторый объект Х в реальном мире не является числом или текстом, значит это скорее

концептуальный класс, чем атрибут.

Класс описания – содержит информацию о свойствах некоторого объекта.

Класс описания вводится в следующих случаях:

1. Существует необходимость описания элементов или служб, не зависимо от существования

конкретных экземпляров этих объектов.

2. Если удаление экземпляров, описываемых им понятий, приводит к потери важной

информации в связи с некорректной ассоциацией этой информации с удаляемым

экземпляром.

3. Если при наличии понятия устраняется дублирования информации.

28. Понятие системного события и идентификация системных событий

29. Открытый системный интерфейс и описание операций в рамках унифицированного процесса проектирования

30. Проектирование динамической структуры ПО с использованием UML в рамках объектно-ориентированного подхода

31. Средства UML для выражения полиморфных сообщений в контексте проектирования динамической структуры ПО

32. Средства UML для выражения асинхронных вызовов в контексте проектирования динамической структуры ПО

33. Проектирование статической структуры ПО с использованием UML в рамках объектно-ориентированного подхода

34. Средства UML для представления атрибутов коллекций в контексте проектирования статической структуры ПО

35. Признаки существования зависимости между классами в контексте проектирования статической структуры ПО

36. Стадии создания информационной системы в рамках канонического проектирования

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

• обследование объекта и обоснование необходимости создания ИС;

• формирование требований пользователей к ИС;

• оформление отчета о выполненной работе и тактико-технического задания на разработку.

Стадия 2. Разработка концепции ИС.

• изучение объекта автоматизации;

• проведение необходимых научно-исследовательских работ;

• разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

• оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

• разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

• разработка предварительных проектных решений по системе и ее частям;

• разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

• разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;

• разработка и оформление документации на поставку комплектующих изделий;

• разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

• разработка рабочей документации на ИС и ее части;

• разработка и адаптация программ.

Стадия 7. Ввод в действие.

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

• проведение опытной эксплуатации;

• проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

• выполнение работ в соответствии с гарантийными обязательствами;

• послегарантийное обслуживание.