Система управления оптовой электронной коммерцией. Куба

Резюме

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

оптово-продукт-продажа-система

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

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

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

Ключевые слова

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

Аннотация

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

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

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

Ключевые слова

Электронная коммерция, система оптовой торговли

Введение.

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

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

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

Существующие системы электронной торговли

Существует широкий спектр платформ, разработанных на основе различных технологий для ведения электронной торговли. Чтобы упомянуть несколько, мы можем перечислить Gesticom B2B, TornadoStore ™, AB-Shop 3. Все они отличаются простотой использования и привлекательны для создания любого типа виртуального магазина. Некоторые из этих платформ даже бесплатны и имеют открытый исходный код. Однако ни они, ни поддерживающие их системы инвентаризации не применимы на Кубе.

Причины, исключающие использование или повторное использование этих систем:

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

Процесс выставления счетов, выполняемый открытыми системами, отличается от описанного для страны.

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

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

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

Идея создания новой платформы также поддерживается использованием сервис-ориентированной архитектуры, которая обеспечивает большую простоту взаимодействия между системами и, таким образом, более легкую интеграцию (должна быть возможность интегрировать полученную систему с ERP-Cubaв настоящее время в разработке). Представленные системы используют гибридную архитектуру между клиент-сервером и 3 уровнями, что не облегчает процесс интеграции.

Методология разработки

«Scrum» - это методология управления проектами, изложенная Хиротакой Такеучи и Икудзиро Нонака в статье «Новый продукт».

Разработка игры. «Основной принцип этой методологии заключается в том, что конкурентный рынок технологических продуктов, помимо основных концепций качества, стоимости и дифференциации, также требует скорости и гибкости». (Такеучи, 1999) Характеристики Scrum, которые подразумевали решение выбрать эту методологию, а не другую, перечислены ниже:

Это гибкая методология разработки. Она предназначена для небольших групп разработчиков (не более 8 человек). Указывается мало артефактов, что исключает ненужную «бумажную работу» и тратит больше времени на внедрение. Она позволяет выпускать функциональный продукт в конце каждого спринта..Предоставляет возможность настройки функциональности в зависимости от бизнес-потребностей клиента.Она позволяет ежедневно визуализировать проект.Она имеет ограниченный и выполнимый объем. Она применяется в группах, интегрированных и приверженных проекту, и которые являются самоуправляемыми.Нет Это методология анализа, а не проектирования (хотя она может быть адаптирована таким образом), а управления работой. Ее можно применять к различным моделям качества (например, CMMI), поскольку они говорят вам, что вы должны делать, то есть, они говорят вам, что вы должны управлять проектом,но они не говорят вам как. Вот где SCRUM входит в качестве модели управления проектами.

Описание бизнес-процессов.

Чтобы описать бизнес-процессы, связанные с объемом этой работы, необходимо сосредоточиться на процессах решения проблем и взаимосвязи приложений этого типа, которые известны.

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

Наем и процесс продаж

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

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

Протокол, Акт, Резолюция, Документ, нотариально заверенный у нотариуса, или другой юридический документ об учреждении юридического лица или компании вместе с ее корпоративной целью. Подписанный и отчеканенный договор купли-продажи согласно Pro forma de Contract (Приложение № 4)

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

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

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

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

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

По договорам купли-продажи с филиалами компаний

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

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

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

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

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

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

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

Иностранные коммерческие компании, операторы зон свободной торговли, представительства банков и проекты или программы MINVEC; Они будут проводиться в соответствии с данной процедурой в соответствии с Постановлением 222/2003, разрешением I-885/2007 и Инструкцией 2/2003 Министерства внутренней торговли.

Для осуществления продажи клиентам, упомянутым в предыдущем разделе, Группе потребуется, помимо вышеупомянутого, представление следующих документов:

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

Лицензия на деятельность в стране, выданная Торгово-промышленной палатой Республики Куба.

