новая папка 1 / 653819

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего образования

«ЛИПЕЦКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра автоматизированных систем управления

В.А. Алексеев

РЕАЛИЗАЦИЯ ПРОГРАММНОГО ПРОЕКТА С ИСПОЛЬЗОВАНИЕМ СРЕДСТВ КОЛЛЕКТИВНОЙ РАЗРАБОТКИ

МЕТОДИЧЕСКИЕ УКАЗАНИЯ к проведению лабораторных работ по курсу

«Технологии командной разработки программного обеспечения»

Липецк Липецкий государственный технический университет

2017

УДК 681.3.068

А471

Рецензент – канд. техн. наук П.А. Домашнев

Алексеев, В.А.

A471 Реализация программного проекта с использованием средств коллективной разработки [Текст]: методические указания к проведению лабораторных работ по курсу «Технологии командной разработки программного обеспечения» / В.А. Алексеев. – Липецк: Издательство Липецкого государственного технического университета, 2017. – 20 с.

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

Предназначены для студентов магистратуры по направлению 09.04.01 «Информатика и вычислительная техника».

Библиогр.: 14 назв.

© ФГБОУ ВО «Липецкий государственный технический университет», 2017

Основные положения гибкой методологии разработки сформулированы в манифесте «Agile Manifesto», определяющем ценности и принципы, которыми руководствуются успешные команды [3]. Основные идеи Agile:

люди и взаимодействие важнее процессов и инструментов;

работающий продукт важнее исчерпывающей документации;

сотрудничество с заказчиком важнее согласования условий контракта;

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

Agile основывается на следующих принципах [3]:

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

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

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

периодичностью от двух недель до двух месяцев.

На протяжении всего проекта разработчики и представители бизнеса

(заказчики) должны ежедневно работать вместе.

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

обеспечить поддержку и полностью довериться им.

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

Работающий продукт – основной показатель прогресса.

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

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

4

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

Необходимым свойством эффективных решений является простота,

которая понимается как искусство минимизации лишней работы.

Лучших результатов добиваются самоорганизующиеся команды.

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

Большинство гибких методологий нацелено на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями,

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

необходимые для выдачи мини-прироста по функциональности: планирование,

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

Примерами гибких методологий являются: Scrum [5], XP (eXtreme Programming), FDD (Feature Driven Development).

3. Информационные системы в управлении программными проектами Проект – это комплексное, не повторяющееся, одномоментное

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

Основная цель проекта – удовлетворение требований заинтересованных лиц.

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

5

Программные проекты – это проекты, целью которых является разработка программных систем. В целом, как и в других отраслях, в программном проекте можно выделить 4 наиболее общих этапа: 1) приобретение знаний – понимание проблемы; 2) концептуальная разработка – поиск подхода к решению проблемы; 3) реализация программного продукта; 4) проверка и внедрение решения [7].

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

минимизации рисков и отклонений от плана, эффективного управления изменениями.

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

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

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

6

реально затраченное на задачу количество времени, регистрировать отставание от графика или опережение.

Многие современные информационные системы управления проектами включают средства организации общения участников – сервисы мгновенного обмена сообщениями, аудио- и видеоконференции, общие графические «доски» для рисования и т.п.

Следуя [8], можно привести следующую классификацию информационных систем, использующихся в управлении проектами:

1.Системы планирования и управления проектами (Project Planning),

например Microsoft Project, Atlassian JIRA [9], Oracle Primavera, Basecamp.

2.Системы поддержки командного взаимодействия (Project Collaboration), например Microsoft Sharepoint, Google G Suite.

3.Системы отслеживания ошибок (Issue Management / Bug Tracker),

например Atlassian JIRA, Zoho, Redmine [10], Bugzilla.

Большинство информационных систем реализуют в той или иной степени

функции всех 3-х классов.

По архитектуре информационные системы можно классифицировать

следующим образом:

1.Десктопные приложения, например классический Microsoft Project.

2.Веб-приложения, доступные для установки на собственный сервер,

например Atlassian JIRA, Redmine. Такие системы доступны, как правило, и в виде SaaS-решений.

3.Веб-приложения, предлагаемые исключительно как SaaS-решения,

например Project Online, Basecamp, Assembla.

Некоторые из информационных систем специально ориентированы на команды, занимающиеся разработкой программных систем, например, Atlassian JIRA, Assembla. Такие системы отличает поддержка гибких методологий разработки (Agile), как правило в них непосредственно поддерживается

7

методология Scrum, а также имеется встроенная возможность интеграции с системами контроля версий [13].

4. Системы управления версий

Система управления версиями (Version Control System, VCS) –

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

многое другое. Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов разрабатываемой программы. Наибольшие преимущества применение систем управления версиями дает при работе с текстовыми (не «бинарными») файлами.

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

VCS совершенно стереотипен. Предполагается, что проект уже существует и на сервере размещён его репозиторий, к которому разработчик получает доступ.

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

1.Обновление рабочей (локальной) копии с сервера.

2.Модификация проекта (его локальной копии).

3.Фиксация изменений, передача их на сервер.

Распределенные VSC (Distributed Version Control System, DVCS)

используют распределённую модель хранения вместо традиционной клиент-

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

8

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

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

начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена так называемыми наборами изменений (change sets) между пользователями.

Как правило, в схеме с распределенной VCS все же присутствует центральный сервер, с которым «обмениваются» наборами изменений отдельные разработчики.

Примерами систем управления версиями являются: Subversion/SVN, Perforce (централизованные), Git [11], Mercurial/Hg [12] (распределенные).

Программное обеспечение систем управления версиями может быть установлено на сервер команды разработчиков, также могут быть использованы хранилища исходного кода (репозитории), предлагаемые как SaaS-решения в сети Интернет. Некоторые такие решения доступны бесплатно для небольших команд и проектов с открытым исходным кодом. Примерами веб-сервисов являются: CloudForge (SVN, Git), Bitbucket, GitHub, GitLab (Git), Codebase (SVN, Git, Mercurial).

Обеспечение работы с системами управления версиями на стороне компьютера разработчика осуществляется с помощью клиентского программного обеспечения с графическим интерфейсом или интерфейсом командной строки, например TortoiseGit/HG/SVN, SourceTree. Для многих интегрированных сред разработки существуют дополнения (плагины),

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

9