Разработка информационного обеспечения и анализ данных для информационной системы "Станция технического обслуживания"
Федеральное агентство по образованию
Государственное образовательное учреждение
Высшего профессионального образования
"САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ имени академика С.П. КОРОЛЕВА"
Филиал в г. Тольятти
Кафедра радиоэлектроники и системотехники
Пояснительная записка к курсовой работе
по дисциплине "Базы данных"
Разработка информационного обеспечения и анализ данных для информационной системы "Станция технического обслуживания"
Руководитель,
доцент, к. п. н. Лаптева С.В.
Исполнитель
студентка
Тольятти 2010
Задание на курсовой проект
студенту группы _________
________________________
(Фамилия, И.О.)
1. Тема работы
______________________________________________________________________________________________________________________________________________________________________________________________________
2. Содержание работы
________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
3. Исходная информация к работе
________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
4. Перечень и объем текстовых, графических и электронных материалов
______________________________________________________________________________________________________________________________________________________________________________________________________
5. Основная литература
________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
6. Календарный план выполнения работ
|
Содержание работы по этапам |
Объем этапа к общему объему работы, % |
Срок окончания |
Фактическое выполнение |
|
1. Утверждение задания |
|||
Руководитель работы
_____________________________________________________________
(подпись) (ФИО)
Задание принял к исполнению _______________ "___" ___________ 2010 г.
(подпись студента)
Реферат
Курсовая работа.
Пояснительная записка 46 с., 8 рис., 18 табл., 4 источника
Анализ предметной области, постановка задачи на проектирование, Инфологическое проектирование даны, Даталогическое проектирование. Нормализация данных, Физическое проектирование, Функциональная схема приложения, Математические методы в прогнозировании, Отладка и тестирования, методология Чена
Основной целью курсовой работы является разработка интерфейсной и функциональной части информационной системы для станции технического обслуживания.
Для достижения данной цели выполнен ряд задач: проанализирована предметная область, выявлены основные виды деятельности организации, рассмотрена структура организации, определён уровень автоматизации на текущий момент, выявлены проблемы, которые необходимо устранить с помощью автоматизации, разработана схема автоматизированной работы организации, разработан проект информационной системы, выбрано программное обеспечение для реализации.
Предметом исследования является автоматизация информационной системы с учётом всех требований к применяемому для разработки программному обеспечению.
Объектом исследования является станция технического обслуживания, систему которой необходимо автоматизировать для упрощения и удобства работы сотрудников.
Результат данного проекта - информационная система с удобным интерфейсом и работоспособной функциональной частью.
Содержание
Введение
1. Анализ предметной области и постановка задачи на проектирование
1.1 Описание деятельности организации
1.2 Определение проблемных областей в функционировании организации
1.3 Постановка задачи на проектирование
2. Проектирование информационного обеспечения и функциональной части АИС
2.1 Проектирование внешнего информационного обеспечения
2.2 Инфологическое проектирование данных
2.3 Анализ и выбор ПО для разработки СУБД
2.4 Функциональная схема приложения
2.5 Описание особенностей интерфейса. Разработка отчётов
2.6 Математические методы в прогнозировании
2.6.1 Формулировка задачи на прогнозирование
2.6.2 Экстрополяционные методы прогнозирования
2.6.3 Метод Исторической Аналогии
2.6.4 Экспертные методы
2.6.5 Метод эвристического прогнозирования (МЭП)
2.6.6 Балансовый метод
2.6.7 Сбор данных. Описание исходных данных
2.7 Выходные данные, графики, прогнозы
3. Реализация БД и функциональной части АИС
3.1 Реализация БД в среде С++ Builder
3.2 Разработка интерфейса приложения
3.3 Описание реализации модуля прогнозирования
3.4 Тестирование нефункциональных параметров программы
Заключение
Литература
Введение
Актуальность. На любых предприятиях, станциях, заводах существуют базы данных, содержащие информацию о всех необходимых объектах, а также о работающем персонале. Для того, чтобы вести отчётность или изменять какие-либо данные в этих базах, необходимо заполнять множество бумажных документов, что очень затрудняет работу сотрудников и требует дополнительные затраты на работников таких отделов. Поиск нужной информации также затруднён, так как в большом количестве информации очень сложно искать нужные данные вручную. Из представленных проблем очевидно, что необходимо создать систему сбора, хранения и обработки данных, которая упростит работу сотрудников. Информационная система позволит перейти на более высокий уровень обслуживания клиентов, заполнения договоров и ведения отчётности.
Цель курсового проекта:
Разработать интерфейсную и функциональные части информационной системы для станции технического обслуживания.
Задачи:
проанализировать предметную область;
выявить основные виды деятельности организации;
рассмотреть структуру организации;
определить уровень автоматизации на текущий момент;
выявить проблемы при работе, которые необходимо устранить с помощью автоматизации;
разработать схему автоматизированной работы организации
разработать проект информационной системы, учитывая все этапы проектирования;
выбрать программное обеспечение для реализации;
реализовать проект, учитывая все требования к интерфейсной и функциональной частям.
Предмет исследования: автоматизация информационной системы с учётом всех требований к применяемому для разработки программному обеспечению.
Объект исследования: станция технического обслуживания, систему которой необходимо автоматизировать для упрощения и удобства работы сотрудников.
1. Анализ предметной области и постановка задачи на проектирование
1.1 Описание деятельности организации
В настоящий момент в организации работают: секретарь, менеджер, бригадир, мастера по различным услугам, товаровед.
Товаровед ведёт учётность деталей и других товаров и комплектующих, которые можно приобрести или заменить на СТО. В его обязанности входит:
Выявления нехватающих комплектующих;
Заказ комплектующих;
Контроль поставок комплектующих;
Ведение отчётности по комплектующим
Секретарь работает с клиентами. В его обязанности входит:
Оформление заказа;
Проставление стоимости услуг;
Подсчёт стоимости заказа;
Приём оплаты;
Выписка чека;
Снятие заказа с учёта после его выдачи заказчику
Отправка заказа в архив
Менеджер распределяет работы и ведёт финансовую отчётность. В его обязанности входит:
Распределение заказов по мастерам;
Оформление бланка на выполнение;
Снятие заказа с учёта на выполнение (после его выполнения);
Начисление заработной платы;
Ведение финансовой отчётности
Бригадир курирует работу мастеров, принимает работу и сдаёт ей заказчику. В его обязанности входит:
Приём от менеджера бланков на выполнение;
Доставка бланков до мастеров;
Контроль сроков выполнения заказов;
Приём работы мастеров;
Информирование менеджера о завершении работ;
Сдача выполненного заказа клиенту
Каждый мастер принимает заказ на выполнение, подписывает бланк на выполнение, выполняет заказ и сдаёт.
Описание бизнес-процессов организации на текущий момент
Клиент приходит на станцию технического обслуживания и обращается к секретарю. Секретарь на специальном бланке оформляет заказ, проставляет в нём стоимости всех услуг согласно ценам, поставленным данной организацией, которые прописаны в постановлении о стоимости услуг. Далее секретарь подсчитывает стоимость всего заказа, принимает оплату от клиента и выписывает чек. В чеке прописываются данные заказчика, данные его автомобиля, номер заказа, стоимость. В конце дня секретарь сдаёт все эти бланки менеджеру. На следующий день менеджер ознакамливается с оформленными заказами и распределяет их по мастерам, учитывая загруженность того или иного мастера, прописывая его данные на бланке заказа. Далее менеджер оформляет бланк на выполнение, в котором прописывает номер заказа, данные мастера, услуги, требования и сроки выполнения. Бланки на выполнение сдаются бригадиру, который доставляет их мастерам. Мастер принимает заказ на выполнение, ознакамливается с требованиями и подписывает бланк на выполнение. После выполнения заказа мастер оповещает об этом бригадира. Бригадир принимает работу и, если нет замечаний, отмечает на бланке на выполнение завершение заказа, информирует менеджера о выполнении заказа и сдаёт бланк. Менеджер отмечает в бланке заказа выполнение, в книге "Отчёты заработной платы" прописывает сумму от выполненного заказа мастеру, отдаёт бланк выполненного заказа секретарю. Когда клиент приходит за своим заказом, секретарь по чеку заказчика ищет бланк выполненного заказа. Если такой имеется, то клиента направляют к бригадиру с бланком заказа. Бригадир сдаёт работу клиенту. Если клиент не имеет претензий, он забирает свой автомобиль и ставит на бланке заказа в графе замечания "нет замечаний". После этого бригадир возвращает бланк секретарю, секретарь закрепляет степлером бланк заказа, чек заказчика и бланк на выполнение и складывает в архив. Если же клиент не удовлетворён работой, то заказ ставится на учёт "Доработка" и возвращается мастеру. После выполнения доработки заказ проходит тот же путь, что и после первого выполнения.
Для лучшего понимания все эти процессы можно отобразить схемой:
Рисунок 1 - Краткая схема бизнес-процессов на СТО
Рисунок 2 - схема продвижения документов на выполнение заказа
Работу товароведа можно описать следующим образом: каждую неделю товаровед берёт выполненные заказы у секретаря, смотрит какие комплектующие были использованы, ищет в книге "Заказ комплектующих" название этой детали и добавляет одну единицу в заказ данной детали. Далее подсчитывает количество каждой детали, которую надо приобрести, подсчитывает сумму заказа и заказывает детали у поставщика. Деньги на заказ комплектующих перечисляются еженедельно в одном и том же размере.
1.2 Определение проблемных областей в функционировании организации
Рассмотрев подетально каждый процесс на станции технического обслуживания, можно выявить ряд проблем, связанных с ручным заполнением различных документов.
Во-первых, когда приходит клиент для оформления заказа, необходимо заново заполнять все его данные, даже если он обращается в данную организацию не первый раз.
Во-вторых, ручное заполнение документов подвергает риску ошибок.
В-третьих, присутствует слишком много бумажной волокиты, связанной с тем, что один и тот же заказ обрабатывают разные люди.
В-четвёртых, возможна утеря одной или нескольких составляющих документации о заказах.
В-пятых, хранение архивов заказов в бумажных библиотеках значительно затрудняет поиск нужного заказа при возникновении какой-либо спорной или конфликтной ситуации.
В-шестых, хранение архивов заказов необходимо в течении трёх лет, после чего их следует уничтожить. Для человека становится накладно проверять даты заказов и удалять просроченные, поэтому часто хранится много лишней макулатуры.
Хранение архивов занимает дополнительное помещение, вследствие чего появляются дополнительные денежные затраты. Эта проблема является седьмой.
Восьмой причиной внедрения автоматизации является неудобная и неэффективная работа с заказами комплектующих и введения отчётности в данной области. Ручное оформление заказа и ведение отчётности замедляет и усложняет работу товароведа. Также имеется большой риск ошибок из-за частой переписи названий и параметров комплектующих.
Таким образом, проблемной областью считается ведение бумажной документации и полное отсутствие автоматизации.
Описание автоматизированных бизнес-процессов организации
Для решения перечисленных выше проблем, необходимо разработать автоматизированную информационную систему, которая будет позвалять выполнять поиск, что ускорит заполнение заказа и выполнять автоматически следующие некоторые процессы. А именно:
возможность найти клиента из базы, если этот клиент однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчёт общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения
Таким образом, бизнес-процессы в организации после реализации автоматизации можно описать следующим образом:
Клиент обращается к секретарю. Секретарь пробивает по существующей базе данного клиента. Если клиент есть в базе данных, то его данные автоматически заполняются в следующем заказе. Если же нет клиента в базе данных организации, то секретарь вводит все данные клиента и оформляет заказ. При этом данные клиента заносятся в базу данных, хранящую информацию о клиентах, и этому клиенту присваивается свой уникальный номер. После заполнения данных о клиенте, выбираются нужные услуги из списка, и информация об услуге автоматически переходит в заказ. Далее происходит автовычисление общей стоимости заказа, и ограничения сроков выполнения согласно требованию клиента. После всего этого заказ сохраняется и становится доступным для менеджера. Секретарь выводит на лист чек, в котором прописан номер заказа, сумма, дата выполнения и данные авто. Менеджер открывает сохранённый заказ, распределяет услуги по мастерам, согласно их нагрузке. Информацию о нагрузке можно просмотреть на сводной форме, в которой прописывается по каждому мастеру все его заказы и сроки их сдачи на текущий момент. Как только заказ снимается с выполнения, эта информация автоматически меняется. После распределения обязанностей менеджер формирует задания на выполнения для каждого мастера и сохраняет как новые задания. При этом формирование задания происходит практически автоматически, считывая информацию с заказа. Бригадир, получив новые задания, распечатывает их на отдельных бланках на выполнение для каждого мастера. Это упрощает работу мастеров, так как им не требуется каждый раз обращаться к рабочей станции системы. После выполнения мастером заказа бригадир принимает работу и отправляет заказ в выполненные. Далее этот заказ лежит в базе до востребования клиентом. Когда клиент приходит за заказом, секретарь проверяет через поиск выполненных заказов есть ли требуемый. Если заказ выполнен, секретарь вызывает по телефону бригадира. Бригадир отводит клиента в сервис и сдаёт ему заказ.
Заказ и поставка деталей и комплектующих осуществляется следующим образом: при переходе заказа в графу "выполненные", все использованные на данный автомобиль детали, переносятся в список "Заказ комплектующих". Также заказать комплектующие может бригадир, вписав её в список заказов. Заказ комплектующих непосредственно поставщикам и контроль поставок осуществляет товаровед.
1.3 Постановка задачи на проектирование
На основе описания автоматизированных бизнес-процессов станции технического обслуживания поставлена задача: разработать автоматизированную информационную систему для СТО, в которой автоматически будут осуществляться следующие функции:
поиск клиента, который однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчёт общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения
составление списка комплектующих, которые необходимо поставить
В АИС должны храниться следующие данные:
база клиентов;
база мастеров;
база комплектующих;
база выполненных заказов
текущие данные о заказах, зарплатах, комплектующих
Доступ к базе данных у всех сотрудников одинаков.
Таким образом, в данном разделе была рассмотрена структура организации и деятельность всех сотрудников. Были описаны все бизнес-процессы на текущий момент и определены проблемные области:
необходимость заполнения заново всех данных клиента, даже если он обращается в данную организацию не первый раз;
ручное заполнение документов подвергает риску ошибок;
большая бумажная волокита;
возможность утери одной или нескольких составляющих документации о заказах;
затруднение поиска нужного;
хранение много лишней макулатуры.
Также описаны автоматизированные бизнес-процессы и их преимущества:
возможность найти клиента из базы, если этот клиент однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчёт общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения
Произведена постановка задачи на проектирование: разработать автоматизированную информационную систему для СТО, в которой автоматически будут осуществляться функции, описанные в автоматизированных бизнес-процессах.
2. Проектирование информационного обеспечения и функциональной части АИС
2.1 Проектирование внешнего информационного обеспечения
Согласно обязанностям сотрудников, описанных в системном анализе можно более точно описать их деятельность, чтобы составить выделить объекты и определить связи между ними.
Секретарь оформляет заказ. Менеджер принимает заказ на выполнение, формирует задание для мастеров и передаёт бригадиру. Бригадир принимает на выполнение, принимает выполненный заказ и снимает его с выполнения. Таким образом заказ содержит информацию о клиенте, обо всех сотрудниках, принимавших участие в организации заказа, о всех мастерах, выполнявших заказ, и об услугах, которые они выполняют о деталях, использовавших в заказе. Связь между клиентом и заказом будет один-ко-многим, так как в заказе может быть только один клиент, а у одного клиента может быть несколько заказав, причём даже сделанных в разное время. Связь между сотрудниками и заказом - многие-ко-многим, так как в организации заказов принимают участие несколько сотрудников, но также каждый из сотрудников организовывает много заказов. Аналогично, определяются связь между заказом и мастером. Связь между заказом и деталью тоже будет многие-ко-многим, так как в одном заказе могут быть несколько деталей, также детали, имеющие одни и те же параметры могут быть использованы, в разных заказах.
Одни и те же услуги могут выполнять разные мастера, поэтому услугу можно представить как отдельный объект. С другой стороны один и тот же мастер может выполнять много услуг, поэтому отношение между услугой и мастером будет многие-ко-многим.
Зарплата мастеров зависит от выполняемых заказов, поэтому для каждого мастера необходимо завести "зарплатную книжку", то есть сформировать таблицу, которая будет в себе содержать информацию о мастере и его текущие начисления. То есть появляется новый объект "зарплата мастера".
Для формирования финансового отчёта необходимо учитывать заработную плату всех сотрудников, которая определяется окладом, заработную плату мастеров, которая начисляется в соответствии с выполненными заказами, а также расходы на покупку деталей. То есть появляется ещё один объект "отчёт", который включает в себя информацию о заработных платах и о заказах склада. Отношение между сотрудником и отчётом - один-ко-многим, так как в отчёте хранятся данные о всех сотрудниках, а у одного сотрудника может быть только одна зарплата. Аналогично определяется связь между зарплатой мастера и отчётом. Связь между заказом деталей и отчётом так же будет один-ко-могим, так как в отчёте хранятся данные по четырём заказам склада, соответствуя четырём неделям месяца. Заказ склада, в свою очередь содержит в себе информацию о деталях и стоимость. Связь между деталью и заказом склада - один-ко-многим.
Таким образом выделены следующие объекты: заказ, клиент, сотрудник, принимающий участие в организации заказа (секретарь, менеджер, бригадир), мастер, услуга, квалификация, заработная плата мастера, деталь, заказ деталей, отчёт по распределению финансов.
2.2 Инфологическое проектирование данных
Согласно представленным объектам в системном анализе предметной области необходимо представить объекты в виде сущностей и связей. Для этого будет использоваться методология Питера Чена:
Рисунок 3 - Инфологическая модель данных
В данной схеме хорошо просматриваются сущности, их атрибуты и связи. Сущности и связи соответствуют объектам, выделенным в предыдущем пункте, и их связям.
Датaлогическое проектирование. Нормализация данных
Для дальнейшего проектирования необходимо выбрать CASE-средства. Оценка CASE-средств будет производиться по следующим критериям:
возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения;
удобство пользовательского интерфейса. Удобство расположения и представления часто используемых элементов экрана, способов ввода данных и др.;
простота освоения. Трудовые и временные затраты на освоение средств;
совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным);
совместимость с версиями ОС (возможность работы в среде различных версий одной и той же ОС, простота модификации CASE-средства для работы с новыми версиями ОС);
переносимость данных между различными версиями CASE-средства;
затраты на CASE-средство. Включают стоимость приобретения, установки, начального сопровождения и обучения. С учётом цены для всех необходимых конфигураций (включая единственную копию, несколько копий, локальную лицензию, лицензию для предприятия, сетевую лицензию).
Каждый критерий может иметь оценку 0-5.
Оценка "0" означает, что данное программное обеспечение полностью не удовлетворяет требованию критерия.
Оценка "5" означает, что данный критерий выполняется полностью.
То CASE-средство, которое будет иметь наибольший балл, будет принято. Балл этого программного обеспечения не должен быть меньше 30.
Оценка отражена в таблице1.
В выборе и оценке учавствуют следующие программные средства: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+BPwin, S-Designor, CASE. Аналитик.
Таблица 1
Оценка CASE-средств
|
CASE-средства Критерии оценки |
Westmount I-CASE |
Designer/2000 |
Silverrun |
ERwin+BPwin |
S-Designor |
CASE. Аналитик |
|
возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения |
5 |
5 |
5 |
5 |
5 |
5 |
|
удобство пользовательского интерфейса |
4 |
3 |
3 |
5 |
4 |
4 |
|
простота освоения |
4 |
3 |
4 |
5 |
5 |
4 |
|
совместимость обновлений |
5 |
5 |
5 |
5 |
5 |
4 |
|
совместимость с версиями ОС |
5 |
5 |
5 |
5 |
4 |
5 |
|
переносимость данных между различными версиями CASE-средства |
5 |
4 |
5 |
5 |
4 |
5 |
|
затраты на CASE-средство |
4 |
3 |
0 |
4 |
4 |
0 |
|
ИТОГОВЫЙ БАЛЛ |
32 |
28 |
27 |
34 |
31 |
26 |
Из приведённой таблицы видно, что наиболее удобным средством для проектирования является Computer Associates Erwin, так как он имеет наибольший балл.
Переведём сущности и связи, определённые в предыдущем пункте, в отношения и связи. Для этого будем использовать логическую ER-модель.
Для нормализации данных необходимо устранить связи многие-ко-многим. Для этого эти связи разрываются дополнительной таблицей. Эта нормализация отображена на рисунке 5.
Рисунок 4 - Модель данных до нормализации
Рисунок 5 - Логическая схема данных
Нормализация необходима для устранения избыточности данных, которая возможна при наличии связей многие-ко-многим.
Физическое проектирование без учёта ПО для разработки СУБД
Все СУБД имеют определённый набор типов данных, имеющих одинаковый смысл, но имеющие разное написание. Поэтому можно определить общие типы данных, не ссылаясь на определённую СУБД. Для этого для каждой таблицы опишем все атрибуты, их расшифровки и общие типы.
Таблица 2
Определение типов таблицы "Клиент"
|
Атрибут |
Расшифровка |
Тип |
|
id_klient |
Идентификационный номер |
Автосчётчик |
|
fam |
Фамилия |
Строка |
|
name |
Имя |
Строка |
|
otch |
Отчество |
Строка |
|
nomer_avto |
Номер автомобиля |
Строка |
Таблица 3
Определение типов таблицы "Заказ"
|
Атрибут |
Расшифровка |
Тип |
|
id_sakas |
Идентификационный номер |
Автосчётчик |
|
id_klient |
ID клиента |
Длинное целое |
|
data_oformlenia |
Дата оформления |
Дата |
|
stoimost |
Стоимость |
Деньги |
|
data_vipolnenia |
Дата выполнения |
Дата |
|
data_zakritia |
Дата закрытия |
Дата |
Таблица 4
Определение типов таблицы "Деталь"
|
Атрибут |
Расшифровка |
Тип |
|
id_detal |
Идентификационный номер |
Автосчётчик |
|
Detal |
Деталь |
Строка |
|
Cena |
Цена |
Деньги |
|
kol |
Количество |
Байт |
Таблица 5
Определение типов таблицы "Заказ склада"
|
Атрибут |
Расшифровка |
Тип |
|
id_sak_sklada |
Идентификационный номер |
Автосчётчик |
|
id_detal |
ID детали |
Длинное целое |
|
Stoim_sak |
Стоимость заказа |
Деньги |
Таблица 6
Определение типов таблицы "Деталь-заказ"
|
Атрибут |
Расшифровка |
Тип |
|
id_detal |
ID детали |
Длинное целое |
|
id_sakas |
ID заказа |
Длинное целое |
|
id_klient |
ID клиента |
Длинное целое |
Таблица 7
Определение типов таблицы "Мастер"
|
Атрибут |
Расшифровка |
Тип |
|
id_master |
Идентификационный номер |
Автосчётчик |
|
Fam |
Фамилия |
Строка |
|
Name |
Имя |
Строка |
|
Otch |
Отчество |
Строка |
|
Stash |
Стаж |
Байт |
|
nomer_pasp |
Номер паспорта |
Длинное целое |
|
seria_pasp |
Серия паспорта |
Целое |
|
data_post_na_rab |
Дата поступления на работу |
Дата |
|
id_kvalif |
ID квалификации |
Длинное целое |
Таблица 8
Определение типов таблицы "Квалификация"
|
Атрибут |
Расшифровка |
Тип |
|
id_kvalif |
Идентификационный номер |
Автосчётчик |
|
Kvalif |
Квалификация |
Строка |
Таблица 9
Определение общих типов таблицы "Мастер-заказ"
|
Атрибут |
Расшифровка |
Тип |
|
id_master |
ID мастера |
Длинное целое |
|
id_sakas |
ID заказа |
Длинное целое |
|
id_klient |
ID клиента |
Длинное целое |
Таблица 10
Определение типов таблицы "Зарплата мастера"
|
Атрибут |
Расшифровка |
Тип |
|
Id_zp_mst |
Идентификационный номер |
Автосчётчик |
|
Kol_sak |
Количество заказов |
Целое |
|
Nachisleno |
Начислено |
Вещественное |
|
id_master |
ID мастера |
Длинное целое |
Таблица 11
Определение типов таблицы "Услуги"
|
Атрибут |
Расшифровка |
Тип |
|
id_uslugi |
Идентификационный номер |
Автосчётчик |
|
usluga |
Название услуги |
Строка |
|
cena |
Цена |
Деньги |
Таблица 12
Определение типов таблицы "Мастер-услуга"
|
Атрибут |
Расшифровка |
Тип |
|
id_uslugi |
ID услуги |
Длинное целое |
|
id_master |
ID мастера |
Длинное целое |
Таблица 13
Определение типов таблицы "Сотрудник"
|
Атрибут |
Расшифровка |
Тип |
|
id_sotrudnik |
Идентификационный номер |
Автосчётчик |
|
Fam |
Фамилия |
Строка |
|
Name |
Имя |
Строка |
|
Otch |
Отчество |
Строка |
|
dolzhnost |
Должность |
Строка |
|
seria_pasp |
Серия паспорта |
Целое |
|
nomer_pasp |
Номер паспорта |
Длинное целое |
|
data_post_na_rab |
Дата поступления на |
Дата |
|
oklad |
Оклад |
Деньги |
Таблица 14
Определение типов таблицы "Заказ-сотрудник"
|
Атрибут |
Расшифровка |
Тип |
|
id_sakas |
ID заказа |
Длинное целое |
|
id_klient |
ID клиента |
Длинное целое |
|
id_sotrudnik |
ID сотрудника |
Длинное целое |
Таблица 15
Определение общих типов таблицы "Отчёт"
|
Атрибут |
Расшифровка |
Тип |
|
id_otch |
Идентификационный номер |
Автосчётчик |
|
id_zp_mst |
ID зарплаты мастера |
Длинное целое |
|
id_sotrudnik |
ID сотрудника |
Длинное целое |
|
id_sak_sklada |
ID заказа склада |
Длинное целое |
|
id_detal |
ID детали |
Длинное целое |
|
Mes |
Месяц |
Строка |
|
god |
Год |
Строка |
Таким образом, определены все таблицы для разработки базы данных с общими типами. Для определения конкретных типов необходимо выбрать программное обеспечение для реализации информационной системы.
2.3 Анализ и выбор ПО для разработки СУБД
Для выбора программного обеспечения для реализации оценим несколько самых распространённых программных продуктов по следующим критериям:
распространённость;
финансовая доступность;
поддержка защиты данных;
Каждый критерий оценивается по трехбалльной системе и может принимать значения "1", "2", "3". Где оценка "1" соответствует наихудшему удовлетворению критерия, а оценка "3" - наилучшему.
Таблица 16
Оценка программного обеспечения для реализации
|
Программное обеспечение Критерии |
Paradox 7 |
Oracle |
INFORMIX |
INTRBASE |
MsAccess |
MsSQL |
|
распространённость |
3 |
3 |
2 |
2 |
3 |
3 |
|
финансовая доступность |
3 |
1 |
3 |
2 |
3 |
2 |
|
поддержка защиты данных |
3 |
3 |
1 |
2 |
2 |
2 |
|
ИТОГОВЫЙ БАЛЛ: |
9 |
7 |
6 |
6 |
8 |
7 |
Следуя из оценки программного обеспечения, для разработки данной информационной системы будет взята за основу СУБД Paradox 7.
Информационную систему можно реализовать в различных средах программирования. Например, таких как: SQL, Java, JavaScript, XML, Builder C++, Visual Basic, Delphi. Для разработки системы нужного уровня наиболее часто применяются Builder C++, Visual Basic, Delphi, поэтому производить оценку будем именно по ним.
Для выбора среды программирования для реализации оценим каждый программный продукт по следующим критериям:
генерация кода. Возможность генерации кодов на одном или нескольких языках на основе проектных спецификаций. Типы генерируемого кода могут включать обычный программный код, схему базы данных, запросы, экраны/меню;
компиляция кода;
отладка. Типичные функции отладки - трассировка программ, выделение узких мест и наиболее часто используемых фрагментов кода и т.д.;
генерация экранных форм;
механизм доступа к определённой БД:
надёжность
Все перечисленные выше критерии имеют одинаковую значимость, поэтому оцениваются по одной шкале оценок.
Критерии могут иметь оценки 1,2,3.
Оценка "1" означает, что ПО минимально удовлетворяет данному критерию или не удовлетворяет вообще.
Оценка "2" показывают среднюю степень выполнения условий критерия.
Оценка "3" означает, что критерий в данном ПО выполняется полностью.
Оценка программного обеспечения представлена в таблице 17.
Таблица 17
Оценка средств программирования
|
Программные продукты Критерии |
Builder C++ |
Visual Basic |
Delphi |
|
генерация кода |
2 |
3 |
|
|
компиляция кода |
3 |
3 |
|
|
отладка |
3 |
2 |
|
|
генерация экранных форм |
3 |
3 |
|
|
механизм доступа к определённой БД |
3 |
2 |
|
|
надёжность |
3 |
2 |
|
|
ИТОГОВЫЙ БАЛЛ: |
17 |
16 |
Из оценки по поставленным критериям видно, что для разработки данной БД наиболее подходящим является среда программирования Builder С++.
2.4 Функциональная схема приложения
Для внесения ясности в функциональную схему приложения распишем некоторые основные функции более подробно.
Функция поиска клиента по базе данных:
Поиск будет осуществляться по ID клиента, если он его помнит, или по фамилии и номеру автомобиля. Если поиск производиться по ID клиента, то в таблице "Клиент" перебираются все ID и на экран выводится фамилия, имя, отчество и номер автомобиля клиента, чтобы исключить случайные ошибки. Если же поиск производиться по фамилии и номеру автомобиля, то в таблице "Клиент" перебираются фамилии и номера машин так, чтобы одновременно совпадали оба параметра, так как клиенты могут бить с одинаковыми фамилиями. Если клиент не найден, на экран должно выйти сообщение. Если клиент найден, то есть он уже когда-либо оформлял заказы, то информация о его заказах должна вывестись на экран.
Функция оформления нового заказа:
Если клиент найден в базе данных, то при оформлении заказа известная информация автоматически заносится в форму. Другая нужная информация: детали, услуги, данные о исполняющих мастерах - вводится путём выбора из списка, чтобы избежать различных опечаток. При выборе какой-либо детали заполняется таблица "Деталь-заказ", в которой прописываются данные ID заказа и ID детали. При этом из таблицы "Деталь" в записи соответствующей детали меняется количество. Это необходимо для учёта деталей на складе.
Если же поиск не дал положительных результатов, то фамилия, имя, отчество и номер автомобиля клиента вводится вручную. Остальная информация вводится аналогично из списка. При добавлении заказа в таблицы сначала заполняется таблица "Клиент", новому клиенту присваивается ID, которое система высчитывает автоматически, так как тип данного поля - автосчётчик. Последующая информация вводится в таблицы аналогично первому случаю поиска.
Функция авоподсчёта стоимости заказа:
При сохранении заказа система считывает информацию по каждой услуге и детали через их ID. При подсчёте стоимости деталей учитывается также число каждого типа деталей, так как замене могут подлежать сразу несколько одинаковых деталей. Далее все эти стоимости складываются, и результат выводиться на экран и сохраняется также в заказ. Все дополнительные расходы и оплата за работу, входят в стоимость деталей и услуг, поэтому не требуют дополнительных расчётов.
Автоудаление заказов, не требующих дальнейшего хранения:
В каждом заказе отмечается дата закрытия заказа. По закону необходимо хранить все отчёты 3 года. Для того чтобы не занимать лишние ресурсы памяти, заказы, дата закрытия которых раньше, чем 3 года назад, удаляются. То есть система периодически сверяет текущую дату с датой закрытия заказа, и, если разность дат превышает 3 года, заказ удаляется.
2.5 Описание особенностей интерфейса. Разработка отчётов
На основе основных функций распишем необходимые отчёты.
Для того чтобы заказчик мог забрать свой заказ, необходимо предоставить ему некоторый отчёт, который должен содержать всю информацию по заказу - данные, вводимые при заполнении заказа (см. выше).
Для контроля внутренней работы фирмы необходимо проверять все финансовые затраты и доходы. Для этого также используются отчёты, содержащие месяц и год, за который сделан отчёт, информацию обо всех сотрудниках и их зарплатах, затраты на приобретение деталей в данный период времени и другие затраты. Также отчет должен включать полный доход за месяц.
Для каждого сотрудника соответственно должны также выполняться отчёты, содержащие информацию о выполненной работе и её стоимости, общее начисление за месяц.
2.6 Математические методы в прогнозировании
2.6.1 Формулировка задачи на прогнозирование
Для планирования развития организации часто используют прогнозирование доходов. Поэтому за прогнозируемую величину возьмём рост доходов (чистых). На величину чистой прибыли влияет количество и стоимость заказов, количество всех расходов. Таким образом, необходимо найти как будут изменяться доходы в ближайшем будущем, основываясь на результатах прошедшего периода.
Поиск и анализ математических методов для прогнозирования.
По оценкам ученых, насчитывается свыше 150 различных методов прогнозирования; на практике же в качестве основных используется лишь 15-20. Также существует множество классификаций этих методов, основанных на различных построениях методов, сложности, точности и других параметров. К точным методам относятся, например, экстраполяция, моделирование, метод исторической аналогии, написание сценариев, анализ корреляций и другие.
2.6.2 Экстрополяционные методы прогнозирования
Методы экстраполяции тенденций являются, пожалуй, самыми распространенными и наиболее разработанными среди всей совокупности методов прогнозирования. Использование экстраполяции в прогнозировании имеет в своей основе предположение о том, что рассматриваемый процесс изменения переменной представляет собой сочетание двух составляющих-регулярной и случайной.
Считается, что регулярная составляющая f (a, х) представляет собой гладкую функцию от аргумента (в большинстве случаев - времени), описываемую конечномерным вектором параметров а, которые сохраняют свои значения на периоде упреждения прогноза. Эта составляющая называется также трендом, уровнем, детерминированной основой процесса, тенденцией. Под всеми этими терминами лежит интуитивное представление о какой-то очищенной от помех сущности анализируемого процесса. Интуитивное, потому что для большинства экономических, технических, природных процессов нельзя однозначно отделить тренд от случайной составляющей. Все зависит от того, какую цель преследует это разделение и с какой точностью его осуществлять.
Случайная составляющая n (х) обычно считается некоррелированным случайным процессом с нулевым математическим ожиданием. Ее оценки необходимы для дальнейшего определения точностных характеристик прогноза.
2.6.3 Метод Исторической Аналогии
Метод прогнозирования, основанный на установлении и использовании аналогии объекта прогнозирования с одинаковым по природе объектом, опережающим первый в своем развитии.
2.6.4 Экспертные методы
Методы экспертных оценок в прогнозировании и перспективном планировании научно-технического прогресса применяются в следующих случаях:
а) в условиях отсутствия достаточно представительной и достоверной статистики характеристики объекта (например, лазеры, голографические запоминающие устройства, рациональное использование водных ресурсов на предприятиях);
б) в условиях большой неопределенности среды функционирования объекта (например, прогнозов человеко-машинной системы в космосе или учет взаимовлияния областей науки и техники);
в) при средне - и долгосрочном прогнозировании объектов новых отраслей промышленности, подверженных сильному влиянию новых открытий в фундаментальных науках (например, микробиологическая промышленность, квантовая электроника, атомное машиностроение);
г) в условиях дефицита времени или экстремальных ситуациях.
Экспертная оценка необходима, когда нет надлежащей теоретической основы развития объекта. Степень достоверности экспертизы устанавливается по абсолютной частоте, с которой оценка эксперта в конечном итоге подтверждается последующими событиями.
2.6.5 Метод эвристического прогнозирования (МЭП)
Методом эвристического прогнозирования называется метод получения и специализированной обработки прогнозных оценок объекта путем систематизированного опроса высококвалифицированных специалистов (экспертов) в узкой области науки, техники или производства. Прогнозные экспертные оценки отражают индивидуальное суждение специалиста относительно перспектив развития его области и основаны на мобилизации профессионального опыта и интуиции.
2.6.6 Балансовый метод
С помощью балансового метода реализуется принцип сбалансированности и пропорциональности. Он применяется при разработке прогнозов, планов и программ. Сущность его заключается в увязке потребностей страны в различных видах продукции, материальных, трудовых и финансовых ресурсов с возможностями производства продукции и источниками ресурсов.
Не будем усложнять задачу рассматриванием всех основных методов прогнозирования, а остановимся на экстраполяционном методе, так как он наиболее распространённый и очень точный.
2.6.7 Сбор данных. Описание исходных данных
Любое прогнозирование основывается на данных собранных в какой-либо промежуток времени. От длительности этого времени зависит приближенность прогнозирования к настоящим результатам. Данные, которые необходимо анализировать, зависят от поставленной задачи, от результата прогнозирования.
Для решения описанной выше задачи на прогнозирование необходимо иметь следующие входные данные: количество заказов, стоимость заказов, количество всех расходов.
Алгоритм поиска решения.
В математике и статистике экстраполяция - это продолжение динамического ряда данных по определенным формулам. Она соотносится с понятием "интерполяция" (лат. interpolatio - изменение, подновление), обозначающим нахождение промежуточных значений по ряду логических или статистических данных.
Самый простой вид интерполяции - линейная, которая представляет искомую зависимость в виде ломаной линии. Интерполирующая функция состоит из отрезков прямых, соединяющих точки.
Существуют также кубическая сплайн-интерполяция, полиномиальная, интерполирование полиномом Ньютона и Лагранжа и другие.
Воспользуемся интерполированием полиномом Лагранжа, так как именно его применяют при фиксированном числе узлов, то есть промежутков времени.
Чтобы найти функцию необходимо иметь набор аргументов и набор значений функции в этих точках.
Пусть xi - значение аргумента в момент времени i, yij - значение функции в момент времени i. Тогда полином Лагранжа будет выглядеть следующим образом:
>,
(1)>
Где i и j - номер промежутка времени. Изменяются от 0 до количества используемых в прогнозировании промежутков времени.
Построение и описание модели прогнозирования
Количество доходов зависит от количества общей прибыли, так как количество всех расходов ежемесячно изменяется на малую величину или совсем не изменяется. Чтобы найти общую прибыль надо сложить стоимости всех заказов. Тогда доход будет составлять разность между суммой стоимостей всех заказов и всеми расходами.
За значения функции в полиноме Лагранжа примем суммы стоимостей заказов по каждому периоду. За значения аргумента - номер временного интервала (месяца). Переходя к модели, введём обозначения: yi - суммы стоимостей заказов по каждому периоду; xi - номер временного интервала
Формулу Лагранжа представляет собой сумму произведений значений функции на коэффициент а, где а для экспериментальных точек (узловых) определяется следующим образом: если i=j - то а=1,если i≠j - то а=0
Для любых других:
Таким образом, строится непрерывная функция, значение которой можно узнать в любой даже не узловой точке. Для того, чтобы узнать значение чистой прибыли необходимо от полученного числа отнять количество доходов.
2.7 Выходные данные, графики, прогнозы
В итоге прогнозирования должны получить значения чистых доходов на 3 периода вперёд. Но при этом наиболее точное значение будет для ближайшего периода.
Таким образом, в данной главе произведено проектирования внешнего информационного обеспечения. Выполнено инфологическое и даталогическое проектирование, нормализация данных. Произведён анализ и выбор программного обеспечения для реализации, результатом которого является выбор СУБД Paradox 7 и среды программирования Builder С++. Произведено физическое проектирование. Описана функциональная схема приложения по методологии Питера Чена. Выделены и описаны некоторые основные запросы. Выполнена работа над прогнозированием системы.
3. Реализация БД и функциональной части АИС
3.1 Реализация БД в среде С++ Builder
Опишем основные модули системы. К ним относятся: Работа с клиентами, оформление заказа, заказ комплектующих, услуги и другие служебные модули.
Модуль "Работа с клиентами" предназначен для поиска клиентов по базе данных или поиска заказчика по номеру заказа. Необходим для продуктивной работы фирмы и упрощения работы сотрудников путём подставления имающихся данных в новый заказ. Модуль "Оформление заказа" предназначен непосредственно для сбора данных нового заказа. Модуль "Заказ комплектующих" предназначен для составления списка деталей, которые необходимо заказать и привести на склад. Эта операция проводится каждую неделю по данным отчёта по количеству деталей на складе. Модуль "Услуги" предназначен для просмотра и редактирования услуг, их цен и изменения информации по исполняющим мастерам.
В работе системы учувствуют также множество других модулей и форм.
3.2 Разработка интерфейса приложения
Описание интерфейса всего приложения будет очень громоздко и не имеет смысла, поэтому опишем только 3 основных формы.
Для реализации поиска клиентов сгенерирована форма "Работа с клиентами", представленная на рисунке 7.
Рисунок 6 - форма "Работа с клиентами"
RadioButton1 и RadioButton2 позволяют определить тип поиска. Если необходимо найти клиента, оформившего данный заказ, то надо выбрать "поиск клиента по ID заказа". Если необходимо просмотреть все заказы клиента или найти клиента в БД, чтобы повторно не вводить данные, то надо выбрать "поиск заказов клиента" и ввести необходимые данные.
ComboBox1 (ID заказа), ComboBox2 (ID клиента), ComboBox3 (Фамилия) и ComboBox4 (№ автомобиля) позволяют ввести (найти) данные для поиска.
По нажатию кнопки Button3 (Найти) осуществляется поиск. Если поиск не дал положительных результатов, выводится сообщение "Объект не найден".
В зависимости от выбранной категории поиска результаты будут различны. Если осуществляется поиск по категории "поиск клиента по ID заказа", то выведется только информация о клиенте в поля Edit1 (ID клиента), Edit2 (ФИО клиента), Edit3 (№ автомобиля). Если же поиск осуществляется по категории "поиск заказов клиента", то кроме информации о клиенте выведется также информация о всех его заказах в виде таблицы StringGrid1.
По нажатию кнопки Button1 (Новый заказ клиента), открывается форма "Оформление заказа", оформляется новый заказ на найденного клиента, то есть в форме "Оформление заказа" сразу отображаются все известные данные.
По нажатию кнопки Button2 (Новый заказ), открывается форма "Оформление заказа", оформляется новый заказ, в который все данные вводятся вручную.
Опишем подробно форму "Оформление заказа", представленную на рисунке 8.
Рисунок 7 - форма "Оформление заказа"
При оформлении заказа заполняются только голубенькие поля, серые поля заполняются при редактировании (принятии заказа на выполнение). Поля Edit9 (ID клиента), Edit1 (ID заказа), Edit2 (Стоимость) заполняются после создания нового заказа, т.е. после добавления данных в таблицы. Кнопка Button1 (Принять) добавляет все введённые данные в соответствующие таблицы. В поля Edit3 (Фамилия), Edit4 (Имя), Edit5 (Отчество), Edit6 (№ автомобиля) содержат информацию о клиенте и, если клиент найден в БД, заполняются автоматически.
Выпадающий список ComboBox1 (ID и наименование детали) позволяет найти нужную деталь для замены в списке. Поле Edit7 (Количество) позволяет указать сколько деталей данного типа требуется для замены в данном заказе. При нажатии кнопки Button2 (Добавить) информация о детали выводиться в таблицу StringGrid1. Выпадающий список ComboBox2 (Исполняющий мастер) позволяет выбрать мастера для исполнения, это поле заполняется при редактировании.
Выпадающий список ComboBox3 (ID и наименование услуги) позволяет найти нужную услугу в списке. При нажатии кнопки Button4 (Добавить) информация об услуге выводиться в таблицу StringGrid2. Выпадающий список ComboBox4 (Исполняющий мастер) позволяет выбрать мастера для исполнения. Для каждой услуги выбирается отдельный мастер. Это поле заполняется при редактировании.
Кнопка Button3 (Добавить данные) вносит недостающие данные при редактировании. Для этого необходимо открыть заказ и дописать недостающую информацию.
Для реализации работы с услугами сгенерирована форма "Услуги", представленная на рисунке 9. Опишем её содержимое и принцип работы.
Рисунок 8 - форма "Услуги"
Данная форма содержит таблицу StringGrid1 (Все услуги) для предоставления клиенту полного списка услуг и краткой информации по ним: ID услуги, наименование, стоимость. При запуске формы эта информация выводится автоматически.
Для осуществления поиска в поле Edit4 (Поиск) надо ввести ID услуги, по которой необходимо просмотреть полную информацию. По нажатию кнопки Button1 (Просмотреть) в область GroupBox2 (Информация по услуге) выводится вся известная информация: в поле Edit1 - ID услуги, в поле Edit2 - наименование услуги, в поле Edit3 - стоимость. В таблицу StringGrid2 (Исполняющие мастера) выводится информация по всем мастерам, исполняющие данную услугу: ID мастера, фамилия, имя, отчество мастера.
Таким образом, были описаны 3 формы, наиболее используемые при работе с клиентом.
3.3 Описание реализации модуля прогнозирования
Для сбора сведений по прогнозированию система должна перебрать все заказы за последние 10 месяцев по дате закрытия и записать в соответствующие массивы стоимости заказов: per1 [kol1], per2 [kol2], per3 [kol3], per4 [kol4], per5 [kol5], per6 [kol6], per7 [kol7], per8 [kol8], per9 [kol9], per10 [kol10]. Для каждого периода времени организуется отдельный массив. Все массивы имеют разную размерность, равную количеству заказов в данном периоде. После чего система переходит к выполнению функции прогнозирования:
int i,j; // служебные переменные
int x1=11, x2=12, x3=13; // номера периодов, для которых узнаём (прогнозируем) значение
int raschod=81; // общий расход
int x; // текущая переменная
float f; // значение функции
// суммирование стоимостей по каждому периоду
for (i=0; i<kol1; i++) sum1=sum1+per1 [i] ;
for (i=0; i<kol2; i++) sum2=sum2+per2 [i] ;
for (i=0; i<kol3; i++) sum3=sum3+per3 [i] ;
for (i=0; i<kol4; i++) sum4=sum4+per4 [i] ;
for (i=0; i<kol5; i++) sum5=sum5+per5 [i] ;
for (i=0; i<kol6; i++) sum6=sum6+per6 [i] ;
for (i=0; i<kol7; i++) sum7=sum7+per7 [i] ;
for (i=0; i<kol8; i++) sum8=sum8+per8 [i] ;
for (i=0; i<kol9; i++) sum9=sum9+per9 [i] ;
for (i=0; i<kol10; i++) sum10=sum10+per10 [i] ;
// задание массива, состоящих из сумм (экспериментальные значения функции); n - количество периодов, данные которых известны и используются для программирования float sum [n] ={sum1,sum2,sum3,sum4,sum5,sum6,sum7,sum8,sum9,sum10};
// прогнозирование для периода n+1
x=x1; f=0;
for (i=0; i<n; i++)
for (j=0; j<n; j++)
if (i! = j) f+= (x-a [i]) / (a [i] -a [j]) *sum [i] ;
f=f-raschod;
Edit1->Text=FloatToStr (f);
// прогнозирование для периода n+2
x=x2; f=0;
for (i=0; i<n; i++)
for (j=0; j<n; j++)
if (i! = j) f+= (x-a [i]) / (a [i] -a [j]) *sum [i] ;
f=f-raschod;
Edit2->Text=FloatToStr (f);
// прогнозирование для периода n+3
x=x3; f=0;
for (i=0; i<n; i++)
for (j=0; j<n; j++)
if (i! = j) f+= (x-a [i]) / (a [i] -a [j]) *sum [i] ;
f=f-raschod;
Edit3->Text=FloatToStr (f);
Результат данного прогноза - значения чистого дохода по трём следующим (будущим) периодам.
Отладка и тестирования приложения
Существует несколько методов тестирования:
Тестирование программ методом "чёрного ящика" (Black box testing)
Тестирование программ методом "белого ящика" (White box)
Тестирование ПО методом "серого ящика" (Grey box)
Тестирование не функциональных аспектов программы.
Опишем эти методы вкратце:
Тестирование программы как "белого ящика" и "чёрного ящика"
При тестировании белого ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определенной степени.
При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идет правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе.
3.4 Тестирование нефункциональных параметров программы
Существуют специальные методы для тестирования аспектов программ, не являющихся функциональными, т.е. не относящихся к работоспособности самих программ. Это тестирование:
Тестирование производительности программного обеспечения - посмотреть работоспособность, если программа управляет большим количеством данных или имеет большое число пользователей. Это напрямую относится к понятию масштабируемости приложений.
Тестирование "Юзабилити" - тестирование интерфейса пользователя, его удобности, практичности и лёгкости для освоения обычным пользователем.
Тестирование безопасности программ важно для программ, имеющих дело с конфиденциальными данными для предотвращения использования уязвимостей хакерами.
Тестирование качества интернационализации и локализации программного обеспечения.
При тестировании данного программного продукта использовался метод тестирования нефункциональных параметров "Юзабилити". Система проходила испытания путём проверки работоспособности при различных действиях пользователя. В целом система работает достаточно устойчиво.
Таким образом, в данной главе было описано назначение главных модулей, представлены основные формы - "Работа с клиентами", "Оформление заказа", "Услуги", - с описанием принципа работы. Программно описан модуль прогнозирования. Произведено тестирование полученного программного продукта методом тестирования нефункциональных параметров "Юзабилити".
Заключение
В данной работе проанализирована предметная область организации, для которой разрабатывается информационная система, выявлены основные виды деятельности этой организации, рассмотрена её структура, определён уровень автоматизации на текущий момент. Выявлены проблемы, которые необходимо устранить с помощью автоматизации:
необходимость заполнения заново всех данных клиента, даже если он обращается в данную организацию не первый раз;
ручное заполнение документов подвергает риску ошибок;
большая бумажная волокита;
возможность утери одной или нескольких составляющих документации о заказах;
затруднение поиска нужного;
хранение много лишней макулатуры.
Также описаны автоматизированные бизнес-процессы и их преимущества:
возможность найти клиента из базы, если этот клиент однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчёт общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения
Произведён анализ и выбор программного обеспечения для реализации, результатом которого является выбор CASE-средства - Erwin, СУБД - Paradox 7 и среды программирования - Builder С++.
Разработан проект информационной системы с учётом всех стадий проектирования: инфологическое и даталогическое проектирование, нормализация данных, физическое проектирование.
Разработан интерфейс приложения, описаны некоторые основные запросы и главные формы - "Работа с клиентами", "Оформление заказа", "Услуги".
Выполнена работа над прогнозированием системы по параметру "Рост дохода".
Выполнено тестирование системы методом тестирования нефункциональных параметров "Юзабилити".
Литература
Иванова Г.С. Объектно-ориентированное программирование (Borland C++) - М.: Издательство МГТУ им. Н.Э. Баумана, 2000. - 323с.
Архангельский А.Я. Компоненты C++Builder. Справочное и методическое пособие. - М.: ООО "Бином-Пресс", 2009. - 960 с.
Лабораторный практикум по вычислительной математике: Учеб. пособие / Ю.М. Заболотнов. Самар. гос. аэрокосм. ун-т. Самара, 2005.