Глава 1. Проектирование и разработка программных продуктов (теория)

Глава 1. Проектирование и разработка программных продуктов (теория)

Лекция 1. Производственная архитектура и приложения масштаба предприятия (2 часа)

 

Введение

Уважаемые студенты, Вашему вниманию предлагается курс “Программирование для инженеров”. Настоящий курс адресован тем, кто хочет изучить методы анализа требований к программным системам и проектирование крупных программных продуктов. В современном обществе программные системы играют большую роль. Практически в каждой отрасли промышленности, науки, образования и сферы услуг применяются различные компьютерные приложения. В том числе в энергетике также нашли свое применение программные продукты различного назначения. Однако далеко не все программные решения еще найдены и от специалистов в области энергетики может потребоваться разработка специализированных приложений. В первой части курса будет дан теоретический материал по проектированию и разработке крупных программных продуктов. Вторая часть курса посвящена рассмотрению простейших компьютерных программ на языке программирования Turbo Pascal. В заключительной третьей части курса будут рассмотрены вопросы проектирования и организации файловых структур с примерами программирования.

 

В контексте настоящего курса лекций архитектура – это скоординированный, единый технологический план. Применительно к информационным технологиям архитектура позволяет акцентировать внимание на целостности технологического процесса и на комплексном подходе, четко нацеленном на достижение конечных целей. Архитектор информационно-вычислительной системы – это тот, кто планирует систему и руководит составлением технологического плана, который должен быть цельным, ясным и последовательным. Другими словами, архитектор и разрабатываемая им архитектура определяют направление создания и развития информационно-вычислительной системы. Учитывать приоритет архитектуры требуется практически в любом виде деятельности, и в частности при планировании, создании и сопровождении какого-либо продукта. Совокупность этих положений можно назвать методом “приоритета архитектуры”.

Метод основан на том, что прежде чем начать любой проект, надо ответить на простые вопросы:

1. Как мы пришли к существующему положению?

2. Знаем ли мы, куда мы движемся?

3. Зачем мы туда идем?

4. Какие задачи нужно решить, чтобы достичь желаемого?

5. В каком порядке следует решать эти задачи?

6. Как мы поймем, что цель достигнута?

7. Что еще следует принять во внимание?

 

Согласно концепции “приоритета архитектуры”, на эти вопросы нужно ответить еще до начала проекта и руководствоваться полученными ответами в течение всей работы над ним. Кроме того, этот метод поможет достичь желаемого баланса между:

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

Замечание. Это не означает, что работу нельзя начать до тех пор, пока полностью не определена архитектура. В последующем мы продемонстрируем обоснованность и реалистичность планирования во время разработки. Другими словами, планирование, разработка и сопровождение – итерационные шаги, часто выполняемые параллельно.

 

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

 

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

двойственности – инфраструктура должна удовлетворять нужды клиентов и в то же время поддерживать задачи производства;

гибкости – необходимость приспосабливаться к постоянно изменяющемуся технологическому пейзажу и в то же время не нарушать любимого правила руководства: “Лучше, быстрее, дешевле – и срочно!”

 

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

 

От метода создания производственной архитектуры требуется:

1. считать приоритетным учет нужд промышленности и бизнеса;
2. предусматривать такие технические решения, которые делают простые вещи легкими, а сложные – возможными и выгодными;
3. обеспечить достаточную гибкость при адаптации к неизбежной эволюции технологии и организации производства.

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

 

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

 

Пояснение.

1. Логически связанный: когда все части общего плана рассматриваются вместе, они должны быть логически связанными.
2. Рутинные работы и скоординированные проекты: задачи архитектуры касаются как каждодневной деятельности, так и автономных проектов.
3. Преобразования сложившейся структуры информационных систем и приложений организации к состоянию, определенному как долгосрочная цель: архитектура должна не просто описывать текущую ситуацию – но и предлагать перспективную концепцию. Очень важно, когда она определяет ясный и оптимальный путь от текущего состояния к достижению долгосрочных целей.
4. Текущие и перспективные задачи и процессы: любой проект может оказаться бесполезным, если он не учитывает как текущую ситуацию, так и перспективы развития бизнеса и производственных процессов. С другой стороны, бизнес-планы часто формируются под влиянием достижений информационных технологий.

 

