Исполнитель,
студ. гр. 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]. Не стоит забывать и о том, что чем больше система, тем больше в ней появляется ошибок, которые все сложнее и сложнее исправлять. А это означает, что большинство крупных создаваемых систем имеют долгий тестовый период, хотя разработка всей функциональности давно закончена. Редко какие компании закладывают в план проекта этот отрезок времени, а потому очень часто происходит срыв сроков сдачи проекта. А точнее сказать, закладываться-то - он закладывается, но не настолько продолжительный, какой он получается в реальности, так как при подобном тестировании и исправлении ошибок адекватное планирование просто невозможно.