Для проектов и программ сотрудничества, утвержденных MINVEC:
- Заверенная копия бюджета проекта или программы, выданная MINVEC. o Заверенная копия MINVEC Технического задания утвержденного Проекта с обязательствами партнеров и их подписями и MINVEC.
Для операторов свободной зоны:
- Письмо-запрос на покупку со списком продуктов для покупки и постановлением Министерства иностранных инвестиций о количестве, которое аккредитует вас в качестве Оператора.
Для посольств и консульств:
- Письмо-запрос на покупку со списком продуктов, которые будут приобретены, и количеством. Удостоверение, которое дает вам аккредитацию в качестве члена дипломатического корпуса, выданное Министерством иностранных дел Кубы.
Для компаний и OACE:
- Субъекты будут предоставлять юридическую документацию, установленную в системе оптовых контрактов, и другие требования, установленные в этой процедуре, не требуя других специальных разрешений для продуктов, которые не имеют специальных правил. ü Для религиозных учреждений:Высшее руководство религиозного учреждения, заинтересованного в покупке, издает подписанный и выдуманный документ, в котором отражаются потребности, которые оно требует, его назначение и то, в отношении какой деятельности оно осуществляется. В случаях, когда требуются средства личной гигиены, гигиены и чистящие средства, это должно сопровождаться заявлением под присягой с указанием количества людей, обслуживаемых в объекте назначения продуктов. Когда запрос касается электрического оборудования или бытовой техники, промышленных кухонь или велосипедов с мотором или без него, религиозное учреждение должно подать запрос на разрешение вице-министру Министерства внутренней торговли, и после его выдачи он будет обработан Коммерческим вице-президентом с филиалами и отделениями., После получения разрешения коммерческого вице-президента или заместителя министра внутренней торговли,В зависимости от одобрения и запроса на покупку от религиозного учреждения, провинциальное отделение письменно проконсультируется с лицом, посещающим религию в провинциальном комитете территории, чтобы выдать свое одобрение продажи. Если вы уезжаете полностью или частично, об этом необходимо сообщить в письменной форме коммерческому вице-президенту. Во всех случаях Подразделение, которое получает запрос на покупку от религиозных организаций, должно обработать и получить письменное разрешение на осуществление продажи. Разрешительные и консультационные документы хранятся в файле контракта. Когда от клиента поступает запрос предложения на оптовую закупку товаров, не соответствующих обычным условиям, либо объемы или продукты, не соответствующие деятельности, осуществляемой Компанией или учреждением, приветствуются,Будет своевременно запрошено, чтобы запрос был оформлен или одобрен руководителем компании или учреждения посредством документа, отражающего продукты и запрошенные количества.

Торговая наценка, кредиты и платежные инструменты

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

Для субсчетов «Автомобильные запчасти и строительные материалы» = себестоимость x 1,80 для продажи товаров = себестоимость x 1,30 для гастрономических производств = на 10% ниже, чем розничная цена продажи услуг = Таблица общих затрат x 1,30 Иностранные фирмы и учреждения, дипломатический корпус = Себестоимость x 1,40 Религиозные учреждения = Себестоимость x 1,60 Для оптовой торговли (модуль) = Себестоимость x 1,30

(Продажные цены товаров, продаваемых в единицах для продажи модулей, будут округлены до 0 или 5 в соответствии с той же процедурой, что и при формировании розничной цены)

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

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

В предложениях должны быть оценены:

Объем продаж Запасы и товарооборот Характеристики покупателя, которому предлагается продать. Предлагаемая коммерческая наценка. Другие количественные и качественные элементы, поддерживающие это.

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

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

Чеки на сумму более 500 CUC должны быть заверены Банком.

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

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

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

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

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

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

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

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

Billing

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

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

Оптовый расчет будет осуществляться в соответствии с положениями

Инструкция № 15/2006 МФУ. Ответственность за подачу копии каждого из счетов-фактур, должным образом подписанных и отчеканенных уполномоченными лицами, будет входить в обязанности экономического руководителя или бухгалтера подразделения. Штамп платежа должен быть записан в счетах-фактурах, инвойс которых был произведен и подтвержден, независимо от используемого платежного инструмента. Никакие продажи или счета-фактуры не должны производиться без предварительной проверки подтверждения оплаты. В случаях, установленных данным порядком, при предоставлении коммерческих кредитов дата платежа должна быть указана в счете-фактуре в качестве перекрестной ссылки. В тех случаях, когда чек используется в качестве платежного инструмента, копия чека, полученного от клиента, должна быть приложена к счету. В случае других платежных инструментов, оставит копию ваучера, подтверждающего оплату во время выставления счета.

Описание предлагаемой системы.

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

HostingService (Service Server): это главный сайт системы: он содержит набор опубликованных веб-сервисов, которые должны обеспечивать выполнение всех процессов, описанных выше. Все остальные сайты работают с услугами, изложенными в этом. AdminSite (Сайт администрирования): Это сайт, предназначенный для работы официальных лиц и реализующий все указанные для них функции. Этот сайт не очень привлекателен для его конечных пользователей. VirtualStore (виртуальный магазин): это виртуальный магазин, который увидят покупатели. В нем есть все функции, реализованные в любом интернет-магазине, и вы можете адаптировать их к кубинским особенностям.

Роли пользователей

Предварительно заданные роли в Системе управления оптовыми продажами перечислены ниже:

Обоснование роли

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

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

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

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

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

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

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

N-уровневая сервис-ориентированная архитектура

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

Рисунок 2. Организационная форма сервисов и интерфейсов, которые могут их использовать.

Система разделена на следующие уровни:

Уровень взаимодействия Бизнес-уровень Уровень доступа к данным Уровень данных

Рисунок 3. Общий логический вид

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

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

Сервисы используют уровень доступа к данным для взаимодействия с базой данных. Эта модель является гибкой с точки зрения типа используемой базы данных. Использование NHibernate позволит использовать любой другой менеджер только путем изменения соответствующих настроек.

развертывание

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

Веб-приложение и сервисы

