Комплексная модель работы строительной фирмы

Министерство образования и науки РФ





Брянский государственный технический университет







Кафедра «Компьютерные технологии и системы»







Тема курсовой работы: «Комплексная модель работы строительной фирмы»												







Документы текстовые

Всего   20  листов









Руководитель      Казаков Ю.М.

«	»			200	г.

Студент    		

«	»			200	г.













Брянск 2006







Задание 

на курсовую работу по дисциплине

«Информационные технологии»



Студент 	Раскина Д.В.	                                            Группа	З 09-ИСТ	

Тема курсовой работы: «Комплексная модель работы строительной фирмы»												



Дата выдачи задания «		» 					200	г.

График выполнения курсовой работы

Функциональная модель системы (стандарт IDEF0)

начало «		» 			 200	 окончание «	» 		200	г.

Диаграмма потоков данных

начало «		» 			 200	 окончание «	» 		200	г.

Диаграмма описания потоков процессов (стандарт IDEF3)

начало «		» 			 200	 окончание «	» 		200	г.

Комплексная модель функционирования системы

начало «		» 			 200	 окончание «	» 		200	г.

Дата сдачи задания «		» 					200	г.



Заведующий кафедрой

«Компьютерные технологии и системы»

д.т.н., профессор								 В.И. Аверченков

							(подпись)

Руководитель курсовой работы 				   				

							(подпись)




Содержание













   1)Цель работы…………………………………………………………….…..4										

    2) Введение…………………………………………………………….………4



3)Описание предметной области………………………………………....….6



4)Описание используемой методологии………………………………….....7



5)Описание процесса построения модели………………..………….……..11



6)Вывод…………………………………………………………………….....20





















































Цель работы.

Освоение  методологии   case средством  BpWin.

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



2. Введение.

SADT - одна из самых известных и широко используемых систем проектирования. SADT - аббревиатура слов Structured Analysis and Design Technique (Технология структурного анализа и проектирования) - это графические обозначения и подход к описанию систем. Дуглас Т. Росс ввел их почти 20 лет назад. С тех пор системные аналитики компании SofTech , Inc . улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное программное обеспечение для оборонных систем, управление финансами и материально-техническим снабжением - вот некоторые из областей эффективного применение SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе интегрированной компьютеризации производства (ICAM) Министерства обороны США была признана полезность SADT, что привело к стандартизации и публикации ее части, называемой IDEFO . Такая стандартизация вкупе с растущей автоматизированной поддержкой означает, что SADT теперь более доступна и проста в использовании. Под названием IDEFO SADT применялась тысячами специалистов в военных и промышленных организациях. В коммерческом мире SADT используется для определения требований. В этом качестве она конкурирует с методами, ориентированными на потоки данных, - структурного проектирования Е.Иордана, структурного анализа Т.ДеМарко, структурного системного анализа С. Гейна и Т. Сарсона, а также с методами структуризации данных -методами М.Джексона, Лж.Д. Варнира и К. Орра. В отличие от этих методов структурного анализа, истоки которых нужно искать в проектировании программного обеспечения, SADT создана для описания системы и ее среды до определения требований к программному обеспечению или к чему-либо другому. Иными словами, поставив своей целью описание системы в общем, создатели SADT изобрели графический язык и набор процедур анализа для понимания системы прежде, чем можно представить себе ее воплощение. Таким образом, SADT, как правило, применяется на ранних этапах процесса создания системы, который часто называют "жизненным циклом системы", и иногда за этим следует применение упомянутых выше методов.

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

•	графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются; 

•	строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: 

•	ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); 

•	связность диаграмм (номера блоков); 

•	уникальность меток и наименований (отсутствие повторяющихся имен); 

•	синтаксические правила для графики (блоков и дуг); 

•	разделение входов и управлений (правило определения роли данных). 

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

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







Предметная область и информационные запросы.



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

Следующий этап- поступление аванса от заказчика для закупки необходимых материалов.

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

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

    На последнем этапе происходит осмотр объекта бригадиром и клиентом и, при отсутствии претензий- сдача объекта в эксплуатацию.







4.  Краткие сведения о методологиях.



                       Методология IDEF0

 Графическое изображение.

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

Наиболее удобным языком моделирования бизнес-процессов является IDEFO, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Desifi Technique. (Подробно методология SADT излагается в книге Дэви А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа проектирования SADT" М.:Метатехнология, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEFO. 

В IDEFO система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

Под моделью в IDEFO понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

Моделируемая система рассматривается как произвольное подмножество во Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.

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

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

                                Методология DFD

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

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться. 

В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС - проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно. 

Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм 

потоков данных являются: 

			внешние сущности; 

			системы/подсистемы; 

			процессы; 

			накопители данных; 

			потоки данных.

. 

Методология описания процессов IDEF3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время, Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.

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

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

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



Описание процесса построения модели.



Построение IDEF0 модели.

К основному блоку добавляем стрелки: Заказ(вход), Готовый объект (выход), Персонал (механизм, т.е. ресурсы, выполняющие работу), ГОСТ (управление, т.е. те правила, которыми руководствуется работа).









Декомпозируем блок Проект на четыре блока: Поступление заказа, Закупка материала, выполнение работы, Контроль качества.

Устанавливаем связи.



Декомпозируем блок Поступление заказа на блоки: Рассмотрение заказа, Анализ рынка, составление сметы, Согласование сторон.





Декомпозируем блок Закупка материала на блоки: Поступление денежных средств от клиента, Подбор материала, Оценка заказчиком, Покупка .



Декомпозируем блок выполнение работы на блоки: Распределение обязанностей, Побелка и покраска, Проверка работы прорабом.



Декомпозируем блок контроль качества на блоки: осмотр бригадиром, Осмотр клиентом.





Построение IDEF3 модели.

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

Процесс выполнения проекта выглядит следующим образом:  При поступлении заказ рассматривается, составляется смета, которая согласовывается с заказчиком. Если заказчик одобряет смету, то перечисляются ДС от заказчика и закупается материал, или расчеты предварительно уточняются. Затем происходит выполнение работ с последующей оценкой и, если претензий нет, то объект принимается, или  первоначально устраняются недочёты в работе.

Декомпозируем блок выполнение проекта на десять взаимосвязанных блоков: Заказ рассматривается, составление сметы, уточнение расчётов, смета согласовывается с заказчиком, закуп, подбор материала, выполнение работ, оценка работ, брак, готовый объект. 

























Построение DFD модели.





В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов.

Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы (Персонал, Заказчик, Готовый объект). 

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

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



Вывод.

BPwin – мощный программный продукт с помощью которого, можно  проводить моделирование, анализ, описание и последующую оптимизацию бизнес-процессов.  

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

Использование BPwin (AllFusion Process Modeler 7) эффективно  использовать в проектах, в которых нужно сделать описание существующих баз предприятия, внедрить на предприятии  корпоративные информационные систем и для проведения реорганизации существующих бизнес-проектов.  С помощью BPwin можно провести оптимизацию деятельности предприятия и осуществить проверку на соответствие ее стандартам ISO 9000, создать проект организационной структуры, исключить ненужные операции, уменьшить размер издержек и увеличить эффективность. В основе программного продукта  BPwin (AllFusion Process Modeler 7) заложены общепринятые технологии моделирования, такие как idef0. Использование этого программного комплекса позволяет эффективно обеспечить все аспекты моделирования информационных систем.





2