27
II ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненныйaцикл (ЖЦ) программного ܖ обеспечения (ПО) ИС – это
непрерывный процесс, который начинается с момента принятия решения о
создании ПО и заканчивается по завершении ܖ его эксплуатации.[5]
Модель ЖЦ ПО представляет собой ܖ структуру, которая определяет
последовательность выполнения и ܖ взаимосвязи ܖ процессов, действий и задач в
течение ЖЦ. Более распространенными являются следующие модели: ܖ каскадная,
с промежуточным контролем и спиральная.
Такие модели как каскадная и с промежуточным контролем включают
следующие этапы ܖ ЖЦ ПО :
Анализ;
Проектирование;
Реализацию;
Внедрение;
Сопровождение.
Отличительной чертой каскаднойaмодели является строго
последовательная ܖ реализация перечисленных выше этапов жизненного ܖ цикла.
Модель имеет следующее достоинство: на каждом из ܖ этапов данная ܖ модель
позволяет формировать законченный комплект ܖ документации и дает
возможность планировать сроки ܖ завершения работ и соответствующие ܖ затраты.
Однако имеется следующий недостаток: реальный процессaразработки ПО в
большинстве случаев не укладывается в такую жесткую схему и требует
возврата к предыдущим этапам до уточнения или пересмотра принятых решений
[17].
В отличие от каскадной ܖ модели с промежуточнымaконтролем жизненный
цикл более близок к реальной разработке и применению ПО. При данной модели
28
допускается возврат каждого этапа жизненного ܖ цикла на любой из предыдущих ܖ
этапов, если требуется выполнение межэтапнойaкорректировки. Кроме того
может быть обеспечена большая ܖ надежность ПО, однако возрастает длительность
периода ܖ разработки.
При спиральной ܖ модели ܖ жизненного цикла отсутствуютaнедостатки
выше описанных моделей. В данной модели основополагающими являются
первоначальные ܖ этапы: анализ и ܖ проектирование, в которых реализуемость
технических решений проверяется с помощью создания прототипов.
Кроме того спиральная ܖ схема разработки позволяет перейти на
следующий ܖ этап не завершив ܖ полностью работы на предыдущем этапе.
Окончательные работы могут быть выполнены на следующем ܖ витке ܖ спирали. В
результате это обеспечивает возможность предъявить заказчику ܖ разработки
некоторый работоспособный ее ܖ вариант, чтобы уточнить требования.
Целью данной ܖ выпускной квалификационнойaработы является
разработка программы учета зеленых ܖ насаждений, способной за счет
автоматизации усовершенствовать учет зеленых ܖ насаждений. В процессе
разработки будет использована каскадная ܖ модель жизненногоaцикла.
Использование этой модели на каждом из этапов позволяет формировать
законченный комплект ܖ документации и дает возможность планироватьaсроки
завершения работ и соответствующие ܖ затраты.
Каскаднаяaмодель включает следующие ܖ этапы [5]:
Анализ
Проектирование
Реализация
Введение
Эксплуатация.
На этапеaанализа ܖ необходимо собрать ܖ информацию по учету средств
измерений и работ по метрологической экспертизе, документообороту
метрологической службы.
На этапе ܖ проектирования по результатам представленной ܖ информации
происходит проектирование базы ܖ данных и структуры ܖ программы.
29
На этапе реализации создается база ܖ данных: создаются все необходимые
справочники документы, регистры. Затем производится настройка ܖ главного меню
и меню всех элементов ܖ программы.
Этап ܖ внедрения включает в себя развертывание технических,
информационных и программных ܖ средств и проведение окончательного
тестирования системы на развернутых средствах, чтобы убедиться в
работоспособности всех модулей системы.
На этапе ܖ эксплуатации необходимо провести ܖ обучение всех
пользователей, которые будут работать с системой.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На этапе ܖ анализа нужно четко установить все виды ܖ данных, которые
будут вводиться в программу ܖ автоматизации. Поскольку если на этом этапе не
будет учтена какая-либо ܖ информация, это отразится на возможности ܖ хранения
данной информации в системе и, следовательно, может быть утрачено использова
ние этой информации в отчетности или другой выходной документации. Чтобы
уменьшить ܖ данный риск ܖ упущенияaинформации, нужно проделать перекрестную
проверку между различными ܖ подразделениями предприятия [18].
На этапе ܖ проектирования нужно провести детальный анализ ܖ информации
и перенести его на структуры базы данных и программы. Постараться избежать
дублированияaинформации в системе.
На этапе ܖ реализации требуется исключить ܖ возможность совершения
пользователем системы ошибочных действий, которые могут повлечь крах
системы или ввод неверныхaданных. Чтобы снизить такой риск, требуется
осуществить тестирование системы достаточным числом пользователей.
На этапе ܖ внедрения нужно проверить наличие необходимого
программногоaобеспечения и лицензий ܖ к нему.
На этапе эксплуатации нужно обеспечить правильное ܖ обучение
пользователей и, чтобы уменьшить рискaпроконтролировать ܖ результаты данного
процесса.
30
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Информационнаяaбезопасность и защитаaинформации технически
выполняется при помощи системы паролей для доступа к информации ܖ разного
уровня. В первую очередь, это пароль для входа пользователя в операционную
систему его рабочего места. Ввод этого пароля открывает пользователю ܖ доступ к
информации на данном ܖ компьютере и к документам, хранящимся на нем. Однако
политика безопасности должна быть сформирована так, чтобы у пользователя
было некоторое ограничение ܖ прав на своем рабочем месте, то есть, к примеру, он
не мог установить вредоносное программное ܖ обеспечение или программы по
копированию ܖ информации. Это несомненно, несколько осложняет работу
пользователя, но при этом дает гарантию защиты информации. В такой ситуации
требуется найти баланс между удобством и комфортом в деятельности ܖ
пользователя и безопасностью ܖ хранения корпоративной ܖ информации.
Программа должна храниться в виде исполняемого файла на жестком
диске компьютера пользователя или на компакт-диске (Flash- накопителе).
Информация, хранящиеся в базе данных системы, составляет
коммерческую тайну, поскольку содержит информацию по продажам,
составляющих основу бизнеса ООО «Инженер Поставка». Поэтому закрытость
информации не позволит злоумышленникам навредить клиентам компании и
самой компании.
Программный продукт, также должен обладать сохранением внесенной
информации даже при сбоях и непредвиденных отключениях электропитания.
Другими словами программный продукт нуждается в автосохранении.
31
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Программный продукт носит название "Информационная система
менеджера по продажам".
Программа реализует основную функцию посредством следующих
модулей.
Модуль Contracts является интерфейсной частью программного продукта и
предназначен для считывания информации о договорах из базы данных, вывода
на экран содержимого базы данных, задания условий фильтрации и организации
вывода данных на печать. Так же данный модуль предназначен для вызова
остальных модулей.
Модуль Clients предназначен для считывания информации о клиентах из
базы данных, вывода на экран содержимого базы данных и редактирования
информации в базе данных.
Модуль Items предназначен для считывания информации о товарах из базы
данных, вывода на экран содержимого базы данных и редактирования
информации в базе данных.
Модуль Managers предназначен для считывания информации о менеджерах
из базы данных, вывода на экран содержимого базы данных и редактирования
информации в базе данных.
Модуль Tasks предназначен для считывания информации об услугах из
базы данных, вывода на экран содержимого базы данных и редактирования
информации в базе данных.
Модуль OrderedItems предназначен для считывания информации о
поставляемых в соответствии с выбранным договором товарах из базы данных,
вывода на экран содержимого базы данных и редактирования информации в базе
данных.
Модуль OrderedTasks предназначен для считывания информации об
оказываемых в соответствии с выбранным договором услугах из базы данных,
вывода на экран содержимого базы данных и редактирования информации в базе
данных.
32
Модуль AddItemToOrder предназначен для организации интерфейса для
добавления в базу данных информации о новом товаре, поставляемом в
соответствии с выбранным договором.
Модуль AddTaskToOrder предназначен для организации интерфейса для
добавления в базу данных информации о новой услуге, оказываемой в
соответствии с выбранным договором.
Модуль NewContract предназначен для организации интерфейса для
добавления в базу данных информации о новом договоре.
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Нормативно-справочная информация для удобства ее использования будет
расположена в следующих справочных таблицах:
- таблица Managers – информация о менеджерах;
- таблица Clients – информация о клиентах;
- таблица Items – информация о товарах;
- таблица Tasks – информация об услугах;
- таблица Contracts – информация о договорах;
- таблица Ordered_items – информация о заказанных товарах;
- таблица Ordered_tasks – информация о заказанных услугах;
Соответственно входные данные следующие:
Таблица Managers:
Имя;
Фамилия;
Номер телефона.
Таблица clients:
Наименование клиента;
Индикатор того, что клиент является юридическим лицом;
Номер телефона;
Описание.
33
Таблица items:
Наименование;
Стоимость;
Описание.
Таблица tasks:
Наименование;
Стоимость;
Длительность выполнения;
Описание.
Таблица contracts:
Номер договора;
Клиент;
Менеджер, заключающий договор;
Дата заключения договора;
Статус исполнения договора;
Дата исполнения договора;
Текст договора;
Полная стоимость договора;
Пометка о расторжении договора;
Таблица ordered_items:
Номер договора;
Количество заказанных единиц товара;
Идентификатор товара .
Таблица ordered_tasks:
Номер договора;
Идентификатор услуги.
34
2.2.3 Характеристика результатной информации
Разрабатываемая программа должна обеспечить следующую
результативную информацию:
– просмотр информации о договорах в базе данных и редактирование этой
информации;
– просмотр информации о клиентах в базе данных и редактирование этой
информации;
– просмотр информации о товарах в базе данных и редактирование этой
информации;
– просмотр информации о менеджерах в базе данных и редактирование
этой информации;
– просмотр информации об услугах в базе данных и редактирование этой
информации;
– просмотр информации о поставляемых в соответствии с выбранным
договором товарах в базе данных и редактирование этой информации;
– просмотр информации об оказываемых в соответствии с выбранным
договором услугах в базе данных и редактирование этой информации;
2.3 Программное обеспечение задачи
2.3.1 Общие положения
Проектирование комплексной по предметной направленности,
интегрированной и, обычно, большой по размеру БД стало сложной задачей.
Наличие целостной методологии проектирования позволило позаботиться о
"сапожнике-проектировщике" и начать шить ему сапоги в виде систем
автоматизации проектирования БД. Этому способствовало наличие
технологического опыта в организации и компьютерной поддержке систем
разработки программного обеспечения и, с другой стороны, использование
активных интегрированных словарей-справочников данных (DD/D, Data
Dictionary/Directory). Так возникли системы CASE (Computer Aided System
35
Engineering) - системы для структурного проектирования БД и связанных с ними
ИС, ориентированные на модели данных, реализованные в различных СУБД.
Наибольшую популярность получили CASE-системы для реляционных СУБД с
SQL-моделями данных, а DD/D переименовался в CASE-репозиторий
проектируемой ИС.
На этом пути возникло два основных направления развития CASE-систем и
технологий проектирования: CASE-системы для проектирования собственно БД
(или т. н. Upper-CASE) и интегрированные инструменты, позволяющие и
проектировать БД, и разрабатывать использующие их прикладные программы.
Важно отметить, что и Upper-CASE в общем случае имеют много средств для
описания функций обработки информации (при использовании процессного
подхода к сбору и анализу сведений о ПрО) и хранения этих описаний в
репозитории [12]. Это подтверждает положение о сильной связи проекта БД и
проекта ИС, базирующейся на этой БД. Вместе с тем эта связь не абсолютна, и
принцип отделения БД от программ сохраняется.
Часто интегрированность функций приводит к сильному сращиванию
CASE-системы с одной СУБД, на которую ориентированы CASE-средства
разработки прикладных программ. Такое сращивание имеет несколько
проявлений, например CASE-репозиторий поддерживается средствами "родной",
но единственной СУБД, генерация прикладных программ производится
"родными" инструментами разработки этой же СУБД, но только ими. Для таких
интегрированных CASE-систем отображение концептуальной модели БД в
логическую схему часто делается также только для предопределенной СУБД [1].
СУДБ MySQL, несмотря на все ее преимущества, не имеет специального
типа данных, приспособленного для хранения данных о денежных суммах.
При хранении информации о денежных суммах недопустимо использовать
вещественные типы данных ввиду того, что мантисса вещественного числа, в
компьютерном представлении, имеет ограниченную и фиксированную длину. В
случае, если речь идет о большой сумме, это может привести к потерям при
округлении, что недопустимо при финансовых операциях. В случае небольших
сумм это может привести к появлению лишних цифр, означающих очень малые
дробные доли копейки, что так же неприемлемо при проведении финансовых
36
операций. Избыточная точность иногда бывает необходима, например, при
осуществлении посоледовательных операций конверсии валют, однако в
разрабатываемом программном продукте нет необходимость в подобных
операциях и значения, используемые для хранения информации о денежных
суммах, можно округлять до второго знака после запятой.
Таким образом, оптимальным типом данных для хранения информации о
денежных суммах в разрабатываемом программном изделии является тип
DECIMAL. Этот тип данных введен в стандарте ANSI/ISO SQL92 и позволяет
хранить числа с фиксированным количеством знаков до и после запятой. Так же
этот тип данных, как и все целочисленные типы данных, может использоваться с
модификатором UNSIGNED, говорящим о том, что хранимые числа могут быть
только положительными и нулем [1]. Однако этот модификатор не описан в
стандарте и от его использования было решено воздержаться.
В свете вышеизложенного, для хранения данных о денежных суммах в базе
данных программного изделия, будут использоваться поля типа DECIMAL.
Количество знаков до запятой будет ограничено восьмью. Количество знаков
после запятой будет ограничено двумя. Все поля, хранящие данные о денежных
суммах, в определениях таблиц описаны как decimal(8,2).
Так же, ввиду отсутствия специального логического типа, для хранения
логических значений используются поля типа tinyint(1).
Для хранения текстовой информации в базе данных будет использоваться
кодировка UTF-8 (Unicode Transformation Format, 8-bit). Выбор обусловлен тем,
что данная кодировка позволяет хранить символы любого языка мира и в тоже
время, при необходимости, сохраняет совместимость с кодировкой ASCII (в ее
семибитном варианте), а так же тем, что данная кодировка становится де-факто
стандартом для хранения и передачи текстовой информации.
2.3.2 Характеристика базы данных
Для описания структуры базы данных (таблиц и полей) в любых СУБД,
использующих язык SQL, используется специальный язык определения данных –
Data Defifnition Language (далее – DDL). Команды DDL языка SQL исполняются,