74. Понятие case-средств.

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

В настоящее время существует множество CASE средств, поддерживающих функциональное моделирование в стандарте IDEF0. В России получили распространение следующие системы:

1. Design/IDEF

2. BPWin/ERWin

3. IDEF0/EMTool

Важным свойством современного программного обеспечения, применяемого для моделирования в стандарте IDEF0, является возможность детального описания элементов модели, а именно:

1. модели в целом (название, автор, точка зрения, цель моделирования, область моделирования, стадия моделирования и пр.);

2. диаграмм;

3. процессных блоков (название/индекс, описание, формулы и пр.);

4. стрелок (название/индекс, описание, формулы и пр.);

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

1. Классификация по выполняемым функциям.

2. Классификация по типам процессов разработки, которые они поддерживают.

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

75. Направление применения case-средств.

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

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

76. Классификация case-средств на основе функциональной ориентации.

1. анализ и проектирование

2. проектирование БД и файлов

3. программирование

4. сопровождение и реинжиниринг

5. поддержка окружения

6. управление проектами

77. Принцип выбора case-систем.

Принцип выбора case-систем основывается на определённых критериях:

1. критерии оценки и отбора функциональных характеристик продукта

2. критерии оценки и отбора технологий

3. критерии оценки функций, реализованных в продукте

4. критерии оценки тестирования

5. критерии оценки возможности документирования

6. критерии оценки возможности управления проектом

78. Понятие графической нотации.

Графическая нотация – это набор объектов и правил, которые устанавливают отношения между этими объектами.

Нотация состоит из:

- набора графических объектов

- набора текстовых объектов

- определённых отношений между этими объектами

79. Понятие стандарта с применением графической нотации.

Типичным примером стандарта с применением графической нотации служит IDEF0,

графическая нотация – это набор объектов и правил, которые устанавливают отношения между этими объектами.

Нотация состоит из:

- набора графических объектов

- набора текстовых объектов

- определённых отношений между этими объектами

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

80. Основные процессы в системе и подходы к их описанию.

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

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

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

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

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

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

Существует довольно много методологий моделирования, используемых сегодня при описании бизнес-процессов. К наиболее популярным из них можно отнести методологию DFD (Data Flow Diagrams), описывающую диаграммы потоков данных, которые используются при  анализе требований и функциональном проектировании информационных систем; STD (State Transition Diagram), рассматривающую диаграммы перехода состояний для проектирования систем реального времени; ERD (Entity-Relationship Diagrams), раcсматривающую диаграммы «сущность — связь», которые применяются при логическом проектировании информационных систем; FDD (Functional Decomposition Diagrams), описывающую диаграммы функциональной декомпозиции; SADT (Structured Analysis and Design Technique), представляющую собой довольно популярную в 90-х годах технологию структурного анализа и проектирования. В последнее время популярна также методология ARIS, рассматривающая совокупность различных типов моделей (включая и поддерживаемые некоторыми другими методологиями), которые используются для описания всех подсистем компании. Не менее популярно и семейство методологий IDEF, применяемых для проектирования бизнес-процессов и данных (разработчики баз данных, как правило, неплохо знакомы с методологией IDEF1X, описывающей логические и физические модели данных, а методология IDEF0 весьма популярна у аналитиков, описывающих бизнес-процессы). У разработчиков приложений очень популярна методология UML (Unified Modelling Language), используемая при проектировании информационных систем и приложений с целью описания требований к информационной системе, сценариев работы пользователей, изменения состояний системы и данных в процессе работы и классов будущего приложения. 

Моделирование бизнес-процессов используется на практике для решения широкого спектра задач. Один из наиболее типичных способов применения подобных моделей — это совершенствование самих моделируемых процессов. На практике производится описание процессов «как есть» (то есть именно так, как они происходят в действительности), а затем различными способами выявляются узкие места в этих процессах и на основе данного анализа создается несколько моделей «как должно быть».

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

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

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

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

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

Перечисленными задачами далеко не исчерпывается область применения моделирования бизнес-процессов — здесь приведены лишь некоторые примеры использования этого вида моделирования.