Файл: Особенности жизненного цикла инновационного проект.pdf

- разработка инструкции по работе с программами, оформление необходимой технической документации;

- сопровождение внедренных программ и программных средств;

- не разглашение информации и сведений, которые являются коммерческой тайной;

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

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

Функциональные обязанности для тестировщика:

- контроль функциональности программного продукта по ТЗ;

- выявление ошибок в работе приложения;

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

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

- автоматизация тестов по программному приложению;

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

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

Функциональные обязанности дизайнера:

- определение того, какие функции нужны в приложении, создание проекта user-flow для каждого экрана;

- прорисовка эскизов экранов (wireframes);

- выбор подходящих паттернов и цветовых палитр;

- создание прототипа и формирование дизайна (mock-ups);

- подбор интерактивного прототипа приложения и проведение его оценки;

- создание финальной ретуши прототипа, полировка всех экранов, чтобы все они были готовы к разработке.

Матрица ответственности проекта

Условные обозначения:

О – Ответственный, У – Утверждает, И – Исполнитель, С – Согласовывает, К – Контролирует, П – Принимает

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

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

Как видно из рис. 4 проект по разработке мобильного приложения для заказа еды из ресторана состоит из пяти фаз, каждая из которых состоит из работ.

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

Вторая фаза содержит 3 работы по проектированию основных составляющих приложения: экранов и связей, UX прототипа, концепции дизайна.

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

В четвертой фазе содержится 2 работы по развертыванию и настройке мобильного приложения, а также размещению приложения в App Store и Google Play.

Пятая фаза содержит 4 работы по продвижению и поддержке мобильного приложения.

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

Таблица 1 – Список работ и их длительность

Используя перечень работ проекта из таблицы 1 и порядок предшествования работ, построим сетевую модель.

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

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

Рис.5. Сетевая модель

Используя сетевую диаграмму (рис. 2), определяем ранний старт и ранний финиш каждой работы, поздний старт и поздний финиш, резерв времени [6; 15].

Начало первой работы – это условный «ноль», старт проекта. Складывая продолжительность работ по различным цепочкам от старта проекта, получаем условное время раннего старта каждой работы (ES). Если предыдущая цепочка работ даёт несколько вариантов старта, то выбираем самый поздний из них. Ранний финиш равен раннему старту плюс продолжительность работы.

Ранний старт ES (Early Start) и ранний финиш EF (Early Finish) определяется прямым прохождением от первой до последней работы проекта. Показатель раннего завершения последней работы дает возможность определить продолжительность всего проекта. Если же проект завершается несколькими параллельными работами, то продолжительность проекта определяется как наибольшая величина из ранних сроков завершения остальных работ.

Поздний финиш LF (Last Finish) последней работы равен времени реализации проекта. Поздний старт LS (Last Start) работы равен поздний финиш минус продолжительность работы. Если получается несколько вариантов позднего старта, следует выбирать наименьший (более ранний) из них.

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

Сравнивая ранний старт и поздний старт каждой работы, определяем общий резерв времени для каждой работы проекта.

Общий (полный) резерв времени TF (Total Float) – промежуток времени, на который можно задержать начало работы или увеличить ее длительность без изменения срока завершения проекта.

TF = LF – ЕF = LF – (ES + T) = LS – ES. 

Частный (свободный) резерв времени FF (Free Float) – промежуток времени, на который можно задержать начало работы или увеличить ее длительность без изменения раннего начала последующих работ. Частный резерв находят как разность между ранним началом последующей работы и ранним окончанием рассматриваемой: FF_{I – J} = ES_{J – K} – EF_{I – J}.

Работы, у которых ранние и поздние сроки начала и окончания совпадают, называют критическими, то есть резерв времени = 0. Работы, у которых ранние и поздние сроки начала и окончания не совпадают, называют некритичными, то есть резерв времени ≠ 0.

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

Расчет показателей сетевого графика приведён в таблице 2.

Таблица 2 – Показатели сетевого графика проекта

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

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

Критический путь 1 состоит из работ:

1.1 – 1.2 – 1.4 – 2.1 – 2.2 – 2.3 – 3.1 – 3.4 – 3.5 – 3.6 – 3.7 – 3.8 – 4.1 – 4.2 – 5.1 – 5.2 – 5.3.

Критический путь 2 состоит из работ:

1.1 – 1.2 – 1.4 – 2.1 – 2.2 – 2.3 – 3.1 – 3.4 – 3.5 – 3.6 – 3.7 – 3.8 – 4.1 – 4.2 – 5.1 – 5.2 – 5.4.

Определим длительность критического пути:

Критический путь 1 = 3 + 4+ 1 + 4 + 6 + 5 + 14 + 10 + 6 + 5 + 7 + 4 + 3 + 2 + 4 + 5 + 4 = 87 дней.

Критический путь 1 = 3 + 4+ 1 + 4 + 6 + 5 + 14 + 10 + 6 + 5 + 7 + 4 + 3 + 2 + 4 + 5 + 4 = 87 дней.

2.4. Оценка стоимости проекта

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

В расходную часть бюджета проекта необходимо включить такие расходы: затраты на Интернет; затраты на электроэнергию; оплату выделенного сервера или хостинга; оплату за размещение в Google Play и App Store; оплату за техническую поддержку и обновления.

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

Приведем примерную калькуляцию оценки рабочего времени специалистов таблице 3.

Таблица 3 – Стоимость трудовых ресурсов