Методологии управления итпроектами
 Скачать 170.99 Kb.
|
|
Методологии управления ИТ-проектами Все методологии (еще их называют моделями, методиками) разработки программного обеспечения классифицируют по «весу», т. е. по количеству формализованных процессов и детальности. Следовательно, чем больше процессов документировано, чем более детально описана методология, тем больше будет ее «вес». − ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Стандарты на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход к разработке программного обеспечения; −Capability Maturity Model for Software (SW-CMM) определяет пять уровней «зрелости проекта»; − Rational Unified Process (RUP) – итеративная модель разработки; − Microsoft Solutions Framework (MSF) – база знаний компании Microsoft по разработки программ; − Personal Software Process – модель определяет требования к компетенциям разработчика. Team Software Process – модель ориентирует на самоуправляемые команды от 3 до 20 разработчиков и др. 2. Легковесные или agile-методики: −eXtreme программирование, предлагающее 12 инженерных практик; − Crystal Clear – семейство методологий, определяют необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач; − Feature Driven ориентированная разработка; − OpenUP – программа, позиционируется как легкий и гибкий вариант тяжеловесной методологии RUP; − Scrum – управление разработкой информационных систем с высокой степенью неопределенности; − Kanban – методология «бережливого производства»; − и др. Идея всех гибких (легковесных) методологий состоит в том, что применяемый в разработке ПО процесс должен быть адаптивным, ориентированным на людей и их взаимодействие. По сути это скорее набор практик, чем методология. На том же семинаре было предложено новое название таких методологий – гибкая разработка Agile Software Development. Выбор методологии управления проектом А. Коуберн сделал также вывод о том, что: 1 У каждого проекта должна быть своя модель процесса разработки. 2 У каждой модели – свое время. Для разработчиков это означает, что не существует единственного правильного процесса разработки. В каждом новом проекте процесс должен определяться каждый раз заново по «закону четырех П». «Закон четырех П» Процесс проекта Персонал Продукт Проект |