Курсовая работа: Методология и технология разработки информационных систем
Одной из важных составляющих успешного проекта является качественное и непрерывные общение с заказчиком. Эффективность сотрудничества, соответствие выполняемой работы требованиям заказчика гарантируются регулярными визитами к клиенту ответственных лиц на всем протяжении работ по проекту, отчетами и докладами о статусе проекта.
Потребность в альтернативе классическим (монументальным) методологиям, которые в основном основаны на документации, привела к тому, что в 2001 году был проведен семинар, куда были приглашены представители различных адаптивных (гибких) методологий. Результатом работы стал манифест гибкой разработки ПО (Manifest for Agile Software Development) (см. Приложение 1).
Более подробно остановимся на адаптивных (гибких) методологиях, так как они наиболее активно развиваются и используются в настоящее время.
Методология SCRUM.
Данная методология предназначена для небольших команд разработчиков. Проект начинается с создания "резерва свойств системы" (backlog). Резерв свойств - это набор функций системы, которые необходимо реализовать. Сами функции могут быть описаны с помощью пользовательских сценариев или более традиционных требований. Контроль над резервом имеет только один человек, обычно это заказчик системы. Резерв постоянно изменяется, функции дополняются и сортируются по приоритетам.
После того, как резерв будет немного наполнен, начинается первая итерация. Весь проект делится на итерации (спринты) длительностью в 30 дней. Длительность итерации можно варьировать, это зависит от конкретного проекта. Для одной итерации выбирают функции, которые будут в ней реализованы. Самое важное условие - неизменность выбранных функций во время одной итерации. Это позволяет разбить весь большой проект с изменяющимися требованиями на некоторое количество фиксированных небольших итераций со стабильными требованиями.
Запланированная дата окончания итерации должна жестко соблюдаться. Команда может не реализовать некоторые из выбранных для итерации функций, но дату окончания итерации переносить нельзя.
Отличительной чертой SCRUM является проведение ежедневных 15-30 минутных совещаний, которые так и называются scrum (потасовка). В ходе этих совещаний лидер команды задает каждому следующие вопросы:
Что удалось сделать из выбранных для данной итерации функций за прошедший день?
Были ли какие-либо проблемы с реализацией?
Что планируется сделать за сегодняшний день?
Это позволяет четко отслеживать ход проекта, быстро обнаруживать возникающие проблемы и, соответственно, быстро реагировать на них.
В конце спринта команда представляет работающий продукт с запланированной функциональностью. После этого устраивается совещание, на котором обсуждаются все неожиданные моменты, с которыми столкнулись разработчики, и планируется следующая итерация. Кроме того, на этом совещании можно изменять приоритеты и вообще все изменять.
Экстремальное программирование (eXtreme Programming или XP)
Методология XP является наиболее известной из гибких методологий. Основными принципами методологии являются: простота решений, интенсивная разработка малыми группами (до 10 человек), активное общение в группе и между группами, заказчик включен в процесс разработки, достаточная степень смелости и желание идти на риск. Разработка ПО при использовании данной методологии производится небольшими итерациями (от недели до месяца) при использовании парного программирования (два программиста вместе создают код на одном общем рабочем месте). Важной особенностью методологии является принятие первого наипростейшего рабочего решения. Это связано с высокой степенью риска, обусловленного поверхностностью анализа и жестким временным графиком, при этом реализуются минимальный набор функций системы, а дальнейшая функциональность расширяется с каждой итерацией.
При использовании XP тщательное предварительное проектирование ПО заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой стороны, регулярными переработками кода. Основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода.
Семейство методологий Crystal.
Crystal - это не просто методология, это целое семейство методологий, разработанное Алистером Коберном.
Коберн рассматривает процесс создания ПО как конечную целенаправленную игру и утверждает, что у этой игры есть всего две цели: главная и вспомогательная. Главная цель заключается в том, чтобы успешно закончить проект, то есть создать работающий продукт. Второстепенная цель - подготовиться к следующей игре. Для достижения этой цели может понадобиться документация, качественное написание кода, то есть все, что облегчает дальнейшее развитие и поддержку продукта.
Если в процессе разработки достигнуты обе цели, то проект считается успешным. Помимо конечного продукта, всегда создаются вспомогательные промежуточные продукты: модели, схемы, описания и т.п. Их должно быть ровно столько, сколько необходимо для достижения конечной цели. Проблема состоит в том, что очень сложно заранее предсказать, какие промежуточные продукты нужны, а какие - нет.
Коберн классифицирует проекты по двум параметрам: критичность и величина команды. Под критичностью понимается величина ущерба, нанесенного в результате использования продукта. Например, ошибка в ПО для космического корабля или для аппарата искусственного дыхания несравнима с ошибкой в ПО для форума на сайте. Жизненно важные проекты имеют категорию L, а те, ошибка в которых обозначает потерю удобств, категорию С.
Степень важности нараст?