Файл: Разработка информационной системы работы с клиентами автосервиса.pdf

Рисунок 3.1 – схема формирования заказ-наряда

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

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

Рисунок 3.2 – Форма авторизации

Необходимо выбрать сотрудника и ввести пароль. После нажатия клавиши «Ок» от пароля вычисляется хеш-функция и полученный результат сравнивается с данными в базе. Если авторизация проходит успешно, загружается рабочая форма сотрудника согласно его статусу. Посмотреть код программы можно в Приложении А.

Интерфейс генерального директора.

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

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

Все это осуществляется при помощи дополнительных форм.

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

Рисунок 3.3 – Интерфейс генерального директора

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

Рисунок 3.4 – Форма оформления заказа

Для того, чтобы сформировать заказ-наряд, нужно просто нажать кнопку «заказ-наряд» и после оформления заказа появится документ на печать в формате html. На рисунке 3.5 показан пример заказ-накладной.

Рисунок 3.5 – Пример заказ-наряда

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

Рисунок 3.6 – Справочники

На рисунке 3.7 представлена форма для оформления поставки, в неё вносит данные мастер-приемщик. После сохранения данных, в вкладку «остатки запасов» автоматически вносятся принятые мастером-приемщиком материалы.

Рисунок 3.7 – Форма оформления поставки

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

3.8, рисунок 3.9)

Рисунок 3.8 – Форма «отчет»

Рисунок 3.9 - Отчет

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

4. Расчет экономических показателей

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

Расчет будет производиться на основе модели COCOMO.

СОСОМО (от Constructive COst MOdel - конструктивной стоимостной модели) является статистической моделью, так как основана на опыте реализации многих программных проектов. Она создана посредством сбора данных о большом количестве проектов и анализа этой информации, в результате чего получены формулы, наилучшим образом аппроксимирующие имеющиеся данные. Модель СОСОМО:

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

прошла достаточно долгий путь развития, начиная с 1981 года.

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

Модель СОСОМО 2 охватывает три описанных ниже уровня: - уровень предварительного. Для определения необходимых затрат осуществляется оценка размера системы на основе объектных точек прототипа с помощью простой формулы «размер производительность»;

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

пересчитываются в количество строк кода программ;

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

Расчет экономических показателей по методу СОСОМО

В моем проекте пятнадцать форм, пять из них средней сложности (запросы к БД), один отчет и шесть программных модулей на языке С#. Процент повторного использования кода программы – 5%.

Формула для предварительного определения объема работ будет выглядеть так:

PM= (NOP * (1- PROCM/100)) / PROD

где PM – это затраты, выраженные в человеко-месяцах;

NOP – количество объектных точек;

PROCM – процент многократного использования кода;

PROD – производительность, как показано на таблице 4.1.

Таблица 4.1 – Уровни производительности

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

Таблица 4.2 – Характеристика проекта

4.1 Уровень прототипирования

Определим затраты на уровне прототипирования, приняв среднюю производительность программиста 13 точек в месяц ( смотрите таблицу 4.1):

PM=(NOP(1–PROCENT/100))/PROD=85(1 – 5/100)) / 13 = 6,2

(чел/мес.).

Определим длительность выполнения проекта на уровне прототипирования:

TDEV = 3 (PM) (0,33+0,2(В-1,01)) = 3*6,2(0,33+0,2 (1-1,01) = 3*1,8 = 5,4

(мес.),

где В = 1.

4.2 Уровень предварительного проектирования

Определим показатель степени В на основе следующих данных

(таблица 4.3).

Таблица 4.3 – данные для расчета показателя степени В

В= 1,01 +14/100 = 1,15.

Определим множитель на основе следующих данных (таблица

4.4).

Таблица 4.4 – Таблица показателей

М=RCPX*RUSE*PDIF*PERS*PREX*SCED*FCIL=1*1*1*1*1,2

*1*1,1=1,32

Затраты на автоматическую генерацию кода PM_m = 0.

Определим размер программы, приняв число строк кода на одну объектную точку равным 50:

RAZMER = 50*85 = 4,25 тыс. строк.

Определим затраты

PM = 2,5 * RAZMER^B * M+ PM_m = 2,5*4,25^1,15* 1,32 = 17,49

(чел/мес.).

Определим длительность выполнения проекта на уровне прототипирования

TDEV = 3*(PM) (0,33+0,2(В-1,01)) = 3* 17,49(0,33+0,2(1,15-1,01)) = 8,34(мес.).

4.3 Пост архитектурный уровень

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

Таблица 4.5 – Факторы-сомножители