Федеральное агентство пообразованию
ФГАОУ ВПО «Уральский федеральныйуниверситет имени первого Президента России Б.Н.Ельцина»
Контрольная работа
«Организация процессаэкстремального программирования. ARIS-модель»
Выполнилистуденты гр. ИМ-38031:
МельниковА.Е. Семин Р.С.
гр.ИМ-38041: Ильин С.В.
Проверила:Шутова Ю.В.
Екатеринбург 2011
Оглавление
Введение
Описание нотаций ARIS
Основные концепции экстремальногопрограммирования
Описание модели «Организация процессаэкстремального программирования
Заключение
Список литературы
Приложение
/>Введение
ARIS (сокр.от англ. Architectureof IntegratedInformation Systems) —методология и программный продукт компании IDSScheer для моделирования бизнес-процессовкомпании.
Цельюнашей работы являлась разработка оптимальной и функциональной ARIS-моделидля организации процесса экстремального программирования.
Данную цель мыреализовывали через следующие задачи:
1) Ознакомлениес программой ARIS.
2) Изучениеметодологий и подходов экстремального программирования./>/>/>
Описание нотаций ARIS
/>
Длясоставления модели мы использовали следующие нотации ARIS.
Табл.1.нотации ARIS.
№
Наименование
Описание
Графическое представление 1 Функция Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия
/> 2 Событие Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
/> 3 Персонал Должности, выполняющие определенные функции на предприятии (например, программист или менеджер)
/> 4 Документ Объект, отражающий реальные носители информации, например бумажный документ
/> 8 Логическое «ИЛИ» Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
/>
Основные концепцииэкстремального программирования
Экстремальноепрограммирование (Extreme Programming, XP) возникло как эволюционный методразработки ПО «снизу-вверх». Этот подход является примером так называемогометода «живой» разработки (AgileDevelopment Method).Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой»разработки, появившемся в 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
Схема модели
/>/> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> />
/>/> /> /> /> /> /> /> /> /> /> /> /> /> /> />
/>/> /> /> /> /> /> /> /> />
/>
/>
/>