курсовая 4. Проектирование информационной системы Драматический театр имени А. С. Пушкина

• Название: Проектирование информационной системы Драматический театр имени А. С. Пушкина
• Дата: 04.06.2018
• Размер: 0.83 Mb.
• Имя файла: курсовая 4.docx
• Тип: Курсовая; #45988

ПРИДНЕСТРОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИМ. Т.Г. ШЕВЧЕНКО
Рыбницкий филиал
кафедра прикладной информатики в экономике

Курсовая работа
по дисциплине: «Проектирование информационных систем»

Тема: «Проектирование информационной системы «Драматический театр имени А.С. Пушкина»»

Выполнил:

Корнев Е. С.

студент III курса

направления

«Прикладная информатика в экономике»
Проверил:

профессор Скодорова Л.К.
Рыбница, 2017

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ 5

ГЛАВА 1. ОПРЕДЕЛЕНИЕ И ВНЕДРЕНИЕ CASE-СРЕДСТВ 7

1.1. Описание анализа рынка CASE-средств 7

1.2. Определение критериев успешного внедрения CASE-cредств 8

1.3. Разработка стратегии внедрения CASE-средств 10

ГЛАВА 2. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ 14

2.1. Инструментальная среда AllFusion Process Modeler 14

2.2. Описание предметной области 15

2.3. Методология IDEF0 17

2.4. Методология DFD 19

2.5. Методология IDEF3 21

2.6. Диаграмма дерева узлов 22

2.7. Стоимостной анализ 24

ЗАКЛЮЧЕНИЕ 25

СПИСОК ЛИТЕРАТУРЫ 27

ВВЕДЕНИЕ

Одним из важнейших условий обеспечения эффективного функционирования любой организации является наличие автоматизированной информационной системы (АИС). Под АИС понимают все системы, реализующие автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал.

Создание современных информационных систем представляет собой сложную задачу, решение которой требует применения специальных методик и инструментов. В последнее время среди системных аналитиков и разработчиков значительно вырос интерес к CASE (Computer-AidedSoftware/SystemEngineering) – технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения.

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

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

Целью курсовой работы является проектирование информационной системы «Драматический театр имени А.С. Пушкина».

Для достижения поставленной цели были поставлены следующие задачи:

1. 
   Изучить предметную область «Драматический театр имени А.С. Пушкина».
   
2. 
   Разработать техническое задание для информационной системы «Драматический театр имени А.С. Пушкина».
   
3. 
   Разработать функциональную модель при помощи средств AllFusionProcessModeler.
   

Объектом исследования является драматический театр им. А.С. Пушкина.

Предметом исследования являются бизнес-процессы, проходящие в аппарате управления драматического театра им. А.С. Пушкина.

В первой главе описывается анализ рынка CASE-средств. Определение критериев успешного внедрения. Разработка стратегии внедрения CASE-средств.

Во второй главе представлена разработка функциональной модели драматического театра им. А.С. Пушкина.

ГЛАВА 1. ОПРЕДЕЛЕНИЕ И ВНЕДРЕНИЕ CASE-СРЕДСТВ

1.1. Описание анализа рынка CASE-средств

Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке или собственными возможностями разработки. Исследование рынка проводится путем изучения литературы по CASE-средствам, посещения конференций и семинаров, проводимых поставщиками и пользователями CASE-средств. При проведении данного анализа необходимо выяснить возможность интеграции конкретного CASE-средства с другими средствами, используемыми (или планируемыми к использованию) организацией. Кроме того, важно получить достоверную информацию о средствах, основанную на реальном пользовательском опыте и сведениях от пользовательских групп [8, стр. 34].

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

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

Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также различными стандартами. В центре внимания этих подходов находится анализ различных аспектов происходящих в организации процессов [7, стр. 56].

Для получения информации относительно положения и потребностей организации могут использовать неформальные оценки и анкетирование. Это поможет определить те области, где автоматизация может принести эффект. В противном случае может оказаться, что совершенствование процесса разработки и сопровождения ПО, программ обучения и других функций более предпочтительно, чем приобретение новых средств. Некоторые из этих усовершенствований могут оказаться необходимыми для получения максимальной выгоды от внедрения любых CASE-средств.

Организационные потребности следуют непосредственно из проблем организации и целей, которые она стремится достичь. Проблемы и цели могут быть связаны с управлением, производством продукции, экономикой, персоналом или технологией. Определение потребностей должно выполняться в сочетании с обзором рынка CASE-средств, поскольку информация о технологиях, доступных на рынке в данный момент, может оказать влияние на потребности [8, стр. 21].

1.2. Определение критериев успешного внедрения CASE-cредств

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

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

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

Как правило, большинство организаций осуществляет внедрение CASE-средств для того, чтобы повысить продуктивность процессов разработки и сопровождения ПО, а также качество результатов разработки. Процесс успешного внедрения CASE-средств не ограничивается только их использованием. На самом деле он охватывает планирование и реализацию множества технических, организационных, структурных процессов, изменений в общей культуре организации, и основан на четком понимании возможностей CASE-средств. Однако, ряд организаций не занимаются и не занимались ранее сбором количественных данных по указанным параметрам. Отсутствие таких данных затрудняет количественную оценку воздействия, оказываемого внедрением CASE-средств. В этом случае рекомендуется разработка соответствующих метрик. В том случае, если базовые метрические данные отсутствуют, организация зачастую может извлечь полезную информацию из своих проектных архивов [9, стр.12].

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

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

1.3. Разработка стратегии внедрения CASE-средств

Стратегия внедрения должна обеспечивать удовлетворение потребностей и критериев, определенных ранее. Стратегия включает следующие составляющие:

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

Существует несколько подходов к разработке стратегии внедрения CASE-средств: нисходящий и восходящий. Относительные преимущества того или иного подхода перед другими должны рассматриваться в контексте специфики конкретной организации. Особое значение при этом придается персоналу организации и процессу разработки программного обеспечения (ПО).

Преимущество нисходящего подхода заключается в том, что он охватывает все процессы создания и сопровождения ПО, обеспечивая максимально возможную их автоматизацию. Другим преимуществом является приобретение интегрированного (или интегрируемого) набора средств, поскольку каждая отдельная поставка подчиняется общей стратегии. Нисходящий подход также может быть легко интегрирован в общую стратегию развития процесса создания и сопровождения ПО, в которой внедрение CASE-средств является только одним из аспектов [10].

Недостатки данного подхода заключаются в следующем:

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

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

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

• 
  небольшая автоматизация может быть выполнена при минимальных затратах;
  

• 
  автоматизация может быть выполнена за короткий промежуток времени, позволяя быстро устранить известные недостатки в существующих процессах;
  

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

Недостатки восходящего подхода заключаются в следующем:

• 
  средства, приобретаемые как результат отдельных взятых применений данного подхода, могут плохо интегрироваться между собой. Это может привести к необходимости выполнения большого объема ручной работы;
  
• 
  в то время как конкретные, сравнительно небольшие проблемы решаются достаточно быстро, до решения фундаментальных проблем, связанных с широким кругом процессов разработки ПО, дело обычно не доходит [11].
  

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

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

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

ГЛАВА 2. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ

2.1. Инструментальная среда AllFusion Process Modeler

AllFusion Process Modeler является инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. AllFusion Process Modeler предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Он предназначен для поддержки процесса создания информационных систем. Относится к категории CASE средств верхнего уровня.

Процесс построения информационной модели в AllFusion Process Modeler состоит из следующих шагов:

• 
  построить контекстную диаграмму;
  
• 
  провести функциональную декомпозицию;
  
• 
  после каждого сеанса декомпозиции провести сеанс экспертизы.
  

Функциональность AllFusion Process Modeler заключается не только в рисования диаграмм, но и в проверке целостности и согласованности модели. CASE-средство обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании, таких, как «зависание» связей при переходе от диаграммы к диаграмме, нарушение ассоциации связей в различных диаграммах модели и т.п. Кроме того, AllFusion Process Modeler поддерживает пользовательские свойства, которые применяются к элементамдиаграммы для описания специфических свойств, присущих данному элементу [8, стр. 17].

AllFusion Process Modeler поддерживает три методологии моделирования:

• 
  функциональное моделирование (IDEF0);
  
• 
  описание бизнес-процессов (IDEF3);
  
• 
  диаграммы потоков данных (DFD).
  

В зависимости от выбранной методологии программой автоматически подбирается нужная панель инструментов. Существует три разных панели инструментов – по числу поддерживаемых программой методологий.

2.2. Описание предметной области