Рассмотрим принципы разработки приложений Microsoft Solution Framework. Ядром этой системы являются шесть основных моделей:

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

 

Модель производственной архитектуры. Эта модель предлагает набор принципов, обеспечивающих быстрое создание производственной архитектуры посредством выпуска версий.

 

Модель проектной группы. Она касается группы, работающей над проектом: описывает роли, обязанности каждого участника, распределение ответственности и работу группы.

 

Модель процесса разработки ПО. Эта модель описывает организационную структуру процесса разработки и руководство им в течение всего времени жизни проекта.

 

Модель управления рисками. Эта модель предлагает организованный путь активного управления рисками проекта.

 

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

 

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

 

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

 

Бизнес и промышленная перспектива состоит из множества стратегий и планов, цель которых – переход организации от сложившегося состояния к желаемому. Модель включает:

- глобальные цели и задачи организации,

- виды продуктов, товаров и услуг, производимых организацией,

- бизнес-процессы, реализующие основные функции организации и связь между ними,

- основные структуры,

- взаимодействие всех перечисленных элементов.

 

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

Рис. 1. Элементы (перспективы) производственной архитектуры

 

Информационная перспектива описывает то, что должна знать организация для решения своих задач и обеспечения нормального функционирования. Она включает:

- стандартные модели данных,

- методы организации данных и управление ими,

- описание структуры “производства” и “потребления” информации в организации.

Информационная перспектива также описывает использование данных в производственных процессах.

 

Технологическая перспектива представляет аппаратное и программное обеспечение, необходимое для работы организации. Она включает:

- персональные компьютеры и серверы,

- операционные системы,

- сетевые компоненты,

- принтеры,

- использование Интернета,

- другое периферийное оборудование,

- производственное оборудование и датчики.

 

Замечание. Хотя модель производственной архитектуры MSF включает четыре перспективы, она является, тем не менее, единой моделью. Когда организация создает производственную архитектуру, важно помнить, что ценность архитектуры не только в индивидуальных перспективах, но и в связях, взаимодействиях и зависимостях между ними.

 

Модель производственной архитектуры MSF характеризуется:

- интеграцией – интересы владельцев бизнеса и предприятия, архитектурной группы и проектных групп сбалансированы.

- итерационным подходом – архитектура решения создается посредством последовательного выпуска версий.

- работоспособностью – основная цель разработки производственной архитектуры – быстро создать промежуточную, но вполне работоспособную версию приложения. Далее проектные команды могут продолжать работу над совершенствованием архитектуры. Таким образом обеспечивается обратная связь и коррекция курса.

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

 

Модель производственной архитектуры MSF предполагает итерационный, поэтапный выпуск серии последовательных версий. При этом организация постепенно достигает желаемой цели. Как показано на рис. 2, при этом организация проходит через различные стадии, которые мы детально обсудим позже.

 

 

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

 

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

1. сложность: это многопользовательские многокомпонентные приложения, разработанные большим количеством программистов и предназначенные для обработки огромного количества данных, параллельного выполнения множества процессов и интенсивного использования распределенных ресурсов. Естественно, что используемые в них алгоритмы очень сложны.

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

3. важность: производственные приложения должны быть достаточно надежными, чтобы выдерживать непрерывную эксплуатацию. От них требуется исключительная гибкость в вопросах, касающихся масштабирования и развертывания, а также наличие средств обслуживания, мониторинга и администрирования.

На рис. 3 представлена модель производственного приложения.

 

 

Рис. 3. Модель производственного приложения

 

 

В таблице 1 представлены требования подмоделей модели производственного приложения.

 

 

Таблица 1 Требования подмоделей модели производственного приложения

 

