Методологии управления разработкой информационных систем

Ранее уже было сказано о РМВоК, PRINCE2 и гибких методологиях, однако для предметной области ИТ-нроектов применяются также MSF,.

RUP и многие другие. Отдельным классом документов в области проектирования и разработки ИС являются отечественные и международные стандарты серий ISO/ГОСТ (ГОСТ 34.601−90, ISO/IEC 12 207:2008 и пр.). В частности, наибольшее число различных методологий создано для такого направления ИТ-проектов, как управление разработкой ИС¹.

Методологии внедрения И С являются источником информации для разработки иерархической структуры самого проекта внедрения и его работ. Состав работ в значительной мере определяется целями проекта внедрения, используемым ПО, особенностями автоматизируемой сферы деятельности, организационной структурой объекта автоматизации, принятой у разработчика организацией работы и прочими факторами.

Число этапов и итераций, их содержание, принцип взаимодействия подрядчиков и исполнителей — вот лишь некоторые из характеристик, которые отличают различные методологии. Среди них есть те, которые универсальны, а есть разработанные и используемые только отдельными предприятиями. Есть методологии, охватывающие только ЖЦ ИС, а есть те, которые концентрируются также на целостном подходе к созданию ИТ-решений, управлению ими и управлению проектами.

Существует большое число корпоративных методологий, которые разрабатывались вендорами для личных потребностей, но со временем стали стандартами в своих направлениях деятельности:

• • IBM — Rational Unified Process (RUP);
• • Microsoft — Microsoft Solution Framework (MSF), Navision On Target, Microsoft Dynamics Sure Step и Microsoft Business Solutions Partner Methodology;
• • SAP — Accelerated SAP (ASAP);
• • Oracle — Oracle Unified Method (OUM), PeopleSoft One Methodology.

Как уже было сказано, данные методологии создавались компаниями с расчетом на использование в проектах с применением их собственных программных средств. Поэтому материалы методологий детализируются порой вплоть до уровня заголовков проектных документов с применением внутренней терминологии компании (в случае Oracle и SAP). Часто подобные документы не являются общедоступными и предоставляются только клиентам и партнерам компании.

Но есть также методологии, которые разрабатывались без привязки к конкретному производителю ПО, а основывались на очень специфичных принципах управления. Наглядные примеры — экстремальное программирование ХР (extreme Programming) или быстрая разработка RAD (Rapid Application Development). Подобные методологии не представляют пошаговых инструкций по проектированию и разработке системы, однако определяют ключевые принципы и практики организации работ, которые применимы в конкретных условиях.

Например, главная особенность^[1][2] методологии экстремального программирования состоит в ее эффективности в условиях неопределенных или нечетких требований. Популярность данного подхода увеличивалась по мере роста числа разработчиков, недовольных традиционным подходом со множеством формальных требований и постоянно готовивших документацию, собиравших информацию о показателях проекта. Напротив, новая методология предлагала простой дизайн, переработку (рефакторинг) кода для контроля затрат, постоянное присутствие заказчика, разработку через тесты и другие аспекты, выгодно отличавшие ее.

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

Выделяют принцип коллективной работы по написанию кода/внесению изменений в настройки. Этот принцип относится к двум аспектам. В первую очередь, это «коллективное владение кодом», когда любой участник команды разработчиков может внести изменения благодаря единым правилам оформления кода и использованию стандартов программирования. В то же время применяется метод «парного программирования», в соответствии с которым двое разработчиков используют один компьютер, чередуя написание кода и доработку настроек, реализацию требований и прочие вопросы.

В отличие от экстремального программирования и других ситуационных методологий, определяющих ключевые принципы управления проектами по разработке, корпоративные стандарты и методы регламентируют именно основные этапы и работу этих проектов. Например, компания Microsoft, будучи мировым гигантом в сфере разработки ПО, подготовила и использует несколько методик для покрытия не только ЖЦ ИС, но и технологической инфраструктуры, их поддерживающей (MOF, MSF, MSM, MSA). Компания пошла еще дальше и разработала отдельную методологию для партнерской сети с целью обеспечения единого подхода к внедрению решений класса MS Dynamics. Эта методология получила название MS Business Solutions Partner Methodology (SureStep). Она основывается на лучших практиках проектов внедрения, а для соответствия различным сценариям предлагает несколько компонентов: этапы, процессы, отчетные материалы, предложения, межэтапные процессы, процедуры управления проектами, описания ролей консультантов и клиентов.

Однако наиболее известной в корпоративной среде и применяющейся во всем мире методикой Microsoft остается Microsoft Solution Framework (MSF), фокусирующаяся на аспекте внедрения ИТ-систем. Ключевые понятия MSF — «вехи» и «артефакты» (как результаты достижения этих вех). Вехами, например, могут являться события «Концепция проекта утверждена» или «Разработка прототипа завершена» с промежуточными.

(вспомогательными) вехами «Базовая версия функциональной спецификации создана», «Среды разработки и тестирования развернуты».

Для MSF очень важно взаимодействие внутри проектной команды, и хотя минимальное число ее участников в официальной методологии ограничено всего тремя, выделяются шесть основных ролей внутри команды, причем связь между участником и ролью имеет тип «многие-ко-многим». Среди шести упомянутых кластеров выделяют:

• 1) управление программой (архитектурным решением);
• 2) разработку (программной и технической архитектуры);
• 3) тестирование (планирование, разработка, отчетность);
• 4) управление релизами;
• 5) управление требованиями заказчика (в части интерфейса решения, а также обучения и технической поддержки);
• 6) управление продуктом (требованиями бизнес-заказчика и бизнесприоритетами).

Именно на этих областях концентрируется методология. Каждый из кластеров отвечает за достижение определенной цели, однако за итоговый результат отвественна вся команда. Для более крупных проектов с большими командами внедрения могут дополнительно создаваться группы направлений и функциональные группы, причем MSF даже предлагает таблицу совместимости ролей: какие из них допустимо, нежелательно или совсем нельзя совмещать.

Таким образом, методологии разработки являются гораздо менее абстрактными и применимыми для многих типов проектов, нежели стандартные методологии проектного управления (в равной степени подходящие и для сферы строительства, и для организации событий).

• [1] Грекул В. И. Учебный курс «Управление внедрением информационных систем». URL: http://www.intuit.ru/studies/courses/2196/267/lecture/6796.
• [2] На основе материалов портала edu.dvgups.ru.