Организация процесса экстремального программирования. ARIS-модель (стр. 1 из 2)
Федеральное агентство по образованию
ФГАОУ ВПО «Уральский федеральный университет имени первого Президента России Б.Н.Ельцина»
Контрольная работа
«Организация процесса экстремального программирования. ARIS-модель»
Выполнили студенты гр. ИМ-38031:
Мельников А.Е. Семин Р.С.
гр. ИМ-38041: Ильин С.В.
Проверила: Шутова Ю.В.
Екатеринбург 2011
Оглавление
Введение
Описание нотаций ARIS
Основные концепции экстремального программирования
Описание модели «Организация процесса экстремального программирования
Заключение
Список литературы
Приложение
ARIS (сокр. от англ. ArchitectureofIntegratedInformationSystems) — методология и программный продукт компании IDS Scheer для моделирования бизнес-процессов компании.
Целью нашей работы являлась разработка оптимальной и функциональной ARIS-модели для организации процесса экстремального программирования.
Данную цель мы реализовывали через следующие задачи:
1) Ознакомление с программой ARIS.
2) Изучение методологий и подходов экстремального программирования.
Описание нотаций ARIS
Для составления модели мы использовали следующие нотации ARIS.
Табл.1. нотации ARIS.
| № | Наименование | Описание | Графическое представление |
| 1 | Функция | Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия |  |
| 2 | Событие | Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций |  |
| 3 | Персонал | Должности, выполняющие определенные функции на предприятии (например, программист или менеджер) |  |
| 4 | Документ | Объект, отражающий реальные носители информации, например бумажный документ |  |
| 8 | Логическое «ИЛИ» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |  |
Основные концепции экстремального программирования
Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки (AgileDevelopmentMethod). Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки, появившемся в 2000 году.
• Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
• Работающая программа более важна, чем исчерпывающая документация
• Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
• Отработка изменений более важна, чем следование планам.
«Живые» методы появились как протест против чрезмерной бюрократизации разработки ПО, обилия побочных, не являющихся необходимыми для получения конечного результата документов, которые приходится оформлять при проведении проекта в соответствии с большинством «тяжелых» процессов, дополнительной работы по поддержке фиксированного процесса организации. Большая часть таких работ и документов не имеет прямого отношения к разработке ПО и обеспечению его качества, а предназначена для соблюдения формальных пунктов контрактов на разработку, получения и подтверждения сертификатов на соответствие различным стандартам. «Живые» методы позволяют большую часть усилий разработчиков сосредоточить собственно на задачах разработки и удовлетворения реальных потребностей пользователей. Отсутствие кипы документов и необходимости поддерживать их в связном состоянии позволяет более быстро и качественно реагировать на изменения в требованиях и в окружении, в котором придется работать будущей программе.
• Живое планирование (planning game)
Его задача как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается, в первую очередь, на основе приоритетов заказчика (т.е. его потребностей, того, что нужно ему от системы для более успешного ведения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценок трудоемкости разработки, совместимости с остальными элементами системы и пр.). Планы изменяются, как только они начинают расходиться с действительностью или пожеланиями заказчика.
• Частая смена версий (small releases)
Самая первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени (от нескольких часов при небольших изменениях и небольшой программе, до месяца-двух при серьезной переработке крупной системы).
• Метафора (metaphor) системы
Метафора в достаточно простом и понятном команде виде должна описывать основной механизм работы системы. Это понятие напоминает архитектуру, но должно гораздо проще, всего в виде одной-двух фраз описывать основную суть принятых технических решений.
• Простые проектные решения (simple design)
В каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Не надо добавлять функции заранее — только после явной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.
• Разработка на основе тестирования (test-driven development)
Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.
• Постоянная переработка (refactoring)
Программисты постоянно перерабатывают систему для устранения излишней сложности, увеличения понятности кода, повышения его гибкости, но без изменений в его поведении, что проверяется прогоном после каждой переделки тестов. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат. Неудачно переработанные компоненты должны выявляться при выполнении тестов и откатываться к последнему целостному состоянию (вместе с зависимыми от них компонентами).
• Программирование парами (pair programming)
Кодирование выполняется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом решить текущую задачу. Второй программист анализирует работу первого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менее прямые, но более гибкие решения.
• Коллективное владение кодом (collective ownership)
В любой момент любой член команды может изменить любую часть кода. Никто не должен выделять свою собственную область ответственности, вся команда в целом отвечает за весь код.
• Постоянная интеграция (continuous integration)
Система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции.
• 40-часовая рабочая неделя
Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.
• Включение заказчика в команду (on-site customer)
В составе команды разработчиков постоянно находится представитель заказчика, который доступен в течение всего рабочего дня и способен отвечать на все вопросы о системе. Его обязанностью являются достаточно оперативные ответы на вопросы любого типа, касающиеся функций системы, ее интерфейса, требуемой производительности, правильной работы системы в сложных ситуациях, необходимости поддерживать связь с другими приложениями и пр.
• Использование кода как средства коммуникации
Код рассматривается как важнейшее средство общения внутри команды. Ясность кода — один из основных приоритетов. Следование стандартам кодирования, обеспечивающимтакую ясность, обязательно. Такие стандарты, помимо ясности кода, должны обеспечивать минимальность выражений (запрет на дублирование кода и информации) и должны быть приняты всеми членами команды.
• Открытое рабочее пространство (open workspace)
Команда размещается в одном, достаточно просторном помещении, для упрощения коммуникации и возможности проведения коллективных обсуждений при планировании и принятии важных технических решений.
• Изменение правил по необходимости (just rules)
Каждый член команды должен принять перечисленные правила, но при возникновении необходимости команда может поменять их ,если все ее члены пришли к согласию по поводу этого изменения.
Как видно из применяемых техник, XP рассчитано на использование в рамках небольших команд (не более 10 программистов), что подчеркивается и авторами этой методики, больший размер команды разрушает необходимую для успеха простоту коммуникации и делает невозможным применение многих перечисленных приемов.
Достоинствами XP, если его удается применить, является большая гибкость, возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков, высокое качество получающегося в результате кода и отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.
экстремальное программирование моделирование бизнес