Файл: Проектирование и реализация операций бизнес-процесса «Ежедневный складской учет».pdf

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

Приведем три разные технологии создания информационных систем:

1) структурная;

2) объектно-ориентированная;

3) ориентированная на бизнес.

1) Структурный подход

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

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

- принцип "разделяй и властвуй";

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

- принцип иерархического упорядочивания;

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

Основными из этих принципов являются следующие:

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

-принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

- DFD (Data Flow Diagrams) диаграммы потоков данных;

- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь";

- STD;

- FDD;

- IDEF. :

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

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

2) Объективно-ориентированный подход

Методология RUP и диаграммы UML

Rational Unified Process (RUP) – одна из лучших методологий разработки программного обеспечения Основываясь на опыте многих успешных программных проектов, Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).

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

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

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

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

Основные процессы методологии RUP:

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

- анализ;

- проектирование;

- реализация;

- тестирование;

- заключение.

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

3) Ориентированная на бизнес (ARIS, eERS, VACD, PCDs, jCOM1)

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

Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы. Бизнес-инжиниринг состоит из моделирования бизнес-процессов (разработка модели "как есть", её анализ, разработка модели "как надо") и разработки и реализации плана перехода к состоянию "как надо".

Бизнес-модель - это формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов. Основная область применения бизнес-моделей - это реинжиниринг бизнес-процессов.

Этапы описания бизнес-процессов:

- определение целей описания;

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

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

- описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм;

- построение организационной структуры процесса (отделы, участники, ответственные).

Используемые методологии:

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

- eEPC — метод описания процессов;

- ERM — модель «сущность-связь» для описания структуры данных;

- UML — унифицированный объектно-ориентированный язык моделирования.

Технология ARIS Script позволяет в автоматическом режиме производить:

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

- формирование аналитических отчётов на основании моделей ARIS;

- интеграцию ARIS Toolset с другими приложениями и базами данных;

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

2. ПРОЕКТНАЯ ЧАСТЬ

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

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

- большая длительность процесса структурирования;

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

- ограничения сроков на разработку системы.

Выбираем структурный подход к разработке ИС.

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

Такая технология получила название CASE (Computer Aided Software Engeneering - создание программного обеспечения с помощью компьютера). Основные черты CASE - технологии:

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

- разработка прикладной системы этапов проектирования..

Как правило, CASE-системы поддерживают следующие этапы процесса разработки:

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

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

- реляционное моделирование - преобразование модели "сущность-связь" в соответствии с требованиями реляционной модели (реляционная модель допускает только бинарные связи);

- генерация схемы базы данных. Результатом выполнения данного этапа является набор SQL-операторов, описывающих создание схемы базы данных (CREATE TABLE, CREATE INDEX,...), с учетом особенностей целевой СУБД;

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

2.1 Описание предметной области (с построением диаграммы потоков данных с декомпозицией)

На первом этапе моделирования и анализе предметной области выбираем DFD-диаграмму с декомпозицией.

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

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

- хранить информацию о покупателях;

- печатать накладные на отпущенные товары;

- следить за наличием товаров на складе.

Следовательно на диаграмме должны присутствовать такие объекты как:

- покупатель;

- накладная;

- склад;

- товар.

Для построения DFD-диаграммы потоков данных выбираем нотацию Йордана (рис.2).

Товар

Покупатель

Накладная

Склад

Рис.2 – DFD диаграмма потоков данных

2.2 Жизненный цикл информационной системы

На следующем этапе моделируем жизненный цикл информационной системы.

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