Файл: Разработка и построение ИСР проекта. Структурная декомпозиция работ.pdf

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

1.2. Разработка иерархической структуры работ как один из способов управления проектами

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

«Работа» – самое точное определение осуществляемых в ходе достижения проектных целей процедур в силу максимальной близости к задачному контексту проектной деятельности. Работу и задачу легче всего грамотно декомпозировать (разбить) на составляющие операции и подзадачи.

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

В словаре ИСР указываются:

• номер элемента в структуре;
• название элемента;
• продолжительность операции;
• предшественник и последователь элемента;
• результаты;
• ответственный за операцию участник.

ИСР формируется на основе ряда правил, два из которых являются ключевыми:

1. Правило 100%. Специальное правило самопроверки обязывает собирать в структуру все создаваемые продукты, результаты работ, операций вне зависимости от источника их производства: внутреннего или внешнего. Это правило применяется ко всем элементам создаваемой иерархии. Ответственное за создание структуры проекта лицо обязано каждый раз после завершения списка раздела задавать вопрос: «Все ли мы учли, что могли забыть?». На практике это представляет собой весьма дискомфортную процедуру. Поэтому практически сразу с момента начала работы над структурой PM следует привлекать экспертов. Именно здесь начинается детальное планирование и нужны те, кто досконально разбирается в отдельных процессах.
2. Правило взаимоисключения элементов. Каждый раз разбивая результат на детализированные элементы, нужно применять ясный критерий, при этом отслеживать, чтобы полученные объекты не смешивались на одном уровне и не дублировались на разных «веточках» иерархии. Под «веточками» далее будем понимать выделенные иерархические разделы, имеющие дальнейшее разбиение вниз. В иерархии не допустимы два или более элемента с идентичным содержанием. Эта ошибка может привести к дублированию операций и конфликтам.

---

Основные ориентиры (условия) при создании структуры работ следующие:

1. Для каждого элемента структуры формулируется измеримый результат.
2. Каждый результат вышестоящего элемента носит агрегированный характер, т.е. является итогом результатов «дочерних» элементов декомпозиции.
3. Пакеты и отдельные операции должны быть уникальными.
4. Структура должна быть полной, но не избыточной.
5. Элементы структуры верхних уровней должны быть совместимы с организационной структурой проекта.
6. Размер элементов нижнего уровня должен быть достаточным для эффективного управления, но не избыточным для их контроля.

Мы можем представить ИСР как разбиение проекта по фазам, этапам или процессам проекта. Пример разбития ИСР по этапам проекта расположен на рисунке 6.

Рисунок 6 Пример разбития ИСР по этапам проекта

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

Вывод по главе «управление проектами: сущность, способы и методы»:

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

ГЛАВА 2.ПОСТРОЕНИЕ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ РАБОТЫ НА ПРИМЕРЕ ПРОЕКТА

2.1. Характеристика проекта

Выбранный проект представляет собой SPA (Single Page Application) приложение, которое облегчает управление проектами по гибкому методу SCRUM, так как на рынке нет подобных приложений, у нас отсутствуют прямые конкуренты, только косвенные, следовательно, наш проект является инновационным, поэтому мы будем использовать метод PERT.

При использовании метода PERT мы должны построить 3 сетевые модели для трёх разных сроков:

1. Оптимистический;
2. Наиболее вероятный;
3. Пессимистический.

Наш проект носит название «SteAndri», в честь основателей проекта.

---

Цель проекта: создать SPA приложения для управление по SCRUM методу.

Результаты: результаты нашего проекта - это готовое приложения для управления проектами по методологии SCRUM.

Работы проекта:

1. Появление идеи;
2. Анализ рынка;
3. Создание концепции;
4. Разработка бизнес модели;
5. Выбор технологий для проекта;
6. Набор людей для проекта;
7. Продумывание Ux/Ui пользователя;
8. Создание дизайна сайта;
9. Создание Frontend части приложения;
10. Создание Backend части приложения;
11. Модульное тестирование;
12. Регрессивное тестирование;
13. Выбор хостинга для приложения;
14. Деплой приложения;
15. Заказ рекламы.

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

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

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

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

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

Продумывание Ux (User experience) пользователя: на этом этапе продумываем типичное поведение пользователя в приложении.

Создание Ui (User Interface) сайта: на этом этапе мы придумываем как будет выглядеть интерфейс нашего приложения, какие будут анимации, какие будут цвета и т.д.

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

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

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

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

Регрессивное тестирование: на этом этапе тестировщик или программист занимается написанием регрессивных тестов, которые предназначены для проверки работы приложения при смене API (Application Programming Interface интерфейс программирования приложений, позволяющий сервисам взаимодействовать, получать доступ и обмениваться данными)

---

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

Деплой: на этом этапе программист занимается развертыванием приложения на новой машине/или на той же самой, но новой его версии. То есть, деплой это процесс (так или иначе организованный) перевода кода вашего проекта в рабочее состояние на конкретной машине.

Заказ рекламы: на этом этапе заказывается реклама на тематических платформах с возможной будущей аудиторией нашего приложения.

Теперь укажем сроки проекта, а затем распишем его бюджет

1. Сроки (65дней):
   1. 10 дней на прединвестиционный этап.
   2. 15 дней на этап разработки.
   3. 25 дней на этап реализации.
   4. 15 дней на этап завершения.
2. Бюджет
   1. 2500 рублей.
3. Участники
   1. Ефремов Степан (дизайнер).
   2. Ефремов Степан (frontend разработчик).
   3. Ефремов Степан (тестировщик).
   4. Цыганок Андрей (backend разработчик).
   5. Цыганок Андрей (тестировщик).
4. Заинтересованный стороны.
   1. Обычные пользователи приложения.
   2. Компании.
5. Критерии успешности
   1. Уложиться в установленные сроки.
   2. Уложиться в установленный бюджет.
6. Требования к проекту
   1. Frontend часть сайта написана с использованием React [1], Redux [2], Formik [3], TypeScript [3].
   2. Git [7] для контроля версий кода проекта.
   3. Backend часть написана с использованием Expressjs [4].
   4. База данных создана с использованием PostgreSQL [5].

Вывод по «главе характеристика проекта»: в этой главе мы ознакомились объектом исследования, его свойствами и требованиями и т.д.

ГЛАВА 2.2 Построение иерархической структуры работ проекта, сетевых моделей, календарного плана

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

Рисунок 7. Иерархическая структура работ «SteAndri».

После построения иерархической структуры работ, нам требуется построить сетевые модели вида «Работа-Дуга» с учётом 3 вариантов времени и «Работа-Вершины» с учётом наиболее вероятного времени для оценки времени работ и проекта в целом, во время построения сетевой модели мы будем обосновывать последовательность работ, опираясь на иерархическую структуру работ.

---

На рисунке 11 изображена сетевая модель вида «Работ-Дуга» с учетом оптимистической оценки времени реализации проекта.

Рисунок 8. Сетевой модели вида «Работ-Дуга» с учётом оптимистичного времени.

Продолжение рисунка 8.

Продолжение рисунка 8.

Теперь рассмотрим сетевую модель вида «Работ-Дуга» с учётом наиболее вероятного времени на рисунке 12.

Рисунок 9. Сетевой модели вида «Работ-Дуга» с учётом наиболее вероятного времени.

Продолжение рисунка 9.

Продолжение рисунка 9.

Так же нужно построить сетевую модель вида «Работ -Вершина» с учётом наиболее вероятного времени, модель находится на рисунке 13.

Рисунок 10. Сетевой модель вида «Работа-Вершина» с учетом наиболее вероятного времени.

Продолжение рисунка 10.

Продолжение рисунка 10.

Продолжение рисунка 10.

Осталось рассмотреть последнее время, на рисунке 14 изображён сетевая модель вида «Работ-Дуга» с учётом пессимистичного времени.

Рисунок 11. Сетевой модели вида «Работ-Дуга» с учётом пессимистичного времени.

Продолжение рисунка 11.

Продолжение рисунка 11.

На рисунке 15 представлен календарный план проекта, построенный на основе сетевой модели вида «Работ-Вершина» с учётом наиболее вероятного времени.

Рисунок 12. Календарный план проекта «SteAndri».

Продолжение рисунка 12.

Продолжение рисунка 12.

Вывод по главе «построение иерархической структуры работ проекта, сетевых моделей, календарного плана».

---