Размещено на http://www.allbest.ru/

Московский Государственный Университет Путей Сообщения

(МИИТ)

Курсовая работа

по дисциплине «Управление жизненным циклом»

«Разработка информационной системы по автоматизации системы учета прибыли и ее распределения CASE-средствами BPwin, ERwin, RationalRose»

Группа ЭБИ-212

Автор: Щепилов Д.А.

Проверила: Морозова В. И.

Москва 2014 год



ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ СИСТЕМЫ

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

Постановка задачи

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

При разработке использовать следующие IDEF-модели:

· IDEF0- функциональное моделирование (Function Modeling Method)

· DFD- диаграммы потоков данных (Data flow diagramming)

· IDEF3- моделирование деятельности (Process Flow and Object Stale Description Capture Method)

Разработать техническое задание, которое включает следующие пункты:

· общие сведения;

· назначение и цели создания (развития) системы;

· характеристика объектов автоматизации;

· требования к системе;

· состав и содержание работ по созданию системы;

· порядок контроля и приемки системы;

· требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

· требования к документированию;

· источники разработки.

Требования к построению модели.

BPwin:

в контекстной диаграмме входных (и выходных) документов должно быть не менее четырех;

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

каждая диаграмма декомпозиции должна состоять не менее чем из трех элементов «работа»;

диаграмм потоков данных должно быть не менее двух;

каждая диаграмма потоков данных должна состоять не менее чем из трех элементов «работа».

ERwin:

полей в таблицах должно быть не менее семи;

таблицы должны включать первичные ключи (связанные - еще и внешние ключи);

связи таблиц должны быть как идентифицирующие так и не идентифицирующие;

Структура отчета следующая:

титульный лист (тема:«Разработка информационной системы по … CASE-средствамиBPwin, ERwin, Rational Rose»),

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

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

исходные и выходные данные (формы документов),

описание методологии функциональной модели IDEF0, IDEF3, DFD (BPwin), модели данных (ERwin), визуального моделирования (RationalRose),

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

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

заключение (что было выполнено, какими средствами, что было создано в работе в системах BPwin, ERwin, RationalRose, преимущества моделирования ИС).



ВВЕДЕНИЕ

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

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

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

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

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

Современные CASE-системы охватывают обширную область поддержки различных технологий проектирования и программирования. Большинство CASE-систем при проектировании используют спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, и т.д. Помимо разработки, CASE-средства ориентированы на проектирование и на генерацию баз данных и пользовательских интерфейсов. Генерация интерфейса прикладной системы с базой данных, не только позволяет сократить время разработки, но и даёт возможность определить разработку приложений от ведения архива проектной документации.

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

Описание предметной области «Учет и использование прибыли АО»

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

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

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

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

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



1. ПОСТРОЕНИЕ МОДЕЛИ (IDEF0)

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

Модель может содержать четыре типа диаграмм:

· контекстную;

· декомпозиции;

· дерева узлов;

· только для экспозиции (FEO).

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



Рис.1 Диаграмма учета прибыли и ее распределения

Контекстная диаграмма для задачи «Система учета прибыли и ее распределения» показана на рис.1.

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

Рис. 2. Декомпозиция контекстной диаграммы

На Рис. 2 представлена декомпозиция контекстной диаграммы, которая более детально показывает разрабатываемый процесс.



Рис. 3 представлена декомпозиция первого блока.

Функциональный блок «Автоматизация учета прибыли и ее использования» разбивается на 4 составляющие - блоки.

Выплата дивидендов

2. ПОСТРОЕНИЕ ДИАГРАММЫ ПОТОКОВ ДАННЫХ (DFD)

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как взаимосвязанный набор действий, которые обрабатывают данные в «хранилища данных» как внутри, так и вне границ моделируемой системы. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

· функции обработки информации (работы);

· документы (стрелки), объекты, сотрудников или отделы, которые участвуют в обработке информации;

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

· таблицы для хранения документов (хранилище данных).

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

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

Рис. 4. Процесс описания «Пополнения резервного фонда»



Рис. 5. Процесс описания «Создания резервного фонда»

3. ПОСТРОЕНИЕ МОДЕЛИ ОПИСАНИЯ ПРОЦЕССОВ (IDEF3)

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

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

· Диаграмм потоков данных для бизнес-процессов;

· Диаграмм изменения состояния объекта.

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

