Определение трудоемкости разработки программного продукта

Таблица 2.1 — Справочник Postavka

2. Product — справочник продукции (таблица 2.2).

Таблица 2.2 — Справочник Product

3. Kategoriya — справочник категорий продукции (таблица 2.3).

Таблица 2.3 — Справочник Kategoriya

4. Strana — справочник стран заказчиков (таблица 2.4).

Таблица 2.4 — Справочник Strana

5. Zakazchik — справочник заказчиков (таблица 2.5).

Таблица 2.5 — Справочник Zakazchik

6. Sotrudniki — справочник сотрудников (таблица 2.6), работающих на складах.

Таблица 2.6 — Справочник Sotrudniki

7. Sklad — справочник складов предприятия (таблица 2.7).

Таблица 2.7 — Справочник Sklad

8. Sklad_tov — справочник размещения продукции по складам (таблица 2.8).

Таблица 2.8 — Справочник Sklad_tov

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

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

Рисунок 2.1 – Логическая модель базы данных

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

Рисунок 2.2 – Физическая модель базы данных

Моделирование физической и логической моделей базы данных проводилось с помощью ERwin 4.0.

2.2 Построение диаграммы вариантов использования (UseCase)

Разработка диаграммы вариантов использования преследует цели:

- определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

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

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

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

Диаграмма UseCase, изображённая на рисунке 2.3, позволяет отобразить список операций, которые сможет выполнить сотрудник склада с помощью разрабатываемого программного продукта, а на рисунке 2.4 представлены возможности администратора приложения.

Рисунок 2.3 — Диаграмма UseCase для сотрудника склада

Рисунок 2.4 — Диаграмма UseCase для администратора

Диаграмма Use Case позволяет создать список операций, которые выполняет система. На основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых ею функций [3, 9].

2.3 Построение диаграммы классов автоматизированной системы

Класс — это описание группы объектов, обладающих общими свойствами, поведением, отношениями с другими объектами и семантикой. Для каждого класса указаны атрибуты и операции.

Атрибуты класса определяют состав и структуру данных, хранимых в объектах этого класса. Каждый атрибут имеет имя и тип, определяющий, какие данные он представляет.

Операции представляют собой действия, реализуемые классом. Каждая операция имеет сигнатуру, содержащую имя операции и список параметров [23].

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

Диаграмма классов представлена на рисунке 2.5.

Программа состоит из 12 классов. Исходный текст некоторых классов представлен в Приложении А.

Для обеспечения работоспособности всего функционала основной формы приложения служат классы Main, MainAdd, Form1. Для обеспечения добавления информации, редактирования информации и удаления в базе данных служат классы Post, PostAdd, Sotr, Zak, ZakAdd, Strana, Prod, KatProd, Sklad.

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

Класс Form1 служит для авторизации пользователя.

Классы Post, PostAdd предназначены для работы с таблицей «Поставки»: Post — для просмотра содержимого таблицы и составления отчетов, PostAdd — для добавления и редактирования данных в таблице.

Классы Zak, ZakAdd позволяют работать с таблицей базы данных «Заказчики»: Zak — для просмотра содержимого таблицы и удаления данных, ZakAdd — для добавления и редактирования данных в таблице.

Рисунок 2.5 – Диаграмма классов

Классы Sotr, Strana, Prod, KatProd, Sklad предназначены для работы с таблицами «Сотрудники», «Страна заказчика», «Продукция», «Категория продукции» и «Склад» соответственно. С помощью этих классов информацию в указанные таблицы можно добавлять, редактировать и удалять.

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

2.4 Разработка автоматизированной системы учета передвижения продукции на ОАО «Беларуськалий»

Для создания приложения «Система учета передвижения продукции на ОАО «Баларуськалий»» использовалась среда разработки Microsoft Visual Studio 2012 и интегрированный язык С#.

При разработке применялись следующие компоненты:

­ компонент Button служить для обработки события;

­ компонент TextBox представляет собой стандартный текстовый редактор, в котором отображаются и изменяются данные;

­ компонент ComboBox служит для отображения выпадающего списка;

­ компонент MenuStrip предоставляет систему меню для формы;

­ компонент PictureBox предоставляет элемент управления графическим окном Windows для отображения рисунка;

­ компонент ContextMenuStrip позволяет создавать контексное меню приложения.

­ компонент DataGridView используется для отображения табличных данных [23].

2.5 Тестирование программного продукта

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

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

Тестовый случай — это алгоритмы проверки функциональности программы. Каждый тестовый случай должен обладать следующими свойствами: четкой целью проверки, известными начальными условиями тестирования, строго определенной средой тестирования, тестовыми данными и ожидаемым результатом тестирования [11].

Тестирование позволяет на ранних этапах разработки обнаружить и исправить ошибки и уязвимости программного обеспечения.

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

Результаты тестирования разработанной автоматизированной системы представлены в таблице 2.9.

Таблица 2.9 — Результаты тестирования программы

Окончание таблицы 2.9

Автоматизированная система учета передвижения продукции на ОАО «Беларуськалий» прошла тестирование на платформе Windows 7 и продемонстрировала корректную работу функций и отлаженное взаимодействие функций друг с другом.

3 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Данный программный продукт разработан для учёта передвижения продукции на ОАО «Беларуськалий».

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

Рисунок 3.1 — Форма авторизации пользователя

Как видно из рисунка 3.1 в приложение можно войти под администратором и под работником склада. Если войти под администратором, то нужно ввести только пароль (рисунок 3.2), а если под работником склада — выбрать адрес склада и ФИО работника (рисунок 3.3).

Рисунок 3.2 — Форма авторизации пользователя

Рисунок 3.3 — Форма авторизации пользователя

Пароль администратора храниться в файле в папке приложения, пароли работников в таблице «Сотрудники». Для подключения к базе данных используется технология ADO.NET. При успешном вводе данных открывается главная форма приложения, представленная на рисунке 3.4.

Рисунок 3.4 — Главная форма приложения

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

Рисунок 3.5 — Главная форма приложения

Меню главной формы «Файл» и «Справочники» отличается для администратора и для работника склада. Для администратора доступны все функции приложения (рисунки 3.6 – 3.7), для работника не доступны функции редактирования и удаления данных, а также работа со справочником «Сотрудники» (рисунки 3.8 – 3.9).

Рисунок 3.6 — Меню «Файл» для администратора

Рисунок 3.7 — Меню «Справочники» для администратора

Рисунок 3.8 — Меню «Файл» для сотрудника

Рисунок 3.9 — Меню «Справочники» для сотрудника

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

Рисунок 3.10 — Форма «Добавление / Редактирование» для администратора

Рисунок 3.11 — Форма «Добавление / Редактирование» для сотрудника

Отобразим работу приложения при добавлении, редактировании и удалении данных на главной форме в режиме администратора. Заполненная форма для добавления представлена на рисунке 3.10. Результат добавления представлен на рисунке 3.12. Форма для редактирования данных представлена на рисунке 3.13, результат выполнения операции на рисунках 3.14 – 3.15.

Рисунок 3.12 — Результат добавления данных

Рисунок 3.13 — Форма редактирования данных

Рисунок 3.14 — Результат редактирования данных

Рисунок 3.15 — Результат редактирования данных

Результат удаления данных представлен на рисунке 3.16.

Рисунок 3.16 — Результат удаления данных

Вид меню «Отчеты» на главной форме для администратора и для сотрудника одинаков и представлен на рисунке 3.17.

Рисунок 3.17 — Меню «Отчеты»

На рисунках 3.18 – 3.21 представлены отчеты, которые можно получить при работе с главной формой.

Рисунок 3.18 — Отчет «Товары на складе»

