Раздел 2. Техническое задание

2.1 Наименование и область применения разработки

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

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

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

Необходимо предоставить общее представление о создаваемой информационной системе и обосновать необходимость её создания.

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

§ снижение стоимости продукции;

§ увеличение количества или ассортимента;

§ сокращение цикла разработка новых товаров и услуг, выход на рынок;

§ переход от производства "на склад" к производству "под конкретного заказчика" с учетом индивидуальных требований и т.д.

Описание моделей бизнес-процессов объекта автоматизации

Рассмотрение исследуемого объекта предполагает построение двух видов моделей. На этом этапе необходимо построить модели «как есть» («as is»), отражающие существующее на момент обследования положение дел в предметной области и описывающие, каким образом функционирует данный объект. Построение моделей бизнес-процессов предметной области может быть выполнено с помощью различных методик, которые отличаются подходами к моделированию. Принято различать методики объектные и функциональные (структурные).

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

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

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

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

Для проведения моделирования разработаны различные методологии и соответствующие инструментальные средства. Методологии функционального моделирования (диаграммы потоков данных DFD, структурные диаграммы процессов IDEF0, ARIS) ориентированы на отображение последовательности функций. При их использовании трудно определить конкретные альтернативы процессов и увидеть схему взаимодействия объектов. Объектные модели, наоборот, отражают только обобщенную схему взаимодействия объектов без детализации последовательности выполнения функций. Методологии объектно-ориентированного подхода отражают объекты, функции и события, при которых объекты инициируют выполнение конкретных процессов. В качестве языка для описания моделей при объектно-ориентированном подходе выступает UML (Unified Modeling Language). UML применительно к бизнес моделированию может включать следующие диаграммы: Activity-диаграммы, Class-диаграммы, Component-диаграммы, Collaboration-диаграммы, Sequence-диаграммы, Use Case-диаграммы, Deployment-диаграммы, Statechart-диаграммы.

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

Определение недостатков существующей системы обработки информации

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

При этом следует сделать акцент на недостатки, устранение которых предполагается осуществить в проекте, например:

§ возможность появления ошибок при составлении документов;

§ высокая трудоемкость обработки информации;

§ низкая достоверность результатов решения задачи из-за дублирования потоков информации;

§ несовершенство организации сбора и регистрации исходной информации;

§ несовершенство защиты целостности и секретности информации и т.д.

2.2 Основание для разработки

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

2.3 Цели и назначение разработки

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

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

§ создание графического пользовательского интерфейса;

§ максимальная простота в использовании;

§ использование открытых программных систем при разработке АИС;

§ обеспечение взаимодействиями с различными серверами баз данных;

§ уменьшить нагрузку на сеть за счет использование отсоединенного механизма доступа к данным и т.д.

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

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

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

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

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

§ программное обеспечение должно обеспечивать одновременную работу до 100 пользователей с данными по локальной вычислительной сети и Internet и т.д.

Разрабатываемая информационная система должна выполнять основные функции. Например:

§ ведение базы сотрудников;

§ возможность ведения нескольких организаций в одной программе;

§ создание карточек сотрудников с расширенным личностным и профессиональным учетом;

§ возможность формирования приказов на базе шаблонов Word;

§ прием на работу новых сотрудников;

§ расчет отпусков, стажа и т.д.

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

2.4 Источник разработки

В данном разделе источник разработки – это источник разработки технического задания.

Должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

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

2.5 Постановка задачи

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

На этом этапе необходимо построить модели «как должно быть» («to be»), которые отражают изменения бизнес процессов с учетом внедрения информационной системы.

2.6 Алгоритм решения

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

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

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

2.7 Требования к системе

В данном разделе указывают:

· требования к структуре и функционированию системы;

· требования к защите информации от несанкционированного доступа;

· требования по сохранности информации приавариях;

· требования к защите от влияния внешних воздействий;

В требованиях к структуре и функционированию системы приводят:

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

· требования к способам и средствам связи для информационного обмена между компонентами системы;

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

· требования к режимам функционирования системы;

· требования по диагностированию системы;

· перспективы развития, модернизации системы.

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

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

В требованиях к средствам защиты от внешних воздействий приводят:

· требования к радиоэлектронной защите средств ПО;

· требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

2.8 Требования к надежности

В требования к надежности включают:

· состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

· требования к надежности технических средств и программного обеспечения;

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

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

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

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

· к составу, структуре и способам организации данных в системе;

· к информационному обмену между компонентами системы;

· к информационной совместимости со смежными системами;

· по применению систем управления базами данных;

· к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

· к защите данных от разрушений при авариях и сбоях в электропитании системы;

· к контролю, хранению, обновлению и восстановлению данных.

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

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

· к независимости программных средств и операционной среды;

· к качеству программных средств, а также к способам егообеспечения и контроля;

· по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

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

· к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

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

2.10 Эстетические и эргономические требования

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

2.11 Требования к стандартизации и унификации

В требования к стандартизации и унификации включают показатели, устанавливающие требуемую степень использования:

· стандартных, унифицированных методов реализации функций (задач) системы,

· поставляемых программных средств,

· типовых математических методов и моделей,

· типовых проектных решений,

· унифицированных форм управленческих документов, установленных ГОСТ 6.10.91,

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

· требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.