И. А. Кудрявцев аучный - реферат

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

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Факультет информатики

Кафедра прикладной информатики

УДК 681.03

ДОПУСТИТЬ К ЗАЩИТЕ В ГАК

Зав. кафедрой, проф., д.т.н.

________________ С.П. Сущенко

«___» ___________ 2008 г.

Портасенок Анастасия Владимировна

РАЗРАБОТКА СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ, ОСНОВАННОЙ НА МЕТОДОЛОГИИ SCRUM

Дипломная работа

И.А. Кудрявцев

Научный руководитель

А.В. Портасенок

Исполнитель,

студ. гр. 1432

Электронная версия дипломной работы помещена

в электронную библиотеку. Файл

Администратор

Томск – 2008

Реферат

Дипломная работа 43 с., 23 рис., 8 источников, 3 прил.

Цель работы – создание системы управления проектами для компании ООО «Битворкс».

Цель работы заключалась в том, чтобы изучить всевозможные методологии разработки программного обеспечения и выбрать наиболее подходящую для данной компании. На ее основе было необходимо создать систему управления проектами. В качестве подготовки к реализации нужно было изучить язык программирования Python, фреймворк Django и СУБД MySQL.

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

Содержание

Введение 4

1 Постановка задачи 5

2 Гибкие методологии разработки и их виды 6

2.1 Что выбрать: гибкость или тяжеловесность? 6

2.2 Итеративность и формализованность 7

2.3 Обзор гибких методологий 9

2.3.1 Почему Scrum? 9

2.3.2 Scrum 10

2.4 Альтернативные продукты, основанные на Scrum 14

3 Используемые технологии 15

3.1 Django 15

4 Анализ и проектирование 20

4.1 Роли в системе 20

4.2 Проектирование схемы базы данных 23

4.3 Прототип системы 25

5 Схема приложения 28

Заключение 29

Список использованных источников 30

Приложение А «Текстовое описание вариантов использования» 31

Приложение Б «Реляционная схема базы данных» 39

Приложение В «Руководство пользователя» 40

Введение

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

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

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

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

Безусловно, в настоящее время существует много различных систем управления проектами, и абстрактных, и основывающихся на конкретных методологиях, но целью данной работы являлось провести анализ существующих методологий разработки программного обеспечения и выбрать из них наиболее подходящую для конкретной компании - OOO «Битворкс», далее компания-заказчик - которая будет удовлетворять всем ее требованиям. Затем, основываясь на выбранной методологии, создать систему управления проектами, которая полностью будет подстроена под нужды указанной компании. Кроме того, заказчиком были выставлены условия по технологической базе: система должна быть написана на языке Python с использованием фреймворка Django, а для работы с базами данных должна использоваться СУБД MySQL.

Постановка задачи

В каждом проекте всегда выделяется некоторый набор задач, которые должны быть реализованы для успешного его завершения. А если проект крупный, то этот набор будет иметь достаточно большой вес. Декомпозиция концептуальных требований может быть глубокой, и удержать это все в голове просто нереально. Бумажные технологии уже давно ушли в прошлое, это и неудобно, и менее надежно. А значит, нужна система, структурирующая требования и позволяющая отслеживать изменения в них.

Каждому разработчику в команде раздаются задачи для исполнения, они распределяются менеджером проекта или самими членами команды. Чтобы можно было безошибочно следить за их исполнением, за прогрессом работы, равномерно распределять нагрузку между людьми, да и вообще помнить, что с кого спрашивать, тоже нужно какое-то программное обеспечение. Как известно, один менеджер может поддерживать должный уровень коммуникации в команде, состав которой не превышает 8 человек. Если же происходит так, что количество человек больше, то потерять контроль над проектом проще простого. Кроме того, каждая задача требует примерной временной оценки для составления прогноза на разработку, чтобы быть уверенными, что к определенному сроку будет готов определенный функционал. Конечно, для этих целей можно просто использовать Excel, но при больших объемах информации вести такой документ - это слишком большая нагрузка для менеджера, занимающая много времени, а поддержание подобных вещей нужно не только ему, но и самим разработчикам тоже, чтобы не путаться в своих задачах и следить за тем, укладываются ли они в те временные рамки, которые были выставлены.

И не стоит забывать о таком факте, что один менеджер может заниматься не одним проектом, а сразу несколькими. В этом случае ему постоянно приходится переключаться между ними, а значит и здесь ему необходима помощь, чтобы этот процесс переключения происходил быстро, и чтобы можно было легко восстановить картину по конкретному проекту.

Программистов, участвующих в проекте, нельзя рассматривать просто как ресурсы, это обычные люди, поведение каждого из которых нельзя предугадать, и нельзя изначально возлагать на какого-то человека ответственность за успех проекта, особенно если он недавно пришел в команду. Для того чтобы правильно оценивать силы конкретного разработчика, нужно сначала присмотреться к нему, собрать определенную статистику. Например, нужно понаблюдать за тем, какие оценки на свои задачи он ставит. Если в течение долгого периода времени он переоценивает свои возможности и ставит меньше времени, чем реально требуется ему на решение, то впоследствии необходимо это учитывать и корректировать его оценки в сторону повышения. Если же наоборот, программист недооценивает и постоянно ставит больше, чем тратит на самом деле, следует снижать поставленное им время. Во всем этом также легко поможет качественная система управления проектами, в которой не составит труда просмотреть данные по каждому разработчику и оценить его работу.

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

Подведя итог всему вышесказанному, можно утверждать, что эффективная система управления проектами является свидетельством зрелости и уровня организации компании и помогает ей развиваться.

Гибкие методологии разработки и их виды

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

1.1 Что выбрать: гибкость или тяжеловесность?

Как правило, разработка программного обеспечения представляет собой довольно хаотическую деятельность, которую нередко можно охарактеризовать фразой "code and fix" ("пишем и правим"). Единого плана не существует, а общий проект представляет собой просто смесь краткосрочных решений. Такой подход может сгодиться для небольшой системы, однако если система начинает расти, добавлять в нее новые свойства становится все более затруднительно [1]. Не стоит забывать и о том, что чем больше система, тем больше в ней появляется ошибок, которые все сложнее и сложнее исправлять. А это означает, что большинство крупных создаваемых систем имеют долгий тестовый период, хотя разработка всей функциональности давно закончена. Редко какие компании закладывают в план проекта этот отрезок времени, а потому очень часто происходит срыв сроков сдачи проекта. А точнее сказать, закладываться-то - он закладывается, но не настолько продолжительный, какой он получается в реальности, так как при подобном тестировании и исправлении ошибок адекватное планирование просто невозможно.

Однако у команд всегда была альтернатива - использовать методологию разработки, которая превращает создание программного продукта в упорядоченный процесс, с помощью которого можно сделать работу программиста более прогнозируемой и эффективной [1]. Для достижения этой цели создается детальное описание процесса, важное место в котором занимает планирование. Казалось бы - вот решение проблемы непредсказуемости разработки и выхода за рамки установленных сроков. Однако в подобных методологиях есть один существенный недостаток, из-за которого большинство команд программистов от них отказываются. Чтобы сделать процесс разработки предсказуемым, необходимо наладить дисциплину внутри коллектива, а для этого нужно точно следовать предписаниям методологии и выполнять множество различных вспомогательных действий, что зачастую замедляет весь темп работ. И в итоге использование такого подхода часто становится бессмысленным. Именно поэтому такие методологии разработки программного обеспечения называют тяжеловесными, или, согласно термину Джима Хайсмита, - монументальными.

