Galvojums




НазваниеGalvojums
страница1/14
Дата публикации12.07.2013
Размер0.64 Mb.
ТипРеферат
exam-ans.ru > Информатика > Реферат
  1   2   3   4   5   6   7   8   9   ...   14

GALVOJUMS



Es, Jurijs Kolomijecs apstiprinu, ka esmu izstrādājis doto maģistra darbu dabaszinātņu maģistrs datorzinātnēs akadēmiska grāda iegūšanai. Šis darbs nav iesniegts nevienā citā augstskolā, akadēmiskā grāda iegūšanai. Visi dotajā darbā manis izmantotie secinājumi un autoru publicēto un nepublicēto darbu citāti ir ar atbilstošām atsaucēm tekstā.

____________________Jurijs Kolomijecs

ANOTĀCIJA


“Agile paņēmienu ietekmes uz programmatūras izstrādes procesu kvalitāti izpēte”. J.Kolomijecs. Darba vadītājs lektors, M.Sc.Comp. A. Ressins.

Darbs dabaszinātņu maģistra datorzinātnēs akadēmiskā grāda iegūšanai: 66 lappuses, 4 tabulas, 31 attēls, 8 izmantotās literatūras un tiešsaistes avotus.
PROGRAMēŠANA, SCRUM, AGILE, KANBAN
Šī darba ietvaros autors implementēja Agile metodoloģijas programmatūras izstrādāšanas procesa, izpētīja to ietekmi uz procesa kvalitāti, izvelējas vispiemēroto un uzrakstīja rekomendācijas.

АННОТАЦИЯ


Работа «Исследование влияния Agile методологий на качество процесса разработки программного обеспечения» на соискание степени магистра естественных наук в области компьютерных наук, автор - Ю. Коломиец. Руководитель работы лектор, M.Sc.Comp. А. Рессин.

Работа содержит: 66 страниц, 4 таблицы, 31 рисункок, и 8 использованных литературных и других информационных источников.
ПРОГРАММИРОВАНИЕ, Scrum, AGILE, KANBAN
В рамках настоящей работы автор провёл практический эксперимент по внедрению Agile методологий в процесс разработки программного обеспечения, оценил их влияние на качество процесса, определил наиболее подходящую и разработал рекоммендации.

ABSTRACT


The work “Research of Agile methodology influence on software development process quality” by student J. Kolomijecs. Adviser of the work is lecturer, M.Sc.Comp. A. Ressin.

The work is presented for achievement academic grade “Master of Natural Sciences in Computer Sciences”: 66 pp., 4 tables, 31 fig., 8 references and other information sources, ХХ appendixes.
programming, scrum, AGILE, KANBAN
In context of current work, author implemented Agile methodologies in current software development process, analyzed it’s influence to the process quality, chose methodology that fits most and wrote recommendations.

СОДЕРЖАНИЕ





GALVOJUMS 2

ANOTĀCIJA 3

АННОТАЦИЯ 4

ABSTRACT 5

СОДЕРЖАНИЕ 6

^ ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, ИСПОЛЬЗУЕМЫХ В РАБОТЕ 7

ВВЕДЕНИЕ 8

1.ПРОБЛЕМА КАЧЕСТВА ПРОЦЕССА РАЗРАБОТКИ ПО 11

2.СРАВНЕНИЕ МЕТОДОЛОГИЙ 13

3.Внедрение Scrum 26

4.Внедрение Kanban 47

5.Сравнение результатов 50

6.Рекомендации 64

7.Выводы 65

8.Список используемой литературы 66
^

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, ИСПОЛЬЗУЕМЫХ В РАБОТЕ



ПО – программное обеспечение

СПО – свободное программное обеспечение

SCM – Certified ScrumMaster

^ ОС – операционная система

ЯП – язык программирования

БД – база данных

VSM – Value Stream Mapping

ROI – Return of Investment

ВВЕДЕНИЕ


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

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

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

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

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

По сравнению с монументальными методологиями, в Agile гораздо меньше ставится акцент на документацию, то есть ориентация смещается на написание кода, а не документов к нему и системе в целом.

Основные различия Agile методологий от монументальных:

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

  • Agile методологии ориентированы на человека, а не на процесс. Agile методологии учитывают природные качества людей, а не действуют вопреки им. Разработка ПО должна приносить разработчикам удовольствие, а не быть обузой.

Agile-манифест включает в себя 4 утверждения:

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

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

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

  • Готовность к изменениям важнее следования первоначальному плану. Таким образом, команда готова к изменениям и приветствует их, не зацикливаясь на написанном плане. [4]

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

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

  • Провести практический эксперимент по внедрению Scrum и Kanban.

  • Оценить влияние Agile методологий на качество процесса разработки ПО.

  • Определить наиболее подходящую методологию.

  • Разработать рекомендации по использованию Scrum и Kanban.
  1   2   3   4   5   6   7   8   9   ...   14

Добавить документ в свой блог или на сайт
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2015
контакты
exam-ans.ru
<..на главную