IDEF3 - это метод, предоставляющий аналитикам средство для описания ситуации, в которой процессы выполняются как в определенной последовательности, так и описать объекты, участвующие совместно в одном процессе.

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

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

При помощи этого метода были описаны следующие процессы:



Рис. 6. Процесс «Определение размеров дивидендов»



Рис. 7. «Альтернативные пути использования прибыли»

4. СОЗДАНИЕ ОТЧЕТОВ

Существует три способа создания отчетов в BPwin 7.0:

с помощью встроенных шаблонов;

спомощью Report Template Builder;

с помощью RPTwin.

Отчеты на основе встроенных шаблонов можно создать, выбрав в меню Tools в режиме Reports режим с необходимым типом шаблона. Всего имеется семь типов шаблонов отчетов:

1) ModelReport. Отчет включает информацию о контексте модели - имя модели, точку зрения, область, цель, имя автора, дату создания и др.

2) DiagramReport. Отчет по контекстной диаграмме, включает список объектов: работ, стрелок, хранилищ данных, внешних ссылок и др.

3)DiagramObjectReport. Наиболее полный отчет по модели, включает полный список объектов модели: работ, стрелок с указанием их типа и др. - и свойства, определяемые пользователем.



ModelReport

Листинг отчета

ModelName: Автоматизация системы учета прибыли и ее использовния

Author Name: Shchepilov Denis

Creation Date: 12.04.2014

SystemLastRevisionDate: 04.06.2014

UserLastRevisionDate: 04.06.2014

Diagram Report



ReportforDiagram: A0, Система учета прибыли и ее использования АО

Activity Name: Выплатадивидендов

Activity Author: Shchepilov Denis

Object Type: Activity

Activity Name: Созданиерезервногофонда

Activity Author: Shchepilov Denis

Object Type: Activity

Activity Name: Пополнениеуставногофонда

Activity Author: Shchepilov Denis

ObjectType: Activity

ActivityName: Альтернативные направления использования

Activity Author: Shchepilov Denis

Object Type: Activity

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

LinkStatus: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

Link Status: WORKING

LinkStatus: WORKING

LinkStatus: WORKINGЛистинг отчета



DiagramObjectReport

Листинг отчета

Name: Система учета прибыли и ее использования АО

Object Type: Activity

Output Name: Сч.80 Уставной капиал

ControlName: Налоговый кодекс

InputName: Сч.84 Нераспределенная прибыль

InputName: Сч.47 Реализация основных средств

InputName: Сч.48 Реализация

InputName: Сч. 43 Готовая продукция

Name: Выплата дивидендов

Object Type: Activity

OutputName: Сч.84 Нераспределенная прибыль

ControlName: НДФЛ

InputName: Сч.84 Нераспределенная прибыль

ControlName: Устав

InputName: Сч.75 Расчеты с учредителями

Name: Определение размеров дивидендов

ObjectType: Activity

OutputName: Сч.75 Расчет с акционерами и учредителями

ControlName: НК РФ

InputName: Сч.84 Нераспределенная прибыль

ControlName: Устав

InputName: Протокол решения собрания акционеров

Name: Выплатадивидендаакционеру

Object Type: Activity

Output Name: Untitled Output 4

Input Name: Доступнаясуммаденег

Name: Определение категории акций

ObjectType: Activity

Output Name: Untitled Output 1

Input Name: Untitled Input 4

Name: Определение способ выплат

ObjectType: Activity

Output Name: Untitled Output 7

Input Name: Untitled Input 12

Name: Выплата по обыкновенным акциям

ObjectType: Activity

Output Name: Untitled Output 10

Input Name: Untitled Input 2

Name: Выплата по привелигированным акциям

ObjectType: Activity

Output Name: Untitled Output 11

Input Name: Untitled Input 3

Name: Определениесрокавыплаты

Object Type: Activity

Output Name: Датавреестре

Control Name: НКРФ

Input Name: Реестрвыплат

Control Name: Устав

Control Name: Статья 395 ГК

Name: Созданиерезервногофонда

Object Type: Activity

Output Name: Резервныйфонд

ControlName: Устав ликвидационной стоимости

InputName: Сч.84 Нераспределенная прибыль

ControlName: ФЗ №208-Ф3

InputName: Чистые активы предприятия

Name: Формирование основы для создания резервного фонда

Object Type: Activity

Output Name: Untitled Output 2