Несколько лет назад такое положение дел натолкнуло методологов на мысль, что нужно как-то менять процесс создания программных продуктов, и на свет появилась группа новых, облегченных методологий, которые коренным образом отличаются от монументальных. В настоящее время наиболее распространенный для них термин - гибкие (agile). Они являют собой нечто среднее между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу [1].

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

"- Гибкие методологии адаптивны, а не предсказуемы. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, и такой подход работает - но до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих.

- Гибкие методологии ориентированы на человека, а не на процесс. В них ясно заявлено о необходимости учитывать в работе природные качества человеческой натуры, а не действовать им наперекор. Кроме этого в гибких методологиях особо подчеркивается, что работа по созданию программных продуктов должна приносить удовольствие. " [1].

1.2 Итеративность и формализованность

Одними из главных критериев для сравнения методологий разработки программных продуктов являются итеративность и формализованность. В соответствии с этими критериями методологии бывают каскадные / итеративные и низкоформализованные / высокоформализованные.

Большая часть команд, разрабатывающих программное обеспечение, до сих пор используют в своих проектах каскадную разработку, при которой фазы выполняются в четкой последовательности: сначала требования, затем анализ и проектирование, потом реализация/интеграция и затем тестирование. Такой подход заставляет ключевых членов группы простаивать довольно продолжительное время, а тестирование откладывается на самый конец жизненного цикла проекта, когда становится дорого исправлять какие-то серьезные ошибки, и это ставит под угрозу сроки выхода конечно го продукта.

Итеративный подход - это последовательность нарастающих шагов или итераций. Каждая итерация включает в себя некоторые или большую часть дисциплин разработки. У каждой итерации есть четко определенный набор целей, и она создает частично работающую реализацию конечной системы. Каждая последующая итерация строится на результатах предыдущих, развивает и усовершенствует систему до тех пор, пока не будет создан конечный продукт [2]. В процессе итеративной разработки рабочие версии системы, имеющие некий ограниченный набор требуемых свойств, производятся достаточно часто. Таким промежуточным версиям недостает функциональности, однако, во всем остальном они полностью соответствуют конечной системе. Промежуточные варианты системы должны быть полностью интегрированы и так же хорошо оттестированы, как и конечная версия продукта. Все гибкие методологии используют именно итеративный подход, и это не случайно.

Итеративный подход оказывается эффективнее по нескольким показателям.

Он приспособлен к меняющимся требованиям. Изменение требований и добавление новых свойств, определяемое заказчиком или нуждами технологии всегда было самым главным источником бед проектов. Оно приводило к опозданию с выпуском, нарушению графиков, неудовлетворению заказчиков и раздражению разработчиков [2]. Однако, это нормальная практика в разработке программного обеспечения, и было бы глупо этому удивляться. Конечно, можно считать, что часто меняющиеся требования – результат плохой проработки требований, однако дела обстоят далеко не всегда таким образом. Ведь сразу определить все возможные варианты требований непросто. Только получив какую-то версию системы, можно оценить, какие ее свойства важны, а какие абсолютно ненужные и неудобные. Выполнить проект без изменений можно, но это грозит выпуском продукта, который не будет иметь никакой коммерческой ценности. К тому же, не стоит забывать о таком важном факторе, как время. В мире бизнеса и информационных технологий не стоит на месте, а движется вперед стремительными темпами, поэтому то, что актуально сегодня, через полгода окажется устаревшим. А если проект рассчитан не на один год, то с самого начала проекта следует готовиться к меняющимся требованиям со стороны заказчика.
Интеграция – это не один «большой взрыв» в конце проекта. Оставить интеграцию на самый конец означает получить переработки с большими затратами времени – иногда до 40% всего объема проекта [2]. Чтобы этого не допустить, итеративный подход предлагает разбить весь процесс разработки на небольшие итерации, в конце каждой из которых должна быть готова полноценная рабочая версия системы, полностью оттестированная и интегрированная. А значит, переработка минимизируется.
Риски обычно обнаруживаются и устраняются на ранних итерациях. Итеративный подход минимизирует риски на ранних стадиях, когда тестируются все компоненты [2]. Он позволяет вовремя понять, является ли предполагаемый риск реальным, и выявить новые. В начале проекта это сделать гораздо легче и несильно дорого.
Менеджеры имеют возможность внесения тактических изменений в продукт. Итеративная разработка быстро создает исполняемую архитектуру (хотя и с ограниченной функциональностью), которую можно использовать для быстрого выпуска продукта с некоторыми ограничениями [2].
Облегчается повторное использование. Гораздо легче определить общие части тогда, когда они уже частично спроектированы или реализованы в итерациях, чем распознать их при планировании. Рецензирование проектных решений на ранних итерациях позволяет архитекторам указать на потенциальные возможности для повторного использования и затем разработать в последующих итерациях зрелый общий код для реализации таких возможностей [2].
Дефекты можно найти и исправить за несколько итераций , что обеспечивает создание четкой архитектуры и высококачественного приложения. Узкие места обнаруживаются еще на ранних итерациях, а не в конце проекта при глобальном тестировании.
Лучшее использование персонала в проекте. Многие организации совмещают использование каскадного подхода с организацией по типу конвейера: аналитики посылают готовые требования проектировщикам, которые отсылают свой продукт программистам, которые посылают компоненты специалистам по интеграции, которые отсылают систему тестировщикам. Такие многочисленные переходы являются источниками ошибок и недопонимания и заставляют людей меньше чувствовать ответственность за конечный продукт. Итеративный процесс расширяет области компетенции членов группы, разрешая им выполнять много ролей, позволяя менеджеру проекта лучше использовать имеющийся персонал, и одновременно убирает вредные передачи. [2]
Члены команды учатся на ходу. Участники проекта на протяжении цикла разработки получают возможность учиться на своих ошибках от итерации к итерации.
Улучшается процесс разработки сам по себе и становится по ходу работы более совершенным. В конце каждой итерации участники проекта могут оценить организацию процесса и внести в него необходимые корректировки, если что-то не будет подходить их команде.

1.3 Обзор гибких методологий

Существует много гибких методологий разработки, однако остановимся только на некоторых из них, наиболее известных и развитых:

· XP

· Scrum

· Crystal

· RUP

Здесь стоит сделать оговорку. RUP как таковой не является гибкой методикой, однако существует возможность настроить его таким образом, что он превратится в низкоформализованный, итеративный процесс.

Итак, эти методологии ориентированы на итеративную разработку программного обеспечения, а также или изначально созданы как низкофрмализованные, или существует возможность настроить их на минимальную формализацию процесса.

1.3.1 Почему Scrum?

Рассмотрим Scrum в сравнении с остальными методологиями, и таким образом объясним, почему для разрабатываемой системы была выбрана именно она.

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

· XP – это больше набор методик, которые ничто не мешает внедрить и в другие методологии, в тот же Scrum или RUP. Они никак друг другу не противостоят. Scrum – это всего лишь каркас, а работу внутри самой команды можно наладить различными способами, включая, например, парное программирование.