Подмодель	Требования
Бизнес	Бизнес-цели Стоимость разработки Возврат инвестиций Сроки Безопасность и сопровождение Инвестиции в существующую инфраструктуру Бизнес-правила
Пользователи	Пользовательский интерфейс Требования к простоте использования Обучение и документация Поддержка приложения Конфигурация ПК и сетевых соединений
Логическая	Логическая структура приложения Моделирование объектов и данных Бизнес-объекты и сервисы Определение интерфейса
Технологическая	Разработка и повторное использование компонентов Средства разработки Платформы Системные технологии и технологии доступа к данным Технологии кластеризации, создания пулов и передачи сообщений
Разработки	Группа разработки Процесс разработки Управление проектом Контроль за исходным кодом Основные направления и результаты тестирования
Физическая	Физическая архитектура приложения Распределение и взаимосвязь компонентов Окончательный продукт на основе данных других подмоделей

 

 

Лекция 2. Проектные группы (2 часа)

 

Разработка производственного приложения должна проводится проектной группой (рис. 4), которая в дополнение к модели Майкрософт должна содержать научно-исследовательский компонент: специалист в предметной области, специалист-вычислитель, специалист-физик. В данном случае можно ожидать, что в запланированный срок будет разработана стабильная версия приложения с относительно оптимальными характеристиками производительности и программной реализацией математической модели, адекватной физике исследуемого процесса. Описание обязанностей каждого члена проектной группы представлены в таблице 2.

 

 

Таблица 2 Роли в проектной группе

 

Члены проектной группы	Роль в группе
Подгруппа управления
Менеджер продукта	Цель – удовлетворение требований заказчика. Главная задача – сформулировать общее представление о поставленной задаче и методе ее решения
Менеджер программы	Цель – соблюдение ограничений проекта. Главная обязанность менеджера программы – выполнить все стадии разработки так, чтобы нужный продукт был выпущен в нужное время. Он координирует деятельность других членов группы.
Подгруппа разработки
Физик	Разработка физико-математических моделей для отдельных компонентов программного комплекса.
Вычислитель	Разработка оптимальных алгоритмов численной реализации физико-математических моделей.
Программист	Разработка компонентов программного продукта, напрямую не связанных с численным моделированием.
Подгруппа внедрения
ЕН-специалист	Соответствие результатов моделирования данным наблюдений. Использование наработок и практического опыта в предметной области.
Тестер	Проведение экспериментальных исследований и тестирование программного продукта. Разработка стратегии, планов и сценариев тестирования.
Логистик	Развертывание и внедрение, постоянное сопровождение программного продукта.
Особый компонент группы
Инструктор	Цель группы обучения – повысить эффективность труда пользователей. Организация обучения пользователей работе с продуктом, разработка руководства пользователя, системы on-line помощи, специализированных Вэб-страниц, учебного курса.

 

 

Менеджер продукта вместе с менеджером программы должен прийти к компромиссному решению относительно функциональных возможностей продукта, сроков его разработки и финансирования. В небольших организациях или при работе над мелким проектом роли можно совмещать. Однако в этом случае существует другая проблема – как не упустить из виду ни одной существенной детали проекта с точки зрения каждой роли. При работе над крупными, наоборот, приходится делить проектную группу на тематические и функциональные подгруппы. Например, в рассматриваемом случае могут быть выделены подгруппы, отвечающие за разработку модулей геометрии теплового агрегата, моделирования процессов тепломассопереноса в системах агрегата. Разделение проектной группы на рис. 4 на подгруппы соответствует методологии корпорации Microsoft выделения функциональных групп, которые формируются в рамках одной роли.

 

 

 

Рис. 4. Проектные группы

 

Следует отдельно поговорить о небольших проектах. Успех проекта зависит от совмещения ролей в проектной группе. В таблице 3 приведены деструктивные и созидательные сочетания ролей.

 

Таблица 3. Деструктивные и созидательные сочетания ролей

 

	Менеджер продукта	Менеджер программы	Разработка	Тестирование	Инструктор	Логистика
Менеджер продукта		З	З	Д	Д	Н
Менеджер программы	З		З	Н	Н	Д
Разработка	З	З		З	З	З
Тестирование	Д	Н	З		Д	Д
Инструктор	Д	Н	З	Д		Н
Логистика	Н	Д	З	Д	Н

Проектная группа, рассчитывающая на успех, должна взаимодействовать с внешними группами – как с заказчиком и пользователями, так и с другими разработчиками. На рис. 5 представлена схема внутренних и внешних связей проектной группы.

 

 

Рис. 5. Схема внутренних и внешних связей проектной группы

 

 

Лекция 3, 4. Процесс разработки (4 часа)

 

Для успешного управления проектами разработки программного обеспечения необходимы два важных качества. Строгость – необходимо для постоянного контроля состояния проекта. Гибкость – требуется для успешной адаптации к неизбежным неожиданностям.

 

Большая часть материала посвящена модели процесса разработки приложений MSF (MSF Process Model for Application Development). Модель процесса MSF – это не детальная инструкция, а структурный каркас, на базе которого организации могут создавать конкретные способы решения своих задач. Модель процесса разработки – составная часть этой структуры, описывающая жизненный цикл проекта разработки программного обеспечения. Она позволяет проектной группе создавать продукт в постоянном контакте с заказчиком и адаптировать процесс в соответствие с его пожеланиями.

Любой проект разработки программного обеспечения в своем развитии проходит определенный жизненный цикл – последовательность этапов и совокупность действий, в результате которых создается первая версия продукта. Можно построить модель жизненного цикла, описывающую на некотором уровне абстракции его составляющие и порядок их определения, реализации, тестирования и выполнения. Реалистичная модель жизненного цикла упрощает выполнение проекта и гарантирует, что в проекте с каждым следующим этапом реализуется все больше запланированных задач.

Современные методы разработки приложений представляют собой квинтэссенцию опыта и практики таких традиционных моделей, как модель водопада и спиральная модель. Затем рассмотрим универсальный процесс и модель процесса разработки MSF.

 

Модель водопада. Для описания традиционного способа разработки приложений часто применяется метафора постройки дома. Сначала строитель беседует с заказчиком, выясняет, что нужно построить, проектирует здание и затем строит его по согласованному плану. По окончанию строительства подрядчик должен удостовериться, что здание устойчиво, а все его компоненты исправны и работоспособны. Затем заказчик проверяет, что все сделано в соответствии с его требованиями. Этапы постройки дома совпадают с основными стадиями модели водопада (рис. 6).

 

 

Рис. 6. Модель водопада

 

Замечание. Модель водопада в настоящее время используется сравнительно редко в связи с тем, что при ее применении на каждой стадии выполнения проекта возникают проблемы:

1. Излишние затраты времени: как правило, интеграция всех подсистем в работающее приложение занимает гораздо больше времени, чем запланировано.
2. Выявление причин, по которым необходимо изменять проект на поздних стадиях: при использовании модели водопада это обычное дело. Проверка работоспособности и реализуемости проекта приложения на ранних стадиях, как правило, не выполняется.
3. Неадекватное управление рисками: риски, связанные с проектом, выявляются на поздних стадиях выполнения проекта.
4. Отсутствие процедуры пересмотра требований: в этой модели требования должны быть сформулированы и зафиксированы на первых стадиях разработки. Как правило, цели и задачи в начале проекта осознаются не полностью, и поэтому их приходится пересматривать на поздних стадиях, что приводит к значительному росту затрат на разработку и задержке выпуска продукта.
5. Ограниченные возможности обмена информацией: традиционная практика предусматривает однократное рецензирование по окончании каждой стадии проекта. Отсутствие постоянного обмена информацией ведет к излишнему вниманию к деталям и может вылиться в непонимание между участниками проекта.
6. Отсутствие рецензирования: первые четыре этапа модели водопада, по сути, - бумажная работа, и чтобы демонстрировать прогресс проекта по окончании каждой стадии необходимо готовить массу документов. Лавинообразное нарастание проектной документации ведет к тому, что наиболее сложные стороны проекта не проверяются, а правильность их решения принимается за аксиому.

 

