1.2 Общее описание
1.2.1. Перспективы продукта
Создаваемая система будет способна решать задачи оптимального размещения и учёта товаров на складе. Она позволяет проводить оптимизацию размещения единиц хранения с учётом топологии склада; используется оптимизационный алгоритм размещения единиц хранения и пополнения зон отбора.
1.2.1.1. Концепции операций
Функции, реализуемые системой:
аутентификация пользователя;
ведение справочников (пользователи, единицы измерения, номенклатура, адреса, поставщики, виды операций, материально-ответственные лица);
ведение оперативной информации (операции на складах, размещение единиц хранения, комплектация заказа, результаты инвентаризации);
поиск оптимального места хранения для принятого товара;
формирование отчётов (наличие товара на складе, перемещение заданного товара по складу, приём товара на склад, отгрузка товара со склада; товары готовые к отгрузке, результат инвентаризации и коррекции товарных запасов) в экранной и документальных формах;
выдача справок по размещению заданного товара и по его остаткам на текущий момент.
1.2.1.2. Концепции пользовательского интерфейса
Объектом автоматизации является малая компания сферы розничной торговли сотовыми телефонами и аксессуарами. Данные типы компаний обладают рядом характеристик, определяющих подходы к реализации и использованию в их деятельности корпоративных информационных систем:
жестко лимитированные финансовые возможности;
высокая интенсивность работы сотрудников, “плотность” работ;
проблема “текучести кадров”;
присутствие выделенного звена стратегического управления (высшего менеджмента)
жесткая высоко-конкурентная внешняя среда с высокой динамикой клиентских предпочтений, отсутствие возможности занятие специализированной ниши в виду молодости обоих направлений;
отсутствие жесткого деления на отделы/подразделения. В лучшем случае – сеть офисов или представительств.
Целью внедрения автоматизированной системы является: повышение конкурентоспособности компании и увеличение прибыли, так как правильно построенные отношения, основанные на персональном подходе к каждому клиенту, позволяют привлекать новых клиентов и помогают удержать старых.
Целью разработки системы автоматизации управления взаимоотношениями с клиентами является: создание программного комплекса, обеспечивающего техническую реализацию выбранной стратегии, её поддержание и развитие в рамках чётко определённых приоритетов компании. Также одной из основных целей является автоматизация документооборота и товародвижения между поставщиками и головным складом, а также между головным складом и удаленным филиалом.
Задачи, решаемые разрабатываемой системой:
централизация информации о контрагентах, истории сделок, контактов, документы;
управление контактами;
управление работой с клиентами в процессе проектной деятельности;
снижение нагрузки на персонал ответственных за взаимодействие с клиентами с ростом клиентской базы, снижение издержек на непроизводящий персонал;
организация единого банка знаний компании.
Моделирование взаимодействия пользователя с системой представлено на рисунке 1.2.
Рисунок 1.2 – Диаграмма переходов и состояний для информационной системы
Для успешного внедрения и эксплуатации создаваемая система автоматизации управления взаимоотношениями удаленным филиалом, головным складом, поставщиками и покупателями должна обладать следующими свойствами:
максимальная простота внесения данных в систему, т.к. эта работа часто производится сотрудниками “на лету” – во время взаимодействия с клиентом;
дружественность пользователю;
надёжность;
расширяемость;
умеренные системные требования, в частности – к аппаратному обеспечению и квалификации персонала;
документированность.
В программном продукте должны быть реализованы следующие разделы:
раздел “Приемка товара” от сторонних поставщиков;
раздел “Перемещение” в удаленный филиал необходимого количества товара;
раздел “Документы”: приходные, расходные, перемещения в филиал;
раздел “Справочник товаров”;
раздел “Справочник поставщиков”;
раздел “Остатки товара”;
раздел “Продажа товара”.
Основными функциями системы должны являться:
система приемки товара от сторонних поставщиков и от головного склада;
продажа товара в филиале;
создание реестра приходных и расходных документов, а также перемещений товара и чеков продаж;
продажа товара клиентам.
1.2.1.3 Аппаратные интерфейсы
Для реализации программного продукта особых аппаратных средств не требуется.
1.2.1.4 Программные интерфейсы
При использовании программного продукта пользователи получают данные как в виде табличных форм для заполнения и просмотра, так и в виде таблиц для печати.
1.2.1.5 Коммуникационные интерфейсы
Приложение передает и получает данные из БД, загруженной в SQL Server, отравляя соответствующие запросы и команды.
1.2.1.6 Ограничения по памяти
Для ПО АИС малого предприятия по технологии потребуется не более 16 Мбайт оперативной памяти и 20 Мбайт вспомогательного запоминающего устройства (см. план теста; ссылка на тест будет приложена).
1.2.1.7 Операции
Основными функциями системы должны являться:
система приемки товара от сторонних поставщиков и от головного склада;
продажа товара в филиале;
создание реестра приходных и расходных документов, а также перемещений товара и чеков продаж;
продажа товара клиентам.
1.2.1.8 Требования по адаптации
Для корректной работы программного продукта требуется операционная система Windows 7. Свободное дисковое пространство в размере не менее 50 Mb для хранения данных.
1.2.2 Функции продукта
Разработана модель функциональности системы, которая реализуется с помощью диаграммы вариантов использования, представленной на рисунке1.3.
Рисунок 1.3 – Функции программы
1.1.2.1 Концепция оформления заказа на реализацию товара в пользовательском интерфейсе
Заполняет электронный документ (форму) «Реализация», на основе тех данных, которые дал покупатель в письменной форме.
1.1.2.2 Концепция "приход товара" в пользовательском интерфейсе
Пользователь заполняет документ (накладную), на основе тех данных, которые предоставил поставщик, в виде товарной накладной.
1.2.3. Пользовательские характеристики
Приложение «AnalyzeShop» предназначено для пользователя любого уровня подготовки. Пользователь, ознакомленный с эксплуатационной документацией по данной программе, может активировать режим полной функциональности, введя пароль, при котором становятся активными все компоненты интерфейса (см.рисунок 1.4).
Рисунок 1.4 – Субъекты приложения
Требования для установления субъектов в приложении:
Для знакомства со строительными материалами, услугами клиента использует форму клиента. При этом также приводится цена товара.
Клиент выбирает товар, с которым он хочет познакомиться, возможно, с намерением купить. Цена для каждого товара может быть подсчитана по требованию пользователя.
Клиент может выбирать вариант заказа товара либо попросить, чтобы продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п. прежде чем заказ будет фактически размещен.
Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счет-фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек).
После ввода заказа клиента в систему продавец отправляет на склад электронное требование, содержащее детали заказанного товара.
Детали сделки, включая номер заказа, номер счета клиента, отправляются по электронной почте клиенту, так что заказчик может проверить состояние заказа.
Склад получает счет-фактуру от продавца и отгружает товар клиенту.
1.2.4 Ограничения
Приложение будет корректно работать на ПК с Windows XP/Vista/7, установленным SQL Server 2008 R2 версии 661 или ниже и процессором с тактовой частотой не ниже 1,6 ГГерц. При наличии другой версии SQL Server базу данных необходимо будет сконфигурировать заново из файла «edm_model.edmx.sql».
1.2.5 Предположения и зависимости
При разработке автоматизированной системы анализа деятельности склада следует помнить, что для каждого заказа комплектующих должен указываться только один поставщик.
1.2.6 Распределение требований
Основные требования (упомянутые в разделе 1.3) должны быть реализованы в этой версии АИС малого предприятия по технологии ERP-System. Желательные требования должны быть по возможности осуществлены в этой версии, но не обязательны для разработчиков. Желательно, чтобы часть из них присутствовала в будущей версии. Необязательные требования будут добавлены по желанию разработчиков.
1.3. Детальные требования
1.3.1. Требования к внешнему интерфейсу
Центральным звеном при проектировании GUI интерфейса выступает пользователь. Это замечание послужило основанием для ряда приводимых ниже рекомендаций разработчикам ПО. Руководящие принципы опубликованы производителями GUI интерфейсов [7]. Руководящие принципы служат разработчикам основанием для построения GUI интерфейса. При принятии любых проектных решений в отношении GUI интерфейса они должны использоваться разработчиками на подсознательном уровне. Некоторые из этих руководящих принципов выглядят как хорошо известные старые истины, другие основаны на современной GUI технологии.
“Контроль — на стороне пользователя” — вот главнейший принцип построения GUI интерфейса. Лучше было бы назвать этот принцип пользовательским восприятием контроля. Основной смысл этого принципа заключается в том, что пользователь инициирует действия, и если в результате этого контроль переходит к программе, то пользователь получает необходимую обратную связь (в виде курсора в форме песочных часов, индикатора ожидания или аналогичным способом).
Рисунок 1.4 демонстрирует типичный поток управления в человеко–машинном взаимодействии. Событие, инициированное пользователем (выбор пункта меню, щелчок мышью, перемещение указателя мыши по экрану и т.д.), может привести к открытию окна GUI интерфейса или вызову программы — как правило, программы на языках типа 4GL или SQL в рамках приложения ИС. Программа временно перехватывает контроль у пользователя.
Процесс выполнения программы имеет возможность вернуть управление назад тому же или другому окну. В другом случае он может вызвать другой модуль на языках типа 4GL или SQL или вызвать внешнюю процедуру. В некоторых случаях программа может кое что делать для пользователя. Это возможно, к примеру, если программе требуется выполнить вычисления, которые обычно связаны с явным пользовательским событием, или если программа перемещает указатель на другое поле экрана, а для события перемещения с исходного поля предусмотрен обработчик события выхода, связанный с ним.
Согласованность несомненно является вторым основным принципом разработки качественного интерфейса. Фактически согласованность означает соблюдение стандартов и следование некоторым общепринятым правилам работы с GUI интерфейсом. Согласованность может рассматриваться, по меньшей мере, в двух аспектах. Соответствие стандартам поставщика GUI интерфейса. Соответствие стандартам в области именования, программирования и другим, разработанным внутри организации стандартам, которые связаны с GUI интерфейсом. Оба аспекта одинаково важны, и второй (на который оказывают влияние разработчики) не должен противоречить первому. Если приложение разрабатывается для Windows, то следует обеспечить “впечатление и ощущение”, свойственные работе в системе Windows.
Разработчик GUI интерфейса не должен слишком увлекаться творчеством и предлагать необычные новшества. Это может плохо сказаться на уверенности и умении пользователей. Пользователям следует представлять знакомую среду, поведение которой предсказуемо. Можно представить, какова была бы реакция автомобилистов, если бы производитель автомобилей выпустил на рынок новую машину, у которой поменяли местами педали скорости и тормоза.
Не следует также недооценивать соответствие внутренним стандартам в области именования, программирования, аббревиатур и т.п. Сюда относятся именование и программирование меню, командных кнопок, полей экранов, также стандарты по расположению объектов на экране и последовательному использованию элементов GUI интерфейса в рамках всех приложений, разрабатываемых собственными силами.
Рисунок 1.4 - Поток управления GUI программы
Индивидуализация и настройка — два взаимосвязанных принципа разработки GUI интерфейса. Индивидуализация GUI интерфейса — это просто его настройка под персональные нужды, в то время как настройка —административная задача приспособления ПО к требованиям различных групп пользователей.
Примером индивидуализации является изменение пользователем порядка и размеров колонки в программе просмотра строк (так называемые сетки — grid) с последующим сохранением этих изменений как его личных предпочтений. При обращении к этой же программе в будущем данные предпочтения учитываются.
Примером настройки является различие в функционировании программы по отношению к опытным пользователям и пользователям новичкам. Например, пользователю новичку программа может предложить явную помощь и дополнительные предупреждающие сообщения, указывающие на потенциальную опасность некоторых событий, инициируемых пользователем.
Во многих случаях различия между индивидуализацией и настройкой весьма размыты и малозаметны. Изменение пунктов меню, создание новых меню и т.п. попадают в обе категории. Если они предназначены для индивидуального использования —это индивидуализация. Если они осуществляются системным администратором в интересах всего коллектива пользователей — это настройка.