Управление проектами по созданию и внедрению ПО
Курс лекций, 04 Октября 2013, автор: пользователь скрыл имя
Краткое описание
«Необходимость управления программными проектами вытекает из того "прискорбного" факта, что процесс создания профессионального ПО всегда является субъектом бюджетной политики организации, где оно разрабатывается, и имеет временные ограничения. Работа руководителя программного проекта по большому счету заключается в том, чтобы гарантировать выполнение этих бюджетных и временных ограничений с учетом бизнес-целей организации относительно разрабатываемого ПО.»
Прикрепленные файлы: 1 файл
Лекция12.doc
— 308.00 Кб (Скачать документ)
Таблица 16 - Список рисков после проведения их анализа
Риск |
Вероятность* |
Степень ущерба | |
Финансовые затруднения
в организации привели к уменьш |
Низкая |
Катастрофическая | |
Невозможно подобрать работников с требующимся профессиональным уровнем |
Высокая |
Катастрофическая | |
Ведущий разработчик заболел в самое критическое время |
Средняя |
Серьезная | |
Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональные возможности |
Средняя |
Серьезная | |
Изменения требований приводят к значительным повторным работам по проектированию системы |
Средняя |
Серьезная | |
В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом |
Высокая |
Серьезная | |
База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций |
Средняя |
Серьезная | |
Недооценки времени выполнения проекта |
Высокая |
Серьезная |
|
CASE-средства
невозможно интегрировать с |
Высокая |
Терпимая |
|
Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта |
Средняя |
Терпимая |
|
Невозможно организовать необходимое обучение персонала |
Средняя |
Терпимая |
|
Скорость выявления дефектов в системе ниже ранее спланированной |
Средняя |
Терпимая |
|
Размер системы
значительно превышает первонач |
Высокая |
Терпимая |
|
Программный код, генерируемый CASE-средствами, неэффективен |
Средняя |
Незначительная |
|
* Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
Планирование
заключается в определении
Таблица 17 – Стратегии управления рисками
Риск |
Стратегия |
Финансовые проблемы организации |
Подготовить краткий документ для руководства организации, показывающий важность данного проекта для достижения финансовых целей организации |
Проблемы неквалифицированного персонала |
Предупредить
заказчика о потенциальных |
Болезни персонала |
Реорганизовать работу команды разработчиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками |
Дефектные системные компоненты |
Заменить потенциально дефектные системные компоненты покупными компонентами, гарантирующими качество работы |
Изменения требований |
Попытаться определить требования, наиболее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию |
Реорганизация компании-разработчика |
Подготовить краткий документ для руководства компании, показывающий важность данного проекта для достижения финансовых целей компании |
Недостаточная производительность базы данных |
Рассмотреть возможность покупки более производительной базы данных |
Недооценки времени выполнения проекта |
Рассмотреть вопрос о покупке системных компонентов, исследовать возможность использования генератора программного кода |
Существует
три категории стратегий
- Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов.
- Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков.
- Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 4.7 это стратегия поведения при возникновении финансовых проблем у организации разработчика.
Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести.
Таблица 18 – Типы рисков
Тип риска |
Признаки |
Технологические риски |
Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документированные технологические проблемы |
Риски, связанные с персоналом |
Низкое моральное
состояние персонала, натянутые
отношения между членами |
Организационные риски |
Разговоры среди персонала о пассивности и недостаточной компетентности высшего руководства организации |
Инструментальные риски |
Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства |
Риски, связанные с системными требованиями |
Необходимость пересмотра многих системных требований, недовольство заказчика ПО |
Риски оценивания |
Изменения графика работ, многочисленные отчеты о нарушении графика работ |
Вопросы для обсуждения
- Объясните, почему нематериальность программных систем порождает особые проблемы в процессе управления программными проектами.
- Объясните, почему хорошие программисты не всегда могут быть хорошими менеджера проектов.
- Объясните, почему процесс планирования проекта является итерационным и почему план должен постоянно пересматриваться в течение всего срока выполнения проекта.
- Менеджер проекта предупреждает о возможной задержке выполнения работ, которой можно избежать только за счет бесплатных сверхурочных работ команды разработчиков. Все члены команды имеют семьи, требующие определенной доли внимания. Обсудите возможность отклонения предложения менеджера о бесплатных сверхурочных работах либо согласия предпочесть интересы организации семейным интересам. Какие аргументы наиболее весомы в этой дискуссии?
- Как опытному программисту, вам предложили возглавить управление проектом, но вы чувствуете, что больше пользы можете принести в качестве технического специалиста, а не менеджера проекта. Обсудите возможности принятия или отклонения предложения возглавить программный проект.