ВІКІСТОРІНКА
Навигация:
Інформатика
Історія
Автоматизація
Адміністрування
Антропологія
Архітектура
Біологія
Будівництво
Бухгалтерія
Військова наука
Виробництво
Географія
Геологія
Господарство
Демографія
Екологія
Економіка
Електроніка
Енергетика
Журналістика
Кінематографія
Комп'ютеризація
Креслення
Кулінарія
Культура
Культура
Лінгвістика
Література
Лексикологія
Логіка
Маркетинг
Математика
Медицина
Менеджмент
Металургія
Метрологія
Мистецтво
Музика
Наукознавство
Освіта
Охорона Праці
Підприємництво
Педагогіка
Поліграфія
Право
Приладобудування
Програмування
Психологія
Радіозв'язок
Релігія
Риторика
Соціологія
Спорт
Стандартизація
Статистика
Технології
Торгівля
Транспорт
Фізіологія
Фізика
Філософія
Фінанси
Фармакологія


Параметры ролей проектной группы

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

Модель процесса проектирования MSF в отличие от традиционных моделей ЖЦ ориентируется на вехи. Она направлена на решение проблем традиционной модели, но используя понятие «вех» (точек синхронизации проектной группы и заказчика) и укорачивая цикл проектирования с помощью механизма выпуска версий, совместно с моделью проектной группы определяет четкую ответственность ролей. В основе этой модели лежит несколько основных идей:

- конструирование решений из обозримых и управляемых частей;

- завершение вехами фазы проекта;

- выпуск версий продукта;

- выполнение планирования с учетом рисков.

Модель процесса проектирования MSF (рис. 2.11) состоит из четырех фаз и четырех вех, которыми завершаются эти фазы.

Рис. 2.11. Модель процесса проектирования с вехами

 

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

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

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

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

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

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

• цели проекта, ожидания заказчика, база для исходной оценки рисков проекта. Данный документ определяет, какая концепция решения закладывается в основу;

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

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

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

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

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

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

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

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

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

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

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

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

• Определяется, какие возможности и когда должны быть реализованы; приоритеты задачам расставляются на основании:

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

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

• Разрабатывается план по предотвращению наиболее вероятных и опасных ситуаций и, на всякий случай, план «ликвидации катастрофы», т.е. план возврата к последнему работоспособному варианту без потери данных.

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

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

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

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

• пользователи плохо формулируют то, что им нужно;

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

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

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

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

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

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

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

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

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

Полученная версия может быть названа качественным продуктом, если она:

• удовлетворяет ожиданиям заказчика и пользователей;

• удовлетворяет проектным ограничениям;

• соответствует реальным потребностям;

• обеспечивает умение его использовать;

• обеспечивает его гладкое внедрение.

При этом:

• далеко не каждый проект должен быть выполнен как можно скорее;

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

• далеко не каждый проект требует решений, не содержащих ошибок.

 

© 2013 wikipage.com.ua - Дякуємо за посилання на wikipage.com.ua | Контакти