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

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

Введение

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

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

Целью разработки информационной системы «Учет работ по ремонту и обслуживанию компьютерной техники в сервисном центре» является автоматизация учета ремонтных работ и обслуживания компьютерной техники в сервисном центре.

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



1. Разработка и анализ технического задания

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

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

Прием оборудования в ремонт осуществляет приемщик - сотрудник СЦ. Он регистрирует новые заказы.

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

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

- проводится диагностика;

- диагностика проведена, ремонт невозможен;

- диагностика проведена, ремонт возможен;

- ремонт проведен успешно.

При успешном завершении ремонта заказчик ставится в известность об окончании ремонта. После оплаты заказчику возвращается изделие, и в заказе фиксируется дата выдачи. Заказу присваивается статус «изделие выдано заказчику».

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

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

1.2 Разработка технического задания

1.2.1 Цель и назначение разработки

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

1.2.2 Функциональные требования к системе

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

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

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

- добавление и корректировка данных о клиентах и сотрудниках сервисной организации;

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

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

Основные функции информационной системы:

1) Формирование справочников.

2) Создание учетных записей пользователей.

3) Формирование заказов.

4) Корректировка заказа.

5) Формирование сведений о ремонте.

6) Формирование отчетов.

1.2.3 Требования по безопасности и целостности информации

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

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

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

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

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

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

- журналирование;

1.2.4 Количественные требования к системе

- количество приемщиков, одновременно работающих в системе, - не более 15;

- количество мастеров, одновременно работающих в системе - не более 20;

- количество записей о заказах - не более 15 000;

- срок хранения записей о клиентах - пол года;

- время выполнения основных запросов - не более 5 сек;

- критерии поиска - не менее 3;

1.2.5 Аппаратно-технические требования

Аппаратно-техническая часть системы представлена следующими устройствами:

- Сервер системы: специализированный компьютер c высокой производительностью и техническими характеристиками. Выполняет функции хранилища всей оперативной и статистической информации. На нем размещается ядро системы - база данных и хранимые процедуры SQL Server. Сервер находится в офисе. Минимальные характеристики: ПК с процессором Celeron 2,0 ГГц, RAM 768MB, жесткий диск от 160 ГБ (2 шт.); ИБП 1000ВА (с режимом выключения сервера); операционная система Microsoft Windows Server 2008; платформа Microsoft .NET Framework 3.0; MS Access 2007.

- Автоматизированное рабочее место (АРМ) сотрудников СЦ: ПК с процессором Celeron 2,0 ГГц, RAM 1024MB; от 15 ГБ свободного пространства на жестком диске; видео адаптер VGA с разрешением экрана минимум 800x600 точек, рекомендовано 1280*1024 - крупный шрифт; операционная система Microsoft Windows XP с пакетом обновления 2 (SP2) или более поздняя версия; платформа Microsoft .NET Framework 3.0 или более поздняя версия)

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

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

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

- форму для ввода данных;

- форму для ввода запроса и параметров на формирование отчетов и их печати;

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

- форму для редактирования справочников.

1.3 Анализ технического задания

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

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

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

1.4.1 Выбор системы управления базами данных

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

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

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

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

1.4.2 Выбор языка программирования

Для реализации функции программы было выбрано бесплатное обеспечение Microsoft Visual Studio Express Edition 2008, язык программирования C#.

Для создания ИС было выбрано бесплатное обеспечение Microsoft Visual Studio Express Edition 2008, язык программирования C#, так как:

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

- Продукты, выполненные в С#, внешне выглядят как стандартные Windows приложения, то есть просты в пользование и понятны любому пользователю. Название объектов (Таких как Button) указывают на действие, которое выполняет этот объект, а возможность создания меню и справки на русском языке, помогает пользователю быстрее освоить продукт.

- Выбор компонентов С# можно расширять, а также самому описывать процедуры, типы данных, объекты и действия производимые в них.

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

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



2. Разработка системного проекта

2.1 Характеристика объекта моделирования

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

2.2 Архитектура и функции системы

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

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

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

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

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

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

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

- система формирует и печатает отчеты;

- система обеспечивает сбор необходимых статистических сведений.

2.3 Интерфейсы и распределение функций между человеком и системой

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

2.4 Анализ требований к программным и информационным компонентам системы

Рассчитаем требуемый объем памяти на жестком диске.

