Эти разделы подробно описаны в гост 34. 602-89, но особенно следует обратить внимание на следующие моменты.

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

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

В разделе «Порядок контроля и приемки системы» указывают виды (приемочные испытания, опытная эксплуатация и приемочные испытания), состав, объем и методы испытаний системы на основе стандарта ГОСТ 34.603-92. Рекомендуется указать кто (разработчик или заказчик) разрабатывает программу и методики испытаний.

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

(Можно вставить раздел, определяющий состав ОБЕСПЕЧИВАЮЩИХ ПОДСИСТЕМ)

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

· процедуры;

· функции.

Такой подход, в частности, поддерживается инструментами 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.11) представлен в Таблице 1.

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

Пример описания фрагмента пользовательского интерфейса (рис. 3.15):

При нажатии на кнопку «Ввод сведений о пациенте» (рис. 3.16) запускается модуль

pacient, открывается форма «Сведения о пациенте».

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

Таблица 1 pacient

Имя поля	Тип поля	Размер поля	Смысловое содержание
ID_Pacient	Числовой		код пациента
Familia	Текстовый		фамилия
Name	Текстовый		имя
Otchestvo	Текстовый		отчество
CNILS	Числовой		страховой номер лицевого счета

Рисунок 3.15 - Учет выданных талонов и сведений о пациенте

Рисунок 3.16 - Форма «Сведения о пациенте»

 

Документ «Описание организации информационной базы» содержит разделы:

· входная информация;

· выходная информация;

· логическая структура базы данных;

· физическая структура базы данных.

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

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

В разделе «Логическая структура» приводят описание состава данных, их форматов и взаимосвязей между данными (ER-диаграмма).

В разделе «Физическая структура» приводят описание избранного варианта расположения данных в среде конкретного СУБД.

Документ Структурная схема комплекса технических средств содержит схему размещения технических средств (рис. 3.17, 3.18) с краткой аннотацией. Например, в состав комплекса технических средств входят следующие технические средства:

· серверы БД;

· серверы приложений;

· сервер системы формирования отчетности;

· веб-сервер;

· ПК пользователей;

· ПК администраторов.

Рисунок 3.17 - Структурная схема комплекса технических средств №1

Рисунок 3.18 - Структурная схема комплекса технических средств №2

 

Серверы БД объединены в отказоустойчивый кластер. Связь между серверами БД и хранилищем данных осуществляется по оптическому каналу. Серверы приложений образуют кластер с балансировкой нагрузки. Серверы БД, серверы приложений и сервер системы формирования отчетности объединены одной локальной сетью, с пропускной способностью 100 Мбит [Греков].

На этапе «Технического проектирования» завершается проектирование и начинается этап «Рабочее проектирование», на котором осуществляется создание программного продукта с помощью программных инструментариев, предназначенных для этих целей, например с помощью средства быстрой разработки Delphi, Oracle Developer 10g и др. и разработка всей сопровождающей документации.