Дипломная работа: Автоматизация документооборота учета материально-технического оборудования в ООО "ТРАНСКОМ"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
56
состояние; координирование работы над проектом. С помощью
интеграции можно находить компромиссы между пересекающимися
целями и альтернативными вариантами.
Управление содержанием. Сюда относятся такие процессы как
создание иерархической структуры работ по проекту, определение,
планирование, подтверждение и управление содержанием.
Управление сроками. Здесь определяется состав операций и
взаимосвязи между ними, оцениваются ресурсы и длительность
операций, разрабатывается расписание и производится управлением
им.
Управление стоимостью. Имеется в виду разработка бюджета и
контроль затрат. Для успешной реализации проекта осуществляется
стоимостная оценка, разрабатывается бюджет расходов и производится
управление стоимостью.
Управление качеством. Эта область включает все процессы, связанные
с выполнением целей. К ним относятся планирование, обеспечение и
контроль качества.
Управление человеческими ресурсами. Направление действий –
организация проектной команды и управление ей. Планируются
человеческие ресурсы, набирается и развивается коллектив,
предпринимаются меры по управлению командой.
Управление коммуникациями. Планируются коммуникации,
распространяется информация, создается отчетность по исполнению,
происходит управление участниками проекта.
Управление рисками. Процессы, относящиеся к данной области, – это
планирование управления рисками, идентификация, качественный и
количественный анализ рисков, планирование реагирования,
мониторинг и управление рисками.
Управление поставками. К этой области относится планирование
покупок и контрактов, запрос информации у поставщиков, подбор
поставщиков, администрирование и закрытие контрактов.
57
Методы PMBoK: управление освоенным объемом (EVM-метод),
выравнивание ресурсов, оценка «снизу вверх», быстрый подход, дерево
решений, анализ допущений, метод набегающей волны, анализ сети, мозговой
штурм, оценка и анализ программ (PERT-метод), метод Монте-Карло, метод
Дельфи, анализ отклонений, метод «операции в узлах» (PDM-метод), SWOT-
анализ, метод критической цепи, метод критического пути (CPM-метод),
декомпозиция, анализ ожидаемого денежного значения (EMV-метод), анализ
чувствительности, метод освоенного объема, анализ характера и последствий
отказов (FMEA-метод).
Инструменты PMBoK: система управления конфигурацией, система
управления изменениями, сетевая модель, матрица вероятности и воздействия,
диаграмма Парето, расписание контрольных событий, система
санкционирования выполненных работ, расписание контрольных событий,
диаграмма Ганта, матрица ответственности, информационная система
управления проектами, иерархическая структура рисков.
Унифицированный процесс Rational это универсальная методология
распределения задач и сфер ответственности при разработке программного
обеспечения. Её цель – создание высококачественного программного
обеспечения, отвечающего потребностям и запросам пользователей.
Методология RUP была разработана в компании Rational Software Corporation,
которую в 2003 году купила IBM [19].
Невероятный успех предложенного в рамках RUP подхода помог многим
компаниям понять, насколько важно иметь чётко прописанный и за
документированный процесс разработки.
Методология RUP предназначена для крупных проектов разработки,
поэтому многие менеджеры уверены, что она не подойдёт для небольших задач,
не требующих большого объёма ресурсов. Но есть множество примеров, когда
небольшие проекты значительно выигрывали от внедрения RUP.
Работа над процессом– команда разработчиков RUP тесно работает с
покупателями, партнёрами и группами компаний, постоянно обновляя
методологию.
58
RUP оптимизирует командную работу– обеспечивает команде
разработчиков свободный доступ к базе знаний с инструкциями для
использования программных средств. Это помогает быстрее справиться с
критическими проблемами. Благодаря этому команда легко находит общий язык
в процессе работы над проектом.
RUP ориентирован на создание и поддержание моделей– вместо
написания большого количества бумажной документации при использовании
RUP методологии создаются модели – семантические представления
разрабатываемого командой программного обеспечения.
RUP– это инструкция использования Unified Modelling Language (UML)
UML позволяет команде легко донести свои требования к проекту, его
архитектуру и план реализации.
RUP – это конфигурируемый процесс, он подходит как небольшим
группам разработчиков, так и крупным организациям.
Шесть основополагающих принципов RUP
В основе RUP лежит шесть главных принципов:
итеративная модель разработки– устранение рисков на каждой стадии
проекта позволяет лучше понять проблему и вносить необходимые
изменения, пока не будет найдено приемлемое решение;
управление требованиями–RUP описывает процесс организации и
отслеживания функциональных требований, документации и выбора
оптимальных решений (как в процессе разработки, так и при ведении
бизнеса);
компонентная архитектура– архитектура системы разбивается на
компоненты, которые можно использовать как в текущем, так и в
будущих проектах;
визуальное моделирование ПО – RUP методология разработки
показывает, как создать визуальную модель программного
обеспечения, чтобы понять структуру и поведение архитектуры и его
компонентов;
59
проверка качества ПО– в процессе разработки программного
обеспечения контролируется качество всех действий команды;
контроль внесённых изменений– отслеживание изменений позволяет
выстроить непрерывный процесс разработки. Создаётся благоприятная
обстановка, в рамках которой команда будет защищена от изменений в
рабочем процессе.
Жизненный цикл RUP разбит на четыре основных фазы, в каждой из
которых ведётся работа над новым поколением продукта: фазу начала проекта,
уточнение, построение и внедрение.
Фаза начала проекта. В этой фазе команда определяет структуру и
основную идею проекта. Команда решает, стоит ли вообще заниматься этим
проектом, исходя из его предполагаемой стоимости, необходимых ресурсов и
цели, которую нужно достичь.
Уточнение. Цель этой фазы анализ требований к системе и её
архитектуры, разработка плана проекта и устранение элементов наивысшего
риска. Это самая важная фаза из всех, поскольку она знаменует переход от
низкого уровня риска к высокому. В рамках этой фазы команда решает,
переходить ли к фазе построения (разработке и написанию кода) или нет.
Построение. В этой фазе RUP методологии команда начинает разработку
всех компонентов и функций программного обеспечения, интегрирует их в
конечный продукт. Это производственный процесс, в рамках которого команда
сосредоточена на управлении ресурсами, чтобы оптимизировать расходы, время
и качество продукта.
Внедрение. Фаза, когда продукт готов и доставлен покупателям. Но после
того как пользователи получают продукт, могут возникнуть новые трудности.
Команде нужно будет исправить ошибки, отловить баги и доделать функции,
которые не были реализованы в первично установленный срок.
В конце каждой фазы существует отметка завершения этапа (Project
Milestone) – момент, когда ваша команда оценивает, достигнуты ли
поставленные цели. При этом команда принимает важные решения, влияющие
на ход следующей фазы.
60
Основой Scrum-методологии является итеративная разработка, а сама она
определяет несколько характеристик при работе с проектами [20]:
правила планирования и управления списком требований к
разрабатываемому продукту;
правила планирования итераций;
правила взаимодействия между членами проектной команды;
правила анализа и корректировки процесса разработки.
Каждая итерация проекта может быть представлена в виде цепочки:
планирование – фиксирование – реализация – анализ. Благодаря фиксированным
требованиям к одной итерации, как к фазе выполнения проекта, а также
возможности менять длину итераций, можно эффективно управлять балансом
гибкости и планируемости разработок.
В системе Agile Scrum-управление проектами состоит из трех
основополагающих частей:
роли;
практики;
документы (артефакты).
Всего в Скрам есть три роли:
владелец продукта (Product Owner);
скрам-мастер (Scrum Master);
команда разработчиков (Delivery Team);
Владельцем продукта является человек, который отвечает за его
разработку. Как правило, это либо официальный представитель, либо
доверенное лицо заказчика. Также он может представлять рынок, на котором
продукт будет реализовываться.
Владелец продукта в обязательном порядке составляет бизнес-план, где
отражается ожидаемая доходность, и план развития, включающий требования,
отсортированные по коэффициенту окупаемости вложений.
Руководствуясь имеющейся информацией, владелец продукта
разрабатывает список требований, который также рассортирован по значимости.
По сути, владельца продукта можно назвать центром принятия окончательных
Источник: https://baza.diplomsite.ru/previewfile/1755