InputName: Сч.84 Нераспределенная прибыль

OutputName: Дебет 84 Кредит 82 Счет на сумму совершаемых отчислений

Input Name: Чистыеактивыпредприятия

Input Name: Untitled Input 1

InputName: UntitledInput 8

Name: Регстрация изменеий отчислений в резервый фонд

Object Type: Activity

Output Name: Untitled Output 7

Input Name: Untitled Input 3

Input Name: Untitled Input 6

Input Name: Untitled Input 9

Name: Пополнениеуставногофонда

Object Type: Activity

OutputName: Уставной фонд

ControlName: Устав предприятия

InputName: Уставной фонд

OutputName: Собственные средства

InputName: Сч.84 Нераспределенная прибыль

Name: Решение об увеличении уставного капитала

Object Type: Activity

Output Name: Протоколрешениясобрания

Input Name: Сч.84 Нераспределеннаяприбыль

Output Name: Untitled Output 8

InputName: Собрание акционеров

InputName: ГК РФ

Name: Внесение денежных средств на счет

Object Type: Activity

Output Name: Untitled Output 9

InputName: Протокол решения собрания

OutputName: Новая редакция учредительных документов

Input Name: АРМБух.

Input Name: ГКРФ

Name: Регистрация изменений

ObjectType: Activity

OutputName: Пополненный уставной капитал

InputName: Новая редакция учредительных документов

Input Name: АРМБух.

Input Name: ИФНС

Name: Альтернативные направления использования

ObjectType: Activity

OutputName: Сч.99 Прибыли и убытки

InputName: Сч.84 Нераспределенная прибыль

Name: Усовершенствование или замена оборудывания

Object Type: Activity

Output Name: Untitled Output 0

Name: Анализ состояния обородувания

ObjectType: Activity

Output Name: Untitled Output 3

Input Name: Untitled Input 2

Name: Запрос информации о сроке использования оборудывания

Object Type: Activity

Output Name: Untitled Output 4

InputName: UntitledInput 1

Name: Подготовка документов для модернизации оборудывания

Object Type: Activity

Input Name: Untitled Input 4

InputName: UntitledInput 3

5. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

автоматизированный информационный учет прибыль

Техническое задание

1.Общие сведения

1.1. Полное наименование системы и ее условное обозначение

Настоящее Техническое задание описывает задачу построения экономической информационной системы (ЭИС) «Система автоматизированного учета прибыли и ее распределения » на предприятии.

1.2. Шифр темы

Шифр темы: Не предусмотрен

1.3. Наименование разработчика и заказчика системы и их реквизиты

Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы:

Разработчик проекта: АО«Profit», г.Москва, ул.Образцова д. 7;

Генеральный директор: Морозова В.И.

Заказчик проекта: ОАО «Дружба», г. Москва, Богратионовская д. 17

1.4. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы

Перечень документов, на основании которых создается система:

Основанием для выполнения работ по теме является договор на создание ЭИС 14-2-12.

1.5. Плановые сроки начала и окончания работы по созданию системы

Сроки начала и окончания разработки ЭИС: январь 2014 - декабрь2014 года.

1.6. Сведения об источниках и порядке финансирования работ

Работа выполняется в рамках курсовой работы высшего учебного заведения кафедры “Экономическая информатика” Московского Государственного Университета Путей Сообщения. Порядок финансирование не предусмотрен.

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

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

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

- расчетно-пояснительная записка.

2. Назначения и цели создания информационной системы

2.1.Назначение системы

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

2)Целями создания системы являются:

- снижение временных и трудовых затрат на обработку информации

-минимизация затрат;

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

-повышение качества получаемой информации.

3. Характеристика объекта автоматизации

1)Краткие сведения об объекте автоматизации или ссылка на документы, содержащие такую информацию

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

4. Требования к системе

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

4.1.1 Требования к структуре и функционированию системы

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

В состав информационной системы учёт прибыли и ее распределения - должны входить следующие подсистемы:

Ш Выплата дивидендов;

Ш Создание резервного фонда;

Ш Пополнение уставного фонда;

Ш Альтернативные пути использования;

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

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

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

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

4.1.1.4 Требования к режимам ожидания функционирование системы

Для информационной системы определены следующие режимы функционирования:

- активный режим работы;

- режим ожидания;

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

4.1.1.5 Требования по диагностированию системы

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

4.1.1.6 Перспективы развития, модернизации системы

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

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

