Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка информационных систем. Учебное пособие
.pdf
4.4. AGILE-методики
61
пользование матрицы компромиссов способствует урегулированию спорных вопросов.
Дисциплина «Управление рисками». Эта дисциплина трактует риски,
как неизбежное «зло» в ЖЦ информационных технологий.
Понятие риска связано с утратой или частичной потерей качества разрабатываемого продукта или услуги, увеличением затрат материальных и
финансовых ресурсов, сбоями в выполнении графика разработки и другими
факторами. Понятно, что бороться с рисками можно, предупреждая их появление, или ликвидируя последствия их возникновения. Рассматриваемая
дисциплина ориентирована на превентивные меры в отношении рисков на
всех стадиях ЖЦ продукта и установление принципов и рекомендаций по
эффективному управлению рисками.
Обычно при решении задач управления рисками выполняются следующие действия:
определяется риск и степень воздействия риска на проект;
анализируются вероятности и причины появления рисков;
вырабатываются предупредительные меры, предотвращающие риски.
Применение такого подхода позволяет подготовиться к будущим рискам, что уменьшает вероятности их появления на поздних стадиях ЖЦ.
Дисциплина «Управление подготовкой» ориентирована на повышение знаний и профессиональных навыков для успешной реализации проектов. Поэтому дисциплина в календарном плане выполнения проекта отводит время для повышения квалификации членов проектной группы, а также
анализа проделанной работы. При этом каждый исполнитель должен обмениваться знаниями с другими исполнителями.
Таким образом, рассматриваемая дисциплина устанавливает принципы
и рекомендации организации процесса управления знаниями на всём ЖЦ
проекта, что обеспечивает плановость процесса подготовки.
4.4. AGILE-методики
Agile-методики (гибкая методология разработки) – группа методов раз-
работки ПО. Среди ASD-методологий известны такие, как экстремальное
программирование, DSDM и другие.
ASD-методологии ориентированы на использование непродолжитель-
ных по времени итераций разработки, что снижает риски проекта. Дли-
4. Технологии разработки ИС
62
тельность итерации, как правило, 2–3 недели и включает все стадии ЖЦ
системы. Поэтому в ASD-методологии программный продукт готов к функционированию в конце каждой итерации, а проектная группа при этом анализирует и при необходимости меняет приоритеты в разработке.
Идеи и принципы Agile-методики. Agile-методики не содержат «цен-
ных указаний» и практических советов, но в ней заложены идеи и принципы, которые должны быть положены в основу функционирования эффективных и успешных действий команды.
Среди идей Agile выделяются следующие:
1. Коллектив и взаимодействия в нём являются более значимыми, чем
процессы и инструменты.
2. Функционирующий продукт или услуга являются более значимыми,
чем подробная документация.
3. Постоянная работа с заказчиком значительно важнее, чем согласова-
ния условий контракта.
4. Динамика в работе и восприимчивость изменений более значимы,
чем соблюдение первоначального плана.
В концепцию Agile-методик заложены следующие принципы:
1. Выполнение всех требований заказчика и регулярная поставка ему
эффективного ПО.
2. Изменение требований заказчика учитывать на всех стадиях реализа-
ции проекта, чтобы заказчик имел конкурентное преимущество.
3. Работоспособный продукт надо выпускать часто, раз в 1–2 месяца.
4. Ежедневная работа исполнителя с заказчиком.
5. Самым эффективным обменом информацией как с исполнителями,
так и исполнителей между собой является непосредственное общение.
6. Часто выпускаемый работоспособный продукт является основным
показателем вашего прогресса.
7. Простота – залог успеха, поэтому не усложняйте проект и минимизи-
руйте лишнюю работу.
8. Эффективные технические решения чаще всего создаются в самоор-
ганизующихся проектных группах.
Благодаря тому, что в Agile-методы заложен принцип непосредствен-
ного общения как с командой, так и внутри команды, то существенно сокращается объём документации по сравнению с другими методами. Кроме
4.5. Технология XP
63
того, заказчик в конце каждой итерации может менять требования, несмотря на уже созданный продукт.
4.5. Технология XP
В XP-технологии (экстремальное программирование), как и RADтехнологии, используется спиральная модель ЖЦ. Авторы технологии решили усовершенствовать известные технологии разработки ИС и ПО и
придать им некий новый уровень, вследствие чего появился термин «экстремальный».
Чтобы выяснить, подходит ли XP-технология для её использования, в
проекте оценивают такие показатели, как «критичность» и «масштаб».
Показатель критичности связывает возможные дефекты ПО с последствиями их наступления. Различают четыре уровня показателя критичности
в зависимости от того, что дефекты вызывают:
1) C – утрату удобства;
2) D – утрату возместимых ресурсов;
3) E – утрату невозместимых ресурсов;
4) L – угрозу для жизни.
Показатель масштаба связан с количеством участников в командах разработчиков:
1–6 участников – малый масштаб;
7–20 участников – средний масштаб;
более 20 участников – большой масштаб.
Учитывая эти показатели, эксперты ограничивают применение XPтехнологии проектами малого и среднего масштаба с низкой критичностью.
Процесс работы с использованием технологии XP выполняется относительно краткими итерациями длительностью 2–3 недели с широким использованием рефакторинга, т. е. когда код оптимизируется с сохранением
его функциональности. Таким образом, характерной чертой XP-технологии
является многократная оптимизация программного кода. Причём это допускается и на финальных стадиях работы над проектом. Чтобы после каждой оптимизации система сохраняла работоспособность, применяют методику TDD (Test-Driven Development – разработка через тестирование). Тестирование «вручную» практически невозможно из-за большого количе-
4. Технологии разработки ИС
64
ства тестов. Поэтому в XP-технологии предусматривается создание специальных программ (автоматических тестов) для тестирования других программ. Чтобы значительно уменьшить риск получения неработоспособного
кода в результате его неоднократных оптимизаций, тесты создают до начала работы над системой, а код, полученный после каждой итерации, обязательно тестируют.
В XP-технологии используют такие приёмы, как парное программиро-
вание, непрерывная интеграция и упрощённое проектирование.
Смысл парного программирования заключается, как это и следует из
названия, в использовании при создании кода двух программистов. Один
пишет код, другой его проверяет. При этом пары программистов не остаются постоянными, а меняются, что позволяет всем программистам знакомиться с системой в целом.
Непрерывная интеграция системы обеспечивает её целостность на
всех стадиях её создания, поэтому этот процесс фактически представляет
собой сборку системы, которая в традиционных технологиях выполняется в
конце проекта. В отличие от этих технологий в XP-технологии сборка системы производится каждый раз после тестирования всех модулей. Такой
подход позволяет контролировать и устранять проблемы интеграции ещё в
начале разработки.
Смысл упрощенного проектирования заключается в использовании
непродолжительных этапов, учитывающих изменения требований. В связи
с этим в текущий момент времени актуально простое решение задачи, которое может меняться при изменении условий (требований) задачи.
При реализации проекта все его участники обязаны следовать общим
требованиям стандартов программирования. Это требование значительно
упрощает применение рефакторинга, а также частично решает проблему
текучести кадров. В лучшем случае следование стандартам программирования должно нивелировать индивидуальность стиля разработки программного продукта, который будет ассоциироваться с работой одного человека.
4.6. RUP-технология
RUP-технология (Rational Unified Process – рациональный унифициро-
ванный процесс) – технология создания ПО, в которой используется спи-
4.6. RUP-технология
65
ральная модель ЖЦ ИС, а языком моделирования – Unified Modelling
Language (UML).
В RUP-технологии акцент сделан на начальных стадиях проекта, где
выполняется анализ и моделирование. Такой акцент обусловлен стремлением ещё в начале проекта выявить возможные ошибки и тем самым
уменьшить риски проекта. При этом по мере создания версий ПО наиболее
значимые риски должны устраняться первыми.
Одним из существенных моментов в RUP-технологии является исполь-
зование механизма прецедентов. Прецедент трактуется как фиксация (описание) некоторых допустимых или недопустимых действий ИС в ответ на
внешние факторы. Для создания прецедентов в RUP предусмотрен язык
UML. Механизм прецедентов необходим для документирования требований заказчика к ИС.
Другими существенными моментами в RUP-технологии являются:
возможность менять требования и решения на всех стадиях проекта;
мониторинг качества на всех стадиях проекта;
применение компонентной архитектуры с начальных стадий проекта.
Процессы и стадии в RUP-технологии. В RUP-технологии применя-
ется итеративная модель процесса разработки. Поэтому в разработке используются непродолжительные циклы, продвигающие начальную версию
к конечной версии. При этом процесс ориентируется на некоторые точки
проекта, в которых достигается значимый промежуточный или конечный
результат. В связи с этим рекомендуется сначала создать и внедрить работоспособную базовую версию. Затем расширять функциональность базовой
версии добавлением новых возможностей. Иногда для небольших и несложных проектов может оказаться достаточно одной версии.
Итеративный характер процесса разработки предъявляет жёсткие требования к ведению документации, которая должна меняться по ходу продвижения проекта и учитывать изменения требований к конечному продукту.
Полный ЖЦ создания ИС содержит четыре фазы, каждая из которых
допускает несколько итераций процесса разработки.
Фаза начальной стадии характеризуется следующими работами:
выработка единого понимания проекта и его ресурсов между заказ-
чиком и разработчиком;
экономическое обоснование проекта;
4. Технологии разработки ИС
66
формирование основных требований к ИС;
выполнение анализа рисков проекта.
В фазе «Уточнение» анализируются исходные данные проекта и требо-
вания заказчика, разрабатывается архитектура ИС и формируется план работ по проекту.
Фаза «Построение» – основная в создании программного кода. На этой
фазе выполняется итеративная разработка функций ИС и в результате создаётся бета-версия системы.
Фаза «Внедрение» является финальной версией системы, которая в со-
ответствии с документами передаётся заказчику. В этой фазе система испытывается, выполняется обучение пользователей и анализ качества ИС.
Среди программных продуктов, поддерживающих RUP-технологию,
можно отметить следующие:
1. Rational Rose, которое представляет собой CASE-средство для визу-
ального моделирования ИС и позволяет генерировать элементы кода, а версия – Rational Rose RealTime может генерировать исполняемый модуль.
2. Rational Requisite Pro, позволяющее мониторить и управлять требо-
ваниями на стадиях разработки, формировать и устанавливать приоритеты.
3. Rational ClearQuest фактически является единой средой, позволяю-
щей управлять требованиями и изменениями, а также выполнять мониторинг дефектов в проекте и тестирование.
4. Rational SoDA – средство автоматического формирования проект-
ной документации, регламентирующее стандарт фирменных документов.
4.7. Метод DSDM
В основе DSDM-метода (метод разработки динамических систем) лежит концепция быстрой разработки приложений (RAD) [7]. DSDM – итеративный подход к созданию ПО с активным участием заказчика.
DSDM-метод нацелен на проекты ИС с ограниченными сроками и
бюджетами, но допускающих внесение изменений в требования на любой
стадии. DSDM-метод и близкий к нему Scrum-метод входят в семейство
Agile-методик создания ПО, которое позиционируется, как семейство гибких методик. В DSDM можно подключать части других методик (RUP или
XP).
4.7. Метод DSDM
67
При создании и развитии DSDM-технологии широко использовались
следующие принципы.
1. Основой эффективной реализации проекта является постоянное вза-
имодействие разработчиков с пользователями.
2. Коллектив разработчиков может принимать решения по ведению
проекта без согласования с начальством.
3. Следование правилу: «хорошая, работающая версия продукта, вы-
полненная на какой-либо итерации, всегда лучше, чем «идеальная» версия
продукта, но поставленная в конце проекта».
4. Основной оценкой успешности проекта является быстрая поставка
ПО, удовлетворяющего функциям продукта и запросам рынка.
5. Процесс разработки должен быть итеративным и иметь обратную
связь с пользователями.
6. Изменения в процессе выполнения проекта должны быть обратимы-
ми.
7. Тестирование должно быть включено в ЖЦ разработки.
Для эффективного применения DSDM-метода необходимо:
обеспечить тесное сотрудничество между коллективом разработчи-
ков, пользователями и руководством;
выполнить (при возможности) декомпозицию проекта на более про-
стые части, чтобы использовать итеративный подход.
DSDM-метод неэффективно применять в следующих случаях:
когда к проекту предъявляют высокие требования по безопасности, т.
е. когда углублённое тестирование вступает в противоречие с соблюдением
сроков и бюджета;
когда в проекте создаются компоненты многоразового применения с
высокими требованиями.
DSDM-метод ЖЦ ИС состоит из предпроектной разработки и постпро-
ектной стадии.
На первой стадии моделируются риски, распределяются средства и
формируется команда разработчиков.
Стадия проекта является самой трудоёмкой и подробно проработанной
стадией DSDM. Как правило, эта стадия выполняется в несколько этапов,
среди которых:
анализ реализуемости и экономической целесообразности;
разработка функциональной модели;
4. Технологии разработки ИС
68
проектирование и разработка;
реализация.
На постпроектной стадии выполняется внедрение и эксплуатация системы. Сопровождение проекта условно является продолжением его разработки.
На успех проекта при использовании DSDM-метода оказывают влияние
следующие факторы:
принятие метода всеми участниками, включая руководство проекта;
желание руководства приобщить пользователей к работе над проек-
том;
постоянство проектного коллектива, обеспечивающего взаимопони-
мание внутри его.
4.8. Методология SCRUM
В подразд. 4.7 отмечалось, что DSDM-метод и близкий к нему Scrumметод входят в семейство Agile-методик создания ПО, которое позиционируется, как семейство гибких методик.
Scrum-методологию применяют в основном при гибкой разработке ПО
[8] с проведением качественного контроля процесса разработки.
Разработчики Scrum-методологии использовали несколько основных
принципов, на которых построено управление процессами:
Прозрачность – доступность сведений о процессе, которая обеспечивается стандартизацией (единые понятия и терминология);
Инспекция – мероприятия по своевременному обнаружению и устранению непредвиденных в процессе разработки отклонений.
Процесс разработки на базе Scrum-методологии реализуется фиксированными и непродолжительными итерациями, которые называются спринтами. После выполнения каждого спринта должно выпускаться работоспособное ПО с добавленными функциональными возможностями. При этом
такие возможности планируются заранее и не могут меняться. Таким образом, спринт представляет собой итерацию, после выполнения которой ПО
расширяет свою функциональность, а фиксированный и короткий спринт
способствует предсказуемости и гибкости процесса разработки.
Спринт – довольно короткая итерация (2–6 недель), а выбор её длительности является фактически компромиссом между гибкостью процесса
Вопросы для самоконтроля
69
и сокращением времени на совещания, демонстрации продукта и др. Часто
такой компромисс определяется в разных коллективах методом проб и
ошибок. В процессе выполнения спринта нельзя менять список требований
к работе, который фиксируется в журналах продукта и спринта. В первом
из них содержится ранжированный по важности список требований к
функциональности, который может меняться участниками процесса, а журнал спринта – подмножество ранжированных требований, которое будет
выполняться в текущем спринте.
В Scrum-методологии используется диаграмма сгорания задач, в кото-
рой отражается ход работы в спринте (что сделано и что осталось сделать?).
Логично представить, что если есть удобное средство для отслежива-
ния работ в спринте, то аналогичное средство должно быть и для всего
проекта.
4.9. Выводы
Рассмотренные методики представляют альтернативные варианты, позволяющие разработчику выбрать наиболее эффективную для него методику. При этом, решая задачу выбора, разработчик, как правило, учитывает
объём проекта, численность и профессиональную подготовленность разработчиков проекта, а также требования заказчика.
Рассмотренные методики могут применяться при разработке разнообразных ИС практически везде, где автоматизируется человеческая деятельность. Сходство и различия рассмотренных методик, а также полезные для
разработчика свойства, в полной мере проявляются при их практическом
использовании в процессе разработки ИС.
Вопросы для самоконтроля
1. Перечислите важнейшие функции аппарата управления коллективом.
2. Приведите график зависимости эффективности умственного труда от
глубины его разделения.
3. Почему при слишком узкой специализации труда исполнителей эф-
фективность разработки падает?
4. Приведите вариант современного разделения труда разработчиков
ИС.
4. Технологии разработки ИС
70
5. На каких принципах базируются методики разработки ПО незави-
симо от их особенностей?
6. В чём заключается принцип аналитического подхода к разработке
ИС?
7. Что означает принцип постепенного наращивания в разработке ИС?
8. Как должна формироваться документация в процессе разработки
ИС?
9. Перечислите основные моменты, связанные с RAD-технологией.
10. Раскройте особенности RAD-технологии.
11. Перечислите разновидности существующих прототипов.
12. Какие основные задачи можно решить с помощью прототипов?
13. Охарактеризуйте горизонтальные, вертикальные, одноразовые и
эволюционные прототипы.
14. Охарактеризуйте модель процессов MSF.
15. Охарактеризуйте модель проектной группы MSF.
16. Перечислите основные задачи ролевых кластеров в MSF-модели.
17. Раскройте основные идеи и принципы Agile-методики.
18. Раскройте основные идеи и принципы технология XP.
19. Что означает понятие «рефакторинг»?
20. В чём заключается смысл парного программирования?
21. Охарактеризуйте основные положения RUP-технологии.
22. На каких принципах разрабатывалась DSDM-технология?
23. В каких случаях неэффективно применять DSDM-метод?
24. На каких принципах разрабатывалась Scrum-методология?
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]