Допустим, что в системе имеется 10 000 записей. Для хранения одной записи требуется примерно 50 байт, а для хранения 10 000 - 500 КБ. Для хранения информации о заказе понадобится примерно 50 байт. Для расчета допустим, что в системе на данный момент имеется 6000 заказов. Следовательно, на все заказы потребуется 300 КБ.

Для хранения информации о 10 заказах потребуется около 0,5 МБ памяти. Для хранения информации о 100 заказах потребуется 10 * 0,5 МБ = 5 МБ.

Таким образом, для хранения данных потребуется 40 Гбайт на жестком диске. На хранение других клиентских объектов базы данных необходимо предусмотреть 100-150 Мб. Таким образом, на сервере потребуется минимум 40 Гбайт свободного места, а на клиентских машинах 100-150 Мб.

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

Таким образом, для функционирования системы достаточно ЭВМ с процессором Celeron с тактовой частотой 2,0 ГГц, оперативной памятью 1024MB, объемом жесткого диска от 40 GB, установленный MS, монитор VGA.

2.5 Функциональная модель требований к системе

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

Определим контекстную диаграмму системы (рисунок 1)



Рисунок 1 - Контекстная диаграмма системы

На рисунке 2 представлена развернутая модель «Деятельность сервисного центра».



Рисунок 2 - Развернутая модель «Деятельность сервисного центра»

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

Прецедент использования «Прием оборудования». Основной исполнитель - приемщик. Он оформляет поступившую от клиента заявку.

Прецедент использования «Выдача оборудования». Основной исполнитель - приемщик. Он выдает клиенту отремонтированное оборудование.

Прецедент использования «Ремонт». Это базовый прецедент. Основной исполнитель - Мастер.

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

Основной исполнитель: мастер.

Заинтересованные лица и их требования:

Приемщик - правильно и быстро обслужить клиентов.

Мастер - быстро и качественно устроить неисправное оборудование.

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

Клиент - быстрое обслуживание, акт выполненных работ.

Предусловия. Мастер идентифицирован и аутентифицирован.

Результаты (Постусловия). Взятое на ремонт неисправное устройство устроено.

Основной успешный сценарий (или основной процесс)

1. Мастер из списка доступных заказов принимает оборудование в ремонт, проводит его диагностику.

2. Система присваивает заказу статус о выполнении диагностики.

3. Мастер подтверждает ремонтоспособность оборудования.

4. Система присваивает заказу статус о завершении диагностики и возможности ремонта.

5. Мастер выбирает просмотр запчастей на складе.

6. Система выводит пользователю список запчастей, доступных на складе.

7. Мастер отмечает необходимые запчасти, подтверждает выбор.

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

9. Мастер выбирает «Ремонт завершен».

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

11. Мастер вводит информацию об обнаруженных неисправностях, о выполненной работе, о виде работы, подтверждает введенные данные.

12. Система проверяет данные на корректность.

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

14. Мастер выбирает печать акта выполненных работ.

15. Система выводит акт выполненных работ на печать.

Расширения (или альтернативные потоки)

*а. При каждом выходе системы из строя.

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

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

*а.2. Система восстанавливает предыдущее состояние.

7а. Мастер не нашел в списке нужной запчасти.

7а.1. Мастер выбирает заказ запчастей.

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

7а.3. Мастер вводит название, характеристики, описание требуемых запчастей.

7а.4. Система сохраняет заявку.

12а. Система обнаружила ошибку ввода.

12а.1. Система выводит сообщение об ошибке, возвращает пользователя на предыдущую форму и просит повторить ввод.

12а.2. Мастер вводит данные, подтверждает ввод.

13а. Система обнаруживает сетевую проблему при попытке сохранения данных на сервере.

13а.1. Система выдает пользователю сообщение с текстом ошибки.

13а.2. Пользователь обращается к администратору для устранения проблемы.

13б. Система обнаруживает проблему аппаратного обеспечения компьютера.

13б.1. Система выдает пользователю сообщение с текстом ошибки.

13б.2. Пользователь обращается к администратору для устранения проблемы.

15а. Система обнаруживает проблему при обращении к принтеру.

15а.1. Система выдает пользователю сообщение с текстом ошибки.

15а.2. Пользователь обращается к администратору для устранения проблемы.

2.6 Концептуальная модель интегрированной базы данных

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

1) Приемщик; 2) Мастер; 3) Клиент; 4) Система; 5) Заказ;