Информационная система «Драматического театра имени А.С. Пушкина» предназначена для автоматизации работы аппарата управления театра. Театр занимается созданием и демонстрацией творческих представлений для посетителей. Для посещения театрального представления необходимо приобрести билет на любое из представленных театральных постановок. Выдачей билета занимается билетная касса, которая передаёт отчётную документацию в бухгалтерию.

В состав театра входит:

• 
  генеральный директор театра;
  
• 
  администрация;
  
• 
  отдел кадров;
  
• 
  бухгалтерия;
  
• 
  инженерный отдел;
  
• 
  художественный отдел.
  

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

Отдел кадров занимается управлением персонала в театре. Отдел кадров выполняет следующие функции:

• 
  введет электронную базу сотрудников туристической фирмы;
  
• 
  учет личного состава;
  
• 
  оформление и увольнение сотрудников;
  
• 
  оформление и ведение трудовой книжки;
  
• 
  работа с личными делами сотрудников;
  

Бухгалтерия занимается ведением и хранением документации, связанной с финансовой деятельностью театра. Помимо основного бухгалтерского учета, предоставляется поквартальная отчетность. Бухгалтерия начисляет заработную плату для каждого работника индивидуально, в зависимости от его должности и квалификации. В отдел бухгалтерии входит главный бухгалтер, бухгалтер и кассир. Главный бухгалтер ведёт финансовую отчётность театра, следит за работой бухгалтеров, контролирует выплату заработной платы. Бухгалтер занимается ведением отчётной документации по отдельным категориям, а также занимается выдачей заработных плат. Кассир занимается продажей билетов, ведением отчётной документации о полученных денежных средств от продажи билетов.

Инженерный отдел занимается созданием чертежей под будущие декорации, расстановкой и обслуживанием светового оборудования, и проверкой работоспособности всего оборудования и реквизита, в том числе самой сцены.

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

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

В методологии IDEF0 система представляется как совокупность взаимодействующих работ или функций. Функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в методологии IDEF0 понимают описание системы, которое должно дать ответ на некоторые заранее определенные вопросы [8, стр. 34].

Первым этапом проектирования в методологии IDEF0 является создание контекстной диаграммы – общее описание системы, а также взаимодействие системы с окружающей средой (рис 1).

Рис. 1. Контекстная диаграмма ИС «Драматический театр им. А.С. Пушкина»

На контекстной диаграмме представлены 4 типа стрелок:

• 
  Вход(Input) − материал или информация, которые используются или преобразуются работой для получения результата (выхода). Входом в систему являются «Заявления на приобретение билета», «Новые сотрудники», «Денежные средства».
  
• 
  Управление(Control) − правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Управление осуществляется на основе «Законов», «Нормативной документации театров» и «КЗоТов».
  
• 
  Выход(Output) − материал или информация, которые производятся работой. Результатом деятельности театра являются «Уволенные сотрудники», «Отчетная документация», «Уволенные сотрудники», «Посетители», «Налоги».
  
• 
  Механизм(Mechanism) − ресурсы, которые выполняют работу. Механизмом системы являются «Материально-технические ресурсы» и «Человеческие ресурсы».
  

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

На диаграмме декомпозиции первого уровня представлены следующие работы: «Администрация», «Отдел кадров», «Бухгалтерия», «Инженерный отдел», «Художественный отдел», «Театральная постановка». Входом данной диаграммы являются: «Новые сотрудники», «Заявления на приобретение билета от посетителей», «Денежные средства», на выходе – «Уволенные сотрудники», «Налоги», «Денежные средства», «Посетители», «Отчётная документация». В качестве управления выступают «Законы» и «Нормативная документация», «КЗоТы», а в качестве механизмов – «Человеческие ресурсы» и «Материально-технические ресурсы». Кроме обычных стрелок на диаграмме присутствуют специальные стрелки, которые называются «туннелированными стрелками» («Решение вопросов» и «Оформление документов»).

Рис. 2. Диаграмма декомпозиции первого уровня
Следующим этапом создана диаграмма декомпозиций второго уровня работы «Бухгалтерия», на данной диаграмме представлены все процессы, протекающие в бухгалтерии (рис. 3). На данной диаграмме декомпозиции представлены следующие работы: «Главный бухгалтер», «Бухгалтер», «Касса». На входе данной диаграммы находится «Новые сотрудники», «Заявления на приобретение билета от посетителей», «Денежные средства», на выходе – «Формирование документации о налогах», «Денежные средства, «Отчётная документация», «Выплата заработных плат», «Зарегистрированный билет». В качестве управления выступают «Законы» и «Нормативная документация», «КЗоТы», «Приказы и распоряжения», а в качестве механизмов – «Человеческие ресурсы» и «Материально-технические ресурсы».
Рис. 3. Диаграмма декомпозиции второго уровня
В результате работы созданы диаграммы декомпозиций первого и второго уровня. Диаграмма декомпозиций первого уровня описывает работу административно-управленческого комплекса драматического театра им. А.С. Пушкина. Диаграмма декомпозиций второго уровня описывает работу бухгалтерии театра.

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

