Проект разработки мобильного приложения

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Введение

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

Основными платформами, для которых сегодня разрабатывается большинство приложений, являются IOS, Android, WP7. Перезапуск и бурное развитие рынка мобильных приложений начались в 2008 году, в связи с выходом IPhone и появлением AppStore. Данные события существенно изменили ландшафт. Приложения стали иметь совсем другой вид и другое назначение. Многие из них даже заменили «большие приложения» на крупных ОС. В связи с молодостью рынка все разработчики торопятся захватить нишу, и поэтому сроки разработки приложений очень маленькие (полгода - это вечность для мобильного проекта). Также такие проекты ограничены в бюджете, как правило, организации не выделяют больших средств на разработку приложений, а если это независимые команды, то они изначально ограничены в бюджете в связи со своей независимостью. Поэтому тема данного исследования является актуальной.

Объект исследования-проект разработки мобильного приложения.

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

Цель исследования -анализ и выявление особенностей и наиболее эффективных подходов к управлению проектами в области разработки мобильных приложений

Для достижения поставленной цели необходимо решить следующие задачи:

проанализировать особенности рынка мобильных приложений;

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

систематизировать основные методологии управления проектами;

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

выявить различия в подходах к управлению проектами Agile иWaterfall;

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

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



Глава 1. Рынок мобильных приложений и его специфика. Определение понятий проект и управление проектами

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

1.1 Рынок мобильных приложений

Мир мобильной разработки перезапустился и начал бурно развиваться в 2008 году. Этому послужили такие события как появление IPhone с IOS, а также AppStore. Данные события подтолкнули разработчиков к переосмыслению предназначения мобильных приложений. Открылись новые перспективы и возможности. Компании начали бороться, чтобы занять определённую нишу. Позднее появились новые мобильные операционные системы, что предоставило ещё больше возможностей, появились новые площадки для реализации проектов. Доступность и простота данных площадок позволила любым разработчикам реализовать свои идеи. И теперь в основном необходимы только команда и небольшие средства, чтобы приобрести среды для разработки. В подтверждение бурного роста рынка приводится график прогноза количество загрузок и прибыли от мобильных приложений (рис 1.1).

Рис. 1.1. Прогноз изменений рынка

Существует несколько основных групп разработчиков мобильных приложений:

Организации, основной деятельностью которых является разработка приложений (это, как разработчики игр, так и компании, которые изготавливают приложения на заказ);

Независимые команды разработчиков, состоящие из нескольких человек (2 программиста и дизайнер);

Отдел внутри организации, создающий какое-то корпоративное приложение для этой компании.

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

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



1.1.1 Сегментация рынка

J'son & Partners Consulting разделяют рынок приложений на следующие сегментыhttp://www.json.ru/poleznye_materialy/free_market_watches/analytics/rynok_mobilnyh_prilozhenij_v_rossii_i_mire/ - Аналитическая статья консалтинговой компании J'son&Partners:

Контентные приложения

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

Бизнес-приложения

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

Мобильные игры

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

Мобильные социальные сети

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

1.1.2 Способы монетизации

Также приложения различаются по бизнес-моделям, благодаря которым происходит монетизация рынка мобильных приложений:

Premium (Платные приложения: которые продаются в платформе по установленной цене)

Freemium (Изначально бесплатные приложения, но, которые подразумевают покупки внутри приложения, это может и расширение до полной версии и какие либо бонусы)

In-AppPurchases (Покупки внутри приложения, они могут быть как в платных, так и в бесплатных)

Ad (Реклама внутри приложения)

1.2 Определение понятий «проект» и «управление проектами»

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

-Богданов В. В. Управление проектами. Корпоративная система -- шаг за шагом / М.: Манн, Иванов и Фербер, 2012.

-Дитхелм Герд Управление проектами. СПб, Бизнес-пресса, 2003, Том 1 "Основы", 390 с., Том 2 "Особенности",

