Размещено на http://www.allbest.ru/

1

Оглавление

• Введение
• 1. Постановка задачи
• 1.1 Анализ требований к системе
• 2. Обоснование выбора инструментальных средств
• 3. Функциональная декомпозиция системы
• 3.1 Описание предметной области
• 3.2 Построение контекстной диаграммы
• 3.3 Декомпозиция контекстной диаграммы
• 3.4 Создание диаграммы декомпозиции в нотации DFD
• 3.5 Создание диаграммы декомпозиции в нотации IDEF3
• 3.6 Построение ролевой диаграммы
• 4. Функционально-стоимостной анализ процесса

программный декомпозиция контекстный диаграмма

Введение

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

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

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

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

- Vantage Team Builder (Westmount I-CASE);

- Designer/2000;

- Silverrun;

- ERwin+BPwin;

- S-Designor;

- CASE.Аналитик;

- Rational Rose.

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

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

Объектом исследования является деятельность магазина одежды.

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

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

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

- сведения о самих программах, их поставщиках, покупателях;

- учёт наличия программ, приходящих от разных поставщиков;

- оформление договоров с поставщиками и покупателями;

- сбор статистики о продажах и обновление данных на сайте организации.

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

1.1 Анализ требований к системе

Требование к выполнению функций:

- работа в режиме реального масштаба времени;

- обеспечение надежности функционирования системы и защиты от сбоев;

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

- обеспечение понятного интерфейса.

Функции, выполняемые программой:

- добавление, удаление, редактирование данных о товарах, сотрудниках, поставщиках;

- добавление, удаление, редактирование данных заказа клиента;

- просмотр и печать отчетов об уровне продаж.

Требование к надежности:

- разграничение прав доступа работы с данными;

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

- обеспечить целостность хранимой информации в базе данных.

Требования к составу и параметрам технических средств:

система должна работать на IBM совместимых персональных компьютерах.

Минимальная конфигурация:

- тип процессора - Pentium 2 и выше;

- объем оперативного запоминающего устройства - 256 Мб и более;

- жесткий диск - 80 Гб и более;

- система охлаждения - любая (подходящая под разъем процессора);

- принтер;

- сетевая карта D-link DGE-528T 10/100/1000 Мбит/c;

- монитор.

Требования к информационной и программной совместимости:

Система должна работать под управлением семейства операционных систем Windows XP\Vista\7.

2. Обоснование выбора инструментальных средств

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

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

Ниже представлены основные характеристики этих программных средств.

1. Visio - наиболее простое и доступное средство моделирования процессов. Этот продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей. Однако для временного или стоимостного анализа требуется разработка отчетов, что значительно усложняет использование этого продукта. Типовые отчеты явно не достаточны для анализа бизнес-процессов. Несмотря на это, Visio является распространенным средством для описания бизнес-процессов как в России, так и за рубежом. Visio поддерживает IDEF и UML форматы для описания бизнес-процессов. Возможна также самостоятельная разработка форматов.

2. ARIS рассматривает предприятие как совокупность четырех взглядов (views):

- взгляд на организационную структуру;

- взгляд на структуру функций;

- взгляд на структуру данных;

- взгляд на структуру процессов.

ARIS позволяет составлять диаграмму целей, связывая процессы через цели с миссией компании. В результате после построения бизнес-модели получается комплексное видение компании: Цели - Процессы - Оргструктура - Данные - Продукты/услуги в виде отдельных, но связанных через объекты диаграмм. Это означает, что при изменении названия должности на одной диаграмме сразу корректируются названия во всех процессах, где она присутствует, и в оргструктуре.

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

- описание требований;

- описание спецификации;

- описание внедрения.

ARIS предлагает рассматривать организацию с позиции 4-х аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-среды предлагается использовать 85 типов моделей (обычно в практической деятельности применяется не более 6-7 типов моделей), каждая из которых принадлежит тому или иному аспекту. ARIS Toolset является, с одной стороны, достаточно сложной для освоения системой. С другой стороны, диаграммы бизнес-процессов в готовом виде понятны даже неподготовленным сотрудникам, это позволяет эффективно организовывать работу команд, не прибегая к тотальному обучению всех работающих над проектом сотрудников.

