62
и содержит рекомендации весьма общего характера. Однако, эти рекоменда-
ции могут быть использованы для построения конкретного процесса, соответ-
ствующего потребностям коллектива разработчиков. [12]
Наш проект является небольшим, включает в себя 2 человека и этапы
разработки и тестирования проводятся в среде разработки C#. Кроме того, ос-
новным преимуществом MSF является итерационная модель одновременно с
уточняющими вехами (аналог каскадной модели). Таким образом, реализация
MSF попыталась объединить каскадную и итерационную модель разработки и
внедрения ПО. [13]
По описанным выше преимуществам, мною был выбран стандарт MSF
как наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возможность управ-
лять одновременно и проектом разработкой приложения и внедрением инфра-
структуры.
Этапы
Предвидение фаза процесс MSF начинается с фазы выработки концеп-
ции. Предвидение может быть определена как создание широкого описания
целей и ограничений проекта. На этом этапе команда определена и то, что ко-
манда должна выполнить для клиента. Цель фазы выработки концепции за-
ключается в создании общей концепции проекта среди всех ключевых заинте-
ресованных сторон проекта.
Методология разработки во время фазы выработки концепции команда
управления программой определяет задачи и ожидаемые результаты, которые
учитывают потребности и цели проекта. Эта фаза завершается видением /
Scope одобрил веху. Этот этап означает, что клиент и команда договариваются
о цели и направлении проекта.
Фаза планирования на этапе планирования, команда определяет, что для
разработки и планов, как создать решение. Команда готовит функциональную
спецификацию, создает дизайн решения, и готовит планы работы, сметы рас-
ходов и графики для различных результатов.
63
Этап планирования включает анализ требований. Эти требования могут
быть классифицированы как бизнес-требование, требования пользователей,
эксплуатационные требования и требования к системе. Эти требования ис-
пользуются для разработки решения и его особенности и проверить правиль-
ность конструкции.
После сбора и анализа требований, команда создает дизайн решения. Ко-
манда создает профили пользователей, которые определяют различные поль-
зователей решения и их роли и обязанности. Затем команда создает ряд сцена-
риев использования. Сценарий использования определяет деятельность, вы-
полняемую определенным типом пользователя. Таким образом, команда
должна создать сценарии использования для всех профилей пользователей.
После создания сценариев использования, команда создает случаи использо-
вания для сценариев использования. Прецедент определяет последователь-
ность шагов, которые пользователь будет выполнять в сценарии использова-
ния.
Разработка фазы во время фазы разработки, команда проекта создает ре-
шение. Этот процесс включает в себя создание кода, который реализует реше-
ния и документирование кода. В дополнение к разработке кода, команда также
развивает инфраструктуру для решения.
Процесс разработки команда выполняет следующие основные задачи на
этапе разработки:
Начиная цикл разработки. Проверка того, что все задачи, выявленные
в ходе выработки концепции и планирование этапов были завершены, так что
команда может приступить к разработке решения.
Создание приложения прототипа. Проверка концепций проекта реше-
ния в среде, которая напоминает среду, в которой решение будет в конечном
счете развернутая. Эта среда является как можно более близкой к производ-
ственной среде. Эта задача будет завершена до начала разработки.
64
Разработка компонентов решения. Разработка основных компонентов
раствора, и расширение этих компонентов к конкретным потребностям реше-
ния.
Построение решения. Серия ежедневно или частые сборки, которые
достигают высшей точки с основным внутренним строит, что означают точки,
когда команда разработчиков поставляет ключевые особенности решения.
Закрытие фазы разработки. Завершение всех функций, а также по-
ставка кода и документации. Решение считается завершенной, и команда вхо-
дит в процесс утверждения веха.
Методология разработки
Стабилизирующая фаза во время фазы стабилизации, команда выпол-
няет интеграцию, нагрузку, и бета-тестирование решения. Кроме того, ко-
манда тестирует сценарии развертывания для решения. Команда сосредото-
чена на выявлении, приоритизации и решение вопросов, с тем, что решение
может быть готовится к выпуску. На этом этапе раствор переходит от состоя-
ния всех функций, являющихся полным, как это определено в функциональ-
ной спецификации для этой версии в состоянии удовлетворения определенных
уровней качества. Кроме того, решение готово к развертыванию в бизнесе.
Результатами стабилизирующей фазы заключаются в следующем:
окончательный релиз
заметки о выпуске
поддержка производительности элементов
результаты испытаний и инструменты тестирования
исходный код и исполняемые файлы
проектные документы
обзор Milestone
Развертывание фазы на этом этапе команда развертывает технологию ре-
шения и компоненты сайта, стабилизирует развертывания, передает проект на
операцию и поддержку, и получает окончательное одобрение клиента проекта.
65
После развертывания команда проводит обзор проекта и исследование удовле-
творенности клиентов. Развертывания фазы достигает кульминации в развер-
тывании полной вехи.
Под моделью жизненного цикла понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач,
выполняемых на протяжении жизненного цикла. Модель жизненного цикла
зависит от специфики информационной системы и специфики условий, в ко-
торых последняя создается и функционирует
К настоящему времени наибольшее распространение получили следую-
щие основные модели жизненного цикла:
Модель водопада
V-образная модель
Модель эволюционного прототипирования
Спиральный метод
Итеративный и инкрементальный метод
Модель водопада на рис.2.1 представляет собой линейный последова-
тельный поток. В котором прогресс рассматривается как непрерывно нисхо-
дящий (как водопад) через фазы реализации программного обеспечения. Это
означает, что любой этап в процессе разработки начинается, только если
предыдущий этап завершен. Водопадный подход не определяет процесс воз-
врата к предыдущему этапу для обработки изменений в требованиях. Водо-
падный подход является самым ранним и наиболее широко известным подхо-
дом, который использовался для разработки программного обеспечения.
66
Рисунок 2.1 – Водопадная модель
Проекты, которые не ориентированы на изменение требований, напри-
мер, проекты, инициированные по запросу предложений, у клиента есть очень
четко задокументированные требования
Таблица 2.2 – Преимущество и недостатки водопадной модели
Преимущества
Недостатки
Легко объяснить пользователям.
Структурный подход.
Этапы и мероприятия четко опреде-
лены.
Помогает планировать и планиро-
вать проект.
Проверка на каждом этапе обеспечи-
вает раннее обнаружение ошибок /
недоразумений.
Каждый этап имеет конкретные ре-
зультаты.
Предполагается, что требования си-
стемы могут быть заморожены.
Очень сложно вернуться на какой-либо
этап после его завершения.
Немного гибкости и настройки объема
сложно и дорого.
Дорого и требует больше времени, по-
мимо подробного плана.
67
V-образная модель на рис.2.2 это расширение модели водопада. Вместо
линейного перемещения ступени процесса после фазы реализации и кодиро-
вания изгибаются вверх, чтобы сформировать типичную V-образную
форму. Основное различие между V-образной моделью и моделью водопада
заключается в раннем планировании испытаний в V-образной модели.
Рисунок 2.2 – V-образная модель
Требования к программному обеспечению четко определены и из-
вестны.
Технологии и инструменты разработки программного обеспечения хо-
рошо известны.
Таблица 2.3 – Преимущества и недостатки V-образной модели
Преимущества
Недостатки
Простой и удобный в использова-
нии
Каждый этап имеет конкрет-
ные результаты.
Очень негибкий, как модель водо-
пада.
Регулировка объема сложна и до-
рога.
68
Более высокие шансы на успех по
модели водопада из-за разра-
ботки планов испытаний на ран-
них этапах жизненного цикла.
Хорошо работает там, где тре-
бования легко понять.
Проверка и валидация продукта
на ранних этапах разработки
продукта.
Программное обеспечение разра-
батывается на этапе реализации,
поэтому ранние прототипы про-
граммного обеспечения не произ-
водятся.
Модель не дает четкого пути для
проблем, обнаруженных на этапах
тестирования.
Дорого и требует больше времени,
в дополнение к детальному плану
Модель прототипирования на рис.2.3 это относится к деятельности по
созданию прототипов программных приложений, например, неполных версий
разрабатываемой программы. Это действие, которое может происходить при
разработке программного обеспечения, и оно используется для визуализации
некоторого компонента программного обеспечения, чтобы ограничить разрыв
в неправильном понимании требований заказчика командой разработчиков.
Это также уменьшит количество итераций, которые могут возникнуть в под-
ходе с водопадом, и их трудно реализовать из-за негибкости подхода с водо-
падом. Таким образом, при разработке окончательного прототипа требование
считается замороженным.
69
Рисунок 2.3 – Модель прототипирования
Таблица 2.4 – Преимущества и недостатки модели прототипирования
Преимущества
Недостатки
Сокращение времени и за-
трат, но это может быть не-
достатком, если разработчик
теряет время на разработку
прототипов.
Улучшено и увеличено участие
пользователей.
Недостаточный анализ. Путаница
пользователя с прототипом и гото-
вой системой.
Недопонимание разработчиком
целей пользователя.
Избыточное время разработки
прототипа.
Это дорого для реализации прото-
типов
Спиральная модель (SDM) на рис.2.4 она объединяет элементы как про-
ектирования, так и поэтапного создания прототипа, чтобы объединить преиму-
щества концепций сверху вниз и снизу-вверх. Эта модель развития сочетает в
70
себе особенности модели прототипа и модели водопада. Спиральная модель
предпочтительна для больших, дорогих и сложных проектов. Эта модель ис-
пользует многие из тех же этапов, что и модель водопада, в основном в том же
порядке, разделенных планированием, оценкой риска и созданием прототипов
и симуляций.
Рисунок 2.4 – Спиральная модель
Он используется в крупных приложениях и системах, которые встроены
в небольшие фазы или сегменты.
71
Таблица 2.5 - Преимущества и недостатки спиральной модели
Преимущества
Недостатки
Оценки (т. Е. Бюджет, график и т.
Д.) Становятся более реалистич-
ными по мере продвижения ра-
боты, поскольку важные проблемы
обнаруживаются ранее.
Раннее привлечение разработчиков.
Управляет рисками и развивает си-
стему в несколько этапов.
Высокая стоимость и время
достижения конечного про-
дукта.
Требуются специальные
навыки для оценки рисков и
предположений.
Высоко настраиваемое огра-
ничение повторного исполь-
зования
Итерационная и инкрементная модель на рис.2.5 она разработана для
преодоления слабых сторон модели водопада. Она начинается с первоначаль-
ного планирования и заканчивается развертыванием с циклическими взаимо-
действиями между ними. Основная идея этого метода состоит в том, чтобы
разработать систему с помощью повторяющихся циклов (итеративно) и мень-
шими порциями за один раз (постепенно), позволяя разработчикам программ-
ного обеспечения использовать преимущества того, что было изучено при раз-
работке более ранних частей или версий системы. Может состоять из мини-
водопадов или мини-V-образной модели. [8]
Рисунок 2.5 - Итерационная и инкрементная модель