Диаграммы потоков данных (Data Flow Diagramming) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота.

Диаграмма DFD описывает [8, стр. 54]:

• 
  функции обработки информации (работы);
  
• 
  документы (стрелки, arrow), объекты, сотрудников или отделы, которые учувствуют в обработке информации;
  
• 
  внешние ссылки (externalreferences), обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
  
• 
  таблицы для хранения документов (хранилище данных, datastore).
  

Созданная диаграмма потоков данных (рис. 4), показывает документооборот и обработку информации в процессе принятия на работу нового сотрудника в театр. В роли работ, то есть функции системы выступают: «Анкетные данные сотрудника», «Кадровый приказ по штату сотрудников», «Статистическая отчётность по штату сотрудников».


Рис. 4. Диаграмма потоков данных при приёме на работу
В качестве внешних сущностей, входы в систему и/или выходы из системы, представлены «Физическое лицо» и «Бухгалтерия». Кроме работ и внешних сущностей на диаграмме представлены хранилища данных, которые представлены в виде «Журнал приказов», «Список сотрудников», а также потоки данных протекающих между работами.

Процесс приёма нового сотрудника начинается с того момента, когда «Физическое лицо» подает резюме и предоставляет личные данные. Затем представленные личные данные записываются в «Анкетные данные сотрудника», а также составляется «Кадровый приказ по штату сотрудников». После издания «Приказа» и его регистрации в «Журнале приказов», кадровый приказ отправляется в «Бухгалтерию». Из «Анкетных данных сотружника» информация о сотрудниках отправляется в «Бухгалтерию» и в «Статистическую отчётность по штату сотрудников», также в статистическую отчётность отправляются сведения о кадровых перестановках и статусе сотрудника из «Журнала приказов». Далееформируется отчёт, содержащий вышеперечисленные данные и отправляется в «Бухгалтерию».

2.5. Методология IDEF3

Методология IDEF3 – способ описания процессов с использованием структурированного метода, позволяющего эксперту в предметной области представить положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время [8, стр. 71].

С помощью методологии IDEF3 построена диаграмма, которая описывает события, происходящие при покупке и выдаче билета на театральную постановку (рис. 5).


Рис. 5. Процесс покупки и выдачи билета
На диаграмме представлены следующие объекты:

• 
  один объект ссылки, с названием «Посетитель», он указывает на начало процесса покупки билета;
  
• 
  семь объектов работ: «Поступление заявления», «Получение информации», «Заполнение формы билета», «Приём денежных средств», «Распечатка чека», «Распечатка билета», «Выдача чека и билета;
  
• 
  объекты перекрёстка, типа: «асинхронного или», которые показывают, что все предшествующие процессы должны быть завершены, а все следующие процессы должны быть запущены.
  

2.6. Диаграмма дерева узлов

Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно.

В результате проектирования сформирована полная функциональная модель с глубиной проработки до уровня действий кассира, отображающая функциональную структуру объекта (ИС «Драматический театр имени А.С. Пушкина»), т. е. производимые им действия и связи между ними.


Рис. 6. Диаграмма дерева узлов ИС «Драматический театр им. А.С. Пушкина»
На диаграмме дерева узлов показана контекстная диаграмма, диаграмма декомпозиции первого уровня: «Администрация», «Отдел кадров», «Бухгалтерия», «Инженерный отдел», «Художественный отдел», «Театральную постановку». Диаграммы декомпозиции второго уровня: «Главный бухгалтер», «Бухгалтер», «Касса» (рис. 6). Диаграммы декомпозиции третьего уровня: «Поступление заявления», «Получение информации», «Заполнение формы билета», «Распечатка билета», «Распечатка чека», «Приём денежных средств», «Выдача чека и билета».

