Дипломная работа н и. А. Кудрявцев аучный руководитель А. В. Портасенок

Главная страница
Контакты

    Главная страница


Дипломная работа н и. А. Кудрявцев аучный руководитель А. В. Портасенок



страница1/15
Дата23.04.2017
Размер1,55 Mb.


  1   2   3   4   5   6   7   8   9   ...   15
Федеральное агентство по образованию Российской Федерации

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

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

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

УДК 681.03

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

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

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

«___» ___________ 2008 г.

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


РАЗРАБОТКА СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ, ОСНОВАННОЙ НА МЕТОДОЛОГИИ SCRUM
Дипломная работа

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


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


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

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

студ. гр. 1432

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

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

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

Томск – 2008



Реферат

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

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

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

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

Содержание


1 Введение 4

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

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

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

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

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

3.3.1 Почему Scrum? 10

3.3.2 Scrum 11

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

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

4.1 Django 16

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

5.1 Роли в системе 21

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

5.3 Прототип системы 26

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

Заключение 30

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

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

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

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



  1. Введение


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

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

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

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

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

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


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

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

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

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

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

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


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


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


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

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

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

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

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

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


  1   2   3   4   5   6   7   8   9   ...   15

  • Введение
  • Постановка задачи
  • Гибкие методологии разработки и их виды
  • Что выбрать: гибкость или тяжеловесность