Критерии оценки и выбора case средств. Реферат: Оценка и выбор CASE средств. Надежностьcase интерфейс оперативная память

Если Вы слепо доверяете надежности своего "винчестера", то, поверь-
те, наступит день, когда Вы об этом пожалеете. У любой механической
системы (а жесткий диск таковой и является) есть свой запас прочно-
сти. Что произойдет после выработки ресурса, точно никто не пред-
скажет, однако на лучшее можете не рассчитывать: самая важная для Вас
информация наверняка пропадет безвозвратно. В Windows NT Server
встроены механизмы, обеспечивающие отказоустойчивость системы:

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

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

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

Таблица 5-1
Источник сбоя Кластерное решение Другие решения
Сетевой концентратор Применимо, если каждый -
из узлов подключен
к своему концентратору
Напряжение питания - Источник беспере-
бойного питания
Подключение к серверу Применимо -
Жесткий диск - RAID, отказо-
устойчивые диски
Аппаратура сервера Применимо -
(процессор, память
и др.)
Серверное ПО Применимо -
Маршрутизаторы, - Дублирующие
выделенные линии и др. маршруты и линии
Коммутируемые - Пулы модемов
соединения
Клиентские - Несколько клиентов
компьютеры с одинаковыми
уровнями доступа


Таблица хорошо показывает, что хотя кластеры и обеспечивают высо-
кую степень надежности сервера, но не являются панацеей. К тому же
они поддерживаются только версией для предприятий (Windows NT
Server Enterprise Edition). Требуются дополнительные механизмы. Рас-
смотрим средства обеспечения бесперебойной работы, встроенные в
Windows NT Server 5.0.

Средства повышения надежности работы
с диском

Если Вы регулярно пользовались такими программами как CHKDSK или
Norton disk Doctor, то наверняка обращали внимание на иногда обна-
руживаемые на жестких дисках "плохие области" (bad blocks), которые
эти программы помечают как недоступные. Причин появления таких
областей несколько, начиная от некачественного диска и кончая неко-
торыми видами вирусов. Но какова бы ни была причина, результат все-
гда один - сокращение доступного рабочего пространства на диске.
Если же Вы своевременно не продиагностировали диск, то последствия
могут быть еще печальнее: Вы потеряете данные, записанные на по-
врежденный участок, а, в самом худшем случае, операционная система
утратит работоспособность. Поэтому, если в Вашем компьютере толь-
ко один жесткий диск или Вы не используете технологии, описанные
далее в этой главе, первейшей заботой должна стать регулярная про-
верка состояния диска.

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

Проверка состояния жесткого диска

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

CHKDSK [[ path ]filenanie] ],

Указывает диск, который надо проверить;

Filename - указывает файлы для проверки фрагментации (только на
FAT);

. /F - исправляет ошибки на диске;

. /V - для FAT показывает полное имя и путь к файлам на диске; для
NTFS - также сообщения об очистке;

. /R - определяет плохие сектора и восстанавливает читаемую ин-
формацию;

. /L: size - только для NTFS: устанавливает размер файла журнала в
килобайтах, если размер не указан, подразумевается активный.

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

Помимо команды CHKDSK в Windows NT 5.0 для проверки диска име-
ется графическая утилита. Чтобы ее вызвать, необходимо щелкнуть
правой кнопкой мыши имя диска в папке My Computer и в появившем-
ся меню выбрать команду Properties. В диалоговом окне надо выбрать
вкладку Tools и щелкнуть кнопку Check Now. Для полной проверки
диска следует отметить оба флажка: Automatically fix filesystem
errors и Scan and attempt recovery of bad sectors.


Диалоговое окно проверки состояния жестких дисков

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

зеркализация дисков, дублирование дисков, чередование дисков с кон-
тролем четности и замена секторов (в "горячем" режиме).

Технология RAID (избыточный массив
недорогих дисков)

Средства повышения надежности работы с дисками имеют промыш-
ленный стандарт и подразделяются на несколько уровней использова-
ния избыточных массивов недорогих дисков (RAID) (см. таблицу 5-2).
Каждый из уровней обладает различным сочетанием производительно-
сти, надежности и стоимости. В Windows NT Server 5.0 обеспечивается
поддержка RAID уровней 0,1 и 5.


Чередование дисков

Этот уровень (RAIDO) обеспечивает чередование между различными
разделами диска. При этом файл как бы "размазан" по нескольким
физическим дискам. Данный метод может увеличить производитель-
ность работы с диском, особенно, когда диски подключены к разным

контроллерам дисков. Так как этот подход нс обеспечивает избы точ-
ности, его нельзя назвать в полной мере RAID. При выходе из строя
любого раздела в массиве все данные будут потеряны. Для реализации
метода требуется от 2 до 32 дисков. Увеличение производительности
достигается только при использовании разных контроллеров диска.


Уровень О: чередование дисков

Зеркализация и дублирование дисков

Зеркальная копия диска или раздел создаются средствами RAID уровня 1:

зеркализацией или дублированием. Зеркальное отражение дисков дей-
ствует на уровне разделов. Любой раздел, включая загрузочный или
системный, может быть зеркально отражен. Это простейший метод
повышения надежности работы с диском. Чаше всего, зеркализация -
самый дорогой метод обеспечения надежности, так как при нем задей-
ствовано всего лишь 50 процентов объема жесткого диска. Однако в
большинстве одноранговых или небольших серверных сетей такой
способ дешев за счет использования всего двух дисков.

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

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

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


