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

АктерыДиректор по проектам / АрхитекторПредусловияФормированный и согласованный «Устав проекта»ОсновнойПотокДиректор по проектам / Архитектор находит карточку уже созданного варианта технического задания;Директор по проектам / Архитектор нажимает на кнопку «Заполнить следующий раздел» на панели инструментов.Директор по проектам / Архитектор выбирает раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие». Система выводит форму «Функциональная структура. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие». Директор по проектам / Архитектор проверяет шаблон документа и при необходимости вводит недостающие данные.Директор по проектам / Архитектор сохраняет раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие».ПостусловияЕсли прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.Описание деятельности для прецедента «Заполнить раздел «Требования к документированию»» представлено в таблице 14.Таблица 14Описание деятельности для прецедента «Заполнить раздел «Требования к документированию»»Краткое описаниеПрецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Требования к документированию».АктерыРуководитель проектаПредусловияЗаполненный шаблон «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»ОсновнойПотокРуководитель проекта находит карточку уже созданного варианта технического задания;Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов.Руководитель проекта выбирает раздел «Требования к документированию». Система выводит форму «Функциональная структура.Требования к документированию». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Требования к документированию». ПостусловияЕсли прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.Описание деятельности для прецедента «Заполнить раздел «Источники разработки»» представлено в таблице 15.Таблица 15Описание деятельности для прецедента «Заполнить раздел «Источники разработки»»Краткое описаниеПрецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Источники разработки».АктерыРуководитель проектаПредусловияЗаполненный шаблон «Требования к документированию».ОсновнойПотокРуководитель проекта находит карточку уже созданного варианта технического задания;Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов.Руководитель проекта выбирает раздел «Источники разработки». Система выводит форму «Функциональная структура. Источники разработки». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Источники разработки». ПостусловияЕсли прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.Построение диаграмм последовательностейОписание взаимодействия между проектируемой автоматизированной системы и действующими субъектами выполняются с помощью диаграмм последовательности:Описание последовательности для прецедента «Заполнить раздел технического задания «Общие сведения»»представлено на рисунке 8.Рис. 8. Диаграмма последовательности для прецедента «Заполнить раздел«Общие сведения»»Описание последовательности для прецедента «Заполнить раздел «Назначения и цели создания (развития) системы»» представлено на рисунке 9.Рис. 9. Диаграмма последовательности для прецедента «Назначения и цели создания (развития) системы»»Описание последовательности для прецедента «Заполнить раздел «Характеристики объекта автоматизации»» представлено на рисунке 10.Рис. 10. Диаграмма последовательности для прецедента «Характеристики объекта автоматизации»»Описание последовательности для прецедента «Заполнить раздел «Требования к системе в целом»» представлено на рисунке 11.Рис. 11. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к системе в целом»»Описание последовательности для прецедента «Заполнить раздел «Требования к видам обеспечения»» представлено на рисунке 12.Рис. 12. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к видам обеспечения»»Описание последовательности для прецедента «Заполнить раздел «Требования к функциям (задачам), выполняемым системой»» представлено на рисунке 13.Рис. 13. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к функциям (задачам), выполняемым системой»»Описание последовательности для прецедента «Заполнить раздел «Состав и содержание работ по созданию системы»» представлено на рисунке 14.Рис. 14. Диаграмма последовательности для прецедента «Заполнить раздел «Состав и содержание работ по созданию системы»»Описание последовательности для прецедента «Заполнить раздел «Порядок контроля и приемки системы»» представлено на рисунке15.Рис. 15. Диаграмма последовательности для прецедента «Заполнить раздел «Порядок контроля и приемки системы»»Описание последовательности для прецедента «Заполнить раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»» представлено на рисунке16.Рис. 16. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»»Описание последовательности для прецедента «Заполнить раздел «Требования к документированию»» представлено на рисунке 17.Рис. 17. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к документированию»»Описание последовательности для прецедента «Заполнить раздел «Источники разработки»» представлено на рисунке 18.Рис. 18. Диаграмма последовательности для прецедента «Заполнить раздел «Источники разработки»»Построение экранных формКаждый раздел технического задания после разработки должен полностью соответствовать описанию и содержать соответствующий набор реквизитов.Форма раздела «Общие сведения» представлена на рисунке 19.Рис. 19. Форма раздела «Общие сведения»Форма раздела «Назначения и цели создания (развития) системы» представлена на рисунке 20.Рис.20. Форма раздела «Назначения и цели создания (развития) системы»Форма раздела «Характеристика объектов автоматизации» представлена на рисунке 21.Рис. 21. Форма раздела «Характеристика объектов автоматизации»Форма раздела «Требования к системе» представлена на рисунке 22.Рис. 22. Форма раздела «Требования к системе»Форма раздела «Состав и содержание работ по созданию системы» представлена на рисунке 23.Рис. 23. Форма раздела «Состав и содержание работ по созданию системы»Форма раздела «Порядок контроля и приемки системы» представлена на рисунке 24.Рис. 24. Форма раздела «Порядок контроля и приемки системы»Форма раздела «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» представлена на рисунке 25.Рис. 25. Форма раздела «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»Форма раздела «Требования к документированию» представлена на рисунке 26.Рис. 26. Форма раздела «Требования к документированию»Форма раздела «Источники разработки» представлена на рисунке 27.Рис. 27. Форма раздела «Назначения и цели создания (развития) системы»Архитектура автоматизированной системыАрхитектура проектируемой автоматизированной системы отвечает структуре объекта автоматизации. Предполагаются следующие требования на оборудование:Общие:Стабильное интернет-соединение со скоростью не менее 256 Кбит/с;Возможность удаленного подключения.Для сервера приложения:256 МБ ОЗУ (рекомендуется 512 МБ и более ОЗУ);440 МБ свободного дискового пространства;Pentium-совместимый компьютер (рекомендуется Pentium III, IV либо AMD Athlon).Для сервера системы:512 МБ ОЗУ (рекомендуется 1 ГБ и более ОЗУ)Минимум 6 ГБ свободного дискового пространствапроцессор x64: 1,4 ГГц, процессор x86: 1,0 ГГц (рекомендуется 2,0 ГГц и выше)процессор x64: AMD Opteron, AMD Athlon 64, Intel Xeon с поддержкой Intel EM64T, Intel Pentium IV с поддержкой EM64T. Процессор x86: Процессор, совместимый с Pentium III либо выше возможность удаленного подключения.При создании будут применены следующие средства и технологии:Объектно-ориентированный дизайн и проектирование.Язык 1С для визуализации и обработки данных:скорость разработки – языка 1С позволяет стартовать разработку быстрее, а это позволяет быстрее получить прототип решения;компиляция в нативный код серверной платформы обеспечивает наилучшую производительность;огромное количество библиотек идет в базе, плюс к ним множество свободно доступных библиотек, это покрывает практически все первостепенные задачи разработки;стоимость поддержки – приложения, формированные на языке 1С, т.к. фирма франчайзи;удобство сборки проектов.1С:наиболее удобное средство для разработки кода на русском языке;команда разработчиков и постановщиков привыкла к данному продукту.MS SQL:простота применения;интеграция с другими продуктами Microsoft – электронные таблицы, графика и сводные таблицы могут быть напрямую связаны с SQL Server либо службами, что предоставляет пользователям возможности просмотра и анализа данных с помощью обозревателя.В основе текущей автоматизированной системы лежит трехзвенная клиент-серверная архитектура, которая представлена на рисунке 28.Рис. 28. Архитектура автоматизированной системы**Сост. по источнику: http://www.4stud.info/networking/lecture5.htmlОписанная архитектура позволяет:Представить данные — на стороне клиента, взаимодействие будет осуществляться через веб-интерфейс, режим толстого либо тонкого клиента.Прикладной компонент — на выделенном сервере приложений располагается разрабатываемая система.Управлять ресурсами — на сервере БД, который и представляет запрашиваемые данные.Трехзвенная архитектура сложнее, но благодаря тому, что функции распределены между серверами второго и третьего уровня, эта архитектура представляет:высокую степень гибкости и масштабируемости;высокую безопасность (т.к. защиту можно определить для каждого сервиса либо уровня);высокую производительность (т.к. задачи распределены между серверами) [http://www.4stud.info/networking/lecture5.html].Архитектура базы данныхПроектирование базы данных начнем с построения концептуальной модели базы данных. Концептуальная модельвключает в себяhttps://www.site-do.ru/db/db4.php:Описание предметной области и настройки связи между информационными объектами;Описание ограничений и требованиям к данным.Построив концептуальную модель и описав требования к данным, мы тем самым обеспечиваем целостность данных, а также сокращаемизбыточность и их дублирование. Концептуальная схема базы данных представлена на рисунке 29.Рис. 29. Концептуальная схема базы данныхКонцептуальная модель показывает, что существует один объект – техническое задание, который состоит из нескольких разделов, каждый раздел включает в себя некоторое количество полей. В свою очередь для заполнения каждого поля потребуется информация, которая храниться в базе данных в виде соответствующих источников. Источники базы данных – это некие справочники, регистры сведений, регистры накоплений и шаблоны.Источники базы данных проектируемой автоматизированной системыобобщенно содержат в себе следующую информацию:Данные об организации;Данные о контрагентах;Компоненты сервиса;Шифры проектов;Виды технической документации;Сроки ведения этапов проектов;Этапы проекта;Формы оплаты;Вид оплаты;Графики оплаты;Валюты;Виды автоматизируемой деятельности;Цели автоматизации;Объекты автоматизации;Критерии оценки достижения целей;Требования к системе в целом;Требования к видам обеспечения;Функциональные требования;Виды и порядок проведения экспертизы;Виды работ по метрологическому обеспечению;Объёмы проверяемой документации;Сроки выполнения работ по метрологическому обеспечению;Виды испытаний;Состав и объем испытаний;Методы испытаний;Данные о приемочной комиссии;Статусы приемочной комиссии;Соответствие испытаний нормам разрабатываемой системы;Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;Требования к документированию;Присоединенные файлы.Все данные, хранящиеся в базе данных, представлены в виде таблицы16.В этой же таблице прописан тип данных, с обязательным указанием ограничений. Таблица 16Данные для храненияНаименование хранящихся данныхТип данныхОграниченияТехнические заданияШифры проектаПеречисление ОтсутствуетКонтрагентПеречисление ОтсутствуетОписаниеСтрока2000 символовИнформация об организацииВид организацииПеречисление ОтсутствуетПолное наименованиеСтрока250 символовСокращенное наименованиеСтрока250 символовИННСтрока12 символовКППСтрока9 символовЮридический адресСтрока500 символовФактический адресСтрока500 символовПочтовый адресСтрока500 символовТелефонСтрока20 символовФаксСтрока20 символовЭлектронная почтаСтрока100 символовИнформация о контрагентахВид организацииПеречислениеОтсутствуетПолное наименованиеСтрока250 символовСокращенное наименованиеСтрока250 символовИННСтрока12 символовКППСтрока9 символовЮридический адресСтрока500 символовФактический адресСтрока500 символовПочтовый адресСтрока500 символовТелефонСтрока20 символовФаксСтрока20 символовЭлектронная почтаСтрока100 символовКонтактные лицаПеречислениеОтсутствуетДолжности контактных лицПеречислениеОтсутствуетКонтактные лицаФамилияСтрока50 символовИмяСтрока50 символовОтчествоСтрока50 символовДолжности контактных лицПеречислениеОтсутствуетДокумент-основаниеСтрока50 символовДата документа-основанияСтрока100 символовСрок действия документа-основания (в месяцах)Число2 символаДолжности контактных лицНаименование должностиСтрока100 символовВалютыНаименование валютыСтрока50 символовЦифровой кодЧисло10 символовСимвольный кодСтрока200 символовКомпоненты сервисаГруппа спискаСтрока250 символовНаименование компонентаСтрока250 символовВиды технической документацииНаименование технического документаСтрока250 символовПрисоединенные файлыСсылкаДо 256 МгЭтапы проектаНаименование этапаСтрока250 символовВид оплатыНаименование вида оплатыСтрока250 символовШифры проектовШифр проектаСтрока19 символовКонтрагентПеречислениеОтсутствуетСроки ведения этапов проектовЭтапы проектаПеречислениеОтсутствуетПериод ведения этапа (в месяцах)Число2 символаДата начала работДатаОтсутствуетДата окончания работДатаОтсутствуетГрафики оплатыЭтапы проектаПеречислениеОтсутствуетФормы оплатыПеречислениеОтсутствуетВид оплатыПеречислениеОтсутствуетВалюта расчетовПеречислениеОтсутствуетДата платежаДатаОтсутствуетВиды автоматизируемой деятельностиНаименование вида деятельностиСтрока250 символовЦели автоматизацииКомпонент сервисаПеречислениеОтсутствуетНаименование цели автоматизацииСтрока2000 символовОбъекты автоматизацииКонтрагентыПеречислениеОтсутствуетКритерии оценки достижения целейНаименование критериев оценкиСтрока500 символовТребования к системе в целомГруппа требованийСтрока250 символовНаименование требованияСтрока500 символовОписание требованияСтрокаОтсутствуетТребования к видам обеспеченияНаименование требованияСтрока500 символовОписание требованияСтрокаОтсутствуетФункциональные требованияКомпонент сервисаПеречислениеОтсутствуетНаименование требованияСтрока500 символовОписание требованияСтрокаОтсутствуетВиды и порядок проведения экспертизыЭтапы проектаПеречислениеОтсутствуетНаименование вида экспертизыСтрока500 символовОбъемы проверяемой документацииПеречислениеОтсутствуетКонтрагентыПеречислениеОтсутствуетВиды и порядок проведения экспертизыЭтапы проектаПеречислениеОтсутствуетНаименование вида работСтрока500 символовСроки выполнения работ по метрологическому обеспечениюПеречислениеОтсутствуетКонтрагентыПеречислениеОтсутствуетОбъемы проверяемой документацииВиды технической документацииПеречислениеОтсутствуетОбъем проверяемой документации (в страницах)Число4 символаСроки выполнения работ по метрологическому обеспечениюВиды работ по метрологическому обеспечениюПеречислениеОтсутствуетПериод выполнения работСтрока500 символовДата начала работДатаОтсутствуетДата окончания работДатаОтсутствуетВиды испытанийЭтапы проектаПеречислениеОтсутствуетКомпоненты сервисаПеречислениеОтсутствуетНаименование вида испытанийСтрока500 символовМетоды испытанийЭтапы проектаПеречислениеОтсутствуетНаименование вида испытанийСтрока500 символовПриемочные комиссииДокумент-основаниеСтрока250 символовДата документа-основанияДатаОтсутствуетКонтрагентыПеречислениеОтсутствуетКонтактные лицаПеречислениеОтсутствуетДолжности контактных лицПеречислениеОтсутствуетСтатусы и утверждение приемочных комиссийПриемочные комиссииПеречислениеОтсутствуетСтатус приемочной комиссииПеречислениеОтсутствуетДата утверждения приемочной комиссииДатаОтсутствуетДата окончания действия приемочной комиссииДатаОтсутствуетСтатусы приемочных комиссийВиды статусов приемочной комиссииСтрока50 символовСоответствие испытаний нормам разрабатываемой системыКомпоненты сервисаПеречислениеОтсутствуетВиды испытанийПеречислениеОтсутствуетНоры разрабатываемой системыПеречислениеОтсутствуетПризнак соответствияБулевоИстина / ЛожьНормы разрабатываемой системыКомпоненты сервисаПеречислениеОтсутствуетНаименование нормы разрабатываемой системыПеречислениеОтсутствуетТребования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действиеНаименование требованияСтрока500 символовОписание требованияСтрокаОтсутствуетТребования к документированиюНаименование требованияСтрока500 символовОписание требованияСтрокаОтсутствуетПрисоединенные файлыВиды технической документацииПеречислениеОтсутствуетОписание файлаСтрока2000 символовПроведя этап построения концептуальной модели базы данных, описания структуры этих данных, с обязательным указанием типа и ограничений в применении, необходимо перейти к этапу построения логической модели базы данных.Для построения логической схемы базы данных воспользуемся набором схем отношений, в которых будут указаны ключевые атрибуты, а также показаны связи между этими отношениями [https://ru.wikipedia.org/wiki/Схема_базы_данных].Логическая схема базы данных представлена на рисунке 30.Рис. 30. Логическая схема базы данных Согласно построенной логистической модели базы данных можно сказать следующее, что связь «Один ко многим» работает только для следующих сущностей:Техническое задание;Разделы технического задания. Факт отнесения сущностей к связи «Один ко многим» зависит от того, что техническое задание содержит в себе несколько разделов, в свою очередь, каждый раздел технического задания содержит в себе множество полей, которые требуется заполнить.Связь «Один к одному» работает для следующих сущностей:Поля технического задания;Описанные источники данных, такие как:Справочники;Регистры сведений;Регистры накопления;Шаблоны.Факт отнесения сущностей к связи «Один к одному» зависит от того, что поля технического задания, как правило, содержат в себе информацию одного источника данных. ЗаключениеВ настоящей работе выполнено проектирование автоматизированной системы для автоматического формирования функциональной структуры, нацеленного на автоматизацию учета на конкретном предприятии.Для достижения поставленной цели был проведен анализ предметной области, построена модель AS-IS и определены ее недостатки. Также были проанализированы имеющиеся информационные системы, посредством которых можно создать техническое задание. В результате анализа был сделан вывод о том, что существующие в данной предметной области аналоги имеют достаточно полный состав выполняемых функций, однако также имеют и определенные недостатки. В рамках данной работы описаны требования к создаваемой системе, работа ключевых пользователей в системе, источники данных, благодаря которым можно автоматически заполнить разделы технического задания.Проектируемая в рамках курсовой работы информационная система, основана на коде программного продукта фирмы 1С, так как их язык обладает наибольшим количеством положительных характеристик.В процессе проектирования была построена диаграмма и сценарии вариантов применения, согласно данным ролевой модели. Построены графика последовательностей, экранные формы для заполнения каждого разделаюНа основе сделанных выводов были построены модели TO-BE в нотации UML, описывающие объекты и процессы в рассматриваемой системе, спроектирована архитектуракомпании в целом, а также архитектура базы данных. При построении архитектуры базы данных были построены концептуальная и логическая модели базы данных, описана структура данных, требования к ним и ограничения в применении.Список использованной литературыГОСТ 34.602-89. Функциональная структура на создание автоматизированной системыКомпоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов [Электронный ресурс], – http://www.4stud.info/networking/lecture5.html – статья в интернете.Проектирование информационных систем [Электронный ресурс], – https://www.intuit.ru/studies/courses/2195/55/lecture/15050?page=2 – статья в интернете.Программа мастер технических заданий [Электронный ресурс], – http://www.freetz.ru/master-tz/– статья в интернете.Инструменты фрилансера [Электронный ресурс], – http://freelancers-tools.com/?p=1728 – статья в интернете.SoftLine [Электронный ресурс] - https://softline.ru/about/news/4926 - статья в интернете.Ресурсы для технических писателей от Adobe [Электронный ресурс] - https://compress.ru/article.aspx?id=18799#Adobe%20RoboHelp%207 - статья в интернете.Автоматизация документирования для разработки [Электронный ресурс] - http://authorit.ru - статья в интернете.Схема базы данных [Электронный ресурс] - https://ru.wikipedia.org/wiki/Схема_базы_данныхКонцептуальная модель базы данных [Электронный ресурс] - https://www.site-do.ru/db/db4.php - статья в интернете.Boruvka O., O jistem problemu minimalnım (About a Certain Minimal Problem), Prace mor. prırodoved. spol. v Brne, III, (2018), 37–58.Frederickson G. N., Data structures for on-line updating of minimum spanning trees, SIAM J. Comput. 14 (2017), 781–798.Fredman M., Willard D. E., Trans-dichotomous algorithms for minimum spanning trees and shortest paths, In Proceedings of FOCS’90 (2016), 719–725. Graham R. L., Hell P., On the history of the minimum spanning tree problem, Ann. Hist. Comput. 7 (2015), 43–57. Chazelle B., A Minimum Spanning Tree Algorithm with Inverse-Ackermann Type Complexity, J. ACM 47 (2018), 1028–1047. Karger D. R., Klein, P. N., Tarjan R. E., Linear expected-time algorithms for connectivity problems, J. ACM 42 (2015), 321–328. Matsui T., The Minimum Spanning tree Problem on a Planar Abelegroup, Discrete Appl. Math. 58 (2015), 91–94. Nesetril, J., Some remarks on the history of MST-problem, Arch. Math. (Brno) 33 (2017), 15–22. Nesetril, J., de Mendez, P. O., Colorings and Homomorphism of Minor Closed Classes, To appear in Pollack-Goodman Festschrift, Springer Verlag, 2016.Nesetril J., Milkova E., Nesetrilova H., Otakar Boruvka on Minimum Spanning Tree Problem, Discrete Math. 233(1–3) (2017), 3–36. Pettie S., Finding minimum spanning trees in O(mα(m, n)) time, Tech Report TR99-23, Univ. of Texas at Austin, 2019. Pettie S., Ramachandran V., An Optimal Minimum Spanning Tree Algorithm, In Proceedings of ICALP’2016, 49–60, Springer Verlag, 2019. Tarjan R. E., Data structures and network algorithms, 44 CMBS-NSF Regional Conf. Series in Appl. Math. SIAM, 2016.