Автоматизированная система домоуправления

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

1. Прием заявки
2. Формирование плана работ и выполнение
3. Факт выполненных работ.

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

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

2. Условие эксплуатации

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

3. Требования к составу и параметрам технических средств

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

1. задача поддержания работоспособности технических средств;
2. задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
3. задача установки (инсталляции) программы.

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

Персонал должен иметь  квалификацию «Оператор ЭВМ» (для  работы с оборудованием).

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

Системные требования ПК:

1. Минимальный процессор - 3300 МГц, Intel Core i3.
2. Рекомендуется 2 Гб ОЗУ или более. Минимально допустимый объем 1 Гб (при данном объеме снижается производительность).
3. Дисковод для компакт- или DVD- дисков.
4. Клавиатура и мышь.
5. Монитор и видео адаптер с разрешением минимум 1366 х 768.

 

4. Требования к информационной и программной совместимости

Минимальные системные  требования: Microsoft Windows 7.

5. Требования к маркировке и упаковке

Программа распространяется в виде программного изделия на внешнем  оптическом носителе (компакт-диске).

Программное изделие  должно иметь маркировку  с обозначением товарного знака компании-разработчика, типа (наименования), номера версии, порядкового  номера, даты изготовления и номера сертификата соответствия Госстандарта России (если такой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учётом требований ГОСТ 9181-74.

6. Требования к транспортировке и хранению.

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

1. температура окружающего воздуха, ^оС – от плюс 5 до плюс 50;
2. атмосферное давление, кПа – от 630 до 800 мм;
3. относительная влажность воздуха при 25 ^оС от 40 до 80 %.

2.5. Требования  к программной документации

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

1. описание программы;
2. руководство системного программиста;
3. руководство оператора;

 

2.6. Стадии  и этапы разработки

№	Название  стадии	Описание  стадии	Исполнитель	Сроки
1	Системный анализ	Определение требований ко всем системным элементам	Разработчик	01.04.2013 - 01.05.2013
2	Анализ требований	Описание всех функций системы	Заказчик	01.05.2013 - 15.05.2013
3	Проектирование	Создание представления  об архитектуре системы, модульной  и алгоритмической структурах, о  структуре данных и об интерфейсе	Разработчик	15.05.2013 - 01.07.2013
4	Кодирование	Перевод результатов  проектирования в текст языка  программирования	Разработчик	01.07.2013 - 01.08.2013
5	Тестирование	Выполнение  программы. Выявление дефектов в  ее функционировании, логики и форме  реализации	Разработчик	01.08.2013 - 10.08.2013
6	Сопровождение	Внесение изменений  в эксплуатируемое программное  программное обеспечение: устранение ошибок, усовершенствование ПО	Разработчик	10.08.2013 - 30.08.2013

 

2.7. Порядок  контроля и приемки

При приёмки  программы проводятся приемно-сдаточные испытания на объекте заказчика.

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

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

3. Описание информационной системы

Наименование  ИС: «Автоматизированная система домоуправлениия».

На основании  анализа предметной области для  нашей системы мы проектируем  базу данных которую мы создаем в ERwin.

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

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

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

 

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

1. Определение проблемы и функциональных границ предметной области.
2. Формирование требований.
3. Анализ предметной области.
4. Формирование логической модели.
5. Формирование физической модели.
6. Генерация базы данных.

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

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

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

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

1. Документирование модели (возможность обсуждать структуру данных с конечными пользователями или экспертами предметной области с использованием понятной им терминологии и независимо от ограничений выбранной СУБД, например, требований именований объектов).
2. Масштабирование (возможность построения независимой от СУБД модели данных, что позволяет разрабатывать гетерогенные ИС и переносить структуру данных из одной СУБД в другую СУБД, например, из Microsoft Access в Oracle).

 

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

Ниже изображены логическая и физическая модели БД

 

Рис. 1. Логическая модель данных в Erwin.

 

Рис. 2. Физическая модель данных в Erwin.

 

 

 

Описание  работы системы

Жилец, для получения  услуг по ремонту в квартире, обращается в электронную систему «Домоуправление»:

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

Далее для создания автоматизированной системы «Домоуправление» потребуется Use CASE средство Rational Rose.

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

Диаграмма вариантов использования

Действующие лица (actors):

• Клиент – заполняет заявку на ремонт в квартире.
• Рабочий– получает заявку, выполняет задание заявки, заполняет отчет (факт работ).

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

Рис. 3. Диаграмма  вариантов использования

Диаграмма последовательности

Рис. 4. Диаграмма  последовательности

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

 

 

4. Руководство системного администратора

4.1. Общие сведения о программе

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

Состав технических  средств:

6. Минимальный процессор – Pentium 4.
7. Рекомендуется 1 Гб ОЗУ или более. Минимально допустимый объем 500 Mб (при данном объеме снижается производительность).
8. Дисковод для компакт- или DVD- дисков.
9. Клавиатура и мышь.
10. Монитор и видео адаптер с разрешением минимум 1366 х 768.