Для активизации раздела надо воспользоваться либо утилитой FDISK,
входящей в поставку любой версии MS-DOS (для разделов FAT), либо
слепком Disk Administrator.

Чередование дисков с записью кода коррекции

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

Этот метод требует выделения на диске больше места для хранения
кода коррекции, чем для информации о четности. В Windows NT Server
данный метод не используется.

Чередование дисков с записью кода коррекции
в виде четности

RAID уровня 3 аналогичен уровню 2 за тем исключением, что код кор-
рекции заменен информацией о четности, записываемой на один диск.
Таким образом, дисковое пространство используется лучше. В Windows
NT Server этот уровень также не применяется.

Чередование дисков большими блоками.
Хранение четности на одном диске

RAID уровня 4 записывает целые блоки данных на каждый диск в мас-
сиве. Отдельный диск используется для хранения информации о чет-
ности. Всякий раз при записи блока информация о четности должна
быть считана, изменена, а затем записана вновь. Этот метод больше
годится для операций записи больших блоков, чем для обработки тран-
закций. В Windows NT Server он не применяется.

Чередование дисков с записью информации
о четности на все диски

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

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

Этот механизм поддерживает от 3 до 32 дисков. В набор чередования
могут входить все разделы, кроме загрузочного (системного).


Уровень 5: чередование диска с четностью

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


Подключение массива RAID в кластер

Базовые и динамические дисковые тома

В Windows NT 5.0 введены новые понятия: базового и динамического
тома. На базовых дисках можно выполнять следующие операции:

Создавать и удалять первичные и расширенные разделы и логичес-
кие диски;

Отмечать раздел как активный;

Удалять наборы томов;

Разбивать зеркализацию в зеркальном наборе;

Восстанавливать зеркальные наборы;

Восстанавливать наборы дисков с чередованием с сохранением ин-
формации о четности;

Делать диски динамическими;

Превращать тома и разделы в динамические.

Некоторые операции можно выполнять только на динамических дис-
ках, а именно:

Создавать и удалять простые тома, зеркальные тома, тома с чередо-
ванием и RAID-5;

Расширять тома;

Удалять зеркало из зеркального тома;

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

Исправлять тома RAID-5.

Чтобы превратить диск в динамический, выберите его в слепке консо-
ли управления Disk Management и щелкните правой кнопкой мыши. В
контекстном меню выберите команду Initialize Disk. Далее следуйте
указаниям программы.

В первой бета-версии Windows NT 5.0 не поддерживается преобразо-
вание разделов диска в динамические. Эта возможность будет реализо-
вана во второй бета-версии.

Внимание! Динамические диски не доступны из MS-DOS или Windows.

Замена секторов в "горячем режиме"

В Windows NT Server можно восстанавливать сектора в процессе рабо-
ты. При форматировании тома файловая система проверяет все секто-
ра и, обнаружив дефектные, помечает их для исключения из дальней-
шей работы. Если плохой сектор обнаружен в процессе записи (чте-
ния), отказоустойчивый драйвер пытается перенести данные в другой
сектор, а первый - отметить как сбойный. Если перенос удается, фай-
ловая система не предупреждает о проблеме. Эта процедура возможна
только на дисках SCSI.




1. Определяет сбойный сектор

2. Перемещает данные в хороший сектор

3. Помечает сбойный сектор

Замена секторов

Исправление ошибок

Описанные возможности отказоустойчивых конфигураций обеспечи-
ваются при установке в системе драйвера FTDISK. В общем случае воз-
можности по обнаружению и исправлению дисковых ошибок опреде-
ляются рядом факторов. В таблице 5-3 перечислены возможные вари-
анты конфигурации и соответствующие им возможности "работы над
ошибками".

Таблица 5-3
Описание Отказоустойчивый том Обычный том
FTDISK установлен; FTDISK FTDISK
тип жесткого диска восстанавливает не восстанавливает
SCSI; резервные данные данные
сектора в наличии
FTDISK замещает FTDISK сообщает
плохие сектора файловой системе
о плохом секторе
Файловой системе не NTFS переназначает
известно об ошибке кластеры; во время
чтения данные теряются
FTDISK установлен; FTDISK FTDISK
тип жесткого диска восстанавливает не восстанавливает
не-SCSI; резервные данные данные
сектора отсутствуют
FTDISK посылает FTDISK сообщает
данные и сообщение файловой системе
о плохом секторе о плохом секторе
файловой системе
NTPS переназначает NTFS переназначает
кластеры кластеры; во время
чтения данные теряются
FTDISK не установлен; - Драйвер диска сообщает
тип диска любой файловой системе
о плохом секторе
NTFS переназначает
кластеры; во время
чтения данные теряются


Резервное копирование

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

Программа Windows NT Backup

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

Резервное копирование и восстановление данных, расположенных
на разделах NTFS, FAT и FAT32 как на локальном, так и на удаленном
компьютере;

Выбор отдельных томов, каталогов или файлов, подлежащих копи-
рованию (восстановлению), а также просмотр подробной информа-
ции о файлах;

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

Выбор дополнительной проверки правильности записи (восста-
новления);

Обычные операции резервного копирования: нормальное (normal),
копирование (copy), приращение (incremental), разница (differen-
tial), ежедневное (daily);

Размещение на одном носителе нескольких записей и их объедине-
ние или замещение;

Создание командного файла для автоматизации резервного копиро-
вания;

Планирование операций резервного копирования по времени;

Просмотр полного каталога резервных копий и выбор файлов и
каталогов, подлежащих восстановлению;

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

Использование программы-мастера резервного копирования (вос-
становления) ;

Сохранение информации об операциях резервирования (восстанов-
ления) в журнале и последующий ее просмотр в Event Viewer.

Интерфейс программы

Если в предыдущих версиях Windows NT для запуска программы резерв-
ного копирования требовалось найти соответствующий значок в груп-
пе средств администрирования, то теперь доступ к ней осуществляется
подобно тому, как в Windows 95- Щелкните правой кнопкой мыши зна-
чок, соответствующий жесткому диску, и выберите в контекстном меню
команду Properties, а затем в появившемся диалоговом окне Disk Pro-
perties - вкладку Tools. Затем следует щелкнуть в разделе Backup
кнопку Backup now, и на экране появится окно программы резервно-
го копирования.

Внимание! Для резервного копирования необходимо, чтобы в сис-
теме был запущен сервис Media support service. В первой бета-версии
Windows NT 5.0 он не запускается по умолчанию. Запустите его через
слепок консоли управления Service Management.


Интерфейс программы Windows NT Backup

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

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


Приглашение начать резервное копирование

Параметры резервного копирования
(восстановления)

К доступным параметрам резервного копирования (восстановления)
относятся:

Тип резервного копирования;

Параметры регистрации в журнале;

Файлы, не подлежащие резервированию;

Параметры восстановления.

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


Диалоговое окно Options, вкладка Backup Type

Вы можете выбрать: выполнять ли резервное копирование всех отме-
ченных файлов (All selected files) или только новых или измененных
(New and changed/lies only).

В первом случае копируются все выделенные файлы (даже те, которые,
например, уже были скопированы несколько дней назад и с тех пор не
изменились). Понятно, что время выполнения резервирования в дан-
ном случае зависит только от общего объема отмеченных файлов. У Вас
также имеется возможность поставить переключатель в положение,
предписывающее отмечать модификацию файла (Normal backup type.
Backup all files. Clear the modified/lag.) или не делать этого (Copy
backup type. Backup all files. Don t clear the modified flag.). Второй
тип позволяет значительно сократить время резервного копирования.

Помимо разностного резервирования и резервирования с приращени-
ем эффективно ежедневное резервное копирование. При этом копиру-

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

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


Диалоговое окно Options, вкладка Backup logging

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

Operation: Backup

Active Device; File

Media Name: "Media created on 15.11.97"

Backup set ft1 on media Ш

Backup Method: Normal

Backup started on 15.11,97 at 16:03.
Backup completed on 15.11.97 at 16:03.
Directories: 2
Files: 5
Bytes: 21,192
Time: 1 second.

Operation: Verify After Backup

Verify Type: Cyclic Redundancy Check

Active Device: File

Active Device: D:\WINNT5\SYSTEM32\Backup.bkf

Backup set HI on media ff1

Backup description: "Set created on 15.11.97 at 16:03"

Verify started on 15.11.97 at 16:03.

Verify completed on 15.11.97 at 16:03.

Time: 2 seconds.

Operation: Restore

Restore started on 15.11.97 at 16:05,

Warning: File New Bitmap Image.bmp was skipped

Warning: File New Rich Text Document, rtf was skipped

Warning: File New Text Document.txt was skipped

Warning: File New WordPad Document.doc was skipped

Warning: File tracking,log was skipped

Restore completed on 15.11.97 at 16:05.

Time: 3 seconds.

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

Для исключения таких файлов из списка копируемых, выберите в диа-
логовом окне Options вкладку Exclude Files и укажите расширения
всех файлов, для которых не надо делать резервную копию.


Диалоговое окно Options, вклидка Exclude files

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

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


Диалоговое окно Options, вкладка Restore options

Выполнение резервного копирования

После определения параметров резервного копирования можно при-
ступить непосредственно к самой процедуре.

Внимание! Если Вы выполняете резервирование в файл, то укажите
имя файла-приемника. Этот файл будет называться в дальнейшем но-
сителем (media), несмотря на то, что в физическом смысле он не яв-
ляется носителем, а сам располагается на носителе, например, на жес-
тком диске. Термин "носитель" не должен Вас смущать, когда програм-
ма задает вопрос типа "Заместить все содержимое носителя?". Речь в
данном случае идет только о файле-приемнике.

Для начала резервного копирования щелкните кнопку Start в програм-
ме Windows NT Backup. Появится диалоговое окно Backup Informa-
tion, предлагающее уточнить некоторые дополнительные параметры.


Диалоговое окно Backup Information

Задать параметры Вам помогут следующие элементы окна:

Флажок Restrict access to owner or administrator - если он от-
мечен, то доступ к носителю будет запрещен для владельцев файлов
или администраторов;

Флажок Backup local Registry - если он отмечен, то будет создана
резервная копия реестра на локальной машине;

Поле Set description - в него Вы можете ввести название резерви-
руемой информации; при восстановлении это название будет пере-
числено в списке доступных наборов;

. фляжок Append this backup to the media - отметив его, Вы укаже-
те программе на необходимость добавления новой информации к
уже хранимой в архиве;

Флажок Replace the data on the media with this backup - отме-
тив его, Вы укажете программе на необходимость замещения всей
предыдущей информации на носителе новой; в случае использова-
ния в качестве носителя магнитной ленты будет создано новое ог-
лавление и данные будут записаны с начала ленты, в случае исполь-
зования файла на диске - переписано содержимое файла;

В поле Use this media name следует ввести имя носителя;

Кнопка Advanced открывает возможность ввести дополнительные
параметры в диалоговом окне Advanced backup options,


Диалоговое окно Advanced Backup Options

С помощью диалогового окна Advanced Backup Options Вы можете
потребовать:

