Методы «быстрой» разработки программной системы

Курсовая работа выполнена по всем требованиям для МТИ.
Уникальность работы более 85% по етхт.
По запросу могу дополнить или изменить.

...

ВВЕДЕНИЕ 3
ГЛАВА 1 АНАЛИЗ МЕТОДОВ И МОДЕЛЕЙ БЫСТРОЙ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ 5
1.1. Специфика состава и применения модели RAD 5
1.2. Специфика состава и применения модели Agile 9
Выводы по главе 1 13
ГЛАВА 2 АНАЛИЗ СПЕЦИКИ И СОСТАВА МЕТОДОЛОГИИ ЭКСТРЕМАЛЬНОГО ПРОГРАММИРОВАНИЯ 14
2.1. Обзор ключевых принципов и особенностей XP методологии 14
2.2. Анализ существующих рисков использования методологии XP на практике 20
Выводы по главе 2 25
ГЛАВА 3 ПРОВЕДЕНИЕ И АНАЛИЗ РЕЗУЛЬТАТОВ СТАТИСТИЧЕСКОГО ОПРОСА ИСПОЛЬЗОВАНИЯ AGILE 26
3.1. Описание порядка проведения статистического опроса 26
3.2. Анализ полученных результатов 29
Выводы по главе 3 34
ЗАКЛЮЧЕНИЕ 35
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 37

Объект исследования: специфика существующих гибких методологий разработки программного обеспечения.
Предмет исследования: ключевые особенности применения XP методологии.
Цель работы заключается в закреплении, расширении, обобщении и систематизации знаний в рамках изучаемой предметной дисциплины, что достигается путем организации анализа специфики существующих гибких методологий разработки программного обеспечения.