3. Rational Rose - CASE-средство фирмы Rational Software Corporation (США), предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанный ими универсальный язык для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Delphi, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

При выполнении курсового проекта мною были использованы CASE-средства компании Computer Associates (CA). СА предлагает полный набор программных средств, обеспечивающих эффективное управление, анализ, проектирование и кодогенерацию информационных систем.

Для проведения анализа и реорганизации бизнес-процессов СА предлагает CASE - средство верхнего уровня - BPwin, поддерживающий методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).

На основе модели BPwin с помощью мощного и удобного инструмента ERwin можно построить модель данных. ERwin позволяет проводить процессы прямого и обратного проектирования более чем для 20 СУБД различных производителей. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того, либо другого. ERwin интегрируется с популярными средствами разработки клиентской части, в том числе с Borland Delphi , что позволяет автоматически генерировать код приложения, который готов к компиляции и выполнению.

3. Функциональная декомпозиция системы

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

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

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

2 клиентские подразделения:

1. организация взаимодействия с Клиентом;

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

- юридические подразделения:

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

- учет товаров:

1. учет поступления товаров в розницу;

2. учет реализации товаров;

3. учет перемещения товаров между структурными подразделениями;

4. учет возврата товаров поставщику;

5. учет инвентаризации товаров;

6. учет списания товаров.

3.2 Построение контекстной диаграммы

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

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

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

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

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

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

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

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

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

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

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

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

- управление: нормативно-правовая база;

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

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

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

Таблица 1 - Описание стрелок контекстной диаграммы

Имя стрелки	Определение стрелки	Тип стрелки
Информация о одежде	Информация о продаваемом товаре и т.д.	Input
Информация о поставщиках	Информация о поставщиках, цены, контакты т.д.	Input
Маркетинговый анализ	Данные о потребностях потенциальных клиентов	Input
Кассир	Работа с продажами т.д.	Mechanism
Бухгалтер	Работа с деловой и экономической документации	Mechanism
Руководитель	Работа с поставщиками и т.д.	Mechanism
Нормативно-правовая база	Правила продаж, правила оформления документации и т.д.	Control
Оборотно-сальдовая ведомость	Остатки товара, прибыль т.д.	Output
Информация о следующем заказе товара	Данные о следующем заказе и т.д.	Output

Контекстная диаграмма "Деятельность магазина одежды" представлена на рисунке 1.

Рисунок 1 - Контекстная диаграмма

3.3 Декомпозиция контекстной диаграммы

IDEF0-модели несут в себе сложную и подробную информацию.

При декомпозиции контекстной диаграммы выделим три основные работы (активности), перечисленные в таблице 2.

Таблица 2 - Работы диаграммы декомпозиции А0

Имя работы	Определение
Предпродажа(А1)	Подготовка товара к продаже, формирование ассортимента
Продажа(А2)	Продажа товара
Формирование результатов(А3)	Формирование результатов работ, формирование последующего плана.

Декомпозиция контекстной диаграммы представлена на рисунке 2.

Рисунок 2 - Создание диаграммы декомпозиции А0

Для построения декомпозиции диаграммы А3 выделим три основные работы (активности), перечисленные в таблице 3.

Таблица 3 - Работы диаграммы декомпозиции А3

Имя работы	Определение
Ведение деловой документации(А3.1)	Ведение документации для налоговой отчетности и т.д.
Поставки(А3.2)	Товар от поставщиков, затраты и т.д.
Формирование следующего заказа(А3.3)	Формирование последующего заказа товара на продажу

Таблица 4- Стрелки диаграммы декомпозиции А3