Выполнить резервное копирование службы каталогов;

Выполнить резервное копирование данных иерархичного хранилища;

Проверить данные после резервирования;

Использовать компрессию на аппаратном уровне (если это допуска-
ет Ваше оборудование);

Выбрать один из описанных ранее типов резервного копирования.

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

Планирование резервного копирования

В предыдущих версиях Windows NT для планирования времени резер-
вного копирования требовалось использовать системный планировщик
(команда AT). Новая версия имеет встроенный планировщик, который
позволяет задать начальные день и время резервирования, указать, яв-
ляется ли данная операция регулярной, если да, то с какой периодич-
ностью и в течение какого времени должна выполняться. Все эти пара-
метры задаются для каждого резервного копирования в диалоговом
окне Scheduled Job Options.


Диалоговое окно Scheduled Job Options

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

. Start date - текущее число;

. Start time - 12:00 (надеясь, что в полночь" все пользователи уже
разошлись по домам, где отдыхают, а не работают с файлами в сво-
их домашних каталогах);

Отметьте флажок Run more then once,

. Frequency - ежедневно (daily), интервал - 1 день.

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


Расписание заданий резервного копирования

Программа указывает полночь "по-американски", то есть в 12.00 AM.

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

Поддержка источников
бесперебойного питания

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

Сервис UPS Windows NT определяет сбои напряжения питания, предуп-
реждает о них пользователя и корректно заглушает систему при исто-
щении источника резервного питания.

Настройка параметров этого сервиса производится в разделе UPS па-
нели управления.


Диалоговое окно настройки параметров UPS
К настраиваемым параметрам относятся:

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

Сигнал от UPS при сбое напряжения питания;

Предупреждение от UPS при снижении уровня зарядки батарей;

Сигнал от сервиса UPS для выключения источника бесперебойного
питания;

Командный файл, выполняемый перед выключением компьютера;

Ожидаемое время работы и перезарядки батарей;

Временные интервалы для предупреждающих сообщений.

Сервис UPS должен использоваться совместно с сервисами Alerter, Mes-
senger и Журналом регистрации. При этом все события, связанные с
сервисом UPS (например, сбой питания или сбой подключения источ-
ника бесперебойного питания) будут занесены в журнал регистрации,
а определенные пользователи будут уведомлены о них по сети. С по-
мощью параметра Server на панели управления можно назначить
пользователей и (или) компьютеры, которые будут получать эти уве-
домления.

Кластеры серверов

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

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

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

Кластерная технология повысит доступность системы. Можно предло-
жить использование двух систем, подключенных к многопортовому
дисковому массиву, на котором располагается база данных. В случае
сбоя сервера А резервная система (сервер Б) автоматически "подхва-
тит" соединение так, что пользователи и не заметят, что произошел
сбой. Таким образом, комбинация технологий обеспечения повышен-
ной надежности работы с диском, стандартно используемых в Windows
NT Server (чередование, дублирование и т. д) с кластерной технологи-
ей гарантирует доступность системы.


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

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

До недавнего времени подобные соображения приводили к тому, что
технические специалисты крупных банков, вынужденные заранее ^зак-
ладываться" на огромный рост вычислительных потребностей, созда-
вали системы на базе больших мэйнфреймов и мини-ЭВМ.

Кластерная технология на базе Windows NT Server предоставляет по-
трясающую возможность - отказаться от дорогостоящего оборудова-
ния и использовать широко распространенную систему на самых обыч-
ных аппаратных платформах. Мощность кластера наращивается про-
стым добавлением в него еще одной системы.


Наращиваемость кластеров

Традиционная архитектура предоставления
высокой доступности

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

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

Традиционная архитектура обеспечения
наращиваемости

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

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

Архитектура кластера

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

Сегодня в кластерах используются, в основном, две модели: с общими
дисками и без общих компонентов.

Модель с общими дисками

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

и превратить в последовательный вид доступ к общим данным. Обыч-
но организующую роль при синхронизации играет диспетчер распре-
деленных блокировок DLM (Distributed Lock Manager). Сервис DLM по-
зволяет приложениям отслеживать обращения к ресурсам кластера.
Если к одному ресурсу обращается более двух систем одновременно,
то диспетчер распознает и предотвращает потенциальный конфликт.
Процессы DLM могут приводить к дополнительному графику сообще-
ний в сети и снизить производительность. Один из способов избежать
этого эффекта - использование программной модели без общих ком-
понентов.

Модель без общих компонентов

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

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

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

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

Серверы кластерных приложений

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

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

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

Модели кластеров Windows NT

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

. модель 1 - высокая доступность и статическая балансировка на-
грузки;

. модель 2 - "горячий резерв" и максимальная доступность;

. модель 3 - частичная кластеризация;

. модель 4 - только виртуальный сервер (без переключения);

. модель 5 - гибридная.

Давайте вкратце рассмотрим эти модели.

Модель 1: высокая доступность и статическая
балансировка нагрузки

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

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

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


Конфигурация модели 1

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

Рассмотрим другой пример использования этой модели. Допустим, на
предприятии имеется почтовый сервер, на котором установлен Mic-
rosoft Exchange. В пиковые моменты нагрузки сервер не справляется и
отключается. Поскольку почта должна функционировать непрерывно,
можно предложить следующее решение. Сервер, на котором исполня-
ется Microsoft Exchange, объединяется в кластер с сервером, на кото-
ром в нормальном режиме работает приложение доступа к данным. В
момент сбоя почтового сервера его роль временно принимает на себя
второй сервер кластера. Но, подчеркиваю, это лишь временно, и сразу
после перезагрузки основного почтового сервера вся работа по обра-

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

