Автоматизация движения готовой продукции на складе ООО «Амазон-колорит»

Автоматизация движения готовой продукции на складе ООО «Амазон-колорит»

Введение

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

В настоящее время данная тема является очень актуальной, так как ручной учет занимает очень много времени. Автоматизированный учет позволяет сократить это время в разы.

Для достижения цели были поставлены следующие задачи:

— изучить и проанализировать предметную область;

— ознакомиться с принципами учета движения готовой продукции на складе;

— проанализировать и спроектировать логическую и физическую модель данных;

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

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

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

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

В разделе «Программа тестирования и методика испытаний» идет речь о цели, об объекте испытаний, методах испытаний, а так же о протоколе испытаний.

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

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

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

1. Постановка задачи

программа готовая продукция учет

1.1 Описание предметной области

Склад готовой продукции — место хранения производимой продукции предприятия. На складе ведется учет прихода готовой продукции, ее расхода и прихода из цеха производства.

Задачи складского учета состоят в следующем:

— учет количества производимой продукции;

— учет прихода новой продукции;

— учет отгрузки готовой продукции потребителю;

1.2 Входная информация Для того, чтобы вести учет поступления и списания готовой продукции, нужны исходящие данные. Они поступают в виде личных данных. Входной информацией является:

— информация о готовой продукции;

— информация о единицах измерения;

— информация об материально-ответственных лицах;

— информация о покупателях;

— информация о цехах;

— информация о складах;

— информация о приходе готовой продукции;

— информация о расходе готовой продукции;

— информация об остатках готовой продукции на складе;

Эти данные служат исходной информацией в учете готовой продукции на складе.

1.3 Выходная информация Выходные данные формируются в результате обработки входящей и постоянной информации. При работе с программным средством «Автоматизация движения готовой продукции на складе ООО «Амазон-Колорит» существует возможность создания следующих отчетов:

— отчет «Оборотная ведомость»;

— отчет «Состояние складов»;

— отчет «Приход»;

— отчет «Расход»;

Отчеты можно просмотреть и вывести на печать.

1.4 Функциональное моделирование Основное понятие IDEF0-методологии — это понятие «модель». IDEF0-модель — это искусственный объект, представляющий собой виртуальный образ системы и ее компонентов, в виде функциональной структуры объекта (совокупность диаграмм), отображающих производимые им действия и связи между этими действиями. Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой ИС. IDEFO-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга.

Система — с точки зрения системологии, это совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей (люди, информация, программное обеспечение, оборудование, изделия, сырье или энергия (энергоносители)). Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.

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

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

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

Согласно методологии IDEF0 создание иерархической модели производится на основе использования метода декомпозиции, заключающегося в разделении крупных составных структур на более мелкие: метасистемы — на системы, системы — на подсистемы, и затем определяются элементы систем. Декомпозиция — это процесс разделение объекта моделирования на его структурные части — блоки и стрелки, с целью создания диаграммы, детализирующей блок верхней доминантности и связанные с ним стрелки. Диаграмма — часть модели, описывающая декомпозицию блока.

К важным понятиям IDEF0 является термин бизнес-правила. Модель деловых процессов позволяет выявить и точно определить бизнес-правила, используемые в деятельности предприятия. Если при разработке ИС не будут учтены существующие на предприятия бизнес-правила, доказавшие свою жизнеспособность и эффективность, то такая система будет функционировать неадекватно. Очень часто бизнес-правила на предприятии не записаны в инструкциях или стандартах предприятия: они как бы есть, но и их как бы нет. В результате попытки реинжиниринга деятельности предприятия или подразделения могут закончиться неудачей только лишь потому, что предлагаемые изменения противоречат сложившимися бизнес-правилами.

Основное требование системного подхода при изучении какого-либо объекта — рассмотрение системы как единого целого, т. е. определенную одним функциональным блоком (черным ящиком) со своими входами и выходами. Контекст системы — описание наиболее абстрактного уровня системы в целом и окружающей среды. Контекст модели очерчивает границы моделируемого процесса и описывает его взаимосвязи с внешней средой и другими процессами, определяя модель процесс как часть целого. В контекст IDEFO-модели входит определение единственного субъекта моделирования, его полное, точное и адекватное описание, называемое целью модели, созданное с одной точки зрения на модель. Согласно IDEF0 контекст системы представляется контекстной диаграммой.

Субъект — это сама система, заданная в определенных границах. Субъект определяет, что включить в модель, а что исключить из нее. Согласно IDEF0 система, имеющая границы является областью моделирования.

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

Родительский блок (Parent Box) — функциональный блок, — подлежащий декомпозиции. По отношению к дочерней диаграмме — блок-предок.

Родительская диаграмма (Parent Diagram) — диаграмма, содержащая один или более родительских блоков.

Дочерняя диаграмма (Child diagram) — диаграмма второго уровня, содержащая функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы.

Дочерний блок (Child Box) — любой функциональный блок на дочерней диаграмме. Диаграмма декомпозиции — полученный при декомпозиции родительских блоков набор тщательно взаимосогласованных описаний. Диаграмма с потоками — диаграмма, описывающая все, связанное с декомпозируемым блоком и его стрелками. При декомпозиции интерфейсные стрелки, присоединенные к блоку, через ICOM коды переносятся на диаграмму-потомок. Таким образом, родительский блок и его интерфейсные дуги определяют контекст для диаграммы-потомка. Глоссарий. Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных стрелок стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей стрелки «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т. д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Пример построения диаграммы IDEF0, в соответствии с рисунком 1.1.

Рисунок 1.1 — Диаграмма IDEF0

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

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

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

Для разработки форм приложения применялись CASE-системы, в частности Erwin 4.0. ERwin имеет два уровня представления модели — логический и физический. На логическом уровне данные не связаны с конкретной системой управления базами данных, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных — это по существу отображение системного каталога, который зависит от конкретной реализации системы управления базами данных.

Пример построения логической модели, в соответствии с приложением Б «Информационная модель»

1.6 Разработка структуры базы данных На основании поставленной задачи: разработать программное средство «Автоматизация движения готовой продукции на складе ООО «Амазон-Колорит», создал базу данных, состоящую из 12 таблиц, содержащих необходимые данные для работы программы.

Таблицы содержит следующие поля:

а) таблица 1 «ceha»:

1) Id_ceha (integer);

2) Naim (varchar (50));

3) Glava (varchar (50)).

б) таблица 2 «ed_izm»:

1) Id_ed_izm (integer);

2) Ed_izm (varchar (50)).

в) таблица 3 «got_prod»:

1) Id_gp (integer);

2) Naim_gp (varchar (50));

3) Id_ed_izm (integer);

4) Ed_izm (varchar (50));

г) таблица 4 «mol»:

1) Id_mol (integer);

2) Fio (varchar (50));

3) Adres (varchar (50));

4) Telefon (varchar (50)).

д) таблица 5 «pokup»:

1) UNP_pokup (integer);

2) Naim_pokup (varchar (50));

3) Adres (varchar (50));

4) Telefon (varchar (50)).

е) таблица 6 «sklad»:

1) Id_sklad (integer);

2) Naim_sklad (varchar (50));

3) Id_mol (integer).

ж) таблица 7 «prihod»:

1) Id_prihoda (integer);

2) Data_prihoda (date);

3) Id_sklada (integer);

4) Id_ceha (integer).

з) таблица 8 «rashod»:

1) Id_rashoda (integer);

2) Data (date);

3) UNP_pokup (integer);

4) Id_sklada (integer).

и) таблица 9 «ostatki»:

1) Id_ost (integer);

2) Id_sklada (integer).

к) таблица 10 «gp_ost»:

1) Id_gp_ost (integer);

2) Id_ost (integer);

3) Id_gp (integer);

4) Kolvo (integer);

5) Cena (integer);

6) NDS (integer).