· Если рассматривать RUP в его тяжелом варианте, то он совершенно не подходит для компании-заказчика, потому как создание слишком большого объема артефактов при коротких проектах – совершенно не выгодно. Облегченный же RUP – более подходящий, однако для его внедрения необходимо, чтобы весь управляющий персонал, включая менеджеров, досконально его знали, чтобы процесс разработки пошел в нужном направлении. В этом случае тоже требуются достаточно большие усилия и некоторая перестройка того процесса, который естественным образом сложился в компании. Scrum же очень близок к существующему на данный момент процессу заказчика, поэтому его внедрение займет минимум усилий и затрат.

· Из семейства методологий Crystal самой подходящей является Crystal Clear, но уж очень она абстрактная и общая. В ней не предусмотрены конкретные меры по организации работы в коллективе или планированию, а значит, в эффективности она проигрывает остальным методологиям, а по своей жесткости очень далеко отстоит от XP. Она не имеет смысла внедрения в работу компании-заказчика, так как по большому счету процесс, описанный Crystal, сам по себе сложился в данной организации.

1.3.2 Scrum

Для того чтобы иметь полное представление о выбранной для компании-заказчика методологии разработки, приведем наиболее подробное ее описание.

Методология Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта.

Основа Scrum — итеративная разработка. Scrum определяет правила, по которым должен планироваться и управляться список требований к продукту для достижения максимальной прибыльности от реализованной функциональности; правила планирования итераций для максимальной заинтересованности команды в результате; основные правила взаимодействия участников команды для максимально быстрой реакции на существующую ситуацию; правила анализа и корректировки процесса разработки для совершенствования взаимодействия внутри команды. Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.

Scrum — простой каркас, который можно использовать для организации команды и достижения результата более продуктивно и с более высоким качеством за счет анализа сделанной работы и корректировки направления развития между итерациями. Методология позволяет команде выбрать задачи, которые должны быть выполнены, учитывая бизнес-приоритеты и технические возможности, а также решить, как их эффективно реализовать. Это позволяет создать условия, при которых команда работает с удовольствием и максимально продуктивно. К примеру, возможность самостоятельного выбора объема и пути решения задач без внешнего давления позволяет всем участникам команды почувствовать себя активными игроками, вовлеченными в процесс, а не простыми исполнителями, от которых требуется лишь четкая реализация поручений.

Scrum фокусируется на постоянном определении приоритетных задач, основываясь на бизнес целях, что увеличивает полезность и доходность проекта на его ранних стадиях. Так как при инициации проекта его доходность определить почти невозможно, Scrum предлагает концентрироваться на качестве разработки и к концу каждой итерации иметь промежуточный продукт, который можно использовать, пусть и с минимальными возможностями. Например, результатом итерации может быть каркас сайта, который можно показать на презентации.

Методология Scrum ориентирована на то, чтобы оперативно приспосабливаться к изменениям в требованиях, что позволяет команде быстро адаптировать продукт к нуждам заказчика. Такая адаптация достигается за счет получения обратной связи по результатам итерации: имея после каждой итерации продукт, который уже можно использовать, показывать и обсуждать, легче собирать информацию и делать правильные корректировки и изменять приоритеты требований. Например, если каркас сайта показать потенциальным пользователям, то появится много вопросов, на основании которых можно скорректировать то, что уже написано или еще не реализовано, понять что более важно пользователю.

Девиз Scrum — «анализируй и адаптируй»: анализируй то, что получил, адаптируй то, что есть, к реальной ситуации, а потом анализируй снова. Чем меньше формализма, тем более гибко и эффективно можно работать, — это основной принцип данной методологии. Но это не означает, что формальных процессов не должно быть совсем, их должно быть достаточно для организации эффективного взаимодействия и управления проектом. Формальная часть Scrum состоит из трех ролей, трех практик и трех основных документов.

Роли

Владелец продукта (Product Owner) — человек, поставляющий требования программистам. От того, как четко написаны требования, зависит, насколько часто команде придется переключаться с задачи на задачу в связи с отсутствием нужной информации, как много нужно задавать вопросов, на которые уходит дополнительное время, как сильно придется изменять уже написанную функциональность от итерации к итерации и, соответственно, эффективность разработки в целом. Обычно владелец продукта является представителем или доверенным лицом заказчика, а для компаний, выпускающих коробочные продукты, он представляет рынок, на котором реализуется продукт. Владелец продукта должен составить бизнес план, показывающий ожидаемую доходность и план развития с требованиями, отсортированными по коэффициенту окупаемости инвестиций. Исходя из имеющейся информации, владелец продукта подготавливает список требований, отсортированный по значимости. Чем лучше владелец продукта описывает требования, управляет приоритетами и чем быстрее выдает информацию, тем больший финансовый эффект получит компания от методологии. В обязанности этого сотрудника входит своевременное предоставление требований к продукту, определение дат и содержания релизов, эффективное управление приоритетами и корректировка требований для достижения максимальной окупаемости инвестиций в продукт.

От человека, исполняющего роль Scrum-мастера (Scrum Master), во многом зависит самостоятельность, инициативность программистов, удовлетворенность сделанной работой, атмосфера в команде и результат всей работы. Этот человек должен быть одним из членов команды разработки и участвовать в проекте как разработчик. Он отвечает за своевременное решение текущих проблем, от ремонта сломанного стула до обеспечения необходимой информацией членов команды для продолжения их работы и загруженности, за поддержание нужных технических практик, используемых на проекте. В обязанности Scrum-мастера входит обеспечение максимальной работоспособности и продуктивности команды, четкого взаимодействия между всеми участниками проекта, своевременное решение всех проблем, тормозящих или останавливающих работу любого члена команды, ограждение команды от всех воздействий извне во время итерации и обеспечение следования процессу всех участников проекта.

Scrum-команда (Scrum Team) — группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы. В обязанности всех членов Scrum-команды входит участие в выборе цели итерации и определение результата работы. Они должны делать все возможное и невозможное для достижения цели итерации в рамках, определенных проектом, эффективно взаимодействовать со всеми участниками команды, самостоятельно организовывать свою работу, предоставлять владельцу рабочий продукт в конце каждого цикла.

Практики

Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, — журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.

После окончания планирования начинается итерация. Каждый день Scrum-мастер проводит «скрам» (Daily Scrum Meeting) — пятнадцатиминутное совещание, цель которого — достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план к реалиям сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущего скрама, что меня тормозит или останавливает в работе, что я буду делать до следующего скрама? В этом митинге может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды.

В конце каждого спринта проводится демонстрационный митинг (Sprint Review Meeting) продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также определяет программы, которые могут работать лучше, и ищет пути для увеличения эффективности дальнейшей работы. Затем цикл замыкается, и начинается планирование следующего спринта.

Документы

В начале проекта владелец продукта готовит журнал продукта — список требований, отсортированный по значимости, а Scrum-команда дополняет этот журнал оценками стоимости реализации требований. Список должен включать функциональные и технические требования, необходимые для реализации продукта. Самые приоритетные из них должны быть достаточно детально прописаны, чтобы их можно было оценить и протестировать. О своевременной детализации требований должен заботиться владелец продукта и предоставлять необходимый объем в нужное время. В этом смысле программисты являются заказчиками требований для владельца продукта. И отношение владельца продукта должно быть соответствующее — каковы требования, такова и их реализация. В дальнейшем остальные требования должны постепенно уточняться и детализироваться до такого же уровня. Главное, чтобы у команды всегда был достаточный объем подготовленных к реализации требований.

