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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве инструмента моделирования будет использоваться 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) содержат классы и их связи. Связи (ассоциации) между классами изображаются двунаправленными соединительными линиями;

* диаграммы объектов (object diagrams) изображают различные объекты системы и их взаимосвязи;

* диаграммы ВИС (use case diagrams) показывают набор функций, который система предоставляет внешним объектам;

* диаграммы компонентов (component diagrams) отображают представление реализации системы. Она содержит различные компоненты системы и их взаимосвязи, такие, как исходный код, объектный код и исполняемый код;

* диаграммы развертывания (deployment diagram) показывают соответствие программных компонентов узлам физической реализации системы;

* диаграммы коллективного взаимодействия (collaboration diagrams) представляют собой набор классов и отправляемых и принимаемых ими сообщений;

* диаграммы последовательностей (sequence diagrams) описывают взаимодействие между классами -- посдедовательность сообщений, которыми обмениваются классы;

* диаграммы состояний (state diagrams) описывают поведение класса в моментобращения к нему внешнего процесса или объекта. Она отображает состояния и ответные сигналы класса при выполнении действия.

2. Создание общей картины решения

2.1 Общие сведения

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

Конечно, информация приобретается из двух основных источников:

· существующая - имеющаяся в учреждении;

· информация из различных видов опросов служащих.

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

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

Наиболее распространенными формами опроса есть:

· структурированный;

· полуструктурированный;

· групповые обсуждения и встречи;

· анкеты.

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

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

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

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

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

В соответствии с основными стратегическими целями МЭСИ и его текущими задачами отдел маркетинга региональной структуры в своей повседневной деятельности обязан реализовывать следующие основные задачи:

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

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

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