Строительство дома, разработка нового оборудования, бизнес реинжиниринг, разработка или внедрение программных средств, проведение рекламной компании или выборов, подготовка спектакля, введение новой налоговой системы, полет на Луну - все это примеры мероприятий, носящих характер проекта. Поскольку понятие проекта, прежде всего, связывается с целенаправленными изменениями больших систем, самое общее определение понятия "управление проектами" (УП) - это "управление изменениями". Некоторые руководители характеризуют УП как форму современного искусства, произвольный набор идей и принципов, позволяющих преодолевать возникающие по ходу дела трудности и успешно завершать проект. Другие рассматривают УП исключительно с точки зрения научного подхода, исходя из того, что все факторы могут быть предсказаны, и все альтернативы заранее проанализированы. Управление проектом - это планирование, координация и контроль работ по проекту для достижения его целей в рамках заданного бюджета и сроков, с надлежащим качеством ("Консалтинг ПРИМ"). В своде знаний по управлению проектами PMI записано:

Управление проектом (УП) или Project Management (PM) - это искусство руководства и координации людских и материальных ресурсов на протяжении жизненного цикла проекта путем применения современных методов и техники управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта.- Project Management Institute. PMIPMBOK (4thEdition) / РуководствокСводузнанийпоуправлениюпроектами (четвёртоеиздание), ProjectManagementInstitute, Inc., 2009.

- Грей К.Ф., Ларсон Э.У. Управление проектами: Практическое руководство/Пер. с англ.-М.: Издательство «Дело и Сервис», 2003.

Управление проектами - это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить эти требования и ожидания необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта. УП подчиняется четкой логике, которая связывает между собой различные области знаний и процессы управления проектами (Московское отделение PMI). Таким образом, управление проектами - "прямая, межпрофессиональная корпорация процессов планирования, управления и принятия решений при межпрофессиональной постановке задач".

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

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

Для этого необходимы специалисты в области сетевого планирования, которые смогут сделать (в самом общем виде) следующее:

подготовить развернутый план проекта;

провести качественный анализ выполнения плана;

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

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

-Покровский М.А. Основы управления проектами. Учебное пособие. Под ред. Фалько С.Г. М.: Изд-во МГТУ им. Баумана

-Управление проектами. Основы профессиональных знаний. Национальные требования к компетенции специалистов. - М.: Изд-во «Консалтинговое Агентство «КУБС Групп - Кооперация, Бизнес-Сервис», 2001.

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

Далее составляется расписание проекта, в котором содержится следующее:

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

оценки времени (разумеется, реалистические!) на каждый этап;

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

В итоге совокупность всех этих элементов даст ответ на три главных вопрос: что должно быть сделано, какие результаты должны быть получены и к какому сроку. При этом не следует забывать, что также важен ответ еще на один вопрос: каким образом? Какие ресурсы потребуются для каждого вида работ? Будут ли эти ресурсы в наличии, когда это будет жизненно необходимо?-Щедровицкий Г.П. Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология.

-Щедровицкий Г.П. Организация. Руководство. Управление. (Методология и философия оргуправленческой деятельности

-Роб Томсет. Управление людьми и проектами

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

Для этого существуют разнообразные отчеты о продвижении проекта по отношению к первоначальному плану. Это позволяет сделать главное: отделить реальное от кажущегося. Для этого последовательно учитываются все произошедшие изменения в проекте и постоянно обновляется текущее состояние. На основе этого разрабатываются (при необходимости) новые задания. 

Руководство компании, используя управление проектами в качестве инструмента, будет иметь не приблизительное, а точное представление о том, что на самом деле происходит в рамках данного проекта, на что нужно обратить особое внимание и какие проблемы требуют немедленного решения. -Разу М.Л. Модульная программа для менеджеров. Управление программами и проектами.

-Пучков О.В. Как улучшить управление проектами ворганизации. //По материалам доклада

Зубенко В.А. Курс лекций по инновационному менеджменту. - М., 2001.

Ниже представлен анализ существующих методологий управления проектами.

1.3 Методологии управления проектами

Методология PMI

Методология PMI, сформулированная в виде стандарта PMBOK, базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBOK отражает существенную коррекцию методологии в сторону интерактивных методик. PMBOK - это свод профессиональных знаний по управлению проектами. В настоящем стандарте описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат. Эти процессы разделены на пять групп, называемых «группы процессов управления проектом».-Ресурс ru.wikipedia.org

-Путеводитель по основным понятиям и схемам методологии Организации. Руководства и Управления: Хрестоматия по работам Г.П.Щедровицкого. М.: Дело, 2004

Они представлены на изображении (рис. 2.1)

Основные процедуры управления проектом по данной методологии:

Определение требований к проекту;

Постановка чётких и достижимых целей;

Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости;

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

Рис. 2.1. Процессы подхода PMI

Методология IW URM

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

Процесс управления проектами TenStep

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

Методология P2M

Она базируется в ориентированности не на продукт или процессы, а на улучшение организации в результате выполнения проектов. Иными словами, методология описывает, как использовать полученный в результате выполнения проектов опыт для развития компании. P2M -- это система знаний, представленная в форме «Руководства по управлению инновационными проектами и программами предприятий». Главное преимущество Р2М по отношению к другим школам по управлению проектами состоит в том, что в Р2М существует акцент на выработку инновации как подхода к управлению программами и управление ожиданиями заинтересованных лиц. В то же время проект в Р2М - в первую очередь обязательство менеджера проекта создать ценность как продукт в соответствии с миссией программы и организации в целом.

Традиционная методология

Данная методология заключается в следующей последовательности процедур управления проектами:

*Определение среды проекта.

*Формулирование проекта.

*Планирование проекта.

*Техническое выполнение проекта (за исключением планирования и контроля).

*Контроль над выполнением проекта.

Методология PRINCE2

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

Процедуры управления проектами по данной методологии:

Начало проекта (SU).

Запуск проекта (IP).

Планирование проекта (PL).

Управление проектом (DP).

Контроль стадий (CS).

Контроль границ стадий (SB).

Управление производством продукта (MP).

Завершение проекта (CP).

Прочие процедуры (управление командой, контрактами и т. п.) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Case), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.-Ресурс ru.wikipedia.org Структура процессов данной методологии показана на рисунке (рис.2.2).

Рис. 2.2. Структура процессов метода PRINCE2

Методология MSF

Microsoft Solutions Framework (MSF) разработан корпорацией Microsoft как методология ведения IT-проектов. MSF представляет каждую фазу проекта как:

Выработка концепции (Envisioning);

Планирование (Planning);

Разработка (Developing);

Стабилизация (Stabilizing);

Внедрение (Deploying).

Рис. 2.3. Схема MSF

1.4 Постановка проблемы

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



Глава 2. Сравнительный анализ методологий

Комплексный проект может включать в себя этапы работ с поставками в совершенно разных индустриях. Зачастую успешность комплексного проекта зависит от того, насколько правильно руководитель проекта выбрал подходящую методологию и смог ее внедрить для достижения требуемых результатов на конкретно взятом этапе.-Воропаев В. И. Управление проектами в России. - М.: Аланс, 2005

-Либерзон В.И. Основы управления проектами

-Манн И.М. Как овладеть искусством управления проектами. - М., Управление компанией, 2010

-Арчибальд Рассел Д. Управление высокотехнологичными программами и проектами. М.: АЙТИ системный интегратор, Изд-во ДМК, 2002

2.1 Водопадная модель. Waterfall

В настоящее время в управлении проектами эта методология является классической. Waterfall -- один из самых первых и устоявшихся подходов.

Она содержит набор стандартных фаз, которые подразумевают чёткую последовательность:

Сбор требований (Requirements)

Планирование (Design)

Разработка/Внедрение (Implementation)

