Создание проекта информационной системы электронной торговли

Министерство образования и науки Республики Таджикистан Политехнический институт Таджикского технического университета имени академика М. Осими в г. Худжанде Факультет: «Информационно-технологический» .

Кафедра: «Информационные системы и экономика» .

" Утверждаю" .

Зав. кафедрой «ИС и Э» .

Худойбердиев Х.А.

Курсовая работа Создание проекта информационной системы электронной торговли Выполнил:

Расулов Азимджон Абдуазизович студент 4 курса группы 40.01.02ра Худжанд — 2015.

Содержание Введение.

1. Этап анализа.

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

1.2 Определение процессов.

1.3 Описание прецедентов.

1.4 Типичный ход событий.

1.5 Концептуальная модель.

1.6 Определение основных функций системы.

1.7 Диаграмма последовательностей.

2. Этап проектирования.

2.1 Системных операций.

2.2 Реальные прецеденты с интерфейсными формами.

2.3 Диаграмма кооперации.

2.4 Распределение обязанностей между классами.

2.5 Диаграмма состояний.

2.6 Диаграмма классов.

2.7 Диаграмма развертывания.

3. Расчет себестоимости ИС.

3.1 Калькуляция весовых действующих лиц.

3.2 Калькуляция весовых вариант использования.

3.3 Определение уровень технический сложности проекта.

3.4 Определение уровень квалификации разработчиков.

3.5 Оценка трудоемкости проекта Заключение Список литературы Приложение.

Введение

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

Основными направлениями деятельности в области электронной торговли являются:

· развитие информационного бизнеса, электронной коммерции и маркетинга на основе Интернет.

Данная работа состоит из 40 страниц, 16 рисунков, 26 таблиц и три глав.

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

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

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

1. Этап анализа.

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

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

Функции электронной торговли:

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

· регистрация покупателей;

· предоставление интерфейса к БД продаваемых товаров (в виде каталога, прайс-листа);

· работа с электронной корзиной покупателя;

· оформление заказов с выбором метода оплаты, доставки, страховки и выпиской счёта;

· резервирование товаров на складе;

· проведение расчётов (при выборе электронных методов оплаты) или контроль факта оплаты (при использовании традиционных форм расчётов);

· формирование заявок на доставку товаров покупателям и выписка сопроводительных документов;

· предоставление покупателю средств отслеживания исполнения заказов;

· доставка товаров;

· сбор и анализ различной маркетинговой информации;

· обеспечение безопасности личной информации покупателей;

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

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

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

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

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

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

Далее, собранный материал переводится в символы IDEF0, в соответствии с правилами методики.

Модель электронной торговли раскрывался как сложный модель и состоит из 11 процессов. Этот модель показано ниже на рисунке 1.1.

Рис 1.1. Декомпозиция бизнес-процесса электронной торговли на составляющие его операции в стандарте IDEF 0.

Таблица 1.1 Описание процессов.

1.3 Описание прецедентов Диаграмма в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

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

Рис. 1.4 диаграмма прецедентов Основной прецедент для рассматриваемой области является добавление товара. В этом процессе участвуют как поставщики (клиент), так и администратор. Основная цель процесса — добавление товара со стороны поставщиков. Для достижения цели, необходимо выбрать из списка доступных каталогов интересующую, далее формировать товар. Этот процесс управляется администраторам ИС то есть проверяет данные о товаре и поставщиков и потом этот товар публикуется в ИС «электронной торговли». Данный прецедент описано в таблице 1.2.

Таблица 1.2 Описание варианта использования «добавление товара» .

Рис. 1.2 процесс добавление товара Таблица 1.3 Описание варианта использования «заказ-онлайн» .

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

1.4 Типичный ход событий Типичный ход событий — обеспечивает наглядное представление общения с системой.

Таблица 1.4 типичный ход события «Оформление заказа» .

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

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

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

