Реферат

Дипломный проект содержит 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 ФЗ «О ГАЗОСНАБЖЕНИИ В РОССИЙСКОЙ ФЕДЕРАЦИИ» [45].

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

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

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

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

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

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

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

Для того чтобы более четко разобраться с предметной областью [36] и понять, что требуется от проектируемой информационной системы далее приводится описание существующих бизнес-процессов [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 Выбор методологии проектирования информационной системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Архитектурное проектирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQL Server 2005 и Visual Studio 2005 вместе предоставляют более глубокие уровни интеграции между базой данных и средой разработки приложений, чем это было возможно ранее. Разработчики теперь могут создавать управляемые хранимые процедуры, функции, пользовательские типы и пользовательские агрегаты непосредственно из среды Visual Studio. Они также могут развёртывать эти новые объекты базы данных непосредственно из Visual Studio без переключения в другие инструменты. Visual Studio 2005 непосредственно поддерживает все новые типы данных SQL Server, такие как встроенный XML. Также существует возможность добавить все управляемые объекты базы данных в ту же систему контроля версий, которая используется для проектов Visual Studio, что позволяет ещё теснее интегрировать и сделать более безопасным процесс разработки [1].

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

В настоящее время обязательной возможностью считается визуальное проектирование, когда программист строит свои приложения, используя готовые модули. Примером могут служить все современные пакеты для разработчиков – Borland Delphi, ,Microsoft Visual Studio 2005 и т.д.

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

В .NET Framework поддерживается прямая и обратная совместимость. В контексте .NET Framework обратная совместимость означает, что любое приложение, созданное в .NET Framework более ранней версии, будет выполняться и в более поздней версии. Прямая совместимость означает возможность выполнения приложения, созданного в более поздней версии .NET Framework SDK v 2.0, в .NET Framework более ранней версии.

Классы ADO.NET были разработаны для поддержки возможностей новой модели программирования: интеграции с XML, единого представления данных с возможностью комбинирования данных из различных источников, а также средств оптимизации взаимодействия с базой данных, представленных в .NET Framework.

Структура ADO.NET создана для решения задач современной модели разработки приложений. В то же время модель программирования по возможности приближена к ADO, что упрощает переход разработчиков ADO к новой среде. ADO.NET является неотъемлемой частью .NET Framework, оставаясь понятной программистам ADO [34].

.NET представляет собой совершенно новый способ создания распределенных настольных и встроенных приложений. Для типов .NET не нужны ни фабрики классов, ни поддержка Unknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты – их просто больше нет.

Специально для новой платформы Microsoft разработала новый язык программирования – С#, который впитал в себя многое из того лучшего, что есть в самых разных языках программирования, и так же является составной частью Microsoft Visual Studio 2005.

Платформа .NET является полностью независимой от используемых языков программирования. Можно использовать несколько .NET-совместимых языков программирования даже в рамках одного проекта.

Основные возможности .NET следующие:

- полные возможности взаимодействия с существующим кодом;

- полное и абсолютное межъязыковое взаимодействие, межъязыковая обработка исключений и межъязыковая отладка;

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

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

- отсутствует сложность СОМ;

- действительное упрощение процесса развертывания приложения.

В .NET нет необходимости регистрировать двойные типы в системном реестре. .NET позволяет разным версиям одного и того же модуля DLL мирно сосуществовать на одном компьютере.

Microsoft Visual Studio 2005 продолжает поддерживать технологии Microsoft .NET Framework уже в версии Microsoft .NET Framework SDK v2.0, которые предоставляют общеязыковую среду выполнения и унифицированные классы программирования. Также в Visual Studio включена библиотека MSDN, содержащая документацию по данным инструментам разработки.

Платформа Microsoft.NET для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. предоставляет класс System.Windows.Forms.Form и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется составом элементов управления, входящих в коллекцию Controls для конкретной формы.

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

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

Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение сценарий транзакций использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader технологии ADO.NET, а так же используя bindingSource, TableAdapter, DataSet . Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все обязанности по реализации бизнес-логики возлагаются на методы сценария транзакций.

Для разрабатываемой информационной системы выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

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

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

На основании концептуальной модели данных для Microsoft SQL Server 2000 разработана физическая модель данных.

В качестве СУБД обосновано применение Microsoft SQL Server 2005 Enterprise Edition. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

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

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

При проектировании системы используется концепция слоев – одна из общеупотребительных моделей, применяемая разработчиками программного обеспечения для разделения сложных систем на более простые части [44].

В качестве базовой платформы для разработки приложения планируется использовать .Net Framework 2.0 [2, 24, 19].

.NET Framework — это управляемая среда для разработки и исполнения приложений, обеспечивающая контроль типов. Эта среда управляет выполнением программы: она выделяет память под данные и команды, назначает разрешения программе или отказывает в их предоставлении, начинает исполнение приложения и управляет его ходом, а также отвечает за освобождение и повторное использование памяти, занятой ресурсами, более ненужными программе. .NET Framework состоит из двух основных компонентов: общеязыковой исполняющей среды (CLR) и библиотеки классов .NET Framework.

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

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

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

Рисунок 3.1 – Пространство имен

Входящий в состав Microsoft .NET Framework SDK v2.0, в данном проекте использовалось следующее пространственное имя для подключения к базе данных (рисунок 3.2)

Рисунок 3.2 – Пространственное имя для подключения к базе данных

Разработка форм осуществляется с использованием специализированных мастеров Visual Studio .NET. Интегрированная среда разработки Visual Studio .NET позволяет создавать элементы в режиме визуальной разработки, где можно перетаскивать элементы прямо на форму.

В результате работы мастера проекта реализуется каркас формы являющийся экземпляром классов, унаследованного от System.Windows.Forms.Form. При отображении формы во время выполнения программы, этот класс будет использоваться как шаблон для отображения окна. Файлы С# имеют расширение «.cs». Код главной формы изображен на рисунке 3.3. Данная форма является диспетчерской, запускающей дочерние окна данного модуля.

Рисунок 3.3 – Инициализация компонентов формы «Start.cs»

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

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

Рисунок 3.4 – Пример обращения к базе данных

SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляют пользователю:

- организация данных;

- выборка данных;

- обработка данных;

- совместное использование данных;

- управление доступом;

- целостность данных.

Взаимодействие приложения с источником данных осуществляется при помощи запросов языка SQL. SQL является инструментом для выборки и обработки информации, содержащейся в базе данных. SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных [31]. Если пользователю необходимо получить информацию из базы данных, он запрашивает её у СУБД при помощи SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю [32]. Процесс запрашивания данных и получения результата называется запросом к базе данных.

На рисунке 3.5 представлен sql-запрос по составлению об установленном оборудовании.

Рисунок 3.5 -Пример sql-запрос

На рисунке 3.6 показан результат выполнения предыдущего sql-запроса.

Рисунок 3.6 – Результат sql-запрос

Также для взаимодействия с источником данных используются хранимые процедуры, написанные на Transact-SQL – это диалект языка SQL, разработанный компанией Microsoft для использования в СУБД Microsoft SQL Server.

Использование хранимых процедур дает несколько очевидных преимуществ:

- сценарии выполнения хранимых процедур кэшируются на сервере, что дает ощутимый прирост в скорости при повторном вызове процедур;

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

- часть бизнес-логики приложения выполняется на сервере;

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

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

Рисунок 3.7 – Код сценария создания хранимой процедуры
Report_order_client

Рисунок 3.8 – Внешний вид отчета Форма принятия заказа

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

На рисунке 3.9 представлен класс MsSQLDataAdapter.

Рисунок 3. 9 – Класс «MsSqlDataAdapter»

Функции CreateConnection() , OpenConnection(), CloseConnection() создают, открывают и закрывают соединение с сервером соответственно. Функции CreateCommand(), CreateParametrizedCommand() предназначены для создания параметризованных и обычных sql-команд. Для параметризованной команды необходимы параметры, которые создаются функциями CreateSqlParameter().

Рисунок 3 .10 – Класс «UserGateWay»

Класс UserGateWay содержит специализированные функции. Например, функция GetUser() определяет идентификатор пользователя по логину и паролю, используется для проверки данных о пользователе при попытке авторизации. Функция GetStatusModules() получает список модулей, к которым разрешен доступ для пользователя с определенным статусом. Функция GetUserName() возвращает данные пользователя по его идентификатору. Функция GetPasswordHash() возвращает хэшированную строку пароля.

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

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

Тестирование – это проверка работы программ с данными, подобным реальным, которые будут обрабатываться в процессе эксплуатации системы. Процесс тестирования программного обеспечения осуществляется на основе фактических или смоделированных входных данных (как стандартных, так и не стандартных) при определённых контролируемых условиях.

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

Процесс тестирования представляет собой эксплуатацию приложения в контролируемых условиях и изучение полученных результатов [39]. При этом проверяется работа приложения с нормальными и ошибочными данными и событиями. Следует изучить и реакцию на неожиданные ситуации.

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

Для тестирования разрабатываемого проекта была выбрана методика тестирования «черного ящика». Эта методика применяется в качестве средства тестирования функционала разрабатываемого программного обеспечения.

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

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

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

Таблица 3.1 наращиваемый подход к тестированию

Рисунок 3.11 – Ошибка приложения при составлении акта

Для наибольшего избегания ошибок в составлении запросов используются инструменты SQL Server. Первоначально запрос создается в SQL Server, там же тестируется (рисунок. 3.12).

Рисунок 3.12 Составление sql - запроса

Этот запрос показывает сроки гарантии установленного оборудования, в нем была пропущена связь между таблицами line_act и line_order_client.. После тестирования составленного запроса он помещается в код программы и тестируется уже сама программа так, как было рассказано выше. В конечном счете, тестирование проводится не только для поиска ошибок, но и для проверки качества продукта. А так как качество — это «соответствие потребностям пользователей в решении их бизнес-задач», процесс тестирования должен способствовать достижению этой цели с помощью проверки корректности работы программы.

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

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

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

Цели этапа развертывания:

- перенести решение в промышленную среду;

- признание заказчиком факта завершения проекта.

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

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

Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 3.2.

Таблица 3.2 – План развертывания приложения

Для создания установочного файла setup.exe была использована программа CreateInstall.

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

Рисунок 3.13 – Рабочее пространство программы

Для нормального функционирования АРМ требуется операционная система Microsoft Windows XP, а также система управления базами данных MS SQL Server 2005. Платформа .NET Framework должна быть установлена до установки приложения. Для развертывания приложения необходимо, чтобы на жестком диске объем свободного места был не менее 20 Мб. Для установки приложения был создан файл setup, автоматически сгенерировавший инсталляционный пакет проекта. Для установки системы достаточно запустить файл setup.exe, и далее следовать инструкциям мастера установки.

Рисунок 3.14 – Окно мастера установки

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

Рисунок 3.15 - Окно мастера установки, запрашивающее путь для установки

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

Рисунок 3.16 – Процесс установки

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

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

В третьем разделе дипломного проекта приведено описание разработки компонента и основных методов его тестирования и отладки.

В качестве базовой платформы для разработки приложения использована платформа .Net Framework 2.0, которая является управляемой средой для разработки и исполнения приложений.

Продемонстрирована реализация взаимодействия компонента с СУБД. Описана методика развертывания приложения средствами программы CreateInstall.

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

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

Жизненный цикл информационной системы — период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации [13].

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

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

V-образная модель была предложена именно для того, чтобы устранить недостатки каскадной модели. Область применения V-образной модели – когда информация о требованиях достаточно полная. Модифицированная V-образная модель включает в себя итерационные циклы внесения изменений в требования. V-образная модель дала возможность значительно повысить качество ПО за счет своей ориентации на тестирование, а также во многом разрешила проблему соответствия созданного продукта выдвигаемым требованиям благодаря процедурам верификации и аттестации на ранних стадиях разработки [15].

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

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

Период итерации, как правило, 60 дней. Обязательным является применение CASE-технологий.

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

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

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

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

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

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

Таблица 4.1 – Результаты выбора приемлемой модели жизненного цикла разработки программного обеспечения.

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

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

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

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

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

Задачи:

- выполнить сбор, спецификацию и аттестацию требований;

- выполнить проектирование информационного и программного обеспечения системы;

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

- провести тестирование программного продукта.

При определении области действия программного продукта эффективнее всего воспользоваться методикой «будет,/не будет». Ниже определены рамки проекта.

Относительно данного проекта можно сказать, что он будет:

- внутренним;

- применяться в операционных системах Windows;

- предназначен для автоматизации процессов предприятия.

Проект не будет:

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

- использоваться в системах отличных от Windows.

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

Для создания уникального продукта или услуги (результата проекта) нужно осуществить некоторую последовательность работ. Задача планирования проекта заключается в том, чтобы достаточно точно оценить сроки исполнения и стоимость этих работ [43].

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

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

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

- выполняется разработка программного обеспечения;

- происходит управление проектом;

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

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

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

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

Рисунок 4.1 - Структура пооперационного перечня работ

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

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

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

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

В качестве программы управления проектами была выбрана Microsoft Office Project 2007. В MS Project предусмотрен обширный набор возможностей по гибкому конфигурированию вида ленточных диаграмм.

В рамках программы MS Project задача – это одно из мероприятий, направленных на достижение цели проекта; основными параметрами задачи являются даты начала и завершения, длительность, трудоемкость, а также виды и количество ресурсов, необходимых для ее выполнения. Каждая задача в пределах проекта должна иметь уникальное имя.

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

Идентификации задач и действий структуры пооперационного перечня работ изображена на рисунке 4.2

Рисунок 4.2 - Идентификация задач и действий

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

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

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

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

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

Повторное использование может обеспечить прогресс на следующих направлениях:

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

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

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

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

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

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

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

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

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

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

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

Визуально диаграмма Ганта представляет собой последовательность действий, выполняемых в рамках данного проекта [5].

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

Диаграмма Ганта не единственный элемент управления проектом который формируется при создании проекта разрабатываемой системы, помимо диаграммы для формирования календарного графика используется структурное планирование. Основная цель структурного планирования заключается в описании состава и взаимосвязи технологических операций, которые требуется выполнить для реализации проекта. Результатом структурного планирования является сетевой график проекта. Сетевая диаграмма – графическое отображение работ проекта и зависимостей проекта между ними. Сетевые диаграммы отображают сетевую модель в графическом виде как множество вершин, соответствующих работам, связанных линиями, представляющими взаимосвязи между работами. Фрагмент сетевой диаграммы представлен на рисунке 4.3.

Рисунок 4.3 – Фрагмент сетевой диаграммы

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

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

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

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

Любой разрабатываемый проект состоит из задач, которые необходимо выполнить для достижения определенного (необходимого) результата. Для того чтобы стало возможным выполнение той или иной задачи необходимо что-либо сделать для этого, то есть затратить какие-либо ресурсы (трудовые, материальные, интеллектуальные) [16].

Одним из наиболее важных свойств любого ресурса является стоимость (Cost (Затраты)) его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 100 рублей в час или 1000 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном проекте использовалась повременная ставка (рисунок 4.4) Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 4.5.

Рисунок 4.4 – Сводная таблица загрузки ресурсов

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

Рисунок 4.5 – Общие затраты на использовании ресурсов проекта

Из этой диаграммы видно, что общие затраты равны фактическим, а следовательно остаток равен нулю, как и должно быть.

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

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

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

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

Распределение ресурсов проекта при создании информационной системы предприятия можно представить в виде перечня представленного на рисунке 4.6.

Рисунок 4.6 - Детальная таблица загрузки ресурсов

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

Рисунок 4.7 - График использования ресурсов руководителя проекта

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

Рисунок 4.8 - Статистика проекта

Общая стоимость работ составляет 68 000 рублей.

3.8 Оценка экономической эффективности проекта

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

Существует ряд методик оценки эффективности проектов, основанных на единой методологической базе и отличающихся условиями применимости и предметными областями. Эффективность проекта – это категория, отражающая соответствие проекта целям и интересам его участников [23]. Некоторые специалисты считают, что возможна только качественная оценка эффективности внедрения информационных системы, и невозможно оценить эффективность вложения средств в цифрах и существуют только косвенные показатели [35]. В результате внедрения информационной системы предприятия удастся достичь следующих результатов:

- повысить прозрачность процессов планирования;

- увеличить эффективность процесса взаимодействия с клиентами и поставщиками;

- упростить и ускорить процесс формирования заказов.

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

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

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

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

Формула расчета чистого приведенного дохода:

(4.1)

Формула для расчета величины денежного потока:

(4.2)

В таблице 4.2 представлены затраты на реализацию проекта.

Таблица 4.2 – Затраты на реализацию проекта

Ставка дисконтирования равна 11,5% /30/.

Денежный поток проекта – это зависимость от времени денежных поступлений и платежей при реализации проекта, определяемая для всего расчетного периода [23]. В таблице 4.3 представлен денежный поток за каждый месяц в отдельности.

Таблица 4.3 – Денежный поток по каждому месяцу

NPV=3474 рублей.

Поскольку величина чистой текущей стоимости 3474 рублей, то есть NPV > 0, то проект можно принять.

Коэффициент возврата инвестиций ROI позволяет оценить прибыльность инвестиций, вложенных в проект.

Формула для расчета коэффициента возврата инвестиций:

(4.3)

При ROI > 100% – инвестиции прибыльны, при ROI < 100% – инвестиции убыточны.

Поскольку ROI = 104%, то есть ROI > 100% - инвестиции прибыльны.

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

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

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

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

Заключение

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

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

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

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

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

В качестве среды разработки программного обеспечения была использована Microsoft Visual Studio 2005 и язык программирования C#.

В третьем разделе дипломного проекта рассмотрена реализация программного продукта. Рассмотрена и продемонстрирована методика взаимодействия приложения с СУБД MS SQL Server 2005. Извлечение необходимых пользователям, разработанной информационной системы, данных было осуществлено с помощью sql – запросов. Для тестирования разрабатываемого проекта была выбрана методика тестирования «черного ящика». Эта методика применяется в качестве средства тестирования функционала разрабатываемого программного обеспечения. Для развертывания разрабатываемой системы был составлен план действий. Результатами этапа развертывания системы являются системы сопровождения и поддержки, хранилище документов, где размещаются все версии документов и кода, разработанных в течение проекта.

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

В четвертом разделе дипломного проекта определялась цель и область действия программного продукта. Осуществлен выбор модели жизненного цикла процесса разработки по результатам, представленным в таблице 4.1. Выбор был сделан в пользу спиральной модели модели. Были определены цели и область действия программного проекта. Составлена структура пооперационного перечня работ. Создание структуры пооперационного перечня работ влечет за собой декомпозицию полномасштабного действия (всего проекта) на ряд последовательных и меньших действий. На её основе построена диаграмма Ганта, с использованием пакета управления проектами Microsoft Project 2007. Были определены необходимые ресурсы для разработки и внедрения информационной системы, также было сделано распределение данных ресурсов. Также был осуществлен расчет экономической эффективности данного проекта.

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

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

Список сокращений

CASE – Computer Added Software Engineering.

ERM – Entity Relationship Diagram.

MS – Microsoft.

SQL – Structured Query Language.

ИП – индивидуальный предприниматель.

ИС – информационная система.

ПК – персональный компьютер.

ПО – программное обеспечение.

ППП – пакет прикладных программ.

ПС – программное средство.

СУБД – система управления базой данных.

ЭВМ – электронная вычислительная машина.

с писок используемых источников

1. Microsoft SQL Server 2005. Обзор продукта. [Электронный документ] (http://www.citcite.ru/se/book/sql2005.htm).Проверено 14.03.2009.

2. Анализ требований и создание архитектуры решений на основе Microsoft .NET. Учебный курс MSCD/Пер. с англ. [текст] – М.: Издательско-торговый дом «Русская редакция», 2004. – 416 с.: ил.

3. Анализ требований к автоматизированным информационным системам. [Электронный документ]( http://www.INTUIT.ru). Проверено 14.03.2009.

4. Бизнес-правила в среде разработки и моделирования. [Электронный документ] (http://www.interface.ru/home.asp?artId=1752). Проверено 11.02.2009.

5. Богданов, В. Управление проектами в Microsoft Project 2002 / В. Богданов. − СПб.: Питер, 2003. – 604 с.

6. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++./ Г. Буч. – М.: «Бином», СПб: «Невский диалект», 2001. – 560с.

7. В продаже "Информационная система предприятия" – конфигурация для работы с корреспонденцией и документами. [Электронный документ] (http://www.cints.ru/news/244/). Проверено 15.02.2009.

8. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. / А.М. Вендров. – [Электронный документ] (http://www.infocity.kiev.ua). Проверено 05.02.2009.

9. Вигерс, К. Разработка требований к программному обеспечению. / К. Вигерс. – М.: Изд.-торг. Дом «Русская Редакция», 2004. – 576с.

10. Гамма, Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. - СПб: «Питер», 2001. – 368с.

11. Грехэм, И. Объектно-ориентированные методы. Принципы и практика / И. Грехэм - М.: «Вильямс», 2004. – 1024с.

12. Избачков, Ю.С. Информационные системы. Учебник для вузов / Ю.С. Избачков, В.Н. Петров. 2-е изд. – СПб.: Питер, 2005. – 739 с.

13. Коберн, А. Быстрая разработка программного обеспечения.: Пер. с англ. / А. Коберн. – М.: ЛОРИ, 2002. – 462с.

14. Коберн, А. Современные методы описания функциональных требований к системам.: Пер. с англ. / А. Коберн. – М.: ЛОРИ, 2002. – 364с.

15. Колдовский, В. Разработка ПО: модели жизненного цикла. [Электронный документ].(http://ko-online.com.ua/node/21072) Проверено 25.03.2009.

16. Колесников, С.Н. Инструментарий бизнеса: современные методологии управления предприятием. - М.: Издательско-консультационная компания «Статус-Кво 97», 2001. -336с.

17. Конноли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика./ Т. Конноли, К., Бегг, А. Страчан. – М.: «Вильямс», 2001. – 632с.

18. Концептуальное проектирование реляционный баз данных с использованием языка UML. [Электронный документ]. (http://www.interface.ru/home.asp?artId=4517). Проверено 05.02.2009.

19. Лабор, В. В. Си Шарп: Создание приложений для Windows. / В. В Лабор - Мн.: «Харвест», 2003 - 384 с.

20. Ларман, К. Применение UML и шаблонов проектирования. 2-е издание / К. Ларман - М.: «Вильямс»,- 2002. – 496с.

21. Лекция 10. Модель реализации. [Электронный документ]. (http://elearning.informika.ru/content/public/teh/tema10/tema10.htm). Проверено 25.03.2009.

22. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. / Д. Леффингуэлл, Д. Уидриг. - М.: «Вильямс», 2002. – 462с.

23. Мазур, И.И. Управление проектами / ИИ. Мазур, В.Д. Шапиро, Н.Г. Ольдерогге – М.: Омега-Л, 2006.- 664с.

24. Маклин , С. Microsoft .NET Remoting.: Пер. с англ. [текст] / С. Маклин, Дж. Нафтел, К. Ульямс. – М.: Издательско-торговый дом «Русская редакция», 2003. – 384 с.

25. Мацяшек, Л.А. Анализ требований к проектированию систем. Разработка информационных систем с использованием UML / Л.А. Мацяшек. М.: Изд. Дом «Вильямс», 2002. – 432с.

26. Мюллер, Р. Дж. Базы данных и UML / Р. Дж. Мюллер. М: «ЛОРИ», 2002. – 420с.

27. Нейбург, Э. Дж. Проектирование баз данных с помощью UML. / Э. Дж. Нейбург, Р.А. Максимчук. - М.: «Вильямс», 2002. – 420с.

28. Олифер, В.Г. Основы сетей передачи данных./ В.Г. Олифер, Н.А. Олифер. [Электронный документ] (http://www.intuit.ru). Проверено 19.03.2009.

29. Описание предметной области с использованием UML при разработке программных систем. [Электронный документ]. (http://www.interface.ru/home.asp?artId=3147). Проверено 16.01.2009.

30. Определение ставки дисконтирования. [Электронный документ]. (http://www.cfin.ru/management/practice/supremum2002/12.shtml)

31. Полякова, Л.Н. Основы SQL БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий. / Л.Н. Полякова. - ИНТУИТ.ру, - 2007. - 462с.

Проверено 21.05.2009.

32. Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD, MCSE, MCDBA/Пер. с англ. – 2-е изд., испр. [текст] – М.: Издательско-торговый дом «Русская редакция», 2003. – 512 стр.: ил.

33. Розенберг, Д. Применение объектного моделирования с использованием UML и анализ прецедентов. / Д. Розенберг, К. Скотт. - М.: «ДМК Пресс», 2002. – 436с.

34. Сеппа Д. Microsoft ADO.NET/Пер. с англ. — М.: Издательско-торговый дом Русская Редакция, 2003- — 640 стр.

35. Скрипкин, К.Г. Экономическая эффективность информационных систем. К.Г. Скрипкин.- М.: ДМК Пресс, 2002. – 420с.

36. Смирнова, Г. Н. Проектирование экономических информационных систем: Учебник Г.Н. Смирнова, А.А. Сорокин Под ред. Ю.Ф. Тельнова. − М.: Финансы и статистика, 2003. – 512с.

37. Структурный подход к проектированию ИС. [Электронный документ](http://www.lcard.ru/~nail/database/case/glava2_1.htm). Проверено 18.02.2009.

38. Сущность структурного подхода. [Электронный документ] (http://www.citcite.ru/se/book/spodhod.htm).Проверено 12.02.2009.

39. Тамре, Л. Введение в тестирование программного обеспечения : Пер. с англ. / Л. Тамре. – М.: Издательский дом «Вильямс», 2003. – 314с.

40. Трофимов, С. Определение требований к программному обеспечению. [Электронный документ] (http://www.caseclub.ru/articles/treb.html). Проверено 16.03.2009.

41. Уилсон, С. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD/Пер. с англ. – 2-е изд., испр. [текст]. С. Уилсон, Б. Мейплс, Т. Лэндгрейв. – М.: Издательско-торговый дом «Русская редакция», 2002. – 736 стр.: ил.

42. Уровни требований к программному обеспечению. [Электронный документ] (http://www.atis.ru/DocItem.aspx?groupId_10=8&itemId_10=15). Проверено 24.03.2009.

43. Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. – М.: Издательский дом "Вильямс", 2003.

44. Фаулер, М. Архитектура корпоративных программных решений.: Пер. с англ. [текст] / М.Фаулер. – М.: Издательский дом «Вильямс», 2006. – 544с.

45. Федеральный закон «О газоснабжении в Российской Федерации» - от 31 марта 1999 года, №69 // Консультант Плюс, Законодательство.

46. Якобсон, А. Унифицированный процесс разработки программного обеспечения. / А. Якобсон, Г. Буч, Дж. Рамбо. – СПб.: Питер, 2002.- 496с.

П риложения

Приложение 1 - Спецификация требований к программному обеспечению

Введение

Назначение

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

Общее описание

Описание продукта

Информационная система предприятия – это новая, которая система позволит сотрудникам:

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

- структурировать хранящиеся данные;

- уменьшить площадь хранимой информации за счет использования информационных технологий

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

Классы и характеристики пользователей

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

Таблица 1. - Основные категории пользователей

Общие ограничения

Операционная среда-1. Минимальные требования к операционной системе – Microsoft Windows XP Professional Edition SP2 с установленными компонентами .Net Framework 2.0.

Ограничения дизайна и реализации-1. Приложение должно быть написано на высокоуровневом языке C#.

Ограничения дизайна и реализации-2. Система должна использовать базу под управлением СУБД MS SQL Server 2005.

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

Документация для пользователей

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

Специфические требования

Таблица 1 - Функциональные требования

Требования к внешнему интерфейсу

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

- формы должны быть снабжены контекстной справкой для пользователей

Таблица 2. - Требования к системе

Основными системными требованиями для проектируемой ИС:

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

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

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

- система также должна позволять экспорт выходных документов в форматы Microsoft Word и Excel.

Требования к производительности

Отклик системы не должен превышать 10 секунд с момента передачи запроса.

Требования к охране труда

Требования к охране труда не определены.

Требования к безопасности

- функции системы становятся доступными пользователю только после его аутентификации в системе;

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

Атрибуты качества ПО

Доступность-1. Система должна быть доступна в рабочее время с 08.00 до 17.00 по местному времени.

Надежность-1. Система не должна нарушать целостность данных.

Приложение Б

Таблица - Атрибуты управляющих таблиц проектируемой исприложение

П риложение В

С крипт базы данных информационной системы

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [id_client] [int] NULL,

[date] [datetime] NULL,

[number] [nchar](10) COLLATE Cyrillic_General_CI_AS NULL,

[comment] [varchar](max) COLLATE Cyrillic_General_CI_AS NULL,

CONSTRAINT [PK_order_client] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[order_client] WITH CHECK ADD CONSTRAINT [FK_order_client_client] FOREIGN KEY([id_client])

REFERENCES [dbo].[client] ([id])

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[order_postavshik](

[id] [int] NOT NULL,

[number] [nchar](10) COLLATE Cyrillic_General_CI_AS NULL,

[date] [datetime] NULL,

[id_postavshik] [int] NOT NULL,

[comment] [varchar](max) COLLATE Cyrillic_General_CI_AS NULL,

CONSTRAINT [PK_order_postavshik] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[order_postavshik] WITH CHECK ADD CONSTRAINT [FK_order_postavshik_postavshik] FOREIGN KEY([id_postavshik])

REFERENCES [dbo].[postavshik] ([id])

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[postavshik](

[id] [int] NOT NULL,

[organization] [varchar](50) COLLATE Cyrillic_General_CI_AS NULL,

[FIO] [varchar](50) COLLATE Cyrillic_General_CI_AS NULL,

[post] [varchar](20) COLLATE Cyrillic_General_CI_AS NULL,

[rab_telephone] [varchar](15) COLLATE Cyrillic_General_CI_AS NULL,

[mobile] [varchar](11) COLLATE Cyrillic_General_CI_AS NULL,

[faks] [nchar](10) COLLATE Cyrillic_General_CI_AS NULL,

[street] [varchar](20) COLLATE Cyrillic_General_CI_AS NULL,

[town] [varchar](15) COLLATE Cyrillic_General_CI_AS NULL,

[region] [varchar](20) COLLATE Cyrillic_General_CI_AS NULL,

[indeks] [nchar](10) COLLATE Cyrillic_General_CI_AS NULL,

[e_mail] [varchar](20) COLLATE Cyrillic_General_CI_AS NULL,

[comment] [varchar](max) COLLATE Cyrillic_General_CI_AS NULL,

CONSTRAINT [PK_postavshik] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[price](

[id] [int] NOT NULL,

[id_postavshik] [int] NOT NULL,

[id_equipment] [int] NOT NULL,

[price] [money] NULL,

[date_price] [datetime] NULL,

CONSTRAINT [PK_price] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[price] WITH CHECK ADD CONSTRAINT [FK_price_equipment] FOREIGN KEY([id_equipment])

REFERENCES [dbo].[equipment] ([id])

GO

ALTER TABLE [dbo].[price] WITH CHECK ADD CONSTRAINT [FK_price_postavshik] FOREIGN KEY([id_postavshik])

REFERENCES [dbo].[postavshik] ([id])

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[uchastnik_act](

[id] [int] NOT NULL,

[id_act] [int] NOT NULL,

[id_employee] [int] NOT NULL,

[factor_uchastia] [float] NULL,

CONSTRAINT [PK_uchastnik_act] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[uchastnik_act] WITH CHECK ADD CONSTRAINT [FK_uchastnik_act_act] FOREIGN KEY([id_act])

REFERENCES [dbo].[act] ([id])

GO

ALTER TABLE [dbo].[uchastnik_act] WITH CHECK ADD CONSTRAINT [FK_uchastnik_act_employee] FOREIGN KEY([id_employee])

REFERENCES [dbo].[employee] ([id])

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[line_act](

[id] [int] NOT NULL,

[id_act] [int] NOT NULL,

[id_line_order_client] [int] NOT NULL,

[date_guarantee] [datetime] NULL,

CONSTRAINT [PK_line_act] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[line_act] WITH CHECK ADD CONSTRAINT [FK_line_act_act] FOREIGN KEY([id_act])

REFERENCES [dbo].[act] ([id])

GO

ALTER TABLE [dbo].[line_act] WITH CHECK ADD CONSTRAINT [FK_line_act_line_order_client] FOREIGN KEY([id_line_order_client])

REFERENCES [dbo].[line_order_client] ([id])

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[plan_work](

[id] [int] NOT NULL,

[number] [nchar](10) COLLATE Cyrillic_General_CI_AS NULL,

[date] [datetime] NULL,

[brigad] [nchar](10) COLLATE Cyrillic_General_CI_AS NULL,

[comment] [varchar](max) COLLATE Cyrillic_General_CI_AS NULL,

CONSTRAINT [PK_plan_work] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[line_plan_work](

[id] [int] NOT NULL,

[id_plan_work] [int] NOT NULL,

[id_line_order_client] [int] NOT NULL,

[date_instal] [datetime] NULL,

CONSTRAINT [PK_line_plan_work] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[line_plan_work] WITH CHECK ADD CONSTRAINT [FK_line_plan_work_line_order_client] FOREIGN KEY([id_line_order_client])

REFERENCES [dbo].[line_order_client] ([id])

GO

ALTER TABLE [dbo].[line_plan_work] WITH CHECK ADD CONSTRAINT [FK_line_plan_work_plan_work] FOREIGN KEY([id_plan_work])

REFERENCES [dbo].[plan_work] ([id])

USE [is_enterprises]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[plan_employee](

[id] [int] NOT NULL,

[id_line_plan_work] [int] NOT NULL,

[id_employee] [int] NOT NULL,

CONSTRAINT [PK_plan_employee] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

USE [is_enterprises]

GO

ALTER TABLE [dbo].[plan_employee] WITH CHECK ADD CONSTRAINT [FK_plan_employee_employee] FOREIGN KEY([id_employee])

REFERENCES [dbo].[employee] ([id])

GO

ALTER TABLE [dbo].[plan_employee] WITH CHECK ADD CONSTRAINT [FK_plan_employee_line_plan_work] FOREIGN KEY([id_line_plan_work])

REFERENCES [dbo].[line_plan_work] ([id])

USE [is_enterprises]

GO

/****** Object: Table [dbo].[employee] Script Date: 05/27/2009 16:33:32 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[employee](

[id] [int] NOT NULL,

[FIO] [varchar](30) COLLATE Cyrillic_General_CI_AS NULL,

[address] [varchar](30) COLLATE Cyrillic_General_CI_AS NULL,

[telephone] [varchar](11) COLLATE Cyrillic_General_CI_AS NULL,

CONSTRAINT [PK_employee] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

П риложение Г

Ф рагмент исходного кода программы

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Text;

using System.Windows.Forms;

namespace is_enterprises

{

partial class FormInstal

{

private void Undo()

{

DataSetis_interprises.EndCurrentEdit();

DataSetis_interprises.postavshik.RejectChanges();

}

private void Create()

{

DataRow row = this.DataSetis_interprises.postavshik.NewpostavshikRow();

rowpostavshik["orzanization"] = "";

rowpostavshik["FIO"] = "";

rowpostavshik["post"] = "";

rowpostavshik["rab_telephone "] = "";

rowpostavshik[" mobile "] = "";

rowpostavshik["faks "] = "";

rowpostavshik["street "] = "";

rowpostavshik["town "] = "";

rowpostavshik["region "] = "";

rowpostavshik["indeks "] = "";

rowpostavshik["e-mail "] = "";

owpostavshik["comment "] = "";

this.DataSetis_interprises.postavshik.Rows.Add(rowpostavshik);

int pos = this. DataSetis_interprises.postavshik.Rows.Count - 1;

this.BindingContext[DataSetis_interprises.postavshik, "postavshik "].Position = pos;

}

private void Save()

{

DisplayReadOnly(true);

string mes = "";

DataSetis_interprises.EndCurrentEdit();

DataSetis_interprises.postavshikDataTable ds1 = (DataSetis_interprises.postavshikDataTable) DataSetis_interprises.postavshik.GetChanges(DataRowState.Modified);

if (ds1 != null)

try

{

this. DataSetis_interprises.Update(ds1);

ds1.Dispose();

DataSetis_interprises.postavshik.AcceptChanges();

}

catch (Exception x)

{

mes = x.Message;

MessageBox.Show("Ошибка обновления базы данных postavshik " + mes, "Предупреждение");

his.DataSetis_interprises.postavshik.RejectChanges();

}

DataSetis_interprises.postavshikDataTable ds2 = (DataSetis_interprises.postavshikDataTable) this.DataSetis_interprises.postavshik.GetChanges(DataRowState.Added);

if (ds2 != null)

try

{

DataSetis_interprises.Update(ds2);

ds2.Dispose();

DataSetis_interprises.postavshik.AcceptChanges();

}

catch (Exception x)

{

mes = x.Message;

MessageBox.Show("Ошибка вставки записи в базу данных postavshik " + mes, "Предупреждение");

DataSetis_interprises.postavshik.RejectChanges();

}

}

private System.ComponentModel.IContainer components = null;

protected override void Dispose(bool disposing)

{

if (disposing && (components != null))

{

components.Dispose();

}

base.Dispose(disposing);

}

public FormInstal()

{

this.menuStrip1 = new System.Windows.Forms.MenuStrip();

this.файлToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

this.войтиВСистемуToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

this.выйтиToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

this.справкаToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

this.руководствоToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

this.оПрограммеToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

this.statusStrip1 = new System.Windows.Forms.StatusStrip();

this.toolStripProgressBar1 = new System.Windows.Forms.ToolStripProgressBar();

this.toolStripStatusLabel1 = new System.Windows.Forms.ToolStripStatusLabel();

this.menuStrip1.SuspendLayout();

this.statusStrip1.SuspendLayout();

this.SuspendLayout();

}

private void ButtonUndo_Click(object sender, EventArgs e)

{

Undo();

}

private void ButtonCreate_Click(object sender, EventArgs e)

{

Create();

}

П риложение Д − Обоснование выбора модели жизненного цикла

Таблица Д. 1 - Выбор модели ЖЦ на основе характеристик требований

Таблица Д.2 - Выбор модели ЖЦ на основе характеристик участников команды разработчиков

Таблица Д.З - Выбор модели ЖЦ на основе характеристик типа проектов и рисков

Таблица Д.4 - Выбор модели ЖЦ на основе характеристик пользователей

П риложение Е

ДИАГРАММА ГАНТА