Курсовая Работа Планирование содержания проекта. МитрошинВариант11. Разработка и анализ модели процесса заданной предметной области с использованием методов и инструментов idef
 Скачать 1.04 Mb.
|
|
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «РЯЗАНСКИЙ ГОСУДАРСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ИМЕНИ В.Ф. УТКИНА» Кафедра «Космические технологии» К защите Руководитель проекта ________________________ дата, подпись ПОЯСНИТЕЛЬНАЯ ЗАПИСКА к курсовому проекту по курсу: «Основы CASE- и CALS-технологий» по теме: «Разработка и анализ модели процесса заданной предметной области с использованием методов и инструментов IDEF» Выполнил: студент группы 948 Митрошин Г.Е. дата сдачи на проверку, подпись Проверил: проф. каф. КТ Таганов А.И. _____________ _________________ оценка дата защиты, подпись Рязань, 2022 Введение. Для того чтобы успешно выполнить проект, объект проектирования должен быть прежде всего правильно и адекватно описан, то есть необходимо построить полноценные и функциональные информационные модели объекта проектирования. В России управление проектами начало развиваться относительно недавно, нооно уже успело показать свою значимость и необходимость в экономике страны. Управление проектами — общность процессов (методик, моделей, программных и технических средств, методологий), которые осуществляются при разработке и реализации проектов, процессы эти имеют ограничения во времени, требуют затрат ресурсов. Для того чтобы проект был успешен, необходимо уметь управлять ресурсами проекта. Управление ресурсами является разделом управления проектами, которыйотражает в себе только те процессы, которые достаточны и необходимы для обеспечения целей проекта за счет оптимального использования имеющихся ресурсов. Планирование — процесс, который доложен осуществляться в соответствиис проектно-сметной документацией, основываясь на общем плане проекта. В процессе планирования должен быть произведен общий анализ работ и ресурсов.Необходимо учитывать ограничение ресурсов и их прогнозное распределение наоснове графиков потребности в ресурсах. Планирование ресурсов проекта — оченьважный процесс, который является основой не только определения во времени потребностей в ресурсах, но и основой планирования поставок ресурсов, основой определения возможности обеспечения ресурсами для заключения контрактов позакупкам ресурсов, а также основой для того, чтобы благоразумно распределятьуже закупленные ресурсы по работам проекта. Ресурсы оказывают влияние практически на все основные параметры проекта (стоимость, сроки, качество), в конечном итоге определяя возможность или невозможность его выполнения. Ресурсное планирование — основная составляющая управления проектами. Ресурсное планирование - это не только разработкаи анализ ресурсов и работ, которые направлены на достижение целей проекта,это еще и разработка системы распределения ресурсов, контроль над ходом работ(сравнение фактических и плановых параметров работ, выбор корректирующихдействий), выбор исполнителей. Задачи изучения дисциплины заключаются: в изучении теоретических основ организационно-управленческой, аналитической деятельности, осуществляемойв ходе реализации проектов; освоении проблематики управления ресурсами проектов; знакомстве с основными подходами и методами управления ресурсами проектов. CALS (Continuous Acqusition and Life cycle Support) – это всесторонние и всеобъемлющие технологии по поддержке жизненного цикла изделий. CALS-технологии призваны служить средством, интегрирующим промышленные автоматизированные системы в единую многофункциональную систему. Целью интеграции автоматизированных систем проектирования и управления является повышение эффективности создания и использования сложной техники.В чем выражается повышение эффективности? • Во-первых, повышается качество изделий за счет более полного учета имеющейся информации при проектировании и принятии управленческих решений. • Во-вторых, сокращаются материальные и временные затраты на проектирование и изготовление продукции. • В-третьих, существенно снижаются затраты на эксплуатацию, благодаря реализации функций интегрированной логистической поддержки. 1. Теоретическая часть. 1.1 Возникновение концепции CALS и её эволюция. \ Впервые работы по созданию интегрированных систем,поддерживающих жизненный цикл продукции, были начаты в 80-х годах воборонном комплексе США. Новая концепция была востребована жизньюкак инструмент совершенствования управления материальнотехническимобеспечением армии США. Предполагалось, что реализации новой концепции, получившей обозначение CALS (ComputerAidedLogisticSupport– компьютерная поддержка процесса поставок), позволит сократить затраты на организацию информационного взаимодействия государственных учреждений с частными фирмами в процессах формализации требований,заказа, поставок и эксплуатации военной техники. Появилась реальная потребность в организации информационно-интегрированной системе, обеспечивающей обмен данными между заказчиком, производителями и потребителями военной техники, а также повышение управляемости, сокращение бумажного документооборота и связанных с ним затрат. Доказав свою эффективность, концепция последовательносовершенствовалась, дополнялась и, сохранив существующую аббревиатуруCALS, получила более широкую трактовку – Continuous Acqusition and Life cycle Support – непрерывные поставки и информационная поддержка жизненного цикла продукции. Первая часть – Continuous Acqusition означает непрерывность информационного взаимодействия с заказчиком в ходе формализации его потребностей, формирования заказа, процесса поставки ит.д. Вторая часть – Life Сycle Support– означает системность подхода к информационной поддержке всехпроцессов жизненного цикла изделия, в том числе процессов эксплуатации,обслуживания, ремонта и утилизации и т.д. В руководстве по применениюCALS в НАТО CALS определяется как "…совместная стратегия государстваи промышленности, направленная на совершенствование существующихпроцессов в промышленности, путем их преобразования в информационно-интегрированную систему управления жизненным циклом изделий". Русскоязычное наименование этой концепции и стратегии – ИПИ - Информационная Поддержка жизненного цикла Изделий. В период 1990-2000гг. в мире был выполнен ряд проектов, направленных на апробацию и внедрение принципов CALS в различных отраслях промышленности. Поскольку термин CALS всегда носил военный оттенок, в гражданской сфере широкое распространение получили термины Product Life Cycle Support (PLCS) или ProductLifeManagement (PLM) – "поддержка жизненногоцикла изделия" или "управление жизненным циклом изделия". Таким образом, идея, связанная только с поддержкой логистических систем, превратилась в глобальную бизнес-стратегию перехода на безбумажную электронную технологию и повышения эффективности бизнеспроцессов за счет информационной интеграции и совместного использованияинформации на всех этапах жизненного цикла продукции. В настоящее времяв мире действуют более 25 национальных организаций, координирующихвопросы развития CALS-технологий, в том числе в США, Канаде, Японии,Великобритании, Германии, Швеции, Норвегии, Австралии, а также в НАТО.  1.2 Концептуальная модель CALS. Основное содержание концепции CALS, принципиально отличающее ее от других, составляют инвариантные понятия, которые реализуются полностью или частично в течение жизненного цикла изделия, в соответствии с рисунком 1. Рисунок 1 — Общее содержание концепции CALS Эти инвариантные понятия условно делятся на три группы: Базовые принципы CALS; Базовые управленческие технологии; Базовые технологии управления данными. К числу первых относятся: 1. Системная информационная поддержка ЖЦ изделия на основе использования интегрированной информационной среды (ИИС), обеспечивающая минимизацию затрат в ходе ЖЦ; 2. Информационная интеграция за счет стандартизации информационного описания объектов управления; 3. Разделение программ и данных на основе стандартизации структур данных и интерфейсов доступа к ним, ориентация на готовые коммерческие программно-технические решения (Commercial Of The Shelf – COTS), соответствующие требованиям стандартов; 4. Безбумажное представление информации, использование электронно- цифровой подписи; 5. Параллельный инжиниринг (Concurrent Engineering); 6. Непрерывное совершенствование бизнес-процессов (Business Processes Reengineering). К числу вторых относятся технологии управления процессами, инвариантные по отношению к объекту (продукции): 1. Управление проектами и заданиями (Project Management/Workflow Management); 2. Управление ресурсами (Manufacturing Resource Planning); 3. Управление качеством (Quality Management); 4. Интегрированная логистическая поддержка (IntegratedLogisticSupport). К числу третьих относятся технологии управления данными об изделии, процессах, ресурсах и среде. 1.3 Базовые принципы CALS Интегрированная информационная среда Системная информационная поддержка и сопровождение ЖЦ изделия осуществляется в интегрированной информационной среде. Терминологический словарь определяет ИИС как "совокупность распределенных баз данных, содержащих сведения об изделиях, производственной среде, ресурсах и процессах предприятия, обеспечивающая корректность, актуальность, сохранность и доступность данных тем субъектам производственно-хозяйственной деятельности, участвующим в осуществлении ЖЦ изделия, кому это необходимо и разрешено. Все сведения (данные) в ИИС хранятся в виде информационных объектов". ИИС, в соответствии с концепцией CALS, представляет собой модульную систему, в которой реализуются следующие базовые принципы CALS: Прикладные программные средства отделены от данных; Структуры данных и интерфейс доступа к ним стандартизованы; Данные об изделии, процессах и ресурсах не дублируются, число ошибок в них минимизируется, обеспечивается полнота и целостность информации; Прикладные средства работы с данными представляют собой, как правило, типовые коммерческие решения различных производителей, что обеспечивает возможность дальнейшего развития ИИС. Все процессы информационного обмена посредством ИИС имеют своей конечной целью максимально возможное исключение из деловой практики традиционных бумажных документов и переход к прямому безбумажному обмену данными. Преимущества и технико-экономическая эффективность такого перехода очевидны. Тем не менее, на переходном периоде нужно обеспечить сосуществование и совместное использование как бумажной, так и электронной форм представления информации и гармонизировать применяемые понятия. 1.4 CASE- технологии За последние годы в области проектирования, разработки и сопровождения сложных систем сформировалось новое направление - CASE - технология (англ. Computer-Aided Software/System Engineering) или системы автоматизации проектирования/программирования - название активно развивающегося в мире направления, призванного сократить сложность, трудоемкость, сроки разработки и стоимость сложных технических проектов, в частности (откуда и произошла данная технология), проектов в сфере разработки ПО. CASE-система позволяет быстро и наглядно, на основе применения той или иной методологии системного анализа и проектирования, синтезировать облик создаваемой системы, оценить входящие в нее части и их взаимодействие. Очень распространенными подходами в CASE-технологиях являются применение визуальных методологий (диаграммы, графики, и пр.), внедрение элементов искусственного интеллекта, использование специально разработанных предметно-ориентированных языков. CASE-технологии широко применяются в сложных проектах в аэрокосмической и военной сферах. К широко известным в мире CASEсистемам относятся такие пакеты программ, как Rational Rose, BPWin, ERWin, Silverrun, Oracle Designer, PRO-IV, и др. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. 1.5 МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГОМОДЕЛИРОВАНИЯ IDEF0. Постоянное усложнение производственно-технических и организационно-экономических систем – фирм, предприятий, производств, и др. субъектовпроизводственно-хозяйственной деятельности - и необходимость их анализас целью совершенствования функционирования и повышения эффективностиобусловливают необходимость применения специальных средств описания ианализа таких систем. Эта проблема приобретает особую актуальность в связи с появлением интегрированных компьютеризированных производств иавтоматизированных предприятий. В США это обстоятельство было осознано еще в конце 70-ых годов, когдаВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM - Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий. Реализация программы ICAM потребовала создания адекватных методованализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Дляудовлетворения этой потребности в рамках программы ICAM была разработана методология IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственнотехнических и организационно-экономических систем (в дальнейшем, там, где это не вызывает недоразумений – систем). Общая методология IDEF состоит из трех частныхметодологий моделирования, основанных на графическом представлениисистем: IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы; IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы. 1.6 Синтаксис графического языка IDEF0. Набор структурных компонентов языка, их характеристики и правила, определяющие связи между компонентами, представляют собой синтаксис языка. Компоненты синтаксиса IDEF0 – блоки, стрелки, диаграммы и правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование (см. ниже). Стрелки представляют данные или материальные объекты, связанные с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу дляуправления конфигурацией модели. Блок - Блок описывает функцию. Типичный блок показан на рис. 1. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом или глагольным оборотом, описывающим функцию. Номер блока размещается в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте. Р  исунок 2 – Блок. Размеры блоков должны быть достаточными для того, чтобы включить имя блока; Блоки должны быть прямоугольными, с прямыми углами; Блоки должны быть нарисованы сплошными линиями. Стрелка - Стрелка формируется из одного или более отрезков прямых и наконечника на одном конце. Как показано на рис. 2, сегменты стрелок могут бытьпрямыми или ломаными; в последнем случае горизонтальные ивертикальные отрезки стрелки сопрягаются дугами, имеющими угол 90. Стрелки непредставляют поток или последовательность событий, как в традиционныхблок-схемах потоков или процессов. Они лишь показывают, какие данныеили материальные объекты должны поступить на вход функции для того,чтобы эта функция могла выполняться. Р  исунок 3 – Стрелки. Ломаные стрелки изменяют направление только под углом 90 град; Стрелки должны быть нарисованы сплошными линиями различной толщины; Стрелки могут состоять только из вертикальных или горизонтальных отрезков; отрезки, направленные по диагонали, не допускаются; Концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать ее; Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается; 1.7 Описание заданной предметной области В данном курсовом проекте нам была дана определенная предметная область – «Управление Содержанием проекта». План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль, а также закрытие. Он объединяет и консолидирует все вспомогательные планы управления и базовые планы, а также другую информацию, необходимую для управления проектом. Необходимость компонентов плана управления проектом определяется, исходя из потребностей проекта. Целями процесса «Управление Содержанием проекта» являются: Реестр извлеченных уроков . Обновления плана управления проектом • Любой компонент . Обновления активов процессов организации 2. Практическая часть Управление содержанием проекта (Project Scope Management) — раздел управления проектами, включающий в себя деятельность, обеспечивающую определение и включение в проект тех и только тех работ, которые необходимы и достаточны для создания продукта проекта и успешного завершения проекта. Заданной предметной областью данного курсового проекта является «Управление содержанием проекта» - это и есть главный блок, который декомпозируется на три: 1. Планирование управления содержанием. Планирование управления содержанием - процесс создания плана управления содержанием, документирующего, каким образом содержание проекта будет определяться, подтверждаться и контролироваться.  Рисунок – «Сбор требований» - Входы, инструменты и методы, выходы; План управления содержанием помогает снизить риск расползания содержания проекта. Основные компоненты плана: процесс подготовки подготовки подробного описания содержания проекта; процесс, который позволяет создавать ИСР из подробного описания содержания проекта; процесс, который определяет, как ИСР будет поддерживаться и одобряться; процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта; процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. План управления требованиями — это компонент плана управления проектом, описывающий способы анализа, документирования требований и управления ими. Компоненты плана управления требованиями: порядок планирования, отслеживания и составления отчетов о действиях в отношении требований; действия по управлению конфигурацией, такие как порядок инициирования изменений продукта, порядок анализа воздействий, их выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений; используемые метрики продукта и обоснование их использования; структура отслеживания, т. е. какие параметры требований будут отражены в матрице отслеживания. Сбор требований. Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. П  отребность — это общее описание ожиданий участников. Требование — это точное определение параметров результата, которые заказчик намерен получить. Рисунок – «Сбор требований» - Входы, инструменты и методы, выходы; Классы требований: Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят. Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон. Требования к решению (продукту), описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Функциональные требования описывают поведение продукта. Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта (надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д). Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем. Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. Требования к качеству, включающие в себя любое состояние или критерий, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту. Процесс сбора требований: Определение участников и заинтересованных сторон. Выявление требований. Обзор, структуризация, категоризация требований, включая определение индивидуальных и общих требований. Анализ и ранжирование требований. Формирование документов и спецификаций требований. − Согласование и утверждение требований. Для того, чтобы уменьшить список требований, необходимо: Связать требования снова с первоначальными целями. Если требование не способствует достижению цели, оно должно быть исключено. Распределить требования по категориям: «должно быть включено», «желательно включить», «хорошо бы включить», «нужно отклонить». Привести список требований в соответствие с возможностями. Если необходимо удалить некоторые требования категории «должно быть включено», следует вернуться и просмотреть цели со спонсором проекта до того, как двигаться дальше. Создать спецификацию требований, которая будет служить основой для контроля изменений. Решить, что делать с требованиями, которые были отклонены. Их необходимо сохранить для будущих обзоров как нереализованные потребности. Рассмотрим подробнее выходы «Сбора требований»: Документация по требованиям описывает, каким образом отдельные требования соответствуют бизнеспотребности в проекте. Требования должны быть однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Матрица отслеживания требований — это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Применение матрицы отслеживания требований помогает удостовериться, что каждое требование добавляет бизнес-ценность, связывая требование с целями организации и проекта. 3. Определение содержания Определение содержания — процесс разработки подробного описания проекта и продукта. Ключевая выгода данного процесса состоит в том, что он описывает границы продукта, услуги или результата путем определения того, какие из собранных требований будут включены в содержание проекта и какие исключены из него. Р  исунок – это «Определение содержания» - Входы, инструменты и методы, выходы; Описание содержания проекта — это изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. Вывод: При работе над данным проетом были изучены основы CASE-CALS технологий и перспективы их внедрения в России. В результате проведенной работы,мы изучили цели,задачи,назначение и общие функциональные возможности CASE-технологий,по системному анализу и моделированию безнесс-процессов предметной области. Мы научились на практике проводить системный анализ предметной области автоматизации, находить оптимизированные проектные решения,строить концептуальные модели бизнесс-процессов. Овладели современными методами системного анализа и моделирования предметной области автоматзации с применением современных методов CASE- и CALSтехнологий. Также приобрели навыки работы с методологией IDEF0. Создали модель заданного процесса при помощи Ramus, см. приложение Литература: В.П. Корячко, Процессы и задачи управления проектами информационных систем / В.П. Корячко, А.И. Таганов: Москва, 2013 А.И. Балашов, Управление проектами / А.И. Балашов, Е.М. Рогова, М.В. Тихонова: Юрайт, 2016 И.В. Гонтарева Управление проектами. Учебное пособие / И.В. Гонтарева, Р.М. Нижегородцев, Д.А. Новиков: КД Либроком, 2013 Системная инженерия. Модели и процессы жизненного цикла систем: Учебное пособие. / Сост.: А.И. Таганов, Р.А. Таганов; Под ред. В.П. Корячко. Рязан. гос. радиотехн. акад. Рязань, 2005. Норенков И.П., Кузьмин П.К. Информационная поддержка наукоемких изделий. CALS-технологии. – М.: Изд-во МГТУ им. Н.Э. Баумена, 2002. Руководство РМВОК. Свод знаний по управлению проектами; CASE-технологии функционально-структурного моделирования бизнес-процессов: учебное пособие. – Рязань: И.П. Коняхин А. В. (Book Jet). 2021 Приложение:      |