4.1.2 Требования к численности и квалификации персонала системы

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

4.1.3 Требуемый режим работы персонала

Требуемый режим работы - полный рабочий день с 9:00 до 19:00

Основной перерыв должен составлять 1 час - с 13:00 до 14:00

4.1.4 Требования к надежности

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

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

- при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функция системы возлагается на ОС;

- при ошибках, связанных с программным обеспечением (ОС, сервер базы данных, Интернет-сервер), восстановление работоспособности возлагается на ОС.

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

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

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

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

4.1.6 Требования по эргономике и технической эстетике

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

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

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

4.1.7 Требования к транспортабельности для подвижных ИС

Требования не предъявляются.

4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранение компонентов системы

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

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

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

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

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

Не предусмотрены.

4.1.8.3 Требования по количеству, квалификации обслуживающего персонала и режимам его работы

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

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

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

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

4.1.8.4 Требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов

Не предусмотрены.

4.1.8.5 Требования к регламенту обслуживания

Не предусмотрены.

4.1.9 Требования к защите внутренней информацией от несанкционированного доступа

ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем» 1992 г.

Компоненты подсистемы защиты от НСД должны обеспечивать:

- индексацию пользователей;

- проверку полномочий пользователя при работе с системой;

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

Конфиденциальность информации при сетевом и прямом доступе к файлам на сервере должна обеспечиваться средствами ОС, брандмаузера и антивируса; непосредственный доступ к самому серверу возможен только уполномоченными в ВУЗе лицами.

4.1.10 Требования по сохранности информации при авариях

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

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

- при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;

- при ошибках связанных с программным обеспечением ОС.

4.1.11 Требования к защите от влияния внешних воздействий

4.1.11.1 Требование к радиоэлектронной защите средств ИС

Не предусмотрены.

4.1.11.2 Требования по стойкости, устойчивости и прочности к внешним воздействиям

Не предусмотрены.

4.1.12 Требование к патентной чистоте

Не предусмотрены.

4.1.13 Дополнительные требования

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

Не предусмотрены.

4.1.13.2 Требования к сервисной аппаратуре, стендам для проверки элементов системы

Не предусмотрены.

4.1.13.3 Требования к системе, связанные с особыми условиями эксплуатации

Не предусмотрены.

4.1.13.4 специальные требования по усмотрению разработчика или заказчика системы

Не предусмотрены.

4.2. Требования к функциям, выполняемым системой

4.2.1 По каждой подсистеме перечень функций, задач или их комплексов, подлежащих автоматизации

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

4.2.2 Временный регламент реализации каждой функции

Будет определен на стадии анализа.

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

Будет представлен на стадии анализа и проектирования.

4.2.4 Перечень и критерии отказов для каждой функции, по которой задаются требования по надежности

Будет представлен на стадии проектирования.

4.3 Требования к видам обеспечения

4.3.1 Требования к математическому обеспечению

Не предусмотрены.

4.3.2 Требования к информационному обеспечению

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

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

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

4.3.3 Требования к программному обеспечению

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

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

4.3.4 Требования к лингвистическому обеспечению системы

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

5. Характеристика объектов автоматизации

5.1 Краткие сведения об объекте

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

6. Требования к системе

6.1 Виды, состав, объем и методы испытаний системы и ее составных частей

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

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

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

6.2. Общие требования к приемке работ, порядок согласования и утверждения приемочной документации

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

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

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

Сдача-приёмка работ производится поэтапно, в соответствии с рабочей программой и календарным планом, являющимися приложениями к Госконтракту №... от... года.

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

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

6.3. Статус приемочной комиссии

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

7.1 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ

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

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

7.2 Изменения, которые необходимо осуществить в объекте автоматически

Не предусмотрены.

7.3 Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ

Необходимым условием функционирования клиентской части системы является наличие операционной системы MicrosoftWindowsXP/2000 с установленной СУБД и программным интерфейсом.

7.4 Создание необходимых для функционирования системы подразделений и служб

Не предусмотрены.

7.5 сроки и порядок комплектования штатов и обучение персонала

Не предусмотрены.



СПИСОК ЛИТЕРАТУРЫ

1. В.И. Морозова, К.Э. Врублевский «Методические указания к выполнению лабораторных работ по разработке информационных систем с использованием CASE-средств BPwin и ERwin».

Размещено на Allbest.ru