CASE-технологии создания информационных систем

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

Ручная разработка обычно порождала следующие проблемы:

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

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

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

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

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

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

3. Основы методологии  проектирования информационных  систем

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

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

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

 Одним из базовых понятий  методологии проектирования информационной  системы является понятие жизненного  цикла ее программного обеспечения (ЖЦ ПО). ЖЦПО – это непрерывный  процесс, который начинается с  момента принятия решения о  необходимости создания ПО информационной системы и заканчивается в момент его полного изъятия из эксплуатации.    

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

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

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

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

 Известно несколько моделей  жизненного цикла программного обеспечения. Под моделью жизненного цикла ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении всего цикла. Модель ЖЗ зависит от специфики информационной системы и условий, в которых система создается и функционирует. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадный способ и спиральная модель. Каскадная модель применяется, как правило, для разработки однородных информационных систем, представляющих собой единое целое. Ее основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на другой происходит только после того, как будет полностью завершена работа на текущем (рис. 8.1).

Рис. 8.1. Каскадная схема разработки информационной системы   

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

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

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

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

Рис. 8.2. Спиральная модель ЖЗ   

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

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

 В рамках спиральной модели  ЖЦ широкое распространение получил  один из подходов к разработке ПО, известный как методология быстрой разработки приложений RAD (Rapid Application Development). Эта методология включает в себя три составляющие: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы.