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

http://www..ru/

Реферат

Дипломный проект содержит 112 страниц, 45 рисунков, 15 таблица, 46 источников, 6 приложения.

ИНФОРМАЦИОННАЯ СИСТЕМА, РАБОТА С ДАННЫМИ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, ФИЗИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ.

Темой дипломного проекта является «Разработка информационной системы предприятия по установке газового оборудования».

В качестве информационного обеспечения используется база данных под управлением СУБД Microsoft SQL Server 2005 Enterprise Edition.

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

Конечным результатом дипломного проекта является программный комплекс «Информационная система предприятия» внедренный и успешно применяемый в данном предприятии.

Abstract

The diploma project includes 112 pages of explanatory note, 45 pictures, 15 tables, 46 literary sources, 6 attachments.

THE INFORMATION SYSTEM, WORKING WITH DATA, INTERFACE, REQUIREMENTS, THE PRODUCT LIFE CYCLE MODEL, MODELLING, DESIGNING, REALIZATION, PHYSICAL MODEL OF DATA STRUCTURE, THE DATABASE, TESTING.

The title of the diploma project is «Designing of the Information System for the Gas Fitting Enterprise».

As an information source of the application, the database under control of DBMS Microsoft SQL Server 2005 Enterprise Edition is used.

The sources of the data for the diploma project were books, periodicals, electronic resources, documents of the organization that were used as theoretical basis for solving the problem. The literary sources were also used as manuals for the project realisation.

The end product of the diploma project is a software package called «the Information System of the Enterprise» implemented and successfully applied in this gas fitting enterprise.

1. Разработка требований к программному обеспечению

1.1 Анализ предметной области

1.2 Анализ существующих решений по автоматизации предметной области

1.3 Выбор методологии проектирования информационной системы

1.4 Сбор требований

1.5 Спецификация требований

1.6 Анализ и моделирование требований

1.7 Аттестация требований

2 Проектирование информационной системы

2.1 Архитектурное проектирование

2.2 Проектирование пользовательского интерфейса

2.3 Проектирование базы данных

2. 4Обоснование выбора платформы создания информационной системы

3 Реализация и аттестация информационной системы

3.1 Реализация приложения

3.2 Взаимодействие приложения с источниками данных

3.3 Тестирование приложения

3.4Методика развертывания приложения

4 Управление информационным проектом

4.1 Выбор жизненного цикла разработки информационной системы

4.2 Определение цели и области действия программного проекта

4.3 Создание структуры пооперационного перечня работ

4.4 Идентификация задач и действий

4.5 Оценка размера и возможности повторного использования ПО

4.6 Оценка длительности и стоимости разработки проекта

4.7 Распределение ресурсов проекта

4.8 Оценка экономической эффективности проекта Заключение Список сокращений Список используемых источников Приложение, А — спецификация требований к программному обеспечению Приложение Б — Атрибуты управляющих таблиц проектируемой ИС Приложение В — Скрипт базы данных информационной системы Приложение Г — Фрагмент исходного кода программы Приложение Д? Обоснование выбора модели жизненного цикла Приложение Е — Диаграмма ганта

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

Рассматриваемая дипломная работа написана на базе предприятия по установке газового оборудования ИП Попов Г. В. «ДонГаз» г. Донецк.

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

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

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

— работу с входными данными;

— получение выходных документов;

— формирование отчетов.

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

Для достижения вышеуказанной цели необходимо решить следующие задачи:

— осуществить бизнес-моделирование процессов предприятия, для разрабатываемой информационной системы;

— провести анализ требований к системе и ее проектирование;

— разработать концептуальную и физическую модели данных;

— провести оценку эффективности технологии разработки.

1. Разработка требований к программному обеспечению

1.1 Анализ предметной области

Целью программного комплекса, разработанного в рамках дипломного проекта, является автоматизация деятельности предприятия по установки газового оборудования «ДонГАЗ».

Для того чтобы внести ясность в понятия газификации, воспользуемся определениями, данными в Федеральном законе от 31.03.1999 N69 ФЗ «О ГАЗОСНАБЖЕНИИ В РОССИЙСКОЙ ФЕДЕРАЦИИ».

Федеральная система газоснабжения — совокупность действующих на территории Российской Федерации систем газоснабжения: Единой системы газоснабжения, региональных систем газоснабжения, газораспределительных систем и независимых организаций. Федеральная система газоснабжения является одной из федеральных энергетических систем Российской Федерации.

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

Основами создания и развития единого рынка газа на территории Российской Федерации являются:

— формирование круга потребителей газа на основе широкого внедрения газа как энергетического и топливного ресурса в производство и быт на территориях субъектов Российской Федерации — развитие газификации;

— создание экономически взаимовыгодных отношений потребителей и поставщиков газа;

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

— проведение государственной политики ценообразования, направленной на развитие единого рынка газа.

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

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

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

Примерами бизнес — актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес — актеров состоит в том, что они являются инициаторами или клиентами бизнес — процессов моделируемой системы.

Сотрудник (business worker) — индивидуум, который действует внутри моделируемой бизнес системы, взаимодействует с другими сотрудниками и является участником бизнес — процесса моделируемой системы.

Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том, что они являются субъектами и входят в состав моделируемой системы.

Бизнес вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес — процесса.

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

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

На рисунке 1.1 представлена схема бизнес-процесса по формированию заказа клиента.

Рисунок 1.1 — Бизнес-процесс «Формирование заказа клиента»

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

На рисунке 1.2 представлена схема бизнес-процесса расчет с клиентом.

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

Рисунок 1.2 — Бизнес-процесс «Расчет с клиентом»

На рисунке 1.3 представлена схема бизнес-процесса контроль по срокам гарантии.

Рисунок 1.3 — Бизнес-процесс «Контроль по срокам гарантии»

Целью данного бизнес-процесса является контроль по срокам гарантии установленного оборудования. Этот бизнес-процесс является неотъемлемой частью взаимодействия с клиентом.

На рисунке 1.4 представлена схема бизнес-процесса формирование заказа на оборудование.

Рисунок 1.4 — Бизнес-процесс «Формирование заказа на оборудование»

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

На рисунке 1.5 представлена схема бизнес-процесса формирование прайса оборудования.

Рисунок 1.5 — Бизнес-процесс «Формирование прайса оборудования»

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

Рисунок 1.6 — Бизнес-процесс «Составление плана работ»

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

На рисунке 1.7 представлена схема бизнес-процесса составление индивидуального плана работ для внештатных сотрудников.

Рисунок 1.7 — Бизнес-процесс «Составление индивидуального плана работ для внештатных сотрудников»

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

На рисунке 1.8 представлена схема бизнес-процесса составление акта о выполненной работе.

Рисунок 1.8 — Бизнес-процесс «Составление акта о выполненной работе»

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

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

На рисунке 1.9 представлены объекты, составляющие бюджетную классификацию Российской федерации. В таблице 1.1 представлена расшифровка объектов представленных на рисунке 1.9.

Рисунок 1.9 — Объекты и сущности предметной области Таблица 1.1 — Объекты и сущности предметной области

1.2 Анализ существующих решений по автоматизации предметной области

Среди существующих программных решений по автоматизации следует отметить автоматизированную информационную систему «Информационная система предприятия» Разработчик: «ИНФОРЕСУРС», на платформе «1С:Предприятие 8». Конфигурация имеет сертификат «Совместимо! Система программ 1С: Предприятие» и позволяет эффективно организовать работу с документами в электронной форме.

Основные возможности программы:

— единый архив документов и справочной информации;

— ведение справочников, хранящих контактную и другую информацию об организации, сотрудниках, контрагентах и физических лицах;

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

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

— возможность работы с электронной почтой и хранение всей корреспонденцию.

Канцелярия:

— регистрация первичных документов и хранение их электронных копий;

— формирование реестров документов;

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

— учет важных документов по местам хранения;

— работа со списками документов — группировки документов в дела;

— автоматизация документооборота;

— все документы системы включены в систему документооборота;

— схемы обработки (маршруты движения) документов доступны для редактирования и настройки под особенности работы;

— организация очередей обработки документов.

Другие возможности:

— напоминания;

— оперативный журнал событий, заданий;

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

— аудит действий пользователя в системе;

— средства совместной работы над документами — блокировки, удостоверение содержания;

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

Технические особенности реализации: Конфигурация для своей работы требует установленную программную оболочку «1С:Предприятие 8», не защищена аппаратным ключом и поставляется с исходными текстами модулей. Фрагменты конфигурации, отвечающие за использования внешних справочников через Интернет, обмен документами, поставляются без исходных текстов и не могут быть изменены. В конфигурации предусмотрена возможность локализации и работа пользователей на нескольких языках в рамках одной информационной базы. Особенности лицензирования: Основная поставка дает право на работу с одной информационной базой (информационная база может быть распределенной) и не ограничивает пользователя рамками локальной сети. Дополнительная лицензия позволяет работать одновременно с любым количеством поставок.

1.3 Выбор методологии проектирования информационной системы

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

Существует две основных методологии проектирования:

— методология структурного проектирования;

— методология объектно-ориентированного проектирования.

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

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

Наиболее распространенные модели структурного подхода:

SADT — Structured Analysis and Design Techniques — описывает модели и функциональные диаграммы;

DFD — Data Flow Diagrams — диаграммы потоков данных;

ERD — Entity Relationship Diagrams — диаграммы «сущность — связь».

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

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

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

Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:

— возможность повторного использования кода;

— повышение безопасности кода за счет инкапсуляции;

— гибкость при модификации и расширении системы;

— отсутствие необходимости разработки классов с нуля, за счет наследования;

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

1.4 Сбор требований

Основная цель рабочего процесса определения требований состоит в том, чтобы направить процесс разработки на получение правильной системы. А правильная система — это система, которая делает то, что необходимо и ничего более. Требование — это характеристика или условие, которому должна удовлетворять система.

Самое главное в любой рабочей деятельности — это cбор требований т.к. если разработчик будет знать то, что от него хотят чтобы он сделал, то и конечный результат будет удовлетворять обеих сторон. Максимально упрощенный и удобный процесс работы, сопровожденный минимизацией временных трудозатрат и наличие продуктивного результата, повысит работоспособность и результативность.

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

На этапе формирования и анализа требований в соответствии с технологией разработки программного обеспечения Microsoft Solution Framework (MSF):

— осуществляется сбор требований;

— составляются профили заинтересованных лиц;

— разрабатываются варианты использования.

Сбор требований осуществлялся на основе использовании метода интервьюирования.

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

— система должна охватывать основные бизнес-процессы предприятия;

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

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

— система должна иметь возможность наращивания в программной части;

— система должна позволять экспорт выходных документов

1.5 Спецификация требований

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

Спецификация требований — процесс документирования системы в структурированном, доступном всем и управляемом формате. Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту. SRS позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом, приемке проекта и связанных с проектом функциях [42, 9]. SRS имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний.

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

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

Разработанная спецификация для информационной системы представлена в приложении А.

1.6 Анализ и моделирование требований

Для того чтобы определить функциональные требования, предъявляемые к системе, необходимо, прежде всего, выявить лиц заинтересованных в этой системе, а затем определить тот функционал, который им требуется для осуществления своей профессиональной деятельности [2, 42].

Заинтересованные в системе пользователи, которые были выявлены в процессе исследования бизнес-процессов и предпроектного обследования предприятия, представлены на рисунке 1.10

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

Дадим краткую характеристику каждому классу пользователей системы.

Менеджер по работе с клиентами — сотрудник занимающийся приемом заказов и последующей работе с клиентами.

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

Сотрудник отдела по установке оборудования — занимается внештатными сотрудниками, также принимает участие в составление плана работ.

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

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

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

В процессе выполнения прецедента «Формирование заказа» пользователь выполняет поэтапное формирование заказа, последовательно вводя данные о клиенте.

В процессе выполнения прецедента «Утверждение заказа» в системе фиксируется состояние заказа, и дальнейшая его модификации.

В процессе выполнения прецедента «Передача заказа в отдел по установки оборудования» происходит передача заказа для дальнейшего его выполнения.

Рисунок 1.11- Варианты использования системы менеджером по работе с клиентами В процессе выполнения прецедента «Внесение изменений» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т. е. если не выполнялся прецедент «Утверждение заказа».

В процессе выполнения прецедента «Контроль по срокам гарантии» пользователь следит за сроками гарантии на оборудование.

В процессе выполнения прецедента «Расчет с клиентом» пользователь формирует счет.

На рисунке 1.12 представлены варианты использования системы начальником отдела по установки оборудования.

В процессе выполнения прецедента «Формирование заказа поставщикам» пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента «Утверждение заказа поставщикам» в системе фиксируется состояние заказа, и дальнейшая его модификации.

В процессе выполнения прецедента «Внесение изменений в заказ поставщикам» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т. е. если не выполнялся прецедент «Утверждение заказа поставщикам».

В процессе выполнения прецедента «Составление акта о выполненной работе» пользователь составляет акт о проделанной работе.

В процессе выполнения прецедента «Составление плана работ» пользователь составляет план работ в соответствии с принятым заказом.

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

