Информатизация бизнеса. Управление рисками - стр. 29
К недостаткам можно отнести тот факт, что для эффективного управления рисками ИТ-проекта, в силу его сложности и неопределенности, необходимо получить не только результаты первоначальной оценки ИТ-рисков, но также рекомендации по их снижению, связи между выявленными рисками и причинами, которые ведут к ним.
2.3. Риски при использовании методологий разработки ПО
Выбор методологии разработки тесно связан с используемой средой разработки и типом программного продукта, его особенностями и характеристиками.
В зависимости от назначения проектный менеджер выбирает наиболее подходящие для разработки и управления ПО модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики. Универсальные концепции, а также управленческие стандарты, например серии ISO 9000, аккумулируют опыт и лучшие управленческие практики, которые стали основой методологий совершенствования деятельности компаний-разработчиков, таких как модели зрелости (CMM/CMMI), стандарты оценки и улучшения процессов (SPICE) и прочие. Объектами стандартизации в сфере ИТ являются:
• конструкторская документация (состав, структура, требования к оформлению);
• стандарты кодирования и оформления программных текстов;
• терминология и определения;
• модели процессов;
• модели жизненного цикла;
• требования к безопасности хранения и передачи информации и способы ее обеспечения;
• качество программного обеспечения, характеристики качества, методы получения данных по качеству;
• графические и нотации и инструменты формализованного описания требований и технических решений;
• форматы хранения данных, обмена и передачи данных.
Выбор методологии, в соответствии с которой будет происходить процесс стандартизации и разработки ИТ-проекта, окажет значительное влияние на процесс разработки ПО, ведь методология разработки системы относится к основной базе, на которой формируются структура, планирование и контроль процесса разработки информационной системы.
Все доступные модели и методологии хороши только для определенных задач и проектов, в которых эти методологии учитывают различные технические, организационные, проектные и командные особенности, и поэтому выбор одной конкретной методологии не означает, что она будет подходить под все проекты, которые ведутся в компании.
В зависимости от «уровня зрелости» организации должна использоваться та или иная группа инструментальных средств. В основе каждой методологии лежит набор «принципов», которые могут быть истинными или ложными для ИТ-проекта. Также с выбором методологии происходит выбор ролей, навыков, видов деятельности, используемых техник, инструментария, поставляемых артефактов, стандартов, мер качества и приоритетов проекта. Многие методологии обвиняют в бюрократизме – чтобы следовать такой методологии, нужно выполнять так много различных предписаний, что замедляется весь темп работ. Некоторые методологии являются слишком общими и подходят для многих случаев разработки, однако не содержат специфических указаний, другие методологии основной целью полагают корректность программных продуктов, явность и повторяемость процесса. Гибкие методологии в первую очередь направлены на повышение продуктивности и снижение стоимости работ, при этом они не применимы для большой проектной команды.