л) таблица 11 «gp_p»:

1) Id_gp_p (integer)

2) Id_prihoda (integer);

3) Id_gp (integer);

4) Data (date);

5) Kolvo (integer);

6) Id_sklad (integer);

7) Cena (integer);

8) NDS (integer).

м) таблица 12 «gp_r»:

1) Id_gp_r (integer);

2) Id_rashoda (integer);

3) Id_gp (integer);

4) Data (date);

5) Id_sklad (integer);

6) Kolvo (integer);

7) Cena (integer);

8) NDS (integer).

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

2. Вычислительная система

2.1 Основные характеристики выбранного персонального компьютера Для нормальной работы приложения необходимы следующие минимальные требования к аппаратным и программным средствам:

Для рабочих станций частота процессора не ниже 500 мегагерц, оперативная память — не ниже 64 мегабайт, свободного места на жестком диске не ниже 20 мегабайт, операционная система Windows 2000/XP, Vista, 7.

2.2 Характеристика программных средств Персональная электронно-вычислительная машина должна быть обеспечена:

— операционной системой Microsoft Windows 95/98/2000/XP и выше;

— системой управления базами данных Microsoft Access.

Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы также не предъявляется.

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

Версия Windows^® XP Professional, операционной системы Windows, сочетает в себе преимущества Windows 2000 Professional (например, средства безопасности, управляемость и надежность) с лучшими качествами Windows 98 и Windows ME (поддержка Plug and Play, простой пользовательский интерфейс и передовые службы поддержки). Это делает Windows^® XP Professional наиболее подходящей операционной системой для настольных компьютеров, применяемых в корпоративной среде. Независимо от того, где устанавливается Windows XP Professional — на одном компьютере или в масштабе локальной сети — эта система повышает вычислительные возможности предприятия, одновременно сокращая совокупную стоимость программного обеспечения всех настольных компьютеров.

Ядро Windows: в основе системы Windows XP Professional лежит проверенный код Windows NT^® и Windows 2000, характеризуемый 32-разрядной вычислительной архитектурой и полностью защищенной моделью памяти. Операционная Windows XP Professional обеспечивает надежную вычислительную среду, отвечающую потребностям всех бизнес-пользователей.

Усовершенствованные средства проверки драйверов устройств: средство проверки драйверов устройств в операционной системе Windows XP Professional, созданное на основе аналогичного средства системы Windows 2000, обеспечивает еще более тщательное испытание драйверов. Драйверы устройств, прошедшие эти испытания, являются наиболее надежными в работе, что обеспечивает максимальную стабильность системы.

Существенное сокращение числа перезагрузок: Устранена большая часть конфликтных ситуаций, при которых пользователи Windows NT 4.0 и Windows 95/98/ME были вынуждены перезагружать свои компьютеры. Кроме того, во многих случаях теперь не требуется выполнять перезагрузку после установки программного обеспечения. В результате этих действий значительно увеличивается время бесперебойной работы системы.

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

Защита файлов Windows: предохраняет основные системные файлы от перезаписи при установке приложений. Если произошла перезапись файла, правильная версия будет восстановлена благодаря защите Windows. Защищая системные файлы, операционная система Windows XP Professional предотвращает наиболее типичные системные неполадки, распространенные в предыдущих версиях Windows.

Программа установки Windows: системная служба, позволяющая корректно устанавливать, настраивать, отслеживать, обновлять и удалять программное обеспечение. Минимизируется время вынужденного простоя и повышается стабильность системы.

Усовершенствованные методы ограничения программ: предоставляет администраторам механизм для идентификации программного обеспечения, которое используется в данной вычислительной среде, и для контроля его работы. Это средство применяется для предотвращения запуска вирусов и «троянских» программ, а также для блокировки программного обеспечения. Способствует повышению целостности и управляемости системы и, в конечном счете, снижению совокупной стоимости всех персональных компьютеров.

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

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

Шифрованная файловая система (EFS) с мультипользовательской поддержкой: все файлы шифруются ключом, генерируемым случайным образом. Процессы шифрования и дешифрования прозрачны для пользователя. В операционной Windows XP Professional файловая система EFS позволяет иметь доступ к зашифрованному документу сразу нескольким пользователям. Высший уровень защиты от хакерских атак и несанкционированного доступа к данным.

IP-безопасность (IPSec): позволяет защитить данные, передаваемые по сети. IP-безо-пасность играет важную роль в обеспечении безопасности виртуальных частных сетей (VPN), обеспечивающих возможность безопасной передачи данных через Интернет. ИТ-администраторы смогут легко и быстро создавать безопасные виртуальные частные сети.

2.2.2 Система программирования, система управления базами данных В качесты системы программирования был выбран Borland C++Builder 6.

Borland C++Builder 6 — очередная версия системы объектно-ориентированного программирования для 32-разрядных операционных систем Microsoft Windows. Интегрированная среда системы (Integrated Development Environment, IDE) обеспечивает продуктивность многократного использования визуальных компонентов в сочетании с усовершенствованными инструментами и разномасштабными средствами доступа к базам данных. Основное предназначение IDE — радикально ускорить производственный цикл разработки сложнейших программных проектов для различных областей применения.

Стандарты пользовательских интерфейсов меняются и развиваются так же быстро, как и операционные системы. Открытость среды IDE позволяет настраивать ее с учетом наиболее модных тенденций в области графических интерфейсов. Разработчик имеет перед глазами хороший образец того, что можно сделать в смысле построения пользовательского интерфейса. На самом деле сама среда IDE создана с помощью C++Builder, поэтому все, что вы видите на экране, вы сможете сделать сами. Визуальный интерфейс сочетает в себе простоту использования для новичка и богатство возможностей для профессионала.

Среди множества нововведений следует особо отметить эффективные средства для поддержки web-служб и разработки переносимых (cross-platform) проектов. Технологии DataSnap, WebServices и WebSnap дают возможность быстро и легко создавать и интегрировать коммерческие сетевые приложения (как персональные, так и коллективные). Клиентский и серверный модули распределенного приложения обмениваются XMLили WSDL-документами в рамках транспортных протоколов TCP/IP, HTTP, SOAP. Библиотека компонентов CLX обеспечивает переносимость исполняемого кода между платформами Windows и Linux. CLX-приложения совместимы на уровне языка C++ с программными продуктами, которые корпорация Borland планирует выпускать для операционной системы Linux.

Система C++Builder может быть использована везде, где требуется дополнить существующие приложения (как прикладные, так и системные) расширенным стандартом языка C++, повысить быстродействие и надежность программ, придать пользовательскому интерфейсу качество профессионального уровня.

В качестве системы управления базами данных для учета движения готовой продукции была выбрана технология Microsoft Access 2010.

Microsoft Office Access или просто Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Корпорация Microsoft для построения полноценных клиент-серверных приложений на базе MS Access рекомендует использовать в качестве движка базы данных СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

Основные компоненты MS Access:

— построитель таблиц;

— построитель экранных форм;

— построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

— построитель отчётов, выводимых на печать.

3. Описание программы

3.1 Описание компонентов Таблица 3.1.1 — Компоненты формы «Form1»

Таблица 3.1.2 — Компоненты формы «Form2»

Таблица 3.1.3 — Компоненты формы «Form3»

Таблица 3.1.4 — Компоненты формы «Form4»

Таблица 3.1.5 — Компоненты формы «Form5»

Таблица 3.1.6 — Компоненты формы «Form6»

Таблица 3.1.7 — Компоненты формы «Form7»

Таблица 3.1.9 — Компоненты формы «Form9»

Таблица 3.1.10 — Компоненты формы «Form10»

Таблица 3.1.11 — Компоненты формы «Form11»

Таблица 3.1.12 — Компоненты формы «Form12»

Таблица 3.1.13 — Компоненты формы «Form13»

Таблица 3.1.14 — Компоненты формы «Form14»