После того как команда во время сессии планирования выбрала и обязалась реализовать набор требований из журнала продукта, эти требования разбиваются на более мелкие задачи, составляющие детализированный список требований — журнал спринта. Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная, например, полдня, разбивка приводит к более грубой оценке, чем приемлема в большинстве проектов, использующих методологию Scrum). Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.

График спринта (Burndown Chart) показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Это график позволяет команде разработчиков делать анализ текущей ситуации и своевременно реагировать на отклонения. График спринта позволяет также владельцу продукта наблюдать за ходом итерации — если общий объем работ не уменьшается каждый день, значит, что-то идет не так. Во время сессии планирования команда находит и оценивает задачи, которые надо выполнить для успешного завершения итерации. Сумма оценок всех задач в журнале спринта является общим объемом работы, который надо выполнить за итерацию. После завершения каждой задачи Scrum-мастер пересчитывает объем оставшейся работы и отмечает это на графике спринта. Только в том случае, если объем работ по окончании итерации закончился (в журнале спринта не осталось незавершенных задач), итерация считается успешной. График спринта используется как вспомогательный инструмент, позволяющий корректировать работу для завершения итерации вовремя, с работающим кодом и требуемым качеством.

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

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

найдены дефекты, которые нужно обязательно исправить для успешного завершения итерации;

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

Исходя из того что журнал спринта не может быть изменен извне во время итерации, нужно выбирать ее длину, основываясь на стабильности требований. Если требования стабильны, меняются или дополняются редко, то можно выбрать шестинедельный цикл. В этом случае экономится время на переключение команды с активной разработки на планирование и демонстрационные митинги. Если требования часто меняются и дополняются, нужно отталкиваться от двухнедельного цикла, в любом случае длина итерации — это величина экспериментальная.

Основной упор методология Scrum делает на управление проектами и не задает никаких технических практик, что дает возможность использовать весь технический багаж, накопленный компанией. При внедрении Scrum чаще всего возникает две трудности. Первая — добиться активного участия от каждого разработчика и слаженной коллективной работы в команде. Похожую задачу решает тренер спортивной команды. Вторая — вовлечь поставщика требований в активное участие в проекте, заинтересовать его динамикой развития продукта, дать возможность быть активным болельщиком и спонсором команды. [4]

1.4 Альтернативные продукты, основанные на Scrum

Для разработки программных продуктов, основанной на Scrum, уже существует по крайней мере одна система, которая называется Agilo for Scrum . Она также разработана на языке Python. Является расширением известной системы Trac, и соответственно имеет аналогичный интерфейс по работе с задачами и ошибками. Для тех, кто является поклонником Trac или привык им пользоваться, переход на Agilo не вызовет особых проблем. Однако многим эта система кажется неудобной, по крайней мере, в качестве полноценного ведения процесса разработки, потому что создана в большей степени для отслеживания ошибок программистов.

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

Используемые технологии

В качестве языка программирования для написания системы управления проектами был выбран Python. Он является одним из модных объектно-ориентированных динамических языков, который отличается от классических (Pascal, C, C++) в первую очередь тем, что он современный. А это значит, что в нем исправлены многие вещи, которые были сделаны в тех языках не очень хорошо. Кроме того, многие приемы программирования (паттерны проектирования), которые сложились за долгое время, добавлены прямо в синтаксис языка. Python является стандартным языком для Web-разработки, он широко используется в организации динамических Web-сайтов. Кроме того, он позволяет организовывать удобную совместную работу над продуктами. Одной из причин выбора именно этого языка программирования стало преимущественное его использование для разработки проектов в компании-заказчике. Благодаря модулям для подключения к базам данных он позволяет работать с Oracle, Interbase, PostgreSQL, MySQL и др. В Python предусмотрена возможность перезагрузки модулей в работающую программу, поэтому разрабатываемую систему можно обновлять без остановки. Это возможно благодаря отсутствию в интерпретаторе утечек памяти.

При проектировании схемы базы данных был использован инструмент Rational Rose. Это популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа данного продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Данный программный продукт изначально создается для обработки и хранения данных. Поэтому актуальность создания общего хранилища данных вполне очевидна. Для этих целей используется СУБД MySQL, как наиболее распространенная при работе с фреймворком Django, и более простая, чем Postgres, которая больше нацелена на сложную серверную логику.

Для разработки дизайна системы был использован продукт Axure RP Pro 4, который позволяет создавать полноценный прототип системы. Этот прототип позволяет видеть не только непосредственно дизайн страниц, но и отслеживать динамику, все переходы между ними. Он позволяет видеть, как ведет себя система в зависимости от действий пользователя.

1.5 Django

При разработке любого программного продукта большое значение имеет выбор фреймворка, с использованием которого будет разрабатываться система. В данном случае предпочтение было отдано фреймворку Django, как одному из самых удобных для создания подобных приложений. Django (Джанго) — это свободный программный каркас для создания веб-приложений, написанный на языке Python. Он обладает многими свойствами и принципами, которые помогают в быстрой разработке веб-приложений, особенно информационного характера. Этот фреймворк делает максимум усилий для того, чтобы из описанной один раз информации достать максимум возможного сервиса. Хотя им можно и не пользоваться (что тоже иногда важно).

Перечислим некоторые из основных его принципов:

· В Django модель данных разрабатываемого приложения описывается в Python классами, и по ней генерируется схема базы данных. А раз схема определяется в языке и от БД не зависит, это значит, что можно легко перейти на другую БД (например, если программист использовал для разработки Postgres, а у пользователя оказался только MySQL).

Пример описания класса модели представлен на рисунке 3.1.1.

Рис.3.1.1.

· Идеология MVC в Django реализована не совсем в классическом варианте. Например, то, что обычно называется Controller, там вырождено в файл соответствия URL’ов обрабатывающим функциям, которые лежат в уровне View. Поэтому часто говорят, что Django просто переназвали Controller во View, а View — в шаблоны.

Пример простой обрабатывающей функции из View представлен на рис. 3.1.2.

Рис.3.1.2.

· Разделение фреймворка на максимально независимые компоненты: так называемая “слабая связанность”. Шаблоны, обработчики и модель почти не завязаны друг на друга. Модель ничего не знает о такой вещи, как HTTP-запрос, а из шаблона нельзя даже случайно изменить данные.

· Отказ от завязывания шаблонов на язык программирования. Когда шаблон представляет собой смесь HTML’а и кода серверного языка, то очень быстро это приводит к тому, что в шаблон проникает довольно много логики, которая должна быть на уровне приложения. Это в свою очередь ведет к тому, что все это сложно поддерживать. В Django язык шаблона вообще не связан с Питоном, а шаблонная логика намеренно очень ограничена. Например, в операторе {% if %} можно проверить только логическую истинность объекта, а произвольное условие типа “равна ли длина списка десяти” — не допускается. Еще одно свойство шаблонной системы — безопасность. Можно обращаться не к любым методам, а только к тем, которые не меняют сами объекты. Поэтому шаблон спокойно можно отдать на редактирование кому-то другому, зная, что он ничего не сломает.

Пример шаблона представлен на рисунке 3.1.3.

