Главная страница
Навигация по странице:

  • 1.4 Управление качеством и рисками проекта

  • 2 Специальный раздел 2.1 Разработка целей и задач проекта, построение матрицы ЖЦ проекта

  • 2.2 Составление таблицы состава операций и расписания в рамках проекта

  • 2.3Управление рисками и качеством проекта

  • курсовой проект Разработка проекта и анализ затрат внедрения ИС для клуба по интересам. курсач (автовосстановление). Учебный комплекс информационных технологий курсовой проект по мдк 04. 01 Обеспечение проектной деятельности Тема Разработка проекта и анализ затрат внедрения ис для клуба по интересам Допускаю


    Скачать 1.1 Mb.
    НазваниеУчебный комплекс информационных технологий курсовой проект по мдк 04. 01 Обеспечение проектной деятельности Тема Разработка проекта и анализ затрат внедрения ис для клуба по интересам Допускаю
    Анкоркурсовой проект Разработка проекта и анализ затрат внедрения ИС для клуба по интересам
    Дата15.09.2022
    Размер1.1 Mb.
    Формат файлаdocx
    Имя файлакурсач (автовосстановление).docx
    ТипУчебный комплекс
    #678959
    страница2 из 3
    1   2   3

    1.3 Выбор и применение инструментальной проектной среды

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

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

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

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

    Задачи – это краткое описание действий, которые необходимо выполнить для достижения цели.

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

    При постановке задачи Microsoft Project позволяет работать над отдельными задачами и подзадачами. Позволяет установить следующие параметры:

    - название;

    - дата начала и окончания;

    - процент завершения;

    - длительность;

    - приоритет;

    - ресурсы;

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

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

    При проектировании также используется типовое решение «1С: ERP управление предприятием». «1С: ERP» — это, прежде всего, инструмент для объединения бизнес-процессов организации в одной мощной системе. ERP-системы предназначены для хранения и обработки большинства критически важных для компании сведений, они позволяют объединить все информационные ресурсы предприятия в единый механизм. Данное программное обеспечение нужно:

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

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

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

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

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

    - чтобы повысить эффективность работы коммерческих и логистических служб, улучшить качество обслуживания клиентов, повысить точность и оперативность получения информации.
    1.4 Управление качеством и рисками проекта

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

    Причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть “известные” — те, которые определены, оценены, для которых возможно планирование. Риски “неизвестные” — те, которые не идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть.

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

    • планирование управления рисками — выбор подходов и планирование деятельности по управлению рисками проекта.

    • идентификация рисков — определение рисков, способных повлиять на проект, и документирование их характеристик.

    • качественная оценка рисков — качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

    • количественная оценка — количественный анализ вероятности возникновения и влияния последствий рисков на проект.

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

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

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

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

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

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

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


    2 Специальный раздел

    2.1 Разработка целей и задач проекта, построение матрицы ЖЦ проекта

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

    Для выполнение всех этапов жизненного цикла проекта была использована программа Microsoft Project. Был создан проект для дальнейшего планирования (рисунок 4).



    Рисунок 4 – Создал новый проект в Microsoft Project

    Создал новую задачу и назвал её «Анализ проектной области» и задал ей дату начала. Далее создал остальные задачи нужные для моего проекта указанные на рисунок 5.


    Рисунок 5 – Проект с заполненными задачами

    После я заполнил лист необходимыми ресурсами для моего проекта.



    Рисунок 6 – Лист ресурсов

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


    Рисунок 7 – График трудозатрат

    В 1С: ERP Управление предприятием создали проект и назначили задачи.



    Рисунок 8 - Созданный проект в 1С: ERP


    Рисунок 9 – Задачи проекта

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

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


    Рисунок 10 – Сценарий бюджетирования проекта

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


    Рисунок 11 – Создание статьи бюджетов «Поступление оплаты от покупателей»
    2.2 Составление таблицы состава операций и расписания в рамках проекта

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

    Ниже будет показана таблица состава операций для разработки информационной системы «Клуб по интересам».

    Таблица 1 – Состав операций



    Название задачи

    Описание задачи

    Дата начала

    Дата окончания

    1

    Постановка задачи

    Составление информационно- технологической схемы с выделением этапов решения

    09.09.2021

    22.09.2021

    2

    Разработка интерфейса

    Процесс проектирования пользовательского интерфейса с применением моделирования пользовательских функций

    23.09.2021

    29.09.2021

    3

    Разработка модулей обработки данных

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

    30.09.2021

    08.10.2021


    Продолжение таблицы 1

    4

    Разработка структуры базы данных

    Проектирование базы данных для взаимодействия с

    модулями обработки данных

    23.09.2021

    30.09.2021

    5

    Заполнение базы данных




    01.10.2021

    12.10.2021

    6

    Отладка программного комплекса

    процесс поиска ошибок в программном комплексе, и их исправления

    11.10.2021

    20.10.2021

    7

    Тестирование и исправление ошибок

    Процесс поиска ошибок при работе с информационной системы для их выявления и устранения

    14.10.2021

    27.10.2021

    8

    Составление программной документации

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

    21.10.2021

    27.10.2021


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

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

    Матрица ответственности устанавливает связи между работами, определенными в структуре проекта, и сотрудниками, планируемыми на исполнение задач. Каждой задаче могут быть назначены несколько сотрудников. Степень ответственности сотрудников обозначена как «О»-основная ответственность, «В» — вспомогательная ответственность.

    Таблица 2 – Матрица ответственности

    Задачи

    Исполнители

    Сотрудник №1

    Сотрудник №2

    Сотрудник №3

    Описание предметной области

    В

    О

    О

    Программирование

    В

    О

    О

    Написание технической документации

    О

    В

    В

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

    О

    О

    О

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

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

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

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

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

    Методы сбора информации:

    - мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.

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

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

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

    Опросы экспертов с большим опытом работы над проектами.

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

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

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

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

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

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

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

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

    Таблица 3 – Шкала воздействия рисков



    Проект

    Цель

    Показаны

    Очень

    низкая /

    0,05


    Низкая /

    0,10


    Умеренная/

    0,20


    Высокая /

    0,40

    Очень

    высокая /

    0,80


    Стоимость

    Незначительное

    увеличение стоимости

    Увеличение стоимости <10%

    Увеличение

    стоимости 10-20%

    Увеличение

    стоимости 30-40%

    Увеличение

    стоимости >40%


    Сроки

    Незначительное

    увеличение

    времени

    Увеличение времени

    <5%

    Увеличение времени

    5-10%

    Увеличение времени

    15-20%

    Увеличение времени

    >20%


    Содержание

    Едва заметное уменьшение

    содержания

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

    Затронуты основные области содержания

    Уменьшение содержания неприемлемо для спонсора

    Конечный продукт проекта фактически бесполезен


    Качество

    Едва заметное понижение качества

    Затронуты только самые трудоемкие приложения

    Для понижения качества требуется одобрение спонсора

    Понижение неприемлемо для спонсора

    Конечный продукт проекта фактически бесполезен


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

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

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

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

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

    Таблица 4 – Роль и ответственность участвующих в проекте

    Роль

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

    Руководитель

    Своевременное выявление рисков, оценка, управление, определение стратегии.

    Менеджер

    Разработка методологии, повышение осведомленности, сопровождение процесса и поддержка

    Участник

    Участие в процессе принятий решений


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

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

    Каждый раз при выявлении фактора, способного повлиять на выполнение проекта, его следует оценить и внести в реестр рисков.
    Таблица 5 – Реестр рисков проекта



    Описание риска

    Вероятность наступления

    Влияние

    Тяжесть Последствий, уровень

    Возможные последствия

    1

    Невозможность работы в 1С пользователей с ограничением по количеству лицензий

    2

    3

    Оправданный

    Отсутствие необходимого количества лицензий для пользователей

    2

    Нестабильность бизнес-процессов

    из-за непрекращающихся изменений на

    предприятии

    2

    4

    Оправданный

    Ухудшение управления организацией

    3

    Недостаточная производительность внедряемой системы

    1

    4

    Приемлемый

    Финансовые потери

    4

    Ввод в эксплуатацию с незамеченными ошибками

    3

    3

    Оправданный

    Нестабильность работы системы

    5

    Неверно рассчитанная длительность проекта

    4

    5

    Недопустимый

    Финансовые издержки из-за простоя

    6

    Неверно рассчитанный бюджет проекта

    5

    5

    Недопустимый

    Непредвиденные издержки на протяжении проекта

    1   2   3


    написать администратору сайта