Рисунок 4. Вариант развертывания

Учитывая, что некоторые службы являются внутренними, а другие частными, рекомендуется следующая конфигурация:

Рисунок 5. Рекомендуемый вариант развертывания.

Безопасность

Системная безопасность применяется в трех основных измерениях: тонкий клиент, сервер приложений и сервер БД.

Рисунок 6. Параметры безопасности системы

Наибольшие угрозы безопасности на стороне клиента - это межсайтовые сценарии (XSS) и SQL-инъекции. Для устранения этих пробелов были приняты следующие соображения:

XSS

Используйте метод POST, а не GET, и выполняйте проверку данных на стороне сервера.

SQL-инъекция

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

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

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

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

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

Бэклог продукта / Стек задач продукта

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

Идентификатор модуля Описание Состояние

Критические требования

1 HostingService Система получает информацию от « 100% системы инвентаризации» о наличии товаров.

Идти	модуль	Описание	государство
		предназначен для «зоны онлайн-продаж» (код продукта, CSTA или семейство, имя, описание, количество, стоимость, розничная цена и процент скидки для соответствующих клиентов.
два	AdminSite	Система ожидает административного процесса для подготовки этих продуктов к презентации клиентам, этот процесс включает в себя: Определите или создайте изображение (я) продукта, если оно существует. Отнесите товар к той категории, к которой он принадлежит. Отметить товар как готовый к продаже (Активный).	100%
3	AdminSite	Регистрация пользователя выполнена на 100% административно некоторым персоналом компании, который будет иметь пользователя в Системе с ролью администратора пользователя. ü Существует несколько типов пользователей сайта: клиенты, официальные лица. ü В официальных пользователях есть следующие роли: o «Администратор» - обычный административный пользователь. o «Администратор пользователей», отвечающий за регистрацию клиентских пользователей в Системе. o «Коммерческий администратор», отвечающий за обработку новых продуктов, полученных из системы инвентаризации, и установление продажной цены. o «Юридический администратор», отвечающий за «блокировку» клиентов с проблемами, чтобы они не могли совершать покупки в интернет-магазине. o «Коммерческий продавец» - пользователь Системы, обрабатывающий заказы, инициированные покупателями. ü Пользователи-клиенты могут быть найдены в следующих ролях:

Идентификатор модуля Описание Состояние

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

4 AdminSite Система должна хранить следующую 100% информацию о клиенте: название компании, коммерческий регистрационный номер, если вы являетесь внутренним клиентом, если вы являетесь дипломатическим клиентом, если вы являетесь клиентом «в одной валюте», если вы платите чеком „ срок ‟укажите количество дней.

5 AdminSite Система должна обрабатывать 100% механизм

, они относятся к конкретному покупателю или к конкретному продукту:

ü Конкретный клиент: Определенным льготным клиентам предоставляется процентная скидка на все покупки, которые они совершают, пока действует это предпочтение. Этот процент определяется бизнес-менеджером. Если покупатель является «предпочтительным покупателем» при покупке, эта скидка будет применяться к общей сумме покупки, и никакая другая скидка применяться не будет.

ü Конкретный продукт: цена продажи некоторых продуктов снижена на процент. Этот процент указывается коммерческим администратором. При покупке скидки будут применяться к тем продуктам, у которых она есть, если текущий покупатель не является преференциальным, в этом случае только их процент дисконтируется от общей суммы без учета продуктов со скидкой.

Необходимые требования

6 VirtualStore Система должна показывать клиентам следующую 100% информацию об одобренных товарах, организованную по определенным категориям: изображение, имя, продажная цена.

7 VirtualStore Система должна показывать покупателям 100% подробную информацию о конкретном продукте, включая изображение, цену продажи, название, описание, количество на складе.

Идти	модуль	Описание	государство
8	VirtualStore	В Системе должна быть предусмотрена система поиска товаров.	100%
9	VirtualStore	Система покажет пользователю X продуктов, которые он недавно посещал во время посещения сайта.	100%
одиннадцать	VirtualStore	Система должна обеспечивать «корзину покупок», в которой вы можете хранить продукты, пока не захотите их купить. ü Товары в корзине должны оставаться доступными при будущих посещениях сайта, пока вы не перейдете к покупке или пока товары не будут удалены из Системы. ü Система должна позволять изменять количество или тип продуктов, добавляемых в корзину. ü В корзине для покупок Система должна отображать количество каждого продукта и общую сумму. ü Если продукт перестает существовать при обновлении или открытии корзины покупок, он будет отображаться с указанием его отсутствия.	100%
12	VirtualStore	Корзина покупок должна позволять предварительно выставлять счета за ее содержимое. ü Система подготовит предварительный счет, содержащий название, описание, продажную цену и количество каждого выбранного продукта, а также сводку с общей суммой, подлежащей оплате. ü Система будет хранить историю предварительных счетов для будущих консультаций, эта информация является частной для клиента, но доступна администраторам. ü Предварительный счет будет виден клиенту в течение времени X, настраиваемого администратором.	100%
13	VirtualStore	После того, как предварительный счет был выставлен, Система должна разрешить «резервирование товара». ü Система резервирует на время X, настраиваемое администратором, товары, запрошенные в определенном предварительном счете. Если в течение этого времени указанный предварительный счет не был оплачен,	100%

Идти

модуль

Описание

государство

товар не будет зарезервирован. Этот параметр настраивается администратором, который выбирает, включено ли резервирование или нет.

ü Система генерирует «заметку о резервировании товара», которая содержит меморандум для клиента о времени, в которое товар будет зарезервирован, и условиях бронирования.

VirtualStore

После выставления предварительного счета Система должна на 100% разрешить «покупку товара».

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

ü Клиент должен выбрать тип платежа: Чек, Аккредитив, Вексель, Онлайн-платеж или Наличный платеж. Оплата наличными может быть объединена с чеком в случае, если чек клиента меньше суммы счета, принимаются наличные платежи на сумму до 0,99 долларов США, система генерирует квитанцию об оплате. Для оплаты чеком, переводным векселем или наличными клиент предоставит соответствующие данные. Если клиент платит больше суммы счета, Система создает аккредитив. Система сохраняет аккредитивы и уведомляет биллинговую систему.

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

ü Система должна учитывать следующие правила при расчете общей суммы заказа:

o Для клиентов (иностранных фирм, не имеющих счета в MN)

Идентификатор модуля Описание Состояние
единая валюта: взимается только компонент CUC. o Для внешних клиентов, которые платят в единой валюте: сумма MN добавляется к CUC без какой-либо конвертации. o Для клиентов со скидкой в CUC и сбором в MN: значение MN вычитается из CUC без преобразования и оплачивается отдельно: CUC со скидкой и полный MN. o Для внутренних клиентов базовая стоимость взимается в CUC и MN. o Для дипломатов взимается розничная цена за вычетом применимого процента для некоторых продуктов. ü После создания счета Система уведомляет пользователя о днях, в течение которых он должен забрать товары, это политика Компании и не зависит от типа приобретенных продуктов.
Необязательные требования
15 AdminSite Система должна обеспечивать 56% рабочего интерфейса для коммерческого персонала в коммерческих помещениях Компании: ü Система должна отображать подробную информацию о заказах или предварительных счетах и счетах. ü Система должна позволять должностному лицу обрабатывать заказ, сделанный клиентом, в то время как он присутствует. o Офицер должен выбрать приказ. o Если оплата производится переводным векселем, чеком или наличными, это должно производиться вручную, и система должна позволять отмечать заказ как оплаченный. В случае Cash система генерирует квитанцию об оплате. o После обработки заказа Система ведет себя так же, как если бы он был обработан онлайн: товар зарезервирован для
Идти	модуль	Описание Статус
		Правда, на купленную продукцию действует скидка в торговом зале. ü Система должна позволять юридическим администраторам замораживать клиента. Эти клиенты не могут совершать покупки.
16	VirtualStore	Система опубликует форму, которую используют 65% Компании, чтобы стать покупателем.

Дополнительные требования

Внешний вид или внешний интерфейс:
- Простой дизайн, простой в использовании и интерактивный интерфейс, облегчающий пользователю работу с Системой. Идеально оформленный дизайн для разрешений 1024 × 768, но готовый для просмотра в других разрешениях.
Юзабилити:
- Установка системы увеличивает скорость продажи оптовых товаров, делая процесс намного более эффективным.
Программное обеспечение:
- Приложение размещается на веб-сервере IIS или Apache с установленным модулем «aspx» для компиляции страниц. Сервер базы данных должен быть SQL Server 2005 или PostgreSQL, хотя любой другой может быть установлен, указав его в конфигурации системы. Все машины У клиентов должен быть установлен браузер, желательно Internet Explorer версии 5.0 и выше, они также могут быть: Mozilla FireFox, Netscape и Opera.

(последние версии).

Кроме того, для отображения баннера установлен Flash Player версии 6.0 или выше (необязательно).

Переносимость:
- Приложение можно запускать в большинстве операционных систем, таких как Microsoft Windows 98 / Me / 2000 / XP и Linux, в последнем случае путем установки Linux-версий программного обеспечения, указанных в этих требованиях.
Оборудование:
- Для эффективной работы с системой необходим серверный компьютер, который должен иметь как минимум следующие характеристики: Pentium IV с 768 МБ ОЗУ, микропроцессор с частотой 3,00 ГГц и сетевую карту с протоколом Ethernet 10/100 МБ / с. клиентские машины: 16-разрядный графический процессор или выше с разрешением 1024 × 768 пикселей или выше, процессор с частотой 600 МГц и ОЗУ 64 МБ или выше.

Они должны быть подключены к локальной сети 10/100 МБ или иметь модем удаленного доступа со скоростью 128 Кбит / с.

Практический вклад и пути решения.

Первые шаги

После установки системы для ее корректной работы необходимо настроить следующие элементы:

Метаданные: эта концепция возникает для хранения данных, не относящихся к объектам разработанной базы данных. Например: система хранит количество контрактов, дату создания и, при желании, предназначено ли оно для компании (в противном случае это человек); если вы хотите, чтобы у этого контракта было новое свойство «X», оно определяется как метаданные контракта, и тип данных указывается, и если это требуется при заполнении формы. Таким образом, при представлении формы контракта предопределенные поля для нее и поля, добавленные через метаданные, будут окрашены.

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

Категории: система работает с семействами (или агрегатами), предоставленными системой инвентаризации, или допускает настройку. Такое определение категорий необходимо при установке системы, чтобы впоследствии организовать продукты.

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

Единицы измерения: Проданные продукты могут обрабатываться либо по их базовым единицам измерения (из системы инвентаризации), либо по эквивалентам, которые определены в системе. Для них созданы сущности UM и Equivalence соответственно.

Содержимое: это определение содержимого в формате HTML, которое будет отображаться на главной странице указанного сайта. Для этого есть редактор страниц в визуальном формате WYSIWYG.

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

Мультивалютное управление и формирование оптовых цен

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

Эта формула - не что иное, как регулярное выражение в следующем формате:

( w {1,} ( d {1,}) *;) *

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

CUC * 9/10; КРУЖКА;

В этом случае клиенты, затронутые показанным правилом, получат результат оценки записанной функции как оптовой цены с розничной ценой в каждом из ее компонентов.

Для клиентов, которые работают с одной валютой или только с частью «n», настроенной в системе, части правила опускаются или нет. Например: если система настроена для работы с CUC и CUP, и вы хотите, чтобы клиент платил 98% компонента CUC, следует написать следующее правило:

CUC * 98/100;

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

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

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

Интернет Сервис

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

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

Строительство предлагаемого решения

Принципы разработки приложений

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

1-й принцип: эквивалентное использование

Дизайн полезен и может быть продан людям с разными способностями.

Рекомендации по Принципу 1:

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

2-й принцип: гибкое использование

Дизайн учитывает широкий спектр индивидуальных предпочтений и возможностей.

Рекомендации по Принципу 2

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

Третий принцип: простой и интуитивно понятный

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

Рекомендации к Принципу 3

Это устраняет ненужную сложность. Это соответствует ожиданиям и интуиции пользователя.

Это обеспечивает широкий диапазон грамотности и языковых навыков.

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

4-й принцип: воспринимаемая информация

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

Рекомендации для Принципа 4

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

Пятый принцип: толерантность к ошибкам

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

Рекомендации по Принципу 5

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

Шестой принцип: это требует небольших физических усилий.

Эту конструкцию можно использовать эффективно, комфортно и с минимумом усталости.

Рекомендации к Принципу 6

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

Это сводит к минимуму постоянные физические усилия.

Седьмой принцип: размер и пространство для доступа и использования

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

Рекомендации к Принципу 7

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

Дизайн должен быть основан на сочетании идей, желаний и потребностей пользователя, а также на материалах, доступных программисту, и в этом случае речь идет о пользователях, которые могут быть экспертами или неопытными в предмете; некоторые из них неподготовлены в вопросах ИТ.

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

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

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

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

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

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

Обработка исключений

Жизненно важно добиться правильной работы любой системы, чтобы выявить и контролировать возможные ошибки, которые могут возникнуть при взаимодействии с программным обеспечением. Для правильной работы приложения эти ошибки будут обрабатываться таким образом, чтобы взаимодействия с базой данных (вставка, удаление, модификация…) выполнялись правильно, для этого были установлены механизмы проверки, которые проверяют правильность данные для обработки; Кроме того, формы настаивают на том, чтобы пользователь вводил минимально возможное количество данных, максимально используя вычисляемые поля в форме, средства управления выбором; такие как: переключатели (RadioButton), флажки (CheckBox) и списки выбора (ListBox) и другие.Таким образом, пользователь выбирает одну из предварительно определенных опций, что не оставляет места для ошибки.

В случае ввода данных пользователем средства, предоставляемые C # и ASP.NET, используются для проверки данных; если есть ошибки, отображаются сообщения, которые иллюстрируют неправильную вставку, изменение или неправильное обращение с данными в целом с возможностями, предлагаемыми используемым языком, показывая пользователю правильную и поясняющую информацию о возможной сделанной ошибке. Все сообщения об ошибках отображаются в выделенных сообщениях с использованием возможностей технологии AJAX для реализации функций, отвечающих за управление и проверку данных в клиенте, и будет реализована вторая проверка данных, отправленных пользователем и полученных от клиента. база данных, чтобы свести к нулю возможные ошибки и гарантировать взаимодействие пользователя с системой качества.

Стандарт кодирования

«Любой дурак может написать код, понятный компьютерам. Хорошие программисты пишут код, понятный людям ". Мартин Фаулер

Стандарт кодирования фокусируется на руководствах по стилю программирования на языке C #, хотя его можно использовать во многих других языках и средах для установления используемых соглашений.

Организация файлов
- Исходные файлы

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

Дерево каталогов и пространство имен

Пространство имен объектов будет отражено в дереве каталогов исходного кода. Таким образом, класс Y10K.AyeAye.Switch будет иметь свой код в Y10K / AyeAye / Switch.cs. Если абстрактный класс содержит полезный код и другие классы, унаследованные от него, например классы специализации, будет файл с расширением cs, соответствующим абстрактному классу, и на том же уровне каталог с именем абстрактного класса, который он будет содержать наследование классов.

вдавливание
- Длина линии

По возможности длина строки не должна превышать 80 символов.

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

Если есть список элементов, разделенных запятыми, он будет разделен запятой.

Если это выражение, оно будет разделено после одного из операторов. Предпочтительно, чтобы выражение было разделено на более высокие уровни, а не на более низкие уровни.

Линия разделения будет выровнена с уровнем, на котором произошло разделение.

Расстояние между отступами

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

Объявления
- Количество выписок в строке

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

инициализация

По возможности переменные будут инициализированы в той же строке объявления.

Объявление классов и интерфейсов: для определения классов и интерфейсов будут соблюдаться следующие правила:

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

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

Фразы
- Простые утверждения

Каждая строка будет содержать не более одного предложения, хотя, как объяснялось в разделе 3, предложение может состоять более чем из одной строки.

Заявления о возврате

В операторе возврата круглые скобки не используются.

Базовый оператор выбора (if / if… else / if… else if… else)

Начальные фигурные скобки блока кода помещаются в конце оператора if, else или else if. Закрывающие фигурные скобки находятся на отдельных строках. Когда за блоком кода следует инструкция else или else if, она будет помещена в ту же строку, что и закрывающая фигурная скобка.

Операторы цикла For или foreach

Подобно операторам выбора, открывающая фигурная скобка будет помещена после оператора определения for или foreach, а закрывающая фигурная скобка - на отдельной строке.

Операторы цикла while или do while

Идентично for, но в случае do while, while будет помещен в ту же строку, что и последняя скобка.

Операторы множественного выбора (переключатель)

Что касается ключей, то они будут размещены, как и в остальных корпусах. Что касается кода и строки разрыва, они будут идти с отступом на один отступ больше, чем соответствующая строка case, которая будет идти с отступом на один отступ больше, чем строка переключателя.

Операторы перехвата и обработки исключения (try / catch / finally) Обработка ключей блока будет такой же, как и в остальных операторах.

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

Отдельные участки кода в файле.

Отдельные определения классов и интерфейсов в файле.

Пустая строка разделяет…

Методы.

Определения локальных переменных в методе. Блоки кода, не связанные напрямую.

Разделения между терминами

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

Разделения в объявлениях

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

string name = "Mr. Эд »; int myValue = 5;

Тест aTest = Test.TestYou;

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

Название класса должно состоять из существительных. Будут использоваться заглавные буквы Паскаля. Префикс класса использоваться не будет.

Номенклатура интерфейсов

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

Номенклатура для перечислений

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

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

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

Номенклатура переменных

Будет использован верблюд. Когда используются тривиальные счетчики, будут использоваться такие имена, как i, j, k, m, n,….

Номенклатура методов

В Паскале методы будут названы глаголами.

Номенклатура для свойств Существительные будут использоваться в Номенклатуре Паскаля для событий

События будут иметь суффикс EventHandler, и будут использоваться два параметра с именем sender и e. Паскаль будет использоваться. Глаголы будут использоваться в прошедшем и настоящем времени, чтобы дать представление о значении события.

Практика программирования
- видимость

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

Магия запрещена

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

Комментарии

Будет использоваться только формат //, / *… * / никогда не будет использоваться.

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

Помощь зачатию

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

Оценка устойчивости

Административное воздействие

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

Для просмотра сайта требуются не очень продвинутые условия: компьютер Pentium III с веб-браузером (Internet Explorer, Mozilla Firefox, Opera), 64 МБ ОЗУ и подключение к СЕТИ, в которой опубликован «HostingService», который может быть LAN, интранет или Интернет. Если вы хотите реализовать приложение в оптимальных условиях, вы можете использовать самые современные технологии, которые потребуют следующих затрат (Оборудование для сети. Цены предоставлены Copextel Corporation):

Количество Описание	Цена (CUC)
один	Сервер DELL PE830 3ГГц / 2 МБ / 800/512 МБ / 2X73 ГБ / M / K	2,177.80
один	Цифровой плоскопанельный 17-дюймовый монитор DELL E173FP	299,00
один	Навесной шкаф 2 кпо 12U под стекло	239,89
один	AT-8024-10. 24 порта 10/100 Base TX, уровень 2, менеджер	424,84
один	Zyxel ES-1024A Коммутатор Fast Ethernet 24 × 10/100 Base Tx	129,04
3. 4	Патч-корд 3м	81,94
14	Канал DEXSON 60 × 40 (2 м)	68,04

Создание системы способствует новым формам распространения продуктов (или услуг), расширяя возможности бизнеса, с учетом увеличения потенциальных клиентов из любой географической области без ограничений. Таким же образом достигается открытие и расширение в сторону новых удаленных и / или неизвестных рынков, а часы бизнес-обслуживания увеличиваются с «n» часов в день до предоставления услуги 360 дней в году, 24 часа в сутки.

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

Для разработки и внедрения системы необходим ряд программного обеспечения и рабочих платформ, некоторые из которых распространяются бесплатно:

программное обеспечение	Цена (долл. США)
Вариант бесплатного программного обеспечения
Кубунту 7.10 Порывистый	Свободно
Monodevelop	Свободно
Веб-сервер Apache	Свободно
Сервер базы данных PostgreeSQL 8.2.4.1	Свободно
Вариант с проприетарным ПО
Windows XP	128,00 $ - 307,53 долл. США
Visual Web Developer 2005 (экспресс-выпуск)	Свободно
Информационный сервер в Интернете	Входит в ОС
SQL Server 2005 (экспресс-выпуск)	Свободно

Социально-гуманистическое влияние

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

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

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

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

Воздействие на окружающую среду

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

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

Технологическое воздействие

Для использования приложения не требуются глубокие компьютерные знания, напротив, требуются только базовые знания о том, как управлять веб-страницей в браузере; также имеют минимальные представления о просмотре Интернета, чтобы иметь доступ к различным модулям информации, продаж и конфигурации системы. Для администрирования сайта также не требуются продвинутые знания, только базовые принципы, владение различными модулями и среднее знание клиент-серверных технологий (управление веб-сервером и системой управления базами данных).

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

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

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

Выводы

В результате исследования можно сделать следующие выводы:

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

рекомендации

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

Внедрение и использование системы на малых и средних предприятиях в стране для оценки ее развертывания в более широком масштабе. Использование системы в качестве вспомогательного материала для преподавания таких предметов, как «Электронная торговля», и дополнительных курсов, таких как «Архитектура и шаблоны». Разработка новых версий Использование других методологий, таких как RUP или XP, для сравнения полученных результатов. Выполните полный переход системы на платформы, гарантирующие ее технологическую независимость.

Библиография

Почему именно ASP.NET? Эскивель, Хулио Батиста. 2006. 4, Madrid: sn, 2006, Vol. 1. Almeida. 2002. Буфет Алмейда. Веб-сайт Буфета Алмейды. 12 октября 2002 г. http://www.lssice.com/23/lssice. Альварес, Мигель Анхель. 2006. Веб-разработка. 2006. http://www.desarrolloweb.com/php/. Аравена I, Диего и другие. 2006. Электронная коммерция. Факультет образования и гуманитарных наук Университета де ла Фронтера. Temuco: sn, 2006. Arsys. 2007. Arsys.es. Справочный сайт: хостинг ресурсов, электронная коммерция. http://www.arsys.es/ayuda/directorio/productos/hosting/comercio-electronico.htm. Associates, Anguiano &. 2006. Правовые проблемы электронной коммерции. Испания: сн, 2006.АУКЕН, Дж. 2007. HTTP-транзакции с использованием PHP. 2007. http://www.malditainternet.com/node/63? PHPSESSID = d7825b7a5b5ca2adea79bd0505c09db Авила, Эдуардо Рене Родригес. 2008. Электронная коммерция. Отдел аспирантуры и исследований УПИИКСА. 2008. БАНКОВСКАЯ ДЕЯТЕЛЬНОСТЬ, CDS 2006. Прочие банковские операции: инкассо и платежные операции. 2006. http://www1.euskadi.net/guiaconsumo/curso_bancario/preguntas.apl?apartado=26. Bitpipe. 2004. Bitpipe.com. 2004. http://www.bitpipe.com/tlist/Perl.html. БОРЕТТО, М.М. 2005. Аспекты интеллектуальной собственности, полученные из цифровой среды, в международном частном праве. 2005 г. http://www.eumed.net/libros/2005/mmb/index.htm. Броса, Педро. 2000.Бизнес-стратегии и юридические и налоговые последствия. 2000. КАМПИТЕЛЛИ, АДРИАН. 2003. Электронная коммерция. 2003. http://www.monografias.com/trabajos12/monogrr/monogrr.shtml. КАРАМЕ, HV 2006. Банки в Интернете. 2006. http://www.ciao.es/Opiniones/PayPal__289916. КОММУНИКАЦИИ, DG 2007. Платежные шлюзы. 2007. http://www.dimensis.com/pasarela-de-pagos.html. Корпорация Microsoft. 2005. Обзор продукта SQL Server 2005. Microsoft TechNet SQL Server TechCenter. 2005. -. 2007. Архитектурный журнал. 2007. Куэрво, Хосе. 2008. Субъекты цифровой подписи и сертификации. 2008.DILOCONFORES. 2006. Безопасные транзакции, формы оплаты. 2006. http://diloconflores.com/store/comersus_index.asp. Объяснение Scrum за 10 минут. Серрано, Хорхе. 2007. 4, Богота: sn, 2007, Vol. 1. Estenos, Raul Sanchez. 2005. 10 причин использовать Java. Лима: sn, 2005. FERNÁNDEZ, F. 2007. Веб-программирование: используемые языки. 2007. http://www.xeoweb.com/programacion-web.php. Гомес, Расиэль. 2001. Интернет-маркетинг. Рауль Порту Сантос. Лима: sn, 2001. GUARDIA, CDL 2007. Эволюция электронной коммерции. 2007. http://www.razonypalabra.org.mx/anteriores/n20/20_cguardia.html. Эррера, Йохани. 2007.Методы и инструменты, используемые в разработке требований. 2007. http://www.monografias.com/trabajos6/resof/resof2.shtml.. ITAA. 2004. Американская ассоциация информационных технологий. 2004. www.itaa.org. МАРАОН, Г.А. 2008. Безопасные электронные транзакции (SET), средства платежа. 2008. http://www.iec.csic.es/criptonomicon/comercio/set.html. МЕНДЕС, Дж. 2006. Тенденции в языках программирования. 2006. http://www.monografias.com/trabajos/tendprog/tendprog.shtml. Microsoft. 2006. Электронная подпись и надежность онлайн-транзакций. 2006. http://www.microsoft.com/spain/seguridad/xp/firma/default.asp. НЬЮКИРК, Дж. 2002.Экстремальное программирование на практике. Мадрид: sn, 2002. Юридические новости. Юридические новости. 2000. http: //noticias.juridicas.com.Planeta Code. 2005. http://www.planetacodigo.com/wiki/glosario:extreme_programming. Прессман, Роджер С. 2002. Разработка программного обеспечения. Практический подход. 2002. REBELDE, MECD 2005. Препятствие электронной коммерции. 2005. http://www.mesaredonda.cu/informacion.asp?idInformacion=254&idSeccion=4&Logo=71. Рибас, Ксавьер. 2005. ЭЛЕКТРОННЫЕ, ПРАВОВЫЕ АСПЕКТЫ ТОРГОВЛИ. 2005. Родригес, Хавьер Пренафета. 2005.Хостинговые контракты. Обзор основных вопросов, которые следует учитывать при заключении такого типа контракта »на сайте Ассоциации содействия развитию информационных технологий и электронной торговли (APT. 2005. http: // news. juridicas.com/external/nj_aptice/2002085556141710242121.html Руссо, Ренне, 2001. Информационные и коммуникационные технологии. 4, 2001, Том 1. Салдивар, Рауль Висенте. 2007. 5 причин не использовать Spring. Mexico DF: sn, 2007. 2. Швабер, Кен и Бидл, Майк. 2003. Гибкая разработка программного обеспечения с помощью SCRUM. 2003. Компьютерная безопасность, почему и для чего. 2002. Ноябрь 2002, КРАСНЫЙ. Серрано, Агустин. 2006.Правовая и налоговая база в электронной коммерции. 2006. Симсом, Ричард. 2007. Компьютерная безопасность. Сообщество сетевых экспертов. 2007. Sparxsystems. 2005. 2005. www.sparxsystems.com. СТЕФЕНС М., РОЗЕНБЕРГ Д. 2003. Реорганизация экстремального программирования: дело против XP California: sn, 2003. Takeuchi, Hirotaka. 1999. Скрам. 1999. Вареа, Исмаэль Гарсия. 2006. JAVA Приют для экспертов? 14 из 4 за 2006 год.

Приложения

Приложение 1: вид виртуального магазина

Приложение 2: Вид на сайт администрации

Приложение 3: Основные функции системы электронной торговли.

Доступ ограничен для пользователей с кодом доступа. Общедоступный и частный каталог продуктов. Печать каталогов. Статус заказа и последующие действия. Управление рисками и ситуациями, возвраты и коллекции. Поиск предметов. Виртуальный магазин. Запасы предметов по опциям (цвета, размеры, срок службы и т. д.). Шифрование данных и заказов. История выставления счетов. Доставка заказа. Печать счетов. Подтверждение оплаты через защищенные страницы SSL и онлайн-банк. Настраиваемый файл товара. Настраиваемая форма покупки..Импорт статей из других баз данных. Резервная копия. Включены шаблоны дизайна. Автономное обслуживание. Проверка выбранных продуктов. Редактирование страниц в визуальном формате WYSIWYG.

Словарь терминов

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

Планирование ресурсов предприятия

Простой протокол доступа к объектам. Это стандартный протокол, созданный Microsoft, IBM и другими, в настоящее время он находится под эгидой W3C, который определяет, как два объекта в разных процессах могут взаимодействовать посредством обмена XML-данными.

Загрузите исходный файл