Lecture03 (1133560), страница 3
Текст из файла (страница 3)
В документациипо процессу каждая дисциплина сопровождается довольно большой диаграммой, поясняющейдействия, которые нужно выполнить в ходе работ в рамках данной дисциплины, артефакты, скоторыми надо иметь дело, и роли вовлеченных в эти действия лиц.• Моделирование предметной области (бизнес-моделирование, Business Modeling)Задачи этой деятельности — понять предметную область или бизнес-контекст, в которыхдолжна будет работать система, и убедиться, что все заинтересованные лица понимают егоодинаково, осознать имеющиеся проблемы, оценить их возможные решения и ихпоследствия для бизнеса организации, в которой будет работать система.В результате моделирования предметной области должна появиться ее модель в виденабора диаграмм классов (объектов предметной области) и деятельностей(представляющих бизнес-операции и бизнес-процессы).
Эта модель служит основоймодели анализа.• Определение требований (Requirements)Задачи — понять, что должна делать система, и убедиться во взаимопонимании по этомуповоду между заинтересованными лицами, определить границы системы и основу дляпланирования проекта и оценок затрат ресурсов в нем.Требования принято фиксировать в виде модели вариантов использования.• Анализ и проектирование (Analysis and Design)Задачи — выработать архитектуру системы на основе требований, убедиться, что даннаяархитектура может быть основой работающей системы в контексте ее будущегоиспользования.В результате проектирования должна появиться модель проектирования, включающаядиаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействиймежду объектами в ходе реализации вариантов использования, диаграммы состояний дляотдельных объектов и диаграммы развертывания.• Реализация (Implementation)Задачи — определить структуру исходного кода системы, разработать код ее компонентови протестировать их, интегрировать систему в работающее целое.• Тестирование (Test)Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценитьее качество в целом, оценить выполнены или нет гипотезы, лежащие в основепроектирования, оценить степень соответствия системы требованиям.• Развертывание (Deployment)Задачи — установить систему в ее рабочем окружении и оценить ее работоспособность натом месте, где она должна будет работать.• Управление конфигурациями и изменениями (Configuration and Change Management)Задачи — определение элементов, подлежащих хранению в репозитории проекта и правилпостроения из них согласованных конфигураций, поддержание целостности текущегосостояния системы, проверка согласованности вносимых изменений.• Управление проектом (Project Management)Задачи — планирование, управление персоналом, обеспечение взаимодействия на благопроекта между всеми заинтересованными лицами, управление рисками, отслеживаниетекущего состояния проекта.• Управление средой проекта (Environment)Задачи — подстройка процесса под конкретный проект, выбор и замена технологий иинструментов, используемых в проекте.Первые пять дисциплин считаются рабочими, остальные — поддерживающими.
Распределениеобъемов работ по дисциплинам в ходе проекта выглядит, согласно руководству по RUP, примернотак, как показано на Рис. 14.Рисунок 14. Распределение работ между различными дисциплинами в проекте по RUP.Напоследок перечислим техники, используемые в RUP согласно [3].• Выработка концепции проекта (project vision) в его начале для четкой постановки задач.• Управление по плану.••••••••••Снижение рисков и отслеживание их последствий, как можно более раннее начало работ попреодолению рисков.Тщательное экономическое обоснование всех действий — делается только то, что нужнозаказчику и не приводит к невыгодности проекта.Как можно более раннее формирование базовой архитектуры.Использование компонентной архитектуры.Прототипирование, инкрементная разработка и тестирование.Регулярные оценки текущего состояния.Управление изменениями, постоянная отработка изменений извне проекта.Нацеленность на создание продукта, работоспособного в реальном окружении.Нацеленность на качество.Адаптация процесса под нужды проекта.Экстремальное программированиеЭкстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционныйметод разработки ПО «снизу-вверх».
Этот подход является примером так называемого метода«живой» разработки (Agile Development Method). В группу «живых» методов входят, помимоэкстремального программирования, методы SCRUM, DSDM (Dynamic Systems DevelopmentMethod, метод разработки динамичных систем), Feature-Driven Development (разработка,управляемая функциями системы) и др.Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой»разработки [5], появившемся в 2000 году.• Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.• Работающая программа более важна, чем исчерпывающая документация.• Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.• Отработка изменений более важна, чем следование планам.«Живые» методы появились как протест против чрезмерной бюрократизации разработки ПО,обилия побочных, не являющихся необходимыми для получения конечного результатадокументов, которые приходится оформлять при проведении проекта в соответствии сбольшинством «тяжелых» процессов, дополнительной работы по поддержке фиксированногопроцесса организации, как это требуется в рамках, например, CMM.
Большая часть таких работ идокументов не имеет прямого отношения к разработке ПО и обеспечению его качества, апредназначена для соблюдения формальных пунктов контрактов на разработку, получения иподтверждения сертификатов на соответствие различным стандартам.«Живые» методы позволяют большую часть усилий разработчиков сосредоточить собственнона задачах разработки и удовлетворения реальных потребностей пользователей. Отсутствие кипыдокументов и необходимости поддерживать их в связном состоянии позволяет более быстро икачественно реагировать на изменения в требованиях и в окружении, в котором придется работатьбудущей программе.Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широкоиспользуемое понимание «процесса разработки» как достаточно жесткой схемы действийпротиворечит самой идее «живости» разработки), приведенную на Рис.
15.По утверждению авторов XP, эта методика представляет собой не столько следование каким-тообщим схемам действий, сколько применение комбинации следующих техник. При этом каждаятехника важна, и без ее использования разработка считается идущей не по XP, согласноутверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода, наряду с УордомКаннингемом (Ward Cunningham), и Роном Джефрисом (Ron Jeffries).• Живое планирование (planning game)Его задача — как можно быстрее определить объем работ, которые нужно сделать доследующей версии ПО. Решение принимается, в первую очередь, на основе приоритетовзаказчика (т.е.
его потребностей, того, что нужно ему от системы для более успешноговедения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценоктрудоемкости разработки, совместимости с остальными элементами системы и пр.). Планыизменяются, как только они начинают расходиться с действительностью или пожеланиямизаказчика.ИсториииспользованияНовая историяиспользованияСкорость проектаТребования«Вброс»архитектурыМетафорасистемыПланированиеверсииНенадежныеоценкиТестовыесценарииПлан версииУверенныеоценкиОшибкиИтерацияПоследняяверсияПриемочныетестыНебольшиеверсииОдобрениепользователейНовая итерация«Вброс»решенияРисунок 15.
Схема потока работ в XP.••••••Частая смена версий (small releases)Самая первая работающая версия должна появиться как можно быстрее и тут же должнаначать использоваться. Следующие версии подготавливаются через достаточно короткиепромежутки времени (от нескольких часов при небольших изменениях в небольшойпрограмме, до месяца-двух при серьезной переработке крупной системы).Метафора (metaphor) системыМетафора в достаточно простом и понятном команде виде должна описывать основноймеханизм работы системы.
Это понятие напоминает архитектуру, но должно гораздопроще, всего в виде одной-двух фраз описывать основную суть принятых техническихрешений.Простые проектные решения (simple design)В каждый момент времени система должна быть сконструирована настолько просто,насколько это возможно. Не надо добавлять функции заранее — только после явнойпросьбы об этом.
Вся лишняя сложность удаляется, как только обнаруживается.Разработка на основе тестирования (test-driven development)Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобытесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основныевозможности системы, чтобы можно было увидеть, что система действительно заработала.Постоянная переработка (refactoring)Программисты постоянно перерабатывают систему для устранения излишней сложности,увеличения понятности кода, повышения его гибкости, но без изменений в его поведении,что проверяется прогоном после каждой переделки тестов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
