![]() Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву ![]() Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Эти разделы подробно описаны в гост 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
Рисунок 3.15 - Учет выданных талонов и сведений о пациенте Рисунок 3.16 - Форма «Сведения о пациенте»
Документ «Описание организации информационной базы» содержит разделы: · входная информация; · выходная информация; · логическая структура базы данных; · физическая структура базы данных. Раздел «Входная информация» должен содержать перечень и описание входных сообщений: наименование, форму представления, сроки и частоту поступления, а также источник информации (документ, видеокадр, устройство, информационная база на машинных носителях и т.д.). Раздел «Выходная информация» содержит перечень и описание выходных сообщений: наименование, форму представления сообщения (документ, видеокадр, сигнал управления), периодичность выдачи, сроки выдачи и допустимое время задержки решения; получателей и назначение выходной информации. В разделе «Логическая структура» приводят описание состава данных, их форматов и взаимосвязей между данными (ER-диаграмма). В разделе «Физическая структура» приводят описание избранного варианта расположения данных в среде конкретного СУБД.
Документ Структурная схема комплекса технических средств содержит схему размещения технических средств (рис. 3.17, 3.18) с краткой аннотацией. Например, в состав комплекса технических средств входят следующие технические средства: · серверы БД; · серверы приложений; · сервер системы формирования отчетности; · веб-сервер; · ПК пользователей; · ПК администраторов. Рисунок 3.17 - Структурная схема комплекса технических средств №1 Рисунок 3.18 - Структурная схема комплекса технических средств №2
Серверы БД объединены в отказоустойчивый кластер. Связь между серверами БД и хранилищем данных осуществляется по оптическому каналу. Серверы приложений образуют кластер с балансировкой нагрузки. Серверы БД, серверы приложений и сервер системы формирования отчетности объединены одной локальной сетью, с пропускной способностью 100 Мбит [Греков]. На этапе «Технического проектирования» завершается проектирование и начинается этап «Рабочее проектирование», на котором осуществляется создание программного продукта с помощью программных инструментариев, предназначенных для этих целей, например с помощью средства быстрой разработки Delphi, Oracle Developer 10g и др. и разработка всей сопровождающей документации.
|
|||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2016-08-26; просмотров: 522; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.118.55.243 (0.009 с.) |