* Определение структуры проекта -- определение административной структуры проектной команды и стандартов управления проектом.

* Определение бизнес-целей -- анализ бизнес-задачи и возможностей для выявления целей создания продукта.

* Оценка существующей ситуации -- анализ текущего состояния и оценка разрыва между реальным и ожидаемым положением дел. Цель подобного анализа -- сформулировать перечень задач и определить направление развития проекта.

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

* Определение требований и профилей пользователей -- определение всех заинтересованных сторон, конечных пользователей и спонсоров проекта, а также документирование их требований к решению. Эта информация помогает «набросать» черновик обшей картины и границ проекта, а также создать концепцию решения.

* Разработка концепции решения -- создание базовой концепции решения, то есть «костяка» решения, которое станет основой будущего продукта. Концепция создается на основе собранных требований.

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

* Закрытие этапа создания обшей картины решения -- завершение этапа, которое подтверждается документом обшей картины и области действия решения, одобренным всеми заинтересованными лицами и проектной командой

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

Общая картина и область действия решения:

· формулировка задач и бизнес-целей;

· анализ существующих процессов;

· наиболее общее определение требований пользователей;

· профили пользователей, определяющие, кто будет работать с продуктом;

· документ общей картины и определение области действия;

· концепция решения, описывающая способ планирования проекта;

· стратегии проектирования решения.

Структура проекта:

· описание всех ролей команд MSF и списки членов команд;

· структура проекта и стандарты процессов, которых должна придерживаться команда.

Оценка риска:

· предварительная оценка риска;

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

· планы устранения или снижения влияния выявленных рисков.

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

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

После сбора и анализа требований команда создает проект решения. Создаются профили, которые определяют пользователей продукта и их роли и обязанности. Затем команда формирует сценарии использования системы. Сценарий использования системы (СИС) -- это описание процесса, выполняемого пользователями определенного типа. Команда создает отдельные СИС для всех пользовательских профилей. Затем формируются варианты использования системы (ВИС), которые определяют последовательность шагов, выполняемых пользователем в СИС.

Этап планирования состоит из трех стадий.

* Концептуальный дизайн. Задача рассматривается с точки зрения пользовательских и бизнес-требований и определяется в виде сценариев использования системы.

* Логический дизайн. Задача рассматривается с точки зрения проектной команды, и решение определяется как набор сервисов.

* Физический дизайн. Задача рассматривается с точки зрения разработчиков (программистов). На этой стадии уточняются технологии, интерфейсы компонентов и сервисы решения.

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

Процесс разработки

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

* Начало цикла разработки. Команда проверяет выполнение всех задач, характерных для этапов создания общей картины решения и планирования, и готовится к началу разработки продукта.

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

* Разработка компонентов решения. Разработка основных компонентов решения и их адаптация в соответствии с потребностями решения.

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

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

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

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

После развертывания команда выполняет анализ проекта и проводит опрос, чтобы выяснить уровень удовлетворен кости заказчика. Этап развертывания завершается контрольной точкой «Решение развернуто».

В качестве инструмента моделирования будет использоваться UML (Unified Modeling Language) - стандартный язык, применяемый для моделирования информационных систем различной сложности -- от крупных корпоративных ИТ-систем до распределенных систем, основанных на Web [5].

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

* визуализации программной системы набором строго определенных символов. Разработчик приложения может однозначно интерпретировать UML-модель, созданную другим разработчиком;

* описания спецификаций информационной системы. UML помогает строить точные, однозначные и полные модели;

* конструирования моделей ИТ-системы, которые могут напрямую преобразовываться в текст на различных языкам программирования;

* документирования моделей программной системы, выражая требования к системе на стадиях разработки и развертывания

Основные черты UML:

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

* состоит из набора нотаций и правил моделирования программных систем различной степени сложности;

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

* не зависит как от языка программирования, так и от платформы.

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

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

* Пользовательское представление (user view) выражает цели и задачи системы с точки зрения пользователей и их требований к системе. Это представление относится к части системы, с которой взаимодействует пользователь. Пользовательское представление также называют представлением в виде набора диаграмм UseCase

* Структурное представление (structural view) отражает статическое или нерабочее состояние системы. Его также называют представлением дизайна (designview).

* Представление поведения (behavioral view) отражает динамическое или изменяющееся состояние системы. Его иногда называют представление процессов (process view).

* Представление реализации (implementation view) представляет структур} логических элементов системы.

* Представление окружения (environment view) отражает распределение физических элементов системы. Окружение системы определяет ее функции с точки зрения пользователей. Представление окружения также называют представлением развертывания (deployment view).

Различные UML-представления содержат диаграммы, показывающие разрабатываемое решение с различных точек зрения. Не обязательно разрабатывать диаграммы для каждой создаваемой системы, но вы должны уметь разбираться в представлениях системы и соответствующих UML-диаграммах. Также, не обязательно использовать все диаграммы для моделирования системы. Следует выделить лишь те модели, которые позволят успешно смоделировать систему.

Применяются следующие UML-диаграммы для изображения различных представлений системы:

* диаграммы классов (class diagrams) содержат классы и их связи. Связи (ассоциации) между классами изображаются двунаправленными соединительными линиями;

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10