Таблица 3.1.15 — Компоненты формы «Form15»

Таблица 3.1.16 — Компоненты формы «Form16»

Таблица 3.1.17 — Компоненты формы «Form17»

Таблица 3.1.18 — Компоненты формы «Form18»

Таблица 3.1.19 — Компоненты формы «Form19»

Таблица 3.1.21 — Компоненты формы «Form21»

Таблица 3.1.22 — Компоненты формы «Form22»

Таблица 3.1.24 — Компоненты формы «Form24»

Таблица 3.1.25 — Компоненты формы «Form25»

Таблица 3.1.26 — Компоненты формы «Form26»

Таблица 3.1.27 — Компоненты формы «Form27»

Таблица 3.1.28 — Компоненты формы «Form28»

Таблица 3.1.29 — Компоненты формы «Form29»

Таблица 3.1.30 — Компоненты формы «Form30»

Таблица 3.1.31 — Компоненты формы «Form31»

3.2 Интерфейс программы Применяемые сегодня методы разработки проектов зачастую не считаются с необходимостью разработки интерфейса. Это упущение может быть следствием того, что специалисты по разработке интерфейсов привлекаются к проекту слишком поздно, когда возможности улучшения качества взаимодействия между пользователем и продуктом большей частью уже потеряны. Интерфейсом удобнее всего заниматься именно на начальных стадиях разработки. И если специалисты по интерфейсам привлекаются уже после того, как программное обеспечение спроектировано и определены его инструменты или когда разработка программы уже почти завершена, то их рекомендации могут потребовать переделки всей выполненной работы, что, естественно, является неприемлемым. Когда бюджет проекта уже исчерпан и рабочий план почти завершен, перспектива отказа от большей части или даже всего дизайна и готового кода, конечно, не может вызвать энтузиазма у менеджеров проекта. Так что даже в такой современной книге по управлению проектами, как «UML Toolkit» (Eriksson and Magnus, 1998), не говорится о необходимости рассматривать интерфейс уже на стадии анализа требований к проекту, которую авторы обозначают как первую фазу его разработки. Однако в действительности разработка интерфейса не должна откладываться до стадии технической реализации, которая в плане Эриксона и Магнуса является третьей фазой. Определив задачу, для которой продукт предназначен, сначала спроектируйте интерфейс, после чего приступайте к его реализации. Это повторяющийся процесс. Определение задачи будет меняться во время разработки интерфейса. Поэтому весь процесс разработки продукта будет проходить в соответствии с изменениями в задаче продукта и его интерфейсе. Здесь необходимо стремиться к максимальной гибкости. На первом этапе разработки следует определить, что именно должен сделать пользователь для получения того или иного результата и как система должна отвечать на каждое его действие.

Пользователи не задумываются над тем, как устроена машина, пока она справляется со своими задачами. При этом не имеет значения, какой именно процессор используется и является ли язык программирования объектно-ориентированным, многопоточным или, быть может, называется какими-то другими умными словами. Для пользователей важнее всего удобство и результаты. Но все, что они видят — это интерфейс. Другими словами, с точки зрения потребителя именно интерфейс является конечным продуктом.

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

— большей продуктивности работы пользователя;

— большему удобству для пользователя;

— большей ценности в глазах покупателя;

— уменьшению расходов на поддержку покупателей;

— ускорению и упрощению процесса внедрения;

— преимуществу перед конкурентами на рынке;

— лояльности к данной марке;

— упрощению инструкций и онлайновой помощи;

— более безопасным продуктам.

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

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

