Модель процессов Microsoft Solution Framework (MSF) представляет собой технологический подход, базирующийся на наборе моделей, правил и спецификаций, применяемых при создании и распространении программных продуктов, а также обеспечивающих более эффективное использование технологий для решений проблем бизнеса. Он позволяет количественно выражать степень завершенности работы над проектом и адаптировать методы управления им в соответствии с изменяющимися потребностями.
Формальные подходы предусматривают особые формальные требования к процессу создания программного обеспечения. Например, для генетических подходов требуются формальности, связанные с происхождением программы и дисциплиной ее создания. В данную труппу входят следующие подходы:
Генетические подходы.
Синтезирующее программирование предполагает синтез программы по ее спецификации. Документ на языке спецификаций является базисом для последующей реализации;
Сборочное (расширяемое) программирование предполагает, что программа собирается путем переиспользования уже известных фрагментов;
Конкретизирующее программирование предполагает, что частные специальные программы извлекаются из универсальной.
Подходы на основе формальных преобразований.
Технология стерильного цеха складывается из следующих частей:
разработка функциональных и пользовательских спецификаций;
планирование разработки;
формальная верификация;
статическое тестирование.
Формальные генетические подходы
Формальное синтезирующее программирование использует математическую спецификацию - совокупность логических формул;
Формальное сборочное программирование использует спецификацию как композицию уже известных фрагментов;
Формальное конкретизирующее программирование использует смешанные вычисления и конкретизацию по аннотациям.
Гибкие (адаптивные, легкие) подходы применяют для небольших или средних проектов в случае неясных или изменяющихся требований к системе. Команда разработчиков должна быть ответственной и квалифицированной, заказчики должны быть согласны принимать участие в разработке. В данную группу входят следующие подходы.
Ранние технологические подходы быстрой разработки.
Эволюционное прототипирование - первый прототип включает создание развитого пользовательского интерфейса.
Итеративная разработка - первый прототип уже должен включать завершенное ядро системы.
Постадийная разработка - должна решить недостаток первых двух подходов - невозможность определения сроков завершения проектов.
Адаптивные подходы.
Экстремальное программирование (eXtreme Programming или XP). Тщательное предварительное проектирование ПО заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой стороны, регулярными переработками кода. Основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода
Адаптивная разработка. В основе лежат три стадии - обдумывание, сотрудничество и обучение. Результаты планирования в данном подходе всегда не предсказуемы. В отличие от обычного планирования, отклонения в котором ведут к ошибкам, здесь отклонения ведут к правильным решениям. Обязательства и планы программистов и заказчиков пересматриваются в течение всего процесса разработки.
Семейство технологических подходов Crystal. Для каждого отдельного проекта существует свой технологический подход, в зависимости от его сложности, срочности, количества разработчиков и т.д.
Подходы исследовательского программирования.
Компьютерный дарвинизм основан на принципе восходящей разработки, когда система строится вокруг ключевых компонентов и программ, которые создаются на ранних стадиях разработки. Представляет собой метод проб и ошибок, основанный на интенсивном тестировании, причем на любом этапе система должна работать.
Фрагментарное программирование состоит в том, что сначала создается шаблон программ с работающими кусочками (фрагментами). Далее выполняется постепенное приближение к конечной цели. Применяется в том случае, когда не могут быть точно сформулированы требования к большей части задачи.
Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC.
По определению, ISO 12207 - базовый стандарт процессов жизненного цикла ориентированный на различные виды ПО и типы проектов автоматизированных систем.
Целесообразность совместного использования стандартов на информационной системы и на ПО обусловливается одним из положений ISO 12207, согласно которому процессы, используемые во время жизненного цикла ПО, должны быть совместимы с процессами, используемыми во время жизненного цикла автоматизированной системы.
Согласно ISO 12207, система - это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов: приобретение, поставка, разработка и т.п.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие - на ряд задач. Очень важной особенностью ISO 12207 является то, что каждый процесс, действие или задача инициируются и выполняются другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т.п.).
Особенности стандарта ISO 12207.
Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть.
Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация, в соответствии с конкретными проектами информационных систем. Эта адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.
Стандарт принципиально не содержит описания конкретных методов действий, а тем более - заготовок решений или документации. Данный стандарт не предписывает имена, форматы или точное содержание получаемой документации. Решения такого типа принимаются сторонами, использующими стандарт.
Обеспечение качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты. Контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие потребностям приобретения.
Степень обязательности рассматриваемого стандарта следующая: после решения организации о применении ISO 12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые обеспечивают согласованность с этим стандартом.
Стандарт содержит предельно мало описаний, направленных на проектирование базы данных. Это можно считать оправданным, так как разные системы и разные прикладные комплексы программного обеспечения могут не только использовать весьма специфические типы баз данных, но и вообще не использовать базу данных.
Ценность стандарта ISO 12207 в том, что он содержит наборы задач, характеристик качества, критериев оценки и т.п., дающие всесторонний охват проектных ситуаций.
ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Объектами стандартизации являются автоматизированные системы различных видов и все виды их компонентов, а не только программное обеспечение и базы данных.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO 12207, в нем предусмотрено, что заказчик может разрабатывать автоматизированную систему для себя сам (например, создав для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь явное и в известном смысле симметричное отражение действий обеих сторон, как это сделано в ISO 12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно производится исходя из этого содержания.