Лекция 5 Тема. Методология проектирования, разработки и сопровождения приложений информационных систем
жүктеу/скачать 0,53 Mb. Pdf көрінісі
|
- Бұл бет үшін навигация:
- Матрица компромиссов проекта
| Управление компромиссами
Управление рамками проекта критично для его успеха. Неудачи многих IT-проектов, включая затягивание сроков и перерасход средств, обусловлены плохой организацией управления их рамками. Эта деятельность должна включать в себя раннее определение рамок проекта, хорошо организованные мониторинг его хода и управление изменениями. В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения. Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 6.2. После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне. Рис. 6.2. Треугольник компромиссов Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика. Иногда заказчики не хотят, чтобы в жертву приносились определенные (не необходимые) возможности продукта. Изображенный выше треугольник помогает проиллюстрировать им суть имеющихся ограничений и служит инструментом поиска компромиссных решений. Реализуемая функциональность должна иметь качество не ниже определенного уровня. Параметр качества может быть изображен в виде четвертого измерения, превращающего треугольник в тетраэдр (треугольную пирамиду). Хотя снижение порога качества дает возможность сократить затрачиваемые ресурсы/время и увеличить функциональность решения, это ведет, безусловно, к неизбежно плохому результату. Матрица компромиссов проекта Другое весьма полезное средство для управления проектными компромиссами – матрица компромиссов проекта, показанная на рис. 6.3. Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. В определенных случаях из этой приоритезации могут делаться исключения, но в целом следование ей облегчает достижение соглашений по спорным вопросам. Рис. 6.3 показывает матрицу компромиссов проекта, используемую обычно проектными группами Майкрософт. Она помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка “Принимается”). Нельзя произвольно сокращать функциональность решения. Как проектная группа, так и заказчик должны тщательно проанализировать все имеющиеся в проекте ограничения и быть готовыми идти на обусловленные ими уступки. Для иллюстрации использования матрицы компромиссов рассмотрим следующее предложение (вместо пропущенных слов могут быть вставлены “календарный график”, “ресурсы” и 7 “функциональность”): Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________. Рис. 6.3. Матрица компромиссов Возможны такие логические взаимосвязи: Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения. Зафиксировав ресурсы, мы согласовываем функциональность решения и принимаем результирующие сроки. Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки. Зафиксировав объем функциональности решения, мы согласовываем календарный график и принимаем результирующие затраты ресурсов. Зафиксировав календарный график, мы согласовываем затраты ресурсов и принимаем результирующую функциональность решения. Зафиксировав сроки, мы согласовываем объем функциональности решения и принимаем результирующие затраты ресурсов. Принципиально важно наличие у проектной группы и заказчика единого, однозначного взгляда на матрицу компромиссов проекта. MSF - это набор принципов и правил деятельности, в некоторой степени ориентированный на проекты разработки программного обеспечения и развития информационной инфраструктуры. Ядром MSF являются шесть основных групп принципов, называемых моделями: модель производственной архитектуры, суть которой - планомерное приведение информационных технологий в соответствие потребностям бизнеса; модель проектной группы, определяющая взаимосвязанные роли и обязанности участников на разных стадиях выполнения проекта; модель процесса, описывающая фазы проекта, контрольные точки каждой фазы, деятельность участников проектной группы в каждой фазе и ее результаты; модель управления рисками, описывающая порядок выявления наиболее существенных рисков и упреждающего реагирования на них; модель процесса проектирования, описывающая трехфазное проектирование, реализующее продвижение от точки зрения пользователей через точку зрения проектной группы к точке зрения разработчиков; 8 модель приложения, более важная для проектов разработки программного обеспечения, описывающая метод его разработки как совокупности сервисов трех уровней: пользовательских, бизнес-логики и данных. Ранее в документах фирмы Microsoft описывалась и седьмая модель — модель совокупной стоимости владения (TCO), однако в более свежих материалах эта модель как часть MSF не упоминается. Возможно, она перемещена в другие дисциплины (одна из них — Microsoft Readiness Framework), о которых Microsoft заговорила сравнительно недавно. жүктеу/скачать 0,53 Mb. Достарыңызбен бөлісу:
|