Рисунок 3 - Выделенные сущности

Общая схема связи сущностей показана на рисунке 4.

Рисунок 4 - Общая схема связей между сущностями

Рассмотрим возможные атрибуты сущности Клиент.

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



3. Модели данных и модели процессов

3.1 Построение модели процессов

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

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

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

Точка зрения. Модель строится с точки зрения разработчика системы.

При дальнейшей декомпозиции процессов необходимо соблюдать следующие правила:

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

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

Схема модели IDEF0 представлена в Приложении А.



3.2 Построение модели данных

Модель данных строится в методологии IDEF1X с помощью программного продукта ERWin. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных.

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

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

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

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

Помимо связи «многие-ко-многим», в данной работе можно выделить связи «один-ко-многим». Связь «один-ко-многим» соединяет основные таблицы, такие как, например, Приемщик с таблицами График, Заказ.

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

Рисунок 5 - Логическая модель данных «Деятельность сервисного центра»

Диаграммы модели данных на физическом уровне представлена в приложении Б.



3.3 Связь модели данных с моделью процессов

Связывание в BPWin работ с сущностями из ERWin осуществляется с помощью механизмов Экспорта-Импорта, встроенных в данные программные продукты. Связь модели данных и модели процессов представлена в Приложении В.

компьютерный учет ремонтный интерфейс



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

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

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

Достоинства функционально-ориентированных метрик:

- Не зависят от языка программирования

- Легко вычисляются на любой стадии проекта

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

Рисунок 6 - Простая форма «Завершение ремонта»

Внешние вводы: Обнаруженные неисправности, Выполненная работа, Вид работы, Кнопка «ОК», Кнопка «Отмена».

Внешние выводы: Вывод деталей ремонта на экран (обнаруженные неисправности, выполненная работа, вид работы), Сообщение об ошибке «Не все поля заполнены».

Внешние запросы: Проверка заполнения обязательных полей (Обнаруженные неисправности, Выполненная работа, Вид работы).

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

Внешние интерфейсные файлы: Права доступа, Календарь (дата завершения ремонта).

Ранг и оценка сложности внешних вводов:

Ранг и оценка сложности внешних вводов = Средний(4)

Ранг и оценка сложности внешних выводов = Низкий(4)

Ранг и оценка сложности внешних запросов = Низкий(3)

Ранг и оценка сложности внутренних логических файлов = Низкий(7)

Ранг и оценка сложности внешних интерфейсных файлов = Низкий(5)

Таблица 1. Исходные данные для расчета FP-метрик

Имя характеристики Ранг, сложность, количество
	Низкий	Средний	Высокий	Итого
Внешние вводы	0х3 = 0	5x4= 20	0x6 = 0	= 20
Внешние выводы	4х4 = 16	0х4 = 0	0х7 = 0	= 16
Внешние запросы	2х3 = 6	0х3 = 0	0x6 = 0	= 6
Внутренние логические файлы	2х7 = 14	0х10 = 0	0x15 = 0	= 14
Внешние интерфейсные файлы	1х5 = 5	0х7 = 0	0x10 = 0	= 5
Общее количество	= 61

FP = Общее_количество * (0,65+ 0,01 *14i=1Fi)

где Fi -- коэффициенты регулировки сложности.

Каждый коэффициент может принимать следующие значения: 0 -- нет влияния, 1 - случайное, 2 -- небольшое, 3 -- среднее, 4 -- важное, 5 -- основное.

Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (таблица 2).



Таблица 2. Определение системных параметров приложения

Системный параметр Fj	Описание
Передача данных	Сколько средств связи требуется для передачи или обмена информацией с приложением или системой?
Распределенная обработка данных	Как обрабатываются распределенные данные и функции обработки?
Производительность	Нуждается ли пользователь в фиксации времени ответа или производительности?
Распространенность используемой конфигурации	Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?
Скорость транзакций	Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)
Оперативный ввод данных	Какой процент информации надо вводить в режиме онлайн?
Эффективность работы конечного пользователя	Приложение проектировалось для обеспечения эффективной работы конечного пользователя?
Оперативное обновление	Как много внутренних файлов обновляется в онлайновой транзакции?
Сложность обработки	Выполняет ли приложение интенсивную логическую или математическую обработку?
Повторная используемость	Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?
Легкость инсталляции	Насколько трудны преобразование и инсталляция приложения?
Легкость эксплуатации	Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?
Разнообразные условия размещения	Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций?
Простота изменений	Была ли спроектирована, разработана и поддержана в приложении простота изменений?