Тестирование (Verification/Test)

Поддержка (Maintenance)



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

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

Разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.

Анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.

Реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.

Тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.

Развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.

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

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

Насколько эффективным оказался такой подход? Он хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения. Благодаря этому она часто используется в больших организациях (таких как Министерство обороны США и NASA) при строгих требованиях к надежности создаваемого ПО.

Недостатки:

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

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

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

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

Модель водопада является правильным выбором для типовых, шаблонных проектов или при наличии жестких требований к качеству (например, при создании критических систем). Но всё же недостатки данной модели очень существенны, и для разработки коммерческого программного обеспечения существуют более эффективные методологии.-Аскар Рахимбердиев. Современные процессы разработки программного обеспечения. RSDN Magazine #4-2006.

2.2 Гибкая модель. Agile

Agile -- это в первую очередь набор принципов:

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

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

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

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

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

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

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

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

Постоянное внимание к техническому совершенству и качеству

проектирования повышает гибкость проекта.

Простота -- искусство минимизации лишней работы -- крайне необходима.

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

Команда должна систематически анализировать возможные способы

улучшения эффективности и соответственно корректировать

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

Базируясь на этих принципах, появлялись новые методологии, которые и составляют семью Agile:

Extreme programming

Scrum

Lean Software Development

Test Driven Development

Feature Driven Development

и др.

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

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

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

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

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

Ограничения методологии Agile:

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

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

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

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

Низкий уровень квалификации команды.

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



Рис. 3.1. Схема Agile

2.3 Сравнительный анализ

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

Есть масса причин, по которым противопоставляют Agile и Waterfall. Кто-то считает, что Waterfall выдохся и не способен быстро реагировать на меняющиеся потребности бизнеса. Другие считают Agile неокрепшим, с дырами в управлении рисками и качеством.

Сильные стороны

№	Waterfall	Agile
1	Легок для понимания и использования;	Итеративная разработка;
2	Детально структурирован, что облегчает его применение к малоопытным командам;	Использование временных рамок(time boxes);
3	Задает стабильные требования к проекту/продукту с самого старта;	Конечный пользователь вовлечен в процесс с самого начала;
4	Проекты легко контролируются, отслеживаются ресурсы, риски, время;	Быстрое получение первой/пробной версии продукта для тестирования;
5	Качество имеет первоочередной приоритет по сравнению со стоимостью и временем.	Легко воспринимаются корректировки и изменения в процессе разработки.

Слабые стороны

№	Waterfall	Agile
1	Все требования должны быть определены и детально описаны до начала разработки;	Может привести к низкому качеству продукта;
2	Дорого и медленно;	Риск никогда не достигнуть закрытия/завершения проекта;
3	Чувствителен к изменениям;	Могут возникнуть проблемы с расширяемостью продукта.
4	Мало возможностей для конечного пользователя повлиять на цели проекта и требования к продукту;
5	Зачастую проблемы выявляются на этапе тестирования;
6	Много документации, много технической документации, которая не понятна конечному пользователю или заказчику.

Условия преимущественного использования

№	Waterfall	Agile
1	Требования к продукту предельно ясны и стабильны;	Конечный пользователь вовлечен в проект со старта;
2	Известны используемые технологии и инструменты;	Четко определены бизнес-цели проекта/продукта;
3	Проект большой, дорогой и сложный;	Небольшой или средний проект, относительно короткий по времени;
4	Примеры: внедрение новой версии известного продукта; внедрение ERP систем.	Состав команды стабильный;
5		Команда с высоким уровнем профессионализма;
6		Система может быть модульной.

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

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

Задача руководителя проекта -- выбрать наиболее подходящий способ для достижения целей проекта. По вышеописанному сравнению можно сделать вывод, что подход Waterfall лучше и намного эффективнее использовать на больших проектах, требования предельно ясны и стабильны, чаще всего это такие проекты как внедрение ERP или внедрение какого-то другого известного продукта. Как было сказано ранее проект разработки мобильных приложений весьма уникальный, и поэтому не обладают крупным бюджетом и сроками. А также проекты разработки мобильных приложений подразумевают вовлечённость заказчика со старта. Поэтому использование подхода Waterfall на подобных проектах очень неэффективно из-за наличия множества обязательных этапов, которые в принципе не нужны для разработки мобильных приложений, а также из-за сильной чувствительности к изменениям. Далее оба подхода будут использованы в проекте разработки мобильного приложения, также будет проведено более детальное сравнение результатов.



Глава 3. Управление проектом разработки мобильного приложения

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

3.1 Особенности управления проектами разработки мобильного приложения

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

Основным отличиями мобильных проектов от настольных проектов является размер, сроки, бюджет. Компании, разрабатывающие мобильные приложения не выделяют на разработку большие бюджеты в связи с маленьким размером проекта и количеством трудозатрат. Также сроки для мобильных проектов являются критическим фактором. Разработчики не могут позволить себе растянуть проект на полгода, год. Это недопустимо для мобильных приложений и может привести к краху всего проекта. Во-первых, количество разработчиков на рынке огромное и любой может прийти к такой же идее и реализовать её за более короткий срок. Во-вторых, платформы, для которых разрабатываются приложения, обновляются раз в год, а также устройства, такие как IPhone, IPad обновляются раз в год, что не позволяет разработчикам затягивать с производством их продукта и вынуждает, как можно раньше выставить свое приложение на рынок.

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

Традиционное представление жизненного цикла проекта-Стандарт ISO/IEC 12207:

Системный анализ;

Анализ требований;

Написание документации;

Проектирование;

Кодирование;

Тестирование;

Сопровождение.

Особенности жизненного цикла проекта разработки мобильного приложения:

Кодирование прототипов начинается еще на этапе продаж;

Анализ требований и проектирование как отдельные этапы проводятся крайне редко, часть анализа проводится параллельно с кодированием;

После утверждения приложения в среде AppStore нет необходимости в сопровождении

Отсутствие документирования в проектах данного класса.

Основные рекомендации при управлении мобильными проектами:

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

Регулярно показывать приложение заказчику;

Необходимо писать код, предусматривая возможность того, что всё может поменяться и будет необходимо его переписывать;

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



3.2 Управление проектом разработки мобильной игры

Рассмотрим проект разработки игры на мобильной платформе IOS. Данный проект был запущен в середине марта и пока находится на стадии разработки.

Данная игра представляет собой головоломку, в связи, с чем ориентирована на широкий круг потребителей. Так как игра разрабатывается на платформе IOS, возникает ряд необходимых условий для реализации проекта:

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

Во-вторых, для запуска приложения необходимо приобрести аккаунт разработчика по цене 100$ в год, который даёт возможность тестировать приложение на устройствах и выкладывать приложение в AppStore.

3.2.1 Команда

Команда проекта состоит из 4 человек:

Менеджер проекта:

Требования:

Высшее образование (не обязательно, но будет являться хорошей «базой»);

Опыт в области разработки игрового или иного ПО - от 2 лет;

Опыт управления проектной командой (так же интересен опыт управления удаленными или распределенными командами);

Владение современными методиками управления проектами и персоналом;

Знания в области планирования и бюджетирования;

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

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

Обязанности:

Участие в разработке ТЗ по проекту (цели, критерии, сроки, бюджет), оценка возможностей реализации проекта в требуемые сроки, разработка календарно-сетевых планов по проекту, выработка критериев и процедур приемки выполненных работ;

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

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

Управление изменениями в требованиях, возникающими в процессе разработки;

Менеджмент в области организации работы специалистов компании (рабочее место, оборудование, программный инструментарий, прочее);

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

Разрешение конфликтных ситуаций - как в коллективе, так и с заказчиками;

Ведение проектной документации и полной отчетности по проекту.

Дизайнер:

Обязанности:

Разработка интерфейсов для мобильных приложений: от создания прототипов до полной реализации;

Подготовка и нарезка дизайна для разработчиков.

Требования к кандидатам:

Знание Guidelines и UX для мобильной платформы iOS;

Знание стандартных графических элементов операционной системы iOS;

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

Отличное владение Photoshop и знание правил хорошего тона.

Разработчик:

Требования:

Высшее или незаконченное высшее техническое образование;

Опыт программирования и проектирования ПО от 5 лет;

Опыт разработки под iOS (Objective C) или Android от 2 лет;

Понимание принципов ООП и знание шаблонов проектирования и алгоритмов;

Опыт работы с многопоточными приложениями, понимание механизмов управления памятью и журналированием на мобильном устройстве;

Отличное знание сетевых протоколов TCP/IP, UDP, HTTP;

Уверенный английский язык на уровне технической литературы.

Опыт работы в SCRUM

Обязанности:

Работа в команде c product/project managers, тестировщиками, дизайнерами - нацеленность на качественный финальный продукт;

Создавать bugs-free решения (без очевидных багов и утечек памяти);

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

Тестировшик:

Основные требования:

Опыт работы в QA в игровой индустрии.

Знакомство с системами баг-трекинга.

Большой игровой опыт.

Общая техническая грамотность.

Увлечение играми и опыт работы с платформами iOS/Android.

Ответственность, скрупулезность, аккуратность, усидчивость.

Знание ПК на уровне очень опытного пользователя.

Хорошее знание английского языка.

Хорошее знание письменного и устного русского языка.

Легкая обучаемость.

Основные обязанности:

Тестирование игр на мобильных устройствах.

Занесение отчетов в баг-трекинговую систему.

Составление тест планов по гейм-дизайн документам.

3.3 Критерии оценки эффективности методологии

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

Отклонение по стоимости;

Отклонение от календарного плана.

Управление проектом

3.3.1 Реализация по подходу Waterfall

Рассмотрим более детально сам проект разработки. В связи с особенностью разработки мобильных приложений, проект рассчитан на короткий срок по сравнению с проектом разработки больших приложений. По плану рассчитано 61 один день и на данный момент проект находится на стадии разработки. Базовый план представлен на рисунке 3.2. Диаграмма Ганта представлена на рисунке 3.3. Данная диаграмма представляет проект разработки, рассчитанный и спланированный по подходу Waterfall. Здесь предусмотрены все этапы и их поочерёдность. Каждый этап начинается только по завершению предшествующего. В связи, с чем проект по времени занял столь долгое время и большой бюджет, что необычно и несвойственно проектам разработки мобильных приложений.

Рис. 3.2. Базовый план.

Рис. 3.3. Диаграмма Ганта базового плана.

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

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

В связи с учтёнными отклонениями потребовалось 5 дней на исправление кода, что привело к изменениям в плане. Соответственно в связи с особенностями каскадной модели, при возникновении каких-то изменений все процессы должны прорабатываться заново. То есть все процессы, начиная со сбора и изменения требований. Отклонения отображены в промежуточном плане на рисунке 3.4. Отставания от базового плана отображены на диаграмме Ганта с отслеживанием на рисунке 3.5.

Рис. 3.4. Промежуточный план.

Рис. 3.5. Диаграмма Ганта с отслеживанием.

Так как проект реализовывался по подходу Waterfall, возникновение отклонений и необходимости дополнительной разработки сильно сказались на сроках и бюджете. Таким образом сроки реализации проекта сдвинулись на 16 дней, а также в связи с увеличением сроков повысились расходы (увеличились затраты на каждого сотрудника, так как они работают большее количество дней). В итоге общие затраты составили 100 800 руб.

3.3.2 Реализация проекта по подходу Agile

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

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

Рис 3.6. Базовый план

Рис 3.7. Диаграмма Ганта

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

Получили следующие результаты:

Рис 3.8. Диаграмма Ганта с отслеживанием

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

Итоговые результаты по двум подходам приведены ниже в таблицах:



3.3.3 Метод освоенного объёма

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

3.3.3.1 Waterfall

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

По рассчитанным показателями и индексам можно увидеть, что происходит отставание от календарного плана и превышение затрат. Отставание от календарного плана составляет 25%, а отклонение от стоимости составляет 36%. Индекс отклонения от стоимости (ИОС) также позволяет определить превышение затрат. В данном случае он равен 0.74, что указывает превышение затрат.

3.3.3.2 Agile

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

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



Заключение

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



Список литературы

Грей К.Ф., Ларсон Э.У. Управление проектами: Практическое руководство/Пер. с англ.-М.: Издательство «Дело и Сервис», 2003.

Project Management Institute. PMI PMBOK (4th Edition) / РуководствокСводузнанийпоуправлениюпроектами (четвёртоеиздание), Project Management Institute, Inc., 2009.

Богданов В.В. Управление проектами в MicrosoftProject 2007. Учебный курс (+СD), СПб Питер, 2008. - 592 с.: ил.

В. Куперштейн Microsoft Project 2010 в управлении проектами, Изд-во: БХВ-Петербург, 2011 - 416 с.

Богданов В. В. Управление проектами. Корпоративная система -- шаг за шагом / М.: Манн, Иванов и Фербер, 2012. -- 248 c.

Дитхелм Герд Управление проектами. СПб, Бизнес-пресса, 2003, Том 1 "Основы", 390 с., Том 2 "Особенности", 274 с.

Под общей редакцией Шапиро В.Д. Управление проектами. Учебник. СПб.: "Два Три", 1996 - 610 с.

Покровский М.А. Основы управления проектами. Учебное пособие. Под ред. Фалько С.Г. М.: Изд-во МГТУ им. Баумана, 1998, 104 с.

Управление проектами. Основы профессиональных знаний. Национальные требования к компетенции специалистов. - М.: Изд-во «Консалтинговое Агентство «КУБС Групп - Кооперация, Бизнес-Сервис», 2001.

Щедровицкий Г.П. Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4). М.: "Путь", 2000 - 384 с.

Щедровицкий Г.П. Организация. Руководство. Управление. (Методология и философия оргуправленческой деятельности. Курс лекций / из архива Г.П. Щедровицкого. Т.5). М., 2003.

Путеводитель по основным понятиям и схемам методологии Организации. Руководства и Управления: Хрестоматия по работам Г.П.Щедровицкого. М.: Дело, 2004, 208 с.

Роб Томсет. Управление людьми и проектами. - М., 2008

Разу М.Л. Модульная программа для менеджеров. Управление программами и проектами. - М.: ИНФРА-М, 2000.

Пучков О.В. Как улучшить управление проектами ворганизации. //По материалам доклада Russell D. Archibald, Improving Project Management Capabilities. / Журнал "Методы менеджмента качества". - М., 2003.

Мазур И.И., Шапиро В.Д. Управление проектами. Справочное пособие. М.: Высшая школа, 2001.

Зубенко В.А. Курс лекций по инновационному менеджменту. - М., 2001.

БританскийстандартBS 6079-2:2000 Project management Part 2 Vocabulary. (перевод Товб А.С. Ципес Г.Л.). - М., 2009

Воропаев В. И. Управление проектами в России. - М.: Аланс, 2005.

Либерзон В.И. Основы управления проектами. - М., 2009.

Манн И.М. Как овладеть искусством управления проектами. - М., Управление компанией, 2010.

Васильев Д.К., Заложнев А.Ю., Новиков Д.А., Цветков А.В. Типовые решения в управлении проектами. М.: ИПУ РАН, 2003

Арчибальд Рассел Д. Управление высокотехнологичными программами и проектами. М.: АЙТИ системный интегратор, Изд-во ДМК, 2002

Размещено на Allbest.ru

...