56
MSF не накладывает никаких ограничений на используемый инструментарий и
содержит рекомендации весьма общего характера. Однако, эти рекомендации
могут быть использованы для построения конкретного процесса, соответствую-
щего потребностям коллектива разработчиков. [10]
Наш проект является небольшим, включает в себя 2 человека и этапы раз-
работки и тестирования проводятся в среде разработки C#. Кроме того, основ-
ным преимуществом MSF является итерационная модель одновременно с уточ-
няющими вехами (аналог каскадной модели). Таким образом, реализация MSF
попыталась объединить каскадную и итерационную модель разработки и внед-
рения ПО.
По описанным выше преимуществам, мною был выбран стандарт MSF как
наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возможность управлять
одновременно и проектом разработкой приложения, а также внедрением инфра-
структуры.
Этапы
Предвидение, фаза процесса MSF начинается с фазы выработки концеп-
ции. Предвиденье может быть определено как создание широкого описания це-
лей и ограничений проекта. На этом этапе определена команда и то, что команда
должна выполнить для клиента. Цель фазы выработки концепции заключается в
создании общей концепции проекта среди всех ключевых заинтересованных
сторон проекта.
Методология разработки во время фазы выработки концепции команда
управления программой определяет задачи и ожидаемые результаты, которые
учитывают потребности и цели проекта. Эта фаза завершается видением. Этот
этап означает, что клиент и команда договариваются о цели и направлении про-
екта.
Фаза планирования, на этапе планирования, команда определяет, что нуж-
но для разработки плана, как создать решение. Команда готовит функциональ-
ную спецификацию, создает дизайн решения, и готовит планы работы, сметы
расходов и графики для различных результатов.
57
Этап планирования включает анализ требований. Эти требования могут
быть классифицированы как бизнес-требования, требования пользователей, экс-
плуатационные требования и требования к системе. Эти требования использу-
ются для разработки решения и в особенности для проверки правильности кон-
струкции.
После сбора и анализа требований, команда создает дизайн решения. Ко-
манда создает профили пользователей, которые определяют различные пользо-
вательские решения их роли и обязанности. Затем команда создает ряд сценари-
ев использования. Сценарий использования определяет деятельность, выполняе-
мую определенным типом пользователя. Таким образом, команда должна со-
здать сценарии использования для всех профилей пользователей. После создания
сценариев использования, команда создает случаи использования для сценариев
использования. Прецедент определяет последовательность шагов, которые поль-
зователь будет выполнять в сценарии использования.
Разработка фазы во время фазы разработки, команда проекта создает ре-
шение. Этот процесс включает в себя создание кода, который реализует решения
и документирование кода. В дополнение к разработке кода, команда также раз-
вивает инфраструктуру для решения.
В процессе разработки команда выполняет следующие основные задачи
на данном этапе:
Начало цикла разработки. Проверка того, что все задачи, выявленные в
ходе выработки концепции и планирования этапов были завершены, так что ко-
манда может приступить к разработке решения.
Создание приложения прототипа. Проверка концепций проекта реше-
ния в среде, которая напоминает среду, в которой решение будет в конечном
счете развернуто. Эта среда является как можно более близкой к производствен-
ной среде. Эта задача будет завершена до начала разработки.
Разработка компонентов решения. Разработка основных компонентов
решения, и расширение этих компонентов к конкретным потребностям решения.
Построение решения. Серия ежедневных и частых тестов, которые до-
стигают высшей точки когда команда разработчиков выявляет ключевые осо-
бенности решения.
58
Закрытие фазы разработки. Завершение всех функций, а также поставка
кода и документации. Решение считается завершенным, и команда входит в про-
цесс утверждения проекта.
Методология разработки
Стабилизирующая фаза, во время фазы стабилизации, команда выполняет
интеграцию, нагрузку, и бета-тестирование решения. Кроме того, команда те-
стирует сценарии развертывания для решения. Команда сосредоточена на выяв-
лении, приоритизации в решении вопросов, с тем, что решение может быть под-
готовлено к выпуску. На этом этапе решение переходит от состояния всех функ-
ций, являющихся полными, как это определено в функциональной специфика-
ции для этой версии в состоянии удовлетворения определенных уровней каче-
ства. Кроме того, решение готово к развертыванию в бизнесе.
Результатами стабилизирующей фазы заключаются в следующем:
окончательный релиз
заметки о выпуске
поддержка производительности элементов
результаты испытаний и инструменты тестирования
исходный код и исполняемые файлы
проектные документы
обзор решения
Развертывание фазы, на этом этапе команда развертывает технологию ре-
шения и компоненты сайта, стабилизирует развертывание, передает проект на
операцию и поддержку, и получает окончательное одобрение от клиента по про-
екту. После развертывания команда проводит обзор проекта и исследование
удовлетворенности клиентов. Фаза развертывания достигает кульминации в раз-
вертывании полной вехи.
Под моделью жизненного цикла понимается структура, определяющая по-
следовательность выполнения и взаимосвязи процессов, действий и задач, вы-
полняемых на протяжении жизненного цикла. Модель жизненного цикла зави-
сит от специфики информационной системы и специфики условий, в которых
последняя создается и функционирует. [11]
59
К настоящему времени наибольшее распространение получили следую-
щие основные модели жизненного цикла:
Модель водопада
V-образная модель
Модель эволюционного прототипирования
Спиральный метод
Итеративный и инкрементальный метод
Модель водопада на рис. 2.1 представляет собой линейный последова-
тельный поток. В котором прогресс рассматривается как непрерывно нисходя-
щий (как водопад) через фазы реализации программного обеспечения. Это озна-
чает, что любой этап в процессе разработки начинается, только если предыду-
щий этап завершен. Водопадный подход не определяет процесс возврата к
предыдущему этапу для обработки изменений в требованиях. Водопадный под-
ход является самым ранним и наиболее широко известным подходом, который
использовался для разработки программного обеспечения.
Рисунок 2.1 – Водопадная модель
60
Проекты, которые не ориентированы на изменение требований, например,
проекты, инициированные по запросу предложений когда у клиента есть ряд
очень четко задокументированных требований.
Таблица № 2.2
Преимущество и недостатки водопадной модели
Преимущества
Недостатки
Легко объяснить пользователям.
Структурный подход.
Этапы и мероприятия четко опре-
делены.
Помогает планировать и планиро-
вать проект.
Проверка на каждом этапе обес-
печивает раннее обнаружение
ошибок / недоразумений.
Каждый этап имеет конкретные
результаты.
Предполагается, что требо-
вания системы могут быть
заморожены.
Очень сложно вернуться на
какой-либо этап после его за-
вершения.
Немного гибкости и
настройки объема сложно и
дорого.
Дорого и требует больше
времени, помимо подробного
плана.
V-образная модель на рис. 2.2 это расширение модели водопада. Вместо
линейного перемещения ступени процесса после фазы реализации и кодирова-
ния изгибаются вверх, чтобы сформировать типичную V-образную фор-
му. Основное различие между V-образной моделью и моделью водопада заклю-
чается в раннем планировании испытаний в V-образной модели. Требования к
программному обеспечению четко определены и известны. Технологии и ин-
струменты разработки программного обеспечения хорошо известны.
61
Рисунок 2.2 – V-образная модель
Таблица № 2.3
Преимущества и недостатки V-образной модели
Преимущества
Недостатки
Простой и удобный в использо-
вании
Каждый этап имеет конкрет-
ные результаты.
Более высокие шансы на успех по
модели водопада из-за разра-
ботки планов испытаний на ран-
них этапах жизненного цикла.
Хорошо работает там, где тре-
бования легко понять.
Проверка и валидация продукта
на ранних этапах разработки
продукта.
Очень не гибкий, как модель водо-
пада.
Регулировка объема сложна и доро-
га.
Программное обеспечение разраба-
тывается на этапе реализации, по-
этому ранние прототипы про-
граммного обеспечения не произ-
водятся.
Модель не дает четкого пути для
проблем, обнаруженных на этапах
тестирования.
Дорого и требует больше времени,
в дополнение к детальному плану
62
Модель прототипирования на рис. 2.3 относится к деятельности по созда-
нию прототипов программных приложений, например, неполных версий разра-
батываемой программы. Это действие, которое может происходить при разра-
ботке программного обеспечения, и оно используется для визуализации некото-
рого компонента программного обеспечения, чтобы ограничить разрыв в непра-
вильном понимании требований заказчика командой разработчиков. Это также
уменьшит количество итераций, которые могут возникнуть в подходе с водопа-
дом, и их трудно реализовать из-за негибкости подхода с водопадом. Таким об-
разом, при разработке окончательного прототипа требование считается заморо-
женным.
Рисунок 2.3 – Модель прототипирования
63
Таблица № 2.4
Преимущества и недостатки модели прототипирования
Преимущества
Недостатки
Сокращение време-
ни и затрат, но это
может быть недо-
статком, если раз-
работчик теряет
время на разработ-
ку прототипов.
Улучшено и увели-
чено участие поль-
зователей.
Недостаточный анализ. Путаница пользователя
с прототипом и готовой системой.
Недопонимание разработчиком целей
пользователя.
Избыточное время разработки прототипа.
Это дорого для реализации прототипов
Спиральная модель (SDM) на рис. 2.4 она объединяет элементы как про-
ектирования, так и поэтапного создания прототипа, чтобы объединить преиму-
щества концепций сверху вниз и снизу вверх. Эта модель развития сочетает в
себе особенности модели прототипа и модели водопада. Спиральная модель
предпочтительна для больших, дорогих и сложных проектов. Эта модель ис-
пользует многие из тех же этапов, что и модель водопада, в основном в том же
порядке, разделенных планированием, оценкой риска и созданием прототипов и
симуляций.
64
Рисунок 2.4 – Спиральная модель
Он используется в крупных приложениях и системах, которые встроены в
небольшие фазы или сегменты.
Таблица № 2.5
Преимущества и недостатки спиральной модели
Преимущества
Недостатки
Оценки (т. Е. Бюджет, график и т.
Д.) Становятся более реалистичны-
ми по мере продвижения работы, по-
скольку важные проблемы обнаружи-
ваются ранее.
Раннее привлечение разработчиков.
Управляет рисками и развивает си-
стему в несколько этапов.
Высокая стоимость и
время достижения конеч-
ного продукта.
Требуются специальные
навыки для оценки рис-
ков и предположений.
Высоко настраиваемое
ограничение повторного
использования
65
Итерационная и инкрементная модель на рис. 2.5 она разработана для
преодоления слабых сторон модели водопада. Она начинается с первоначально-
го планирования и заканчивается развертыванием с циклическими взаимодей-
ствиями между ними. Основная идея этого метода состоит в том, чтобы разрабо-
тать систему с помощью повторяющихся циклов (итеративно) и меньшими пор-
циями за один раз (постепенно), позволяя разработчикам программного обеспе-
чения использовать преимущества того, что было изучено при разработке более
ранних частей или версий системы. Может состоять из мини-водопадов или ми-
ни-V-образной модели.
Рисунок 2.5 - Итерационная и инкрементная модель
Он используется в больших системах, в которые встроены небольшие фа-
зы или сегменты. Также может использоваться в системе отдельные компонен-
ты, например, система ERP. Например, мы можем начать с модуля бюджета в
качестве первой итерации, а затем мы можем начать с модуля инвентаризации и
так далее.