Visual studio это case средство или нет
Модель процесса оценки и выбора [17], рассматриваемая ниже (рисунок 4.2), описывает наиболее общую ситуацию оценки и выбора, а также показывает зависимость между ними. Как можно видеть, оценка и выбор могут выполняться независимо друг от друга или вместе, каждый из этих процессов требует применения определенных критериев.
Процесс оценки и выбора может преследовать несколько целей, включая одну или более из следующих:
- оценка нескольких CASE-средств и выбор одного или более из них;
- оценка одного или более CASE-средств и сохранение результатов для последующего использования;
- выбор одного или более CASE-средств с использованием результатов предыдущих оценок.
Рис. 4.2. Модель процесса оценки и выбора
Как видно из рисунка, входной информацией для процесса оценки является:
- определение пользовательских потребностей;
- цели и ограничения проекта;
- данные о доступных CASE-средствах;
- список критериев, используемых в процессе оценки.
Результаты оценки могут включать результаты предыдущих оценок. При этом не следует забывать, что набор критериев, использовавшихся при предыдущей оценке, должен быть совместимым с текущим набором. Конкретный вариант реализации процесса (оценка и выбор, оценка для будущего выбора или выбор, основанный на предыдущих оценках) определяется перечисленными выше целями.
Элементы процесса включают:
- цели, предположения и ограничения, которые могут уточняться в ходе процесса;
- потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам;
- критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;
- формализованные результаты оценок одного или более средств;
- рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).
Процесс оценки и/или выбора может быть начат только тогда, когда лицо, группа или организация полностью определила для себя конкретные потребности и формализовала их в виде количественных и качественных требований в заданной предметной области. Термин "пользовательские требования" далее означает именно такие формализованные требования.
Пользователь должен определить конкретный порядок действий и принятия решений с любыми необходимыми итерациями. Например, процесс может быть представлен в виде дерева решений с его последовательным обходом и выбором подмножеств кандидатов для более детальной оценки. Описание последовательности действий должно определять поток данных между ними.
Определение списка критериев основано на пользовательских требованиях и включает:
Порою кажется, что все вокруг устроено несложно: солнце светит, лампочки мигают, зарплату выдают вовремя. Но только захочешь сделать что-нибудь "полезное для общества", приглядишься повнимательнее, и сразу все становится ой как не просто - на пути встают комплексные объекты и системы: жилищно-коммунальное хозяйство, экономический кризис, вертикаль власти, топология, логистика территориально распределенных сетей, уголовно-процессуальный кодекс, методология планирования ресурсов с учетом производственных ограничений.
Когда в одну кучу собирается несколько разнородных объектов с различными свойствами и взаимосвязями, которые не удерживаются в одной голове в один момент времени, у человека возникает естественная когнитивная потребность "наклеить ярлычки, разложить все по полочкам, а полочки разместить по шкафчикам".
CASE’оведы и CASE’олюбы
Очевидно, что большинство современных организаций (а тем более их конгломератов - холдингов, государственных структур) являются сложными системами (с множеством экономических, культурологических, информационных, властных, семейных, технических и всяких других отношений и функций). В результате особенно остро потребность "структурирования" возникает у руководителей, менеджеров всех мастей, вынужденных подобными системами управлять. Информационные системы (в бумажных и компьютерных формах), разрабатываемые для обслуживания таких систем, с каждым годом становятся все сложнее. Автоматизация деятельности любого предприятия (как с применением корпоративной ИС собственной разработки, так и при выборе тиражной системы с последующей ее адаптацией и внедрением) предполагает обязательный изначальный анализ самой деятельности с подключением обслуживающих аналитиков и "информационщиков".
"Свято место пусто не бывает": раз есть потребность, то есть и предложение. Вот уже более 30 лет развиваются многообразные CASE-средства - средства компьютеризированного анализа, проектирования, перепроектирования, контроля за соблюдением соответствия тому, что было спроектировано и т. п.
Некоторых российских представителей фирм - поставщиков этих средств мы недавно собрали за круглым столом, чтобы вместе разобраться в спектре многообразных возможностей систем указанного класса (тоже, кстати, непростых).
Широкий спектр CASE-инструментария, охватывающего разнообразную деятельность - от анализа бизнес-структур и бизнес-требований до поддержки жизненного цикла разработки и сопровождения информационных систем, - не кажется искусственным в свете неразрывной связи систем управления организациями и ИС. Не случайно буква S в термине CASE (Computer Aided S. Engineering) трактуется сегодня в широком смысле: и как Software, и как System (хотя изначально было software), ведь программные продукты - это частный (специализированный) случай систем вообще.
Попробуем разобраться, какой длины жизненный цикл и жизненный цикл чего и для кого могут поддерживать рассматриваемые в этом обзоре CASE-инструменты.
В узком смысле CASE-средства - это средства визуального моделирования, а в широком - средства, максимально автоматизирующие все процессы жизненного цикла проекта разработки и реализации (как в организационной, так и в программной инженерии). Кроме того, это средства правильного ведения работ, поддерживающие коммуникации участников проекта на разных этапах и с разных позиций (как между командами заказчика и разработчика, так и внутри рабочей группы).
Используемые в CASE-средствах модели (визуальная составляющая CASE-инструментов) - это общий язык для всех участников некоего процесса, обеспечивающий возможность задавать те или иные аспекты предметной области с помощью общей терминологии, общих графических изображений (нотаций). Модели являются предметом коммуникаций, без которых не о чем говорить, нечего обсуждать, так как предмет не определен. Но кроме предмета коллективной разработки нужны также и специальные средства коллективизации усилий, пространство, в котором должны согласованно действовать все участники в рамках общего проекта.
Михаил Кумсков: "Наша практика показывает, что инструмент по отношению к процессам жизненного цикла вторичен. И мы, начиная внедрение, в первую очередь уделяем внимание управлению требованиями, управлению изменениями, ставим эти процессы. А потом уже учим участников пользоваться средствами визуального моделирования, анализа, проектирования и т. д. Потому что изначально должна быть налажена прозрачность коммуникаций и управляемость коллективом через специализированные средства ее поддержки".
С учетом многообразия проектов, протекающих в организациях, хотелось бы расширить понятия CASE до средств поддержки взаимодействия бизнес - ПО - бизнес, объединить их в единое целое, ведь программные продукты затем и нужны, чтобы управлять и помогать в управлении бизнесом. Дело в том, что задачи проектирования ИС и задачи оптимизации бизнес-процессов (или бизнеса как такового) переплетаются очень тесно. Более того, оптимизация бизнеса без внедрения ИС сейчас в принципе невозможна. Поэтому все должно быть связано методологически, а еще лучше - технологически (это может быть единая CASE-система, может быть несколько бесшовно интегрированных CASE-инструментов,).
Антон Шматалюк: "Наше понимание жизненного цикла максимально широко: CASE-средства сначала являются инструментом для бизнеса, затем они используются в качестве мостика между бизнесом и проектировщиками информационных систем, далее - как средства проектирования и создания ИС, и, наконец, они осуществляют обратную связь, отслеживая эффективность взаимодействия готовой ИС с бизнесом.
При внедрении информационной системы в организации должны поддерживаться как бизнес-процессы, заложенные в самой ИС, так и смежные неавтоматизированные процессы организации. Без этого полноценного внедрения не получится. Ведь организация действует в единой системе, все процессы тесно взаимосвязаны, и только в совокупности они обеспечивают целостность деятельности компании, где всеми процессами нужно управлять и регулярно их оптимизировать".
Большинство поставщиков имеют несколько другой взгляд на определение области применения CASE: одни инструменты и модели предназначены для разработчиков информационных систем, другие - организационным аналитикам, но авторы все же считают, что постепенно эти две линии сойдутся "у ног клиента".
Сергей Орлик: "Все ПО так или иначе создается ради обеспечения потребностей государственных институтов и структур, промышленных предприятий и бизнеса. С нашей точки зрения, жизненный цикл разработки программного обеспечения включает следующие ключевые элементы: анализ бизнес-потребностей в автоматизации и соответственно определение требований к ПО; моделирование, проектирование (в том числе интеграционных аспектов) и аудит; разработку и отладку; тестирование (функциональное, нагрузочное и т. п.); развертывание системы и ее эксплуатацию; и, наконец, управление конфигурациями и изменениями на всех этапах жизненного цикла. На первый план сегодня выходит адекватная поддержка высокой скорости изменений бизнес-процессов, актуализация поведения прикладных систем, в том числе - в соответствии с изменениями акцентов в требованиях, предьявляемых к ПО как бизнес-инструменту и работающему активу.
Сегодня важны не только удобство и скорость работы в той или иной среде разработки (что на протяжении значительной, более чем 20-летней истории нашей компании было в центре внимания). На первый план выходят аспекты обеспечения качества создаваемых программных продуктов, степень их документированности (как с точки зрения пользователей, так и ИТ-специалистов и разработчиков), легкость сопровождения и, конечно, возможность расширения их функциональности в соответствии с запросами пользователей".
Среди CASE-средств для разработчиков сейчас наиболее популярны средства проектирования баз данных (БД). Поскольку структура БД, создаваемой ИС, как правило, весьма сложна, то ее разработка - процесс трудоемкий. К тому же необходимо обеспечить связь между модельной составляющей и БД, автоматическое написание рабочего кода приложения, существенно экономящее время программистов и гарантирующее проектировщикам, что в системе воплощено именно то, что они задумали.
Не так давно начали пользоваться популярностью CASE-средства, предназначенные для проектирования архитектуры ИС, т. е. для так называемых системных архитекторов, отвечающих за модульное построение, интерфейсы, соединение в единое целое разнородных клиент-серверных приложений в рамках проекта.
Если целью работы с CASE-средствами является программный продукт, то он, как правило, создается на некотором языке программирования в определенной среде разработки. Такие возможности CASE-средств, как автоматическое создание кода и обратный процесс - построение диаграмм на основании исходного кода, методы анализа качества кода, требуют, чтобы осуществляющее их приложение "знало" соответствующий язык и среду программирования на уровне компилятора данного языка.
Тот факт, что некоторые производители CASE-средств попутно являются конкурирующими производителями языков и сред разработки, накладывает свой отпечаток. Так, если вы используете средства разработки от Microsoft, то для вас вряд ли окажутся полезными CASE-средства Oracle. Аналогично не приходится ожидать особой поддержки Oracle и Borland в средствах Microsoft. В то же время продукт IBM Rational Rose имеет кодогенераторы как для языков Microsoft Visual Studio, так и для языка Borland Delphi. Но в целом ориентированность некоторых комплексов CASE-средств на определенные среды разработки может оказаться столь велика, что это способно значительно сузить круг при поиске подходящего инструмента в том случае, когда среда разработки приложения уже выбрана. (В этом смысле приведенная ниже таблица сравнения не вполне корректна и должна рассматриваться читателями с указанной оговоркой.)
CASE-инструментарий призван обеспечить понимание и корректное взаимодействие представителей двух разных лагерей: аналитиков, определяющих требования бизнеса (описывающих бизнес-процессы), и разработчиков, отвечающих за структуру данных и объектно-ориентированный анализ, проектирование и программирование.
Перед тем как что-то автоматизировать, организации необходимо описать на стандартизированном CASE-языке модель своего бизнеса, выделить из него часть, подлежащую автоматизации. Утвержденный результат этого процесса и должен быть передан разработчикам автоматизированной системы в качестве технического задания на разработку (ТЗ). К сожалению, эту последовательность действий соблюдает пока очень малое число предприятий, внедряющих у себя ERP-системы, и это одна из главных причин провала проектов внедрения, поскольку ТЗ, написанное на естественном (неформализованном) языке, всегда оставляет огромное поле для недопонимания сторон.
Кроме того, по имеющейся статистике, 80% средств, которые ИT-службы предприятий тратят на программное обеспечение, уходят на сопровождение, а не на разработку (закупку) систем. И можно понять, почему. Высокие затраты на сопровождение, во-первых, связаны с плохим изначальным проектированием систем. CASE-средства способны эти затраты снизить. Во-вторых, в реальной жизни к системе в процессе ее эксплуатации предъявляются новые требования, у бизнеса появляются новые задачи, когда организация развивается. Не могут избежать непрерывных изменений и разработчики - как тиражных систем (вынужденные выводить все новые и новые версии на рынок), так и заказных, постоянно доделывающие что-то в ИС под новые требования заказчика. Так что изменения систем неизбежны, и было бы уместно, если бы CASE-средства поддерживали процессы изменений функционирующих ИС, причем желательно в режиме реального времени (реинжиниринг информационной системы без остановки жизненно важных ее элементов).
Галина Антипина: "Команды, которые профессионально занимаются разработкой информационных систем, постепенно начинают осознавать необходимость комплексного применения средств управления созданием ПО. Раньше они ограничивались средствами моделирования (бизнес-процессов, баз данных, информационных систем). Сейчас все больше компаний понимает необходимость использования таких специализированных продуктов, как средства конфигурационного управления проектами, контроля версий, тестирования. В первую очередь такой интерес идет от руководителей отделов разработки, которые понимают, что использование таких продуктов позволяет сократить время создания, повысить качество ПО, выполнить проекты в заданные сроки и в рамках бюджета. Непосредственные участники проектов (аналитики, разработчики и др.) выигрывают в первую очередь от упрощения коммуникации между участниками проекта, что позволяет значительно сократить время на поиск нужных документов, файлов, "самой последней" версии создаваемой программы и сосредоточиться на выполнении конкретных задач".
Алла Прохорова: "Для реализации полноты всех ступеней жизненного цикла только инструментальных средств мало, нужна методология разработки, задающая правила игры. Причем методология, адаптированная к нуждам конкретной фирмы. Как на предприятиях реального сектора нужны собственные бизнес-технологии ведения их деятельности в виде бизнес-процессов, так и компаниям-разработчикам необходим свой аналогичный каркас. Именно для этих задач и создана методология ведения проектов разработки (Rational Unified Process, RUP). Она представляет собой энциклопедию, в которой описаны роли участников проекта, инструкции. В адаптированном RUP возникают свои роли под свой стиль работ, и уже под нужные процессы делаются инструкции, собственный шаблонированный документооборот проектных документов. Постепенно собирается библиотека моделей, требований, репозитории".
Антон Шматалюк: "После того как информационная система создана, необходимо обучение пользователей, соединение ее с имеющимися в организации процессами. Пренебрежение этим может повлечь еще большие затраты на сопровождение, например из-за того, что система внедрена, но с ней до конца не умеют работать. По результатам эксплуатации нужен анализ использования ИС, управление дальнейшей автоматизацией предприятия, оптимизация на основе анализа. Будущие CASE-средства обязательно должны эти позиции поддерживать. ARIS уже начинает идти по этому пути, предлагая, например, ARIS Redocumentation SCOUT для аудита внедренных систем SAP".
В идеале необходимо, чтобы CASE-линейка обеспечивала с точки зрения менеджмента адекватную связь между всеми средствами поддержки жизненного цикла организационной системы, включая преобразование организационных технологий в корпоративные приложения (например, в виде workflow- или BPM-систем, средств интеграции различных приложений и бизнес-процессов и пр.).
В дальнейших частях обзора мы коснемся модельных, технологических характеристик рассматриваемых CASE-систем, а также анализа деятельности их поставщиков.
Основные этапы жизненного цикла систем, их поддержка, а также значимые свойства представленных линеек продуктов
CASE – ComputerAidedSystem/SoftwareEngineering–программные средства, поддерживающие все или часть процессов ЖЦ ПО:
§ создания и сопровождения ИС, включая анализ и формулировку требований,
§ проектирование прикладного программного обеспечения (приложений) и баз данных,
§ конфигурационное управление и управление проектом,
§ а также другие процессы.
Основная цель CASE-технологии– разграничение процесса проектирования программных продуктов от процесса кодирования и последующих этапов разработки, максимально автоматизировать процесс разработки.
Подходы к проектированию:
Интегрированное CASE-средство содержит следующие компоненты:
§ репозиторий– обеспечивает хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
§ средства коллективной работы;
§ графические средства анализа и проектирования– обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
§ средства разработки приложений, включая языки 4GL и генераторы кодов;
§ средства конфигурационного управления(контроль версий и сборок);
§ средства документирования;
§ средства тестирования;
§ средства управления проектом;
Примеры CASE средств:
§ средства проектирования БД – моделируют данные и генерируют схемы БД: CAERwinProcessModeler(CA), S-Designer (SDP), DataBaseDesigner (ORACLE);
§ объектно-ориентированные: Rational Rose (Rational Software), Object Team (Cayenne).
§ планирования и управления проектом: SECompanion, MicrosoftProjectи др.;
§ конфигурационного управления:PVCS (Intersolv);
§ средстваразработкиприложений: 4GL Uniface (Compuware), JAM (JYACC), PowerBuilder (SAP), Oracle Developer Suite (ORACLE), New Era (Informix), SQL Windows (Gupta), Microsoft Visual Studio идр.);
Системы контроля версий (СКВ). Назначение, классификация, примеры. Репозиторий. Сервис GitHub. Организация коллективной работы над проектом с помощью СКВ.
Система контроля версий (СКВ)— это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.
Примеры:Git, Subversion, rcs
Типы:
2,3 –Позволяют организовать коллективную разработку.
Централизованные системы контроля версий:
Например:CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него.
Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новые версии своей работы.
Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё.
Распределенные системы контроля версий
В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.
Общая характеристика системы Git. Структура репозитория. Алгоритмы и принципы работы. Использование VisualStudio с Git.
Git– распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом, первая версия выпущена 7 апреля 2005 года.
Репозиторий Git– каталог файловой системы, в котором находятся файлы конфигурации репозитория, файлы журналов, хранящие операции, выполняемые над репозиторием, индекс, описывающий расположение файлов и хранилище, содержащее собственно файлы.
Алгоритм работы
1. Вы вносите изменения в файлы в своём рабочем каталоге.
2. Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git'а на постоянное хранение.
GitHub– крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Основан на системе контроля версий Git и бесплатен для проектов с открытым исходным кодом.
Можно использовать Visual Studio и Git для совместной работы с командой с использованием Team Foundation Server (локально или в Visual Studio Online), на сайте CodePlex или в сторонней службе, такой как GitHub или Bitbucket.
© 2014-2022 — Студопедия.Нет — Информационный студенческий ресурс. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав (0.008)
3.2. CASE-средства. Общая характеристика и классификация
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
- мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
- интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
- использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
- репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
- графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
- средства разработки приложений, включая языки 4GL и генераторы кодов;
- средства конфигурационного управления;
- средства документирования;
- средства тестирования;
- средства управления проектом;
- средства реинжиниринга.
Требования к функциям отдельных компонент в виде критериев оценки CASE-средств приведены в разделе 4.2.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
- применяемым методологиям и моделям систем и БД;
- степени интегрированности с СУБД;
- доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
- средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
- средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
- средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
- средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
- средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
Вспомогательные типы включают:
- средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
- средства конфигурационного управления (PVCS (Intersolv));
- средства тестирования (Quality Works (Segue Software));
- средства документирования (SoDA (Rational Software)).
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
- Vantage Team Builder (Westmount I-CASE);
- Designer/2000;
- Silverrun;
- ERwin+BPwin;
- S-Designor;
- CASE.Аналитик.
Описание перечисленных CASE-средств приведено в разделе 5. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики. Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:
- сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
- наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
- отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
- необходимость интеграции существующих и вновь разрабатываемых приложений;
- функционирование в неоднородной среде на нескольких аппаратных платформах;
- разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
- существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:
- неадекватная спецификация требований;
- неспособность обнаруживать ошибки в проектных решениях;
- низкое качество документации, снижающее эксплуатационные качества;
- затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе (феномен "сапожника без сапог").
Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:
- подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
- широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
- внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
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-средств может закончиться неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.
Для того, чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных "подводных камней" использования CASE-средств. Среди наиболее важных проблем выделяются следующие:
- достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;
- внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;
- отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;
- CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;
- некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, при этом, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение;
- негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также постоянным затратам на обучение и повышение квалификации персонала.
Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:
Читайте также: