Эти разделы подробно описаны в ГОСТ 34.602-89, но особенно следует обратить внимание на следующие моменты.

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

В последнее время рекомендуется разрабатывать профиль стандартов на разрабатываемую ИС и утверждать его в составе ТЗ.

После утверждения ТЗ разработчик и заказчик заключают контракт на разработку ИС, с указанием этапов выполнения работ, сроков их выполнения и стоимости.

3.2.1.3. Стадия «Проектирование»

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

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

· проектирование процессов;

· проектирование объектов данных;

· проектирование программ, экранных форм, отчетов;

· разработка архитектуры ИС.

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

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

· процессы верхнего уровня;

· подпроцессы;

· сценарии процессов;

· процедуры;

· функции.

Такой подход, в частности, поддерживается инструментами AllFusion Process Modeler (BPwin), Process Modeler (СУБД Oracle). Детализация (декомпозиция) — это условный прием, позволяющий представить систему в виде, удобном для восприятия и анализа, как для разработчиков, так и для представителей заказчика.

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

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

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

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

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

Этап «Техническое проектирование» является самым ответственным и решающим в успешном завершении разработки ИС.Этап выполняется на основе стандарта РД 50-34.698-90, результатом его выполнения является технический проект. Технический проект ИС содержит основные проектные решения по системе в целом, ее функциям и всем видам обеспе-чения ИС, которых должно быть достаточно для разработки программных кодов и рабочей документации. В стандарте ГОСТ 34.201-89 приведены более 20 документов, которые следует разработать на этом этапе (пояснительная записка к техническому проекту, ведомость технического проекта, перечень входных сигналов и данных, перечень выходных сигналов (документов), описание автоматизируемых функций, описание информационного обеспечения системы, описание организации информационной базы, описание комплекса технических средств и др.). Содержание этих документов приведено в стандарте РД 50-34.698-90.

Для упрощения оформления документации для этапа «Технический проект» предлагаются так называемые«Утвержденные спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты». Эти спецификации требований являются основой для детального планирования процесса разработки программных средств и их компонентов. Под спецификациями требований понимается формальное описание свойств объектов будущего про-граммного продукта: программных модулей, таблиц БД и элементов пользовательского интерфейса.

Поэтому в упрощенном варианте для дипломного проекта рекомендуется следующий комплект документов на этапе технического проекта:

· пояснительная записка к техническому проекту;

· спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты;

· описание организации информационной базы;

· структурная схема комплекса технических средств.

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

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

· программные модули;

· таблицы БД;

· элементы пользовательского интерфейса.

Спецификации для программного модуля содержат назначение и характеристики каждого программного модуля(постановка задачи, общие требования к входным и выходным данным, описание алгоритма функцио-нирования)и результаты выполнения модуля (выходной документ, экранная форма и т.п.).В качествепрограммных модулейописываютсявсе функциональные блоки нижнего уровня иерархиимодели «TO BE» (рис. 3.9).

Спецификации для каждого программного модуля выглядят следую-

щим образом:

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

· паспорт модуля – содержит:

o описание всех входных данных (полей таблиц БД), необходимых для выполнения модуля;

o функциональную схему модуля (блок-схему алгоритма или ссылку на реализуемую выходную или экранную форму).

Пример оформления спецификации на программный модуль kart_disp:

Модуль «Формирование карты диспансеризации» (kart_disp).

Назначение: формирование карты диспансеризации.

Входные данные: pacient.familia, pacient.name, pacient.otchestvo, pacient.pol, pacient.OMC, pacient.SNILS, pacient.data_rog, pacient.adres, pacient.tel, pacient.rabota, pacient.OKBЭD.

Выходные данные: карта диспансеризации, в соответствие с рис. 3.14.

Спецификации для таблиц БД содержат описание каждого поля таблиц (тип и размер поля, его смысловое значение). Пример спецификации для таблицы pacient (рис. 3.14) представлен в Таблице 1.

Рис. 3.14. Бланк карты диспансеризации

Таблица 1.