67
информации. Таким образом, необходимо, чтобы команда проекта понимает кли-
ента и его бизнеса. В противном случае это невозможно правильно реализовать
потребности клиентов. Процесс разработки программного обеспечения должен
сосредоточиться на требованиях на протяжении всего проекта. Выявление и до-
кументирование требований в начале не является достаточным. Кроме того, про-
цесс разработки программного обеспечения должен гарантировать, что не только
клиент, но и конечные пользователи участвуют в процессе формирования требо-
ваний. Успех проекта сильно зависит от этих двух групп: первая покупка про-
дукта, а второй его использования. Процесс разработки программного обеспече-
ния должен определить процедуры для подготовки конечных пользователей ис-
пользовать конечный продукт.
Архитектура привод – в современных разработках программного обеспече-
ния, архитектура системы оказывает значительное влияние на общем качестве
продукта. Одной из причин этого является интеграция в существующие системы
и окружающей среды, как большая часть сегодняшнего развития программного
обеспечения. Повторное использование приобретает все большее значение в связи
с увеличением времени и давления затрат.
Фокус на команды – команда должна рассматриваться как совокупность
равноправных лиц, которые вместе несут ответственность за качество и успеш-
ность проекта. Когда ответственность за неудачи может быть отнесена к одному
человеку, успех проекта не гарантирован больше. Сосредоточение на совместную
работу и повышает мотивацию участников проекта, так как все это рассматрива-
ется как столь же важной частью проекта. Это в конечном итоге приводит к высо-
кой идентификации членов команды с продуктом. Очевидно, что мотивированные
члены команды способствуют высокому качеству, поскольку они работают более
концентрированными и добросовестными. Процесс разработки программного
обеспечения должна включать четко определенную структуру команды, в том
числе эффективной постановки задач и четких руководящих принципов комму-
никации. MSF «команда сверстников» присваивает значение равного по каждому
члену команды и роли: полная команда имеет шесть целей для достижения и мо-
жет рассматриваться как мощные реализации принципа команды фокуса. В боль-
шинстве проектов некоторые цели имеют более высокое значение, чем другие.
68
Менеджеры решают самостоятельно или возложить ответственность за неспособ-
ность членов своей команды. MSF «команда коллег» концепция позволяет избе-
жать этих проблем и позволяет проект, чтобы получить прибыль от всех возмож-
ностей коллективной работы.
Парное программирование – парное программирование тесно связано с ак-
центом на команды, но был выбран в качестве другого критерия оценки, по-
скольку он был недооценен за свой вклад в высокое качество в прошлом. XP де-
монстрирует, как два разработчики могут дополнять друг друга, а не ингибирова-
ния друг друга. Один разработчик реализует текущий метод, а другой работает
над вопросами интеграции. Такой подход экономит время и минимизирует коли-
чество ошибок. Лучшие решения, более вероятно, так как два человека, скорее
всего, имеют разные точки зрения той же проблемы и, следовательно, дополняют
друг друга в ее решении.
Портняжное с ограничениями – процесс разработки программного обеспе-
чения должен быть определен и формализован в пути относительно его примене-
ния к широкому набору проектов. Процесс, который концентрируется на неболь-
шой или специализированный наборе проектов гарантирует высокое качество в
конкретной среде. Основной целью процесса является применение многих проек-
тов внутри компании, не снижая его прочности. Процесс должен быть адаптиро-
ван к различным проектам на основе ее основных элементов. Для того, чтобы
охватить всю сложность типовых проектов заданного набора основных элементов
должно быть сохранено. Большое количество основных элементов, не обяза-
тельно улучшить качество конечного продукта. Поэтому процесс разработки про-
граммного обеспечения должны опираться на основные элементы. Основываясь
на этих основных элементах, процесс должен определить методы для пошива про-
цесса к типу проекта и размера проекта.
Конфигурация и управление изменениями – хорошо функционирующая
конфигурация и управление изменениями (КЗУ) является важной частью обеспе-
чения качества программного обеспечения. Существование или не существование
КЗУ оказывает наибольшее влияние при обслуживании программного обеспече-
ния и развития, все же основы для КЗУ (надлежащей документации, кода архивов
источника и т.д.) должны быть установлены в процессе разработки.
69
Управление рисками – корректное понимание риска и форма управления
смягчением вместе эффективное управление рисками и является ключевым фак-
тором в достижении высокого качества продукции. Управление рисками позво-
ляет смягчить риск раннего и возможность действовать вместо реагировать на
проблемы и риски. MSF представляет свою собственную модель управления рис-
ками. Она, следовательно, делает акцент на дисциплине как важное значение для
поддержания проекта на трассе улучшая общее качество доставки. Управление
рисков как собственная дисциплина является критерием для любого процесса раз-
работки программного обеспечения с акцентом на улучшении качества программ-
ного продукта. Управление рисками в рамках ежедневных встреч и других дисци-
плин предполагает, что идентификация и управление рисками становится менее
важным, поскольку проектная группа занята другими проблемами. Проект стано-
вится восприимчивым к факторам риска. В таблице 2.1 приведены критерии для
выбора стандарта.
Таблица 2.1
Критерии для выбора стандарта
Критерий
MSF
RUP
XP
Разработка программного обеспечения Итерационной
+
+
+
Качество как цель
+
-
-
Непрерывно проверка качества
+
+
+
Требования заказчика
+
+
+
Архитектура привод
+
+
+
Фокус на команды
+
+
+
Парное программирование
+
-
-
Портняжное с ограничениями
+
+
-
Конфигурация и управление изменениями
+
-
-
Управление рисками
+
-
-
Microsoft Solutions Framework является наиболее сбалансированной техно-
логией, ориентированной на проектные группы малых и средних размеров. MSF
70
не накладывает никаких ограничений на используемый инструментарий и содер-
жит рекомендации весьма общего характера. Однако, эти рекомендации могут
быть использованы для построения конкретного процесса, соответствующего по-
требностям коллектива разработчиков.
Наш проект является небольшим, включает в себя 2 человека и этапы раз-
работки и тестирования проводятся в среде разработки C#. Кроме того, основным
преимуществом MSF является итерационная модель одновременно с уточняю-
щими вехами (аналог каскадной модели). Таким образом, реализация MSF попы-
талась объединить каскадную и итерационную модель разработки и внедрения
ПО.
По описанным выше преимуществам, мною был выбран стандарт MSF как
наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возможность управлять
одновременно и проектом разработкой приложения и внедрением инфраструк-
туры.
Этапы
Предвидение фаза процесс MSF начинается с фазы выработки концепции.
Предвидение может быть определена как создание широкого описания целей и
ограничений проекта. На этом этапе команда определена и то, что команда должна
выполнить для клиента. Цель фазы выработки концепции заключается в создании
общей концепции проекта среди всех ключевых заинтересованных сторон про-
екта.
Методология разработки во время фазы выработки концепции команда
управления программой определяет задачи и ожидаемые результаты, которые
учитывают потребности и цели проекта. Эта фаза завершается видением / Scope
одобрил веху. Этот этап означает, что клиент и команда договариваются о цели и
направлении проекта.
Фаза планирования на этапе планирования, команда определяет, что для
разработки и планов, как создать решение. Команда готовит функциональную
спецификацию, создает дизайн решения, и готовит планы работы, сметы расходов
и графики для различных результатов.
71
Этап планирования включает анализ требований. Эти требования могут
быть классифицированы как бизнес-требование, требования пользователей, экс-
плуатационные требования и требования к системе. Эти требования используются
для разработки решения и его особенности и проверить правильность конструк-
ции.
После сбора и анализа требований, команда создает дизайн решения. Ко-
манда создает профили пользователей, которые определяют различные пользова-
телей решения и их роли и обязанности. Затем команда создает ряд сценариев ис-
пользования. Сценарий использования определяет деятельность, выполняемую
определенным типом пользователя. Таким образом, команда должна создать сце-
нарии использования для всех профилей пользователей. После создания сцена-
риев использования, команда создает случаи использования для сценариев ис-
пользования. Прецедент определяет последовательность шагов, которые пользо-
ватель будет выполнять в сценарии использования.
Разработка фазы во время фазы разработки, команда проекта создает реше-
ние. Этот процесс включает в себя создание кода, который реализует решения и
документирование кода. В дополнение к разработке кода, команда также разви-
вает инфраструктуру для решения.
Процесс разработки команда выполняет следующие основные задачи на
этапе разработки:
Начиная цикл разработки. Проверка того, что все задачи, выявленные в
ходе выработки концепции и планирование этапов были завершены, так что ко-
манда может приступить к разработке решения.
Создание приложения прототипа. Проверка концепций проекта решения
в среде, которая напоминает среду, в которой решение будет в конечном счете
развернутая. Эта среда является как можно более близкой к производственной
среде. Эта задача будет завершена до начала разработки.
Разработка компонентов решения. Разработка основных компонентов
раствора, и расширение этих компонентов к конкретным потребностям решения.
Построение решения. Серия ежедневно или частые сборки, которые до-
стигают высшей точки с основным внутренним строит, что означают точки, когда
команда разработчиков поставляет ключевые особенности решения.
72
Закрытие фазы разработки. Завершение всех функций, а также поставка
кода и документации. Решение считается завершенной, и команда входит в про-
цесс утверждения веха.
Методология разработки.
Стабилизирующая фаза во время фазы стабилизации, команда выполняет
интеграцию, нагрузку, и бета-тестирование решения. Кроме того, команда тести-
рует сценарии развертывания для решения. Команда сосредоточена на выявлении,
приоритизации и решение вопросов, с тем, что решение может быть готовится к
выпуску. На этом этапе раствор переходит от состояния всех функций, являю-
щихся полным, как это определено в функциональной спецификации для этой
версии в состоянии удовлетворения определенных уровней качества. Кроме того,
решение готово к развертыванию в бизнесе.
Результатами стабилизирующей фазы заключаются в следующем:
окончательный релиз;
заметки о выпуске;
поддержка производительности элементов;
результаты испытаний и инструменты тестирования;
исходный код и исполняемые файлы;
проектные документы;
обзор Milestone.
Развертывание фазы на этом этапе команда развертывает технологию ре-
шения и компоненты сайта, стабилизирует развертывания, передает проект на
операцию и поддержку, и получает окончательное одобрение клиента проекта.
После развертывания команда проводит обзор проекта и исследование удовлетво-
ренности клиентов. Развертывания фазы достигает кульминации в развертывании
полной вехи.
Под моделью жизненного цикла понимается структура, определяющая по-
следовательность выполнения и взаимосвязи процессов, действий и задач, выпол-
няемых на протяжении жизненного цикла. Модель жизненного цикла зависит от
специфики информационной системы и специфики условий, в которых последняя
создается и функционирует
73
К настоящему времени наибольшее распространение получили следующие
основные модели жизненного цикла:
Модель водопада;
V-образная модель;
Модель эволюционного прототипирования;
Спиральный метод;
Итеративный и инкрементальный метод.
Модель водопада на рисунке 2.1 представляет собой линейный последова-
тельный поток. В котором прогресс рассматривается как непрерывно нисходящий
(как водопад) через фазы реализации программного обеспечения. Это означает,
что любой этап в процессе разработки начинается, только если предыдущий этап
завершен. Водопадный подход не определяет процесс возврата к предыдущему
этапу для обработки изменений в требованиях. Водопадный подход является са-
мым ранним и наиболее широко известным подходом, который использовался для
разработки программного обеспечения.
Рисунок 2.1 – Водопадная модель
Проекты, которые не ориентированы на изменение требований, например,
проекты, инициированные по запросу предложений, у клиента есть очень четко
задокументированные требования. В таблице 2.2 приведены преимущество и не-
достатки водопадной модели.
74
Таблица 2.2
Преимущество и недостатки водопадной модели
Преимущества
Недостатки
Легко объяснить пользователям.
Структурный подход.
Этапы и мероприятия четко определены.
Помогает планировать и планировать про-
ект.
Проверка на каждом этапе обеспечивает ран-
нее обнаружение ошибок / недоразумений.
Каждый этап имеет конкретные результаты.
Предполагается, что требования системы мо-
гут быть заморожены.
Очень сложно вернуться на какой-либо этап
после его завершения.
Немного гибкости и настройки объема сложно
и дорого.
Дорого и требует больше времени, помимо по-
дробного плана.
V-образная модель на рисунке 2.2 это расширение модели водопада. Вме-
сто линейного перемещения ступени процесса после фазы реализации и кодиро-
вания изгибаются вверх, чтобы сформировать типичную V-образную форму. Ос-
новное различие между V-образной моделью и моделью водопада заключается в
раннем планировании испытаний в V-образной модели.
Рисунок 2.2 – V-образная модель
75
Требования к программному обеспечению четко определены и известны.
Технологии и инструменты разработки программного обеспечения хорошо
известны. В таблице 2.3 приведены преимущество и недостатки V-образной мо-
дели.
Таблица 2.3
Преимущества и недостатки V-образной модели
Преимущества
Недостатки
Простой и удобный в использовании
Каждый этап имеет конкретные резуль-
таты.
Более высокие шансы на успех по модели
водопада из-за разработки планов испыта-
ний на ранних этапах жизненного цикла.
Хорошо работает там, где требования
легко понять.
Проверка и валидация продукта на ранних
этапах разработки продукта.
Очень негибкий, как модель водопада.
Регулировка объема сложна и дорога.
Программное обеспечение разрабатывается
на этапе реализации, поэтому ранние прото-
типы программного обеспечения не произ-
водятся.
Модель не дает четкого пути для проблем,
обнаруженных на этапах тестирования.
Дорого и требует больше времени, в
дополнение к детальному плану
Модель прототипирования на рисунке 2.3 это относится к деятельности по
созданию прототипов программных приложений, например, неполных версий
разрабатываемой программы. Это действие, которое может происходить при раз-
работке программного обеспечения, и оно используется для визуализации неко-
торого компонента программного обеспечения, чтобы ограничить разрыв в непра-
вильном понимании требований заказчика командой разработчиков. Это также
уменьшит количество итераций, которые могут возникнуть в подходе с водопа-
дом, и их трудно реализовать из-за негибкости подхода с водопадом. Таким обра-
зом, при разработке окончательного прототипа требование считается заморожен-
ным. В таблице 2.4 приведены преимущество и недостатки модель прототипи-
рования.
76
Рисунок 2.3 – Модель прототипирования
Таблица 2.4
Преимущества и недостатки модели прототипирования
Преимущества
Недостатки
Сокращение времени и затрат, но это
может быть недостатком, если разработ-
чик теряет время на разработку прото-
типов.
Улучшено и увеличено участие пользо-
вателей.
Недостаточный анализ. Путаница пользова-
теля с прототипом и готовой системой. Не-
допонимание разработчиком целей пользо-
вателя.
Избыточное время разработки прототипа.
Это дорого для реализации прототи-
пов