Читайте также:
|
ИНТАЛЕВ: Корпоративный навигатор (ИНТАЛЕВ)
ИНТАЛЕВ: Корпоративный навигатор позволяет осуществить системную оптимизацию и развитие системы управления организацией. Продукт признан и сертифицирован основоположниками системы сбалансированных показателей — компанией Balanced Scorecard Collaborative Inc. (США).
Система предоставляет собой платформу и набор уже готовых комплектов решений управленческих задач, т.е. по сути управленческих шаблонов. Каждый из комплектов предназначен для решения определенной бизнес-задачи: построения стратегии, разработки финансовой структуры и т.д. Комплекты легко интегрируются между собой, позволяя разработать единую систему управления организации: от стратегии до должностной инструкции отдельного менеджера.
ОРГ-Мастер Про (Бизнес Инжиниринг Групп)
ОРГ-МАСТЕР ПРО предназначен для решения широкого спектра задач бизнес-моделирования.
Программный продукт ОРГ-МАСТЕР позволяет разрабатывать системы целей и показателей, систему бизнес-процессов, финансовую, информационную, организационную структуры и прочее.
При проектировании данные могут быть представлены в виде иерархических справочников, проекций (отражающих взаимосвязи между справочниками), диаграмм. Для бизнес-процессов поддерживается разработка диаграмм в нотациях IDEF, Cross Functional Flowchart, EPC (Event-Driven Process Chain). Возможно построение организационных диаграмм и диаграмм собственного типа.
Бизнес-Инженер (Битек)
Бизнес-инженер является профессиональным инструментальным средством моделирования деятельности предприятия и разработки регламентирующих документов.
Он поддерживает полный цикл проектирования организации: от разработки стратегии, ключевых показателей и бизнес-процессов до анализа и оптимизации оргструктуры, повышения эффективности персонала, проектов, построения системы менеджмента качества, финансов и информационной системы предприятия.
Система позволяет разрабатывать бизнес-модели, а также формировать на их основе аналитические отчеты и регламентирующую документацию по различным направлениям: стратегия, бизнес-процессы, персонал и т.д.
2.2 Обзор методологии моделирования бизнес-процессов
Классические стандарты DFD и WFD содержат набор символов или обозначений, с помощью которых описывается бизнес-процесс. Эти обозначения принято называть языком или методологией описания процессов. В данном случае этот язык или методология являются классическими.
В настоящее время в мире появилось много других языков или методологий описания бизнес-процессов, содержащих несколько иные обозначения. Причем каждая методология содержит свой язык и имеет свое название. В настоящее время это приводит к некоторому замешательству среди конечных пользователей, которые данные технологии применяют на практике в своей организации. Отсюда возникает кажущаяся сложность применения процессных технологий.
На самом деле, несмотря на свое различие, в основном связанное с названием диаграмм и видов используемых объектов современные методологии описания бизнес-процессов практически идентичны и представляют из себя незначительные видоизменения двух классических схем - DFD и WFD – Work Flow Diagram, которые были рассмотрены.
Давайте рассмотрим другие современные языки описания бизнес-процессов:
· IDEF0;
· DFD в нотациях Гейна-Сарсона и Йордана-Де Марко;
· IDEF3;
· Oracle;
· BAAN;
· ARIS.
· Swimmer lanes;
Первая распространенная методология, которая будет рассмотрена это IDEF0. Этот язык придумали американские военные с целью успешного тиражирования бизнес-процессов предприятий аэрокосмической промышленности. В свое время американские военные столкнулись со следующей проблемой. При проектировании заводов было замечено, что каждый раз приходится заново проделывать один и тот же шаг - проектировать одинаковые подсистемы управления, на что уходило дополнительное время и ресурсы. После этого было предложено разработать язык или чертеж, с помощью которого можно было бы описать типовые подсистемы управления и при строительстве нового завода использовать наработанные схемы. Язык, который был придуман и использован для этих целей лег в основу методологии описания бизнес-процессов IDEF0.
Стандарт описания бизнес-процесса IDEF0.
Следующий стандарт описания бизнес-процессов, который получил распространение, был разработан на основе развития классической методологии DFD. Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна Сарсона, вторая нотацией Йордона-Де Марко.
Гейн Сарсон, предложил классическую DFD-схему немного усложнить. Он предложил ввести дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых хранится информация, либо материальные ресурсы. Примерами таким мест являются архив, в котором хранятся документы, база данных, в которой хранится информация, либо склад, на котором хранятся материальные ресурсы. Данный объект получил название - хранилище данных. На DFD-схемах в нотациях Гейна-Сарсона и Йордона-Де Марко также используются объекты, с помощью которых показывают внешних субъектов, с которыми бизнес-процесс взаимодействует. Данные объекты называют внешними сущностями. На рис. 5 приведен пример DFD-схемы бизнес-процесса "Оформлении и выдача трудовой книжки сотруднику при увольнении", разработанной в нотации Гейна-Сарсона.
DFD схема бизнес-процесса.
Стандарт IDEF0, который был рассмотрен ранее является развитием классического DFD – подхода и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.
Стандарт IDEF3 предназначен для описания бизнес-процессов нижнего уровня и содержит объекты – логические операторы, с помощью которых показывают альтернативы и места принятия решений и в бизнес-процессе, а также объекты – стрелки с помощью которых показывают временную последовательность работ в бизнес-процессе.
Схема бизнес-процесса в стандарте IDEF3.
При описании бизнес-процессов с использованием методологии ORACLE наиболее часто применяется вторая согласно перечню таблицы 5 модель бизнес-процессов. Построение этой модели основано на подходе "Swimmer lanes", который представляет из себя смесь классических DFD и WFD стандартов и имеет одну отличительную особенность. Диаграмма, на котором рисуется схема бизнес-процесса разделена по горизонтали на дорожки. Каждая дорожка принадлежит определенному структурному подразделению или должности, участвующей в бизнес-процессе. Те операции бизнес-процесса, которые выполняются этим структурным подразделением, размещаются в зоне соответствующей дорожки. Такой подход позволяет наглядно показать распределение ответственности в бизнес-процессе и продемонстрировать степень его организационной фрагментарности.
Пример описания бизнес-процесса на Oracle.
Одной из современных методологий бизнес-моделирования, получившей широкое распространение в России является методология ARIS, которая расшифровывается как Architecture of Integrated Information Systems - проектирование интегрированных информационных систем. Ее использует программное средство ARIS Toolset
Методология ARIS на данный момент времени является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации.
Модель «Дерево» бизнес-процесса – ARIS.
2.3 Архитектура Java
На сегодняшний день создание программного обеспечения представляет собой чрезвычайно тяжелое занятие.
Компилятор Java производит байт-коды, т.е. модули приложения имеют архитектурно-независимый формат, который может быть проинтерпретирован на множестве разнообразных платформ. Это уже не исходные тексты, но еще не платформно-зависимые машинные коды.
Нейтральность к архитектуре. Достигается прежде всего стандартизацией "бинарного формата кодов". Промежуточный код не зависит от конкретной аппаратной платформы, операционной системы и типа оконного интерфейса. Для того, чтобы программы, написанные на Java, могли работать на данной аппаратно-программной платформе, достаточно, чтобы для нее была создана лишь соответствующая виртуальная машина.
Компилятор Java производит не "машинные коды" подобно тому, как это делает, например, компилятор языка С. Вместо этого генерируются так называемые байт-коды: высокоуровневые машиннонезависимые коды для абстрактной машины, которая должна быть реализована в виде интерпретатора Java и run-time системы.
Сама по себе идея байт-кодов не нова, они широко используются в различных системах начиная с середины семидесятых годов. Особенности Java байт-машины следующие:
Переносимость на другие архитектуры.Кроме независимости кодов от конкретной архитектуры Java жестко специфицирует формат базовых типов данных. Без этого одна и та же программа, скомпилированная для разных аппаратных платформ, вела бы себя по-разному. Например, стандарт С/С++ не предусматривает конкретного представления для целого типа int. Предполагается, что этому типу соответствует основной формат машинного слова для данной архитектуры. В результате программа, написанная для 32-разрядного процессора, чаще всего переносится на 16-разрядную архитектуру с очень большими усилиями.
Архитектура Java не позволяет случайно или намеренно повредить память программы. Вместо арифметики указателей Java использует полноценные объекты для массивов и строк, что позволяет контролировать индексы доступа к ним во время выполнения. Кроме того, невозможны превращения между целыми числами и указателями.
Естественно, что все это не может полностью гарантировать программиста от любых ошибок, однако, Java устраняет целый класс их, существенно облегчая задачу разработчика.
Система Java достаточно безопасна, чтобы жить в сетевом окружении. Нейтральность к архитектуре и переносимость делают ее достаточно привлекательной для создания распределенных по сети приложений.
Встроенная многопотоковость - существенная черта архитектуры Java. Стандартная библиотека включает в себя класс Thread, с методами, позволяющими стартовать новый поток, завершить его работу и проверить текущее состояние потока.
2.4 Spring Framework
Spring Framework (или коротко Spring) — универсальный фреймворк с открытым исходным кодом для Java-платформы. Также существует форк для платформы.NET Framework, названный Spring.NET.
Фреймворк был впервые выпущен под лицензией Apache 2.0 license в июне 2003 года. Первый стабильный релиз 1.0 был выпущен в марте 2004. Spring 2.0 был выпущен в октябре 2006, Spring 2.5 — в ноябре 2007, Spring 3.0 в декабре 2009, и Spring 3.1 в декабре 2011. Текущая версия — 4.0.
Несмотря на то, что Spring Framework не обеспечивал какую-либо конкретную модель программирования, он стал широко распространённым в Java-сообществе главным образом как альтернатива и замена модели Enterprise JavaBeans. Spring Framework предоставляет бо́льшую свободу Java-разработчикам в проектировании, кроме того, он предоставляет хорошо документированные и лёгкие в использовании средства решения проблем, возникающих при создании приложений корпоративного масштаба.
Spring Framework обеспечивает решения многих задач, с которыми сталкиваются Java разработчики и организации, которые хотят создать информационную систему, основанную на платформе Java. Из-за широкой функциональности трудно определить наиболее значимые структурные элементы, из которых он состоит. Spring Framework не всецело связан с платформой Java Enterprise, несмотря на его масштабную интеграцию с ней, что является важной причиной его популярности.
Spring Framework, вероятно, наиболее известен как источник расширений (features), нужных для эффективной разработки сложных бизнес-приложений вне тяжеловесных программных моделей, которые исторически были доминирующими в промышленности. Ещё одно его достоинство в том, что он ввел ранее неиспользуемые функциональные возможности в сегодняшние господствующие методы разработки, даже вне платформы Java.
Этот фреймворк предлагает последовательную модель и делает её применимой к большинству типов приложений, которые уже созданы на основе платформы Java. Считается, что Spring Framework реализует модель разработки, основанную на лучших стандартах индустрии, и делает её доступной во многих областях Java.
Spring Framework может быть рассмотрен как коллекция меньших фреймворков или фреймворков во фреймворке. Большинство этих фреймворков может работать независимо друг от друга, однако, они обеспечивают большую функциональность при совместном их использовании. Эти фреймворки делятся на структурные элементы типовых комплексных приложений:
· Inversion of Control-контейнер: конфигурирование компонентов приложений и управление жизненным циклом Java-объектов.
· Фреймворк аспектно-ориентированного программирования: работает с функциональностью, которая не может быть реализована возможностями объектно-ориентированного программирования на Java без потерь.
· Фреймворк доступа к данным: работает с системами управления реляционными базами данных на Java-платформе, используя JDBC- и ORM-средства и обеспечивая решения задач, которые повторяются в большом числе Java-based environments.
· Фреймворк управления транзакциями: координация различных API управления транзакциями и инструментарий настраиваемого управления транзакциями для объектов Java.
· Фреймворк MVC: каркас, основанный на HTTP и сервлетах, предоставляющий множество возможностей для расширения и настройки (customization).
· Фреймворк удалённого доступа: конфигурируемая передача Java-объектов через сеть в стиле RPC, поддерживающая RMI, CORBA, HTTP-based протоколы, включая web-сервисы (SOAP).
· Фреймворк аутентификации и авторизации: конфигурируемый инструментарий процессов аутентификации и авторизации, поддерживающий много популярных и ставших индустриальными стандартами протоколов, инструментов, практик через дочерний проект Spring Security (ранее известный как Acegi).
· Фреймворк удалённого управления: конфигурируемое представление и управление Java-объектами для локальной или удалённой конфигурации с помощьюJMX.
· Фреймворк работы с сообщениями: конфигурируемая регистрация объектов-слушателей сообщений для прозрачной обработки сообщений из очереди сообщений с помощью JMS, улучшенная отправка сообщений по стандарту JMS API.
· Тестирование: каркас, поддерживающий классы для написания модульных и интеграционных тестов.
Spring предоставляет свой слой доступа к базам данных и поддерживает все популярные базы данных.
JDBC, iBatis / MyBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, Apache Cayenne и т. д.
Для всех этих фреймворков, Spring предоставляет такие особенности:
· Управление ресурсами — автоматическое получение и освобождение ресурсов базы данных
· Обработка исключений — перевод исключений при доступе к данным в исключения Spring-а
· Транзакционность — прозрачные транзакции в операциях с данными
· Распаковка ресурсов — получение объектов базы данных из пула соединений
· Абстракция для обработки BLOB и CLOB
2.5 Алгоритм бизнес-процессов.
Алгоритм — это конечный набор правил, который обладает пятью важными чертами: конечность, определённость, ввод, вывод, эффективность.
Исходя из определений бизнес-процесса и алгоритма, становится очевидным, что необходимые атрибуты любого бизнес-процесса практически полностью повторяют атрибуты алгоритма, демонстрируя их тождественность. Действительно, основные атрибуты, а также само графическое представление бизнес-процесса наталкивают на мысль, что описываемые структуры могут обладать не только схожими атрибутами, но и схожими свойствами.
Кроме того, тождественность двух рассматриваемых понятий проявляется в той роли, которую они играют в реализованных программных решениях: бизнес-процесс — это ядро BPM-приложения, определяющее его поведение, в то время как алгоритм выполняет аналогичную функцию в приложениях, написанных с помощью языков программирования.
В качестве доказательства близкого сходства, почти тождественности, понятий «бизнес-процесс» и «алгоритм» на рисунке 1 приведено графическое представление реального бизнес-процесса. Рассматриваемый в данной статье бизнес-процесс представляет собой упрощенный процесс согласования кредитной заявки в банке, цель заключается в проведении заявки на получение кредита, созданной пользователем путем заполнения форм, через все этапы согласования. На основе диаграммы этого бизнес-процесса создается полноценное автоматизирующее его приложение, которое разворачивается на сервере приложений. Все пользовательские действия выполняются в рабочем пространстве, также развернутом на сервере приложений и доступном для пользователей через браузер. Взаимодействие пользователя с приложением осуществляется с помощью экранных форм. На практике данный процесс автоматизирован с помощью продукта Oracle BPM 11g.
При анализе и моделировании бизнес-процесса становится все более и более очевидной его схожесть с понятием алгоритма. Поскольку основные свойства рассматриваемых понятий совпадают, то можно предположить, что применение методов оценки и оптимизации алгоритмов к бизнес-процессам может дать положительные результаты.
Следует отметить, что для большинства бизнес-процессов, на которых построена деятельность предприятия или организации, обладают одной общей чертой: их концепция заключается во введении первичных данных и их согласовании в виде переходов от одного этапа к другому с возможностью редактирования. Таким образом, представляется возможным выделение общей модели бизнес-процесса.
Очевидно, что представленной в виде схемы алгоритм, построенный на основе бизнес-процесса, является рекурсивным.
BEGIN
AP
if (!Действие1 подтверждено) {
Редактировать1
Подтверждение действия
}elseif (!Действие2 подтверждено) {
Редактировать2
Подтверждение действия
}elseEND
Наличие общих атрибутов у понятий алгоритма и бизнес-процесса, а также возможность выделения из бизнес-процесса рекурсивной модели говорит о возможности рассмотрения процесса как алгоритма, а значит и применения к нему методов оценки эффективности и оптимизации, характерных для алгоритмов.
Наиболее важным этапом создания приложения на основе бизнес-процессов является этап моделирования бизнес-процесса. Любая ошибка, допущенная на данном этапе, приводит к возникновению проблем, возникающий во время эксплуатации приложения, например, к необходимости выполнения пользователями лишних действий, увеличению времени исполнения бизнес-процесса, нерациональному использованию аппаратно-программных средств и т. д. Избежать этих проблем можно только путем применения на этапе моделирования каких-либо методов оценки эффективности и выполнения оптимизации бизнес-процессов. В связи со всем вышесказанным, такими методами могут стать методы оценки эффективности и проведения оптимизации алгоритмов. Одним из этапов поиска этих методов является попытка выделения из бизнес-процесса рекурсивной модели.
Следующий шаг после успешного выделения рекурсивной модели — оценка сложности алгоритма. Именно на этом шаге дают о себе знать все отличительные особенности бизнес-процесса с человеческим участием: мы не можем определить точное количество рекурсивных вызовов, то есть, в нашем случае, количество раз, когда один из участников процесса отправляет заявку на кредит на шаг редактирования. Поскольку количество рекурсивных вызовов напрямую влияет на сложность алгоритма, данная особенность не позволяет точно ее вычислить. Тем не менее, представляется вполне возможной приближенная оценка: так как на приведенном мной в качестве примера бизнес-процессе основывается работоспособное приложение, можно собрать статистические данные по его работе, выделить среднее количество рекурсивных вызовов в каждом конкретном случае и оценить сложность алгоритма. Полученная таким способом информация послужит основой для поиска так называемых «узких мест» бизнес-процесса и его последующей оптимизации. Например, если деятельность одного из участников бизнес-процесса порождает большое количество рекурсивных вызовов, следует задуматься о квалификации участников процесса, которым назначена эта роль. Следует отметить, что описанная таким образом методика применима не только к оценке бизнес-процесса, состоящего исключительно из пользовательских действий, как описано в данной статье, но и к процессу, содержащему автоматические действия: включение автоматических действий в рассматриваемый процесс даст возможность сделать выводы об эффективности работы аппаратно-программных средств, выступающих в качестве платформы для BPM-приложения.
3 СРЕДА РАЗРАБОТКИ NETBEANS IDE
NetBeans IDE - свободная интегрированная среда разработки приложений на языках программирования Java, JavaFX, Python, PHP, JavaScript, C, C++ и ряда других.
Проект NetBeans IDE поддерживается и спонсируется компанией Oracle, однако разработка NetBeans ведется независимым сообществом разработчиков-энтузиастов (NetBeans Community) и компанией NetBeans Org.
По качеству и возможностям последние версии NetBeans IDE не уступают лучшим коммерческим (платным) интегрированным средам разработки для языка Java, таким, как IntelliJ IDEA, поддерживая рефакторинг, профилирование, выделение синтаксических конструкций цветом, автодополнение набираемых конструкций на лету, множество предопределённых шаблонов кода и др.
Для разработки программ в среде NetBeans и для успешной инсталляции и работы самой среды NetBeans должен быть предварительно установлен Sun JDK или J2EE SDK подходящей версии - это исполнительные среды Java, в которых выполняются программы. Среда разработки NetBeans по умолчанию поддерживала разработку для платформ J2SE и J2EE. Начиная с версии 6.0 Netbeans поддерживает разработку для мобильных платформ J2ME, C++ и PHP без установки дополнительных компонентов.
3.1 Параметры исполнительного сервера
Неотъемлемой частью клиент-серверного приложения является сам сервер, в нашем случае необходим определенный набор программного обеспечения - это веб-сервер для возможности подключения и аутентификации пользователей, СУБД для работы с базой данных и PHP для обработки запросов пользователей. Существует множество вариантов сборок вышеуказанного программного обеспечения, но для себя я выбрал самый простой в установке и использовании и к тому же полностью бесплатный сервер LAMP.- акроним, обозначающий набор серверного программного обеспечения, широко используемый во Всемирной паутине. LAMP назван по первым буквам входящих в его состав компонентов:- операционная система Linux;- веб-сервер;- СУБД;- язык программирования, используемый для создания веб-приложений (помимо PHP могут подразумеваться другие языки, такие как Perl и Python).
Хотя изначально эти программные продукты не разрабатывались специально для работы друг с другом, такая связка стала весьма популярной из-за своей гибкости, производительности и низкой стоимости (все её составляющие являются открытыми и могут быть бесплатно загружены из Интернета). Набор LAMP входит в состав большинства дистрибутивов Linux и предоставляется многими хостинговыми компаниями.
Так как в начальном этапе работы клиент - серверного приложения, сервер будет обслуживать лишь двух клиентов, нам не столь важен выбор комплектующих сервера, поэтому было принято решение об установки бесплатно виртуальной машины Oracle VM VirualBox на рабочую станцию с четырехъядерным процессором Intel Core i3 2.40Ghz и тремя гигабайтами оперативной памяти под управлением ОС Windows XP x86.
Условие задачи:
Программа должна обеспечивать ввод и корректировку информации, а по запросу - поиск следующей информации:
1. Название организации, предприятия, компании;
2. Контактные данные (офисный телефон, номер факса или же электронную почту);
3. Сфера деятельности
Область применения: может быть применена в качестве дополнительного заработка или как помощь в выполнении некоторых задач
В данной задаче входными данными являются данные, вводимые с клавиатуры компьютера.
Выходными данными является результат работы программы.
Поскольку ставится задача разработать приложение для Windows, то использоваться программа может под управлением Windows 7, Windows 8.
При решении данной задачи необходимо использовать интегральную среду разработки программ Delphi 7, так как среда Delphi 7 позволяет достаточно быстро разрабатывать приложения для Windows.
Технические характеристики компьютера:
· Pentium IV и выше;
· Объем оперативной памяти не менее 512 Мб;
· Жесткий диск объемом не менее 1 Гб.
Именно эти параметры создают условия для полноценной работы IDE Delphi 7 и программ, созданных в этой среде.
Дополнительных средств (принтер, сканер, дополнительные дисководы и т.д.) не требуется.
Для начала необходимо определить правила приложения согласованно с предприятием, в данном случае пользователю будет предоставляться возможность выбора между заказчиком и тем, кто выполняет задачу.
4 ЭТАП ПРОЕКТИРОВАНИЯ
4.1 Клиентская часть
Для разработки приложения необходимо определить основные положения в приложении.
1. Исполнитель – тот, кто регистрируется, заполнив все необходимые данные и откликается на определенную задачу.
2. Заказчик – тот, кто создает задание, при этом указывая срок и цену за выполнения данной задачи.
3.Пользователь, в лице предприятия имеет возможность просматривать стратегии касательно своих бизнес-процессов и видеть историю выполнений своих задач.
4.2 Серверная часть
Для реализации серверной части приложения понадобился сервер LAMP со стандартным набором программного обеспечения, установленный на виртуальную машину. В качестве сервера выступает ноутбук, на который установлена виртуальная машина под управлением операционной системы Ubuntu Server 12.10. Преимущество виртуальной машины перед реальной заключается в том, что в любой момент ее можно интегрировать на любую платформу с любой комплектацией. Это и явилось причиной выбора в пользу виртуальной машины.
ЗАКЛЮЧЕНИЕ
В заключении хочется подчеркнуть, что главное достоинство идеи анализа бизнес-процессов предприятия посредством создания его модели – ее универсальность. Во-первых, моделирование бизнес-процессов это ответ практически на все вопросы, касающиеся совершенствования деятельности предприятия и повышения его конкурентоспособности. Во-вторых, руководитель или руководство предприятия, внедрившие у себя эту методологию, будут иметь информацию, которая позволит самостоятельно совершенствовать свое предприятие и прогнозировать его будущее.
Так же в ходе проделанной работы были исследованы различные программные обеспечения и сферы деятельности с повышенным интересом к моделированию бизнес-процессов. Были рассмотрены все финансовые и технологические стороны, приняты в учёт все недоработки и проблемы, с которыми столкнулись разработчики других ПО.
При разработке программного обеспечения были выявлены и исправлены все ошибки. Программа была установлена и протестирована.
Таким образом, можно говорить о том, что поставленные задачи были выполнены в полной мере.
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Вендров А.М. Методы и средства моделирования бизнес-процессов (обзор) http://www.jetinfo.ru/2004/10/1/article1.10.2004.html
2. http://staratel.com/iso/ISO9000/Article/ConImp/ContImprove.htm
3. http://www.cfin.ru/itm/bpr/idef0_bpr.shtml
4. Швецов В.И., Визгунов А.Н., Мееров И.Б. Базы данных. Учебное пособие. Нижний Новгород: Изд-во ННГУ, 2004. 217 с
5. http://www.citycg.ru/services/business-process/metody-opisanija-processov/
6. http://ooad.asf.ru/standarts/Library/ReviewPO/List06.aspx
7. http://www.kpms.ru/General_info/BPM.htm
8.http://www.cfin.ru/software/kis/b-model.shtml
9. http://www.connect.ru/article.asp?id=5956
10. http://compress.ru/article.aspx?id=18417
ПАРАМЕТРЫ РАЗВИТИЯ РЕБЁНКА И ИХ ПОНИМАНИЕ В РАЗНЫХ НАУЧНЫХ КОНЦЕПЦИЯХ
Дата добавления: 2014-12-20; просмотров: 131 | Поможем написать вашу работу | Нарушение авторских прав |