Имя стрелки	Источник стрелки	Тип источника	Назначение стрелки
Результаты продаж	Границы диаграммы	Input	Обработка результатов продаж
Информация о поставщиках	Границы диаграммы	Input	Обработка информации о поставщиках
Маркетинговый анализ	Границы диаграммы	Input	Консультации с специалистами
Бухгалтер	Границы диаграммы	Mechanism	Ведение документации
Руководитель	Границы диаграммы	Mechanism	Переговоры с поставщиками и с специалистами
Нормативно-правовая база	Границы диаграммы	Control	Ведение законной документации
Поставщики	Поставки	Input	Переговоры с поставщиками
Имя стрелки	Источник стрелки	Тип источника	Назначение стрелки
Оборотно-сальдовая ведомость	Ведение деловой документации	Output	Граница диаграммы
Информация о следующем заказе	Формирование следующего заказа	Output	Граница диаграммы

Результат выполнения всех действий показан на рисунке 3.



Рисунок 3 - Результат построения диаграммы декомпозиции А3

3.4 Создание диаграммы декомпозиции в нотации DFD

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

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

В новую диаграмму DFD "Предпродажа" вносятся имена работ:

- обработка информация о поставщиках;

- обработка информация о товаре;

- обработка информация о заказах.

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

Используя кнопку на палитре инструментов, необходимо внести хранилища данных:

- База данных "Поставщики";

- База данных "Заказ";

- База данных "Товар".

Декомпозиция функции А1 "Предпродажа" представлена на рисунке 4.

Рисунок 4 - Декомпозиция функции А1 "Предпродажа"

3.5 Создание диаграммы декомпозиции в нотации IDEF3

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

Функция А2 "Продажа" реализуется следующими активностями:

- получение заявки на товар;

- проверка наличия товара на складе;

- получение товара со склада;

- получение платежа;

- выдача товара покупателю;

- закрытие сделки.

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

Таблица 5 - Типы перекрестков

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Асинхронное "И" (Asynchronous AND)	Все предшествующие процессы должны быть завершены.	Все следующие процессы должны быть запущены.
	Синхронное "И" (Synchronous AND)	Все предшествующие процессы должны быть завершены одновременно.	Все следующие процессы запускаются одновременно.
	Асинхронное "ИЛИ" (Asynchronous OR)	Один или несколько предшествующих процессов должны быть завершены.	Один или несколько следующих процессов должны быть запущены.
	Синхронное "ИЛИ" (Synchronous OR)	Один или несколько предшествующих процессов должны быть завершены одновременно.	Один или несколько следующих процессов запускаются одновременно.
	Исключающее "ИЛИ" XOR (Exclusive OR)	Только один предшествующий процесс завершен.	Только один следующий процесс запускается.

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

Рисунок 5 - Декомпозиция функции А2 "Продажа"

3.6 Построение ролевой диаграммы

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

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

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

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

Словарь ролевых групп представлен на рисунке 6.

Рисунок 6 - Словарь ролевых групп

Словарь ролей представлен на рисунке 7.

Рисунок 7 - Словарь ролей

Построение ролевой диаграммы представлено на рисунке 8.



Рисунок 8 - Построение ролевой диаграммы

Таблица 6 - Ролевые группы

Name	Definition	Importance
Персонал	Персонал выполняющий основную деятельность компании	Low
Управленческий отдел	Определяет план развития, представитель компании	High

4. Функционально стоимостной анализ процесса

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

АВС-метод включает следующие основные понятия:

- объект затрат - причина, по которой работа выполняется; обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат;

- движитель затрат - характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго длиться работа;

- центры затрат, которые можно трактовать как статьи расхода.

Для работ на диаграмме А1 "Деятельность магазина одежды" вносятся параметры ABC согласно таблице 7.

Таблица 7 - Центры затрат ABC

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

Стоимость и продолжительность работ на диаграмме "Деятельность магазина одежды" определяются и вносятся согласно таблице 8.

Таблица 8 - Стоимость и продолжительность работ

Диаграмма после внесения необходимых характеристик отображена на рисунке 9.

Рисунок 9 - Диаграмма с внесенными затратами

Общие затраты по работе рассчитываются как сумма по всем центрам затрат (рисунок 10).



Рисунок 10 - Общая стоимость затрат

Размещено на Allbest.ru