Фаза "Анализ". Выработка единой концепции проекта для всех его участников, страница 2

Формируется  перечень характеристик продукта.- (не функциональные требования)

Формируются проектные требования.(то есть что надо иметь чтобы реализовать бизнес требования)

Строяться схемы использования и другие функциональные модели(уже! но Обращается внимание на функции-требования, про роли-внешние сущности пока ничего пока)

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

То же самое с аппаратным обеспечением.

Шаг 3 Рационализация

уточняться требования, характеристики

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

(Обслуживание покупателей, Ввод документов,  редактирование, обслуживание заказов)

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

Если характеристика не вписывается ни в один из классов, она, вероятно, не так важна для текущего выпуска.

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

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

Шаг 4 Реализация

Определяются приоритеты наборов  характеристик то есть какие из них в первую очередь реализованы будут.

Выявляются те которые будут реализованы в версии, какие в последующих

Предварительная концепция проекта .

Предварительный график проекта

Шаг 5 Утверждение

Одобрение концепции как основной этап фазы анализ

Для достижения этого этапа необходимы четыре документа:

 «Концепция», где описан разрабатываемый продукт, решаемые им адачи, его характеристики и предварительный график;

 «Структура проекта», где описаны распределение ролей в проектной группе и области ответственности каждой роли;

«Основной документ оценки рисков», где перечислены риски проекта и описаны методы управления ими.

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

 прототип приложения,.

Цель этих документов — обеспечить эффективный обмен информацией

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

Концепция как документ

Концепция (документ)

Документ, описывающий концепцию, должен включать, по крайней мере:

Краткую формулировку концепции

 Это краткая формулировка цели проекта (цель проекта)- одно (два ) предложени в котором указываеться

Что конкретно будет сделано

Для каких целей

Для каких условий

Примерные сроки

(Разработка ИС ведения документооборота кафедры ИиАПС в течении 2 месяцев)

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

Контекст (Для каких условий заказчика)

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

Существующей схемы развертывания. На уровне общей характеристики

Масштаб, состав(типовые элементы), существующие связи.

 (….RUP )

Результаты исследования требований пользователей;

Требования необх  структурировать, снабдив каждое из них

Ÿ  кратким названием

Ÿ  описанием,

Ÿ  статусом (предложение, принято, включено в окончательный список и т. п.),

Ÿ  оценкой стоимости реализации

Ÿ  описанием рисков, сопряженных с выполнением этого требования.

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

Ÿ  производительность,

Ÿ  расширяемость и

Ÿ  надежность.

(….из RUP.)

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

(Обслуживание покупателей, Ввод документов,  редактирование, обслуживание заказов)

Обоснование  необходимости разработки конкурентоспособности решения;

приоритеты  (ими будут руководств при выборе решений)

Какие из характеристик (функциональных и нет) приоритетны, какие нет (оптимизация, ограничение, как получиться)

Интеграция (дополнять концепции и функц возможности др. продуктов) (то есть где то должен быть контекст, условия проектирования)

Будущие инвестиции

Базовую концепцию бизнес-решения; (технологии приблизительная архитектура) То есть намечены должны быть какие технологии применяют

приблизительный график.

Структура проекта (документ)

Концепция описывает, что именно будет сделано, а структура проекта — кто будет это делать. Этот документ определяет:

o   каждую роль в группе;

o   кто отвечает за каждую роль;

o   состав групп и контактную информацию;

o   организаторов проекта:

o   методы управления проектом — например, системы контроля и виды отчетности;

o   связанные с проектом графики, адреса электронной почты и Webузлы.

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

Сводный документ оценки рисков

Важным результатом этапа «Одобрение концепции» является сводный документ оценки рисков, который содержит

перечень основные рисков (классифицированы основные риски и приведены их описания),

 их оценки и

 планы управления ими(ответственных за осуществление этих планов.)

СОДЕРЖАНИЕ ФАЗЫ АНАЛИЗ(роль различных ролей группы)

	Менеджер продукта	Менеджер программы	Разработчик	Инструктор	Тестер	логистик
Выявление требований	Работа с заказчиком		**** и их взаимосвязи?	****** Касаемо удобства
Формулировка целей проектирования		Формулировка целей проектирования
Формулировка критериев приемки продукта					**********
Концепция решений		*********
Основные направления разработки (технологии)			*********
Структура продукта предворит архитектура		**********
Разработка прототипов	Привлечение заказчика	Наверное да?	**********	Привлечение пользователя
Управление рисками	*******	**********	*********	**********	Разработка *******
Разработка стратегии тестирования					*****
Вопросы развертывания и их влияния на проект (анализ условий?)	**?	**?	**?			*********
Вопросы сопровождения						*******