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

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

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

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 представлены варианты использования системы сотрудником отдела по установки оборудования.

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