Модели жизненного цикла в некоторых реальных методологиях программирования

Модель процессов MSF

Предложение Microsoft Solutions Framework, касающееся жизненного цикла [44], исходит из идеи механического "скрещивания" каскадной модели   MSF (мы ее подробно обсуждали в лекции 7) и самой примитивной спиралевидной модели (подобной спирали охвата предметной области — см. лекцию 8). По мнению авторов, модель процессов MSF (см. рис 11.2) "объединяет в себе лучшие принципы каскадной и спиральной моделей. Она сохраняет преимущества упорядоченности каскадной модели, не теряя при этом гибкости и творческой ориентации модели спиральной, учитывает необходимость постоянного пересмотра, уточнения и оценки проектных требований, стимулирует активное взаимодействие между проектной группой и заказчиком, который оценивает ход и результаты работы на протяжении всего проекта".

увеличить изображение
Рис. 11.2. Модель процессов MSF [44]

К сожалению, авторы предложения MSF не совсем точны в своих оценках модели. Как и в случае с RUP, в этой модели очевидно стремление к универсальности, которое неизбежно приводит к огрублению ситуации в конкретных случаях и к необходимости словесного дополнения схемы. Недостатки моделей, основанных на раскручивающейся спирали (см. лекцию 10), присущи ей в полной мере: невозможность отслеживания временных соотношений между сроками выполнения работ, трудности дополнения специфичных этапов. К тому же ориентация на всеобщность лишает модель и тех преимуществ, которые демонстрирует, например, модель Боэма, снабженная конкретным механизмом интерпретации.

Если обратиться к процессам, которые отражают модель MSF, т.е. к их отдельному описанию, то становится заметным стремление авторов сделать методологию гибкой. К примеру, вот что они пишут о сотрудничестве с заказчиком: "Вовлечение заказчика в проект является необходимым условием успешности проектов. Модель процессов MSF предоставляет заказчику широкий спектр возможностей для уточнения и модификации проектных требований и установки контрольных точек (вех) для мониторинга работы над проектом. В свою очередь, это требует затрат времени со стороны заказчика и взятия им на себя определенных обязательств". Однако далее говорится о том, что "MSF признает первостепенную важность договорных и юридических отношений между заказчиком, его поставщиками и проектной командой и необходимость управления этими отношениями". (Стоит сопоставить эти высказывания с соответствующим принципом Agile Manifesto [31] — см. лекцию 5.) Только из схемы ни первое, ни второе утверждение извлечь нельзя. И это пример словесного дополнения, к которому приходится прибегать при неудовлетворительном схематическом представлении модели.

Изучение методологии, провозглашаемой MSF, позволяет сделать вывод о том, что ее авторы достаточно тщательно проработали процессы менеджмента, когда основой организации коллектива разработчиков считается проектная группа с рассредоточенными ролями (мы об этом уже говорили в лекции 2). Но опять-таки в модели жизненного цикла это обстоятельство никак не отражено, что вполне объяснимо стремлением к всеобщности. Отсюда следует, что обсуждаемое предложение всегда в конкретных проектах должно адаптироваться. Сделать это проще, чем, к примеру, в случае RUP или жестких схем, которые только и допускает стандарт CMM [18]. Однако до уровня стратегии быстрого развития предложения MSF не доходят и занимают промежуточное положение между жесткими и гибкими методологиями.

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

Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта (см., например, [3]). Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разработки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой характер, который позволяет менеджеру в большей мере сосредоточиться на руководстве командой, чем на управлении. В результате отслеживание процесса не требует, к примеру, специальных документов о достигнутых результатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претендуют на инструментальность, и в таком ключе их рассматривать не имеет смысла. Тем не менее понятия контрольных точек и контрольных мероприятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным.

Жизненный цикл любой методологии быстрого развития можно описать следующим образом.

• Начальная фаза. Она выделена, поскольку приходится выполнять работы, которые не являются характерными для основного процесса.
• Серия максимально коротких итераций, состоящих из шагов:
  • выбор реализуемых требований (в экстремальном программировании — пользовательских историй);
  • реализация только отобранных требований;
  • передача результата для практического использования;
  • короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием).
• Фаза заключительной оценки разработки проекта.

Реальные   быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками (пример того, как это делается в экстремальном программировании [3], будет рассмотрен ниже).

До последнего времени быстрые процессы было не принято формализовывать настолько, чтобы их можно было предлагать в качестве стандарта. И сегодня не приходится говорить, например, о сертифицировании команды как "правильно" работающей по быстрой методологии, подобном тому, что требует CMM. Тем не менее вопрос о сертификации быстрого процесса приобретает актуальность — складывается своеобразная мода на гибкие методологии, отрицательно сказывающаяся на престиже подхода в целом. Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасения, что в результате быстрые подходы станут формализованными до такой степени, что их нельзя уже будет называть гибкими. Эта проблема отмечалась во многих докладах на недавней конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003 [37].

Тем не менее сегодня уже появилась компания, выполняющая проекты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000 [39], свидетельствующий об определенных гарантиях качества организации проектной деятельности и получаемых результатов. Это произошло весной 2003 года по прошествии примерно года с момента подачи заявки на сертификацию [51]. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и поддерживаемыми стандартом. В остальном процедура сертификации не нарушила процессы производства программ в компании. Не потребовалось никакой настройки процесса, доведения его до требований стандарта. Не претерпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования (см. лекцию 2), признана соответствующей требованиям качества и т.д. ^{1Уместно отметить, что попытка сертификации по предыдущей версии стандарта, несомненно, провалилась бы, поскольку он, подобно CMM, помимо всего прочего, утверждает необходимость ведения процессов по определенным схемам, которые в экстремальном программировании не работают. В новой версии ограничиваются требованиями к качеству, а не к форме организации работ.}.

В последующих разделах мы конкретизируем общую для быстрых методологий схему на примере двух характерных подходов к разработке программных систем.