Основы проектирования бизнес процессов

Сочинский государственный  университет 

Экономический факультет

Кафедра  «Менеджмент  организации»

КОНТРОЛЬНАЯ РАБОТА

По дисциплине

«Основы проектирования бизнес-процессов»

На тему:

Выполнила:

студент  4 курса 

группа  08-ЗМ-ДО

Рахимова Е.В.

Проверил:

Сочи, 2012

Содержание

Введение………………………………………………………………………………….3

1.Понятие CASE – средства……………………………………………………………..4

2. Технология освоения и внедрения CASE-средств…………………………………..6

3. Характеристика современных CASE-средств………………………………………12

Заключение………………………………………………………………………………20

Литература……………………………………………………………………………….23

Введение

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

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

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

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

1.Понятие CASE - средства

Многие организации-разработчики программного обеспечения информационных систем (ПО ИС), пытаясь внести усовершенствования в процесс разработки, обращаются к CASE-технологии. Согласно обзору передовых  технологий (Survey of Advanced Technology), составленному  фирмой Systems Development Inc. в 1996 г. по результатам  анкетирования более 1000 американских фирм, CASE-технология в настоящее  время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей  более чем в трети своих  проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные  возможности CASE-средств, существует множество  примеров их неудачного внедрения, в  результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи  с этим необходимо отметить следующее:

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

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

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

• Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;
• Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;
• Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

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

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

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

2.Технология освоения и внедрения CASE-средств

Современная технология освоения и внедрения CASE-средств базируется в основном на стандартах-рекомендациях IEEE (IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools и IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools). Процесс внедрения CASE-средств состоит из следующих этапов:

• определение потребностей в CASE-средствах;
• оценка и выбор CASE-средств;
• выполнение пилотного проекта;
• практическое внедрение CASE-средств.

С внедрением CASE-средств  обычно связывают большие ожидания. В ряде случаев эти ожидания оказываются  нереалистичными и приводят к  неудаче при внедрении. К таким  ожиданиям можно отнести следующие:

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

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

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

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

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

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

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

Оценка и накопление соответствующих  данных может выполняться следующими способами:

• анализ CASE-средств и документации поставщика;
• опрос реальных пользователей;
• анализ результатов проектов, использовавших данные CASE-средства;
• просмотр демонстраций и опрос демонстраторов;
• выполнение тестовых примеров;
• применение CASE-средств в пилотных проектах;
• анализ любых доступных результатов предыдущих оценок.

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

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

1. Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.
2. Обеспечение целостности проекта и контроля за его состоянием.
3. Независимость от программно-аппаратной платформы и СУБД.
4. Открытая архитектура
5. Качество технической поддержки в России, стоимость приобретения и поддержки, опыт успешного использования
6. Простота освоения и использования

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

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

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

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

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

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

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

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

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

3.Характеристика современных CASE-средств

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

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

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

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

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация  по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым  функциям и включает отдельные локальные  средства, решающие небольшие автономные задачи (tools), набор частично интегрированных  средств, охватывающих большинство  этапов жизненного цикла ИС (toolkit) и  полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные  общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим  признакам:

• применяемым методологиям и моделям систем и БД;
• степени интегрированности с СУБД;
• доступным платформам.

Классификация по типам в  основном совпадает с компонентным составом CASE-средств и включает следующие  основные типы:

• средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);
• средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
• средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team).

Вспомогательные типы включают:

• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
• средства конфигурационного управления (PVCS, SCCS и др.);
• средства тестирования (Quality Works и др.).

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

• Vantage Team Builder (Westmount I-CASE);
• Designer/2000;
• Silverrun;
• ERwin+BPwin;
• S-Designor;
• CASE.Аналитик;
• Rational Rose.

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

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

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

Модуль построения моделей  бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. Модуль концептуального моделирования данных (ERX- Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

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

Для автоматической генерации  схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты  к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL.

Система Silverrun реализована  на трех платформах - MS Windows, Macintosh и OS/2 Presentation Manager - с возможностью обмена проектными данными между ними.

Vantage Team Builder представляет  собой интегрированный программный  продукт, ориентированный на реализацию  каскадной модели ЖЦ ПО и  поддержку полного ЖЦ ПО.

Vantage Team Builder обеспечивает  выполнение следующих функций: 

• проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;
• проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);
• генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;
• программирование на языке C со встроенным SQL;
• управление версиями и конфигурацией проекта;
• многопользовательский доступ к репозиторию проекта;
• генерация проектной документации по стандартным и индивидуальным шаблонам;
• экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляется  в различных конфигурациях в  зависимости от используемых  СУБД (ORACLE, Informix, Sybase или Ingres) или средств  разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от  остальных некоторой степенью  ориентации на спиральную модель  ЖЦ ПО за счет возможностей  быстрого прототипирования, предоставляемых  Uniface. Для описания проекта ИС  используется достаточно большой  набор диаграмм. При построении  всех типов диаграмм обеспечивается  контроль соответствия моделей  синтаксису используемых методов,  а также соответствия одноименных  элементов и их типов на  различных типах диаграмм.