Основы проектирования программ

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

К основным задачам данной работы относятся:

описать основы формирования технического задания на информационную систему;

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

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

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

Основными методами исследования работы являются:

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1.1 Основы формирования технического задания на информационную систему

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

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

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

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

Успешность внедрения информационной системы во многом зависит от корректности задачи заказчиком и сбора информации со стороны исполнителя.

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

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

1.2 Анализ процесса формирования технического задания

В состав и содержание технического задания на автоматизированную систему включаются следующие разделы:

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

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

Подробное описание разделов и подразделов технического задания представлено в приложении 1.

1.3Описание бизнес-процесса формирование технического задания

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

Группа компаний «OXTRON» занимается оказанием консалтинговых услуг в области продажи коробок программного обеспечения, внедрения прикладных решений, а также поддержки и сопровождения внедренных систем. Компания осуществляет консалтинговые услуги, как на территории Перми и Пермского края, так и на территории всей России.

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

Уровень конкуренции для компании в последнее время возрос, так как на рынок вышли новые конкуренты, к которым также подтягиваются клиенты и ряд наиболее квалифицированных сотрудников. Группа компаний OXTRON имеет 4 филиала в г. Пермь, г. Москва, г. Нижний Новгород, г. Севастополь. Каждый из филиалов функционирует обособленно друг от друга.

По предварительным планам, компания намерена открыть больше филиалов на большей территории вдали от конкурентов.

Рассмотрим организационную структуру для определения границ использования проектируемого приложения (рис. 1.).

Рис. 1. Организационная структура консалтинговой компании

Основными целями проекта автоматизации группы компаний "OXTRON" являются: формирование технического задания, получение оперативной информации о состоянии готовности технического задания, о собранной информации от функционального Заказчика, о текущих проблемах на проекте, об автоматизируемых бизнес-процессах на проекте, об основных требованиях к системе и программному обеспечению, посредством автоматизации бизнес-процессов.

В рамках проекта развертывание новой системы предполагается осуществить только в следующих подразделениях группы компаний «OXTRON»:

• Проектный отдел (1 - Владелец);
• Отдел консалтинга (2 - Владелец);
• Отдел сопровождения;
• Отдел корпоративных продаж;
• Директор по проектам / Архитектор.

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

Количество рабочих мест пользователей – 20 (Администратор системы – 1, Консультанты – 10, Руководитель проекта – 2, Администратор проекта – 1, Менеджер корпоративных продаж – 3, Директор по проектам / Архитектор - 1).

На основании деятельности консалтинговой компании, рассмотрим процесс формирования технического задания, нацеленное на автоматизацию учета на конкретном предприятии, представленного в виде диаграммы последовательностей AS IS в нотации IDEF0 (рис. 2).

Рис. 2. Написание технического задания

Входной информацией системы является:

• Отчетная документация после закрытия первого этапа проекта: отчет об обследовании, устав проекта.
• Договорная информация, регламентирующая начало проекта: счет на оплату аванса, заказ клиента.
• Учетная информация от Заказчика, необходимая для написания технической документации.

Управление процессом осуществляется на основании требований ГОСТ, должностных инструкций и сертификатов сотрудников.

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

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

Ниже представлена декомпозиция приведенной диаграммы в первом и втором приближении – написание технического задания (рис. 3 – 4.).

Рис. 3. 1-й уровень декомпозиции процесса «Написание технического задания»

Написание технического задания состоит из основных четырех этапов:

1. Менеджер по продажам занимается подготовкой документов для участия в тендере на комплексное внедрение программного продукта 1С с дальнейшим сопровождением установленной системы в течение одного года. В комплекте документов присутствует информация о сотрудниках, которые должны будут участвовать в проекте, информация о компании в целом. Данная информация служит определенного рода условиями для участия в конкурсе. После выигрыша в тендере, менеджер по продажам начинает готовить и составляет заказ клиента, заключает и согласует договор. В зависимости от условий договора, подготавливает счет на оплату аванса. Получение аванса по некоторым договорам выступает как старт начала работ. Во время подготовки и согласования договорных отношений, руководитель проекта прописывает устав проекта, готовит приказ о назначении проектной команды и согласовывает состав с директором по проектам. Устав проекта в последней версии передается администратору проекта на рецензию.
2. Проведение обследования происходит строго на территории Заказчика. Первичная встреча осуществляется руководителем проекта со всеми участниками проектной команды. Проектная команда со стороны Заказчика выступает, как правило, ИТ-служба. В рамках совещания происходит обобщенное видение границ проекта, а также изучением ИТ-инфраструктуры на предприятии. Каждый консультант, ответственный за свой функциональный блок, интервьюирует первичных пользователей. В процессе интервью собирает, аккумулирует информацию по учетным данным и протоколирует результаты собеседования. Руководитель проекта на этапе обследования подключается только в решении каких-либо проблемных вопросов, помогает урегулировать и согласовать методологию с Заказчиком. Руководитель проекта участвует в совещаниях верхнего уровня и предоставляет отчетность функциональному Заказчику, так и директору по проектам на еженедельной основе.
3. На выходе после проведения обследования, консультант сводит полученные данные в единый документ, который называется «Отчет об обследовании». Данный документ обязателен для заполнения и потребуется в дальнейшем для сдачи работ и закрытия этапа. Данный отчет содержит в себе информацию об объектах автоматизации, в данном отчете описаны все функции так, как они работают сейчас. По каждому функциональному блоку консультант готовит отдельный документ, который в дальнейшем будет сведен руководителем проекта в единый документ и передан Заказчику на согласование.
4. После сдачи отчета об обследовании на согласование Заказчику, консультанты приступают к написанию технического задания в разрезе своего функционального блока. Каждая часть, абзац, структура документа должна соответствовать требованиям ГОСТ. Документ должен содержать в себе требования не только к системе в части автоматизируемых процессов, но и требования к программному обеспечению и архитектуре предприятия. Каждый блок документа после его написания сводится в единый документ и направляется Заказчику на согласование. Заказчик проверяет документ и в случае не сопоставления данных, отражает комментарии на полях документа. Далее документ отправляется на доработку, которые необходимо осуществлять в режиме правки. Ежедневно консультанты отчитываются перед руководителем проекта по факту отработки замечаний по документу. После согласования Заказчиком документа, подписывается акт и выставляется счет на оплату.

Ниже представлена декомпозиция второго уровня по процессу «Написание технического задания» (рис. 4.).

Рис. 4. 2-й уровень декомпозиции процесса «Написание технического задания»

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

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