Рис.3.1.3.

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

Пример такого файла приведен на рис. 3.1.4.

Рис. 3.1.4.

Центральная же идея Django — быстрая разработка с маленьким количеством кода. Все нацелено на то, чтобы большую часть времени программист занимался не настройкой фреймворка, а написанием кода своего приложения. Например, если рассмотреть административную часть веб-приложения, то можно увидеть, что в Django для этого писать код вообще не надо. Нужно только указать, какие объекты хотелось бы видеть в административном интерфейсе и все, Django автоматически сформирует интерфейс, который очень удобно использовать.

А теперь кратко опишем общую структуру проекта, созданного с помощью этого фреймворка. Проект – это коллекция конфигурационных файлов и приложений, каждое из которых содержит непосредственную реализацию логики создаваемого продукта. При создании нового проекта автоматически создаются 4 файла:

__init__.py
manage.py – утилита для взаимодействия с Django
setting.py - файл с настройками проекта
urls.py - файл URL’ов, о котором упоминалось выше

Приложение создается отдельно, и сразу после создания в его каталоге появляются файлы:

__init__.py
models.py – файл с описанием модели данных
views.py – файл с обрабатывающими URL функциями

Все остальные необходимые модули, классы разработчик помещает внутрь своих приложений.

На рисунке 3.1.5. показана схема обработки запроса страницы, который делает пользователь.

Прежде всего Django ищет переменную ROOT_URLCONF в файле настроек settings.py, которая содержит в себе полный путь к файлу с URL’ами.
Затем Django загружает соответствующий модуль, находит там переменную urlpatterns, которая представляет собой список шаблонов. Пробегаясь по нему по порядку, останавливается на первом шаблоне, который совпадает с запрошенным URL.
После этого Django импортирует и вызывает обрабатывающую функцию из view.py, которая соответствует найденному шаблону. Она получает объект REQUEST, достает из него все необходимые аргументы и каким-то образом их обрабатывает или передает управление другим функциям. (На диаграмме изображено обращение к брокеру Django, которые получает из базы необходимые данные). После своей работы она возвращает объект RESPONSE.

Рис.3.1.5.

Стоит также упомянуть еще об одном важном преимуществе Django – об его встроенном брокере для работы с базой данных. Он позволяет не писать sql-запросы в чистом виде, а пользоваться классами модели и их методами для создания, обновления, удаления и выборки нужных данных. Брокер позволяет делать выборки с различной фильтрацией и сортировкой и является очень полезным и удобным средством при разработке, ускоряя ее. Однако он не лишен недостатков: он не слишком мощный, и сложные запросы все-таки приходится писать вручную, а также он не позволяет работать с хранимыми процедурами.

Анализ и проектирование

1.6 Роли в системе

Аутентификация и последующая авторизация пользователей происходит на основе ролей, которые они играют в системе, и в зависимости от этого им либо разрешено, либо запрещено выполнять определенные действия. Учитывая выбранную нами методологию разработки, можно выделить 4 основные роли:

Разработчик
Scrum мастер
Владелец продукта
Администратор системы

Однако было бы неправильно и скупо останавливаться только на этом наборе. Существует несколько моментов, которые стоило бы хорошенько обдумать.

Во-первых, функции Scrum мастера и владельца продукта достаточно нечеткие в технической части, и в разных компаниях, даже в разных проектах в одной компании, они могут распределяться по-разному. Где-то эти две роли будут уравнены в своих правах, а где-то вполне вероятно, что полномочия Scrum мастера в системе должны в точности совпадать с полномочиями разработчика. Плюс ко всему достаточно важную роль играет политика компании в части открытости. Иногда все люди могут свободно наблюдать за тем, как идут дела по всем проектам, чтобы оценивать продуктивность других команд, быть в курсе их успехов или неудач, но в других случаях им позволительно знать только о своих задачах, и ни о чем больше.

Во-вторых, не стоит забывать о том, что в разработке продукта могут принимать участие различные люди, это могут быть тестеровщики, просто наблюдатели или еще кто-то. И у всех у них тоже должен быть определенный набор прав, и, скорее всего, специфический.

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

Определим базовую функциональность для каждой из ролей.

Рис.4.1.1.

Рисунок 4.1.1. не требует подробных пояснений, в полной мере отражая функции роли «Разработчик». На рисунке 4.1.2. представлены функции «Владельца продукта», которые в точности совпадают с функциями «Scrum мастера». Поэтому в дальнейшем, в рамках этого абзаца, все, что говорится о «Владельце продукта», применимо и к «Scrum мастеру». «Владелец продукта» наследует все функции роли «Разработчик», расширяя ее и добавляя новые. Он обладает максимальным объемом прав, которых достаточно для использования создаваемой системы в полной мере. Единственное ограничение, которое на него налагается – это то, что он не может менять временную оценку не своих задач, что соответствует методологии Scrum.

Рис. 4.1.2.

Обязанности по созданию проектов и настройке системы возложены на роль «Администратор» (рис. 4.1.3.)

Рис. 4.1.3.

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

Покажем на диаграммах выделенные архитектурно-значимые варианты использования для большей наглядности (рис.4.1.4.). В этом случае варианты использования также одинаковы как для «Scrum-мастера», так и для «Владельца продукта», и для обеих этих ролей справедливы варианты использования роли «Разработчик».

Рис.4.1.4.

Набор архитектурно – значимых вариантов использования более подробно описан в Приложении А.

1.7 Проектирование схемы базы данных

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

В результате проектирования системы управления проектами, основанной на методологии Scrum, была получена диаграмма, представленная на рис.4.1.

Для того, чтобы не пришлось изучать ее самостоятельно, поясним семантику множеств сущностей и множеств связей.

Начнем с очевидных множеств сущностей, таких как Project и Customer . Project – это все проекты компании, у которых определены бюджет и крайний срок сдачи, а Customer – заказчики этих проектов, причем очень часто компания сотрудничает с одним и тем же заказчиком довольно продолжительное время.

Как правило, требования программных продуктов постоянно меняются, и было бы неплохо отслеживать их динамику, чтобы в любой момент можно было посмотреть, кто, что и когда изменил и какие файлы добавил или удалил. За эту функцию отвечает Requirement , а Document - Type определяет, какой тип документа (техническое задание, прототип дизайна сайта и т.п.) описывается.

В компании может существовать несколько команд разработчиков, каждая из которых участвует в каком-то проекте. Очевидно, что за весь свой трудовой путь она принимает участие во многих проектах, а иногда в нескольких одновременно. Сами команды хранятся в Team , а история их разработок в Project - Team . Множество сущностей Project - Member хранит в себе непосредственно людей, хоть каким-то образом относящихся к программным продуктам организации, будь то администратор системы, разработчик, человек от компании-заказчика и т.д.

Множество сущностей Project - Member - Role определяет, что определенный человек в определенной команде играет определенную роль. Все роли, которые возможны, находятся в Project - Role . Учитывая выбранную методологию Scrum, ими могут быть, например, Scrum-мастер, владелец продукта, разработчик, тестеровщик и т.д.

Кроме роли в проекте каждый пользователь системы имеет еще одну роль – User - Role . Она определяет права доступа непосредственно в систему, то есть используется при авторизации и аутентификации.