Спиральная модель. Применение более современных методов привело к появлению итерационного подхода к управлению процессом разработки – так называемой спиральной модели, проиллюстрированной на рис. 7.

 

 

 

 

Рис. 7. Спиральная модель

 

Эта модель подразделяется на следующие стадии:

исследование – анализ требований предварительное планирование;

проработка – проектирование приложения;

переходный период – оценка и стабилизация приложения;

создание – реализация приложения.

 

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

 

Как и модель водопада, спиральная модель порождает множество проблем. Некоторые из них перечислены ниже:

 

1. Задержка реализации функциональных возможностей: реализация сложных компонентов, представляющих особую важность для заказчиков и пользователей, откладывается на завершающие итерации. Это затягивает выполнение проекта и увеличивает стоимость работ.
2. Никогда не заканчивающиеся проекты: проекты, реализуемые по спиральной модели, часто начинают жить собственной жизнью, когда работа над проектом превращается в работу для проекта; такие проекты или никогда не заканчиваются, или заканчиваются ничем.
3. Неизвестная стоимость: постоянное повторение стадий и затягивание реализации сложных требований затрудняет оценку стоимости проекта. В свою очередь, это усложняет оценку затрат и эффективности при обосновании следующих проектов.
4. Отсутствие стабильности: постоянное изменение системы формирует у заказчиков и пользователей мнение о нестабильности продукта. Постоянное обновление всех составляющих проекта на каждой итерации резко увеличивает затраты и значительно повышает стоимость развертывания продукта.
5. Отсутствие автоматизации: необходимость инвестиций в автоматизацию процесса разработки программного обеспечения часто упускается из вида. В отсутствие средств автоматизации итерационный подход приводит к значительным задержкам выпуска продукта.

 

Универсальный процесс. Это широко распространенный метод анализа, проектирования и разработки приложений масштаба предприятия. Основные характеристики этого процесса, базирующегося на универсальном языке моделирования, таковы:

- сценарии использования как основа проекта,

- приоритет архитектуры,

- итерационный и инкрементальный процесс разработки,

- прогнозирование рисков,

- объектно- и сервисно-ориентированное проектирование,

- активное накопление и повторное использование объектно-ориентированных шаблонов, объектов и кода.

 

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

 

Этапы универсального процесса:

1. Требования: сбор бизнес-, технических и прикладных требований к проекту.
2. Анализ: бизнес-моделирование и прикладное моделирование на основе собранных требований.
3. Проектирование: создание архитектуры на основе объектно-ориентированного подхода.
4. Реализация: разработка спроектированного приложения (на ранних стадиях разработка прототипов).
5. Тестирование: проверка сделанной работы.

 

Рассмотрим более подробно этапы универсального процесса.

 

Этап “Требования”. Основной задачей этапа является направление итерации на разработку приложения в соответствии с требованиями заказчика и пользователей. Для этого необходимо описать приложение с той степенью детализации, которая достаточна для достижения согласия между заказчиком, пользователями и проектной группой относительно того, что приложение должно делать и чего оно делать не должно. Информация на этой стадии собирается из множества источников: от участников проекта, из существующих систем и документов, подготовленных заказчиком.

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

К компетенции этого этапа относится и контекст, в котором будет работать приложение. Авторы универсального процесса рекомендуют описывать контекст с помощью бизнес-моделей и моделирования предметной области. Функциональные требования, описывающие взаимодействие приложения с субъектами и объектами контекста, описываются схемами использования.

Результаты работы этапа могут быть описаны следующим образом:

1. Бизнес-модель (или модель предметной области), задающая контекст проектируемой системы.
2. Модель схем использования, описывающая функциональные и общие требования, вытекающие из конкретных схем использования. Модель представляется в форме результатов опроса, набора диаграмм и детального описания каждой схемы использования.
3. Дизайн и прототип пользовательского интерфейса для каждого актера, составляющие проект пользовательского интерфейса приложения.
4. Список дополнительных требований, не относящихся к конкретным схемам использования.

 

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

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

2. Аналитическая модель формулируется на языке разработчиков, и поэтому на этапе “Анализ” появляется формализм, позволяющий судить о внутренней структуре программной системы.

3. Аналитическая модель структурирует требования таким образом, что они становятся более понятными, тем самым подготавливая их к превращению в проектные концепции.

4. Модель, построенную на этапе анализа, можно рассматривать как первый набросок проектной модели.

Основной результат этапа “Анализ” – архитектурное представление аналитической модели. Это представление включает:

1. Анализ классов,

2. Анализ реализации схем использования,

3. Пакетирование.

 

Этап “Проектирование”. По завершению анализа можно приступить к низкоуровневому проектированию. На этом этапе выявляются классы и описывается их поведение. После чего классы распределяются на четыре уровня: стандартный пользовательский интерфейс, бизнес-уровень, уровень доступа и уровень данных.

На этапе проектирования выполняются следующие работы:

1. Определяются структуры подсистем (проектная модель).

2. Подсистемы распределяются между уровнями.

3. Определяются интерфейсы классов и объектов.

 

Этап “Реализация”. Универсальный процесс создавался на основе принципов спиральной модели, поэтому предлагает инкрементальный подход к созданию прототипов и разработке. Этот процесс циклически продолжается до тех пор, пока все необходимые функции не реализованы, а проектная группа полностью не удовлетворена реализацией.

Этап “Реализация” состоит из:

1. Реализации прототипа архитектуры,

2. Реализации компонентов (классов и объектов)

3. Тестирования компонентов.

4. Интеграции компонентов,

5. Сборки приложения,

6. Создание тестов на основе схем использования,

7. Проверки архитектуры,

8. Планирование следующей сборки,

9. Переходу к следующей итерации.

 

Этап “Тестирование”. Цель этого этапа – сверка достигнутых результатов с ожидаемыми. Тестирование начинается по окончанию этапа “Реализация” независимо от того, выпуском какого типа – внутренним, промежуточным или внешним – завершается этап. На каждом этапе тестовая модель уточняется: из нее изымаются тесты, утратившие актуальность, создаются схемы регрессионного тестирования и добавляются тесты для будущих сборок. Каждый тест реализует конкретный метод проверки определенных функций приложения и включает условия тестирования, необходимые входные данные и ожидаемые результаты. Тесты создаются на основе схем использования. Помимо тестирования приложения, необходимо предусмотреть тесты процедуры установки и корректности конфигурации приложения на каждой используемой платформе.

 

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

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

В спиральной модели приложение разрабатывается в несколько итераций. Первые итерации жизненного цикла спиральной модели позволяют уточнить модель приложения, а на последующих итерациях реализуется набор его функциональных возможностей. Спиральная модель позволяет выявить основные риски на возможно более ранних стадиях проекта и справиться с ними в первых версиях продукта. Благодаря своей итерационной природе спиральная модель легко адаптируется к изменениям требований, что позволяет повысить качество продукта. Однако для эффективности этого метода необходима высокая степень автоматизации процессов и документооборота. Многие проекты, разрабатывавшиеся по спиральной модели, так и не заканчивались – итерационный цикл продолжался без конца.

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

 

 

 

Рис. 8. Модель процесса разработки MSF

 

Модель процесса разработки MSF имеет три отличительные особенности:

1) разбиение на фазы,

2) контроль выполнения работ на каждой фазе,

3) итеративность.

 

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

Анализ, цель которого – выработать единую концепцию проекта.

Планирование, результаты которого – подробный план проекта и архитектура приложения.

Разработка, цель которой – создание полнофункционального продукта.

Стабилизация, задача которой – создание стабильного продукта, готового к развертыванию.