Специалисты по разработке интерфейсов работают в области, в которой неправильные решения могут вызвать физические поражения и способствовать психологическим расстройствам. Например, если интерфейс создает необходимость слишком часто нажимать на клавиши или кнопку мыши, это может привести к возникновению или обострению хронического стрессового нарушения (repetitive stress injuries). Плохой интерфейс может вызывать психологические расстройства. Таким образом, требуется создание основы для установления юридических норм защиты добросовестных специалистов. Другой необходимостью является установление определенных профессиональных стандартов (речь идет не о стандартах разработки интерфейсов). Меры, упомянутые в этой книге, а также те, которые будут разработаны в будущем, могут помочь установить количественные, объективные нормы. Например, инженер-строитель должна показать, что она спроектировала мост, который отвечает установленным стандартам, в соответствии с которыми этот мост должен выдерживать нагрузку, скажем, в два раза превышающую минимально возможный уровень. Выбросы из автомобиля должны содержать не более 0,2% CO для того, чтобы этот автомобиль мог быть сертифицирован. Аналогичным образом, мы могли бы установить, что интерфейс текстового процессора не может быть принят, если, скажем, его общая информационно-теоретическая эффективность меньше 0,7 или если общая символьная производительность является меньше 0,8, а отдельные элементы имеют эффективность меньше 0,5.

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

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

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

В бизнесе разработки интерфейсов давно существует миф о том, что «расширение функциональности и сохранение простоты использования не могут быть совмещены в одном интерфейсе». Действительно, добавление множества специальных, созданных именно для данного случая сервисов, уменьшает простоту использования. Но как раз это является плохой разработкой. Часто, но не всегда, возможно увеличить функциональность, не увеличивая степень сложности интерфейса. Добавление нового сервиса, как правило, может быть сделано таким образом, что это не прибавит сложности в интерфейсе (здесь следует отметить разницу между сложностью интерфейса и сложностью задачи). Если добавляемая функция позволяет объединить в единое целое разрозненные элементы интерфейса, то такой интерфейс может стать проще.

Одним из способов сохранить простоту заключается в сокращении объема предъявляемой информации до того минимума, который необходим для адекватного взаимодействия. Это действительно так, за исключением того, что слово «адекватного» следует заменить словом «нормального». Однако в этой компании ошибаются, когда утверждают: «Например, не используйте словесных описаний командных имен или сообщений». Здесь возникает вопрос: что же можно считать минимумом для нормального взаимодействия? В большинстве современных интерфейсов акцент делается на краткость в ущерб ясности. Почему мы должны заниматься расшифровкой непонятного названия «Список» в выпадающем меню в текстовом процессоре, когда можно было бы использовать более понятное «Создать указатель или оглавление»? (Необходимо учесть, что выпадающее меню не занимает места в документе, поскольку оно исчезает сразу же, как только вы уводите от него курсор или выбираете какую-то из опций). Не следует путать простой внешний вид экрана с простотой использования интерфейса.

Что касается данного программного средства, то его интерфейс отвечает следующим требованиям:

— понятность для пользователей различной степени квалификации;

— большей продуктивности работы пользователя;

— большему удобству для пользователя.

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

Рисунок 3.1 — Главное окно

4 Программа тестирования и методика испытаний

4.1 Цель и объект проведения испытаний

Объектом испытаний является программное средство «Учет движения готовой продукции на складе».

Целью испытаний является определение работоспособности программного средства «Автоматизация движения готовой продукции на складе ООО «Амазон-Колорит».

4.2 Порядок проведения испытаний

Для проведения испытаний наличие на персональной электронной вычислительной машины операционной системы не ниже Windows XP, манипулятора типа «Мышь», клавиатуры, видеоадаптера, установленной среды программирования Borland C++ Builder 6, система управления базами данных Microsoft Access.

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

4.3 Методы испытаний

Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

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

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

4.4 Протокол испытаний

Приступил к тестированию программного средства «Автоматизация движения готовой продукции на складе ООО «Амазон-Колорит».

Тест прихода продукции из цеха на склад представлен в таблице 4.4.1. Ожидаемый и полученный результаты теста представлены в таблице 4.4.2.

Таблица 4.4.1 — Тест прихода продукции на склад

Таблица 4.4.2 — Ожидаемый и полученный результат при тестировании и возможности прихода из цеха на склад

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

Таблица 4.4.3 — Тест заполнения расхода готовой продукции