Ассоциация (association) — это отношение между классами, отражающая некоторые значимые и полезные связи между ними. Ассоциация обозначается проведенной между классами линией, с которой связано определенное имя, начинающееся с большой буквы. На рисунку 5 приведен пример ассоциации.

Рис. 1.5. Система обозначений ассоциаций в языке UML.

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

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

Таблица 1.6. Список стандартных ассоциаций.

Функциональность и эффективность информационной системы — является одним из основных требований в разрабатываемой квалификационной работе.

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

Модель предметной области — это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области. Такие модели также называют концептуальными моделями.

Рис. 1.5 диаграмма классов электронной торговли На рис. 1.5 показана концептуальная модель. В ней выделены 5 основных концептуальных классов: «Users», «Product», «Zakaz», «Oplata» и «Korzina». Эти классы в свою очередь разделятся на несколько классов которые приведены ниже на рисунке 1.5.

Каждый класс имеет свои атрибуты и операции.

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

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

Полноценность и достоверность информации — так же одно из наиболее важных требований к разрабатываемой теме.

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

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

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

Таблица 1.7. Описания функций ИС электронной торговли.

1.7 Диаграмма последовательностей Диаграмма последовательности — одна из диаграмм взаимодействия. На диаграмме последовательностей иллюстрируются события, инициированные в системе исполнителями.

Моделирование временной упорядоченности потока управления осуществляется следующим образом:

1. Устанавливается контекст взаимодействия, будь то система, подсистема, операция, класс или один из сценариев прецедента либо кооперации.

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

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

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

Рис 1.6. Диаграмма последовательности прецедента онлайн-заказ.

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

2. Этап проектирования Для разработки данного ИС используется PHP & MYSQL потому что РНР предоставить программисту средства для быстрого и эффективного решения поставленных задач. Практический характер РНР обусловлен пятью важными характеристиками:

* традиционностью;

* простотой;

* эффективностью;

* безопасностью;

* гибкостью.

Существует еще одна «характеристика», которая делает РНР особенно привлекательным: он распространяется бесплатно! Причем, с открытыми исходными кодами (Open Source).

Сценарии на языке PHP могут выполняться под всеми основными операционными системами, в том числе под Microsoft Windows и Unix-подобными операционными системами (Linux, OpenBSD, Solaris, HP-UX), Mac RISC OS, OS X и некоторыми другими. Большинство современных веб-серверов поддерживают PHP: Apache, Personal Web Server, Microsoft Internet Information Server, iPlanet, Netscape, Caudium, Oreilly Website Pro, OmniHTTPd, Xitami и другие.

Язык PHP позволяет организовать обработку данных форм, создание динамических страниц сайта, создание и обработку файлов cookies и многие другие функции CGI (Common Gateway Interface).

Язык сценариев PHP позволяет вести разработку приложений как на основе процедурного, так и на основе объектно-ориентированного программирования (ООП).

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

Предусловия (preconditions) — это перечень предпосылок, которые всегда должны выполняться до начала сценария прецедента. Выполнение этих условий не проверяется в рамках логики выполнения данной операции, а предполагается, что они истинны. Результаты, или постусловия (postconditions), описывают, какие условия должны выполняться в случае успешного завершения сценария. Эти результаты должны удовлетворять интересам всех заинтересованных лиц. Выделение постусловий — наиболее важная часть описания системных операций.

Таблица 2.1. Описание системной операции register_customer.

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

После регистрации пользователи могут входить, заполняя форму авторизации своим логин и паролем. Описание операции авторизации приведены в таблице 2.2.

Таблица 2.2. Описание системной операции autorize.

Таблица 2.3. Описание системной операции add_product.

В этом операции пользователи-поставщики могут зарегистрировать новые товары, заполняя данные товары которые приведены в таблице № 2.3.

Таблица 2.4. Описание системной операции update_product.

В этом операции пользователи-поставщики могут редактировать данные товара.

Таблица 2.5. Описание системной операции delete_product.

Если товар на складе в наличии не осталось, то с помощью данной операции, поставщик может удалить товар.