Рисунок 1.12 — Варианты использования системы менеджером по персоналу На рисунке 1.13 представлены варианты использования системы сотрудником отдела по установки оборудования.

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

В процессе выполнения прецедента «Формирование заказа поставщикам» пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента «Внесение изменений в заказ поставщикам» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т. е. если не выполнялся прецедент «Утверждение заказа поставщикам».

В процессе выполнения прецедента «Составление плана для сотрудников» пользователь составляет план работ в соответствии с принятым заказом для каждого внештатного сотрудника в отдельности.

В процессе выполнения прецедента «Определение коэффициента участия сотрудников» пользователь определяет степень участия сотрудника.

В процессе выполнения прецедента «Формирование списка внештатных сотрудников» пользователь формирует список сотрудников для выполнения работ.

На рисунке 1.14 представлены варианты использования системы администратора автоматизированной системы.

В процессе выполнения прецедента «Регистрация пользователя» администратор регистрирует в системе новую учетную запись.

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

Рисунок 1.13- Варианты использования системы сотрудником отдела по установки оборудования Рисунок 1.14 — Варианты использования системы специалистом администратором В процессе выполнения прецедента «Удаление пользователя» администратор удаляет учетную запись пользователя и списка зарегистрированных в системе.

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

1.7 Аттестация требований

Аттестация требований — процесс проверки требований на достоверность, непротиворечивость, полноту и выполнимость.

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

— обзор требований — процесс просмотра системной спецификации на предмет неточных описаний и ошибок;

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

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

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

Выводы к разделу

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

В качестве методологии проектирования обосновано применение объектно-ориентированного подхода.

Проектирование информационной системы

1.8 Архитектурное проектирование

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

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

Архитектуры информационной системы требуется соблюдение следующих условий:

— соответствие с миссией организации;

— определенность в требованиях;

— направленность в разработке;

— возможность к адаптации;

— необходимость гибкости.

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

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

— файл-серверная;

— клиент-серверная;

— многоуровневая.

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел.

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

На рисунке 2.1 представлена схема клиент-серверной архитектуры.

