1.1. Основные понятия CASE-технологии
Первоначальное значение термина CASE, ограниченное во­просами автоматизации разработки лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС. Термин CASE (ComputerAidedSoftwareEngineering Методология компьютерного проектирования ПО) используется в настоящее время в весьма широком смысле. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с сис­темным ПО и техническими средствами образуют полную среду разработки ИС [13].
Появлению CASE-технологий и CASE-средств предшество­вали исследования в области методологии программирования. К последнему был применен системный подход с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д.
Кроме того, появлению CASE-технологии  способствовали и такие факторы, как:
• широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

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

Можно перечислить следующие факторы, усложняющие оп­ределение возможного эффекта от использования CASE-средств:

1. широкое разнообразие качества и возможностей CASE-средств;
2. относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их приме­нения;
3. широкое разнообразие в практике внедрения CASE-средств в различных организациях;
4. отсутствие данных для уже выполненных и текущих проектов на основе CASE-технологий;
5. широкий диапазон предметных областей проектов;
6. различная степень интеграции CASE-средств в различные проекты.

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

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

Если организация не обладает хотя бы одним из перечисленных качеств, то внедрение CASE-средств может закончиться неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.
Для того чтобы принять взвешенное решение относительно инвестиций в CASEтехнологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных «подводных камней» использования CASE-средств.
Среди наиболее важных проблем можно выделить следующие:
•  достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ИС;
•  внедрение CASE-средств может представлять собой достаточно длительный процесс, т.е. не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на их внедрение. Вследствие
этого руководство организации пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;
•  отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и используемыми в данной организации может привести к дополнитель­ным трудностям;
•  CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

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

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

3. Высокий уровень отдачи от инвестиций в CASE-средства.

1.2. Основы методологии проектирования информационных систем
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО), означающее непрерывный процесс, начинающийся с момента принятия решения о необходимости его создания и заканчивающийся в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISOInternationalOrganizationofStandardization Международная ор­ганизация по стандартизации, IECInternationalElectro-technicalCommission Международная комиссия по электротехнике), определяющий структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО [4]. Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

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

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

1.3. Модели жизненного цикла ИС
Стандарт ISO/IEC 12207 не предлагает конкретную модель. ЖЦ (структуру, определяющую последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ) и методы разработки ИС. Модель ЖЦ зависит от специфики  ИС  и  условий,  в  которых  последняя создается  и функционирует.  Регламенты  стандарта  являются  общими  для любых  моделей  ЖЦ, методологий   и  технологий  разработки Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ИС,  но детально не конкретизирует, как реализовать или выполнить действия и задачи, включенные в эти процессы [4].
К настоящему времени наибольшее распространение получили каскадная модель (19701985  гг.) и спиральная модель (19861990 гг.) ЖЦ [5].
В изначально существовавших однородных ИС каждое при лужение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ, основной характеристикой которого является разбиение всей разработки на этапы, причем переход от одного этапа к следующему происходит только после того, как будет полностью завершена работа на текущем этапе (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы раз­работка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в том, что на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности, а выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный  подход  хорошо  зарекомендовал  себя   при   построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предоставить  разработчикам  свободу  реализовать  их с технической точки зрения как можно лучше. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования такого подхода обнаружился ряд недостатков, вызванный прежде всего тем, что реальный процесс создания ИС никогда полностью укладывался в жесткую схему. В процессе создания ИС постоянно возникала потребность в возврате к предыдущим этапам и мнении или пересмотре ранее принятых решений. В результате реальный  процесс создания ИС  принимал  следующий  вид (рис 1.2).

Рис. 1.1. Каскадная схема разработки ИС

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

Рис. 1.2. Реальный процесс разработки ИС по каскадной схеме

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

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

1.4. Методологии и технологии проектирования ИС
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и Поддерживающие их стандарты, методики и инструментальные
Средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность
трех составляющих:
1. Пошаговой процедуры, определяющей последовательность
технологических операций проектирования (рис. 1.4);

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

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

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

1. поддерживать полный ЖЦ ИС;
2. обеспечивать  гарантированное  достижение  целей  разработки ИС с заданным качеством и в установленное время;
3. предоставлять возможность выполнения крупных проектов в виде подсистем (т.е. декомпозицию проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные практически не связанные по данным и функциям подсистемы, реализация которых должна выполняться отдельными группами специалистов (37 человек, что обусловлено принципами управляемости коллектива и повышением производительности за счет минимизации числа внешних связей). При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирова­ние результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
4. обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта внедрение идет последовательно по отдельным подсистемам:
   •  предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
   •  обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков  и систем программирования);
   •  должна   быть    поддержана   комплексом    согласованных
   CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
   Реальное   применение  любой   технологии   проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся: стандарт проектирования, стандарт оформления проектной документации и стандарт пользовательского интерфейса.
   Стандарт проектирования должен устанавливать:
   •  набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
   •  правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
   •  требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE средств, общие настройки проекта и т. д.; механизм обеспечения совместной работы над проектом, и том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации должен устанавливать:

1. комплектность, состав и структуру документации на каждой стадии проектирования;
2. требования к ее оформлению (включая требования к со держанию разделов, подразделов, пунктов, таблиц и т.д.);
3. правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
4. требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
5. требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт пользовательского интерфейса должен устанавливать:

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

Ссылки

http://www.ekportal.ru

http://www.citforum.ru

http://www.interface.ru

http://www.info-system.ru

Контрольные вопросы

1. Какие факторы привели к появлению CASE-технологий?
2. Что такое CASE-технологии?
3. Перечислите основные преимущества использования CASE-средств.
4. Какими качествами должна обладать организация для успешного внедрения CASE-средств?
5. Что подразумевается под жизненным циклом программного обеспечения?
6. На каких процессах базируется структура ЖЦ ПО по-стандарту ISO/IEC 12207?
7. Назовите и охарактеризуйте основные модели ЖЦ.
8. Из каких составляющих состоит технология проектирования?
9. Каким  требованиям  должна  удовлетворять  технология проектирования, разработки и сопровождения ИС?
10. Назовите стандарты для реального применения технологии проектирования, разработки и сопровождения ИС.
11. Что устанавливает стандарт проектирования?
12. Определите стандарт оформления проектной документами и стандарт пользовательского интерфейса.

Начало | Глава 2