Таблица 2.6. Описание системной операции search-product.

С помощью данной операции пользователи могут найти товар и по форме поиска и по каталогу.

Таблица 2.7. Описание системной операции zakaz_product.

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

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

2.2 Реальные прецеденты с интерфейсными формами Таблица 2.8 Описание варианта использования «добавление товара» .

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

бизнес интернет информационный торговля Рис. 2.1 процесс добавление товара Этот процесс управляется администраторам ИС то есть проверяет данные о товаре и поставщиков и потом этот товар публикуется в ИС «электронной торговли» .

Таблица 2.9 Описание варианта использования «заказ-онлайн» .

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

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

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

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

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

Таблица 2.10. Сравнительная характеристика типов диаграмм взаимодействия.

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

Рис. 2.4 — Диаграмма последовательности онлайн-заказ.

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

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

2.4 Распределение обязанностей между классами Таблица 2.11. Краткое описание шаблонов распределения обязанностей.

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

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

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

Рис 2.6 Диаграмма состояние товара на сайте Характеристика состояний системы не зависит (или слабо зависит) от логической структуры, зафиксированной в диаграмме классов. Поэтому при рассмотрении состояний системы приходится на время отвлечься от особенностей ее объектной структуры и мыслить совершенно другими категориями, образующими динамический контекст поведения моделируемой системы.

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

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

Рис 2.7 диаграмма классов электронной торговли Они иллюстрируют взаимоотношения программных элементов, а не понятий из предметной области. На рисунке 2.7 приведен пример диаграммы классов для электронной торговли.

Рис. 2.8 диаграмма компонентов Диаграмма компонентов служит частью физического представления модели, играет важную роль в процессе ООАП и является необходимой для генерации программного кода. Для разработки диаграмм компонентов в браузере проекта предназначено отдельное представление компонентов (Component View), в котором уже содержится диаграмма компонентов с пустым содержанием и именем по умолчанию Main (Главная) В шестом подразделе второй главы проектировано диаграмма классов, в котором было сгенерировано взаимоотношения между классами. Также в этом разделе разработано диаграмма компонентов модуль корзина-заказ электронной торговли.

2.7 Диаграмма развертывания Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «размещение» точнее отражает сущность этого типа диаграмм.

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

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

Рис. 2.9. Диаграмма развертывания В седьмом разделе было проектировано диаграмма развертывание. Этот вид диаграмм предназначен для анализа аппаратной части системы.

3. Расчет себестоимости ИС.

3.1 Калькуляция весовых действующих лиц Все действующие лица системы делятся на три типа: простые, средние и сложные. Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом. Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом (например, алфавитно-цифровым терминалом). Сложное действующее лицо представляет личность, пользующуюся графическим пользовательским интерфейсом.

Таблица 3.1. Весовые коэффициенты действующих лиц.

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

Таблица 3.2. Типы действующих лиц.

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

Таким образом, общий весовой показатель равен:

А=2*1 + 4*2+1*3 =13.

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

Таблица 3.3 Весовые коэффициенты вариантов использования.

Для системы электронной торговли сложность вариантов использования определяется следующим образом (табл. 3.4).

Таблица 3.4. Сложность вариантов использования.

Таким образом, общий весовой показатель равен:

UC = 5*4 +6 * 10 =80.

В результате получаем показатель UUCP (Unadjusted Use Case Points):

UUCP=A+UC=13+80=93.

3.3 Определение уровень технический сложности проекта Техническая сложность проекта (TCF — Technical Complexity Factor) вычисляется с учетом показателей технической сложности (табл. 3.6). Каждому показателю присваивается значение Тi. в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 — высокую значимость). Значение TCF вычисляется по формуле TCF = 0,6 + (0,01*(STi* Весi)) Таблица 3.6 Показатели технической сложности проекта TCF.

Таблица 3.5. Показатели технической сложности проекта TCF.

Каждому показателю присваивается значение Ti в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 — высокую значимость). Значение TCF вычисляется по формуле:

TCF = 0,6 + (0,01 * (УTi * Весi).

Таблица 3.6. Показатели технической сложности системы электронной торговли.

Вычислим TCF для системы:

TCF = 0,6 + (0,01 * 41,75) = 1,0175.

3.4 Определение уровень квалификации разработчиков Уровень квалификации разработчиков (EF — Environmental Factor) вычисляется с учетом следующих показателей.

Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1 — F4 0 означает отсутствие, 3 — средний уровень, 5 — высокий уровень. Для показателя F5 0 означает отсутствие мотивации, 3 — средний уровень, 5 — высокий уровень мотивации. Для F6 0 означает высокую нестабильность требований, 3 — среднюю, 5 — стабильные требования. Для F7 0 означает отсутствие специалистов с частичной занятостью, 3 — средний уровень, 5 — все специалисты с частичной занятостью. Для показателя F8 0 означает простой язык программирования, 3 — среднюю сложность, 5 — высокую сложность.

Таблица 3.7. Показатели уровня квалификации разработчиков.

Для каждого показателю даем значение от 1 до 5. Вычислим EF для системы электронной торговли :

Таблица 3.8. Показатели уровня квалификации разработчиков системы электронной торговли.

Значение EF вычисляется по формуле:

EF = 1,4 + (-0,03* (УFi * Весi)).

Вычислим EF:

EF = 1,4 + (-0,03*20) = 0.8.

В результате получаем окончательное значение UCP (Use Case Points):

UCP = UUCP * TCF * EF = 93 * 1,075* 0.8 = 79,98.

3.5 Оценка трудоемкости проекта Рассмотрим показатели F1-F8 и определим, сколько показателей F1-F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч на одну UCP, если 3 или 4−28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.

Для системы регистрации получаем 20 чел.-ч на одну UCP.

Таким образом, общее количество человеко-часов на весь проект равно.

UCP =79,98*20 = 1599,6 ч/ч.

UCP =1599,6 ч/ч что составляет около 39,99 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из четырех человек (руководитель программист, дизайнер и аналитик), и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 10,7 недель на весь проект.

Для подсчета заработной платы сотрудников за весь период проекта, были произведены вычисления, показанные на рис. 3.9.

Таблица 3.9. начисление зарплаты сотрудникам электронной торговли.

На таблице 3.9. показано начисление зарплаты за проект разработчика и преподавателя ИС. Исходя из вычисленной суммы разработанного учебно — методического комплекса понятно, что получает 28 сом в час, программист и аналитик получают по 17 сом в час, а дизайнер получает. Это означает что разработка ИС электронной торговли является эффективной, потому что она действительно оправдывает эту стоимость.

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

Заключение

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

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

1. UML основы. М. Фаулер. — СПб.: Символ-Плюс, 2005. — 184 с.

2. Технологии разработки программного обеспечения. С. А. Орлов. — СПб.: Питер, 2002. — 342 с.

3. Дастурамал барои и? рои кор? ои лаборатор? аз фанни технологияи UML. Солиев О. М., Худойбердиев Х. А. (электрон? дар китобхонаи ра? амии ДПДТТ).

4. Дастурамал барои и? рои кор? ои семестр? аз фанни технологияи UML. Худойбердиев Х. А. (электрон? дар китобхонаи ра? амии ДПДТТ).

5. Язык UML. Руководство пользователя. Г. Буч, Д. Рамбо, А. Джекобсон. — СПб.: Питер, 2001. — 325 с.

6. Использование средств Visual Basic.Net в создании информационных систем. Учебное пособие. Мачулина Л. А., Скороходов В. А. — Ростов-на-Дону: 2008. -141 с.

7. Самоучитель UML. Леоненков А. В. -СПб.: БХВ-Петербург, 2006. -432 с.

8. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. Вендров А. М. — М.: Финансы и статистика, 2006. — 192 с.

Приложение Рис. 3. компонент главного страницы.