Проектирование интернет-магазина для предприятия розничной торговли "Электра"

К настоящему времени наибольшее распространение получили следующие  две основные модели ЖЦ:

каскадная модель (70-85 г.г.);

спиральная модель (86-90 г.г.).

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

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

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

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

 

2.2.3 Стандарт ISO 12207.

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

Стандарт определяет архитектуру, процессы, разделы и подразделы ЖЦ ПО, а также перечень базовых работ  и детализирует содержание каждой из них. Архитектура ЖЦ ПО в стандарте  базируется на трех крупных компонентах:

основные процессы жизненного цикла ПО и определяющие работы;

вспомогательные процессы и  работы, поддерживающие жизненный цикл ПО;

организационные процессы и  управление жизненным циклом ПО.

Эти разделы стандарта  состоят из ряда подразделов, в которых  подробно раскрывается содержание каждой работы и комментируются особенности  их выполнения. Рекомендации к каждому  подразделу состоят в среднем  из 3-6 пунктов — работ (процедур). Общее число работ и комментариев к ним в стандарте свыше 220.

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

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

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

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

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

 

2.2.4 Диаграммы,  реализованные в структурном  подходе

Диаграммы декомпозиции DFD, IDEF0 и IDEF3

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

Диаграммы потоков данных (Data flow diagramming, DFD):

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

создаются для моделирования  существующего процесса движения информации;

используются для описания документооборота, обработки информации;

применяются как дополнение к модели IDEFO для более наглядного отображения текущих операций документооборота (обмена информацией);

обеспечивают проведение анализа и определения основных направлений реинжиниринга ИС.

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

В случае наличия в моделируемой системе программной/программируемой  части (практически всегда) предпочтение, как правило, отдается DFD по следующим  соображениям.

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

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

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

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

функции процесса;

входящая и исходящая  информация, при описании документов;

внешние бизнес-процессы, описанные  на других диаграммах;

точки разрыва при переходе процесса на другие страницы.

Если при моделировании  по методологии IDEF0 система рассматривается  как сеть взаимосвязанных функций, то при создании DFD-диаграммы система  рассматривается как сеть связанных  между собой функций, т.е. как совокупность сущностей (предметов). Структурный  анализ - это системный пошаговый  подход к анализу требований и  проектированию спецификаций системы  независимо от того, является ли она  существующей или создается вновь. Методологии Гейна-Сарсона (Gane-Sarson) и Йордана/Де Марко (Yourdon/DeMarko) построения диаграмм потоков данных, основанные на идее нисходящей иерархической организации, наиболее ярко демонстрируют этот подход. Целью этих двух методологий является преобразование общих, неясных знаний о требованиях к системе в  точные (насколько это возможно) определения. Обе методологии фокусируют внимание на потоках данных, их главное  назначение - создание базированных на графике документов по функциональным требованиям. Методологии поддерживаются традиционными нисходящими методами проектирования и обеспечивают один из лучших способов связи между аналитиками, разработчиками и пользователями системы  за счет интеграции следующих средств:

Диаграмм потоков данных.

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

Миниспецификации обработки, описывающие DFD-процессы нижнего уровня и являющиеся базой для кодогенерации.

 

2.3 Разработка  интернет-магазина.

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

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

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

Настройки

Дизайн

Каталог

Оплата и доставка

Клиенты

Управление статьями

Вопросы

Новости

Опросы

Сертификаты

Локализация

Отчеты

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

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

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

Базовая функциональность системы  управления Интернет-магазином на и  возможности интернет-магазина:

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

Неограниченное число  категорий

Неограниченное число  продуктов

Неограниченная глубина  дерева категорий

Каждый товар может  быть добавлен сразу в несколько  категорий

Возможность временного отключения показа продуктов

Учет остатков товарных позиций  на складе

Определение HTML описаний и  логотипов категорий

HTML описание продуктов

Возможность указания стоимости  доставки для каждого продукта индивидуально

Возможность установить бесплатную доставку для продукта

Каждый продукт может  быть отнесен к некоторому классу налогообложения

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

Поддержка электронных продуктов

Фотографии продуктов, которые  можно загрузить в трех вариантах (обычная, уменьшенная, увеличенная)