Рисунок 2.1 — Клиент-серверная архитектура.

Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название — трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. Многоуровневая архитектура приложения (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компоненты которых выполняются на разных компьютерах. Частным случаем, Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:

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

— компонент, выполняющий обработку данных, выполняется на сервере приложений;

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

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

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

Диаграмма компонентов системы представлена на рисунке 2.2.

Рисунок 2.2 — Диаграмма компонентов информационной системы.

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

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

1.9 Проектирование пользовательского интерфейса

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

Пользовательский интерфейс клиентской части приложения выполнен в виде Windows-приложения.

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

Рисунок 2.3 — Прототип пользовательского интерфейса Пользовательская среда информационной системы предприятия состоит из следующих частей:

— главное меню приложения;

— основная часть.

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

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

Таблица 2.1. — Структура Главного меню

1.9 Проектирование базы данных

Основными целями проектирования базы данных являются:

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

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

— разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы.

В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации — концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к базе данных информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Данные, помещаемые в базу данных, также предоставляет конечный пользователь.

Реляционная модель данных в подавляющем большинстве случаев вполне достаточна для моделирования любых данных [17, 18, 26]. Однако проектирование базы данных в терминах схемы отношений на практике может вызвать большие затруднения, т.к. в этой модели изначально не предусмотрены механизмы описания семантики предметной области. С этим связано появление семантических моделей данных, которые позволяют описать конкретную предметную область гораздо ближе к интуитивному пониманию и, в то же время, достаточно формальным образом.

Концептуальное проектирование — сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

— обследование предметной области, изучение ее информационной структуры;

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

— моделирование и интеграция всех представлений;

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

Построение мощной и наглядной концептуальной схемы базы данных позволяет более полно оценить специфику моделируемой предметной области и избежать возможных ошибок на стадии проектирования схемы реляционной базы данных. На рисунке 2.4 пример концептуальной модели, на базе анализа сущностей Рисунок 2.4 — Концептуальная модель данных Спецификация таблиц базы данных представлена в приложении Б. На основе полученной концептуальной модели и данных приложения Б разработана логическая модель данных проектируемой подсистемы.

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

Рисунок 2.5 — Логическая модель данных На основе логической модели данных составляется физическая модель данных. Физический уровень модели данных, в отличие от логического уровня, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация о всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует, физический уровень модели зависит от конкретной реализации СУБД. Физический уровень модели данных изображен на рисунке 2.6.

Рисунок 2.6 — Физическая модель данных В процессе физического проектирования базы данных в среде MS SQL Server 2005 была создана база данных is_enterprises, состоящая из файлов данных is_enterprises.mdf и файлов журналов транзакций is_enterprises _log.ldf. Принцип отдельного хранения данных и журналов транзакций, а также разбиение этих двух групп информации на различные файлы в SQL Server 2005 необходим для повышения надежности системы.

Листинг SQL-скриптов, создающих информационные структуры сервера баз данных приведен в приложении В.

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

Одним из требований заказчика является реализация информационного обеспечения на основе Microsoft SQL Server 2005 Enterprise Edition. Построенные на сильных сторонах SQL Server 2000, SQL Server 2005 представляет собой интегрированное решение по управлению и анализу данных, которое поможет организациям различного масштаба:

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

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

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

SQL Server является всеобъемлющим, интегрированным сквозным решением, которое наделяет пользователей вашей организации безопасной, надежной, и продуктивной платформой для обработки промышленной информации и приложений, касающихся интеллектуальных ресурсов предприятия. SQL Server 2005 предоставляет мощные, знакомые инструменты для профессионалов информационных технологий так же, как и для работников информационной сферы, уменьшая сложность создания, развёртывания, управления и использования, данных предприятия и аналитических приложений на платформах от мобильных устройств до информационных систем предприятия. Благодаря исчерпывающему набору функций, взаимодействию с существующими системами и автоматизации типовых задач, SQL Server 2005 предоставляет полное решение в области хранения данных для предприятий всех масштабов.

Платформа данных SQL Server 2005 предоставляет организациям всех размеров следующие преимущества:

— использовать активы данных: в дополнение к поставке безопасной, надёжной базы данных для отраслей промышленности и аналитических приложений, SQL Server 2005 позволяет заказчикам получать больше выгоды от их данных включением встроенных функций, таких как отчётность, анализ и извлечение информации;

— увеличить продуктивность благодаря всеобъемлющим возможностям интеллектуальных ресурсов предприятия и интеграции со знакомыми инструментами, такими, как Microsoft Office System, SQL Server 2005 предоставляет работникам информационной сферы вашего предприятия важную, своевременную информацию, приспособленную для их конкретных нужд. Цель — сделать BI доступными для всех пользователей организации и, конечном счёте, позволить пользователям на всех уровнях организации принимать лучшие бизнес решения, основанные на одном из самых ценных активов — их данных;

— уменьшить сложность информационной технологии: SQL Server 2005 упрощает разработку, внедрение и управление отраслями промышленности и аналитическими приложениями, предоставляя программистам гибкую среду разработки и интегрированные, автоматизированные инструменты управления администраторам баз данных;

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

SQL Server 2005 состоит из ряда компонентов, таких, как Integration Services, Analysis Services, Reporting Services, Интеграция с Microsoft Office System.

Reporting Services расширяют платформу Microsoft BI для достижения информационного работника, оценивающего бизнес данные. Reporting Services являются серверной отчётной средой предприятия, управляемой при помощи Web служб. Отчёты могут доставляться во множестве форматов, с диапазоном интерактивных опций и опций печати. Сложный анализ может достичь широкой аудитории посредством распространения отчётов в качестве источника данных для потребителей нижнего уровня.

Построитель Отчётов, новый компонент Reporting Services SQL Server 2005, позволяет пользователям создавать свои собственные отчёты на основе дружественной модели данных. Построитель Отчётов использует платформу Reporting Services для создания специальных отчётов конечных пользователей. Пользователи создают и редактируют отчёты при помощи клиентского приложения Построителя Отчётов. Пользовательский интерфейс Построителя Отчётов создан на основе знакомых парадигм Microsoft Office, таких как Excel и PowerPoint.

Отчёты, которые обслуживаются Сервером Отчётов в Reporting Services, могут выполняться в контексте Microsoft SharePoint® Portal Server и приложений Microsoft Office System, таких как Microsoft Word и Microsoft Excel. Можно использовать функции SharePoint для подписки на отчёты, создания новых версий отчётов и распространения отчётов. Также можно открыть отчёты в Word или Excel для просмотра HTML версии.

Благодаря архитектуре уровня предприятия, глубокой интеграции с семейством BI инструментов SQL Server, богатому набору инструментов, интерфейсов прикладного программирования и алгоритмов, SQL Server позволяет создавать новый тип BI приложений, повышающих производительность и прибыли и снижающих издержки через создание специальных решений, работающих с данными, для широкого круга проблем бизнеса.