Если снова вспомнить Scrum, то не придется объяснять, что несут в себе такие множества сущностей, как Product-Task , Sprint и Sprint - Task . Каждый спринт относится к конкретному проекту. На него планируется определенный набор задач, на которые разбиваются все глобальные требования к системе. Декомпозированные задачи могут иметь иерархическую структуру благодаря ParentTask . Кроме того, предусмотрена возможность организации задач таким образом, что нельзя приступить к выполнению какой-либо задачи, пока не выполнена другая, то есть возможность реализации отношения зависимости. Конечно, в идеале каждая задача, запланированная на спринт, должна быть обязательно выполнена в его рамках. Но никто не застрахован от того, что выполнить ее просто не успеют из-за внезапно возникших проблем, и она перейдет на следующую итерацию. Именно поэтому на указанной диаграмме задача может относиться ко многим спринтам.

Рис. 4.1.1.

Каждая задача постоянно находится в динамике, у нее может меняться тип («задача», «улучшение», «дефект» и т.д.) и статус («новая», «завершена», «в разработке» и т.д.). Эти параметры отражены в Task - Type и Status . Чтобы была возможность просмотреть всю историю изменений для конкретной задачи, внесено множество сущностей Task - History , по которой можно отследить, когда и какой член команды изменил параметры задачи и почему, причину позволяют узнать комментарии. Комментарии можно оставлять не только при изменении задачи, но и просто внутри нее, ведя, например, какое-то обсуждение.

Для каждого проекта может быть свой набор приоритетов для выполняемых задач, это может зависеть от заказчика или специфики работ. Кому-то удобнее выставлять приоритеты цифрами, а кто-то предпочитает ограничиться тремя емкими фразами. Учитывая эту возможность, в схеме появляется множество сущностей Priority-Set , которая ее предоставляет. При этом все приоритеты берутся из Priority , которое можно дополнять новыми вариантами.

Очень часто при работе с задачами требуется возможность прикрепления файла, например техническое задание, которое пришло от заказчика, скриншот ошибки и др. Для этого в схеме появилось множество сущностей File , которое служит для хранения файлов Requirement, ProductTask, SprintTask и Comment. Для определения того, к какой сущности относится конкретный файл, в схему было введено Entity , которое и содержит в себе список всех возможных множеств сущностей, для которых актуально наличие файла.

В системе есть несколько видов пользователей, и каждый из них обладает определенным набором прав, который регламентирует, что пользователь может делать, а что – нет. Для того, чтобы сделать эту часть проектируемой системы настраиваемой, появилось множество сущностей Rule , в котором содержатся все возможные действия пользователей, права на выполнение которых могут быть ограничены по каким-либо причинам. (Подробнее об этом говорилось выше, в параграфе 4.1.)

Реляционная схема базы данных представлена в Приложении Б.

1.8 Прототип системы

Прежде чем приступать к реализации, необходимо не только четко знать, что должна уметь делать система и что могут делать различные пользователи, но и четко представлять себе, как это все должно выглядеть. Иначе очень часто происходят такие неприятные ситуации, когда программист закончил разработку какой-то функциональности, а оказалось, что при таком интерфейсе совершенно неудобно работать или даже полностью нарушена задуманная логика приложения. В этом случае зачастую приходится не только изменять внешний вид страниц, но и переписывать большой объем кода, а иногда даже затрагивать архитектуру программного продукта, что влечет за собой дополнительные немалые затраты времени, сил, а также материальные затраты. Чтобы этого не допустить, необходимо заранее позаботиться о внешнем виде и удобстве интерфейса системы.

Перед началом непосредственной реализации нашего приложения такой прототип был создан.

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

Рис. 4.3.1.

Рисунок 4.3.2. показывает, как будет происходить изменение набора прав для выбранной роли.

Рис. 4.3.2.

2 Схема приложения

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

Рис.5.1.

Заключение

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

В процессе подготовки к непосредственной разработке программного продукта, были изучены язык программирования Python, фреймворк для быстрой и удобной разработки веб-приложений Django. Также была изучена СУБД MySQL.

На основе выбранной методологии была создана система управления проектами, полностью удовлетворяющая требованиям компании.

Список использованных источников

1 К. Бек, М. Фаулер. Экстремальное программирование: планирование. Библиотека программиста. – СПб.: Питер, 2003. – 144 с.:ил.

2 Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2004.- 432 с.

3 Сузи Р.А. Python. - СПб.: БХВ-Петербург, 2002 - 768 с.: ил.

4 Открытые системы. Scrum: гибкое управление разработкой [Электронный ресурс]: Статья [б.м, б.г, б.и].– Режим доступа: – http://www.osp.ru/os/2007/04/4220063/

5 Обзор методологии Scrum [Электронный ресурс]: Статья [б.м, б.г, б.и].– Режим доступа: – http://www.citforum.ru/SE/project/scrum/

6 Django [Электронный ресурс]: [б.м, б.г, б.и].– Режим доступа: – http://www.djangoproject.com/

7 MAXKIR Самое интересное о разработке программного обеспечения [Электронный ресурс]: Статья [б.м, б.г, б.и].– Режим доступа: – http://www.maxkir.com/sd/newmethRUS.html

8 TeaM RSN Доступ к базам данных: Python & MySQL [Электронный ресурс]: Статья [б.м, б.г, б.и].– Режим доступа: – http://www.ruscript.net/scripts/34/

Приложение А «Текстовое описание вариантов использования»

ВИ «Войти в систему»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь загрузил первую страницу системы с предложением ввода логина и пароля.

Минимальные гарантии : Система отклонила попытку входа и оповестила об ошибке.

Гарантия успеха : Пользователь вошел в систему и получил все права доступа, которые ему назначены в соответствии с его ролями.

Триггер : Пользователь ввел свои логин и пароль и нажал кнопку входа.

Основной сценарий:

1 Пользователь ввел свой логин, пароль и нажал кнопку входа.

2 Система удостоверилась, что такой пользователь есть в базе данных.

3 Система получает роли пользователя в системе.

4 Пользователь входит в систему.

5 Система загружает для пользователя стартовую страницу, соответствующую его ролям.

Альтернативы:

1.1.1. Пользователь не заполнил все обязательные поля.

1.1.2. Система оповещает пользователя о том, что не все требуемые поля заполнены и просит их заполнить.

2.1.1. Пользователь с указанными логином и паролем отсутствует в базе данных

2.1.2. Система отклоняет попытку входа.

2.1.3. Система оповещает пользователя о том, что введенные логин и пароль неверны.

3.1.1. Пользователю не назначено ни одной роли.

3.1.2. Система отклоняет попытку входа.

3.1.3. Система оповещает пользователя о том, что ему недостаточно прав.

ВИ «Создать проект»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь имеет право на создание нового проекта.

Минимальные гарантии : Система не смогла создать проект и оповестила об этом пользователя.

Гарантия успеха : Система создала новый проект и перешла на страницу со списком всех проектов, доступных пользователю. Новый проект появился в этом списке.

Триггер : Пользователь воспользовался элементом управления для добавления проекта.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу создания нового проекта.

2 Система предоставляет пользователю набор полей, необходимых для заполнения.

3 Пользователь заполняет необходимые поля корректными значениями.

4 Пользователь, используя элемент управления, производит сохранение проекта.

5 Система переводит пользователя в список проектов, в числе которых появился новый проект.

Альтернативы:

3.1.1. Пользователь вводит в поле для ввода некорректное значение.

3.1.2. Система при сохранении проекта оповещает об этом пользователя и предлагает ввести новые значения.

4.1.1. Система не может сохранить проект.

4.1.2. Система оповещает об этом пользователя с детальным описанием причины.

ВИ «Создать спринт»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь находится на странице подробного описания какого-либо проекта. Пользователь имеет право на создание спринта.

Минимальные гарантии : Система не смогла создать новый спринт и оповестила об этом пользователя.

Гарантия успеха : Система создала новый спринт и перешла на страницу для формирования списка задач на этот спринт.

Триггер : Пользователь воспользовался элементом управления для добавления спринта.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу создания нового спринта.

2 Система предоставляет пользователю набор полей, необходимых для заполнения.

3 Пользователь заполняет необходимые поля корректными значениями.

4 Пользователь, используя элемент управления, производит сохранение спринта.

5 Система переходит на страницу для формирования списка задач на только что созданный спринт.

Альтернативы:

3.1.3. Пользователь вводит в поле для ввода некорректное значение.

3.1.4. Система при сохранении спринта оповещает об этом пользователя и предлагает ввести новые значения.

4.1.3. Система не может сохранить спринт.

4.1.4. Система оповещает об этом пользователя с детальным описанием причины.

ВИ «Создать задачу»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь имеет право добавить новую задачу.

Минимальные гарантии : Система не смогла создать задачу и оповестила об этом пользователя.

Гарантия успеха : Система создала новую задачу и перешла на страницу со списком всех задач проекта. Новая задача появилась в этом списке.

Триггер : Пользователь воспользовался элементом управления для добавления задачи.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу создания новой задачи.

2 Система предоставляет пользователю набор полей, необходимых для заполнения.

3 Пользователь заполняет необходимые поля корректными значениями.

4 Пользователь, используя элемент управления, производит сохранение задачи.

5 Система переводит пользователя в список всех задач проекта, в числе которых появилась новая задача.

Альтернативы:

3.1.5. Пользователь вводит в поле для ввода некорректное значение.

3.1.6. Система при сохранении задачи оповещает об этом пользователя и предлагает ввести новые значения.

4.1.5. Система не может сохранить задачу.

4.1.6. Система оповещает об этом пользователя с детальным описанием причины.

ВИ «Удалить задачу»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь имеет право удалить задачу.

Минимальные гарантии : Система не смогла удалить задачу и оповестила об этом пользователя.

Гарантия успеха : Система удалила задачу и перешла на страницу со списком всех задач проекта.

Триггер : Пользователь воспользовался элементом управления для удаления задачи.

Основной сценарий:

6 Пользователь, используя элемент управления, удаляет задачу.

7 Система удаляет задачу и переводит пользователя в список всех задач проекта, в котором отсутствует удаленная задача.

Альтернативы:

2.1.1. Система не может удалить задачу.

2.1.2. Система оповещает об этом пользователя с детальным описанием причины.

ВИ «Просмотреть список задач»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь выбрал, какие именно задачи он хочет увидеть.

Минимальные гарантии : Система не смогла предоставить список задач и оповестила об этом пользователя.

Гарантия успеха : Система предоставила список задач, запрошенных пользователем с указанием их основных параметров и возможностью перейти к детальному описанию каждой задачи.

Триггер : Пользователь воспользовался элементом управления для перехода на страницу с требуемыми задачами.

Основной сценарий:

1 Пользователь, используя элемент управления, выбирает, какие задачи он хочет просмотреть («Мои задачи», «Задачи по Проекту №1», …).

2 Система предоставляет пользователю список задач, отсортированных по приоритетам, при этом давая возможность отсортировать их по другим полям, например, по типу или статусу.

Альтернативы:

2.1.1. Система не может предоставить список задач для пользователя.

2.1.2. Система сообщает пользователю о невозможности предоставления списка задач.

ВИ «Изменить задачу»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь находится на странице с детальным описанием задачи.

Минимальные гарантии : Система не смогла сохранить изменения и оповестила об этом пользователя с описанием причины.

Гарантия успеха : Система успешно сохранила изменения и перешла на страницу с детальным описанием измененной задачи.

Триггер : Пользователь воспользовался элементом управления для перехода на страницу для редактирования задачи.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу для редактирования задачи.

2 Система удостоверяется в том, что пользователь имеет право на изменение всех параметров задачи.

3 Система предоставляет пользователю набор полей для редактирования.

4 Пользователь меняет параметры редактируемой задачи.

5 Пользователь, используя элемент управления, производит сохранение задачи.

6 Система сохраняет задачу и переходит на страницу с детальным описанием измененной задачи.

Альтернативы:

2.1.1. Система обнаружила, что пользователь не имеет право менять какой-либо из параметров редактируемой задачи.

2.1.2. Система запрещает пользователю редактирование параметра, который он не может менять.

2.2.1 Система обнаружила, что пользователь не имеет право на редактирование выбранной задачи.

2.2.2 Система отказывает пользователю в редактировании задачи и сообщает ему о причине отказа.

6.1.1. Система не может сохранить изменения.

6.1.2. Система оповещает об этом пользователя с детальным описанием причины.

ВИ «Добавить задачи в спринт»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Спринт для текущего периода уже создан. Пользователь имеет право редактировать спринт.

Минимальные гарантии : Система не смогла добавить задачи в текущий спринт и оповестила об этом пользователя.

Гарантия успеха : Система успешно добавила задачи в текущий спринт и перешла к списку задач на этот спринт

Триггер : Пользователь воспользовался элементом управления для перехода на страницу для редактирования текущего спринта.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу для редактирования текущего спринта.

2 Система предоставляет пользователю два списка задач. В одном из них все задачи на проект, отсортированные по приоритету, а в другом список задач на текущий спринт.

3 Пользователь выделяет задачи, которые он хочет перенести в спринт.

4 Пользователь с помощью элемента управления переносит задачи из первого списка во второй.

5 Система показывает сумму оценок по времени всех задач, отобранных на спринт.

6 Система сохраняет изменения и остается на странице редактирования спринта.

Альтернативы:

6.1.1. Система не может сохранить изменения.

6.1.2. Система сообщает пользователю о невозможности сохранения с описанием причины.

ВИ «Сформировать команду разработчиков на проект»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Проект создан и выбран. Пользователь имеет право менять состав команды.

Минимальные гарантии : Система не смогла сохранить состав команды и оповестила об этом пользователя.

Гарантия успеха : Система успешно сохранила сформированный состав команды и перешла на страницу с детальным описанием проекта.

Триггер : Пользователь воспользовался элементом управления для перехода на страницу для редактирования состава команды на проект.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу для редактирования состава команды на проект.

2 Система предоставляет пользователю два списка с пользователями. В одном из них все пользователи, которые есть в системе, отсортированные по алфавиту, а в другом список разработчиков на данный проект.

3 Пользователь выделяет пользователей, которых он хочет добавить в команду.

4 Пользователь с помощью элемента управления переносит выделенных пользователей из первого списка во второй.

5 Система сохраняет изменения и переходит на страницу с детальным описанием проекта.

Альтернативы:

5.1.1. Система не может сохранить изменения.

5.1.2. Система сообщает пользователю о невозможности сохранения с описанием причины.