Выводы по главе 1
В рамках данной главы проведен анализ методов и моделей быстрой разработки программных систем. В частности рассмотрена специфика состава и применения моделей RAD и Agile. Приведены схематические и концептуальные иллюстрации структуры данных моделей, описаны их преимущества и недостатки. Кратко описаны основные ценности Agile, кратко описаны популярные методологии Agile.
ГЛАВА 2 АНАЛИЗ СПЕЦИКИ И СОСТАВА МЕТОДОЛОГИИ ЭКСТРЕМАЛЬНОГО ПРОГРАММИРОВАНИЯ
2.1. Обзор ключевых принципов и особенностей XP методологии
Экстремальное программирование (XP) является сравнительно молодой методологией, созданной и получившей широкое практическое применение в начале текущего века. Основными принципами XP являются следующие [5]:
простота программных решений;
проведение разработки программного кода в интенсивном режиме малыми группами (7-10 человек), постоянное и активное общение в рамказ группы и между другими группами для обмена идеями и опытом;
регулярная обратная связь с клиентом, непосредственном задействованным в процесс создания программного продукта;
высокая степень уверенности, смелости и мотивации работы над проектами.
Ключевым фактором, обеспечивающим высокую скорость разработки является итеративность. Это проявляется в том, что разработка ПО ведется короткими итерациями с ежедневной взаимосвязью с заказчиком. Итерации предлагается делать по возможности короткими, от 2-3 недель до одного месяца. За одну пройденную итерацию группа разработчиков берет на себя ответственность за реализацию ряда свойств и функциональностей системы, каждое из которых должно быть формализовано в виде отдельной пользовательской истории (ПИ). ПИ в данном случае являются некоторой начальной информацией, на базе которой осуществляется разработка программного модуля. ПИ отличаются от используемых в языке UML прецедентов тем, что пользовательская история является достаточно краткой, от 1 до 2 абзацов текста. Прецеденты, как правило, делают достаточно подробными, с базовыми и альтернативными потоками, что позволяет сформировать точный порядок использования. Истории пользователей создаются непосредственно самими пользователями, являющихся частью всей команды, в отличие от прецедентов использования, которые обычно формирует системный аналитик. Отсутствие уровня формализации описания входных данных проекта достигается посредством компенсации активного включения в созданный процесс включения заказчика в процесс, а также за счет постоянного общения с заказчиком. В данном случае термин extreme обозначает степень привлечения заказчика к постановке задач и контролю их выполнения для снижения сроков разработки посредством коммуникации и постоянной обратной связи [7].
Дополнительным фактором ускорения разработки ПО является наличие малых групп и применения принципа парного программирования, т.е. организации труда двух программистов, которые осуществляют коллективную разработку кода на одном рабочем месте. Данный процесс нацелен на достижение необходимого уровня доверия и общения в рамках рабочей группы, а также позволяет обеспечить раннее обнаружение проблем (ошибок, просрочек и т.д.). Парное программирование позволяет достигнуть главной цели, которая заключается в максимальной стабилизации процесса создания проекта, что вызвано высокой степенью рисков потери кода и понижению надежности работы ПО из-за ухода программиста из команды, например, из-за высокого и интенсивного графика работы. В таком случае второй программист из пары способен осуществить полноценную замену, что не является достижимым в классических методиках, поэтому реализуется в виде технической документации. Важное значение, при этом, играет порядок распределения группы в рабочем пространстве, в XP чаще всего используется открытое рабочее пространство, что означает обеспечение быстрого и свободного доступа ко всем результатам работы команды разработчиков [12].
Следующим фактором ускорения разработки является принятие и реализация самого простого рабочего решения для реализации функциональности. Подобный подход обусловлен высокой степенью риска принятия не верного или не эффективного решения, обусловленного неполнотой анализа и жестким графиком времени. В связи с этим реализуется минимальный набор ключевых функций системы на первой и дальнейших итерациях, а функциональность расширяется на текущих и следующих этапах.
Как правило методология XP характеризуется некоторым набором из 12 практик, которые должны быть выполнены для достижения существенного результата. Практики XP не способны однозначно определить процесс XP, т.е. выполнение данных практик не позволяет гарантировать итоговый результат. Ни одна из практик не является новым решением, но в XP они комбинируются [14]. Практики модели XP описаны ниже и приведены на рисунке 3.
Рисунок 3 – Практики модели XP
1. Планирование процесса. Команда разработчиков собирается вместе, после чего принимается коллективное решение о перечне свойств системы, которые необходимо реализовать в будущей итерации. Набор всех свойств определяется исключительно на базе формирования перечня пользовательских историй. Трудоемкость каждой функциональности определяется разработчиками кода.
2. Регулярное взаимодействие с заказчиком, что означает небходимость регулярных встреч и коммуникации команды с клиентом или его представителями. Заказчик должен формировать пользовательские истории, выбирать доступные истории из предлагаемого перечня, которые будут реализованы в будущей итерации, выполняет пояснения и формирует ответы на вопросы, связанные с бизнес-логикой. Приветствуется, если заказчик является экспертом в рассматриваемой предметной области.
3. Метафора системы, что означает использования простых и понятных правил именования классов, интерфейсов и переменных. Команда разработчиков обязана иметь единые правила именования программного кода.
4. Простая архитектура. Любая функциональность системы должно быть реализовано, по возможности, как можно более кратко и просто. Для сокращение времени разработки принимается первое, самое простое и работающее решение, что позволяет обеспечить оперативную реализацию нужного уровня функциональности в текущий момент времени, что существенно экономит временные затраты на поиск решений.
5. Стандарты кодирования, которые в первую очередь нужны для обеспечения работы других практик, а именно для организации процессов коллективного владения кодом, разработки в паре, выполнения рефакторинга. Без единого и унифицириованного стандарта выполнять данные практики достаточно сложно, в ряде случае практически невозможно, что связано с рабочим режимом команды, характеризующимся постоянной нехваткой времени. Детальные стандарты внедрять не требуется, все сводиться лишь к формализации наиболее общих аспектов, т.к. определение в XP ключевых объектов стандартизации является субъективным [16].
6. Рефакторинг, заключающийся в оптимизации существующего программного кода в сторону его упрощения и сокращения, что предусматривает процесс постоянной работы над его улучшением. При этом необходимо следить за тем, что код остается прозрачным и его элементы определяются единожды, после чего постоянно повторно используются. Это позволяет программистам сокращать общее число ошибок, которые в дальнейшем приходиться устранять. При реализации нового свойства или функциональности системы разработчик должен подумать над тем, возможно ли упрощение существующего кода, повышение его качества и как это поможет реализовать поставленные задачи. В связи с этим возникает важная особенность: не эффективно совмещать рефакторинг с разработкой или переработкой программного дизайна системы, эти процессы должны происходить отдельно друг от друга.
7. Парное программирование. Все разработчики осуществляют процесс написания кода в парах, причем один из них пишет код, а другой в это время смотрит и анализирует. Из этого следует необходимость размещения группы программистов в рамках одного места, что существенно легче реализовать на территории заказчика. Это связано с тем, что методология XP эффективнее работает именно в нераспределенных коллективах.
8. 40-часовая неделя. Разработчику крайне не рекомендуется работать больше 8 часов в сутки. Необходимость проведения сверхурочной работы является однозначным показателем, что на дном направлении разработки существует проблема. Крайне важным является тот факт, что заказчик обычно не платит за сверхурочную работу при имплементации XP. В связи с этим необходимо постоянно осуществлять поиск причин сверхурочной работы, после чего устранять их скорейшим образом [17].
9. Коллективное владение кодом. Каждый разработчик в коллективе, работающем согласно XP, должен иметь возможность доступа к созданному коду любой части системы, обладать правами внесения изменений в любой модуль. При этом вводиться негласное правило: если разработчик внес изменения, а система перестала корректно функционировать, то данный программист должен оперативно устранить допущенные ошибки.
10. Частая смена версий. Чем чаще осуществляются выпуски новых версий (релизов) систем, тем большее количество недостатков системы можно выявить. Изначальные релизы позволяют определить недостатки на ранних стадиях, далее функциональность разрабатываемой системы расширяется. В связи с тем, что пользователь непосредственно включается в процесс разработки, начиная уже с первого релиза, он может точно оценить работу системы и сформировать или откорректировать новую пользовательскую историю. На базе этого планируется и формируется следующая итерация. Это позволяет обеспечить непрерывность обратной связи с конечными пользователями.
11. Непрерывная интеграция. Основным правилом организации интеграции является следующее: сборку проекта и релиз можно производить лишь в том случае, когда все модульные тесты пройдены успешно. В противном случае программист должен внести исправления, после чего выполнить интеграцию составных частей системы, или удалить их. Данная практика позволяет обеспечить более быстрый процесс получения готовой системы и избежать необходимости длительной сборки [7].
12. Тестирование. В отличие от большинства других Agile-методологий тестирование в XP является ключевой составляющей. В ряде случаев используется методология написания тестов перед кодом (TDD). При этом каждый модуль должен иметь свой тестовый класс, что позволяет осуществить возвратное тестирование, а большинство ошибок может быть исправлено уже на стадии кодирования. Модульные тесты создаются программистами, каждый из них может написать тест для любого модуля. Таким образом, тест определяет код, то есть фрагмент кода помещается в хранилище только в том случае, когда все тесты пройдены успешно.
Проанализировав изложенные выше факторы следует отметить, что XP крайне пренебрежительно относится к деталям процесса разработки, исключением является сам исходный код. Процесс XP является неформальным, однако требует наличия высокого уровня самодисциплины у разработчиков команды. В случае, когда это правило не выполняется, то XP лишь усугубляет процесс разработки. XP не требует от программистов создания множества формальных отчетов и построения разнородных моделей. В XP разработчик считается квалифицированным, если он с большой степенью ответственности относится ко всем своим обязанностям. В противном случае внедрение XP является бессмысленным действием. Риск возникновения проблем при разработке снижается лишь в той команде, для которой XP подходит [19].
2.2. Анализ существующих рисков использования методологии XP на практике
Следует выделить следующие наиболее вероятные риски методологии XP, которые способны усложнить процесс выполнения проекта [1]:
1. Разработчики реализуют лишь те функции, которые являются необходимыми для обеспечения возможностей, выбранных заказчиком для текущей итерации. В результате принятия подобного решения вне внимания может остаться развитие системы, что может привести к необходимости составления заглушек (моков и стабов) и переписыванию кода в процессе разработки.
2. Представитель заказчика в период выполнения командой работы над системой постоянно находится среди разработчиков, а требования к уровню его квалификации являются высокими. В случае, если заказчик не согласился или не смог предоставить персонал достаточного уровня, то проект может быть выполнен не качественно и не рационально.
3. Общий вид проектируемой системы определяется с помощью метафоры, над которой коллективно работают заказчик и разработчики. В случае, когда не ведется журнал подобного процесса и структура используемых технических наименований не является стандартизованной, то подобный процесс может быть не рационально организован и малоэффективен.
4. В каждый момент времени создаваемая система осуществляет выполнение всех тестов и поддерживает все возможные взаимосвязи, которые формируются программистом, не содержит дубликатов кода и включает в свой состав минимально возможное число классов и методов реализации функциональных возможностей. Данный принцип частично вступает в противоречие с качеством при быстрой разработке кода. Без наличия высокого уровня самодисциплины и соблюдения стандартов разработки кода система может быть выполнена не качественно [3].
5. Система запускается в эксплуатацию спустя несколько месяцев после начала реализации, не всегда имея весь перечень окончательных решений всех проблем. Периодичность сборки новых версий может изменяться от ежедневной до еженедельной. Проведение качественного тестирования функциональных возможностей системы за такой срок является крайне трудоемким проблематичным технически процессом, причем заказчик фактически выполняет функции бета-тестера. В связи с этим некоторые системы с высокими требованиями к надежности входят в первую группу риска.
6. В связи с тем, что архитектура системы постоянно меняется и эволюционирует, проект трансформируется, однако должна обеспечиваться гарантия правильного выполнения всех модульных тестов. ХР исходит из принципа, что модифицировать часть системы можно в любой момент без существенных временных затрат. Однако подобна практика рефакторинга является сложной и трудоемкой в реальных условиях.
7. Новый программный код интегрируется в созданную систему раз в несколько часов. Затем система вновь собирается в цельный программный пакет, после чего проходит проверка созданных тестов. Если хоть один из них выполнен не корректно, то все внесенные изменения разработчиками отменяются. В таком случае может быть не понятно, кто должен выявлять и исправлять ошибки, как локальные, так и вызванные неправильным кодом. Проведение подобных комплексных тестов здесь не предполагается, причем, в ряде случаев выполненные изменения сохраняются даже в случае детекции ошибки [2].
8. Весь программный код проекта пишется группой из двух человек за одним рабочим местом. При этом не всегда учитывается человеческий фактор, который играет определяющую роль, т.к. пара разработчиков могут иметь сложности в общении или сотрудничестве.
9. Объем сверхурочных работ не должен превышать по общей длительности рабочей недели. Даже отдельно взятые случаи выполнения сверхурочных работ, которые повторяются часто, являются важным признаком наличия серьезных проблем, требующих срочных мер. Как показывает современная практика использования ХР, сверхурочная работа в данном подходе является правилом, поэтому борьба с проблемами в данном случае является регулярной задачей. Усиливается актуальность такой задачи в период замены текущей версии программного продукта более совершенной. В случае, если заказчик не получает достаточных доказательств реального улучшения работы системы, это говорит о проблемах в организации процесса разработки.
10. Каждый разработчик ПО имеет возможность в любой момент времени модифицировать любую выбранную часть кода в системе. Без стандарта осуществления контроля исходного кода весь процесс разработки кода приобретает неконтролируемый и хаотический характер.
11. Команда специалистов располагается в большом помещении, которое окружено комнатами меньшего размера. В центре рабочего пространства организуются рабочие места, станции компьютеров, на которых осуществляют разработку программисты. В случае необходимости работы в территориально распределенной группе проект требует высокой степени стандартизации протокола взаимодействия между членами команды, что не всегда возможно и легко достижимо [11].
12. Программисты должны постоянно создавать тесты для программных модулей. Чтобы принять эффективное решение, необходимо своевременно понять и оценить стоимость сдачи системы с заранее известным программным дефектом, после чего выполнить сравнение с ценой задержки на его решение. Тесты, которые созданы программистами редко являются полнофункциональными, а также не учитывают всех особенностей многопользовательского процесса работы. На более сложные тесты у разработчиков часто просто нет времени. Решается подобная проблема путем привлечения на определенный срок исполнителей -контакторов, а это связано с высокой ролью человеческого фактора.
13. Члены коллектива разработчиков, которые используют ХР обязаны выполнять все изложенные правила. При этом следует помнить, что это лишь правила, поэтому команда в любой момент может изменить их, в том случае, когда ее члены достигнут соглашения по поводу всех изменений. Данный принцип существенно зависит от наличия специфики человеческого фактора. Это связано с тем, что нарушение дисциплины разработки ПО может привлечь влечет за собой срывы сроков, превышению бюджета проекта и т.д [13]. Схема диаграммы потоков процесса имплементации XP приведена на рис.4.
Рисунок 4 – Схема диаграммы потоков процесса имплементации XP
Преимущества применения ХР:
заказчик может получить такой итоговый продукт, который ему требуется, даже в тех случаях, когда он точно не представляет его итоговый вид;
команда разработчиков быстро вносит модификации в программный код и оперативно добавляет новую функциональность системы за счет простоты дизайна кода, постоянного планирования, рефакторинга и релизов проекта;
код является рабочим за счет применения модульного тестирования и серверов непрерывной интеграции;
команда программистов может легко и удобно осуществлять поддержку кода, посредством того, что он написан в соответствии с едииым стандартом;
быстрый темп создания программного продукта благодаря применению парного программирования, отсутствия существенных переработок, наличия и общения заказчика с командой;
высокое качество разработанного программного кода;
уменьшение степени рисков, которые связаны с разработкой, что объясняется тем, что итоговая ответственность за выполняемый проект распределяется равномерным образом;
затраты на разработку программного обеспечения существенно ниже, благодаря избеганию необходимости формирования перечня излишней документации [10].
Недостатками ХР являются [8]:
итоговый успех проекта сильно зависит от вовлеченности и уровня компетентности заказчика;
сложно предугадать и оценить затраты времени на выполнение проекта, в связи с тем, что в начале работы никто не знает полного перечня требований;
успех применения методологии XP сильно зависит от уровня знаний и навыков программистов, как правило, с данной практикой эффективно могут работать лишь senior-специалисты;
менеджмент часто негативно относится к ХР, т.к. трудно понимает необходимость оплаты труда двух программистов, из которых одновременно работает лишь один;
регулярные встречи и митинги с программистами могут дорого стоить заказчикам;
из-за недостатка и упрощений в формировании структуры и документации не является эффективным для применения в крупных проектах;
в связи с тем, что ХР и все гибкие методологии являются функционально-ориентированными, то различные нефункциональные требования к ПО сложно формализовать в виде пользовательских историй.
Выводы по главе 2