Некоммерческое акционерное общество
АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ
Кафедра «Информационные системы»
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ
Методические указания к выполнению курсовой работы
для студентов специальности 5В070300 – «Информационные системы»
Алматы 2013
Составитель: Нурлыбаев Н.А. Информационно-управляющие системы. Методические указания к выполнению курсовой работы для студентов специальности 5В070300 – «Информационные системы» – Алматы: АУЭС, 2013. – 48 с.
Методические указания содержат указания к выполнению курсовой работы по дисциплине «Информационно-управляющие системы»
Методические указания предназначены для студентов специальности 5В070300 – «Информационные системы»
Рецензент:доцент Куликов А.А.
Печатается по плану издания НАО «Алматинский университет энергетики и связи» на 2012 г.
© НАО «Алматинский университет энергетики и связи», 2013 г.
Сводный план 2012 г. поз.204
Введение
Технология создания информационных систем (далее — ИС) предъявляет особые требования к методикам реализации и программным инструментальным средствам, а именно:
- Реализацию проектов по созданию ИС принято разбивать на стадии анализа (прежде чем создавать ИС, необходимо понять и описать бизнес-логику предметной области), проектирования (необходимо определить модули и архитектуру будущей системы), непосредственного кодирования, тестирования и сопровождения. Известно, что исправление ошибок, допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем на текущей, откуда следует, что наиболее критическими являются первые стадии проекта. Поэтому крайне важно иметь эффективные средства автоматизации ранних этапов реализации проекта.
- Проект по созданию сложной ИС невозможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков.
- Жизненный цикл создания сложной ИС сопоставим с ожидаемым временем ее эксплуатации. Другими словами, в современных условиях компании перестраивают свои бизнес-процессы примерно раз в два года, столько же требуется (если работать в традиционной технологии) для создания ИС. Может оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания ИС жизненно необходим инструмент, значительно (в несколько раз) уменьшающий время разработки ИС.
- Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно внесение изменений в проект на поздних этапах создания ИС — весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям.
На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям.
В настоящем пособии рассматривается САSЕ-средство верхнего уровня Ramus, поддерживающее методологии IDEF0 (функциональная модель) и DFD (Data Flow Diagram), которое предназначено для проведения анализа и реорганизации бизнес-процессов. Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей — того, к чему нужно стремиться (модель ТО-ВЕ). Методология IDEF0 предписывает построение иерархической системы диаграмм — единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция — система разбивается на подсистемы, и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, Ramus позволяет переключиться на любой ветви модели на нотацию DFD и создать смешанную модель. Нотация DFD включает такие понятия, как "внешняя сущность" и "хранилище данных", что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.
На основе модели Ramus можно построить модель данных. Для построения модели данных можно использовать такие инструменты, как DBDesigner Fork или WWW SQL Designer.
DBDesigner Fork поддерживает несколько уровней представления модели, в том числе, логический, что позволяет наглядно представить модель данных даже для неспециалистов. DBDesigner Fork позволяет проводить процессы прямого и обратного проектирования баз данных .Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога.
Варианты заданий выбираются в соответствии с рекомендацией преподавателя или по схеме:
а) Две последние цифры номера зачетной книжки Nзк определяют номер варианта, если 1 < Nзк<24, если же 25< Nзк<99, то номер варианта определяется, как остаток от деления на Nзк на 25.
Варианты заданий: проектирования информационных систем.
1 Страховая компания.
Описание предметной области.
Заказчиком является страховая компания. Задачей является отслеживание финансовой деятельности компании.
Компания имеет различные филиалы по всей стране. Каждый филиал характеризуется названием, адресом и телефоном. Деятельность компании организована следующим образом: к заказчику обращаются различные лица с целью заключения договора о страховании. В зависимости от принимаемых на страхование объектов и страхуемых рисков, договор заключается по определенному виду страхования (например, страхование автотранспорта от угона, страхование домашнего имущества, добровольное медицинское страхование). При заключении договора Вы фиксируете дату заключения, страховую сумму, вид страхования, тарифную ставку и филиал, в котором заключался договор.
Нужно учесть, что договоры заключают страховые агенты. Помимо информации об агентах (фамилия, имя, отчество, адрес, телефон), нужно еще хранить информацию о филиале, в котором работают агенты. Кроме того, нужно иметь возможность рассчитывать заработную плату агентам. Заработная плата составляет некоторый процент от страхового платежа (страховой платеж - это страховая сумма, умноженная на тарифную ставку). Процент зависит от вида страхования, по которому заключен договор.
2. Гостиница.
Описание предметной области.
Заказчиком является гостиница. Задачей является отслеживание финансовой стороны работы гостиницы.
Деятельность заказчика организована следующим образом: гостиница предоставляет номера клиентам на определенный срок. Каждый номер характеризуется вместимостью, комфортностью (люкс, полулюкс, обычный) и ценой. Клиентами заказчика являются различные лица, о которых собирается определенная информация (фамилия, имя, отчество и некоторый комментарий). Сдача номера клиенту производится при наличии свободных мест в номерах, подходящих клиенту по указанным выше параметрам. При поселении фиксируется дата поселения. При выезде из гостиницы для каждого места запоминается дата освобождения.
Необходимо хранить информацию не только по факту сдачи номера клиенту, но и осуществлять бронирование номеров. Кроме того, для постоянных клиентов, а также для определенных категорий клиентов, предусмотрена система скидок. Скидки могут суммироваться.
3 Ломбард.
Описание предметной области.
Заказчиком является ломбард. Задачей является отслеживание финансовой стороны работы ломбарда.
Деятельность компании организована следующим образом: к заказчику обращаются различные лица с целью получения денежных средств под залог определенных товаров. У каждого из приходящих клиентов запрашивается фамилия, имя, отчество и другие паспортные данные. После оценивания стоимости принесенного в качестве залога товара определяется сумму, которую готовы выдать на руки клиенту, а также комиссионные. Кроме того, определяете срок возврата денег. Если клиент согласен, то договоренности фиксируются в виде документа, деньги выдаются клиенту, а товар остается в ломбарде. В случае, если в указанный срок не происходит возврата денег, товар переходит собственность ломбарда.
После перехода прав собственности на товар, ломбард может продавать товары по цене, меньшей или большей, чем была заявлена при сдаче. Цена может меняться несколько раз, в зависимости от ситуации на рынке (например, владелец ломбарда может устроить распродажу зимних вещей в конце зимы). Помимо текущей цены, нужно хранить все возможные значения цены для данного товара.
4 Реализация готовой продукции.
Описание предметной области.
Заказчиком является компания, занимающаяся оптово-розничной продажей различных товаров. Задачей является отслеживание финансовой стороны работы компании.
Деятельность компании организована следующим образом: компания торгует товарами из определенного спектра. Каждый из этих товаров характеризуется наименованием, оптовой ценой, розничной ценой и справочной информацией. В компанию обращаются покупатели. Для каждого из них в базе данных должны храниться стандартные данные (наименование, адрес, телефон, контактное лицо). По каждой сделке составляется документ по количеству купленного покупателем товара и датой покупки.
Обычно покупатели в рамках одной сделки покупают не один товар, а сразу несколько. Также компания решила предоставлять скидки в зависимости от количества закупленных товаров и их общей стоимости.
5 Ведение заказов.
Описание предметной области.
Заказчиком является компания, занимающаяся оптовой продажей различных товаров. Задачей является отслеживание финансовой стороны работы компании.
Деятельность компании организована следующим образом: компания торгует товарами из определенного спектра. Каждый из этих товаров характеризуется ценой, справочной информацией и признаком наличия или отсутствия доставки. В компанию обращаются заказчики. Для каждого из них в базе данных должны храниться стандартные данные (наименование, адрес, телефон, контактное лицо). По каждой сделке составляется документ с количества купленного покупателем товара и датой покупки.
Доставка разных товаров может производиться разными способами, различными по цене и скорости. Нужно хранить информацию о том, какими способами может осуществляться доставка каждого товара, и информацию о том, какой вид доставки (а, соответственно, и какую стоимость доставки) выбрал клиент при заключении сделки.
6 Бюро по трудоустройству.
Описание предметной области.
Заказчиком является бюро по трудоустройству. Задачей является отслеживание финансовой стороны работы компании.
Деятельность бюро организовано следующим образом: бюро готово искать работников для различных работодателей и вакансии для ищущих работу специалистов различного профиля. При обращении в бюро клиента-работодателя, его стандартные данные (название, вид деятельности, адрес, телефон) фиксируются в базе данных. При обращении в бюро клиента-соискателя, его стандартные данные (фамилия, имя, отчество, квалификация, профессия, иные данные) также фиксируются в базе данных. По каждому факту удовлетворения интересов обеих сторон составляется документ. В документе указываются соискатель, работодатель, должность и комиссионные (доход бюро).
Также необходимо хранить информацию по открытым вакансиям. Кроме того, для автоматического поиска вариантов, необходимо вести справочник «виды деятельности».
7 Нотариальная контора.
Описание предметной области.
Заказчиком является нотариальная контора. Задачей является отслеживание финансовой стороны работы компании.
Деятельность нотариальной конторы организована следующим образом: фирма готова предоставить клиенту определенный комплекс услуг. Для наведения порядка эти услуги формализовали, составив их список с описанием каждой услуги. При обращении к клиенту, его стандартные данные (название, вид деятельности, адрес, телефон) фиксируются в базе данных. По каждому факту оказания услуги клиенту составляется документ. В документе указываются услуга, сумма сделки, комиссионные (доход конторы), описание сделки.
В рамках одной сделки клиенту может быть оказано несколько услуг. Стоимость каждой услуги фиксирована. Кроме того, компания предоставляет в рамках одной сделки различные виды скидок. Скидки могут суммироваться.
8 Фирма по продаже запчастей.
Описание предметной области.
Заказчиком является фирма, занимающаяся продажей запасных частей для автомобилей. Задачей является отслеживание финансовой стороны работы компании.
Основная часть деятельности, связана с работой с поставщиками. Фирма имеет определенный набор поставщиков, по каждому из которых известны название, адрес и телефон. У этих поставщиков фирма приобретает детали. Каждая деталь наряду с названием характеризуется артикулом и ценой (считаем цену постоянной). Некоторые из поставщиков могут поставлять одинаковые детали (один и тот же артикул). Каждый факт покупки запчастей у поставщика фиксируется, причем обязательными для запоминания являются дата покупки и количество приобретенных деталей.
Выяснилось, что цена детали может меняться от поставки к поставке. Поставщики заранее ставят фирму в известность о дате изменения цены и о его новом значении. Нужно хранить не только текущее значение цены, но и всю историю изменения цен.
9 Распределение дополнительных обязанностей.
Описание предметной области.
Заказчиком является коммерческая компания. Задачей является отслеживание хода выполнения дополнительных работ.
Компания имеет определенный штат сотрудников, каждый из которых получает определенный оклад. Время от времени, возникает потребность в выполнении некоторой дополнительной работы, не входящей в круг основных должностных обязанностей сотрудников. Для наведения порядка в этой сфере деятельности все виды дополнительных работ проклассифицированы, кроме того, определена сумма оплаты по факту их выполнения. При возникновении дополнительной работы определенного вида назначается ответственный сотрудник и фиксируется дата начала работ. По факту окончания фиксируется соответствующая дата и выплачивается дополнительная сумма к зарплате с учетом составленной классификации. Некоторые из дополнительных работ являются достаточно трудоемкими и, в то же время, срочными, что требует привлечения к их выполнению нескольких сотрудников. Также оказалось, что длительность работ в каждом конкретном случае составляет разную величину. Соответственно, нужно заранее планировать длительность работы и количество сотрудников, занятых для выполнения работы.
10 Техническое обслуживание станков.
Описание предметной области.
Заказчиком является предприятие, занимающееся ремонтом станков и другого промышленного оборудования. Задачей является отслеживание финансовой стороны деятельности предприятия.
Клиентами компании являются промышленные предприятия, оснащенные различным сложным оборудованием. В случае поломок оборудования они обращаются в фирму.
Ремонтные работы в компании организованы следующим образом: все станки проклассифицированы по странам-производителям, годам выпуска и маркам. Все виды ремонта отличаются названием, продолжительностью в днях, стоимостью. Исходя из этих данных, по каждому факту ремонта фиксируется вид станка и дату начала ремонта.
Нужно не просто подразделять станки по типам, а иметь информацию о том, сколько раз ремонтировался тот или иной конкретный станок.
11 Туристическая фирма.
Описание предметной области.
Заказчиком является туристическая компания, которая работает с клиентами, продавая им путевки. Задачей является отслеживание финансовой стороны деятельности фирмы.
Работа с клиентами в компании организована следующим образом: у каждого клиента, пришедшего в турфирму, собираются некоторые стандартные данные – фамилия, имя, отчество, адрес, телефон. После этого сотрудники выясняют у клиента, куда он хотел бы поехать отдыхать. При этом ему демонстрируются различные варианты, включающие страну проживания, особенности местного климата, имеющиеся отели разного класса. Наряду с этим, обсуждается возможная длительность пребывания и стоимость путевки. В случае, если удалось договориться, и найти для клиента приемлемый вариант, регистрируется факт продажи путевки (или путевок, если клиент покупает сразу несколько путевок) и фиксируется дата отправления. Иногда принимается решение о предоставлении клиенту некоторой скидки.
Фирма работает с несколькими отелями в нескольких странах. Путевки продаются на одну, две или четыре недели. Стоимость путевки зависит от длительности тура и отеля. Скидки, которые предоставляет фирма, фиксированы. Например, при покупке более 1 путевки, предоставляется скидка 5%. Скидки могут суммироваться.
12 Грузовые перевозки.
Описание предметной области.
Заказчиком является компания, занимающаяся перевозками грузов. Задачей является отслеживание стоимости перевозок с учетом заработной платы водителей.
Компания осуществляет перевозки по различным маршрутам. Для каждого маршрута определено некоторое название, вычислено примерное расстояние и установлена некоторая оплата для водителя. Информация о водителях включает фамилию, имя, отчество и стаж. Для проведения расчетов нужно хранить полную информацию о перевозках (маршрут, водитель, даты отправки и прибытия). По факту перевозок водителям выплачивается премия.
Фирма решила ввести гибкую систему оплаты. Так, оплата водителям должна теперь зависеть не только от маршрута, но и от стажа водителя. Кроме того, нужно учесть, что перевозку могут осуществлять два водителя.
13 Учет телефонных переговоров.
Описание предметной области.
Заказчиком является коммерческая служба телефонной компании. Компания предоставляет абонентам телефонные линии для междугородних переговоров. Задачей является отслеживание стоимости междугородних телефонных переговоров.
Абонентами компании являются юридические лица, имеющие телефонную точку, ИНН, расчетный счет в банке. Стоимость переговоров зависит от города, в который осуществляется звонок, и времени суток (день, ночь). Каждый звонок абонента автоматически фиксируется в базе данных. При этом запоминаются город, дата, длительность разговора и время суток.
Фирма решила ввести гибкую систему скидок. Так, стоимость минуты теперь уменьшается в зависимости от длительности разговора. Размер скидки для каждого города разный.
14 Учет внутриофисных расходов.
Описание предметной области.
Заказчиком является бухгалтерия частной фирмы. Сотрудники фирмы имеют возможность осуществлять мелкие покупки для нужд фирмы, предоставляя в бухгалтерию товарный чек. Задачей является отслеживание внутриофисных расходов.
Фирма состоит из отделов. Каждый отдел имеет название. В каждом отделе работает определенное количество сотрудников. Сотрудники могут осуществлять покупки в соответствии с видами расходов. Каждый вид расходов имеет название, некоторое описание и предельную сумму средств, которые могут быть потрачены по данному виду расходов в месяц. При каждой покупке сотрудник оформляет документ, где указывает вид расхода, дату, сумму и отдел.
Нужно хранить данные о расходах не только в целом по отделу, но и по отдельным сотрудникам. Нормативы по расходованию средств устанавливаются не в целом, а по каждому отделу за каждый месяц. Неиспользованные в текущем месяце деньги могут быть использованы позже.
15 Библиотека.
Описание предметной области.
Заказчиком является библиотека. Библиотека решила зарабатывать деньги, выдавая напрокат некоторые книги, имеющиеся в небольшом количестве экземпляров. Задачей является отслеживание финансовых показателей работы библиотеки.
У каждой книги, выдаваемой в прокат, есть название, автор, жанр. В зависимости от ценности книги для каждой из них определена залоговая стоимость (сумма, вносимая клиентом при взятии книги напрокат) и стоимость проката (сумма, которую клиент платит при возврате книги, получая назад залог). В библиотеку обращаются читатели. Все читатели регистрируются в картотеке, которая содержит стандартные анкетные данные (фамилия, имя, отчество, адрес, телефон). Каждый читатель может обращаться в библиотеку несколько раз. Все обращения читателей фиксируются, при этом по каждому факту выдачи книги запоминаются дата выдачи и ожидаемая дата возврата.
Стоимость проката книги должна зависеть не только от самой книги, но и от срока ее проката. Кроме того, необходимо добавить систему штрафов за вред, нанесенный книге, и систему скидок для некоторых категорий читателей.
16 Прокат автомобилей.
Описание предметной области.
Заказчиком является коммерческая служба в фирме, занимающейся прокатом автомобилей. Задачей является отслеживание финансовых показателей работы пункта проката.
В автопарк входит некоторое количество автомобилей различных марок, стоимостей и типов. Каждый автомобиль имеет свою стоимость проката. В пункт проката обращаются клиенты. Все клиенты проходят обязательную регистрацию, при которой о них собирается стандартная информация (фамилия, имя, отчество, адрес, телефон). Каждый клиент может обращаться в пункт проката несколько раз. Все обращения клиентов фиксируются, при этом по каждой сделке запоминаются дата выдачи и ожидаемая дата возврата.
Стоимость проката автомобиля должна зависеть не только от самого автомобиля, но и от срока его проката, а также от года выпуска. Также нужно ввести систему штрафов за возвращение автомобиля в ненадлежащем виде и систему скидок для постоянных клиентов.
17 Выдача банком кредитов.
Описание предметной области.
Заказчиком является информационно-аналитический центр коммерческого банка. Одним из существенных видов деятельности банка является выдача кредитов юридическим лицам. Задачей является отслеживание динамики работы кредитного отдела.
В зависимости от условий получения кредита, процентной ставки и срока возврата все кредитные операции делятся на несколько основных видов. Каждый из этих видов имеет свое название. Кредит может получить юридическое лицо (клиент), при регистрации предоставивший следующие сведения: название, вид собственности, адрес, телефон, контактное лицо. Каждый факт выдачи кредита регистрируется банком, при этом фиксируются сумма кредита, клиент и дата выдачи.
Необходимо учитывать в системе еще и дату фактического возврата денег. Нужно еще учесть, что кредит может гаситься частями, и за задержку возврата кредита начисляются штрафы.
18 Платная поликлиника.
Описание предметной области.
Заказчиком является служба планирования платной поликлиники. Задачей является отслеживание финансовых показателей работы поликлиники.
В поликлинике работают врачи различных специальностей, имеющие разную квалификацию. Каждый день в поликлинику обращаются больные. Все больные проходят обязательную регистрацию, при которой в базу данных заносятся стандартные анкетные данные (фамилия, имя, отчество, год рождения). Каждый больной может обращаться в поликлинику несколько раз, нуждаясь в различной медицинской помощи. Все обращения больных фиксируются, при этом устанавливается диагноз, определяется стоимость лечения, запоминается дата обращения.
При обращении в поликлинику пациент обследуется и проходит лечение у разных специалистов. Общая стоимость лечения зависит от стоимости тех консультаций и процедур, которые назначены пациенту. Кроме того, для определенных категорий граждан предусмотрены скидки.
19 Учет телекомпанией стоимости прошедшей в эфире рекламы.
Описание предметной области.
Заказчиком является коммерческая служба телевизионной компании. Задачей является отслеживание расчетов, связанных с прохождением рекламы в телеэфире.
Работа построена следующим образом: заказчики просят поместить свою рекламу в определенной передаче в определенный день. Каждый рекламный ролик имеет определенную продолжительность. Для каждой организации-заказчика известны банковские реквизиты, телефон и контактное лицо для проведения переговоров. Передачи имеют определенный рейтинг. Стоимость минуты рекламы в каждой конкретной передаче известна (определяется коммерческой службой, исходя из рейтинга передачи и прочих соображений).
Необходимо также хранить информацию об агентах, заключивших договоры на рекламу. Зарплата рекламных агентов составляет некоторый процент от общей стоимости рекламы, прошедшей в эфире.
20 Интернет-магазин.
Описание предметной области.
Заказчиком является коммерческий отдел компании, продающей различные товары через Интернет. Задачей является отслеживание финансовой составляющей работы компании.
Работа компании организована следующим образом: на Интернет-сайте компании представлены (выставлены на продажу) некоторые товары. Каждый из них имеет некоторое название, цену и единицу измерения (штуки, килограммы, литры). Для проведения исследований и оптимизации работы магазина необходимо собирать данные о клиентах. При этом определяющее значение имеют стандартные анкетные данные, а также телефон и адрес электронной почты для связи. В случае приобретения товаров на сумму свыше 5000р. клиент переходит в категорию «постоянных клиентов» и получает скидку на каждую покупку в размере 2%. По каждому факту продажи автоматически фиксируется клиент, товары, количество, дата продажи, дата доставки.
Иногда возникают проблемы, связанные с нехваткой информации о наличии нужных товаров на складе в нужном количестве. Кроме того, обычно клиенты в рамках одного заказа покупают не один вид товара, а несколько видов. Исходя из суммарной стоимости заказа, компания предоставляет дополнительные скидки.
21 Ювелирная мастерская.
Описание предметной области.
Заказчиком является ювелирная мастерская. Мастерская осуществляет изготовление ювелирных изделий для частных лиц на заказ. Работа ведется с определенными материалами (платина, золото, серебро, различные драгоценные камни и т.д.). При обращении в мастерскую потенциального клиента необходимо определить какое именно изделие ему необходимо. Все изготавливаемые изделия принадлежат к некоторому типу (серьги, кольца, броши, браслеты), бывают выполнены из определенного материала, имеют некоторый вес и цену (включающую стоимость материалов и работы).
Ювелирное изделие может состоять из нескольких материалов. Кроме того, постоянным клиентам мастерская предоставляет скидки.
22 Парикмахерская.
Описание предметной области.
Заказчиком является парикмахерская.
Парикмахерская стрижет клиентов в соответствии с их пожеланиями и некоторым каталогом различных видов стрижки. Так, для каждой стрижки определены название, принадлежность полу (мужская, женская), стоимость работы. Для наведения порядка необходимо составить базу данных клиентов, запоминая их анкетные данные (фамилия, имя, отчество). Начиная с 5-ой стрижки, клиент переходит в категорию постоянных и получает скидку в 3% при каждой последующей стрижке. После того, как закончена очередная работа, в кассе фиксируются стрижка, клиент и дата производства работ.
У парикмахерской появился филиал, и необходимо видеть, в том числе, и раздельную статистику по филиалам. Кроме того, стоимость стрижки может меняться с течением времени. Нужно хранить не только последнюю цену, но и все данные по изменению цены стрижки.
23 Химчистка.
Описание предметной области.
Заказчиком является химчистка.
Химчистка осуществляет прием у населения вещей для выведения пятен. Для наведения порядка необходимо составить базу данных клиентов, запоминая их анкетные данные (фамилия, имя, отчество). Начиная с 3-го обращения, клиент переходит в категорию постоянных клиентов и получает скидку в 3% при чистке каждой последующей вещи. Все оказываемые услуги подразделяются на виды, имеющие название, тип и стоимость, зависящую от сложности работ. Работа с клиентом первоначально состоит в определении объема работ, вида услуги и, соответственно, ее стоимости. Если клиент согласен, он оставляет вещь (при этом фиксируется услуга, клиент и дата приема) и забирает ее после обработки (при этом фиксируется дата возврата).
У химчистки появился филиал, и необходимо видеть, в том числе, и раздельную статистику по филиалам. Кроме того, принято решение делать надбавки за срочность и сложность работ.
24 Сдача в аренду торговых площадей.
Описание предметной области.
Заказчиком является крупный торговый центр, сдающий в аренду коммерсантам свои торговые площади. Задачей является наведение порядка в финансовой стороне работы торгового центра.
Работа торгового центра построена следующим образом: в результате планирования определено некоторое количество торговых точек в пределах офисного здания, которые могут сдаваться в аренду. Для каждой из торговых точек важными данными являются этаж, площадь, наличие кондиционера и стоимость аренды в день. Со всех потенциальных клиентов собираются стандартные данные (название, адрес, телефон, реквизиты, контактное лицо). При появлении потенциального клиента ему показываются имеющиеся свободные площади. При достижении соглашения оформляется договор, в базе данных фиксируется торговая точка, клиент, период (срок) аренды.
Некоторые клиенты арендуют сразу несколько торговых точек. Помимо этого, необходимо собирать информацию об ежемесячных платежах, поступающих от арендаторов.
1 Создание моделей бизнес-процессов с использованием программного средства RAMUS
Теоретическая часть
1.1 Начало работы
При запуске «Ramus» появляется окно, в котором предлагается создать новый проект (по умолчанию), или же открыть уже существующий файл проекта. Данное окно не будет выводиться в дальнейшем, если поставить галочку «Использовать выбор, по умолчанию, и больше не спрашивать».
При выборе пункта «Создать новый файл» автоматически запускается мастер создания нового проекта. Этот мастер можно закрыть и заполнить необходимые сведения позже, но рекомендуется выполнить все его этапы.
На первом этапе предлагается внести сведения об авторе, названии проекта и модели. Также следует выбрать тип нотации модели: IDEF0 или DFD.
На втором этапе предлагается внести сведения о том, в какой организации используется данный проект.
На третьем этапе предлагается дать короткое описание проекту.
На четвёртом этапе предлагается создать несколько основных классификаторов проекта. Например: «Информация», «Ресурсы» и т.д.
На пятом, заключительном этапе, предлагается выбрать, какие классификаторы, из созданных, будут содержать перечень собственников процессов.
После завершения работы мастера, откроется рабочее пространство «Диаграммы», в котором можно приступить к созданию графической модели.
1.2 Создание модели в стандарте IDEF0
1.2.1 Принципы построения модели IDEF0.
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом и называвшийся первоначально SADT — Structured Analysis and Design Tech-nique. Позднее вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT бы-ло принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ; другими словами, первоначально необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции.
После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").
Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
1) Почему этот процесс должен быть замоделирован?
2) Что должна показывать модель?
3) Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: "Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций ИС" и т. д.
Точка зрения. Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.
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 может содержать два типа диаграмм:
1) контекстную (в каждой модели может быть только одна контекстная диаграмма);
2) декомпозиции.
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т. д., до достижения нужного уровня подробности описания, После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес -процессам на любом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Рассмотрим основные компоненты нотации IDEF0, используемые при построении моделей.
1.2.2 Функциональный блок.
Функциональные блоки обозначают
поименованные процессы, функции или задачи, которые происходят в течение
определенного времени и имеют распознаваемые результаты. Функциональные блоки
изображаются в виде прямоугольников. Все функциональные блоки должны быть
названы и определены. Имя функционального блока должно быть выражено сочетанием
отглагольного существительного, обозначающего процесс, например: «Работа с
клиентом», «Прием заказа» и т. д. Функциональный блок «Работа с
клиентом» может иметь, например, следующее определение: «Работа
относится к полному циклу обслуживания клиента от приема звонка до оформления
документов по заказу». При создании новой модели автоматически создается
контекстная диаграмма на которой можно разместить единственный функциональный
блок, изображающий систему в целом (см. рисунок 1.1), щелкнув сначала по кнопке
на палитре инструментов,
а затем по свободному месту на диаграмме.
Рисунок 1.1 - Пример контекстной диаграммы
Для внесения имени функционального блока следует сделать по нему двойной щелчок, выбрать в редакторе свойств вкладку «Название» и внести имя блока (см.рисунок 1.2).
Диаграммы декомпозиции содержат
родственные работы, т. е. дочерние работы, имеющие общую родительскую работу.
Для создания диаграммы декомпозиции следует щелкнуть по кнопке 
(перейти к дочерним диаграммам).
Возникает диалог «Создание новой диаграммы» (см.рисунок 1.3), в котором следует
указать нотацию новой диаграммы и функциональных блоков на ней. Остановимся
пока на нотации IDEF0 и щелкнем на ОК.
Появляется диаграмма декомпозиции (см.рисунок 1.4). Допустимый интервал числа работ 2 - 8.
Рисунок 1.2 - Редактор свойств функционального блока
Рисунок 1.3 - Диалог «Создание новой диаграммы»
Рисунок 1.4 - Пример диаграммы декомпозиции
Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме.
Если оказывается, что количество функциональных
блоков недостаточно, то функциональный блок можно добавить в диаграмму, щелкнув
сначала по кнопке на
палитре инструментов, а затем по свободному месту на диаграмме.
Функциональные блоки на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу расположения, в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ.
Каждая из работ на диаграмме декомпозиции может быть, в свою очередь, декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рисунке 1.4 работа «Обработка звонка» имеет номер 1 и не была еще декомпозирована. Работа «Обработка заказа» (номер 4) имеет нижний уровень декомпозиции.
1.2.3 Стрелка.
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок.
Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок/стрелки, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока, - входы. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелки, входящие в блок сверху, - управления. Управления определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелки, покидающие блок справа, – выходы, т.е. данные или материальные объекты, произведенные функцией.
Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Стрелки, направленные вверх, идентифицируют средства, поддерживающие выполнение функции. Другие средства могут наследоваться из родительского блока. Стрелки механизма, направленные вниз, являются стрелками вызова. Стрелки вызова обозначают обращение из данной модели или из данной части модели к блоку, входящему в состав другой модели или другой части модели, обеспечивая их связь, т.е. разные модели или разные части одной и той же модели могут совместно использовать один и тот же элемент (блок).
Стандартное расположение стрелок показано на рисунке1.5.
Рисунок 1.5 - Стандартное расположение стрелок
Стрелки представляют собой некую информацию, обозначаются существительными (например, «Устав», «Сотрудники», «Заказ») или именными сочетаниями (например, «Готовое изделие»).
Рассмотрим четыре типа стрелок, которые используются в Ramus.
Вход — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, «Сырье» — это нечто, что перерабатывается в процессе «Изготовление изделия» для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при «Приеме пациента» карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — «Заполненная карта пациента»). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет — управление.
Управление — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рисунке 1. 4 стрелки «Правила бух учета» — управление для работы «Оформление документов по заказу». Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.
Выход — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рисунке 1.4 стрелка «Информация о заказе» является выходом для работы «Обработка заказа».
Механизм — ресурсы, которые выполняют работу, например, персонал предприятия, программное обеспечение, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рисунке 1.4 стрелка «Менеджер» является механизмом для работы «Обработка заказа». По усмотрение аналитика, стрелки механизма могут не изображаться в модели.
Для рисования стрелки входа, например, следует щелкнуть по кнопке с символом стрелки на палитре инструментов перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска, и щелкнуть один раз по штриховой полоске, затем щелкнуть в левой части работы со стороны входа. Стрелки управления, выхода и механизма изображаются аналогично.
Туннелирование стрелок. Туннель - круглые скобки в начале и/или окончании стрелки. Туннельные стрелки означают, что данные, выраженные этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме.
Стрелка, помещенная в туннель там, где она присоединяется к блоку (см.рисунок 1.6), означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции.
Стрелка, помещаемая в туннель на свободном конце (см.рисунок 1.7) означает, что выраженные ею данные отсутствуют на родительской диаграмме.
Рисунок 1.6 - Туннелирование «не в дочерней работе»
Рисунок 1.7 - Туннелирование «не в родительской диаграмме»
Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется «не в родительской диаграмме».
Другим примером туннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеет собственного имени.) В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть затуннелирована, а в комментарии к стрелке можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое туннелирование называется «не в дочерней работе».
В программном комплексе Ramus вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня.
Пункт «Туннель» позволяет использовать на диаграммах туннелирование стрелок. Пункт доступен только при вызове контекстного меню стрелки на отрезке, обрамлённом скобками. При выборе данного пункта откроется небольшое диалоговое окно с возможными вариантами действий (см.рисунок 1.8).
Рисунок 1.8 - Туннелирование стрелки в Ramus
В окне представлены два основных действия:
1) «Создать стрелку», позволяет отменить туннелирование и создать отрезок стрелки на родительской диаграмме или внутри функционального блока (зависит от расположения туннеля);
2) «Обозначить стрелку круглыми скобками», позволяет, собственно, туннелировать стрелку.
В случае если туннелируются стрелки на входе в функциональный блок (стрелки управления, входов, механизмы), то доступен и третий вариант:
1) «Обозначить стрелку круглыми скобками (показывать в отчётах для дочерних элементов)». Выбор данного варианта обозначает, что данная стрелка будет считаться стрелкой управления, входа или механизма соответственно, для всех дочерних функциональных блоков данного функционального блока, хотя на диаграммах этого и не будет показано (см.рисунок 1.9).
Рисунок 1.9 - Туннелирование стрелки в Ramus на входе в функциональный блок
Данную функциональность следует использовать только в крайних случаях, с целью повышения читабельности диаграмм, если на диаграммах присутствует множество объектов затрудняющих их восприятие.
Граничные стрелки. Следует также отметить, что программное обеспечение Ramus позволяет создавать сквозные стрелки (потоки) вне основной иерархии.
Для этого нужно открыть две диаграммы, каждую в своей вкладке, которые не являются дочерними друг к другу. После того как будет открыто две диаграммы, можно кликнуть на начале или на конце стрелки, и выбрав вкладку с другой диаграммой, присоединить стрелку к нужному функциональному блоку. В результате стрелка будет автоматически затуннелирована должным образом на обеих диаграммах, а возле значка туннеля на каждой диаграмме будет указан код другой диаграммы, на которой представлена начинается/заканчивается стрелка. Для обозначения такого типа туннелей используется специальный значок в виде круга, а не в виде скобок, как у обычного туннеля.
Несвязанные граничные стрелки. При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в Ramus как синтаксическая ошибка.
На рисунке 1.10 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся Ramus при декомпозиции работы «Обработка заказа» (см. рисунок 1.4).
Рисунок 1.10 - Пример несвязанных стрелок
Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования курсора, щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим курсора, щелкнуть по сегменту выхода работы и затем по стрелке.
Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, т. е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой.
В IDEF0 различают пять типов связей работ.
Связь по входу, когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей (например, на рисунке 1.11 стрелка «Информация о заказе» связывает работы «Обработка заказа» и «Оформление документов по заказу»).
Рисунок 1.11 - Связь по входу
Связь по управлению, когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рисунке 1.12 стрелка «Учебный план» связывает работы «Разработка учебного плана» и «Проведение занятий», при этом учебный план не претерпевает изменений в процессе проведения занятий.
Рисунок 1.12 - Связь по управлению
Обратная связь по входу, когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рисунке 1.13 стрелка «Заказ на доукомплектование» связывает работы «Комплектование заказа» и «Проверка заказа», при этом выявленный недоукомплектованный заказ направляется на повторное комплектование.
Рисунок 1.13 - Обратная связь по входу
Обратная связь по управлению, когда выход нижестоящей работы направляется на управление вышестоящей (стрелка «Рекомендации», рисунок 1.14). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса.
Рисунок 1.14 - Обратная связь по управлению
Связь выход-механизм, когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (см.рисунок 1.15).
Рисунок 1.15 - Связь выход-механизм
Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.
Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис.
Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (см.рисунок 1.16).
Рисунок 1.16 - Пример именования разветвляющейся стрелки
Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей.
Правила именования сливающихся стрелок полностью аналогичны - ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после этого вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.
1.2.4 Нумерация работ и диаграмм.
Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера А1, А2, А3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядко-вый номер, например работы декомпозиции А3 будут иметь номера А31, А32, А33, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам.
Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, Al, А2, А21, А213 и т.д.). Ramus автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. Ramus позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии. В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер — С-number, который должен присваиваться автором модели вручную. С-number — это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например, AVI00021.
1.2.5 Рекомендации по рисованию диаграмм.
В реальных диаграммах к каждой работе может подходить и от каждой может отходить около 10 стрелок. Если диаграмма содержит 6 — 8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пересекаться. Такие диаграммы могут стать очень плохо читаемыми.
В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил Ramus поддерживает автоматически, выполнение других следует обеспечить вручную.
1) Прямоугольники работ должны располагаться по диагонали с левого верхнего в правый нижний угол (порядок доминирования). При создании новой диаграммы декомпозиции Ramus автоматически располагает работы именно в таком порядке. В дальнейшем можно добавить новые работы или изменить расположение существующих, но нарушать диагональное расположение работ по возможности не следует. Порядок доминирования подчеркивает взаимосвязь работ, позволяет минимизировать изгибы и пересечения стрелок.
2) Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы.
3) Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.
4) Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и назвать единым термином.
5) Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению — «верхней» (см. рисунки 1.13, 1.14). Ramus автоматически рисует обратные связи нужным образом.
6) Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная и, в случае насыщенных диаграмм, творческая работа.
7) Если нужно изобразить связь по входу, необходимо избегать нависания работ друг над другом. В этом случае Ramus изображает связи по входу в виде петли, что затрудняет чтение диаграмм.
1.2.6 Проведение экспертизы.
Цикл автор-читатель. Этот цикл предназначен для обеспечения обратной связи при построении модели. Он включает определенные формализованные процедуры, предписывающие правила координации деятельности участников создания модели. В работе над моделью принимают участие специалисты разных профилей — аналитики (авторы), эксперты предметной области (читатели), библиотекари и комитет технического контроля. Обычно библиотекарь выделяется для больших проектов. Цикл «автор-читатель» содержит следующие этапы.
На очередном этапе декомпозиции аналитик создает диаграмму на основе общих знаний, анализа документации и опроса экспертов. Общие знания не позволяют создать диаграмму достаточно корректно, поэтому она нуждается в уточнении и дополнении.
Все коммуникации при создании модели контролируются библиотекарем. Он ответственен за прохождение папок и архивирование диаграмм модели. После создания диаграмма посылается библиотекарю для помещения в архив.
Автором формируется папка и передается для распространения библиотекарю (одна копия направляется автору). В папку должна входить текущая диаграмма. Кроме того, в папку могут включаться сопутствующие отчеты, в том числе словарь стрелок и работ, диаграмма верхнего уровня, дерево узлов и любая необходимая дополнительная документация. На папке регистрируются входящие данные — дата, автор, данные читателя и т. д., после чего папка направляется эксперту предметной области (читателю).
Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся в диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы, в разделе «Замечания», зачеркнуть цифру, соответствующую номеру замечания (это делается на твердой копии диаграммы).
После рецензирования папки возвращаются библиотекарю. Библиотекарь должен обеспечивать проведение рецензирования в срок. Затем папки регистрируются и направляются автору.
Автор вносит ответ на замечания и, если он согласен с замечаниями, вносит изменения в модель. На практике зачастую сеанс экспертизы проводится в форме устного собеседования между автором и экспертом. В этом случае особенно важно вносить замечания эксперта и комментарии автора в диаграмму для документирования всех идей, возникших в результате моделирования.
Если это необходимо, проводится дополнительная экспертиза у того же или у другого эксперта.
После прохождения нескольких циклов число замечаний обычно уменьшается и диаграмма становится стабильной. В процессе изменения диаграмма может менять свой статус, который должен быть отражен в каркасе диаграммы. Когда автор считает, что диаграмма уже достаточно проработана и достигла уровня «Рекомендовано», он пересылает ее на утверждение в комитет технического контроля, где она проходит окончательную экспертизу. После внесения замечаний и окончательных изменений диаграмма (или набор диаграмм) окончательно утверждается, получает статус «Публикация» и может быть распечатана и распространена среди участников проекта.
1.2.7 Пример выполнения практического задания.
Описание предметной области «Формирование заказов».
Организация, заказчик разработки, занимается продажей различных товаров по заказам.
Деятельность фирмы организована следующим образом: склад получает товар под конкретный заказ, т.е. при приеме заказа от клиента определяется вид необходимой продукции и срок доставки на склад.
Такой способ приема заказов характерен для небольших фирм, которые хотят избежать затоваривания склада и продавать наиболее современные товары.
В силу данного обстоятельства требуется не только формирование заказа контракта и счета клиента, но и формирование заявки для доставки соответствующих товаров на склад
На основании приведенного описания предметной области, используя методологию IDEF0, можно построить следующую функциональную модель, описывающую основные бизнес–процессы (см. рисунки 1.17 - 1.19).
Рисунок 1.17 - Контекстная диаграмма
Рисунок 1.18 - Диаграмма декомпозиции 1-го уровня
Рисунок 1.19 - Диаграмма декомпозиции 2-го уровня
(процесс «Произвести оформление документов на заказ»)
1.3 Дополнение созданной модели процессов диаграммами DFD
1.3.1 Диаграммы поисков данных (Data Flow Diagrams).
Диаграммы потоков данных (Data flow diagrams, DFD) известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму - предвестника DFD.
Диаграммы потоков данных используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ.
DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью диаграмм "сущность-связь" (Entity-Relationship Diagrams, ERD).
DFD можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.
Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна‑Сарсона (Gane‑Sarson).
В Ramus для построения диаграмм потоков данных используется нотация Гейна‑Сарсона.
Основные символы DFD в нотации Гейна‑Сарсона изображены на рис. 1.20. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных.
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным.
|
Название символа |
Изображение символа |
|
Поток данных |
|
|
Процесс |
|
|
Хранилище |
|
|
Внешняя сущность |
|
Рисунок 1.20 - Основные символы диаграммы потоков данных
Назначение процесса (функционального блока) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «Обработать заказ»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
Внешняя сущность (внешняя ссылка) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, «Клиент». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Включение внешних сущностей в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
Если создается независимая DFD модель, то контекстная диаграмма содержит один процесс и внешние сущности (см.рисунок 1.21).
Рисунок 1.21 - Пример контекстной DFD диаграммы
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как данные двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение данных, хранение данных, поставка и распространение данных (см.рисунок 1.22).
Рисунок 1.22 - Пример DFD диаграммы
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD система может рассматриваться как совокупность предметов. В этом случае функциональные блоки именуются по названию системы, например, «Система обработки информации».
Слияние и разветвление стрелок. В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя.
Построение диаграмм DFD. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.
Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением, в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.
Затем модель окружения описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один функциональный блок, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует.
Наконец, модель поведения показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник изображает каждое событие из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения.
Полученные диаграммы могут быть преобразованы с целью более наглядного представления системы, в частности, работы на диаграммах могут быть декомпозированы.
1.3.2 Создание смешанной модели
Авторы нотаций IDEF0 и DFD не предполагали совместного использования диаграмм различной нотации в одной модели, поэтому создание смешанной модели имеет ряд особенностей. Во-первых, существуют определенные правила декомпозиции работы одной нотации в диаграмму другой. Во-вторых, Ramus позволяет разместить объекты одной нотации на диаграмме другой. Рассмотрим эти особенности.
Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге «Создание новой диаграммы» кликнуть по радио-кнопке DFD (см.рисунок 1.23).
Рисунок 1.23 - Дополнение модели IDEF0 диаграммой DFD
Создается новая диаграмма DFD, и стрелки, которые касаются родительской работы, мигрируют на диаграмму нижнего уровня так, как если бы это была диаграмма IDEF0 (см.рисунки 1.24 и 1.25). Стрелки входа родительской работы на дочерней диаграмме DFD показываются входящими стрелками с левой стороны диаграммы DFD, стрелки управления — входящими стрелками с верхней стороны диаграммы и т. д.
Рисунок 1.24 - Декомпозируемый функциональный блок на диаграмме IDEF
Рисунок 1.25 - Диаграмма DFD. Декомпозиция процесса
«Принять заказ и ввести данные»
В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
1)
Добавить в диаграмму внешнюю
ссылку 
. Внешняя ссылка
является источником или приемником данных извне модели.
2)
Добавить в диаграмму хранилище
данных 
. Хранилище данных
позволяет описать данные, которые необходимо сохранить в памяти прежде, чем
использовать в функциональных блоках.
Согласно нотации DFD диаграмма не должна иметь граничных стрелок-все стрелки должны начинаться и заканчиваться на работах, хранилищах данных или внешних сущностях. Поэтому, если строго следовать правилам нотации, следует:
1) Удалить все граничные стрелки на диаграмме DFD.
2) Создать соответствующие внешние сущности и хранилища данных.
Для этого нужно добавить в диаграмму внешнюю сущность или хранилище данных, выбрав соответствующую кнопку на панели инструментов, затем сделать по объекту двойной щелчок и в появившемся диалоговом окне выбрать кнопку «Задать DFD объект» (см.рисунок 1.26).
Рисунок 1.26 - Диалоговое окно «Свойства DFD объекта»
В появившемся диалоговом окне в контекстном меню выбрать пункт Создать элемент (см.рисунок 1.27).
Рисунок 1.27 - Создание элемента классификатора
Название классификатора можно ввести в созданную строку, дважды, медленно кликнув мышью по строке или же нажав клавишу F2, предварительно выделив нужную строку мышью (см.рисунок 1.28). Собственно, таким образом можно редактировать название любого классификатора из созданных (см.рисунок 1.29).
Рисунок 1.28 - Создание классификатора Внешние сущности
Рисунок 1.29 - Создание элемента Заказчик классификатора Внешние сущности
Для завершения создания элемента необходимо щелкнуть по кнопке ОК (см. рисунок 1.30)
Рисунок 1.30 - Завершение создания DFD объекта
Аналогично создаются хранилища данных (см.рисунок 1.31)
Рисунок 1.31 - Создание хранилища данных
3. Создать внутренние стрелки, начинающиеся с внешних сущностей вместо граничных стрелок.
4. Стрелки на диаграмме IDEF0 затуннелировать.
Результат этих действий представлен на рисунке1.32 и 1.33.
Рисунок 1.32 - Туннелирование стрелок на диаграмме IDEF0
Рисунок 1.33 - Замена граничных стрелок внутренними на диаграмме DFD
Строго придерживаться правил нотации DFD при создании смешанных моделей не всегда удобно, поэтому Ramus позволяет создавать граничные стрелки на диаграммах DFD и не идентифицирует такие стрелки как синтаксическую ошибку.
В результате дополнения диаграмм IDEF0 диаграммами DFD может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ в смешанной модели можно увидеть в окне Модели (см.рисунок 1.34). Для отображения окна Модели, необходимо выполнить действия, показанные на рисунке 1.35.
Рисунок 1.34 - Представление смешанной модели в окне Модели
Рисунок 1.35 - Отображение окна Модели
1.3.3 Создание модели DFD.
Для создания модели DFD, в рамках проекта, необходимо в окне Модели в контекстном меню выбрать пункт Создать модель, затем выбрать ее тип и задать свойства новой модели (см.рисунки 1.36 – 1.39).
Рисунок 1.36 - Создание новой модели в проекте
Рисунок 1.37 - Выбор типа модели
Рисунок 1.38 - Контекстное меню для выбора свойств модели
Рисунок 1.39 - Редактирование свойств модели
На основании приведенного в п.п.1.2.7 описания предметной области, используя методологию DFD, можно построить следующую модель, описывающую основные бизнес–процессы (см.рисунки 1.40 - 1.43).
Рисунок 1.40
Рисунки 1.41
Рисунки 1.42
Пример.
Наименование системы.
Полное наименование системы:
Автоматизированная информационная система «Аренда легковых автомобилей».
Условное обозначение системы:
АИС «Аренда легковых автомобилей».
Список литературы
1. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.
2. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
3. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем.
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем.– М.: Финансы и статистика, 2002.
5. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.
6. Пятибратов А.П., Гудыно Л.П., Кириченко А.А. Вычислительные системы, сети и телекоммуникации. – М.: Финансы и статистика, 2001.
7. Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 2000.
8. Петров В.Н. Информационные системы. – СПб.: Питер, 2002.
Содержание
Введение
Курсовые задания
Теоретический материал
Список литературы