Name already in use
ramus / dest / doc / ru / Инструкция пользователя.pdf
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- Download
- Delete file
Footer
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
1 Создание моделей бизнес-процессов с использованием программного средства ramus
При запуске «Ramus» появляется окно, в котором предлагается создать новый проект (по умолчанию) или же открыть уже существующий файл проекта. Данное окно не будет выводиться в дальнейшем если поставить галочку «Использовать выбор по умолчанию и больше не спрашивать».
При выборе пункта «Создать новый файл» автоматически запускается мастер создания нового проекта. Этот мастер можно закрыть и заполнить необходимые сведения позже, но рекомендуется выполнить все его этапы.
На первом этапе предлагается внести сведения об авторе, названии проекта и модели. Также следует выбрать тип нотации модели: IDEF0 или DFD.
На втором этапе предлагается внести сведения о том, в какой организации используется данный проект.
На третьем этапе предлагается дать короткое описание проекту.
На четвёртом этапе предлагается создать несколько основных классификаторов проекта. Например: «Информация», «Ресурсы» и т.д.
На пятом, заключительном этапе, предлагается выбрать какие классификаторы, из созданных, будут содержать перечень собственников процессов.
После завершения работы мастера, откроется рабочее пространство «Диаграммы» в котором можно приступить к созданию графической модели.
1.2 Создание модели в стандарте idef0
1.2.1 Принципы построения модели idef0
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом и называвшийся первоначально SADT — Structured Analysis and Design Tech-nique. Позднее вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (IntegratedComputer-AidedManufacturing). В дальнейшем это подмножество SADT бы-ло принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система пре-образует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ; другими словами, первоначально необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции.
После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема «плавающей области»).
Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
Почему этот процесс должен быть замоделирован?
Что должна показывать модель?
Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений», «Идентифицировать роли и ответственность служащих для написания должностных инструкций», «Описать функциональность предприятия с целью написания спецификаций ИС» и т. д.
Точка зрения. Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.
IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.
Модели AS-IS и ТО-ВЕ. Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изме-нения существующей структуры организации бизнеса. Анализ недостатков и «узких мест» начинают с построения модели AS-IS (Как есть), т. е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (должностных инструкций, положений о пред-приятии, приказов, отчетов и т. п.), анкетирования и опроса служащих предприятия (организация опроса должна быть итерационной и реализовать цикл автор-читатель, см. 1.2.6), создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели TO-BE (Как будет) — модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых определяют наилучший вариант.
Следует указать на распространенную ошибку при создании модели AS-IS — это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям, и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную ин-формацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD ВЕ (Как должно бы быть).
Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели TO-BE, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого. Для закрепления материала вспомним фразу: «в результате автоматизации хаоса получается автоматизированный хаос».
Иногда текущая модель AS-IS и будущая ТО-ВЕ различаются очень сильно, так что переход от начального состояния к конечному становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.
Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель, создаваемая в Ramusможет содержать два типа диаграмм:
контекстную (в каждой модели может быть только одна контекстная диаграмма);
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т. д., до достижения нужного уровня подробности описания, После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Рассмотрим основные компоненты нотации IDEF0, используемые при построении моделей.
Как увеличить размер шрифта интерфейса в программе ramus (на java)?
ramus — это редактор idef0-схем ОС Fedora 30, с kde.
Надеюсь, я вас правильно понял: Сервис ⇒ Свойства программы
Прочие шрифты зашиты внутри программы в html файлах и не настраиваются в интерфейсе пользователя. Нужно дорабатывать код программы.
Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.3.11.43304
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Изменение имени автора в документе Microsoft Word
Каждый раз, когда вы создаете новый текстовый документ в MS Word, программа автоматически устанавливает для него ряд свойств, в числе которых и имя автора. Свойство “Автор” создается на основе сведений о пользователе, которые отображаются в окне “Параметры” (ранее “Параметры Word”). Кроме того, доступные сведения о пользователе — это также источник имени и инициалов, которые будут отображаться в исправлениях и комментариях.
Примечание: В новых документах имя, которое отображается в качестве свойства “Автор” (показано в сведениях о документе), берется из раздела “Имя пользователя” (окно “Параметры”).
Изменение свойства “Автор” в новом документе
1. Нажмите кнопку “Файл” (“Microsoft Office” ранее).
2. Откройте раздел “Параметры”.
3. В появившемся окне в категории “Общие” (ранее “Основные”) в разделе “Личная настройка Microsoft Office” задайте необходимое имя пользователя. Если это потребуется, измените инициалы.
4. Нажмите “ОК”, чтобы закрыть диалоговое окно и принять изменения.
Изменение свойства “Автор” в существующем документе
1. Откройте раздел “Файл” (ранее “Microsoft Office”) и нажмите кнопку “Свойства”.
Примечание: Если вы используете устаревшую версию программы, в разделе “MS Office” сначала нужно выбрать пункт “Подготовить”, а затем уже перейти в “Свойства”.
-
Совет: Рекомендуем обновить Word, воспользовавшись нашей инструкцией.
2. Из выпадающего меню выберите “Дополнительные свойства”.
3. В открывшемся окне “Свойства” в поле “Автор” введите необходимое имя автора.
4. Нажмите “ОК” для закрытия окна, имя автора существующего документа будет изменено.
Примечание: Если вы измените раздел свойств “Автор” в существующем документе в области сведений о нем, это не повлияет на сведения о пользователе, которые отображаются в меню “Файл”, разделе “Параметры” и на панели быстрого доступа.
Вот, собственно, и все, теперь вы знаете, как изменить имя автора в новом или уже существующем документе Microsoft Word.