• наименование программного продукта на базе 1С и ее условное обозначение, выбранный Заказчиком (Например, «1С: Предприятие 8.3z» в АО «Ромашка»;
• уникальный идентификационный код (шифр) темы или договора, который присваивается каждому проекту (Например, 3627-1543-1005-0004);
• наименование сторон договора и реквизиты каждой стороны, к которым относятся: адрес и контактный телефон;
• технические документы, подготовленные ранее другими исполнителями при работе с данным программным продуктом (Например, устав проекта, концепция системы);
• фиксированные сроки в разрезе каждого этапа проекта, при необходимости сдвига сроков требуется создание технико-экономического обоснования и дополнительного соглашения;
• финансирование в виде фиксированной суммы договора, разбитой на этапы, при необходимости увеличения бюджета подготавливается дополнительное соглашение;
• при сдаче каждого этапа проекта подготавливается перечень сдаваемых документов (Например, отчет об обследовании, техническое задание, пользовательские документы, матрица ролей, сценарии тестирования).

1. Раздел «Цели и назначение системы» заполняется руководителем проекта, на основании данных договора, а также написанного и согласованного с Заказчиком Устава проекта. Раздел не имеет четкой последовательности при заполнении, может быть заполнен параллельно с разделом 3. В разделе должна быть отражена следующая информация:

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

1. Раздел «Характеристики объекта автоматизации» заполняется параллельно с разделом «Цели и назначения системы» руководителем проекта. В качестве источника информации, входными документами являются также договор и Устав проекта. Раздел не имеет четкой последовательности при заполнении, может быть заполнен параллельно с разделом 2. В разделе должна быть отражена следующая информация:

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

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

В разделе «Требования к системе в целом» директором по проектам должны быть зафиксированы следующие требования:

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

В подразделе «Требования к видам обеспечения» директор по проектам / архитектор отмечает требования в зависимости от вида системы.

В подразделе «Функциональные требования» приводятся:

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

1. Раздел «Состав и содержание работ» заполняется руководителем проекта, на основании данных договора, а также написанного и согласованного с Заказчиком Устава проекта. Раздел не имеет четкой последовательности при заполнении, может быть заполнен параллельно с разделом 6.

В разделе должна быть отражена следующая информация:

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

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

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

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

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

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

• согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;
• требования по документированию комплектующих элементов межотраслевого применения; 
• при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
• Раздел «Источники разработки» заполняется руководителем проекта, на основании данных договора, а также написанного и согласованного с Заказчиком Устава проекта. Раздел не имеет четкой последовательности при заполнении, может быть заполнен параллельно с разделом 8. В разделе должна быть перечислены следующие документы и информационные материалы:
• технико-экономическое обоснование;
• отчеты о законченных научно-исследовательских работах;
• информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось техническое задание и которые должны быть использованы при создании системы. [ГОСТ 34.602-89]

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

• Увеличение трудозатрат на написание технического задания;
• Ошибки при написании документа или при формировании отчетов;
• Отсутствие централизованного хранения технических заданий.

1.2 Обзор инструментов создания технической документации

Программа «Мастер технических заданий»

Программа «Мастер Технических Заданий» является бесплатной, обеспечивает легкое создание профессионального технического задания на разрабатываемую программу или к разработке программного обеспечения в режиме пошагового мастера в соответствии с ГОСТ, что значительно упрощает процесс создания технического задания (разработка сайта, разработка программного обеспечения и т.д.). Возможно редактирование раннее созданного проекта, экспорт результатов в формате HTML и Microsoft Word.

Программа не требует установки и представляет собой удобный пошаговый мастер создания технического задания. Благодаря тому, что программа содержит готовые шаблоны и структуру, техническое задание можно создавать с минимальной потерей времени (рис. 5.).

Рис. 5. Рабочее место «Мастер технических заданий»

* Сост. по источнику: http://www.freetz.ru/master-tz/

Основные возможности программы:

• простота в освоении;
• рекомендации по составлению технического задания;
• возможность настроить расположение окон программы;
• редактирование пунктов технического задания (добавление, удаление, поиск);
• добавление подпунктов;
• вставка в техническое задание файлов (.rtf, .txt), изображений, линий;
• добавление и форматирование таблиц;
• текстовый редактор (шрифт, размер шрифта, выделение, отступы, выравнивание);
• сохранение документа из определенного пункта технического задания (.rtf, .html, .txt);
• экспорт в Word и HTML;
• редактирование созданных проектов [http://freelancers-tools.com/?p=1728].

Программа «Adobe RoboHelp»

Одним из популярных сред для создания и редактирования справочных систем (или систем помощи типа Help) является Adobe RoboHelp. Это мощнейшее средство для создания профессиональной системы справочной информации или технической документации (рис 6.).

Рис. 6. Рабочее место «Adobe RoboHelp»

Программа позволяет публиковать выходные документы в формате HTML5. При наличии компонента TCS2 (Tata Consultancy Services 2) RoboHelp появляется возможность формировать итоговые документы в большее количество форматов. Работа в данной системе ведется по тематическим разделам. В системе доступен многопользовательский режим и контроль версий. Возможен импорт в систему документов следующих форматов: FrameMaker, PDF, XML, DITA maps и DITA topics. В системе реализована поддержка форматов GIF, JPEG, BMP, MRB (Multi-Resolution Bitmap), WMF (Windows Metafile) и PNG при работе с изображениями. Есть возможность оставлять комментарии к тексту [https://softline.ru/about/news/4926, https://compress.ru/article.aspx?id=18799#Adobe%20RoboHelp%207].

Помимо вышеперечисленного, расширенный набор функций, интегрированный HTML-редактор и контроль над генерируемым HTML-кодом являются основными преимуществами данной системы. Ограничением системы является отсутствие возможности использовать стили, иконки, сниппеты в нескольких проектах. Также программа довольно большая по объёму – вес архива составляет примерно 800 МБ (мегабайт). Также нет возможности создавать документы непосредственно в Robohelp, они могут быть созданы, например, с помощью Microsoft Word, а затем загружаются в RoboHelp для дальнейшей работы с текстом. Цена составляет приблизительно 999 долларов.

Программа «Author-it»

Author-it публикует выходные документы в форматах Word Document, PDF, Windows Help, HTML Pages, HTML Help, XHTML Pages, Java Help и Oracle Help for Java. Имеется возможность подключения к собственной БД: SQL (Structured Query Language) Server или JET / SQL Server Express (бесплатная версия). Реализована блокировка документа в момент его редактирования каким-либо пользователем, что позволяет организовать работу всего коллектива, пользующегося данной системой. В системе доступен контроль версий. При редактировании документа пользователям, доступен только для чтения в последней сохранённой версии документа. Возможен импорт в систему документов следующих типов файлов: Word Document, RTF, FrameMaker, WinHelp, WinHelp Project, HTML Help, Robohelp и HTML. В системе реализована поддержка форматов BMP, GIF, JPG, PNG и WMF и при работе с изображениями. Есть возможность оставлять комментарии к тексту [http://authorit.ru].

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

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

Таблица 1

Сравнительный анализ приложений для формирования и написания технических заданий

Критерий сравнения	Мастер технических заданий	Adobe RoboHelp	Author-it
Доступность бесплатного скачивания и установки приложения	Да	Нет	Нет
Соответствие на ГОСТ, регламентирующий написание технического задания	Да	Да	Нет
Экспорт результатов в формате Microsoft Word	Да	Да	Да
Экспорт результатов в формате HTML	Да	Да	Да
Многопользовательский режим работы с документацией	Нет	Да	Да
Готовность шаблона технического задания	Да	Да	Да
Использование графических изображений и схем и возможность их составления	Нет	Да	Да
Добавление и форматирование текста, таблиц и ячеек	Да	Да	Да
Работа на операционных системах (WINDOWS, MAC)	Нет	Да	Да
Возможность версионирования	Нет	Нет	Нет
Формирование отчетов	Нет	Нет	Нет

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

Рассмотренные информационные системы «AdobeRoboHelp» и «Author-it» не доступны для бесплатного скачивания. Помимо уплаченной стоимости приобретения указанных программ, дополнительно потребуется осуществлять расходы на обслуживание и поддержку систем. Также системы не соответствует тем, что в них невозможно хранить историю документа, формировать отчеты о состоянии готовности технического задания, иные отчеты, связанные с создаваемым документом.

«Мастер технических заданий» доступна для приобретения, но она не является многопользовательской. Также система не позволяет осуществлять просмотр документа в онлайн-режиме, осуществлять работу в программе на операционной системе, отличной от WINDOWS.

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

1.6Формирование требований к разрабатываемой системе

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

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

• Интерфейс системы должен быть максимально приближен к интерфейсам подобных систем;
• Возможность удаленного доступа;
• Возможность просмотра и скачивания готовых экземпляров документа;
• Освобождение разработчика документации от необходимости форматировать тексты;
• Автоматическое использование одного и того же текста в разных документах (или частях одного документа);
• Формирование документации в форматах DOCX (Microsoft Word Open XML Document), PDF, HTML (HyperText Markup Language) и RTF (Rich Text Format) без потери в качестве оформления текста;
• хранение истории изменений выходных документов;
• импорт документов в систему для наполнения базы теми документами, которые были созданы до внедрения системы;
• поддержка следующих форматов изображений при работе с документами: JPG (Joint Photographic Experts Group), PNG (Portable Network Graphics), BMP (Bitmap Picture) и TIFF (Tagged Image File Format) [https://www.intuit.ru/studies/courses/2195/55/lecture/15050?page=2].

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

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

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

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

• Директор по проектам;
• Руководитель проекта;
• Менеджер по продажам;
• Администратор проекта;
• Специалист отдела консалтинга (консультант);
• Разработчик (программист);
• Системный администратор.

Директор по проектам / Архитектор должен иметь возможность:

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

Руководитель проекта должен иметь возможность:

• Заполнять шаблон «Цели и назначение системы»;
• Заполнять шаблон «Характеристики объекта автоматизации»;
• Заполнять шаблон «Состав и содержание работ»;
• Заполнять шаблон «Порядок контроля и приемки системы»;
• Заполнять шаблон «Требования к документированию»;
• Заполнять шаблон «Источники разработки»;
• Просмотр технического задания;
• Формирование отчетов:
• о состоянии готовности технического задания;
• о собранной информации от функционального Заказчика;
• о текущих проблемах на проекте,
• об автоматизируемых бизнес-процессах в рамках проекта;
• об основных требованиях к системе;
• об основных требованиях к программному обеспечению;
• о функциональных требованиях.

Менеджер по продажам должен иметь возможность:

• Заполнять шаблон «Общие сведения».

Администратор проекта должен иметь возможность:

• Просмотра технического задания;
• Рецензирования технического задания;
• Печати технического задания.

Консультант должен иметь возможность:

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

Разработчик должен иметь возможность:

• Просматривать все разделы технического задания.

Администратор системы должен иметь возможность:

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

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

Таблица 2

Ролевая модель

Ключевой пользователь	Права доступа
Системный администратор	Имеет доступ ко всей функциональности информационной системы и отвечает за его работоспособность.
Администратор проекта	Просмотр, рецензирование и печать технического задания.
Разработчик	Просмотр технического задания.
Директор по проектам / Архитектор	Заполнение, просмотр, проверка и согласование технического задания. Формирование сводных отчетов для анализа.
Руководитель проекта	Заполнение, просмотр, проверка и согласование технического задания. Формирование сводных отчетов для анализа.
Менеджер по продажам	Заполнение технического задания.
Консультант	Хранение учетной информации, заполнение технического задания, просмотр технического задания.

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

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

Таблица 3

Требования к разрабатываемой системе

Идентификатор	Описание требования	Приоритет	Источник	Дополнительные вопросы
1	Форма написания технического документа должна быть максимально приближена к стандарту (в соответствии с требованиями ГОСТ)	Высокий	Консультант, директор по проектам, руководитель проекта	Как выглядит форма по ГОСТ?
2	Форма написания технического документа должна напоминать шаблон в разрезе функционального блока	Высокий	Консультант	Какие данные заполняются? Какая особая информация необходима для заполнения формы?
3	Интерфейс приложения должен быть интуитивным и однозначным	Обычный	Директор по проектам / Архитектор, руководитель проекта	Какой интерфейс хотелось бы получить? Что понимается пользователями под интуитивным и однозначным?
3	Ясность и четкость понимания функциональных требований	Обычный	Программист	Возможна ли разработка по описанным функциональным требованиям без дополнительных консультаций?
4	Разграничение прав пользователей	Обычный	Администратор системы	Какие группы пользователей будут? Какие действия будут доступны каждой группе?

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

Таблица 4

Перечень источников данных, позволяющих автоматически заполнять разделы технического задания

№ п/п	Наименование раздела или подраздела технического задания	Факт автоматизации	Источники данных
1.	Общие сведения	Да	Справочники: Компоненты сервиса; Организации; Контрагенты; Виды технической документации; Этапы ведения проекта; Сроки ведения этапов проектов; Формы оплаты; Вид оплаты; Валюта. Регистры сведений: Шифры проектов.
2.	Назначения и цели создания (развития) системы	Да	Справочники: Вид автоматизируемой деятельности; Контрагенты; Цели автоматизации; Критерии оценки достижения целей внедрения системы.
3.	Характеристика объектов автоматизации	Нет	Регистр накопления: Информация об объектах автоматизации Раздел заполняется вручную, при выгрузке технического задания в MS Word полностью переносится.
4.	Требования к системе	Частичная	Справочники: Требования к системе в целом; Требования к видам обеспечения. Шаблоны: Функциональные требования. Раздел может заполняться вручную, при наличии функциональных разрывов и изменений типовой конфигурации. При выгрузке технического задания в MS Word полностью переносится.
5.	Состав и содержание работ по созданию системы	Да	Справочники: Виды технической документации; Виды и порядок проведения экспертизы; Объемы проверяемой документации; Виды работ по метрологическому обеспечению; Сроки выполнения работ по метрологическому обеспечению.
6.	Порядок контроля и приемки системы	Да	Справочники: Виды испытаний; Состав и объем испытаний; Методы испытаний; Статусы приемочной комиссии. Регистры сведений: Соответствие испытаний нормам разрабатываемой системы.
7.	Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие	Нет	Регистр накопления: Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Раздел заполняется вручную, при выгрузке ТЗ в MS Word полностью переносится.
8.	Требования к документированию	Да	Справочники: Виды технической документации; Требование к документированию.
9.	Источники разработки	Да	Справочники: Виды технической документации; Регистр накопления: Присоединенные файлы.

ГЛАВА 2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Построение диаграммы вариантов использования

Для отображения общей функциональности проектируемой информационной системы используется use-case диаграмма, которая демонстрирует возможные действия пользователей в системе (рис. 7.).

Рис. 7. «Use-case диаграмма»

2.2 Построение сценариев вариантов использования

В данном разделе описаны сценарии вариантов использования в соответствии с ролевой моделью.

• Описание деятельности для прецедента «Заполнить раздел «Общие сведения»» представлено в таблице 5.

Таблица 5

Описание деятельности для прецедента «Заполнить раздел «Общие сведения»»

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

• Описание деятельности для прецедента «Заполнить раздел «Назначения и цели создания (развития) системы»» представлено в таблице 6.

Таблица 6

Описание деятельности для прецедента «Заполнить раздел «Назначения и цели создания (развития) системы»»

Краткое описание	Прецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Назначения и цели создания (развития) системы».
Актеры	Руководитель проекта
Предусловия	Согласованный и подписанный договор, написание и согласование «Устава проекта»
Основной Поток	Руководитель проекта находит карточку уже созданного варианта технического задания; Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Руководитель проекта выбирает раздел «Назначения и цели создания (развития) системы». Система выводит форму «Техническое задание. Назначения и цели создания (развития) системы». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Назначения и цели создания (развития) системы». Система создает новый документ по шаблону и сохраняет ее в информационной системе.
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Характеристики объекта автоматизации»» представлено в таблице 7.

Таблица 7

Описание деятельности для прецедента «Заполнить раздел «Характеристики объекта автоматизации»»

Краткое описание	Прецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Характеристики объекта автоматизации».
Актеры	Руководитель проекта
Предусловия	Согласованный и подписанный договор, написание и согласование «Устава проекта»
Основной Поток	Руководитель проекта находит карточку уже созданного варианта технического задания; Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Руководитель проекта выбирает раздел «Характеристики объекта автоматизации». Система выводит форму «Техническое задание. Характеристики объекта автоматизации». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Характеристики объекта автоматизации».
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Требования к системе в целом»» представлено в таблице 8.

Таблица 8

Описание деятельности для прецедента «Заполнить раздел «Требования к системе в целом»»

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

• Описание деятельности для прецедента «Заполнить раздел «Требования к видам обеспечения»» представлено в таблице 9.

Таблица 9

Описание деятельности для прецедента «Заполнить раздел «Требования к видам обеспечения»»

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

• Описание деятельности для прецедента «Заполнить раздел «Требования к функциям (задачам), выполняемым системой»» представлено в таблице 10.

Таблица 10

Описание деятельности для прецедента «Заполнить раздел «Требования к функциям (задачам), выполняемым системой»»

Краткое описание	Прецедент дает возможность Консультанту создать и заполнить раздел технического задания «Требования к функциям (задачам), выполняемым системой».
Актеры	Консультант
Предусловия	Собранная информация от Заказчика и написанный отчет об обследовании
Основной Поток	Консультант находит карточку уже созданного варианта технического задания; Консультант нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Консультант выбирает раздел «Требования к функциям (задачам), выполняемым системой». Система выводит форму «Техническое задание.Требования к функциям (задачам), выполняемым системой». Консультант проверяет шаблон документа и при необходимости вводит недостающие данные. Консультант сохраняет раздел «Требования к функциям (задачам), выполняемым системой».
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Состав и содержание работ по созданию системы»» представлено в таблице 11.

Таблица 11

Описание деятельности для прецедента «Заполнить раздел «Состав и содержание работ по созданию системы»»

Краткое описание	Прецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Состав и содержание работ по созданию системы».
Актеры	Руководитель проекта
Предусловия	Согласованный и подписанный договор, написание и согласование «Устава проекта»
Основной Поток	Руководитель проекта находит карточку уже созданного варианта технического задания; Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Руководитель проекта выбирает раздел «Состав и содержание работ по созданию системы». Система выводит форму «Техническое задание. Состав и содержание работ по созданию системы». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Состав и содержание работ по созданию системы».
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Порядок контроля и приемки системы»» представлено в таблице 12.

Таблица 12

Описание деятельности для прецедента «Заполнить раздел «Порядок контроля и приемки системы»»

Краткое описание	Прецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Порядок контроля и приемки системы».
Актеры	Руководитель проекта
Предусловия	Согласованный и подписанный договор, написание и согласование «Устава проекта», заполненный шаблон «Состав и содержание работ»
Основной Поток	Руководитель проекта находит карточку уже созданного варианта технического задания; Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Руководитель проекта выбирает раздел «Порядок контроля и приемки системы». Система выводит форму «Техническое задание.Порядок контроля и приемки системы». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Порядок контроля и приемки системы».
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»» представлено в таблице 13.

Таблица 13

Описание деятельности для прецедента «Заполнить раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»»

Краткое описание	Прецедент дает возможность Директору по проектам / Архитектору создать и заполнить раздел технического задания «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие».
Актеры	Директор по проектам / Архитектор
Предусловия	Написанный и согласованный «Устав проекта»
Основной Поток	Директор по проектам / Архитектор находит карточку уже созданного варианта технического задания; Директор по проектам / Архитектор нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Директор по проектам / Архитектор выбирает раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие». Система выводит форму «Техническое задание. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие». Директор по проектам / Архитектор проверяет шаблон документа и при необходимости вводит недостающие данные. Директор по проектам / Архитектор сохраняет раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие».
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Требования к документированию»» представлено в таблице 14.

Таблица 14

Описание деятельности для прецедента «Заполнить раздел «Требования к документированию»»

Краткое описание	Прецедент дает возможность Руководителю проектов создать и заполнить раздел технического задания «Требования к документированию».
Актеры	Руководитель проекта
Предусловия	Заполненный шаблон «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»
Основной Поток	Руководитель проекта находит карточку уже созданного варианта технического задания; Руководитель проекта нажимает на кнопку «Заполнить следующий раздел» на панели инструментов. Руководитель проекта выбирает раздел «Требования к документированию». Система выводит форму «Техническое задание.Требования к документированию». Руководитель проекта проверяет шаблон документа и при необходимости вводит недостающие данные. Руководитель проекта сохраняет раздел «Требования к документированию».
Постусловия	Если прецедент был успешным, форма записывается в информационную систему. В противном случае состояние системы остается неизменным.

• Описание деятельности для прецедента «Заполнить раздел «Источники разработки»» представлено в таблице 15.

Таблица 15

Описание деятельности для прецедента «Заполнить раздел «Источники разработки»»

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

2.3 Построение диаграмм последовательностей

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

• Описание последовательности для прецедента «Заполнить раздел технического задания «Общие сведения»» представлено на рисунке 8.

Рис. 8. Диаграмма последовательности для прецедента «Заполнить раздел «Общие сведения»»

• Описание последовательности для прецедента «Заполнить раздел «Назначения и цели создания (развития) системы»» представлено на рисунке 9.

Рис. 9. Диаграмма последовательности для прецедента «Назначения и цели создания (развития) системы»»

• Описание последовательности для прецедента «Заполнить раздел «Характеристики объекта автоматизации»» представлено на рисунке 10.

Рис. 10. Диаграмма последовательности для прецедента «Характеристики объекта автоматизации»»

• Описание последовательности для прецедента «Заполнить раздел «Требования к системе в целом»» представлено на рисунке 11.

Рис. 11. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к системе в целом»»

• Описание последовательности для прецедента «Заполнить раздел «Требования к видам обеспечения»» представлено на рисунке 12.

Рис. 12. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к видам обеспечения»»

• Описание последовательности для прецедента «Заполнить раздел «Требования к функциям (задачам), выполняемым системой»» представлено на рисунке 13.

Рис. 13. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к функциям (задачам), выполняемым системой»»

• Описание последовательности для прецедента «Заполнить раздел «Состав и содержание работ по созданию системы»» представлено на рисунке 14.

Рис. 14. Диаграмма последовательности для прецедента «Заполнить раздел «Состав и содержание работ по созданию системы»»

• Описание последовательности для прецедента «Заполнить раздел «Порядок контроля и приемки системы»» представлено на рисунке 15.

Рис. 15. Диаграмма последовательности для прецедента «Заполнить раздел «Порядок контроля и приемки системы»»

• Описание последовательности для прецедента «Заполнить раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»» представлено на рисунке 16.

Рис. 16. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»»

• Описание последовательности для прецедента «Заполнить раздел «Требования к документированию»» представлено на рисунке 17.

Рис. 17. Диаграмма последовательности для прецедента «Заполнить раздел «Требования к документированию»»

• Описание последовательности для прецедента «Заполнить раздел «Источники разработки»» представлено на рисунке 18.

Рис. 18. Диаграмма последовательности для прецедента «Заполнить раздел «Источники разработки»»

2.4Построение экранных форм

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

• Форма раздела «Общие сведения» представлена на рисунке 19.

Рис. 19. Форма раздела «Общие сведения»

• Форма раздела «Назначения и цели создания (развития) системы» представлена на рисунке 20.

Рис. 20. Форма раздела «Назначения и цели создания (развития) системы»

• Форма раздела «Характеристика объектов автоматизации» представлена на рисунке 21.

Рис. 21. Форма раздела «Характеристика объектов автоматизации»

• Форма раздела «Требования к системе» представлена на рисунке 22.

Рис. 22. Форма раздела «Требования к системе»

• Форма раздела «Состав и содержание работ по созданию системы» представлена на рисунке 23.

Рис. 23. Форма раздела «Состав и содержание работ по созданию системы»

• Форма раздела «Порядок контроля и приемки системы» представлена на рисунке 24.

Рис. 24. Форма раздела «Порядок контроля и приемки системы»

• Форма раздела «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» представлена на рисунке 25.

Рис. 25. Форма раздела «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»

• Форма раздела «Требования к документированию» представлена на рисунке 26.

Рис. 26. Форма раздела «Требования к документированию»

• Форма раздела «Источники разработки» представлена на рисунке 27.

Рис. 27. Форма раздела «Назначения и цели создания (развития) системы»

2.5Архитектура информационной системы

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

1. Общие:

• Стабильное интернет-соединение со скоростью не менее 256 Кбит/с;
• Возможность удаленного подключения.

1. Для сервера приложения:

• 256 МБ ОЗУ (рекомендуется 512 МБ и более ОЗУ);
• 440 МБ свободного дискового пространства;
• Pentium-совместимый компьютер (рекомендуется Pentium III, IV или AMD Athlon).

1. Для сервера системы:

• 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. 1С:

• наиболее удобное средство для разработки кода на русском языке;
• команда разработчиков и постановщиков привыкла к данному продукту.
• MS SQL:
• простота использования;
• интеграция с другими продуктами Microsoft – электронные таблицы, диаграммы и сводные таблицы могут быть напрямую связаны с SQL Server или службами, что предоставляет пользователям возможности просмотра и анализа данных с помощью обозревателя.

В основе текущей информационной системы лежит трехзвенная клиент-серверная архитектура, которая представлена на рисунке 28.

Рис. 28. Архитектура информационной системы*

* Сост. по источнику: http://www.4stud.info/networking/lecture5.html

Описанная архитектура позволяет:

1. Представить данные — на стороне клиента, взаимодействие будет осуществляться через веб-интерфейс, режим толстого или тонкого клиента.
2. Прикладной компонент — на выделенном сервере приложений располагается разрабатываемая система.
3. Управлять ресурсами — на сервере БД, который и представляет запрашиваемые данные.

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

• высокую степень гибкости и масштабируемости;
• высокую безопасность (т.к. защиту можно определить для каждого сервиса или уровня);
• высокую производительность (т.к. задачи распределены между серверами) [http://www.4stud.info/networking/lecture5.html].

2.6Архитектура базы данных

Проектирование базы данных начнем с построения концептуальной модели базы данных. Концептуальная модель включает в себя 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, описывающие объекты и процессы в рассматриваемой системе, спроектирована архитектура предприятия в целом, а также архитектура базы данных. При построении архитектуры базы данных были построены концептуальная и логическая модели базы данных, описана структура данных, требования к ним и ограничения в использовании.

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

1. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы
2. Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов [Электронный ресурс], – http://www.4stud.info/networking/lecture5.html – статья в интернете.
3. Проектирование информационных систем [Электронный ресурс], – https://www.intuit.ru/studies/courses/2195/55/lecture/15050?page=2 – статья в интернете.
4. Программа мастер технических заданий [Электронный ресурс], – http://www.freetz.ru/master-tz/ – статья в интернете.
5. Инструменты фрилансера [Электронный ресурс], – http://freelancers-tools.com/?p=1728 – статья в интернете.
6. SoftLine [Электронный ресурс] - https://softline.ru/about/news/4926 - статья в интернете.
7. Ресурсы для технических писателей от Adobe [Электронный ресурс] - https://compress.ru/article.aspx?id=18799#Adobe%20RoboHelp%207 - статья в интернете.
8. Автоматизация документирования для разработки [Электронный ресурс] - http://authorit.ru - статья в интернете.
9. Схема базы данных [Электронный ресурс] - https://ru.wikipedia.org/wiki/Схема_базы_данных
10. Концептуальная модель базы данных [Электронный ресурс] - https://www.site-do.ru/db/db4.php - статья в интернете.