Кожемякина Ольга Петровна1, Гусева Елена Николаевна2
1Магнитогорский Государственный Технический Университет им. Г. И. Носова, студентка
2Магнитогорский Государственный Технический Университет им. Г. И. Носова, кандидат педагогических наук, доцент кафедры бизнес-информатики и информационных технологий
Аннотация
В статье рассматривается моделирование бизнес-процессов строительной компании. Приведены результаты исследования финансово-экономической деятельности организации. Построена функциональная модель бизнес-процессов. Построена имитационная модель в программной среде Arena, проведен компьютерный эксперимент и проанализированы его результаты. Разработаны рекомендации по совершенствованию деятельности компании и произведено экономическое обоснование внедрения данных рекомендаций.
Kozhemyakina Olga Petrovna1, Guseva Elena Nikolaevna2
1Magnitogorsk State Technical University, student
2Magnitogorsk State Technical University, Associate Professor of Business Informatics and Information Technologies
Abstract
The article discusses the modeling of business processes of the construction company. The results of investigation of financial and economic activities of the organization. Build a functional model of the business processes. Build a simulation model in the software environment Arena, conducted a computer experiment and analyze the results. Recommendations for improving the company’s operations and business case made implementation of these recommendations.
Библиографическая ссылка на статью:
Кожемякина О.П., Гусева Е.Н. Применение имитационного моделирования для совершенствования деятельности строительной фирмы // Современная техника и технологии. 2015. № 6 [Электронный ресурс]. URL: https://technology.snauka.ru/2015/06/7094 (дата обращения: 25.02.2023).
Введение
Строительная отрасль России развивается быстрыми темпами, однако согласно результатам исследований специалистов в ближайшие пять лет строительный рынок ждёт замедление роста до 2,9-3,5% в год, а основная доля рынка – до 70% – будет приходиться на жилищное строительство. Компании, ведущие бизнес в России, зафиксировали падение прибыли из-за сокращения потребительской активности населения. Кроме того, наша строительная отрасль зависит от импорта оборудования и строительных материалов, которые в последнее время подорожали. Цены на отечественную продукцию также растут, приближаясь к мировым, что является следствием высоких удельных расходов и затрат при производстве, особенно на топливно-энергетические ресурсы. Основными проблемами строительных компаний являются: увеличение стоимости материалов, инструментов и оборудования, снижение спроса на услуги, высокая конкуренция. Эти обстоятельства обуславливают проведение глубокого анализа деятельности предприятия и ее совершенствование. Моделирование бизнес-процессов является одним из методов улучшения качества и эффективности работы организации [1]. Существует несколько подходов моделирования, однако имитационное моделирование является единственным методом, который обеспечивает как точный анализ, так и визуальное представление [2]. Разработка имитационной модели строительной фирмы и составление рекомендаций по совершенствованию деятельности актуально в рамках данной работы.
Объектом исследования является хозяйственно-экономическая деятельность строительной компании. Предметом исследования является моделирование и анализ бизнес-процессов строительной фирмы. Целью исследования является совершенствование бизнес-процессов компании, повышение эффективности деятельности предприятия.
Для достижения указанной цели были поставлены и решены следующие задачи:
1) исследование бизнес-процессов компании и построение ее функциональной модели;
2) анализ современных программных средств имитационного моделирования;
3) построение имитационной модели и проведение компьютерного эксперимента на модели;
4) разработка рекомендаций по совершенствованию деятельности предприятия.
5) расчет экономической эффективности внедрения рекомендаций по совершенствованию деятельности предприятия.
Основная часть
Работа была написана на базе малого предприятия ИП Хайруллин М.М., которое занимается предоставлением услуг строительно-ремонтных работ в городе Магнитогорске. Строительная компания реализует такие виды деятельности: ремонт квартир и офисов, выполнение штукатурно-малярных работ, облицовка плиткой, укладка гипсокартона, ламината, отделка потолков, работы с электрическим оборудованием, сантехникой. Кроме того, компания выполняет и крупные заказы, такие, как: строительство коттеджей «под ключ». В ходе исследования бизнес-процессов компании выявлены основные сущности, ресурсы (персонал, материальные, финансовые и информационные), процессы и их параметры, временные характеристики выполняемого заказа в зависимости от площади строительного объекта и вида выполняемых работ. Построена функциональная модель деятельности строительной компании AS-IS в нотации IDEF0 [3], контекстная диаграмма представлена на рис.1, а ее декомпозиция изображена на рис.2
Рисунок 1 – Контекстная диаграмма функциональной модели
Рисунок 2 – Декомпозиция контекстной диаграммы
Благодаря построенной функциональной модели определены «узкие» места в работе компании: бумажный документооборот, дублирование информации, возникновение ошибок в документах и потеря данных. Так как функциональная модель помогла выявить только проблемы, связанные с информационными бизнес-процессами, было принято решение о построении имитационной модели бизнес-процессов компании для более детального анализа деятельности фирмы.
При выборе программной среды, в которой будет строиться имитационная модель, был проведен сравнительный анализ современных программных средств имитационного моделирования: GPSS World, AutoMod, AnyLogic, Arena [4]. Критериями оценки послужили: область применения, функциональные возможности, пользовательский интерфейс, совместимость с базовыми и прикладными программами, анимация моделируемых процессов, статистический анализ результатов моделирования. В ходе анализа определена наиболее подходящая по заданным критериям система: Arena, компании-разработчика Rockwell Software.
Была построена и описана имитационная модель в среде Arena [5]. На диаграмме верхнего уровня (рис.3) выделены основные бизнес-процессы деятельности строительной фирмы: расчет стоимости заказа; закупка материалов; отгрузка материалов; выполнение строительных работ; ведение отчетности.
Рисунок 3 – Диаграмма верхнего уровня имитационной модели
Бизнес-процессы компании инициируются с момента поступления заявки клиента на выполнение строительных работ. Затем менеджер выполняет расчет примерной стоимости заказа в подмодели. В данном процессе определяется потребность в строительных материалах, оборудовании, приблизительную длительность выполнения работ, количество и специализацию рабочих для выполнения заказа. Дизайнер при необходимости разрабатывает дизайн-проект помещения. На выходе мы имеем оплаченную заявку, сопроводительную документацию, смету, а так же дизайн проекта. Далее в соответствии со сметой выполняется закупка строительных материалов. Этот процесс включает: выбор поставщиков сырья и материалов, заказ материалов и расчеты с поставщиками, в результате чего получаем все необходимые документы на материалы, а так же сами материалы. Следующий процесс – это отгрузка материалов на склад. Результатом данного процесса является поставка материалов рабочим для выполнения строительных работ. После этого бригада рабочих приступают к выполнению заказа. Длительность работ напрямую зависит от их объема и сложности. После окончания работ производится полный расчет с клиентом и формируется отчетность.
После построения модели произведен имитационный компьютерный эксперимент и анализ его результатов. Имитационная модель помогла выявить следующие «проблемные» места: значительные временные затраты на обработку документов; нехватка рабочего персонала; нерациональное использование рабочего времени; увеличение финансовых затрат; несвоевременное выполнение заказов; снижение количества заказов.
На рис.4 показан результат отчета о входящих и выполненных заказах. Эти данные доказывают, что не все заказы выполняются в срок.
Рисунок 4 – Отчет о входящих и выполненных заказах
Результат отчета о занятости персонала (рис.5) показывает, что некоторые ресурсы имеют слишком низкую занятость, это негативно сказывается на затратах компании, производительности труда и обуславливает простои в работе.
Рисунок 5 – Отчет о занятости персонала в процентах
Устранить выявленные проблемы, помогут составленные рекомендации по совершенствованию в деятельности предприятия. Рекомендации:
- автоматизация документооборота;
- сокращение затрат на хранение товарно-материальных запасов;
- снижение издержек на логистику;
- реорганизация организационной структуры и должностных обязанностей персонала;
- усовершенствование технической инфраструктуры предприятия;
- эффективное использование времени простоев;
- повышение производительности труда;
- развитие клиентской базы.
Для обоснования экономической эффективности [6] внедрения предложенных рекомендаций выполнен расчет затрат на внедрение составленных рекомендаций, спрогнозирован экономический эффект от их внедрения в виде прибыли.
Рассчитан коэффициент экономической эффективности внедрения рекомендаций [6].
Коэффициент общей экономической эффективности капитальных вложений (Э):
где П – годовая прибыль, тыс. руб./год;
К – капитальные вложения, тыс. руб./год.
Э = 1800 тыс. руб./570 тыс. руб. ;
Э = 3,1.
Коэффициент общей экономической эффективности 3,1 > 1 следовательно, внедрение рекомендаций по совершенствованию деятельности компании эффективно.
Определен срок окупаемости капиталовложений [6].
Срок окупаемости (Т):
где П – годовая прибыль, тыс. руб./год;
К – капитальные вложения, тыс. руб./год.
Т = 570 тыс. руб./1800 тыс. руб. ;
Т = 0,3 года = 3,5 месяца.
Т.е. внедрение рекомендаций окупится через 3 месяца и начнет приносить прибыль. График, представленный на рис.7,показывает, как изменяется денежный поток в течение 12 месяцев. Так как срок окупаемости достаточно короткий, риски, связанные с внедрением рекомендаций не высоки.
Рисунок 7 – График срока окупаемости капиталовложений
Заключение
Методология IDEF0 послужила удобным инструментом функционально-информационного описания бизнес-процессов строительной фирмы. Функциональная модель позволяет понять, какие объекты служат исходными данными для процессов, какие результаты производятся каждой работой, что является управляющим фактором и какие ресурсы для этого необходимы. В данном случае применение функционального моделирования может решать не только технические проблемы строительной фирмы, связанные с информационными технологиями, но также проблемы, имеющие отношение к сфере ее производственной деятельности.
Компьютерный эксперимент с имитационной моделью позволил визуализировать бизнес-процессы строительной фирмы, проследить за динамикой выполнения заказов, протяженностью работ, занятостью персонала. Поскольку конечной целью моделирования бизнес-процессов компании является улучшение ее деятельности, то можно считать, что именно программа-имитатор позволила разобраться в причинах возникновения «узких мест» в деятельности организации. Были выявлены случаи продолжительного простоя оборудования, нерациональное использование трудовых ресурсов предприятия. Детальный анализ числовых характеристик моделируемого процесса позволил сформулировать ряд рекомендаций, внедрение которых, позволит улучшить бизнес-процессы строительной фирмы, что в свою очередь приведет к сокращению затрат предприятия и оптимизации ее деятельности.
Библиографический список
- Гусева Е.Н. Имитационное моделирование экономических процессов в среде «Arena» : учеб. пособ.: [электронный ресурс]/ Е. Н. Гусева. – М.: Флинта, 2011.– 132с.
- Гусева Е.Н. Основы имитационного моделирования экономических процессов: лаб. практикум / Е.Н. Гусева. – Магнитогорск: МаГУ, 2008. – 100с.
- Гусева Е.Н. Имитационное моделирование разработки рудника по добыче меди.– Современные проблемы и пути их решения в науке, транспорте, производстве и образовании 2013: Сб. науч. тр. по материалам международ. науч.-практ. конф.– Одесса: Черноморье, 2013. – Т. 11. – С.73-76.
- Зиновьев В.В., Гречишкин П.В., Практическое применение программных средств имитационного моделирования // Сб. докл. III Всерос. науч.-практ. конф. «Имитационное моделирование. Теория и практика.» (ИММОД-2007), Санкт-Петербург, 17-19 окт. 2007. С. 78-82.
- Интернет-проект «Менеджмент качества» статья «Моделирование бизнес-процессов» URL: http://www.kpms.ru/General_info/BPM.htm (дата обращения: 06.06.2015)
- Марка Д. А., Мак Гоуэн К. Методология структурного анализа и проектирования SADT . – М.: Метатехнология, 1993. – 240с.
- Немцев В.Н., Телятников К.М. Совершенствование инструментов управления промышленного предприятия // Материалы 66-й научно-технической конференции МГТУ: Сб. докладов. Т. 2. Магнитогорск: ГОУ ВПО «МГТУ», 2008. С. 149-152.
- Чусавитина Г.Н. Использование метода логико-смыслового моделирования при подготовке будущего специалиста по информатике // Проблемы науки и образования в современной высшей школе. Тезисы докладов XXXVIII внутривузовской научной конференции преподавателей МаГУ. — 2000. – С. 191-194.
- Шеер А.В. Моделирование бизнес-процессов. – М.: Весть – МетаТехнология, 2009. – 347с.
- Электронная скан-библиотека Роль капитального строительства в инвестиционном процессе URL: http://bookdata.org/construction/investments07/economics05.php (дата обращения: 02.06.2015)
Все статьи автора «Ольга Кожемякина»
Система ‘Учет заказов и их выполнение в строительной фирме’
Министерство
образования и науки Российской Федерации
Государственное
автономное образовательное учреждение
среднего
профессионального образования Свердловской области
«Уральский
радиотехнический колледж им. А.С. Попова»
специальность:
230401 — Информационные системы (по отраслям)
Курсовая
работа
Система
«Учет заказов и их выполнение в строительной фирме»
Екатеринбург
2015
Содержание
Введение
. Постановка задачи
. Системный проект
.1 Описание предметной области
.2 Диаграмма потоков данных
.3 Описание данных
.4 Спецификация системы
.5 Логическая структура базы данных
.6 Физическая структура базы данных
Заключение
Список литературы
Введение
Новые материалы, технологии и инструменты приводят к увеличению темпов
выполнения работ в строительной отрасли и появлению конкуренции среди
строительных фирм. Для того чтобы выжить на рынке и получить хорошую прибыль,
необходимо не только отлично выполнять работы по основному виду деятельности,
но и отладить сопутствующие функции — учет материалов, обслуживание и учет
клиентов, своевременное формирование отчетности.
От скорости получения нужной информации по материалам, клиентам, заказам,
учету затрат и доходов зависит выбор верных решений в управлении фирмой.
Необходима автоматизация этих операций.
Для автоматизации учета заказов и их выполнения в строительной фирме
нужно разработать программное обеспечение, которое обеспечит ввод, хранение,
редактирование и получение информации.
Цель курсовой работы — проектирование автоматизированного рабочего места
(АРМ) системы «Учет заказов и их выполнение в строительной фирме».
АРМ состоит из программно-аппаратные средств, которые позволяют работать
с данными — обеспечивают удобный ввод, редактирование, хранение информации,
получение информации в виде запросов и отчетов, вывод ее на печать или на
экран.
Необходимость разработки соответствующей информационной системы
обусловлена требованиями к обработке большого объема данных и быстрому
получению информации.
1. Постановка
задачи
Для автоматизации работы строительной фирмы, обеспечения доступа и
обработки достоверной информации необходимо разработать систему по учету
заказов и их выполнения.
Строительная фирма занимается ремонтом помещений. В результате увеличения
количества клиентов, поставщиков, материалов, технологий стало необходимо
автоматизировать учет клиентов и заказов, а также материалов.
При выполнении работ сотрудники фирмы руководствуются должностными и
технологическими инструкциями, а также разработанным Порядком выполнения работ
и оказания услуг. Разработан перечень услуг, которые могут быть заказаны и
выполнены.
Материалы для ремонта по договору с поставщиком поступают на склад, где
ведет учет кладовщик. Данные по материалам должны поступать в общую базу
данных.
В соответствии с нормами расхода материалов, ценами на материалы и
другими затратами проводится калькуляция стоимости услуг экономистом фирмы.
Результат — прайс-лист, который предоставляется клиентам.
При обращении клиента его данные вносятся в базу. Затем клиент
определяется с выбором услуг, менеджер оформляет заказ, выдает квитанцию на
оплату.
Сотрудник — мастер в соответствии с полученным заказом получает на складе
материалы и выполняет работу. После выполнения работы клиент оплачивает ее и
получает чек.
Информация по выполненному заказу и его оплате также поступает в базу и
используется для формирования отчетности и принятия соответствующих решений
руководством фирмы.
Можно выделить следующие процессы в информационной системе.
1) Прием материалов.
Прием материалов на склад осуществляет кладовщик, затем вводит информацию
в базу.
2) Калькуляция цен на услуги.
Экономист в соответствии с нормами расхода и технологическими
инструкциями делает подбор материалов для оказания каждой услуги. Затем в
соответствии с ценами на материалы и прочими затратами делается расчет
стоимости услуг.
) Оформление заказа.
Данные о клиенте и объекте ремонта вводятся в базу менеджером. Клиент
выбирает услуги и их количество. Затем формируется заказ, печатается квитанция.
) Выполнение заказа.
Мастер получает материалы на складе и выполняет работу.
5) Оплата заказа.
Клиент оплачивает готовую работу по квитанции.
) Формирование отчетности.
Данные по выполненному заказу и поступившей оплате вводятся в базу
менеджером. По запросу или по итогам расчетного периода проводится расчет
доходов и расходов, формируются различные отчеты.
2. Системный
проект
.1 Описание
предметной области
Проведем первый этап проектирования базы данных — создание модели
процессов. Одним из самых удобных средств для этого — программа AllFusion Process
Modeler (BPWin).
Программа BPWin предназначена для структурного моделирования деловых
процессов. Она легко осваивается пользователями, поскольку имеет простой и
понятный интерфейс. Программа поддерживает несколько методологий. В работе
используются диаграммы IDEF0, в которых процесс представляется совокупностью
взаимодействующих работ или функций, а также DFD — диаграммы потоков данных
Проектирование начинается с контекстной диаграммы, то есть наиболее
абстрактного уровня модели, который является практически ее общим описанием.
Затем проведем декомпозицию крупных фрагментов системы на более мелкие части.
Контекстная диаграмма представлена на (рисунок 1).
Рисунок
1 — Функциональная модель системы учета заказов
Входные
данные — это материал или информация, которые используются или преобразуются
функцией (работой). Входными данными являются поступление материалов, обращение
клиента
Выходами
системы являются материал или информация, которые производятся функцией (работой).
Это прайс-лист, чек и отчеты. Система может не иметь входа, но обязательно
должен быть хотя бы один выход.
Стрелка
сверху — это управление, правила, стратегии, процедуры или стандарты, которыми
руководствуется функция (работа). Это должностные и технологические инструкции,
разработанный Перечень услуг и Порядок оказания услуг, нормы расхода материалов
на услуги, договор с поставщиком, на основе которого принимаются материалы.
Выход
может быть входом или управлением для другой функции.
Стрелка
снизу — это механизм, ресурсы, которые выполняют работы. В данной системе можно
выделить четыре вида ресурсов — кладовщик, мастер, экономист, менеджер.
Проведем
декомпозицию полученной модели (рисунок 2).
Рисунок
2 — Декомпозиция процесса «Учет заказов и выполнение работ»
Программа
позволяет выделять цветом стрелки. Это удобно, когда стрелок много, и они
разделяются.
Выделим
шесть фрагментов — поступление материалов, калькуляция цен на услуги,
оформление заказа, выполнение заказа, оплата заказа и формирование отчетности.
Проведем
декомпозицию крупных фрагментов до достижения нужного уровня детализации.
Прием
материалов делится на прием на склад (выход — материалы на складе) и ввод
информации в базу данных (рисунок 3). На выходе — хранящаяся в базе данных
информация.
Рисунок
3 — Декомпозиция процесса «Прием материалов»
Калькуляция
цен на услуги (рисунок 4) делится на подбор материалов для каждой услуги
расчета цен на них. Выход — прайс-лист на услуги.
Рисунок
4 — Декомпозиция процесса «Калькуляция цен на услуги»
Оформление
заказа (рисунок 5) делится на ввод информации по клиенту в базу данных, выбор
услуг клиентом, оформление заказа. Управлением для функции выбора услуг
является прайс-лист, но основе которого клиент принимает решение. Ресурс —
менеджер.
Рисунок 5 — Декомпозиция процесса «Оформление заказа»
На выходе этой диаграммы — оформленный заказ и квитанция на оплату.
Следующая диаграмма — выполнение заказа (рисунок 6).
Рисунок 6 — Декомпозиция процесса «Выполнение заказа»
Получив заказ, мастер получает материалы от кладовщика и выполняет
работу. На выходе — выполненные работы.
Затем клиент оплачивает работу по квитанции (без декомпозиции).
Декомпозиция фрагмента «Формирование отчетности» на (рисунок
7).
Менеджер вносит информацию о выполнении заказа и оплате, затем
рассчитывает доходы и расходы, формирует отчеты.
Рисунок 7 — Декомпозиция процесса «Формирование отчетности»
.2 Диаграмма
потоков данных
Диаграммы потоков данных используются для описания движения документов и
обработки информации как дополнение к IDEF0. В отличие от IDEF0, где система
рассматривается как взаимосвязанные работы и стрелки представляют собой жесткие
взаимосвязи, стрелки в DFD показывают лишь то, как объекты (включая данные)
движутся от одной работы к другой. DFD отражает функциональные зависимости
значений, вычисляемых в системе, включая входные значения, выходные значения и
внутренние хранилища данных. DFD — это граф, на котором показано движение
значений данных от их источников через преобразующие их процессы к их
потребителям в других объектах.содержит процессы, которые преобразуют данные,
потоки данных, которые переносят данные, активные объекты, которые производят и
потребляют данные, и хранилища данных, которые пассивно хранят данные.
Диаграмма DFD строительной фирмы приведена на (рисунок 8).
Рисунок 8 — Диаграмма потоков данных
.3 Описание
данных
Описание данных сформировано при помощи средства автоматизированного
проектирования AllFusion Process Modeler (BPwin).
Arrow Name: Выполненные работыStatus: WORKINGDest.: Оплата заказаDest.
Type: InputSource: Выполнение работSource Type: OutputDest.: Расчет
доходов и расходовDest. Type: InputName: Договор с поставщикомStatus: WORKINGDest.: Прием на складDest. Type: ControlSource:
{Border}Source Type: ControlName: Должностные инструкцииStatus: WORKINGDest.: Оплата заказаDest.
Type: ControlSource: {Border}Source Type: ControlDest.: Прием на складDest. Type: ControlDest.: Ввод информации в базу данныхDest. Type: ControlDest.: Подбор
материалов для оказания каждой
услугиDest. Type: ControlDest.: Расчет цен на услугиDest. Type: ControlDest.: Ввод информации о клиенте в базу данныхDest.
Type: ControlDest.: Выбор услугDest. Type: ControlDest.: Формирование заказаDest. Type: ControlDest.: Получение материалов со складаDest. Type: ControlDest.: Выполнение работDest. Type: ControlDest.: Расчет доходов и расходовDest. Type: ControlDest.: Формирование отчетовDest. Type: ControlName: ЗаказStatus: WORKINGDest.: Получение материалов со складаDest. Type: InputSource: Формирование заказаSource Type: OutputName: Информация в БДStatus: WORKINGDest.: Формирование отчетовDest. Type: Input
Arrow Source: Расчет доходов и расходов
Arrow Source Type: OutputName: Информация о клиентеStatus: WORKINGDest.: Выбор услуг
Arrow Dest. Type: InputSource: Ввод информации о клиенте в базу данных
Arrow Source Type: OutputName: Информация о материалахStatus: WORKINGDest.: Расчет
цен на услугиDest. Type: InputSource: Ввод информации в базу данныхSource Type: OutputName: Квитанция на оплатуStatus: WORKINGDest.: Оплата
заказаDest. Type: ControlSource:
Формирование заказаSource Type: OutputName: КладовщикStatus: WORKINGDest.: Прием на складDest. Type:
MechanismSource: {Border}Source Type: MechanismDest.: Ввод информации в базу данныхDest. Type: MechanismDest.: Получение материалов со складаDest. Type: MechanismName: МастерStatus: WORKINGDest.: Получение материалов со складаDest. Type: MechanismSource: {Border}Source Type:
MechanismDest.: Выполнение работDest. Type: MechanismName: Материалы на складеStatus: WORKINGDest.: Получение материалов со складаDest. Type: InputSource: Прием на складSource Type: OutputName: МенеджерStatus: WORKINGDest.: Оплата заказаDest.
Type: MechanismSource: {Border}Source Type: MechanismDest.: Ввод информации о клиенте в базу данныхDest.
Type: MechanismDest.: Выбор услугDest. Type: MechanismDest.: Формирование заказаDest. Type:
MechanismDest.: Расчет доходов
и расходовDest. Type: MechanismDest.: Формирование отчетов
Arrow Dest. Type: MechanismName: Набор услугStatus: WORKINGDest.: Формирование
заказаDest. Type: InputSource: Выбор услугSource Type: OutputName: Нормы
расхода материаловStatus: WORKINGDest.: Подбор материалов для оказания каждой
услугиDest. Type: ControlSource: {Border}Source Type: ControlName: Обращение
клиентаStatus: WORKINGDest.: Оплата заказаDest. Type: InputSource:
{Border}Source Type: InputDest.: Ввод информации о клиенте в базу данныхDest.
Type: InputName: ОтчетыStatus: WORKINGDest.: {Border}Dest. Type: OutputSource:
Формирование отчетовSource Type: OutputName: Перечень услугStatus:
WORKINGDest.: Подбор материалов для оказания каждой услугиDest. Type:
ControlSource: {Border}Source Type: ControlName: Порядок оказания услугStatus:
WORKINGDest.: Оплата заказаDest. Type: ControlSource: {Border}Source Type:
ControlDest.: Прием на складDest. Type: ControlDest.: Подбор материалов для
оказания каждой услугиDest. Type: ControlDest.: Расчет цен на услугиDest. Type:
ControlDest.: Ввод информации о клиенте в базу данныхDest. Type: ControlDest.:
Выбор услугDest. Type: ControlDest.: Формирование заказаDest. Type:
ControlDest.: Выполнение работDest. Type: ControlDest.: Расчет доходов и
расходовDest. Type: ControlDest.: Формирование отчетовDest. Type: ControlName:
Поступление денегStatus: WORKINGDest.: Расчет доходов и расходовDest. Type:
InputSource: Оплата заказаSource Type: OutputName: Поступление
материаловStatus: WORKINGDest.: Прием на складDest. Type: InputSource: { Border
}Source Type: InputName: Прайс-листStatus: WORKINGDest.: {Border}Dest. Type:
OutputSource: Расчет цен на услугиSource Type: OutputDest.: Выбор услугDest.
Type: ControlName: Технологические инструкцииStatus: WORKINGDest.: Подбор
материалов для оказания каждой услугиDest. Type: ControlSource: {Border}Source
Type: ControlDest.: Расчет цен на услугиDest. Type: ControlDest.: Получение
материалов со складаDest. Type: ControlDest.: Выполнение работDest. Type:
ControlName: ЧекStatus: WORKINGDest.: { Border }Dest. Type: OutputSource:
Оплата заказаSource Type: OutputName: ЭкономистStatus: WORKINGDest.: Подбор
материалов для оказания каждой услуги
Arrow Dest. Type: MechanismSource: {Border}Source Type:
MechanismDest.: Расчет цен на услугиDest. Type: Mechanism
.4
Спецификация системы
программный информация база учет
Для описания цели и функциональных возможностей системы составляется ее
спецификация. Спецификация может быть нескольких видов — словесная, модельная,
формальная.
Спецификация — это описание алгоритмов задач, выполняемых процессами.
В спецификации указывается, что должна делать система, и не указывается,
каким именно образом.
Если спецификация системы существует, то, чтобы показать, что система
удовлетворяет спецификации, применяют методы формальной верификации.
Кроме верификации также применяют валидацию для исследования соответствия
спецификации требованиям пользователя.
) Спецификация процесса «Прием материалов»
@ВХОД = Поступление материалов (Наименование, цена)
@ВЫХОД = Данные о материалах (Наименование, Цена)
@СПЕЦПРОЦ Прием материалов
ВЫПОЛНИТЬ принять материалы, ввести данные в базу
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА Приема материалов
) Спецификация процесса «Калькуляция цен на услуги»
@ВХОД = Информация о материалах (Наименование, Цена)
@ВЫХОД = Прайс-лист (Название услуги, Цена)
@СПЕЦПРОЦ Расчет цен на услуги
ВЫПОЛНИТЬ подобрать список материалов для выполнения услуги, рассчитать
стоимость услуги
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА Калькуляции цен на услуги
) Спецификация процесса «Оформление заказа»
@ВХОД = Данные клиента (ФИО, адрес и телефон клиента)
@ВЫХОД = Оформленный заказ (номер заказа, дата заказа, код клиента, код
услуги, количество)
@СПЕЦПРОЦ Оформление заказа на осуществление услуг
ВЫПОЛНИТЬ выбрать услуги, ввести данные о заказе в таблицы заказов и
услуг по заказам
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА Оформления заказа
4) Спецификация процесса «Выполнение заказа»
@ВХОД = Оформленный заказ (номер заказа, дата заказа, код клиента, код
услуги, количество), материалы на складе
@ВЫХОД = Выполненные работы (Дата выполнения)
@СПЕЦПРОЦ Выполнение заказа
ВЫПОЛНИТЬ получить материалы, выполнить работу
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА Выполнения заказа
) Спецификация процесса «Оплата заказа»
@ВХОД = Выполненные работы (Дата выполнения), Обращение клиента
@ВЫХОД = Чек
@СПЕЦПРОЦ Принять оплату заказа
ВЫПОЛНИТЬ Принять деньги согласно квитанции
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА Оплаты заказа
) Спецификация процесса «Формирование отчетности»
@ВХОД = Выполненные работы, оплата заказа (Дата выполнения, Дата оплаты)
@ВЫХОД = Отчеты
@СПЕЦПРОЦ Формирование отчетов
ВЫПОЛНИТЬ сформировать отчеты
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА Формирования отчетности
2.5
Логическая структура базы данных
Чтобы визуально представить структуру данных системы, их атрибуты и
связи, формируют логическую модель данных. Она представляет данные независимо
от требований платформы и языка реализация базы данных.
В реляционных моделях данных объекты и взаимосвязи между ними
представляются с помощью таблиц. Каждая таблица представляет один объект и
состоит из строк и столбцов. Таблица в реляционной модели называется
отношением.
Атрибут (поле) — любой столбец в таблице.
Домен — множество значений, которые может принимать атрибут.
Кортежи (записи) — строки таблицы.
Таблицы связаны между собой при помощи ключевых полей.
Ключ — это поле, позволяющее однозначно идентифицировать запись в
таблице. Ключ может быть простым (состоит из одного поля) или составным (из
нескольких полей).
Основным средством разработки логической модели данных в настоящий момент
являются различные варианты ER-диаграмм. Концептуальная модель данных на
логическом уровне представлена на (рисунок 8).
Рисунок 8 — Концептуальная модель данных на логическом уровне
2.6
Физическая структура базы данных
Физическая модель данных, в отличие от логической, зависит от конкретной
СУБД. Физическая модель информацию о всех объектах базы данных. При этом
физическая модель зависит от конкретной реализации СУБД из-за отсутствия
общепринятого стандарта. Одной и той же логической модели могут соответствовать
несколько разных физических моделей.
В физической модели нужно описывать всю информацию о конкретных объектах
— таблицах, столбцах, доменах, индексах, процедурах, триггерах.
Концептуальная модель данных на физическом уровне представлена на
(рисунок 9).
Рисунок 9 — Концептуальная модель данных на физическом уровне
При разработке определены требования к системе, ограничения и условия
функционирования программы, создана функциональная модель и диаграмма потоков
данных, построены логическая и физическая модели базы данных.
Разработанное по созданному проекту программное обеспечение позволит
повысить эффективность выполнения работ в строительной фирме, улучшить работу с
клиентами и учет заказов, повысить качество планирования и анализа доходов и
расходов, увеличить скорость принятия решений руководством фирмы.
Список
литературы
1. Бойко
В.В., Савинков М. Проектирование БД информационных систем; М: «Финансовая
статистика», 1989 г.
2. Гвоздева
В.А. Основы построения автоматизированных информационных систем: учебник. М.:
ИНФРА-М. 2007. 320 с.
. Емельянова
Н.З. Проектирование информационных систем / Т.Л. Партыка, И.И. Попов. М.:
Форум. 2011. 432 с
. Маклаков,
С.В. Создание информационных систем с ALLFusion Modeling Suite. М.:
Диалог-МИФИ. 2007. 400 с.
. Рогозов
Ю.И., Стукотий Л.Н., Свиридов А.С. Моделирование систем, ТРТУ, 2004.
. Красильникова
М.B. Проектирование информационных систем. 2004 г.
. Сатунина
А.Е. Управление проектом корпоративной информационной системы предприятия /
Л.А. Сысоева. М.: Финансы и статистика. 2009. 352 с.
. Соловьев
И.В. Проектирование информационных систем. Фундаментальный курс. / А.А.
Майоров. М.: Академический проект. 2009. 398 с.
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
1 |
|
Диаграмма строительной компании23.03.2020, 18:12. Показов 3845. Ответов 15
Здравствуйте! Есть строительная компания. Правильно ли я создал модель диаграммы? Миниатюры
0 |
|
8554 / 5425 / 568 Регистрация: 27.03.2013 Сообщений: 18,708 |
|
|
23.03.2020, 18:45 |
2 |
|
Связей между таблицами нет.
0 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 19:04 [ТС] |
3 |
|
VinniPuh, я аксессом не пользуюсь, сейчас просто необходимость такая появилась, а ради одного случая качать не особо хочется. Вот со связями, что скажете? Миниатюры
0 |
|
Модератор 11306 / 4633 / 743 Регистрация: 07.08.2010 Сообщений: 13,394 Записей в блоге: 4 |
|
|
23.03.2020, 19:05 |
4 |
|
Правильно ли я создал модель диаграммы? нет, неправильно(имеется ввиду схема 1, вторую еще не смотрела)
0 |
|
8554 / 5425 / 568 Регистрация: 27.03.2013 Сообщений: 18,708 |
|
|
23.03.2020, 19:16 |
5 |
|
…я аксессом не пользуюсь,… А зачем тогда в разделе про — Access вопрос задаёте.
0 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 19:21 [ТС] |
6 |
|
VinniPuh, где бы я это не делал — мне все равно нужна помощь.
0 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 19:22 [ТС] |
7 |
|
shanemac51, а если так? Миниатюры
0 |
|
8554 / 5425 / 568 Регистрация: 27.03.2013 Сообщений: 18,708 |
|
|
23.03.2020, 19:28 |
8 |
|
Ну так логичнее просить помощи там, в какой программе собираетесь делать, а не там, хоть в где.
0 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 19:31 [ТС] |
9 |
|
VinniPuh, с чего вы взяли, что у меня вообще MCOffice есть?
0 |
|
Модератор 11306 / 4633 / 743 Регистрация: 07.08.2010 Сообщений: 13,394 Записей в блоге: 4 |
|
|
23.03.2020, 19:34 |
10 |
|
а если так? мне не нравится
0 |
|
8554 / 5425 / 568 Регистрация: 27.03.2013 Сообщений: 18,708 |
|||||
|
23.03.2020, 19:39 |
11 |
||||
|
…с чего вы взяли, что у меня вообще MCOffice есть?… Потому что — Access , неотъемлемая часть — MC Office и вы задаёте вопрос, именно в разделе — Access.
0 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 19:41 [ТС] |
12 |
|
VinniPuh, Кстати, а почему при установке — Офиса вы Акцесс не установили? Для особо внимательных, спрошу еще раз. С чего вы взяли, что у меня вообще MCOffice есть/ устанавливал?
0 |
|
802 / 316 / 59 Регистрация: 29.03.2016 Сообщений: 680 |
|
|
23.03.2020, 20:20 |
13 |
|
Правильно ли я создал модель диаграммы? Несмотря на отсутствие подробного ТЗ, можно уверенно ответить: Нет.
1 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 20:24 [ТС] |
14 |
|
Jamaica, ТЗ: построить ER-диаграмму по таким данным : Строительная компания Вот что у меня по итогу вышло : Миниатюры
0 |
|
802 / 316 / 59 Регистрация: 29.03.2016 Сообщений: 680 |
|
|
23.03.2020, 20:35 |
15 |
|
РешениеТо, что у Вас имеется — это не ТЗ, это можно назвать «хотелка». Из ошибок: Для более/менее вменяемого решения этой задачи нужно изучить (хотя бы вкратце)
1 |
|
0 / 0 / 0 Регистрация: 28.04.2019 Сообщений: 118 |
|
|
23.03.2020, 20:39 [ТС] |
16 |
|
Jamaica, у меня более этого условия — нет. Спасибо, буду исправлять!
0 |
(продолжение)
Изображение слайда
2
Слайд 2: Пример диаграммы IDEF0
Изображение слайда
3
Слайд 3: Контекстная диаграмма
Контекстный блок — функциональный блок самого высокого уровня
Изображение слайда
4
Слайд 4: Дочерняя диаграмма
0
A-0
2
A0
3
1
A3
2
A3
3
1
A32
Изображение слайда
5
Слайд 5: Графические диаграммы
Изображение слайда
6
Слайд 6: Отношение в блоках
В пределах одной диаграммы:
доминирование;
управление;
выход — вход;
обратная связь по управлению;
обратная связь по входу;
выход – механизм.
Изображение слайда
7
Слайд 7: Отношение в блоках
Изображение слайда
8
Слайд 8: Отношение в блоках
Изображение слайда
9
Слайд 9: Отношение в блоках
Изображение слайда
10
Слайд 10: Отношение в блоках
Изображение слайда
11
Слайд 11: Отношение в блоках
Изображение слайда
12
Слайд 12: Отношение в блоках
Изображение слайда
13
Слайд 13: Отношение в блоках
ICOM — коды, связывающие граничные стрелки этих диаграмм со стрелками их родительских блоков
I (Input)
C (Control)
O (Output)
M (Mechanism)
Изображение слайда
14
Слайд 14: Пример: Строительная фирма
Фирма «М-Строй» осуществляет:
Строительство жилых зданий
Отделку жилых и офисных помещений
Изображение слайда
15
Слайд 15: Пример: Строительная фирма
Перед проектированием, создаются:
В и дение проекта – описываются общие задачи и ограничения, приводится заключение
Модель прецедентов – основные функциональные и нефункциональные требования
Дополнительная спецификация
Словарь терминов и другие
Изображение слайда
16
Слайд 16: Пример: Строительная фирма
Алгоритм выделения задач (требований) системы:
Определить рамки системы: программный комплекс? Аппаратно- программный? Включает в себя своих пользователей?
Определить основных исполнителей
Для исполнителей определить задачи
Изображение слайда
17
Слайд 17: Организационная диаграмма
Строительная Фирма
Бухгалтерия
Отдел кадров
Планово-
экономический
отдел
Отдел
закупок и
продаж
Строительные
площадки
Изображение слайда
18
Слайд 18: Основные исполнители
Исполнители бывают:
Основные – чьи потребности удовлетворяются с помощью системы
Вспомогательные – напрямую не связаны с основной целью (обслуживание БД, администрирование)
Изображение слайда
19
Слайд 19: Пример: Строительная фирма
Основные исполнители:
Руководство (директор) – наблюдение и контроль
Бухгалтер
Бухгалтер-кадровик
Экономист
Оператор склада
Менеджер отдела поставок
Менеджер продаж
Изображение слайда
20
Слайд 20: Организационная диаграмма
Строительная Фирма
Бухгалтерия
Отдел кадров
Планово-
экономический
отдел
Отдел
закупок и
продаж
Строительные
площадки
Изображение слайда
21
Слайд 21: Пример: Строительная фирма
Контекстная диаграмма
Осуществление
строительства, отделки
Строительные
материалы
А-0
СНИП и документация
Готовые здания,
помещения
Сотрудники, рабочие,
оборудование
Изображение слайда
22
Слайд 22: Пример: Строительная фирма
Поиск
заказчиков
А-1
Оформление
договора
А-2
Расчет сметы
А-3
Производство
строительных
работ
А-4
Продажа, сдача
объекта
А-5
заказы
договор
Смета на проведение работ
Строительные материалы
Готовый объект
Прибыль
менеджеры
Юристы бухгалтера
экономисты
Строители,
бригадиры
Изображение слайда
23
Слайд 23: Стрелки, помещенные в «туннель»
Изображение слайда
24
Слайд 24: Слияние и расщепление моделей
При коллективной работе над моделью отдельные фрагменты могут разрабатываться отдельными исследователями – расщепление модели
Изображение слайда
25
Слайд 25: Слияние и расщепление моделей
Признаком включения фрагмента является стрелка вызова
Расчет смет
А-3
Расчет
строительной
сметы
Изображение слайда
26
Слайд 26: Слияние моделей
Имя фрагмента совпадает с именем вызова
Стрелка вызова выходит из функции, которая не декомпозирована
Имя вызывающей функции совпадает с именем контекстной диаграммы фрагмента
Модель фрагмента должна иметь хотя бы одну диаграмму декомпозиции
Расчет смет
А-3
Расчет
строительных
смет
Изображение слайда
27
Слайд 27: Правила построения диаграмм
Изображение слайда
28
Слайд 28: Правила построения диаграмм
Изображение слайда
29
Слайд 29: Правила построения диаграмм
Изображение слайда
30
Слайд 30: Правила построения диаграмм
Изображение слайда
31
Слайд 31: Правила построения диаграмм
Изображение слайда
32
Слайд 32: Правила построения диаграмм
Изображение слайда
33
Слайд 33: Правила построения диаграмм
Изображение слайда
34
Слайд 34: Правила построения диаграмм
Изображение слайда
35
Слайд 35: Перечень узлов
A0 Производить продукт
A1 Планировать производство
А11 Выбрать технологию производства
A12 Оценить требуемое время и затраты на производство
A13 Разработать производственные планы
A14 Разработать план вспомогательных действий
A2 Разрабатывать и управлять графиком выпуска и ресурсами
Изображение слайда
36
Слайд 36: Перечень узлов
Изображение слайда
37
Слайд 37: Перечень узлов
Изображение слайда
38
Слайд 38: Пример диаграммы IDEF0
Изображение слайда
Творческая свобода проектировщика ограничивается :
1) стандартом проектирования БП ;
2) отраслевыми стандартами БП ;
3) ранее принятыми стандартами проектирования БП предприятия ;
4) установочными концепциями.
Изображение слайда
Неоднозначность?
отнести понятие “Распоряжение” или к интерфейсу “Управление”, или к интерфейсу “Вход”?
понятие “расходные материалы” — к “Входу” или “Механизму” при моделировании работы канцелярии?
Изображение слайда
Все “Работы” принадлежат одному классу, т.е. обладают одинаковым набором свойств и поведением.
Все связи между “Работами” относятся к классу “Ресурс”. Например, электронное издание “Налогового кодекса РФ” является общедоступным информационным ресурсом.
Изображение слайда
Классификация ресурсов:
Трансформируемые
Нетрасформируемые
Неизнашиваемые “Ресурсы”.
Изнашиваемые (устаревающие) “Ресурсы”. (инструменты, персонал).
Блокируемые
Не блокируемые
Изображение слайда
Изображение слайда
События?
Исполнение “Работы” безусловно инициируется событием “Поступление Ресурса”.
Необходимым (но не достаточным!) условием завершение “Работы” является свершение полного набора событий “Поступление Ресурса”, связанных с интерфейсами “Работы”.
Изображение слайда
Изображение слайда
46
Последний слайд презентации: IDEF0 моделирование: Литература
Методология функционального моделирования (руководящий документ), ГосСтандарт России, 2001
С.В.Черемных, И.О. Семенов, В.С.Ручкин Структурный анализ систем : IDEF- технологии.
Сергей Рубцов, IDEF 0 и опыт разработки.
Изображение слайда



















Сообщение было отмечено ShaRaKos как решение













