FP = 61 * (0,65+ 0,01 * (4+3+5+5+5+5+5+3+3+4+2+3+5+4)) = 73,81

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



Таблица 3. Исходные данные для расчета указателя свойств

№	Характеристика	Количество	Сложность	Итого
1	1. Внешние вводы	5	х4	= 20
2	2. Внешние выводы	4	х4	= 16
3	3. Внешние запросы	2	х3	= 6
4	4. Логические файлы	2	х7	= 14
5	5. Интерфейсные файлы	1	х5	= 5
6	6. Количество алгоритмов	2	х3	= 6
Общее количество	= 67

FP = 67 * (0,65+ 0,01 * (4+3+5+5+5+5+5+3+3+4+2+3+5+4)) =81,07

Рисунок 7 - Сложная форма «Новый заказ»

Внешние вводы: Клиент, Оборудование (Тип, Производитель, Модель, Серийный номер, Описание неисправности), Кнопка «Оформить заказ», Кнопка «Отмена».

Внешние выводы: Вывод информации о заказе на экран: Клиент, Тип, Производитель, Модель, Серийный номер, Описание неисправности. Сообщение об ошибке «Не все поля заполнены», «Перед выбором модели необходимо выбрать производителя оборудования», «Перед выбором производителя необходимо выбрать тип оборудования».

Внешние запросы: Проверка заполнения обязательных полей (Клиент, Тип, Производитель, Модель, Серийный номер, Описание неисправности), Проверка прав доступа.

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

Внешние интерфейсные файлы: права доступа, список клиентов, список типов оборудования, список производителей, список моделей.

Ранг и оценка сложности внешних вводов:

Ранг и оценка сложности внешних вводов = Высокий(6)

Ранг и оценка сложности внешних выводов = Средний(5)

Ранг и оценка сложности внешних запросов = Высокий(6)

Ранг и оценка сложности внутренних логических файлов = Низкий(5)

Ранг и оценка сложности внешних интерфейсных файлов = Низкий(5)

Таблица 4. Исходные данные для расчета FP-метрик

	Низкий	Средний	Высокий	Итого
Внешние вводы	0х3 = 0	0x4= 0	8x6 = 48	= 48
Внешние выводы	0х4 = 0	9х4 = 36	0х7 = 0	= 36
Внешние запросы	0х3 = 0	0х3 = 0	7x6 = 42	= 42
Внутренние логические файлы	1х7 = 7	0х10 = 0	0x15 = 0	= 7
Внешние интерфейсные файлы	5х5 = 5	0х7 = 0	0x10 = 0	= 25
Общее количество	= 158

FP = Общее_количество * (0,65+ 0,01 *14i=1Fi)

где Fi -- коэффициенты регулировки сложности.

Каждый коэффициент может принимать следующие значения: 0 -- нет влияния, 1 - случайное, 2 -- небольшое, 3 -- среднее, 4 -- важное, 5 -- основное.

FP = 158 * (0,65+ 0,01 * (4+3+5+5+5+5+5+3+3+4+2+3+5+4)) = 191,18

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

Таблица 5. Исходные данные для расчета указателя свойств

№	Характеристика	Количество	Сложность	Итого
1	1. Внешние вводы	8	х6	= 48
2	2. Внешние выводы	9	х7	= 63
3	3. Внешние запросы	7	х6	= 42
4	4. Логические файлы	1	х7	= 7
5	5. Интерфейсные файлы	5	х5	= 25
6	6. Количество алгоритмов	3	х3	= 9
Общее количество	= 194

FP = 194 * (0,65+ 0,01 * (4+3+5+5+5+5+5+3+3+4+2+3+5+4)) =234,74



Заключение

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

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



Библиографический список

1. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 2006.

2. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. Киев, "Диалектика", 2004.

3. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. "СУБД", 2001, №3.

4. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., "МетаТехнология", 2005.



Приложение А

Рисунок 1 - Декомпозиция работы «Ремонт»

Рисунок 2 - Декомпозиция работы «Выполнение ремонта»



Приложение Б

Рисунок 1 - Физическая модель данных «Деятельность сервисного центра»



Приложение В

Рисунок 1 - Связанная модель данных и модель процессов

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

...