ВИ «Изменить права доступа в системе для какой-либо роли»

Основное действующее лицо: Пользователь

Участники и их интересы:

Предусловие : Пользователь вошел в систему. Пользователь имеет право менять права доступа для ролей системы. Пользователь находится на странице с описанием прав доступа для каждой роли.

Минимальные гарантии : Система не смогла сохранить изменения и оповестила об этом пользователя.

Гарантия успеха : Система успешно сохранила сформированный набор прав для выбранной роли и перешла на страницу с описанием прав доступа для каждой роли системы.

Триггер : Пользователь воспользовался элементом управления для перехода на страницу для редактирования набора прав выбранной роли.

Основной сценарий:

1 Пользователь, используя элемент управления, переходит на страницу для редактирования набора прав выбранной роли системы.

2 Система предоставляет пользователю список всех прав, которые можно назначить роли.

3 Пользователь выделяет права, которые хочет назначить выбранной роли.

4 Пользователь с помощью элемента управления пытается сохранить изменения.

5 Система сохраняет изменения и переходит на страницу с описанием прав доступа для каждой роли.

Альтернативы:

5.1.1. Система не может сохранить изменения.

5.1.2. Система сообщает пользователю о невозможности сохранения с описанием причины

Приложение Б « Реляционная схема базы данных»

Приложение В « Руководство пользователя»

После того, как пользователь загрузил главную страницу системы, ему предлагается ввести свои логин и пароль (Рис.1.). В случае верных данных пользователь входит в систему, и с правой стороны, над главным меню, отражается его имя.

Рис.1. Рис.2.

Покажем работу основных частей системы, касающихся непосредственной работы с задачами.

Если пользователю назначена только роль разработчика, после входа в систему ему предоставляется список его задач на текущие спринты. Если же пользователь хотя бы для одного проекта является владельцем продукта или Scrum мастером, то перед ним появляется краткий обзор его проектов (Рис.3.). Здесь он может посмотреть сроки проекта, информацию о текущем спринте и о задачах, увидеть заказчика. Из этой страницы по выделенным ссылкам пользователь может пройти на страницы с составом команды, с задачами по проекту или задачами текущего спринта, со списком требований. Чтобы просмотреть подробную информацию о проекте, нужно щелкнуть мышкой по названию проекта.

Рис.3.

Во всех случаях, когда информация предоставляется в виде списка, в котором каждый блок – это отдельный проект, пользователь может воспользоваться элементом управления, находящимся над главным меню, для фильтрации по проектам (Рис. 4.).

Рис.4.

Это актуально для страниц со списками задач, кратким описанием проектов, списком требований и др.

С помощью пункта главного меню «Tasks» (Рис.5.) можно просмотреть различные группы задачи по проектам, а также создать новую задачу, если у пользователя есть на это право.

Рис.5.

Все списки задач выглядят однообразно. Представлено название проекта, щелкнув по которому можно перейти к детальному его описанию, если пользователю разрешено это действие; указаны сроки текущего спринта и непосредственно сами задачи с указанием главных их характеристик (Рис. 6). Для удобства просмотра выделенная строка подсвечивается светло-зеленым цветом. Если пользователь захочет отсортировать список по какому-либо параметру, сделать это можно при нажатии на заголовок нужной колонки. Чтобы посмотреть детальное описание задачи, необходимо нажать на номер задачи в колонке «ID».

Рис.6.

Страница с детальным описание задачи представлена на рисунке 7. Комментарии для выбранной задачи располагаются в порядке убывания даты добавления, чтобы не приходилось пролистывать вниз для просмотра последней записи. Все операции, которые можно проделывать с задачами, реализуемы с помощью кнопок в левой части страницы.

Рис.7.

При добавлении новой задачи появляется страница, изображенная на рисунке 8. Не все поля являются обязательными для заполнения, но указать «Project», «Name» и «Priority» необходимо. Для сохранения задачи необходимо нажать кнопку «Save». При успешном сохранении система перейдет на страницу с задачами проекта, где появится только что созданная задача.

Рис.8.

На рисунке 9 представлено подробное описание проекта. Здесь появляется та же сводная информация о проекте, которая видна на кратком обзоре, приводится сводная информация по разработчикам, а также список всех спринтов по данному проекту. По каждому разработчику видно, сколько задач у него выполнено, сколько осталось и с какими статусами, сколько ошибок и т.д. При нажатии на ячейку в таблице статусов появляется всплывающее окошко, в котором задачи из этой ячейки расписаны по типам. В таблице с типами происходи то же самое, но задачи расписываются по их статусам.

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

Рис.9.

В настоящее время информационные технологии достигли высокого уровня и продолжают развиваться.

Потребности людей растут, проекты становятся все более масштабными и бюджетными. Растут требования, уделяется внимание жестким ограничениям по времени, ресурсам и рискам.

На этом фоне в компаниях по разработке программного обеспечения существует проблема с организацией эффективной работы коллектива.

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

А для этого необходимо применить подходящую для данной компании методологию разработки программного обеспечения.

Если методология будет выбрана правильно, эта цель будет достигнута.

Целью данной работы являлось создание системы управления проектами для компании «Битворкс», которая будет основана на методологии разработки, наиболее полно удовлетворяющей нуждам данной компании.

Как известно, методологии разработки можно подразделить на два вида: тяжеловесные и гибкие.

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

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

При выборе методологии подробно были рассмотрены XP, Scrum, Crystal и RUP.

Наиболее подходящей оказалась Scrum.

Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта, т.к. ее основа – итеративная разработка.

В методологии Скрам всего тири роли: владелец продукта, скрам-мастер и скрам-команда. У каждой из этих ролей свой набор обязанностей, которые они должны выполнять.

Кратко опишем схему процесса разработки.

1) В начале разработки Владелец продукта поставляет список требований к продукту, полученные от заказчика, выставляет для них приоритеты, и вместе с командой делает приближенную оценку. Полученный артефакт называется Product backlog.

2) После этого начинаются итерации, которые в Скрам называются «СПРИНТ». При планировании каждого спринта все участники определяют ту функциональность, которая будет реализована в его пределах, детализируют до небольших задач, команда дает им оценки, и итерация начинается.

3) Ежедневно в начале дня проходит 15-минутный митинг, называемый «Скрам», в течение которого выясняется, кто что делал вчера, что будет делать сегодня, и с какими проблемами столкнулся.

4) В конце каждой итерации происходит демонстрация новой функциональности и ее обсуждение.

В рамках данной работы были рассмотрены лишь архитектурно – значимые варианты использования, и для каждой роли, описанной Скрам, был выделен свой набор.

На слайде приведен типичный пример набора вариантов использования для роли «Скрам мастер»

На основе анализа предметной области и набора требований, полученного от заказчика, была получена схема БД, представленная на слайде.

Для реализации системы был строго определен набор технологий:

1) Фреймворк Джанго, который позволяет очень быстро и легко создавать веб-приложения

2) Язык программирования Python, который также является стандартным языком для веб-разработки

3) СУБД MySQL

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

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

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

В результате проделанной работы было:

1) Проведено исследование методологий

2) Выбрана подходящая методология для данной компании

3) Изучен язык программирования Python

4) Изучен фреймворк Джанго

5) Освоена СУБД MySQL

6) Создан прототип приложения

7) Разработаны основные компоненты системы