Рисунок 3.19 — Отчет «Список производимой продукции»

Рисунок 3.20 — Отчет «Список заказчиков»

Рисунок 3.21 — Отчет «Список сотрудников»

Форма для работы со справочником «Заказчики» представлена на рисунке 3.22. Из данной формы можно вызвать форму «Справочник «Страны»» (рисунок 3.23).

Рисунок 3.22 — Форма «Справочник «Заказчики»»

Рисунок 3.23 — Форма «Справочник «Страны»»

Формы для работы со справочниками «Сотрудники» и «Склады» представлены на рисунках 3.24 — 3. 25.

Рисунок 3.24 — Форма «Справочник «Сотрудники»»

Рисунок 3.25 — Форма «Справочник «Склады»»

При работе с формой «Справочник «Продукция»» (рисунок 3.26) можно вызвать форму «Справочник «Категории продукции»» (3.27).

Рисунок 3.26 — Форма «Справочник «Продукция»»

Рисунок 3.27 — Форма «Справочник «Категории продукции»»

Для работы с таблицей «Поставки» используется форма, представленная на рисунке 3.28.

Рисунок 3.28 — Форма «Справочник «Поставки»»

Меню «Файл» формы «Справочник «Поставки»» отличается для администратора и для работника склада. Для администратора доступны все функции формы (рисунок 3.29), для работника не доступны функции редактирования и удаления данных (рисунок 3.30).

Рисунок 3.29 — Меню «Файл» для администратора

Рисунок 3.30 — Меню «Файл» для сотрудника

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

Форма для редактирования информации о поставке представлена на рисунке 3.33. При добавлении и изменении данных о поставке автоматически формируется накладная по отгрузке продукции в MS Word. Пример формирования накладной по форме, представленной на рисунке 3.32, представлен на рисунке 3.34.

Рисунок 3.31 — Форма «Поставки: Добавление / Изменение» для администратора

Рисунок 3.32 — Форма «Поставки: Добавление / Изменение» для сотрудника

Рисунок 3.33 — Форма «Поставки: Добавление / Изменение» при изменении данных

Рисунок 3.34 — Накладная по отгрузке продукции

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

Так же при работе со справочником «Поставки» можно сформировать три вида отчета (рисунок 3.35), которые представлены на рисунках 3.36 – 3.38.

Рисунок 3.35 — Меню «Отчеты»

Рисунок 3.36 — Отчет «Товары на складе»

Рисунок 3.37 — Отчет «Список производимой продукции»

Рисунок 3.38 — Отчет «Список заказчиков»

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

4 ЭКОНОМИЧЕСКИЙ РАЗДЕЛ

Определение трудоемкости разработки программного продукта

Трудоемкость разработки программного продукта (ПП) может быть определена укрупненным методом (чел./ч.). При этом необходимо воспользоваться формулой:

, (4.1)

где Т_ОА — трудоемкость подготовки описания задачи и исследования алгоритма решения;

Т_БС — трудоемкость разработки блок-схемы алгоритма;

Т_П — трудоемкость программирования по готовой блок-схеме;

Т_ОТЛ — трудоемкость отладки программы на ЭВМ;

Т_ДР — трудоемкость подготовки документации по задаче в рукописи;

Т_ДО — трудоемкость редактирования, печати и оформления документации по задаче.

Составляющие приведенной формулы определяются, в свою очередь, через условное число операторов Q в разрабатываемом ПП по формуле:

(4.2)

где q — число операторов в программе;

С — коэффициент сложности программы;

p — коэффициент коррекции программы в ходе ее разработки.

Тогда составляющие трудоемкости разработки программы определятся по формулам:

(4.3)

(4.4)

(4.5)

(4.6)

(4.7)

(4.8)

где W — коэффициент увеличения затрат труда вследствие недостаточного описания задачи;

К — коэффициент квалификации разработчика алгоритмов и программ.