Размещено на http://allbest.ru

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ЭКОНОМИКИ И УПРАВЛЕНИЯ «НИНХ»

Информационно-технический факультет

Кафедра бизнес-информатики

РАСЧЕТНО-ГРАФИЧЕСКАЯ РАБОТА

Разработка информационной системы для репетиторской фирмы по методологии экстремального программирования

Учебная дисциплина: Управление жизненным циклом информационных систем

Новосибирск 2017

Оглавление

1. Описание методологии XP (Extreme programming)

1.1 История возникновения

1.2 Описание цели и точки зрения

1.3 Графическое изображение

1.4 Особенности

1.5 Характеристика этапов

1.6 Преимущества и недостатки

1.7 Область применения

2. Диаграммы методологии

Заключение

список использованной литературы

1. Описание методологии XP (Extreme programming)

Экстремальное программирование, или XP. Эта методология возникла примерно в 2000 году, у нее три автора -- это Кент Бек (основной автор), Уорд Каннингем и Рон Джеффрис.

В 1996 году был исторический проект Крайслер по разработке автомобилей. Он не имел серьезной программной составляющей.

И в итоге через несколько лет было принято решение проект закрыть, проект назывался С3, но те подходы, которые были разработаны в рамках этого проекта, они во многом были связаны как раз с антикризисной разработкой, с разработкой в условиях неопределенности, но разработкой, так сказать, материальной продукции, а не программных продуктов. Были в следствии использованы в той самой методологии, которая называлась экстремальное программирование.

Идеологом методологии выступил Кент Бек.

1.2 Описание цели и точки зрения

Цель: описание полного жизненного цикла разработки информационной системы для репетиторской фирмы, в соответствии с методологией XP (Extreme Programming).

Точка зрения: IT компания (исполнитель).

1.3 Графическое изображение

Графическое представление методологии ХР представлено на рисунке 1.

Рисунок 1- Графическое изображение методологии ХР

1.4 Особенности

· Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность - 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое - 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.

· Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.

· Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве - в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.

· Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.

· Достаточная степень смелости и желание идти на риск.

Обычно XP (Extreme Programming) характеризуют набором из 12 правил (практик), которые необходимо выполнять для достижения хорошего результата. Ни одна из практик не является принципиально новой, но в XP они собраны вместе.

1. Планирование процесса.

2. Тесное взаимодействие с заказчиком.

3. Общесистемные правила именования.

4. Простая архитектура.

5. Рефакторинг.

6. Парное программирование.

7. 40-часовая рабочая неделя.

8. Коллективное владение кодом.

9. Единые стандарты кодирования.

10. Небольшие релизы.

11. Непрерывная интеграция.

12. Тестирование.

1.5 Характеристика этапов

Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.

Разработка метафоры системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры -- крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования. экстремальный программирование итерация рефакторинг

Рефакторинг (refactoring). Рефакторинг -- это оптимизация существующего кода в сторону упрощения, что предусматривает постоянную работу по упрощению кода. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг надо отложить.

Парное программирование (pair programming) -- одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.

Смена версий (small releases). Минимальная итерация -- один день, максимальная -- месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.

Непрерывная интеграция (continuous integration). Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это жесткое и однозначное -- если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.

Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP -- одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test -- тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности). Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты; любой программист имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.

1.6 Преимущества и недостатки

Преимуществами XP являются:

- простота в использовании, адаптации, обучении;

- устойчивость к внешним факторам, таким как текучесть кадров, нехватка денег, внезапное

- завершение финансирования;

- учёт изменчивости требований и кардинального пересмотра всей системы;

- равномерная загруженность всех членов коллектива;

- быстрое включение в работу новичков с минимальным уровнем риска;

- эффективный контроль работоспособности разрабатываемых систем;

- увеличение производительности разработчиков;

- предоставление дополнительных благ членам коллектива;

- естественный профотбор членов команды;

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

- широкая известность и популярность.

- Недостатками XP являются:

- Невыполнимость в таком стиле достаточно больших и сложных проектов;

- невозможность планировать сроки и трудоемкость проекта на достаточно долгую перспективу;

- невозможность четко предсказать результаты длительного проекта в терминах соотношения качества результата и затрат времени и ресурсов;

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

1.7 Область применения

XP применяется, при:

- Малых и средних проектах;

- небольших и средних по размеру командах разработчиков;

- неясных или быстро меняющихся требованиях.

2. Диаграммы методологии

Рисунок 2. Диаграмма 1 уровня «Разработка ИС для репетиторской фирмы»

Рисунок 3. Диаграмма 2 уровня

Рисунок 4. Диаграмма 3 уровня

Заключение

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

Информационная система, разработанная в соответствии с методологией XP (Extreme Programming) способна изменяться в короткие сроки и давать именно то, что необходимо заказчику, поэтому целесообразнее всего использовать именно её в данной ситуации.

Список использованной литературы

1. Унифицированный процесс разработки и экстремальное программирование НОУ [Электронный курс] : лекция / ИНТУИТ : [сайт]. - Режим доступа: http://www.intuit.ru/, свободный (дата обращения 26.03.2017).

2. Extreme Programming - Экстремальное программирование [Электронный ресурс] - Режим доступа: http://www.informicus.ru/default.aspx?SECTION=6&id=95, свободный (дата обращения: 26.03.2017)

3. Методологии разработки программного обеспечения. Часть 2. Экстремальное программирование [Электронный ресурс] - Режим доступа: http://compress.ru/article.aspx?id=12147, свободный (дата обращения: 26.03.2017)

4. Экстремальное программирование: новые возможности [Электронный ресурс] - Режим доступа: http://citforum.ru/SE/project/programing.shtml, свободный (дата обращения: 26.03.2017)

Размещено на Allbest.ru