Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПР / ПР4_Хакова_ИСТ-223.docx
Скачиваний:
0
Добавлен:
07.06.2026
Размер:
322.17 Кб
Скачать

5 Управление рисками и коммуникации

Понятие критического пути

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

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

Определение критического пути является важным этапом планирования, так как позволяет:

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

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

минимизировать риск срыва сроков;

эффективно распределить ресурсы.

Метод определения критического пути

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

Основными критериями включения задачи в критический путь являются:

наличие логической зависимости от предыдущих задач;

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

отсутствие временного резерва.

Критический путь проекта

На основе анализа структуры работ и календарного плана был определён следующий критический путь:

Сбор требований  Формирование требований  Архитектура  Разработка клиентской части  Интеграция системы  Тестирование приложения  Подготовка документации.

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

Сбор и формирование требований являются базой для всех последующих этапов. Ошибки на данном этапе могут привести к необходимости переработки проекта.

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

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

Интеграция системы невозможна без завершения разработки ключевых компонентов.

Тестирование приложения проводится после интеграции и необходимо для выявления и устранения ошибок.

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

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

Работы, не входящие в критический путь

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

К таким задачам относятся:

UI/UX проектирование;

разработка серверной части;

подготовка отчёта.

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

Контроль выполнения критических задач

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

Для предотвращения срыва сроков проекта необходимо:

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

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

оперативно реагировать на возникающие проблемы;

при необходимости перераспределять ресурсы.

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

УПРАВЛЕНИЕ РИСКАМИ

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

Своевременное управление рисками позволяет снизить вероятность возникновения проблем и обеспечить успешную реализацию проекта.

Реестр рисков проекта

В рамках проекта были выявлены основные риски, представленные в таблице 5.

Таблица 5 – Реестр рисков проекта

Риск

Вероятность

Влияние

Уровень риска

1

Нехватка времени

Высокая

Высокое

Критический

2

Ошибки в разработке

Средняя

Среднее

Средний

3

Перегрузка функционалом

Средняя

Высокое

Высокий

4

Потеря данных

Низкая

Среднее

Низкий

Анализ рисков

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

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

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

План реагирования на риски

Для каждого риска разработаны меры минимизации, которые представлены в таблице 6.

Таблица 6 – План реагирования на риски

Риск

Меры реагирования

Нехватка времени

Чёткое планирование, контроль сроков

Ошибки в разработке

Регулярное тестирование

Перегрузка функционалом

Ограничение проекта рамками MVP

Потеря данных

Резервное копирование

Стратегии управления рисками

В рамках проекта применяются следующие стратегии:

предотвращение риска;

снижение риска;

контроль риска;

принятие риска.

КОМАНДА ПРОЕКТА И КОММУНИКАЦИИ

Участники проекта

В проекте участвуют следующие стороны:

разработчик (студент);

преподаватель;

пользователи.

Карта участников проекта

Таблица 7 – Карта участников

Участник

Роль

Влияние

Интерес

Студент

Разработчик

Высокое

Высокий

Преподаватель

Контроль

Высокое

Высокий

Пользователи

Пользователи

Низкое

Высокий

Расширенная характеристика участников проекта

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

Таблица 8 – Карточка участника проекта (разработчик)

Параметр

Описание

Участник

Разработчик

Роль

Основной исполнитель

Основные задачи

Анализ, проектирование, разработка, тестирование

Ответственность

Реализация приложения и документации

Уровень участия

Высокий

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

Таблица 9 – Карточка участника проекта (преподаватель)

Параметр

Описание

Участник

Преподаватель

Роль

Контроль и консультирование

Основные задачи

Проверка работы, рекомендации

Ответственность

Оценка проекта

Уровень участия

Средний

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

Таблица 10 – Карточка участника проекта (пользователь)

Параметр

Описание

Участник

Пользователь

Роль

Конечный пользователь

Основные задачи

Использование приложения

Ответственность

Эксплуатация системы

Уровень участия

Низкий

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

Анализ организации коммуникаций

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

Коммуникации в проекте направлены на:

  • контроль выполнения задач;

  • обсуждение промежуточных результатов;

  • выявление проблем и рисков;

  • согласование решений.

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

  • еженедельные консультации с преподавателем;

  • промежуточные отчёты по этапам;

  • финальная защита проекта.

Инструменты коммуникации

Средства коммуникации

Для взаимодействия используются:

  • электронная почта;

  • мессенджеры;

  • онлайн-консультации;

  • личные встречи.

Расширенный план совещаний представлен в таблице 11.

Таблица 11 – План совещаний проекта

Тип совещания

Участники

Периодичность

Цель

Рабочие встречи

Разработчик, преподаватель

1 раз в неделю

Контроль прогресса

Консультации

Разработчик, преподаватель

По необходимости

Решение проблем

Итоговые встречи

Разработчик, преподаватель

По завершении этапов

Подведение итогов

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

АНАЛИЗ И ПЕРСПЕКТИВЫ РАЗВИТИЯ ПРОЕКТА

Необходимые изменения для практической реализации

Для внедрения проекта в реальную среду необходимо внести ряд изменений:

  • расширить функциональность приложения;

  • реализовать серверную инфраструктуру;

  • обеспечить защиту данных пользователей;

  • внедрить систему масштабирования.

Ограничения текущей версии

Текущая версия проекта имеет ограничения:

  • отсутствие коммерческой модели;

  • ограниченный функционал;

  • отсутствие многопользовательских возможностей.

Перспективы развития проекта

Возможные направления развития:

  • разработка версии для iOS;

  • внедрение искусственного интеллекта;

  • расширение базы уроков;

  • внедрение геймификации;

  • интеграция с онлайн-сервисами.

Соседние файлы в папке ПР