И. Соммервилл - Инженерия программного обеспечения (1133538), страница 23

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 23)

Написание предложений — очень ответственная работа, так как для многих организаций вопрос о том, будет лп прослт выполняться самой организацией нлн разрабатываться по контракгу сторонней компанией, является критическим. Нсвоззюжно дать каких-либо рекомендаций по написанию предложений, многое здесь зависит от опыта менеджера. Эйрон (Лгоп) (12) считает эту работу менеджера одной пз вюкпейяшх среди других выполняемых им работ. 1!а этапе планирования проекта определяются процессы, этапы и полученные на каждол~ иа них роз>льтаты, которые должны привести к выполнению проекта. Реализация этого илана приведет к достижению целей проекта.

Определение стоимости проекта напрямую связано с его планированием, поскольку здесь оцениваютсл ресурсы, треб>ющнеся для выполнения плана. Эти вопросы обсуждаются далее в этой главе, а также в главе 23. 84 'Часть 1. Инженерия программного обеспечения: обзор Контроль за ходом выполнения работ (мониторинг проекта) — это непрерывный процесс, продолжающийся в течение всего срока реализации проекта. Менеджер должен постоянно отслеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью.

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

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

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

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

Вместе с тем необходимо, чтобы хотя бы несколько членов группы разработчиков имели квалификацию и опыт, достаточные лля работы над данным проектом. В противном случае невозможно избежать ошибок в разработке ПО. Проблемы создания команд разработчиков и подбора персонала более подробно рассматриваютсл в главе 22. 4. Управление проектами 85 Менеджер проекта обычно обязан посылать отчеты о ходе его выполнения как заказчику, так и подрядным органиэациям.

Это должны быть краткие документы, основанные на информации. извлекаемой из подробных'отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта. 4.2. Планирование проекта Таблица 4.1. Виды планов План Описание Описывает стандарты и мероприятил по поддержке качества разра- батываемого ПО (глава 24) План качества Описывает способы, ресурсы и перечень работ, необходимых лля ат- тестации программной системы (глава 19) План аттестации Описывает структуру и процессы управления конфигурацией (глава 29) План управления конфи~уранией Предлагает план мероприятий, требующихся для сопровоаслсння ПО в процессе его эксплуатации, а также расчет стоииости сопровожде- ния и необходимые для этого ресурсы (глава 27) План сопровож- дения ПО Описывает мероприятия, направленные на повышение квалифика- ции членов команды разработчиков (глава 22) План по управлению персоналом В листинге 4.1 показан процесс планирования создания ПО в виде псевдокола.

Здесь сделан акцент на том, что планирование — это итерационный процесс. Поскольку в про. цессе выполнения проекта постоянно посгупает новая информация, план должен регулярно пересматриваться. Вюкнымн факторами, которые должны учитываться при разработке плана, являются финансовые и деловыс обязательства организации. Если они изменяются, эти изменения также должны найти отражение в плане работ. Листинг 4.1. Процесс планирования проекта Определение проектных ограничений Первоначальная оценка параметров проекта Определение этапов выполнения проекта и контрольных отметок Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения.

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

Эти виды планов кратко описаны в табл. 4.1 и подробно обсуждаются в соответсгвующих главах книги. 86 т1асть 1. Инженерия программного обеспечения: обзор нг>ззге пока проект не завершится или не будет остановлен 1оор Составление графика работ Иачало выполнения работ Ожидание окончания очередного этапа работ Отслеживание хода выполнения работ Пересмотр оценок параметров проекта Изменение графика работ Пересмотр проектных ограничений зх (возникла проблема) Т1>вп Пересмотр технических или организационных параметров проекта впб зх епб Хвор Процесс планирования начинается с определения проектных ограничений (времснпыс ограничения.

возможносги наличного персонала, бюджетныеограничения и т.д.). Эти ограничеипл должн<я определяться параллельно с оцсииванием проектных параметров, таких как структура и размер проекта, а также распределением функций срепи нсполнитглсй. Затем опрслеляются этапы разработки и то, какие результаты (докумснтацил. прототипы, подсистемы илп версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала рвзрабатывастгя график работ по выполнению проекта или дается разрс. щсиис на нр>должспис нгпользования ранее созданного графика, После этого (обычно через 2-8 недели) проводится контроль выполнения работ и отмечаются расхождения между рсюп пым и плановым ходом работ.

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

Желательно описать возможные проблемы еще до того. как оин проявят себя в ходе выполнения проекта. Поэтому лучше составллть пессимистические графики работ. чем "оптимистические". Но, конечно, невозможно построить план, учитывающий вес, в том числе случайные, проблемы и задержки выпалисиия проекта. поэтому и возникает необходимость периодического пересмотра проектных <>грш>ичсннй и этапов создания программного продукта. 4.2.1. План проекта План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ иа этапы и врсыснно11 график выполнения этих этапов. В некоторых орпншзациях план прослта составляется как сдиш ш документ, содержащий вес аиды план<>в. описанных ньиве. В других случаях план проекта описывает только тсхпологпческш1 процесс <озлкпия ПО.

Характеристики

Список файлов книги