Смекни!
smekni.com

Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ (стр. 2 из 11)

Каждый этап завершается контрольной точкой.

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

На этапе создания общей картины приложения команда решает различные задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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