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

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

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

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

«Организация процесса экстремального программирования. 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)

В каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Не надо добавлять функц

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать