Современные case технологии. Кейс-технология. Метод case study («разбор конкретных ситуаций»). Основы методологии проектирования ИС

IP protocol был разработан для самых различных типов подключений, и хотя максимальная длина для IP datagram составляет 64K, большинство подключений (transmission links) используют меньший максимальный размер для IP-пакета или MTU.
MTU, Maximum Transmission Unit - максимальный размер блока в байтах, который может быть передан на канальном уровне сетевой модели OSI.

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

На рисунке отображен заголовок IP пакета и то, как он инкапсулируется в датаграмму второго уровня.
Здесь важно отметить, что в поле FLAGS включает в себя три бита, один из которых "don"t fragment" (DF) bit , который определяет разрешено данный пакет фрагментировать или нет.

Вопросы с IP фрагментированием

Хотя фрагментация пакета выполняется достаточно быстро, обратная сборка исходного пакета требует значительных ресурсов: затрат памяти, вопросы быстродействия.
В случае потери одного из фрагментов вся датаграмма должна быть передана заново.
Фрагметы очень тяжело обрабатывать на брендмауэрах (с 4-го по 7 уровень), при неправильной последовательности они будут забракованы.

TCP MSS и избегание дефрагментации

TCP Maximum Segment Size (MSS) - определяет максимальный размер датаграммы TCP/IP, которую будет принимать данный хост.
Датаграмма TCP/IP может быть фрагментирована на уровне IP.
Значение MSS отсылается внутри TCP header только в сегментах TCP SYN. Каждая сторона TCP соединения объявляет другой стороне свое значение MSS.
Вопреки распространенному мнению, значение MSS не согласовывается между хостами, - у каждого хоста они могут оставаться разными, только отсылающий хост отдает сегменты размером не больше, чем требует принимающий хост.

Таким образом TCP MSS позволяет избежать фрагментации на уровне двух участников сессии TCP. Но TCP MSS не может обработать тот случай, когда по пути между хостами есть меньший MTU.

PMTUD

PMTUD (Path Maximum Transmission Unit Discovery) - был разработан для избегания фрагментации по пути между хостами. PMTUD используется для автоматического определения минимального MTU вдоль пути пакета между хостами.

PMTUD поддерживается только TCP, UDP и другие протоколы не поддерживают PMTUD.

Хост отсылает нефрагментированный пакет с установленным DF bit . Если маршрутизатор пытается отдать пакет на link, с меньшей MTU чем этот пакет, маршрутизатор дропнет этот пакет и возвратит сообщение ICMP "Destination Unreachable", с кодом "fragmentation needed and DF set" (type 3, code 4). Когда Хост-источник получает эту информацию, он понижает MSS и затем пересылает TCP сегмент заново.

Наиболее часто встречающаяся проблема с PMTUD - это среда в которой не пропускается сообщения ICMP

Где актуально использование PMTUD

Как уже было сказано, PMTUD нужен в случаях, когда по пути от хоста А к хосту Б встречаются линки с меньшими значениями MTU.
Наиболее общие примеры:
- PPPoE (часто используемый вместе с ADSL) использует 8 bytes для своего заголовка. Это уменьшает эффективное значение MTU для Ethernet до 1492 (1500 - 8).
- Туннельный протоколы GRE, IPsec, and L2TP также используют пространство для своих заголовков, что также уменьшает эффективное MTU на исходящем интерфейсе.

Вообще Path MTU Discovery (RFC 1191) осуществляется всеми клиентами включая Windows 2000/2003/XP/7/8.
Для нормальной работы PMTUD необходимо, чтобы пропускался протокол ICMP, в частности должны пропускаться сообщения ICMP "unreachable" и "time-exceeded".

Для проверки можно использовать утилиту mturoute.exe. Утилита отрабатывает аналогично PMTUD и возвращает значение MTU, которое необходимо использовать на данном хосте.

Текущее значение MTU можно увидеть через команды:
Windows 7, Windows Vista: netsh interface ipv4 show subinterfaces
Windows XP: netsh interface ip show interface

Значения MTU для локальной машины можно поменять и вручную (хотя и не рекомендуется)
Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems
Также можно использовать утилиту Set MTU, поставляемой с Cisco Systems VPN Client.

Что такое туннель

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

Туннель состоит из основных компонентов:
- Passenger protocol
- Carrier protocol . Протокол, осуществляющий инкапсуляцию:
GRE
IP in IP tunnels
- Transport protocol . Протокол отвечающий за маршрутизацию encapsulated protocol. В нашем случае это IP.

На приведенном рисунке IP у нас выступает как transport protocol и как passenger protocol .

Инкапсуляция трафика дает следующие преимущества:

• Endpoints могут использовать private addresses
• Позволяет строить VPN поверх WAN сетей
• Возможность использования шифрования

Исходя из того, что наиболее "тяжелый" вариант - это одновременное использование GRE и IPsec, рекомендации будут следующие:
- PMTUD позволяет установить на GRE интерфейсе оптимальное значение MTU и включается на туннельном интерфейсе командой tunnel path-mtu-discovery
- Обеспечьте нормальную работу PMTUD, при этом на обоих целевых хостах должна успешно выполняться mturoute.exe
- Также рекомендуется одновременно использовать и команду ip mtu 1400 . В этом случае ip mtu будет обеспечивать пространство для GRE + IPSec, в случае же более низких значениях MTU по пути, IP MTU бует подкорректировано динамически. Значение 1400 рекомендовано, т.к. оно покрывает большинство возможных комбинаций GRE + IPSec.
- Следует использовать ip tcp adjust-mss 1360 на туннельном интерфейсе. Это позволит маршрутизатору уменьшить значение TCP MSS в TCP SYN Packet. Что позволить двух конечным хостам генерировать достаточно малые пакеты. (1360 = 1400 - 20(TCP) - 20 (IP))

Общий конфиг для туннельного интефейса DMVPN + IPSec будет выглядеть:
interface Tunnel200
description ### DMVPN TUNNEL HUB
ip address 10.5.0.1 255.255.255.0
no ip redirects
ip mtu 1400
tunnel path-mtu-discovery
ip nbar protocol-discovery
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
ip flow ingress
ip flow egress
ip nhrp authentication baurus
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
delay 100000
tunnel source 87.237.40.107
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN

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

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

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

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

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

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

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

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

Широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

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

CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

Реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

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

Мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

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

Использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты:

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

Графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы;

Средства разработки приложений, включая языки 4GL и генераторы кодов;

Средства конфигурационного управления;

Средства документирования;

Средства тестирования;

Средства управления проектом;

Средства реинжиниринга.

Все современные 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), Obiect Team (Cavenne)).

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

Средства планирования и управления проектом (SE Companion, Microsoft Project)

Средства конфигурационного управления (PVCS (Intersolv));

Средства тестирования (Quality Works (Segue Software));

Средства документирования (SoDA (Rational Software)).

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

Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

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

Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

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

Достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

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

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

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

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

Процесс внедрения состоит из следующих этапов:

Определение потребностей в CASE-средствах; .

Оценка и выбор CASE-средств; "

Выполнение пилотного проекта;

Практическое внедрение CASE-средств.

Определение потребностей в CASE-средствах можно проиллюстрировать следующей диаграммой.

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

Процесс оценки и выбора CASE-средств можно рассмотреть в виде модели. Этот процесс может преследовать несколько целей и включать:

Оценку нескольких CASE-средств и выбор одного или более из них;

Оценку одного или более CASE-средств и сохранение результатов для последующего использования;

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

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

Как видно из рисунка, входной информацией для процесса оценки является:

Определение пользовательских потребностей;

Цели и ограничения проекта;

Данные о доступных CASE-средствах;

Список критериев, используемых в процессе оценки.

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

Элементы процесса включают:

Цели, предположения и ограничения, которые могут уточняться в ходе процесса;

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

Критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

Формализованные результаты оценок одного или более средств;

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

Выбор критериев для использования из приведенного далее перечня;

Определение дополнительных критериев;

Определение области использования каждого критерия (оценка, выбор или оба процесса);

Определение одной или более метрик для каждого критерия оценки;

Назначение веса каждому критерию при выборе.

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

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

Подтвердить достоверность результатов оценки и выбора;

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

Собрать информацию, необходимую для разработки плана практического внедрения;

Приобрести собственный опыт использования CASE-средства.

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

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

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

Информацию относительно приобретения, установки и настройки CASE-средств.

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

Ожидаемые потребности в обучении и ресурсы, используемые в течение и после завершения процесса перехода.

Определение стандартных процедур использования средств.

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

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

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

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

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

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

Использованное время;

Время, выделенное персонально для конкретных специалистов;

Размер, сложность и качество ПО;

Удобство сопровождения.

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

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

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

Аннотация

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

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

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

Введение

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

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

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

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

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

1.1. Жизненный цикл по ИС

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 .

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

1.2. Модели жизненного цикла ПО

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

• 
  каскадная модель (70-85 г.г.);
• 
  спиральная модель (86-90 г.г.).

Положительные стороны применения каскадного подхода заключаются в следующем :

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

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

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

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

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

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

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

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

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

2.3. Моделирование потоков данных (процессов)

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

• 
  внешние сущности;
• 
  системы/подсистемы;
• 
  процессы;
• 
  накопители данных;
• 
  потоки данных.

^

4.2. Оценка и выбор CASE-средств

4.2.1. Общие сведения

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

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

Рис. 4.2. Модель процесса оценки и выбора

Как видно из рисунка, входной информацией для процесса оценки является:

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

Элементы процесса включают:

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

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

Определение списка критериев основано на пользовательских требованиях и включает:

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