на тему рефераты Информационно-образоательный портал
Рефераты, курсовые, дипломы, научные работы,
на тему рефераты
на тему рефераты
МЕНЮ|
на тему рефераты
поиск
Модели проектных групп

Модели проектных групп

12

Курсовая работа

на тему: «Модели проектных групп»

Содержание

Введение

1. Модель Microsoft Solutions Framework (MSF)

1.1 Принципы, концепции и методики MSF

1.2 Жизненный цикл MSF

1.3 Обзор модели команды MSF

2. Модель Rational Unified Process (RUP)

2.1 Предназначение RUP

2.2 Жизненный цикл RUP

2.3 Методология RUP

3. Модель Extreme Programming (XP)

3.1 Ориентация, принципы и практика XP

3.2 Методология XP

3.3 Жизненный цикл XP

4. Сравнение технологий MSF, RUP и XP

Заключение

Список использованной литературы

Введение

В настоящее время широкое применение получают так называемые промышленные технологии создания программного продукта. Эти технологии были разработаны фирмами, накопившими большой опыт создания ПО. Технологии представлены описаниями принципов, методов, применяемых процессов и операций. Такие технологии, как правило, поддерживаются набором CASE - средств (Computer Aided System Engineering), охватывают все этапы жизненного цикла продукта и успешно применяются для решения практических задач. Но развитие технологии разработки программного обеспечения, методов моделирования, появление CASE-технологий не решило проблему определения и формализации требований к информационным системам, но способствовало возникновению нескольких основных подходов.

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

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

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

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

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

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

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

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

1. Модель Microsoft Solutions Framework (MSF)

1.1 Принципы, концепции и методики MSF

Существует две основные модели организации коллектива при разработке ПО:

1) иерархическая модель

2) модель группы

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

Недостатки иерархической модели:

· нехватка информации;

· невозможность учесть все особенности проекта;

· отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении -- вверх по иерархии, к главному менеджеру;

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

· сложность расстановки приоритетов.

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

Поэтому для анализа современных решений необходимо использовать модель (рис. 1), представляющую собой иерархию уровней управления процессом разработки ПО [1].

Рис. 1. Иерархия уровней управления процессом разработки ПО

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

Модель группы не определяет структуру коллектива с точки зрения отдела кадров. В такую разностороннюю группу привлечены ресурсы из разных отделов организации. Задача модели проектной группы -- определить цели проекта и распределить обязанности. Руководители каждого направления с помощью выделенных им ресурсов выполняют возложенную на них часть работы. Обязанности ролей определяются работой над проектом, а не деятельностью «штатной единицы». При этом руководители направлений выполняют свои обычные функции: составляют график выплаты премий, распределяют отпуска и контролируют эффективность работы сотрудников. Начальник может оценить степень участия и эффективность работы сотрудников в проектной группе, но это -- прерогатива менеджера, а не проектной группы.

Далее в курсовой работе поочередно будут рассмотрены современные модели проектных групп: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и Extreme Programming (XP).

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь [2].

Microsoft Solutions Framework представляет собой хорошо сбалансированный набор методик организации процесса разработки, который может быть адаптирован под потребности практически любого коллектива разработчиков. MSF содержит не только рекомендации общего характера, но и предлагает адаптируемую модель коллектива разработчиков, определяющую взаимоотношения внутри коллектива, гибкую модель проектного планирования, основанного на управлении проектными группами, а также набор методик для оценки рисков.

MSF предлагает использовать в процессе создания и функционирования проектной группы ряд принципов, концепций и методик:

Основные принципы:

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

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

· концентрация на бизнес-приоритетах - необходимость принятия решений проектной группой на основе полного понимания бизнеса заказчика и при активном его участии в реализации проекта;

· единое видение проекта, формирующего целостный подход проектной группы к разработке IT-решения;

· гибкость, переменчивость - присутствие всех командных ролей и их вовлеченность в процесс принятия решений, обусловленных происходящими переменами;

· поощрение свободного общения - открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами вне ее;

Ключевые принципы:

· команда соратников - равноправное положение каждой из ролей в команде;

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

· нацеленность на конечный результат;

· установка на отсутствие дефектов;

· стремление к самосовершенствованию;

· создание заинтересованности и высокого морального духа команды;

Испытанные методики:

· создание малых многопрофильных проектных групп - большая оперативность действий в сравнении с крупными коллективами;

· коллективная работа - меньше препятствий для эффективного обмена информацией;

· всеобщее участие в проектировании [2].

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

Внедрение модели проектной группы MSF уже помогло компании Damgaard выпустить в срок новую систему управления предприятием АХАРТА, используемого более чем в 20 странах мира, компании Navision - увеличить штат разработчиков в несколько раз без дополнительных затрат на обучение, группе разработчиков из Unitied Airline - создать крупнейшую в мире систему резервирования авиабилетов в срок и без перерасхода выделенного бюджета.

Внедрение модели MSF необходимо для любой растущей компании. В частности Damgaard и Navision внедрили MSF Team model именно в тот момент, когда начался интенсивный рост численности разработчиков. В соответствии с данной модель были четко определены обязанности каждого члена команды.

1.2 Жизненный цикл MSF

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

Рис. 2. Модель жизненного цикла MSF

Модель жизненного цикла MSF ориентирована на «вехи» (milestones) - ключевые точки проекта, характеризующие достижение какого - либо существенного результата. Этот результат может быть оценен и проанализирован, что подразумевает ответ на вопрос: «А были ли достигнуты цели, поставленные на этом шаге?». В модели предусматривается наличие основных вех (завершение главных фаз модели) и промежуточных, отражающих внутренние этапы главных фаз [3].

Основными фазами модели MSF являются:

1. Создание общей картины приложения (Envisioning). На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес - целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: «Организован костяк команды» и «Создана общая картина решения».

2. Планирование (Planning). Включает планирование и проектирование продукта. На основе анализа требований разрабатывается проект и основные архитектурные решения, функциональные спецификации системы, планы и календарные графики, среды разработки, тестирования и пилотной эксплуатации. Этап состоит из 3 стадий: концептуальное, логическое и физическое проектирование. На стадии концептуальное проектирование задача рассматривается с точки зрения пользовательских и бизнес - требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. И уже на стадии физического проектирования задача рассматривается с точки зрения программистов, уточняются используемые технологии и интерфейсы.

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

Страницы: 1, 2, 3, 4



© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.