Автоматизация бизнес-процессов продажи билетов ООО "Зритель"
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
реалистичным. Новая версия плана утверждается после появления очередного релиза.
При первоначальном составлении плана релизов не стоит стараться слишком детализировать его этапы, если нет четких критериев, когда должен окончиться один этап и начаться другой. Вместо этого проект просто разбивается на 6-8-недельные итерации каждого релиза, исходя из возможностей реализации требуемых функций. Вопрос о том, какие функции, к какой итерации должны быть отнесены, решается на основе принципа: ближе к началу проекта относят, в первую очередь, наиболее приоритетные функции, во вторую очередь более простые для реализации функции. Последнее делается с целью оставить разработчикам время для более полного изучения предметной области в ходе подготовки первого релиза, а также для решения организационных вопросов.
Чтобы избежать сбоев нарушения плана выпуска релизов при выполнении итерации, не следует завершать работу с этим планом в ходе конструирования. Если становится ясно, что по тем или иным причинам рабочие продукты, запланированные к выпуску на данной итерации, не могут быть сделаны вовремя, рекомендуется воспользоваться следующими приемами корректировки плана:
разбиение этапа - выделение в нем той части, которая может быть выполнена на данной итерации, и перенесение остального на другие итерации. Это делается, когда трудности возникают с реализацией высокоуровневых требований, от которых многое зависит;
сдвиг работ - перенос запаздывающего рабочего продукта на следующую итерацию с сохранением даты окончания итерации. Этот прием применяется для требований с низким приоритетом, а также на ранних итерациях, разгрузка которых позволяет потратить освобождающееся у разработчиков время на дополнительное изучение предметной области;
перераспределение работ - ускорение работ за счет привлечения к проекту дополнительных ресурсов (как правило, кадровых) с сохранением даты окончания итерации и запланированного объема работ. Этот прием можно применять для рабочих продуктов, которые поддаются декомпозиции на части, допускающие раздельное выполнение. Разумеется, он лишен смысла, если менеджер не располагает резервными ресурсами.
2.1.6Ожидаемые риски на этапах жизненного цикла и их описание
Риск применительно к программным проектам - это любая причина, по которой развитие проекта может быть прервано. Конечно, это неформальное определение, оно только обозначает возможность ситуаций, когда проект может быть прерван вопреки желанию менеджера продолжать проект. Ситуации, когда проект прекращается для менеджера, но, возможно, продолжается с другим менеджером или завершается в связи с причинами, на которые нельзя повлиять, здесь не рассматриваются, поскольку разумная целевая установка менеджера - преодоление рискованной ситуации с минимальными потерями и продолжение проекта. В соответствии с этой установкой менеджер должен еще до начала основных работ проанализировать, из-за чего данный проект может быть сорван, и понять, как он и его фирма могут и должны поступать, чтобы исключить, или хотя бы минимизировать риски. В частности, результатом такого анализа может стать отказ от проекта. С другой стороны, риск невыполнения проекта является одной из причин, из-за которых заказ на разработку может быть не получен.
Причины возможного срыва работ весьма разнообразны, они зависят от конкретных условий и не сводятся лишь к техническим аспектам. Разработчики должны учитывать такие особенности ведения проекта, как техническая политика руководства фирмы и заказчика, их компетентность, их расчет на удачу, с одной стороны, а с другой - кредитоспособность, репутацию тех, кто предлагает заказ. Риск невыполнения проекта может быть связан и с изменением рыночной конъюнктуры. Наконец, есть чисто внутренние причины рисков: сбои в используемом окружении (программном и техническом), неточность предъявляемых требований, ненадежность подрядчиков и др. и, возможно, кадров (нельзя исключать, что принятый на ключевую роль работник откажется от контракта в самый неподходящий момент).
Чтобы снизить влияние рисков на развитие проекта, менеджер должен разработать специальный план, называемый далее планом управления рисками. Содержание этого плана - идентификация рисков для данного проекта и мероприятия, снижающие зависимость проекта от рисков.
Преодоление рисков может осуществляться на нескольких уровнях:
Исключение риска. Некоторые рискованные ситуации могут быть исключены полностью. Например, чтобы увольнение работника с ключевой ролью не очень сказалось на продолжении развития проекта, целесообразно с самого начала предложить для занятия этой роли двух человек сравнимой квалификации. В начале проекта их дискуссии полезны для выработки объективных решений, а если один из них откажется от контракта, второй все еще сможет продолжать дело. Полезные дискуссии - эта та жертва, которая в ряде случаев возможна для исключения риска. К сожалению, дублирование не может быть рекомендовано для исключения всех рискованных ситуаций.
Частный случай исключения риска - переключение его с проекта на окружение. К примеру, если рыночная ценность создаваемого изделия кажется сомнительной, для его разработки комфортнее договориться с заказчиком об авансовых платежах, тем самым, заставив его самого решать задачу преодоления риска и освободив от этого разработчиков (возможно, за счет снижения оплаты проекта). К сожалению, эта стратегия являе?/p>