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

Содержание
TOC \o "1-3" \h \z \u Реферат PAGEREF _Toc75795817 \h 4Список сокращений PAGEREF _Toc75795818 \h 5Введение PAGEREF _Toc75795819 \h 61. Анализ предметной области PAGEREF _Toc75795820 \h 71.1 Сбор сведений об объекте PAGEREF _Toc75795821 \h 71.1.1 Название организации и основная деятельность PAGEREF _Toc75795822 \h 71.1.2. Организационная структура PAGEREF _Toc75795823 \h 71.2. Выделение основных бизнес-процессов PAGEREF _Toc75795824 \h 81.2.1. Бизнес- процессы в организации. Текстовое описание бизнес-процессов PAGEREF _Toc75795825 \h 81.2.2. Оборудование PAGEREF _Toc75795826 \h 91.2.3. Территория PAGEREF _Toc75795827 \h 101.2.4. Внешняя среда PAGEREF _Toc75795828 \h 101.2.5. Диаграмма сети основных бизнес-процессов данной организации PAGEREF _Toc75795829 \h 112. Техническое задание PAGEREF _Toc75795830 \h 143. Моделирование предметной области PAGEREF _Toc75795831 \h 153.1. IDEF0 модель PAGEREF _Toc75795832 \h 183.2. Модели данных PAGEREF _Toc75795833 \h 203.3. Диаграмма вариантов использования PAGEREF _Toc75795834 \h 223.4. Диаграмма классов PAGEREF _Toc75795835 \h 244. Дизайн информационной системы PAGEREF _Toc75795836 \h 264.1. Прототипирование программного обеспечения PAGEREF _Toc75795837 \h 264.2. Дизайн интерфейсов PAGEREF _Toc75795838 \h 285. Расчет стоимости информационной системы PAGEREF _Toc75795839 \h 32Список литературы PAGEREF _Toc75795840 \h 34Приложение 1 – Схема иерархии бизнес-процессов организации PAGEREF _Toc75795841 \h 36Приложение 2 – DFD-диаграмма сети основных бизнес-процессов организации PAGEREF _Toc75795842 \h 37Приложение 3 – Контекстная диаграмма верхнего уровня в нотации IDEF0 PAGEREF _Toc75795843 \h 38Приложение 4 – Диаграммы декомпозиций PAGEREF _Toc75795844 \h 39Приложение 5 – Физическая модель данных PAGEREF _Toc75795845 \h 43Приложение 6 – Диаграмма вариантов использования PAGEREF _Toc75795846 \h 44Приложение 7 – Диаграмма классов PAGEREF _Toc75795847 \h 45Приложение 8 – Интерфейс пользователя PAGEREF _Toc75795848 \h 46Приложение 9 – Затраты на покупку оборудования PAGEREF _Toc75795849 \h 47Приложение 10 – Техническое задание PAGEREF _Toc75795850 \h 49

РефератСостав курсового проекта
Показатель Объем Ед. измОбъем пояснительной записки страница
Количество таблиц штука
Количество формул штука
Количество рисунков штука
Количество графических моделей штука
Количество приложений штука
Количество используемых источников штука
Ключевые слова: База данных, информационная система, бизнес- процесс
Объектом исследования являются информационные процессы, происходящие в ИС производство пакетов
Цель работы – создание информационной системы в виде базы данных с интерфейсом пользователя для предприятия по производству пакетов

Список сокращенийБД – база данных.
ИС – информационная система.
СУБД – система управления базами данных.
ПО- программное обеспечение
ТЗ
Администратор ИС – лицо, ответственное за настройку и введения БД, а также регистрацию пользователей.
Сотрудник – пользователь ИС
БП – бизнес-процесс
ИП — индивидуальное предпринимательство
ВведениеПод проектированием информационных систем понимается процесс разработки технической документации, связанный с организацией системы, получения и преобразования исходной информации в результативную информацию. К основным задачам проектирования относятся: оказание влияния на улучшение организации учётной, плановой и аналитической работы; выбор оборудования и разработка рациональной технологии решения задач и получения результативной информации, создание баз данных, обеспечивающий оптимальное использование информации, создание нормативно-справочной информации.
Целью курсовой работы является разработка информационной системы ИП «Производство пакетов»
Дизайн ИС создается на основании регламентных документов и анализа предметной области. Он определяет роли пользователей, основные информационные потоки, правила формирования документов и построения отчетности. Дизайн ИС служит основанием для:
определения функциональных требований к ИС;
выбора программного обеспечения;
формирования технического задания.
Объектом дизайна является информация и процессы обработки информации.
Продуктами дизайна являются ИС разного назначения. В данном проекте для моделирования информационной системы были использованы:
CASE-средства Microsoft Visio 2019, Ramus.
база данных создана средствами программы 1С:Предприятие 8.3";
интерфейс информационной системы реализован средствами программы 1С:Предприятие 8.3".

1. Анализ предметной области1.1 Сбор сведений об объекте1.1.1 Название организации и основная деятельностьНазвание организации – ИП «Производство Пакетов».
Основная деятельность. Деятельность Завода основана на предоставлении полиэтиленовых пакетов в магазины и производственные предприятия. Основное преимущество предприятия заключается в производстве полиэтилена низкого давления и полиэтилена высокого давления. Кроме того, Производство предоставляет больше возможностей для творческой работы, так как можно выбрать свой рисунок пакета. Другими словами, клиент получает возможность за короткий промежуток времени сделать большое количество пакетов с различными рисунками.
1.1.2. Организационная структура
Директор, Бухгалтер, Менеджер по продажам, Рабочие, Уборщица

Рисунок 1 – Организационная структура
Таблица 1 – Основные бизнес-процессы ИП «Производство пакетов»
Исполнитель Название БП Тип БП
Директор 1.Организационные вопросы.
2.Работа с кадрами.
3.Поиск поставщиков.
4.Распределение заказов. 1.Обеспечивающий
2.Обеспечивающий
3.Обеспечивающий
4.Сопутствующий
Менеджер по продажам 1.Обеспечение заказами.
2.Взаимодействие с клиентами
3.Запуск рекламных компаний.
4.Расчет стоимости партий пакетов 1.Обеспечивающий
2.Обеспечивающий
3.Общеспечиващий
4.Обеспечивающий
Бухгалтер 1.Бухгалтерское сопровождение фирмы. 1.Управление
Рабочие 1.Принятие сырья.
2.Изготовление пакетов.
3.Проверка качества продукции
1.Сопутствующий
2. Основной
3.Сопутствующий
Уборщик 1. Обеспечение порядка 1. Вспомогательный
1.2. Выделение основных бизнес-процессов1.2.1. Бизнес- процессы в организации. Текстовое описание бизнес-процессовНазвание услуги
Производство пакетов с помощью полиэтилена низкого давления
Производство пакетов с помощью полиэтилена высокого давления
Продукты
Пакеты-майка 28*50
Пакеты-майка 30*55
Пакеты-майка 30*60
Пакеты-майка 43*64
Пакеты-майка 42*75
Пакеты-майка 16*30
1.2.2. ОборудованиеНаименование Количество Цена за 1 шт. Общая сумма
Основное оборудование
Экструдер 2 150 200 300 400
Пакетоделательная машина 2 450 000 900 000
Оборудование для запайки пакетов 1 37 000 37 000
Аппарат для нанесения печати 1 150 000 150 000
Коронатор2 63 000 126 000
Пресс для вырубки ручек 1 120 000 120 000
Итого: 1 633 400
Оборудование для администрации и персонала
Стол 2 4 000 8 000
Стул 2 2 000 4 000
Компьютер 2 25 000 50 000
Телефон 1 3 000 3 000
Итого: 65 000
Микроволновая печь 1 5 000 6 000
Электрический чайник 1 3 000 3 000
Спецодежда 6 2 000 12 000
Шкаф 1 5 000 5 000
Итого: 26 000
Общая сумма: 1 724 400
1.2.3. Территория
Месторасположение помещение для проекта находится на расстоянии не менее 300 м от ближайших жилых комплексов. Площадь — 200 кв.м с высотой потолков от 8 метров Арендованное помещение поделить на три части: производственный цех (80 кв.м −150 кв.м), административное помещение или офис (20 кв.м −30 кв.м), склад готовой продукции (40 кв.м −60 кв.м). Само здание должно быть снабжено электричеством, водой, отоплением, канализацией. Также в производственном цехе необходимо установить вытяжную вентиляцию и систему контроля качества.
1.2.4. Внешняя среда
Клиентами производства являются юридические лица. Основным критерием отличия ИП является разные способы производства пакетов. Далеко не все производители пакетов готовы вложиться в необычный и дорогой способ производств
Факторы риска
Бизнес по производству полиэтиленовых пактов сопряжен с определенными рисками, а именно:
Риск штрафов из-за загрязнения окружающей среды. Для снижения этих рисков необходимо изучить все нормативы и выполнить условия по организации производства, чтобы сделать бизнес жизнеспособным;
Риск некорректной работы оборудования также может присутствовать. Обязательно изучите все инструкции от поставщика и следуйте им при работе, ведь поломка может вам дорого стоить, так как производство будет простаивать;
Риск отсутствия продаж. Для того, чтобы оптимизировать данный риск, старайтесь постоянно заниматься продвижением своего бизнеса и рекламой для обеспечения прихода новых клиентов;
Демпинг цен — конкуренты могут занижать цены и привлекать определённый сегмент клиентов. Чтобы не подвергаться данному риску, постарайтесь непрерывно мониторить предложения конкурентов и вводить новые акции для клиентов.

Рисунок 2 – Схема бизнес-процессов
1.2.5. Диаграмма сети основных бизнес-процессов данной организации
Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища). Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением. Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. Кроме основных элементов, в состав DFD входят словари данных и мини спецификации. Декомпозиция завершается, когда процесс становится простым, т.е.:
Процесс имеет два-три входных и выходных потока;
Процесс может быть описан в виде преобразования входных данных в выходные;
Процесс может быть описан в виде последовательного алгоритма.
Полнота диаграммы обеспечивается, если в системе нет "повисших" процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены.
DFD- диаграмма основных бизнес-процессов организации приведена в приложении 2.
2. Техническое заданиеКак инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
обеим сторонам o представить готовый продукт o выполнить попунктную проверку готового продукта (приемочное тестирование — проведение испытаний) o уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний)
заказчику o осознать, что именно ему нужно o требовать от исполнителя соответствия продукта всем условиям, оговоренным в ТЗ
исполнителю o понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы o спланировать выполнение проекта и работать по намеченному плану o отказаться от выполнения работ, не указанных в ТЗ.
Нормативная база для составления ТЗ:
ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
Техническое задание на создание ИСУ «Производство пакетов» приведено в приложении 10.
3. Моделирование предметной областиВ основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области. Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области. К моделям предметных областей предъявляются следующие требования:
формализация, обеспечивающая однозначное описание структуры предметной области;
понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;
обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей. Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.
Структурный аспект предполагает построение: объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области; функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах; структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов; организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах; технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.
Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции. С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения. Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию. Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС. Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов
Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные). Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.
3.1. IDEF0 модельВ основе методологии IDEF0 лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий. Функциональный блок представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис. 1).

Рисунок 3 – Функциональный блок
Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом: верхняя сторона имеет значение "Управление"; левая сторона имеет значение "Вход"; правая сторона имеет значение "Выход"; нижняя сторона имеет значение "Механизм". Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей". Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Декомпозиция является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Последним из понятий IDEF0 является глоссарий. Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы в виде краткого описания и зафиксирована точка зрения. Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. Контекстная диаграмма верхнего уровня A0 в нотации IDEF0 приведена в приложении 3. Декомпозиция контекстной диаграммы A0 и диаграммы А1, А2, А3 декомпозиции приведены в приложении 4.
3.2. Модели данныхОдной из основных частей информационного обеспечения является информационная база. Информационная база представляет собой совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы “сущность-связь” (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).
Базовые понятия ERD: сущность, связь, атрибут. Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот. Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
Физическая модель данных приведена в приложении 5.
3.3. Диаграмма вариантов использованияЯзык UML предоставляет в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, предназначенный для разработки и документирования сложных моделей систем различного целевого назначения. Следует отметить, что одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако изобразительных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функционального поведения сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования.
Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение программной системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования и связь. В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Предлагаются различные способы представления или написания подобных сценариев. Один из таких шаблонов представлен в табл. УУ и может быть рекомендован для применения на начальных этапах концептуального моделирования.
Действующее лицо — внешняя по отношению к разрабатываемому программному обеспечению сущность, которая взаимодействует с ним в целях получения или предоставления какой-либо информации. Как уже упоминалось выше, действующими лицами могут быть пользователи, другое программное обеспечение или какие-либо технические средства. Вариант использования — некоторая очевидная для действующего лица процедура, решающая его конкретную задачу. Все варианты использования так или иначе связаны с требованиями к функциональности разрабатываемой системы и могут сильно различаться по объему выполняемой работы. Связь — взаимодействие действующих лиц и соответствующих вариантов использования. Варианты использования также могут быть связаны между собой. При этом фиксируют связи использования и расширения.
Таблица 2 – Шаблон для написания сценария отдельного варианта использования
Имя Типичный ход событий, приводящий к успешному выполнению варианта использования Исключение 1 Примечание 1
Действующие лица Исключение 2 Примечание 1
Цель Исключение 3 Примечание 1
Тип … …
Краткое описание Ссылки на другие варианты использования Исключение n Примечание n
Использование подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют как отдельный вариант и указывают связь с ним типа «использование». Расширение применяют, если имеется два подобных варианта использования, различающиеся наличием в одном из них некоторых дополнительных действий. В этом случае дополнительные действия определяют как отдельный вариант использования, который связан с основным вариантом связью типа «расширение». Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность. Диаграмма вариантов использования приведена в приложении 6.
3.4. Диаграмма классовДиаграммой UML, поясняющей внутреннее устройство системы, является диаграмма классов, описывающая создаваемую программную систему через ее компоненты (классы, объекты), отношения и взаимодействия между ними. В основном диаграммы классов в этих методах применяют на этапе проектирования, для того чтобы показать особенности построения конкретных классов. UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации: концептуальный уровень, на котором диаграммы классов, называемые в этом случае контекстными, демонстрируют связи между основными понятиями предметной области; уровень спецификаций, на котором диаграммы классов отображают интерфейсы классов предметной области, т. е. связи объектов этих классов; уровень реализации, на котором диаграммы классов непосредственно показывают поля и методы конкретных классов. Это три разные модели, связь между которыми неоднозначна. Так, если концептуальная модель определяет некоторое понятие предметной области как класс, то это не означает, что для реализации этого понятия будет использован отдельный класс. Каждая из перечисленных моделей используется на конкретном этапе разработки программного обеспечения: концептуальная модель — на этапе анализа; диаграммы классов уровня спецификации — на этапе проектирования; диаграммы классов уровня реализации — на этапе реализации. Концептуальные модели в соответствии с определением оперируют понятиями предметной области, атрибутами этих понятий и отношениями между ними. Класс при этом традиционно понимают как совокупность общих признаков некоторой группы объектов предметной области. В соответствии с этим определением на диаграмме классов каждому классу соответствует группа объектов, общие признаки которых и фиксирует класс.
Диаграмма классов приведена в приложении 7.
4. Дизайн информационной системы4.1. Прототипирование программного обеспеченияЛюбую техническую задачу можно решить различными способами. Это касается как задачи формулировки требований к программной системе, так и реализации ее пользовательского интерфейса. часто бывает так, что комбинация функциональных и нефункциональных требований такова, что возникает риск невозможности их реализации. Как правило, такой риск связан с требованиями к быстродействию системы при известных ограничениях на среду ее реализации. В этом случае создаются прототипы (не обязательно связанные с пользовательским интерфейсом), реализующие соответствующую часть системы, имитирующие потоки данных, поступающие на ее вход, и обработку этих данных. Прототипы могут быть горизонтальные и вертикальные, одноразовые и эволюционные, бумажные и электронные. Вертикальный (структурный) прототип направлен не столько на проектирование интерфейса пользователя, сколько на реализацию вертикального «среза» системы, затрагивая все уровни ее реализации. При создании такого рода прототипов рекомендуется использовать те же языки и среды реализации, что и при изготовлении целевой системы. Такого рода прототипы используются для анализа применимости, проверки архитектурных концепций. Одноразовый (исследовательский) прототип создается, когда нужно быстро получить макет разрабатываемой программной системы, те или иные ее аспекты и компоненты. Одноразовый прототип должен создаваться быстро, при его разработке не следует уделять внимание вопросам повторного использования кода, качества, быстродействия, технологичности и т.п. В результате получается «сырой» код, который может содержать значительное число дефектов. Необходимо принять меры к тому, чтобы фрагменты кода, реализующие такого рода прототипы, не стали частью целевой системы. Эволюционный прототип создается как первое приближение системы, призванное стать впоследствии самой системой. Программный код эволюционного прототипа должен последовательно перерасти в код целевого приложения. Поэтому данный вид прототипов требует всего того, от чего следует отказаться при создании одноразовых прототипов: тщательной разработки, применения технологических методов и приемов, тестирования результатов и т.п. Бумажный прототип — наброски интерфейсов на бумаге. Они, конечно, не заменят интерфейса, созданного в среде разработки. Однако при всех недостатках у таких прототипов есть два существенных достоинства. Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и не будет отвлекаться от анализа функциональности. Горизонтальный (поведенческий) прототип моделирует интерфейс пользователя приложения, не затрагивая логики обработки и структур данных. Для горизонтальных прототипов не обязательно использовать программную среду реализации, в которой будет разрабатываться конечный вариант системы. Прежде чем создавать горизонтальный прототип, необходимо определить, какие основные экраны будут присутствовать, какие окна будут открываться, какие правила перехода между ними будут поддерживаться.
Графический интерфейс, созданный в прототипе, должен отвечать всем требованиям стандартного графического интерфейса:
использовать ограниченный набор цветов, применять их правильное сочетание;
иметь инструментальную панель быстрых кнопок;
иметь продуманную последовательность переключения фокуса управляющих элементов;
для доступа к основным командам использовать горячие клавиши;
использовать ярлычки подсказок, всплывающие при перемещении курсора мыши над быстрыми кнопками и иными компонентами;
использовать возможность вызова файла справки.
4.2. Дизайн интерфейсовВ приложении 8 представлена диаграмма Use Case (прецедентов) для моделирования информационной системы учета процесса производства пакетов. В соответствии с диаграммой, структура информационной системы будет иметь вид, приведенный на рисунке 3.
32004028956000
Рисунок 4 – Структура информационной системы
На рис. 4 - 6 представлены макеты экранов информационной системы учета процесса производства пакетов, иллюстрирующие прецеденты:
«Вход в систему»
«Просмотр и изменение информационной базы. Справочники»
«Просмотр и изменение информационной базы. Документы»

Рисунок 5 – Экран: прецедент «Войти в систему»

Рисунок 6 – Справочник «Виды пакетов»

Рисунок 7 – Справочник «Поставщики»

Рисунок 8 – Справочник «Рабочие»

Рисунок 9 – Справочник «Сырье»

Рисунок 10 – Форма документа «Заказы»

Рисунок 11 – Форма документа «Клиенты»

5. Расчет стоимости информационной системыТаблица 3 – Расчет расходов ИП «Производство пакетов»
Наименование Количество Цена за 1 шт. Общая сумма
Основное оборудование
Экструдер 2 150 200 300 400
Пакетоделательная машина 2 450 000 900 000
Оборудование для запайки пакетов 1 37 000 37 000
Аппарат для нанесения печати 1 150 000 150 000
Коронатор2 63 000 126 000
Пресс для вырубки ручек 1 120 000 120 000
Итого: 1 633 400
Оборудование для администрации
Стол 2 4 000 8 000
Стул 2 2 000 4 000
Компьютер 2 25 000 50 000
Телефон 1 3 000 3 000
Итого: 65 000
Оборудование для персонала
Микроволновая печь 1 5 000 6 000
Электрический чайник 1 3 000 3 000
Спецодежда 6 2 000 12 000
Шкаф 1 5 000 5 000
Итого: 26 000
Общая сумма: 1 724 400

Список литературыБелов, В.В. Проектирование информационных систем: Учебник / В.В. Белов. - М.: Академия, 2018. - 144 c.
Гвоздева, Т.В. Проектирование информационных систем: технология автоматизированного проектирования. Лабораторный практикум. Учебно-справочное пособие / Т.В. Гвоздева, Б.А. Баллод. - СПб.: Лань, 2018. - 156 c.
Гвоздева, Т.В. Проектирование информационных систем. Стандартизация: Учебное пособие / Т.В. Гвоздева, Б.А. Баллод. - СПб.: Лань, 2019. - 252 c.
Гинзбург, В.М. Проектирование информационных систем в строительстве. Информационное обеспечение / В.М. Гинзбург. - М.: АСВ, 2008. - 368 c.
Емельянова, Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 432 c.
Заботина, Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. - М.: НИЦ Инфра-М, 2013. - 331 c.
Исаев, Г.Н. Проектирование информационных систем: Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2013. - 424 c.
Исаев, Г.Н. Проектирование информационных систем: Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2009. - 240 c.
Коваленко, В.В. Проектирование информационных систем: Учебное пособие / В.В. Коваленко. - М.: Форум, 2012. - 320 c.
Коваленко, В.В. Проектирование информационных систем: Учебное пособие / В.В. Коваленко. - М.: Форум, 2015. - 976 c.
Мартишин, С.А. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: Методы и средства проектирования информационных систем и технологий. Инструментальные средства информационных систем: Учебное пособие / С.А. Мартишин, В.Л. Симонов,. - М.: ИД ФОРУМ, НИЦ Инфра-М, 2012. - 160 c.
Мартишин, С.А. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: Методы и средства проектирования информационных систем и технолог / С.А. Мартишин, В.Л. Симонов, М.В. Храпченко. - М.: Форум, 2017. - 62 c.
Мартишин, С.А. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: Методы и средства проектирования информационных систем и техноло / С.А. Мартишин, В.Л. Симонов, М.В. Храпченко. - М.: Форум, 2018. - 61 c.
Перлова, О.Н. Проектирование и разработка информационных систем: Учебник / О.Н. Перлова, О.П. Ляпина, А.В. Гусева. - М.: Academia, 2017. - 416 c.
Перлова, О.Н. Проектирование и разработка информационных систем: Учебник / О.Н. Перлова. - М.: Академия, 2018. - 272 c.
Соловьев, И.В. Проектирование информационных систем / И.В. Соловьев. - М.: Академический проспект , 2009. - 398 c.
Соловьев, И.В. Проектирование информационных систем. Фундаментальный курс / И.В. Соловьев, А.А. Майоров. - М.: Академический проект, 2009. - 398 c.
Соловьев, И.В. Проектирование информационных систем. Фундаментальный курс: Учебное пособие для высшей школы / И.В. Соловьев, А.А. Майоров; Под ред. В.П. Савиных. - М.: Академический проспект, 2009. - 398 c.
Федоров, Н.В. Проектирование информационных систем на основе современных CASE-технологий / Н.В. Федоров. - М.: МГИУ, 2008. - 280 c.
Приложение 1 – Схема иерархии бизнес-процессов организации
Рис.2.Схема бизнес-процессов

Приложение 2 – DFD-диаграмма сети основных бизнес-процессов организации
Рисунок 11 – DFD-диаграмма сети основных бизнес-процессов организации
Приложение 3 – Контекстная диаграмма верхнего уровня в нотации IDEF0
Рисунок 12 – Контекстная диаграмма А0

Приложение 4 – Диаграммы декомпозиций
Рисунок 13 – Декомпозиция диаграммы А0

Рисунок 14 – Декомпозиция диаграммы А1

Рисунок 15 – Декомпозиция диаграммы А2

Рисунок 16 – Декомпозиция диаграммы А3

Приложение 5 – Физическая модель данных
Рисунок 17 – Физическая модель данных

Приложение 6 – Диаграмма вариантов использования
Рисунок 18 – Диаграмма вариантов использования
Приложение 7 – Диаграмма классов
Рисунок 19 – Диаграмма классов
Приложение 8 – Интерфейс пользователя
Рисунок 20 – Интерфейс пользователя
Приложение 9 - Затраты на покупку оборудованияНаименование Количество Цена за 1 шт. Общая сумма
Основное оборудование
Экструдер 2 150 200 300 400
Пакетоделательная машина 2 450 000 900 000
Оборудование для запайки пакетов 1 37 000 37 000
Аппарат для нанесения печати 1 150 000 150 000
Коронатор2 63 000 126 000
Пресс для вырубки ручек 1 120 000 120 000
Итого: 1 633 400
Оборудование для администрации
Стол 2 4 000 8 000
Стул 2 2 000 4 000
Компьютер 2 25 000 50 000
Телефон 1 3 000 3 000
Итого: 65 000
Оборудование для персонала
Микроволновая печь 1 5 000 6 000
Электрический чайник 1 3 000 3 000
Спецодежда 6 2 000 12 000
Шкаф 1 5 000 5 000
Итого: 26 000
Общая сумма: 1 724 400

Приложение 10 – Техническое задание1.Общие сведения.
1.1. Наименование системы: информационная система учета процесса продажи пакетов. Краткое наименование: ИСУПП.
1.2. Основание для проведения работ.
Работа выполняется на:
основании договора №1 от 22 января 2021 г. между Гуровым Романом Андреевичем и руководителем ИП «Производство пакетов» Ивановым Иван Ивановичем;
основании Приказа №56 от 10.05.2020
основании Распоряжение №35 от 11.05.2020.
Наименование организаций Заказчика и Разработчика.
1.3.1 Заказчик.
Заказчик: ИП «Производство пакетов» Адрес: г. Тула, ул. Октябрьская, 48. Телефон/Факс: +7(4857)705-55-55Банковские реквизиты: ИП «Производство пакетов» ИНН 7501004321, р/сч № 40603410800020007021 в АКБ Сбербанк России,БИК 044579857, корр. счет № 30101820400000000335
Разработчик: Гуров Роман Андреевич
Паспорт:
выдан: Миграционным пунктом в г. Заозерск межрайонного отдела УФМС России по Мурманской области в г. Североморск, дата выдачи: 07.11.2016,
серия: 7156 номер: 553144, Зарегистрирован по адресу: г. Тула, ул. Победы, 57, кв. 5
Телефон/Факс: +7(999)000-00-00/+7(0000)040-70-77ИНН 509999942843, р/сч № 5001982011179527 в Тинькофф Банк, БИК 830244835, корр. счет № 301865269323183
1.4. Плановые сроки начала и окончания работы
1.4.1. Плановые сроки начала работы 22 января 2020 г.
1.4.2. Плановые сроки окончания работы 31 марта 2021 г.
1.5. Источники и порядок финансированияПорядок финансирования работ определяется условиями Договора №1.
1.6. Порядок оформления и предъявления заказчику результатов работ
Работы по созданию ИСУПП сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором №1.
Назначение и цели создания системы
2.1. Назначение системы
ИСУПП предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика. Основным назначением ИСУПП является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика. В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах: информационная поддержка процессов организации услуг ИП «Производство пакетов», анализа финансово-хозяйственной деятельности, обеспечение полноты, достоверности и оперативности получения отчетной информации.
2.2. Цели создания системы
ИСУПП – прикладное программное обеспечение, предназначенное для:
формирования заказов;
регистрации клиентов;
формирования платежных документов;
обеспечения сбора и первичной обработки исходной информации, необходимой для подготовки недельного отчета руководителю.
Характеристика объектов автоматизации
Объектом автоматизации является набор процессов, указанных в материалах предпроектного обследования «Анализ предметной области»:
описание организационной структуры см. в разделе 1.1.2.;
бизнес-процессы, выполняемые в структурных подразделениях Заказчика см. в приложении 1 «Схема иерархии бизнес-процессов организации».
Требования к системе
4.1. Требования к системе в целом
4.1.1. Требования к численности и квалификации персонала системы и режиму его работы
4.1.1.1. Требования к численности персонала
В состав персонала, необходимого для обеспечения эксплуатации ИСУПП необходимо выделение следующих ответственных лиц:
Директор - 1 человек.
Менеджер по продажам – 1 человек.
Рабочие - 6 человек.
Данные лица должны выполнять следующие функциональные обязанности:
Руководитель отвечает за развитие фирмы, распределение обязанностей между рабочими, принимает активное участие в работе с поставщиками, бухгалтерией, закупками сырья.
Менеджер по продажам занимается взаимодействием с клиентами, организацией продаж партий товара, рекламным сопровождением фирмы.
Рабочие выполняют обязанности по изготовлению продукции.
4.1.2.2. Требования к квалификации персонала
Пользователи ИС должны иметь базовые навыки работы с операционными системами Microsoft (любая из версий), офисным программным обеспечением Microsoft Office и Open Office.
Техническое обслуживание и администрирование оборудования АСУ должно выполняться специалистами, имеющими соответствующую квалификацию и навыки выполнения работ.
4.1.2.3. Требования к режимам работы персоналаПерсонал, работающий с системой ИСУПП и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:
Директор работает 5 дней в неделю по 8 часов. График работы — 5 рабочих дня через 2 выходных дня.
Руководитель имеет гибкий график работы.
Менеджер по продажам работает 5 дней в неделю по 8 часов. График работы – 5 рабочих дня через 2 выходных дня.
Рабочий работает 5 дней в неделю по 8 часов. График работы – 5 рабочих дня через 2 выходных дня.
4.1.3. Показатели назначения
4.1.3.1. Параметры, характеризующие степень соответствия системы назначению.
Система должна обеспечивать следующие количественные показатели, которые характеризуют степень соответствия ее назначению:
расчетное количество пользователей - 3;
количество одновременно выполняемых запросов к БД - 1;
хранение информации об оказанных образовательных услуг в течение 2-х лет;
формирование недельного отчета о работе ИП «Производство пакетов».
Целевое назначение системы должно сохраняться на протяжении всего срока эксплуатации ИСУПП. Срок эксплуатации ИСУПП определяется сроком устойчивой работы аппаратных средств вычислительных средств, своевременным проведением работ по замене (обновлению) аппаратных средств, по сопровождению программного обеспечения системы и его модернизации. Время выполнения запросов информации определяется на стадии проектирования системы. Специальные требования к вероятностно-временным характеристикам, при которых сохраняется целевое назначение ИСУПП, определяются соответствующими требованиями к прикладным системам.
4.1.3.2. Требования к приспособляемости системы к изменениямОбеспечение приспособляемости системы должно выполняться за счет:
модернизации оборудования;
своевременности администрирования;
модернизации процессов сбора, и обработки данных в соответствии с новыми требованиями.
4.1.3.3. Требования к сохранению работоспособности системы в различных вероятных условиях
В зависимости от различных вероятных условий система должна выполнять требования, приведенные в таблице 1.
Таблица 4 – Требования к сохранению работоспособности
Вероятное условие Требование
Нарушения в работе системы внешнего электроснабжения продолжительностью до 15 мин. Функционирование в полном объеме.
Нарушения в работе системы внешнего электроснабжения продолжительностью свыше 15 мин. Переход на ручную обработку данных
Выход из строя компьютера администратора Уведомление руководителя
Переход на ручную обработку данных
4.1.4. Требования к надежности
4.1.4.1. Состав показателей надежности для системы в целом
Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств.
Надежность должна обеспечиваться за счет:
применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
своевременного выполнения процессов администрирования;
соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
предварительного обучения пользователей и обслуживающего персонала.
Время восстановления работоспособности прикладного ПО АСУ при любых сбоях и отказах не должно превышать одного рабочего дня.Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла системы;
при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;
при ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
Для защиты аппаратуры от бросков напряжения и коммутационных помех должны применяться сетевые фильтры. Должно осуществляться разграничение прав доступа к системе. Должен вестись журнал событий системы.
4.1.4.2. Перечень аварийных ситуаций, по которым регламентируются требования к надежности
Под аварийной ситуацией понимается аварийное завершение процесса, выполняемого той или иной подсистемой, а также «зависание» этого процесса.
При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:
сбой в электроснабжении;
ошибки Системы, не выявленные при отладке и испытании системы;
сбои программного обеспечения.
4.1.4.3. Требования к надежности технических средств и программного обеспечения
К надежности оборудования предъявляются следующие требования:
в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;
применение технических средств соответствующих классу решаемых задач;
аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев.
К надежности электроснабжения предъявляются следующие требования:
с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация ПК источником бесперебойного питания с возможностью автономной работы системы не менее 15 минут;
система должны быть укомплектована агентами автоматической остановки операционной системы в случае, если перебой электропитания превышает 15 минут.
Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:
предварительного обучения пользователей и обслуживающего персонала;
своевременного выполнения процессов администрирования;
соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
своевременное выполнение процедур резервного копирования данных.
Надежность программного обеспечения подсистем должна обеспечиваться за счет:
надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;
проведением комплекса мероприятий отладки, поиска и исключения ошибок.
ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.
4.1.4.4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.
Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации - по методике Разработчика, согласованной с Заказчиком.
4.1.5. Требования к эргономике и технической эстетикеПодсистема формирования данных должна обеспечивать удобный для конечного пользователя интерфейс, отвечающий следующим требованиям.
В части внешнего оформления:
интерфейсы подсистем должен быть типизированы;
должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя;
должен использоваться шрифт: Times New Romanразмер шрифта должен быть: 12-14 кеглей
цветовая палитра должна быть: стандартная
в шапке отчетов должен использоваться логотип Заказчика.
В части диалога с пользователем:
для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке.
Настраиваемость графических элементов интерфейса, в том числе цветового оформления, в пределах возможностей операционной системы.
Интерфейс должен обеспечивать удобную навигацию в диалоге с пользователем, который хорошо знает свою предметную область и не является специалистом в области автоматизации. Интерфейсы по подсистемам должен быть типизированы.Наличие контекстно-зависимой помощи.
Для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
При возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке.Должна быть возможность получения отчетности по мониторингу работы подсистем.
4.1.6. Требования к антивирусной защите
Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;
автоматическую инсталляцию клиентского ПО на рабочих местах пользователей;
автоматическое обновление вирусных сигнатур на рабочих местах пользователей и администраторов;
ведение журналов вирусной активности;
администрирование всех антивирусных продуктов.
4.1.7. Требования по сохранности информации при авариях.
В Системе должно быть обеспечено резервное копирование данных. Выход из строя жесткого диска не должен сказываться на работоспособности подсистемы хранения данных. Должна обеспечиваться сохранность информации при отказе оборудования. Средствами обеспечения сохранности информации при авариях и сбоях в процессе эксплуатации являются:
носители информации (сменные: оптические - дисковые или магнитные - ленточные, накопители на сменных жестких дисках);
создание резервной копии базы данных;
создание резервной копии программного обеспечения.
Для восстановления данных и программного обеспечения из резервной копии должны использоваться средства резервного копирования и архивирования. ИС должна обеспечивать возможность резервирования всех данных, а также возможность их восстановления. Резервное копирование данных должно осуществляться эксплуатационным персоналом ежедневно, автоматически или вручную по расписанию. Вид резервного копирования – инкрементальный (копирование только изменений с предыдущего копирования), но при этом не реже раза в неделю должно производиться и полное копирование. Должна быть предусмотрена возможность восстановления данных за день сбоя с помощью их повторного ввода
4.1.8. Требования по стандартизации и унификации
Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации РД 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х.
Для работы с БД должен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.Для разработки пользовательских интерфейсов и средств генерации отчетов должны использоваться встроенные возможности ПО. В системе должны использоваться общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.
4.1.9. Требования безопасности
Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.
Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».
Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:
50 дБ - при работе технологического оборудования и средств вычислительной техники без печатающего устройства;
60 дБ - при работе технологического оборудования и средств вычислительной техники с печатающим устройством.
4.2. Требования к видам обеспечения
4.2.1 Требования к математическому обеспечению не предъявляются.
4.2.2. Требования к информационному обеспечению
В системе должна быть создана база данных. Физическая модель данных приведена в материалах анализа предметной области, раздел 3.2. «Модели данных», приложение 6. «Физическая модель данных». Внутреннее устройство системы отражено в диаграмме классов, описывающей создаваемую программную систему через ее компоненты (классы, объекты), отношения и взаимодействия между ними. Она приведена в приложение 8. «Диаграмма классов» анализа предметной области.
Состав, структура и способы организации данных в системе должны быть определены на этапе технического проектирования. Уровень хранения данных в системе должен быть построен на основе современных реляционных или объектно-реляционных СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.
Средства СУБД, а также средства используемых операционных систем должны обеспечивать документирование и протоколирование обрабатываемой в системе информации. Доступ к данным должен быть предоставлен только авторизованным пользователям с учетом их служебных полномочий, а также с учетом категории запрашиваемой информации. Структура базы данных должна быть организована рациональным способом. Технические средства, обеспечивающие хранение информации, должны использовать современные технологии, позволяющие обеспечить повышенную надежность хранения данных и оперативную замену оборудования. Информация в базе данных системы должна сохраняться при возникновении аварийных ситуаций, связанных со сбоями электропитания.
Система должна иметь бесперебойное электропитание, обеспечивающее её нормальное функционирование в течение 15 минут в случае отсутствия внешнего энергоснабжения, и 5 минут дополнительно для корректного завершения всех процессов.
Резервное копирование данных должно осуществляться на регулярной основе, в объёмах, достаточных для восстановления информации в подсистеме хранения данных
4.2.2.1. Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы
Кассовый чек (фискальный) выдается непосредственно при осуществлении услуги и его оформление происходит на основании данных в кассовом аппарате.
Обязательное количество реквизитов:
название организации;
индивидуальный номер предприятия (фирмы);
регистрационный номер контрольно-кассового аппарата;
порядковый номер чека (расчет номера ведется за рабочую смену);
дата и время, когда осуществился расчет за услугу;
фискальный признак кассового чека; -место произведения расчета (почтовый индекс);
название услуги и стоимость выполненных услуг;
общее количество услуг уже с учетом скидок (при их наличии);
система налогообложения, на которой находится фирма, осуществляющая реализацию услуги;
форма осуществления расчета за покупку (наличными , по безналичному расчету) и сумма оплаты;
признак произведенного расчета по соответствующей классификации: приход, возврат прихода, расход и возврат расхода.
Квитанция на оплату услуг - приравненный к кассовому чеку – бланк строгой отчетности, который оформляется вручную.  Квитанция об оплате услуг должна содержать следующие реквизиты:
Название, номер квитанции (состоит из 6 знаков), серию;
Наименование исполнителя (реквизиты предпринимателя);
Место нахождения исполнителя услуги, присвоенный налогоплательщику ИНН;
Вид оказанной услуги;
Стоимость услуги и способ ее оплаты (наличный или безналичный расчет);
Дата, когда был осуществлен расчет и когда был составлен данный документ.
Бланк квитанции об оплате услуг содержит указание лица, который ответственен за заполнение бланка, его подпись, печать компании (при ее наличии). Компания и предприниматель имеют право дополнить бланк иными реквизитами, необходимыми для описания характеристик оказываемой услуги. Бланки строгой отчетности при оказании услуг населению изготавливаются в типографии или с использованием автоматизированных систем.
4.2.3. Требования к техническому обеспечению
Проект может функционировать без серверной части.Клиентская часть:
Процессор: Intel Celeron J4025D, 2 ГГц (2.9 ГГц, в режиме Turbo), двухъядерный
Установленная оперативная память: (RAM) SO-DIMM, DDR4 4096 Мб 2133 МГц
Имя ОС: Майкрософт Windows 10 ProВерсия: 10.0.17134 Сборка 17134
Видеоадаптер: Intel UHD Graphics 600
Разработка мобильной части не предусмотрена.
4.2.5. Требования к метрологическому обеспечению
Не предъявляются.
4.2.6. Требования к организационному обеспечению
Основными пользователями системы ИСУПП являются сотрудники функционального подразделения Заказчика. Состав сотрудников определяется штатным расписанием Заказчика, которое, в случае необходимости, может изменяться.
В случае возникновения изменения функциональности системы ИСУПП, пользователи должны действовать следующим образом:уведомить директора о необходимости доработки системы;
информировать всех пользователей (за 3 дня) о переходе системы в профилактический режим.
К защите от ошибочных действий персонала предъявляются следующие требования:
должна быть предусмотрена система подтверждения легитимности пользователя при просмотре данных;
для всех пользователей должна быть запрещена возможность удаления пред настроенных объектов и отчетности;
для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя.
5. Состав и содержание работ по созданию системы
Осуществление всего комплекса работ по созданию должно осуществляться в несколько очередей. Спецификация работ по созданию ИСУПП в объеме требований настоящего ТЗ приведена в 3.
Таблица 5 – Состав и содержание работ по созданию системы
Стадия работ Выполняемые работы Сроки Итоги выполнения работы
Формирование требований Обследование объектов автоматизации 4 часа Отчет о результатах обследования
Разработка Технического задания на создание ИСФ 4 часа Утверждение заказчиком ТЗ на создание ИСШАЯ «EG»
Проектирование Разработка Технического проекта
Разработка прототипа ИСУПП 16 час Технический проект
Спецификации программно-аппаратных средств
Разработка проектов организационно-распорядительной, программной и эксплуатационной документации Поставка программно-технических средств для опытной эксплуатации Поставка программно-технических средств (лицензинное ПО) для опытной эксплуатации на ПК 5 часов Акты
Разработка программных средств Разработка, отладка и тестирование программных средств ИСУПП 15 часов Программные средства на машиночитаемых носителях. Комплект проектов организационно-распорядительной, программной и эксплуатационной документации на ИСУПППриемка работ Проведение предварительных испытаний 2 час Протоколы испытаний. Акт готовности подсистемы к развертыванию в опытной зоне
Рабочая документация Разработка рабочей документации на системном и ее части. 2 час Подтверждение рабочей документации
Разработка или адаптация программ. 6. Порядок контроля и приёмки системы
Система подвергается испытаниям следующих видов:
Предварительные испытания.
Опытная эксплуатация.
Приемочные испытания.
Состав, объем и методы предварительных испытаний системы определяются документами «Программа и методика испытаний», разрабатываемым на стадии «Рабочая документация».Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».
Состав, объем и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Ввод в действие» с учетом результатов проведения предварительных испытаний и опытной эксплуатации.Сдача-приёмка работ производится поэтапно, в соответствии с рабочей программой и календарным планом, являющимися приложениями к Договора №1 от 22 января 2020 г.
Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии.
Все создаваемые в рамках настоящей работы программные изделия (за исключением покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (например, на компакт-диске). Статус приемочной комиссии определяется Заказчиком до проведения испытаний
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действиеДля создания условий функционирования ИСУПП, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в настоящем техническом задании, и возможность эффективного её использования, в организации Заказчика должен быть проведен комплекс мероприятий. Силами Заказчика в срок до начала этапа «Разработка рабочей документации. Адаптация программ» должны быть выполнены следующие работы:
осуществлена подготовка помещения для размещения ПК системы в соответствии с требованиями, приведенными в настоящем техническом задании;
осуществлена закупка и установка необходимого оборудования.
Силами Заказчика в срок до начала этапа работ «Разработка рабочей документации. Адаптация программ» должны быть решены организационные вопросы по взаимодействию с системами-источниками данных. К данным организационным вопросам относятся:
организация доступа к базам данных источников;
определение регламента информирования об изменениях структур систем-источников;
выделение ответственных специалистов со стороны Заказчика для взаимодействия с проектной командой по вопросам взаимодействия с системами-источниками данных
8. Требования к документированию
Таблица 6 – Требования к документированию
Этап Документ
Проектирование. Разработка технического проекта. Ведомость технического проекта
Пояснительная записка к техническому проектуСхема функциональной структурыРазработка рабочей документации. Адаптация программ Ведомость эксплуатационных документов
Ведомость машинных носителей информации
Технологическая инструкция
Руководство пользователяОписание технологического процесса обработки данных
Инструкция по формированию и ведению базы данных (набора данных)
Состав выходных данных
Каталог базы данныхПрограмма и методика испытанийСпецификация
Описание программ
Текст программ
Ввод в действие Акт приёмки в опытную эксплуатациюПротокол испытанийАкт приемки Системы в промышленную эксплуатацию
Акт завершения работ
Документы должны быть представлены в бумажном виде (оригинал) и на машинном носителе (копия). Исходные тексты программ - только машинном носителе (оригинал). Все документы должны быть оформлены на русском языке. В ходе создания ИСУПП должен быть подготовлен и передан Заказчику комплект документации в составе:
проектная документация и материалы техно-рабочего проекта на разработку ИС;
конструкторская, программная и эксплуатационная документация на Подсистему;
сопроводительная документация на поставляемые программно-аппаратные средства в комплектности поставки заводом-изготовителем;
предложения по организации системно-технической поддержки функционирования Подсистемы.
Состав и содержание комплекта документации на ИСУПП может быть уточнен на стадии проектирования. Подготовленные документы должны удовлетворять требованиям государственных стандартов и рекомендаций по оформлению, содержанию, форматированию, использованию терминов, определений и надписей, обозначений программ и программных документов.