Модель 2: "горячий резерв"
и максимальная доступность

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

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


Модель с "горячим резервированием"

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

Модель 3: частичная кластеризация

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

на локальном диске сервера. В случае сбоя сервера эти приложения
становятся недоступными.


Модель частичной кластеризации

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

Иногда случается, что модель переключения, обеспечиваемая Microsoft
Cluster Server, не годится для некоторых приложений. (Например, при
исполнении расчетной задачи переключение с узла на узел все равно
прервет процесс вычислений). Для таких приложений необходимы
иные, специфичные механизмы обеспечения бесперебойной работы.

Модель 4: только виртуальный сервер
(без переключения)

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

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

В случае сбоя сервера программное обеспечение кластера запускает
необходимые сервисы в указанном порядке сразу после перезагрузки.

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


Модель с одним виртуальным сервером

Модель 5: гибридное решение

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

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


Гибридное решение

Установка Microsoft Cluster Server

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

Прежде чем начать

Для установки MSCS (Microsoft Cluster Server) необходимо иметь следу-
ющее оборудование.

1. Два компьютера произвольной конфигурации. Характеристики
компьютеров могут различаться. Например, один имеет процессор

Pentium Pro с тактовой частотой 200 Мгц, объем ОЗУ - 256Мб, встро-
енный жесткий диск объемом 2 Гб. Второй - процессор Pentium II с
тактовой частотой 233 Мгц, объем ОЗУ б4Мб и встроенный жесткий
диск объемом 1 Гб. Разброс характеристик определяется используе-
мой Вами моделью: от практически идентичных (для режима "горя-
чего резервирования") до совершенно различных (для режима час-
тичной кластеризации).

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

Другим требованием является то, что SCSI ID одного из компьюте-
ров должен быть обязательно равен шести, а другого - семи.

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

между серверами;

на одном конце.

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


Связь с промежуточным расположением устройств хранения

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


Связь серверов с расположением общих дисков на одном конце

3. Не меыее 2 сетевых плат в каждом компьютере. Узлы в кластере
должны быть связаны между собой надежным каналом, называемым
интерконнектом (interconnect). По этому каналу они обменивают-
ся друг с другом информацией о своем состоянии. Предположим, в
качестве такого канала используется та же самая сетевая плата, что
и для доступа к ресурсам кластера. В этом случае велика вероятность,
что в моменты загрузки сети будет происходить ложное срабатыва-
ние процедуры переключения. При обоих работоспособных серве-
рах информация об их состоянии просто не будет доходить от од-
ного к другому. В результате оба сервера инициируют процесс пе-
реключения, что, вполне вероятно, приведет к сбою системы.


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

Взаимодействие между кластерами осуществляется по протоколу
TCP/IP. Поэтому Вам понадобится назначить адреса для сетевых карт
интерконнекта. Для этой цели можно использовать специальные
зарезервированные адреса:

10.0.0.1 - 10.255.255.254;

172.16.0.1 - 172.31.255.254;

192.168.0.1 - 192.168.255-254.

4. Общим дискам в серверах должны быть присвоены одинаковые
буквы. Например, если в одном из серверов локальные диски име-
ют буквы С, D и Е, а в другом - С, D, Е, F и G, то первый общий диск
в обеих системах должен быть диском Н.

Внимание! Все общие диски должны иметь формат NTFS.

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

После того, как выполнены все перечисленные условия, можно устанав-
ливать ПО MSCS.

Процедура установки

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

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

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

Администрирование кластера

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

Интерфейс программы весьма напоминает интерфейс консоли управ-
ления с загруженным слепком, однако теперь администратор класте-
ров не является слепком ММС.


Окно Cluster Administrator

Окно состоит из двух частей. В левой части в виде древовидной струк-
туры представлены элементы кластера: группы, доступные ресурсы,
сетевые интерфейсы, узлы и т. д. В правой - содержимое той или иной
ветви древовидной структуры кластера.

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

Создавать новый ресурс;

Создавать и модифицировать группу ресурсов кластера;

Управлять сетевыми интерфейсами;

Управлять ресурсами каждого из узлов в отдельности;

Имитировать сбой в работе ресурса;

Останавливать работу отдельных групп;

Перемещать ресурсы между группами.

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

Создание новой группы ресурсов

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


Назначение предпочтительного владельца группы ресурсов

Создание нового ресурса

В Microsoft Cluster Server можно создавать ресурсы одного из следую-
щих типов:

Координатор распределенных транзакций;

Совместно используемый файловый ресурс;

Приложение общего вида;

Сервис общего вида;

Виртуальный корень Internet Information Server;

Адрес IP;

Сервер очередей (Microsoft Message Queue Server);

Сетевое имя;

Физический диск;

Спулер печати;

Сервис таймера.


Добавление нового ресурса

Например, если Вы хотите добавить новый виртуальный корень для
своего сервера Web, то необходимо создать ресурс типа US Virtual Root.

Определение взаимозависимости ресурсов

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


Определение зависимости загрузки ресурсов

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

Определение свойств ресурса

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


Определение специфичных параметров ресурса

Редактирование свойств ресурсов

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


Модификация свойств f)ecvl)ca

В этом диалоговом окне можно изменить следующие параметры:

Имя и описание ресурса;

Возможных владельцев ресурса (на уровне серверов);

Последовательность загрузки сервисов, влияющих на работу редак-
тируемого ресурса;

Параметры перезапуска ресурса в случае сбоя;

Интервалы опроса;

Командную строку и параметры запуска.

Проверка работоспособности

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

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

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

Заключение

Windows NT 5.0 унаследовала от предыдущих версий все возможности
обеспечения бесперебойной работы. Средства поддержки отказоустой-
чивых дисковых томов, поддержка источников бесперебойного пита-
ния, улучшенная версия программы резервного копирования удачно
дополняются кластерными технологиями.

Несомненно, что перечисленные возможности в совокупности с под-
держкой аппаратных средств отказоустойчивости позволяют говорить
о Windows NT Server 5.0 как о серверной операционной системе, впол-
не способной удовлетворить потребности предприятий, где требуется
высокий уровень надежности.

13.12.2016, ВТ, 11:30, Мск

Современный мир все больше полагается на автоматизированные системы в самых разных областях человеческой деятельности. Растет число приложений, к непрерывной работе которых выдвигаются повышенные требования. Специалисты НПП «Родник» представляют коробочное решение Stratus everRun Enterprise, которое поможет быстро и просто обеспечить бесперебойную работу программного решения или сервиса.

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

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

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

Доступный сервис

С целью классификации компьютерные системы обычно разделяют по времени непрерывной работы, в процентах от общей длительности работы. Зачастую доступность сервиса или системы характеризуется параметром в 99–99,9% времени, и число «99,9» выглядит очень надежно. Но на практике это означает до 90 часов простоя в течение года, или же до полутора часов в неделю. Для восстановления работы такой системы обычно используется ее перезапуск, или восстановление из резервной копии.

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

Системы высокой доступности работоспособны 99,95–99,99% времени. Здесь используются кластерные системы и технологии, в которых выполнено то или иное запараллеливание сервисов и систем. «Высокая доступность», тем не менее, может означать до нескольких часов простоя в течение года. В зависимости от решения, дублирующий сервис или система могут находиться в так называемом «холодном» резерве, в этом случае для ее запуска требуется какое-то время. Также следует отметить сложность кластерных технологий и повышенные требования к квалификации ИТ-персонала. Кластеры сложны и отнимают много времени на развертывание, требуют тестирования и непрерывного административного контроля. Программное обеспечение обычно приходится лицензировать для каждого из серверов кластера. В результате в случае роста кластерной системы общая стоимость владения быстро растет.

Основные области применения Stratus everRun:

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

Cиловые структуры

Финансы и банковские услуги

Телекоммуникации

Медицина

Государственный сектор

Производство

Транспорт и логистика

Непрерывная доступность (англ. fault tolerance) – до 99,999% времени. Такой уровень надежности системы достигается специализированными программными и аппаратными решениями. В зависимости от предметной области (управление технологическими процессами, банковские системы), такие комплексы могут быть очень разными по сложности и стоимости.
Но, как отмечалось выше, есть и менее требовательные сферы применения, от которых ожидается непрерывная работа. Сюда можно отнести системы управления зданиями, системы внешнего контроля (видеонаблюдения), системы контроля доступа, и тому подобные. Вряд ли пользователи будут счастливы, если пропадет сигнал со всех видеокамер и датчиков, или система вентиляции цеха или здания остановит работу.

Готовое решение

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

Для систем непрерывной доступности одним из таких решений является программный пакет everRun Enterprise компании Stratus. Он специально спроектирован так, чтобы обеспечить сохранение данных даже при аппаратных или программных сбоях.

Преимущества решения

При использовании everRun Enterprise приложение «живет» в двух ВМ на двух физических серверах. Если одна ВМ выходит из строя, приложение продолжает работать на другом сервере без перерывов или потери данных. Это достигается за счет постоянного считывания состояния работающей виртуальной машины и сохранения ее параметров. В случае сбоя последнее состояние системы переносится на параллельно работающую ВМ, так что выполнение приложений не прерывается. Серверы системы могут быть географически разнесены для повышения надежности.

Программное обеспечение Stratus everRun предназначено для того, чтобы обеспечить непрерывную работу служебных приложений и целостность собираемых данных. При этом система, разумеется, обладает функционалом и для быстрого аварийного восстановления в случае крупного отказа. Решения Stratus everRun базируются на использовании стандартного оборудования, и защищают любые приложения для MS Windows Server и Linux от отказов и сбоев в работе аппаратной части серверов.

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

Как everRun Enterprise обеспечивает непрерывную работу и сохранение данных приложений, развернутых на виртуальных машинах

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http :// www . allbest . ru /

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

План лекции

1. Процесс выбора

2. Критерии оценки и выбора

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

Литература

1. Процесс выбора

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

· формулировка задач выбора, включая цели, предположения и ограничения;

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

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

· подготовка отчета по результатам выбора.

В процессе выбора возможно получение двух результатов:

· запроса на получение дополнительной информации к процессу оценки.

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

· использование предварительного отбора (например, отбор только средств, работающих на конкретной платформе);

· использование ранее полученных результатов оценки, результатов оценки из внешних источников или комбинации того и другого;

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

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

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

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

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

2. Критерии оценки и выбора

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

· числовые меры в широком диапазоне значений, например, объем требуемой памяти;

· числовые меры в ограниченном диапазоне значений, например, простота освоения, выраженная в баллах от 1 до 5;

· двоичные меры (истина/ложь, да/нет), например, способность генерации документации в формате Postscript;

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.

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

Рис. Структура набора критериев

Простота использования

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

· локализация (в соответствии с требованиями данной страны).

· простота освоения. Трудовые и временные затраты на освоение средств.

· адаптируемость к конкретным требованиям пользователя. Адаптируемость к различным алфавитам, режимам текстового и графического представления (слева-направо, сверху-вниз), различным форматам даты, способам ввода/вывода (экранным формам и форматам), изменениям в методологии (изменениям графических нотаций, правил, свойств и состава предопределенных объектов) и др.

· качество документации (полнота, понятность, удобочитаемость, полезность и др.).

· доступность и качество учебных материалов. Они могут включать компьютерные учебные материалы, учебные пособия, курсы.

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

· простота работы с CASE-средством (как для начинающих, так и для опытных пользователей).

· унифицированность пользовательского интерфейса (по отношению к другим средствам, использующимся в данной организации).

· онлайновые подсказки (полнота и качество).

· качество диагностики (понятность и полезность диагностических сообщений для пользователя).

· допустимое время реакции на действия пользователя (в зависимости от среды).

· простота установки и обновления версий.

Эффективность

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

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

· производительность. Время, затрачиваемое CASE-средством для выполнения конкретных задач (например, время ответа на запрос, время анализа 100000 строк кода). В некоторых случаях данные оценки производительности можно получить из внешних источников.

Сопровождаемость

· уровень поддержки со стороны поставщика (скорость разрешения проблем, поставки новых версий, обеспечение дополнительных возможностей).

· трассируемость обновлений (простота освоения отличий новых версий от существующих).

· совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным).

· сопровождаемость конечного продукта (простота внесения изменений в ПО и документацию).

Переносимость

· совместимость с версиями ОС (возможность работы в среде различных версий одной и той же ОС, простота модификации CASE-средства для работы с новыми версиями ОС).

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

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

Общие критерии

Приведенные ниже критерии являются общими по своей природе и не принадлежат к совокупности показателей качества, приведенной в стандарте ISO/IEC 9126: 1991.

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

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

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

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

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

· экспортные ограничения.

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

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

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

· адаптация, требуемая для внедрения CASE-средств в организации пользователя. Примером может быть определение способа использования централизованного CASE-средства с единой, общей БД в распределенной среде.

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

1. Какие действия включает процесс выбора CASE-средств?

2. Какие параметры, могут быть использованы для определения масштаба выбора CASE-средств?

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

4. Структура набора критериев

5. Функциональные характеристики.

6. Надежностьcase интерфейс оперативная память

7. Простота использования.

8. Эффективность

9. Сопровождаемость.

10. Переносимость.

11. Общие критерии.

Литература

1. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 2006

2. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 2006.

3. Создание информационной системы предприятия. "ComputerDirect", 2006, N2

4. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. Киев, "Диалектика", 2009.

5. Панащук С.А. Разработка информационных систем с использованием CASE-системы Silverrun. "СУБД", 2013, №3.

6. Горчинская О.Ю. Designer/2000 - новое поколение CASE-продуктов фирмы ORACLE. "СУБД", 2005, №3.

7. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. "СУБД", 1995, №3.

8. Горин С.В., Тандоев А.Ю. CASE-средство S-Designor 4.2 для разработки структуры базы данных. "СУБД", 2012, №1.

Размещено на Allbest.ru

...

Подобные документы

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

    курсовая работа , добавлен 18.07.2014

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

    курсовая работа , добавлен 13.10.2015

    Использование CASE-средств для поддержки процессов создания и сопровождения информационных систем. Задачи графического редактора диаграмм, документатора и администратора проекта. Основные возможности IBM Rational Professional Bundle и IBM Rational Rose.

    реферат , добавлен 30.05.2012

    Системы автоматического проектирования. Сравнительный анализ средств для проектирования автоматизированных информационных систем. Экспорт SQL-кода в физическую среду и наполнение базы данных содержимым. Этапы развития и характеристика Case-средств.

    курсовая работа , добавлен 14.11.2017

    Определение понятия CASE-технологий. Использование комплексного инструментария ER/Studio для создания логической и физической модели данных, генерирования баз данных на платформе СУБД Access. Процедура добавления атрибутов и сущностей, создания связей.

    контрольная работа , добавлен 21.12.2011

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

    дипломная работа , добавлен 20.07.2014

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

    контрольная работа , добавлен 27.09.2010

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

    презентация , добавлен 20.11.2013

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

    реферат , добавлен 24.02.2011

    Классификация автоматизированных информационных систем (АИС). Проектирование АИС складского учета с использованием CASE-средства Rational Rose. Подходы к проектированию, анализ CASE-средств. Программная реализация профессионально ориентированной АИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс оценки включает следующие действия:

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

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

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

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

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

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

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

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

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

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

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

Отчет по результатам оценки должен содержать следующую информацию:

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

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

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

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

В процессе выбора возможно получение двух результатов:

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

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

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

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

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

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

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

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

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

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

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.

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

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

Проектная среда:

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

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

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

ПО/технические средства:

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

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

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

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

Рис. 2. Структура набора критериев

Технологическая среда:

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

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

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

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

Моделирование:
Данные критерии определяют способность выполнения функций, необходимых для спецификации требований к ПО и преобразованию их в проект:

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

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

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

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

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

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

- проектирование архитектуры ПО . Проектирование логической структуры ПО - структуры модулей, интерфейсов и др.

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

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

- генерация экранных форм . Возможность генерации экранных форм на основе спецификаций требований и/или проектных спецификаций.

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

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

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

- автоматизированное проектирование отчетов.

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

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

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

- компиляция кода.

- конвертирование исходного кода . Возможность преобразования кода из одного языка в другой.

- анализ надежности . Возможность количественно оценивать параметры надежности ПО, такие, как количество ошибок и др.

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

- реструктуризация исходного кода . Возможность модификации формата и/или структуры существующего исходного кода.

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

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

Тестирование:
Критерии тестирования включают следующие:

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

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

- автоматический запуск тестовых примеров.

- регрессионное тестирование . Возможность повторения и модификации ранее выполненных тестов для определения различий в системе и/или среде.

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

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

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

- анализ исключительных ситуаций в процессе тестирования.

- динамическое моделирование среды. В частности, возможность автоматически генерировать моделируемые входные данные системы.

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

Документирование:

- редактирование текстов и графики . Возможность вводить и редактировать данные в текстовом и графическом формате.

- редактирование с помощью форм . Возможность поддерживать формы, определенные пользователями, вводить и редактировать данные в соответствии с формами.

- возможности издательских систем.

- поддержка функций и форматов гипертекста.

- соответствие стандартам документирования.

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

Управление конфигурацией:

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

- отслеживание модификаций . Фиксация и ведение журнала всех модификаций, внесенных в систему в процессе разработки или сопровождения.

- управление версиями . Ведение и контроль данных о версиях системы и всех ее коллективно используемых компонентах.

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

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

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

Управление проектом:

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

- оценка . Возможность оценивать затраты, график и другие проектные параметры, вводимые пользователями.

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

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

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

Надежность

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

Простота использования

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

Эффективность

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

Сопровождаемость

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

Переносимость

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

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

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

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

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

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

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

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

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

Рис. 3. Шаги пилотного проекта

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

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

Кроме того, организация должна учитывать продолжительность пилотного проекта (и в целом процесса внедрения). Слишком продолжительный проект связан с риском потери интереса к нему со стороны руководства.

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

  • цели, задачи и критерии оценки;
  • персонал;
  • процедуры и соглашения;
  • обучение;
  • график и ресурсы.

Цели, задачи и критерии оценки

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

· описать проект в терминах ожидаемых результатов (т.е. конечного продукта). Описание должно включать форму представления и содержание результатов. Должны быть четко определены договорные требования и соответствующие стандарты.

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

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

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

Персонал

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

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

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

Процедуры и соглашения

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

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

Обучение

Должны быть определены виды и объем обучения, необходимого для выполнения пилотного проекта. При планировании обучения нужно иметь в виду три вида потребностей: технические, управленческие и мотивационные. Ресурсы, требуемые для обучения (учебные аудитории и оборудование, преподаватели и учебные материалы), должны соответствовать плану пилотного проекта.

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

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

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

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

График и ресурсы

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

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

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

При выполнении курсовой работы я изучил и рассмотрел:

1. Выполнение оценки CASE – средств.

2. Изучил процесс выбора CASE – средств.

3. Узнал критерии оценки и выбора CASE – средств.

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

Из работы следует, что современные принципы и особенности проектирования оценки и выбора это CASE – средств основано на использовании структурного анализа, объектно-ориентированного моделирования, CASE – систем.

1. Алексеев А.А., Попенко Р.А. CASE-средства в информационной системе – СПб.: ЮНИТИ, 2003.

2. Баркин Р.С. CASE-метод. Моделирование – М.: Центр, 2003.

3. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений // СУБД – 2003. – №3.

4. Вендров А.М. Проектирование программного обеспечения экономических систем – М.: Финансы и статистика, 2005.

5. Вендров А.М. Объектно-ориентированный анализ и проектирование информационных систем c использованием языка UML и case-средства Rational Rose – М.: Академия АйТи, 2000.

6. Гнатуш А. CASE-технологии: что, когда, как? // IT-менеджер – 2004. – №16 (4).

7. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие – М.: Центр Информационных Технологий, 2002.

8. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение) – М.:Лори, 2003.

9. Королёв К.З. Информационные технологии и программное обеспечение. Учебник. М.: ДАНА, 2003.

10. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования – М.: МетаТехнология, 2003.

Характеристики CASE средств

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

  • Наличие графического интерфейса. Для представления моделей процессов CASE средства должны обладать возможностью отображать процессы в виде схем. Схемы много проще в использовании, чем различные текстовые и числовые описания. Это позволяет получать легко управляемые компоненты модели, обладающие простой и ясной структурой.
  • Наличие репозитория. Репозиторий это общая база данных, которая содержит описание элементов процессов и отношений между ними. Каждый объект репозитария должен обладать перечнем свойств, характерных только для этого объекта.
  • Гибкость применения. Эта характеристика дает возможность представлять бизнес процессы в различных вариантах, важных с точки зрения анализа. CASE средства должны позволять проводить анализ процессов и создавать модели, сфокусированные на различных аспектах деятельности предприятия.
  • Возможность коллективной работы. Анализ и моделирование процессов может требовать совместной работы нескольких человек. Для одновременной работы над моделями процессов CASE средства должны обеспечивать управление изменениями любыми фрагментами моделей и их модификацией при коллективном доступе.
  • Построение прототипов. Прототипы процессов необходимы для того, чтобы на ранних стадиях изменения процессов можно было понять, насколько процесс будет соответствовать требованиям.
  • Построение отчетов. CASE средства должны обеспечивать построение отчетов по всем моделям процессов с учетом взаимосвязи элементов. Такие отчеты необходимы для анализа моделей и определения возможностей по оптимизации. За счет отчетов обеспечивается контроль полноты и достаточности моделей, уровень декомпозиции процессов, правильность синтаксиса диаграмм и типов применяемых элементов.

Выбор CASE средств

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



Понравилась статья? Поделитесь ей
Распечатать статью
Наверх