Методология Microsoft Solution Framework

Для анализа особенностей MSF обратимся к работе Якимчук С. «MSF – философия создания IT-решений или голые амбиции лидера» в журнале «ИТ менеджер», №3, 2004 г.

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

Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации. Такой подход позволяет планировать возможности для последующих версий, делать учёт опыта предыдущих циклов, обеспечивая гибкость и устойчивость к переменам требований. Таким образом, обеспечивается ведение «живой» документации, которая изменяется по мере эволюции проекта. В рамках одной итерации все документы (равно как и программный код) тоже развиваются итеративно. Например, план тестирования или концепция проекта (shared vision document) распространяется среди всех ролей проекта в виде «подходов» (approaches) еще до утверждения и затем итеративно эволюционируют благодаря обратной связи участников проекта до формы, подлежащей утверждению. Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями, и часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии. Создание базовой версии всех проектных документов на самых ранних этапах дает возможность всем членам проектной группы осмыслить свои задачи и цели проекта, а так же приступить к работе с минимальными задержками.

Методология MSF рекомендует делать текущие сборки программных компонент решения. Это особенно важно в сложных комплексах, где необходимо учитывать и тестировать совместимость компонент. Для этих целей Майкрософт при разработке своих продуктов выполняет ежедневные билды (daily builds). Разработка и тестирование ведутся практически одновременно, что увеличивает надежность результирующего кода. Для осуществления такого подхода к разработке необходимо вести управление конфигурациями проекта. Необходим строгий мониторинг и контроль версий программного кода, документации, аппаратных настроек и других артефактов проекта. Управление конфигурациями в свою очередь служит эффективным инструментом управления изменениями в проекте, которое регламентируют процесс внесения изменений в артефакты проекта от запроса на изменение, до включения его в базовую версию.

К основным рекомендациям MSF для выпуска версий решения относятся следующие:

Ø Создавая планы, предусматривайте версионирование.

Ø Прежде всего, поставляйте базовую функциональность.

Ø Выбирайте приоритеты, учитывая риски.

Ø Осуществляйте частые итерации разработки.

Ø Требуйте соблюдения процедуры контроля изменений в проекте.

Ø Не создавайте новых версий, если они не увеличивают ценность решения.

В рамках одной итерации жизненный цикл выпуска версии разбивается на пять фаз: выработка концепции (единого видения), планирование, разработка, стабилизация (тестирование), внедрение. Каждая фаза цикла заканчивается главной вехой (контрольной точкой). Соответственно главные вехи будут иметь названия: концепция продукта утверждена, планы продукта утверждены, разработка завершена, готовность решения утверждена, внедрение завершено. Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых кластеров (разработка, тестирование, внедрение, управление проектом и пр.).

В описании MSF перечисляются документы, которые могут создаваться на разных фазах, и их состав. Однако это перечисление носит рекомендательный характер.

Методика масштабируется за счет:

Ø определения состава фаз и вех;

Ø выбора числа и скорости итераций;

Ø распределения исполнителей по ролевым кластерам (в частности – с привлечением специалистов заказчика.

Методика Oracle CDM

CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения о простом приспособлении CDM к проектам, в которых используется другой инструментальный комплекс.

Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов:

Стратегия – разработка общих принципов и требований к создаваемой системе;

Анализ - формулирование детальных требований к прикладной системе;

Проектирование - преобразование требований в детальные спецификации системы;

Реализация - разработка и тестирование приложений;

Внедрение - установка системы, подготовка к началу эксплуатации;

Эксплуатация - поддержка и мониторинг приложения, планирование будущих функциональных расширений.

В рамках этапов выполняются процессы, обозначенные характерными англоязычными аббревиатурами:

Ø RD - Определение производственных требований,

Ø ES - Исследование существующих систем,

Ø TA - Определение технической архитектуры,

Ø DB - Проектирование и построение БД,

Ø MD - Проектирование и реализация модулей,

Ø CV - Конвертирование данных,

Ø DO - Документирование,

Ø TE - Тестирование,

Ø TR - Обучение,

Ø TS - Переход к новой системе,

Ø PS - Поддержка и сопровождение.

Процессы состоят из последовательностей задач, задачи разных процессов взаимосвязаны явно указанными ссылками. CDM наиболее сильно связан с методикой "Oracle PJM" по организации управления проектом.

Существует три модификации модели жизненного цикла:

Ø "классическая" (предусмотрены все работы/задачи и этапы),

Ø "быстрая разработка" (Fast Track), еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle,

Ø "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.

Методология CDM не предусматривает включение дополнительных задач или удаление задачи (и порождаемых ею документов), не предусмотренное одной из трех моделей ЖЦ; изменение последовательности выполнения задач по сравнению с предложенной, тем более - по ходу процесса проектирования. Модель является каскадной

ГОСТ 34

Объектами стандартизации являются автоматизированные системы различных видов и все виды их компонентов, а не только ПО и БД.

Наиболее часто используемыми являются стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

Комплекс стандартов рассчитан на взаимодействие заказчика и разработчика. Предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается, отталкиваясь от этого содержания (см. таблицу 9).

Таблица 9

Стадии и этапы на практике ориентируют разработчиков на каскадную схему жизненного цикла или близкую к ней.

В ГОСТе 34.003-90 определено несколько важных положений, отражающих особенности АС как объекта стандартизации. Например, в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечений. Дано определение автоматизированной системы: система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Поиск по сайту: