Федеральное агентство по образованию

ФГАОУ ВПО «Уральский федеральный университет имени первого Президента России Б.Н.Ельцина»

Контрольная работа

«Организация процесса экстремального программирования.
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, если его удается применить, является большая гибкость, возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков, высокое качество получающегося в результате кода и отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.

экстремальное программирование моделирование бизнес

Описание модели «Организация процесса экстремального программирования»

Организацию процесса экстремального программирования можно представить в виде последовательно выполняемых операций.

На первом этапе команда разработчиков, работающих в стиле XP, ожидает поступление заказа. Как только поступает заказ, менеджер команды решает – брать этот заказ или нет. Критериями отбора являются такие факторы как занятость команды, сложность проекта, опыт команды в данной области, ну и, в конечном счете, желание и способность реализовать проект. На этом этапе заключается предварительный договор между заказчиком и разработчиками.

Далее, если команда берется реализовывать проект, она просит представителей заказчика составить карточки с историями. История (story)– некоторая вещь, которую по желанию заказчика должна делать система. Затем эти карточки исследуются разработчиками на предмет возможности программной реализации историй и их целесообразности. Если у программистов появляются замечания относительно историй, предоставленных заказчиком, карточки отправляются на повторную переработку. Как только разработчики получают список историй, который устраивает их и заказчика, они переходят к планированию и согласованию даты выпуска версии программы и заключают договор с заказчиком.

Затем начинается короткий (быстрый) процесс планирования. «Вбрасывается» метафора системы. Системная метафора (system metaphor) – история, описывающая логику работы системы, которую могут рассказать любые участники проекта – заказчики, программисты и менеджеры. Далее все члены команды – менеджеры, инструктора, представители заказчика, программисты и др. занимаются планирование версии системы: отбирают истории, реализация которых более приоритетна для бизнеса (для того чтобы как можно быстрее запустить программный продукт в реальное производство), а также придумывают основные методы, средства и технологии, которые будут использованы при реализации данной версии. Планирование продолжается пока все участники процесса не придут к единому решению, которое будет всех устраивать как с точки зрения затрат ресурсов, так и с точки зрения временных затрат и будет наиболее оптимальным в конкретной ситуации.

Далее переходят непосредственно к процессу программирования. Параллельно проходит процесс модульного автоматизированного тестирования написанного кода. Программисты работают в парах и после написания очередной функциональности, выполнив рефакторинг, протестировав ее на работоспособность, интегрируют код в основной проект. Затем тестируют весь проект в целом, чтобы убедиться, что все работает. Во время всего процесса разработки в офисе с программистами находятся представители заказчика, которые должны отвечать на все вопросы команды, возникающие в процессе разработки. Таким образом, осуществляется мгновенная обратная связь.

Когда реализация версии заканчивается, она переходит к функциональному тестированию, которое осуществляют представители заказчика. На этом этапе возможно несколько ситуаций:

· в программе обнаружены ошибки – версия продукта отправляется на доработку;

· заказчик видит необходимым добавление новой истории в текущую версию программы – версия продукта отправляется на доработку;

· версия одобрена и готова для ввода в эксплуатацию на предприятии;

На предприятии программу эксплуатирую реальные пользователи, и разработчики могут сразу проследить поведение системы, увидеть потребности бизнеса. Также заказчик может оценить эффективность работы разработанного программного обеспечения и принять решение о том, нужно ли ему продолжать сотрудничать с разработчиками. Если проект убыточен либо заказчик не видит смысла в его дальнейшей модернизации, проект сворачивается. Иначе, в случае успеха проект приносит прибыль, «аппетит» заказчика повышается – он предлагает новые истории для модернизации. После чего начинается оценка этих историй и разработка очередной версии программы.

Заключение

При рассмотрении данной схемы может возникнуть ощущение, что организация процесса экстремального программирования ничем не отличается от классического подхода к разработке программного обеспечения. На самом деле это не так. Ниже перечислены основные преимущества экстремального программирования перед другими методиками:

- короткие сроки разработки версии

- контроль времени разработки

- максимально короткие сроки ввода программы в эксплуатацию

- отсутствие строгой архитектуры системы (целостность кода обеспечивается постоянным тестированием, рефакторингом дизайна, частой мелкой интеграцией кода)

- постоянная качественная обратная связь с заказчиком

- сведение к минимуму энтропии (тенденции системы к накоплению ошибок с течением времени и к существенному росту стоимости внесения в нее изменений).

- особенная внутренняя организация работы команды и рабочего пространства (небольшое количество человек, парное программирование)

Но, конечно, существуют и недостатки данного подхода: невыполнимость в таком стиле достаточно больших и сложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточно долгую перспективу и четко предсказать результаты длительного проекта в терминах соотношения качества результата и затрат времени и ресурсов. Также можно отметить неприспособленность XP для тех случаев, в которых возможные решения не находятся сразу на основе ранее полученного опыта, а требуют проведения предварительных исследований.

Список литературы

1) Кент Бек: Экстремальное программирование — Питер, 2002

2) Кент Бек: Экстремальное программирование: разработка через тестирование — Питер, 2003

Приложение 1

Схема модели