Студопедия Главная Случайная страница Задать вопрос

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

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





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

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

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

В разделе «Требования к документированию»приводят согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 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.






Дата добавления: 2015-08-30; просмотров: 268. Нарушение авторских прав

Studopedia.info - Студопедия - 2014-2017 год . (0.095 сек.) русская версия | украинская версия