В ходе курсовой работы также сделаны диаграммы декомпозиции работы «Администрация», и диаграммы описывающие бизнес-процессы в работах «Инженерный отдел», «Художественный отдел» и «Бухгалтерия» (Приложение).

2.7. Стоимостной анализ

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

Для проведения стоимостного анализа в список центра затрат были введены:

• 
  затраты на управление;
  
• 
  затраты на оплату рабочих;
  
• 
  затраты на закупку компонентов.
  

После проведения стоимостного анализа оформили отчет (таблица 1), который показывает затраты по каждому блоку, которые необходимы для функционирования деятельности «Театра». Кроме того, в отчете присутствуют три вида затрат, для каждой из работ: «Компоненты», «Рабочая сила» и «Управление».
Таблица 1

Стоимостной анализ

Activity Number	Activity Name	Activity Cost (руб.)	Cost Center	Cost Center Cost (Руб.)
0	Московский драматический театр имени А.С. Пушкина	107125,00	Компоненты Рабочая сила Управление	31625,00 42500,00 33000,00
1	Театр	107125,00	Компоненты Рабочая сила Управление	31625,00 42500,00 33000,00
11	Администрация	6300,00	Компоненты Управление	700,00 5600,00
12	Отдел кадров	2200,00	Компоненты Рабочая сила	700,00 1500,00
121	Кадровый приказ по штату сотрудников	0,00
123	Анкетные данные сотрудника	0,00
125	Статистическая отчётность по штату сотрудников	0,00
13	Бухгалтерия	15625,00	Компоненты Рабочая сила Управление	6125,00 4500,00 5000,00
131	Главный бухгалтер	1500,00	Компоненты Управление	500,00 1000,00
132	Бухгалтер	750,00	Компоненты Рабочая сила	500,00 250,00
133	Касса		Компоненты Рабочая сила	1125,00 3,250,00
1	Поступление заявления	0,00
2	Получение информации	0,00
3	Заполнение формы билета	125,00	Компоненты Рабочая сила	25,00 100,00
6	Распечатка билета	250,00	Компоненты Рабочая сила	100,00 150,00
5	Распечатка чека	250,00	Компоненты Рабочая сила	100,00 150,00
4	Приём денежных средств	125,00	Рабочая сила	125,00
7	Выдача чека и билета	125,00	Рабочая сила	125,00
14	Инженерный отдел	2200,00	Компоненты Рабочая сила	700,00 1500,00
15	Художественный отдел	3600,00	Компоненты Рабочая сила	2000,00 1600,00
16	Театральная постановка	4000,00	Компоненты Рабочая сила	1000,00 3000,00

ЗАКЛЮЧЕНИЕ

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

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

В результате выполнения работы была достигнута цель – построена информационная система «Драматический театр имени А.С. Пушкина».

На стадии исследования и проектирования была изучена предметная область информационной системы «Драматический театр имени А.С. Пушкина», с помощь CASE-средства AllFusion Process Modeller смоделированы взаимодействия всех основных объектов театра, информационные потоки между ними.

В ходе курсовой работы проведён стоимостной анализ. Исходя из его показателей, выяснилось, что стоимость проекта составляет 107125 тысяч рублей РФ, за эксплуатацию в день.

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

СПИСОК ЛИТЕРАТУРЫ

1. 
   ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированной системы.
   
2. 
   ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.
   
3. 
   ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
   
4. 
   ГОСТ Р 50646-2012 Услуги населению.
   
5. 
   ГОСТ Р 50460-92. Знак соответствия при обязательной сертификации. Форма, размеры и технические требования.
   
6. 
   ГОСТ Р 50646-94. Услуги населению. Термины и определения.
   
7. 
   Федоров Н.В. Проектирование информационных систем на основе современных CASE-технологий. – М.: МГИУ, 2008.
   
8. 
   Скодорова Л.К., Константинова Ю.С. Проектирование информационных систем – Тирасполь, 2011.
   
9. 
   Скодорова Л.К., Пападюк К.Н., Проектирование в информационных систем в среде AllFusion Process Modeler. – Рыбница, 2017.
   
10. 
    http://citforum.ru/
    
11. 
    https://studopedia.ru
    
12. 
    http://www.myshared.ru
    

ПРИЛОЖЕНИЕ


Рис. 1 Процесс создания чертежей для декораций



Рис. 2 Процесс создания театральной постановки

Рис. 3 Диаграмма декомпозиций второго уровня работы «Администрация»


Рис. 4 Процесс приёма ТМЦ