(по материалам стандартов IEEE)
Определение потребностей в CASE-средствах
Оценка и выбор CASE-средств
Критерии оценки и выбора
Выполнение пилотного проекта
Переход к практическому использованию
CASE-средств
Данная статья представляет собой сокращенное изложение стандартов IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools и IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. Временной разрыв между их утверждением составляет 4 года (первый стандарт был утвержден в декабре 1996 г., а второй - в декабре 1992 г.), однако они достаточно тесно взаимосвязаны, поскольку первый стандарт содержит целый ряд ссылок на второй. Цель приведенных в стандартах рекомендаций - предоставить руководство, позволяющее повысить вероятность успешного внедрения CASE-технологии. Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками CASE-средств в течение длительного периода их существования.
Термин "adoption" (внедрение) используется в широком смысле. Он включает все действия, от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации. Под CASE-средством понимается программное средство, поддерживающее процессы создания и сопровождения программного обеспечения (ПО), включая анализ и формулировку требований, проектирование ПО, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы (CASE-средство может обеспечивать поддержку только в заданных функциональных областях или в широком диапазоне функциональных областей). Под средой разработки ПО понимается совокупность CASE-средств, объединенных вместе для поддержки определенных методов, технологий, принципов и стандартов, определяющих деятельность в процессе разработки ПО. Интеграционные механизмы могут иметь различные уровни и формы, такие как база данных, система сообщений, согласованный протокол передачи или общая схема.
Многие организации-разработчики ПО, пытаясь внести усовершенствования в процесс разработки, обращаются к CASE-технологии. Однако несмотря на ее потенциальные возможности, некоторые организации не достигают ожидаемых выгод и результатов.
В то время как существует много возможных причин неудач в достижении желаемых результатов с помощью CASE-технологии, причина наиболее значительных расхождений между ожидаемыми результатами и реальностью заключается, по-видимому, в неадекватном понимании сути процесса разработки ПО и практики внедрения CASE-средств. Этот факт является критическим в плане долговременного успеха внедрения CASE-технологии в организации.
Ключом к успешному внедрению CASE-средств является готовность организации, которая включает следующие аспекты:
Технология. Понимание существующих возможностей и способность
принять новую технологию;
Культура. Готовность к внедрению новых процессов и взаимодействий;
Управление. Четкое руководство и организованность по отношению
к наиболее важным процессам.
Для того чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, организация вынуждена производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных "подводных камней" использования CASE-средств. Среди наиболее серьезных проблем необходимо отметить следующие:
оценка отдачи от инвестиций в CASE-средства. Достоверная оценка
CASE-средств затруднительна ввиду отсутствия приемлемых метрик и данных
по проектам и процессам разработки ПО;
гарантированные обязательства руководства по отношению к использованию
CASE-средств. Внедрение CASE-средств может представлять собой достаточно
длительный процесс и может не принести немедленной отдачи. Вследствие этого
руководство организации может утратить интерес и прекратить выполнение
своих обязательств по отношению к их использованию;
инвестируемые ресурсы. Затраты на внедрение CASE-средств оказываются
обычно большими, чем ожидает большинство организаций;
существующие процессы и методы. Часто встречающееся отсутствие
полного соответствия между теми процессами и методами, которые поддерживаются
CASE-средствами, и теми, которые используются в данной организации, может
привести к дополнительным трудностям;
интеграция средств. CASE-средства зачастую трудно использовать
в комплексе с другими подобными средствами. Это объясняется как различными
парадигмами, поддерживаемыми различными средствами, так и проблемами передачи
данных и управления от одного средства к другому;
накладные расходы. Некоторые CASE-средства требуют слишком много
усилий для того, чтобы оправдать их использование в небольшом проекте при
этом, тем не менее, можно извлечь выгоду из дисциплины, к которой обязывает
их применение;
персонал. Иногда негативное отношение персонала к внедрению
новой CASE-технологии может быть главной причиной провала проекта.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых релизов и возможному быстрому моральному старению средств, а также постоянным затратам на обучение нового персонала и повышение квалификации действующего персонала.
Процесс внедрения CASE-средств состоит из следующих шагов:
1. Определение потребностей в CASE-средствах;
2. Оценка и выбор CASE-средств;
3. Выполнение пилотного проекта;
4. Практическое внедрение CASE-средств.
Определение потребностей в CASE-средствах
Данный шаг включает следующие действия:
анализ возможностей организации и ее готовности к внедрению CASE-средств;
определение организационных потребностей;
обзор рынка CASE-средств;
определение критериев успешного внедрения;
разработка стратегии внедрения CASE-средств.
Анализ возможностей организации в категориях процессов использования в ней ПО, технологической базы и персонала может быть формальным или неформальным. Формальные подходы определяются моделью CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001: 1994, ISO 9003-3: 1991 и ISO 9004-2:1991.
Организационные потребности выводятся непосредственно из проблем организации и целей, которые она стремится достичь. Проблемы и цели могут быть связаны с управлением, процессами, производством продукции, экономикой, персоналом или технологией.
Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке или собственными возможностями разработки. В процессе обзора важным является приобретение опыта работы с литературой по CASE-средствам, посещение конференций и семинаров, проводимых поставщиками и пользователями CASE-средств. Возможность интеграции CASE-средства с другими средствами, используемыми (или планируемыми к использованию) организацией, может являться важным фактором при выполнении данного обзора. Кроме того, важно получить достоверную информацию о средствах, основанную на реальном пользовательском опыте и сведениях от пользовательских групп.
Стратегия внедрения CASE-средств должна обеспечивать удовлетворение определенных потребностей и критериев. Данная стратегия определяет следующее:
организационные потребности;
критерии успешного внедрения, связанные с удовлетворением организационных
потребностей, включая ожидаемые результаты последовательных шагов процесса
внедрения;
подразделения организации, в которых должно выполняться внедрение CASE-средств;
стратегии и планы оценки и выбора, пилотного проектирования и перехода
к полномасштабному внедрению;
основные факторы риска;
ориентировочный уровень и источники финансирования процесса внедрения
CASE-средств;
ключевой персонал и другие ресурсы.
Необходимо отметить, что внедрение новой технологии может включать важные и трудные изменения в культуре организации. Существенное внимание должно уделяться ролям различных групп, вовлеченных в процесс таких изменений. Наиболее существенные роли включают следующие:
спонсор (обычно из числа менеджеров высшего уровня). Данная роль является
критической для поддержки проекта и обеспечения необходимого финансирования.
Спонсор должен обладать четким пониманием необходимости серьезных усилий,
связанных с внедрением CASE-средств, и длительности периода ожидания осязаемых
результатов.
исполнитель - обычно лицо (или группа лиц), осознающее потенциальные
возможности новой технологии, пользующееся авторитетом среди технического
персонала и способное возглавить процесс внедрения новой технологии.
целевая группа - обычно включает менеджеров и технический персонал,
которые будут привлечены к непосредственному использованию CASE-средств,
а также специалистов, которые будут привлечены косвенно, таких, как специалисты
по документированию, персонал поддержки сети и заказчики. Должны быть определены
потребности каждой из таких групп и план их эффективного удовлетворения.
Оценка и выбор CASE-средств
Процесс оценки и выбора может преследовать несколько целей, включая одну или более из следующих:
оценка нескольких CASE-средств и выбор одного или более из них;
оценка одного или более CASE-средств и сохранение результатов для последующего
использования;
выбор одного или более CASE-средств с использованием результатов предыдущих
оценок.
Входной информацией для процесса оценки является:
определение пользовательских потребностей;
цели и ограничения проекта;
данные о доступных CASE-средствах;
список критериев, используемых в процессе оценки.
Процесс оценки и/или выбора может быть начат только тогда, когда лицо, группа или организация полностью определила для себя конкретные потребности и формализовала их в виде количественных и качественных требований в заданной предметной области. Термин "пользовательские требования" далее означает именно такие формализованные требования.
Процесс оценки включает следующие действия:
формулировка задачи оценки, включая информацию о цели и масштабах оценки;
определение средств-кандидатов путем просмотра списка кандидатов и
анализа информации о конкретных средствах;
оценка средств-кандидатов в контексте выбранных критериев.
Список CASE-средств - возможных кандидатов формируется из различных источников: обзоров рынка ПО, информации поставщиков, обзоров CASE-средств и других подобных публикаций. Сами CASE-средства могут быть получены путем приобретения, в виде оценочной копии или другими способами.
Оценка и накопление информации о CASE-средствах может выполняться следующими способами:
анализ CASE-средств и документации поставщика;
опрос реальных пользователей;
анализ результатов проектов, использовавших данные CASE-средства;
просмотр демонстраций и опрос демонстраторов;
выполнение тестовых примеров;
применение CASE-средств в пилотных проектах;
анализ любых доступных результатов предыдущих оценок.
Результаты оценки должны быть стандартным образом документированы (для облегчения последующего использования) и, при необходимости, утверждены.
Процессы оценки и выбора тесно взаимосвязаны друг с другом. По результатам оценки цели выбора и/или критерии выбора и их веса могут потребовать модификации. В таких случаях может потребоваться повторная оценка. Когда анализируются окончательные результаты оценки и к ним применяются критерии выбора, может быть рекомендовано приобретение CASE-средства или набора CASE-средств. Альтернативой может быть отсутствие адекватных CASE-средств, в этом случае рекомендуется разработать новое CASE-средство, модифицировать существующее или отказаться от внедрения.
В процессе выбора возможно получение двух результатов:
рекомендаций по выбору конкретного CASE-средства;
запроса на получение дополнительной информации к процессу оценки.
Если ни одно из CASE-средств не удовлетворяет минимальным критериям, выбор (возможно, вместе с оценкой) может быть повторен для других CASE-средств - кандидатов.
Если различия между самыми предпочтительными кандидатами несущественны, дополнительная информация может быть получена путем повторного выбора (возможно, вместе с оценкой) с использованием дополнительных или других критериев.
Критерии формируют базис для процессов оценки и выбора. Критерии могут принимать различные формы, включая:
числовые меры в широком диапазоне значений, например, объем требуемой
памяти;
числовые меры в ограниченном диапазоне значений, например, простота
освоения, выраженная в баллах от 1 до 5;
двоичные меры (истина/ложь, да/нет), например, способность генерации
документации в формате Postscript;
меры, которые могут принимать одно или более из конечных множеств значений,
например, платформы, для которых поддерживается CASE-средство.
В большинстве случаев только некоторые из множества описанных ниже критериев оказываются приемлемыми для использования, при этом также могут добавляться дополнительные критерии.
Критерии оценки и выбора
1) Функциональные характеристики
Критерии данного класса предназначены для определения функциональных характеристик CASE-средства. Они в свою очередь подразделяются на ряд групп и подгрупп.
1. Среда функционирования
а) Проектная среда:
поддержка процессов жизненного цикла (ЖЦ) ПО. Определяет набор процессов
ЖЦ, которые поддерживает CASE-средство. Примерами таких процессов являются
анализ требований, проектирование, реализация, тестирование и оценка, сопровождение,
обеспечение качества, управление конфигурацией и управление проектом, причем
они зависят от принятой пользователем модели ЖЦ;
размер поддерживаемых приложений. Определяет ограничения на такие величины,
как количество строк кода, уровней вложенности, размер базы данных, количество
элементов данных, количество объектов конфигурационного управления.
б) ПО/технические средства:
требуемые технические средства. Оборудование, необходимое для функционирования
CASE-средства, включая хост-процессоры, оперативную память и дисковую память;
требуемое ПО. ПО, необходимое для функционирования CASE-средства, включая
операционные системы и графические оболочки.
в) Технологическая среда:
соответствие стандартам технологической среды. Такие стандарты касаются
языка, базы данных, репозитория, коммуникаций, графического интерфейса
пользователя, документации, разработки, управления конфигурацией, безопасности,
стандартов обмена информацией и интеграции по данным, по управлению и по
пользовательскому интерфейсу;
совместимость с другими средствами. Способность к взаимодействию с
другими средствами, включая непосредственный обмен данными. Примерами таких
средств являются текстовые процессоры и другие средства документирования,
базы данных, репозитории и другие CASE-средства;
поддерживаемая методология. Набор методов и методик, поддерживаемых
CASE-средством (например, объектно-ориентированное или структурное проектирование);
поддерживаемые языки. Примерами таких языков являются языки программирования
(Кобол, Ада, С), языки баз данных и языки запросов (SQL), графические языки
(Postscript, HPGL), языки спецификации проектных требований и интерфейсы
операционных систем (языки управления заданиями).
2. Функции, ориентированные на фазы жизненного цикла
а) Моделирование:
Данные критерии определяют способность выполнения функций, необходимых для спецификации требований к ПО и преобразованию их в проект. Они включают следующие критерии:
построение и анализ диаграмм. Наиболее распространенные типы диаграмм
включают диаграммы Бахмана, блок-схемы, диаграммы управляющих потоков и
потоков данных, функциональные декомпозиции, ER-диаграммы, диаграммы HIPO,
Джексона, Насси-Шнейдермана, объектно-ориентированные диаграммы, сети Петри,
диаграммы переходов состояний, структурные схемы программ и диаграммы Варнье-Орра;
ввод и редактирование спецификаций требований и проектных спецификаций.
К спецификациям такого рода относятся описания функций, данных, интерфейсов,
качества, производительности, технических средств, среды, затрат и графиков;
моделирование данных и процессов. Возможность ввода и редактирования
информации, описывающей элементы данных системы, процессы системы и их
отношения;
имитационное моделирование. Возможность динамического моделирования
различных аспектов функционирования системы на основе спецификаций требований
и/или проектных спецификаций, включая внешний интерфейс и производительность
(например, время отклика, коэффициент использования ресурсов и пропускную
способность);
прототипирование. Возможность проектирования и генерации предварительного
варианта всей системы или ее отдельных компонентов на основе спецификаций
требований и/или проектных спецификаций;
генерация экранных форм;
возможность трассировки. Возможность сквозного анализа функционирования
системы от спецификации требований до конечных результатов;
проверка спецификаций на полноту и непротиворечивость;
другие виды анализа. Конкретные дополнительные виды анализа могут включать
алгоритмы, управляющие потоки, потоки данных, нормализацию данных, использование
данных, пользовательский интерфейс;
автоматизированное проектирование отчетов.
б) Реализация:
Реализация затрагивает функции, связанные с созданием исполняемых элементов системы (программных кодов) или модификацией существующей системы. Многие критерии в данном параграфе зависят от конкретного языка или языков, примеры которых приведены выше в технологической среде. Критерии реализации включают следующие:
синтаксически управляемое редактирование. Возможность ввода и редактирования
исходных кодов на одном или нескольких языках с одновременным синтаксическим
контролем;
генерация кода. Возможность генерации кодов на одном или нескольких
языках на основе проектных спецификаций. Типы генерируемого кода могут
включать код общего назначения, схему базы данных, запросы, экраны/меню;
конвертирование исходного кода. Возможность преобразования кода из
одного языка в другой;
анализ надежности. Возможность количественно оценивать параметры надежности
ПО, такие как количество ошибок и др;
реверсный инжиниринг. Возможность анализа существующих исходных кодов
и формирования на их основе проектных спецификаций;
реструктуризация исходного кода. Возможность модификации формата и/или
структуры существующего исходного кода;
анализ исходного кода. Примерами такого анализа могут быть определение
размера кода, вычисление показателей сложности, генерация перекрестных
ссылок и проверка на соответствие стандартам.
в) Тестирование:
Критерии тестирования включают следующее:
описание тестов. Типичные возможности включают генерацию тестовых данных,
алгоритмов тестирования, требуемых результатов и т. д;
фиксация и повторение действий оператора. Возможность фиксировать данные,
вводимые оператором с помощью клавиатуры, мыши и т. д., редактировать их
и воспроизводить в тестовых примерах;
регрессионное тестирование. Это касается, в частности, возможности
повторения и модификации ранее выполненных тестов для определения различий
в системе и/или среде;
автоматизированный запуск тестовых примеров и анализ результатов тестирования.
Типичные возможности включают сравнение ожидаемых и реальных результатов,
сравнение файлов, статистический анализ результатов и др.;
анализ производительности. Возможность анализа производительности программ.
Анализируемые параметры производительности могут включать использование
центрального процессора, памяти, обращения к определенным элементам данных
и/или сегментам кода, временные характеристики и т. д.
3. Общие функции
Приведенные ниже критерии определяют функции CASE-средств, охватывающие всю совокупность фаз ЖЦ. Поддержка всех этих функций осуществляется посредством репозитория.
а) Документирование:
редактирование текстов и графики;
редактирование с помощью форм. Возможность поддерживать формы, определенные
пользователями, вводить и редактировать данные в соответствии с формами;
возможности издательских систем;
поддержка функций и форматов гипертекста;
соответствие стандартам документирования;
автоматическое извлечение данных и генерация документации по спецификациям
пользователя.
б) Управление конфигурацией:
контроль доступа и изменений. Возможность контроля доступа на физическом
уровне к элементам данных и контроля изменений. Контроль доступа включает
возможности определения прав доступа к компонентам, а также извлечения
элементов данных для модификации, блокировки доступа к ним на время модификации
и помещения обратно в репозиторий;
отслеживание модификаций. Фиксация и ведение журнала всех модификаций,
внесенных в систему в процессе разработки или сопровождения;
управление версиями. Ведение и контроль данных о версиях системы и
всех ее коллективно используемых компонентах;
учет состояния объектов конфигурационного управления. Возможность получения
отчетов о всех последовательных версиях, содержимом и состоянии различных
объектов конфигурационного управления;
генерация версий. Поддержка пользовательского описания последовательности
действий, требуемых для формирования версии ПО, и автоматическое выполнение
этих действий;
архивирование. Возможность автоматического архивирования элементов
данных для последующего использования.
в) Управление проектом:
оценка. Возможность оценивать затраты, график и другие проектные параметры,
вводимые пользователями;
управление работами и ресурсами. Возможность поддержки плановых данных,
фактических данных и их анализа. Типичные данные включают графики (с учетом
календаря, рабочих часов, выходных и др.), компьютерные ресурсы, распределение
персонала, бюджет и др.;
управление процедурой тестирования. Поддержка управления процедурами
и программой тестирования, например, управления расписанием планируемых
процедур, фиксация и запись результатов тестирования, генерация отчетов
и т. д.;
управление качеством. Ввод соответствующих данных, их анализ и генерация
отчетов.
2) Надежность
целостность данных;
автоматическое резервирование;
безопасность (защита от несанкционированного доступа);
обработка ошибок (обнаружение ошибок в работе системы, извещение пользователя,
корректное завершение работы или сохранение состояния к моменту прерывания);
анализ отказов в критических приложениях.
3) Простота использования
удобство пользовательского интерфейса. Касается расположения и представления
часто используемых элементов экрана, способов ввода данных и др.;
локализация (в соответствии с требованиями данной страны);
простота освоения, установки и обновления версий (трудовые и временные
затраты);
адаптируемость к конкретным требованиям пользователя (различным алфавитам,
режимам текстового и графического представления (слева-направо, сверху-вниз),
различным форматам даты, способам ввода/вывода (экранным формам и форматам),
изменениям в методологии и др.);
качество документации (полнота, понятность, удобочитаемость, полезность
и др.);
доступность и качество учебных материалов. Они могут включать компьютерные
учебные материалы, учебные пособия, курсы;
требования к уровню знаний. Квалификация и опыт, необходимые для эффективного
использования CASE-средств;
простота работы с CASE-средством (как для начинающих, так и для опытных
пользователей);
унифицированность пользовательского интерфейса (по отношению к другим
средствам, использующимся в данной организации);
онлайновые подсказки (полнота и качество);
качество диагностики (понятность и полезность диагностических сообщений
для пользователя).
4) Эффективность
требования к оптимальному размеру внешней и оперативной памяти, типу
и производительности процессора, обеспечивающим приемлемый уровень производительности;
эффективность рабочей нагрузки. Эффективность выполнения CASE-средством
своих функций в зависимости от интенсивности работы пользователя (например,
количество нажатий клавиш или кнопки мыши, требуемое для выполнения определенных
функций);
производительность. Время, затрачиваемое CASE-средством для выполнения
конкретных задач (например, время ответа на запрос, время анализа 100000
строк кода). В некоторых случаях данные оценки производительности можно
получить из внешних источников.
5) Сопровождаемость
уровень поддержки со стороны поставщика (скорость разрешения проблем,
поставки новых версий, обеспечение дополнительных возможностей);
трассируемость обновлений (простота освоения отличий новых версий от
существующих);
совместимость обновлений (совместимость новых версий с существующими,
включая, например, совместимость по входным или выходным данным);
сопровождаемость конечного продукта (простота внесения изменений в
ПО и документацию).
6) Переносимость
совместимость с версиями ОС. Возможность работы в среде различных версий
одной и той же ОС, простота модификации CASE-средства для работы с новыми
версиями ОС;
переносимость данных между различными версиями CASE-средства;
соответствие стандартам переносимости. Такие стандарты включают документацию,
коммуникации и пользовательский интерфейс, оконный интерфейс, языки программирования,
языки запросов и др.
7) Общие критерии
затраты на CASE-средство (включают стоимость приобретения, установку,
начальное сопровождение и обучение. Следует учитывать цену для всех необходимых
конфигураций, включая единственную копию, много копий, локальную лицензию,
лицензию для предприятия, сетевую лицензию);
оценочный эффект от внедрения CASE-средства (уровень продуктивности,
качества и т. д.). Такая оценка может потребовать экономического анализа;
профиль дистрибьютора. Общие показатели возможностей дистрибьютора.
Профиль дистрибьютора может включать величину его организации, стаж в бизнесе,
финансовое положение, список любых дополнительных продуктов, деловые связи
(в частности, с другими дистрибьюторами средства), планируемая стратегия
развития;
сертификация поставщика. Сертификаты, полученные от специализированных
организаций в области создания ПО (например, SEI и ISO), удостоверяющие,
что квалификация поставщика в области создания и сопровождения ПО удовлетворяет
некоторым минимально необходимым или вполне определенным требованиям;
лицензионная политика. Доступные возможности лицензирования, право
копирования (носителей и документации), любые ограничения и/или штрафные
санкции за вторичное использование (подразумевается продажа пользователем
CASE-средства продуктов, в состав которых входят некоторые компоненты CASE-средства,
использовавшиеся при разработке продуктов);
экспортные ограничения;
профиль продукта. Общая информация о продукте, включая срок его существования,
количество проданных копий, наличие, размер и уровень деятельности пользовательской
группы, система отчетов о проблемах, программа развития продукта, совокупность
применений, наличие ошибок и др.;
поддержка поставщика. Доступность, реактивность и качество услуг, предоставляемых
поставщиком для пользователей CASE-средств. Такие услуги могут включать
телефонную "горячую линию", местную техническую поддержку, поддержку
в самой организации;
доступность и качество обучения.
Выполнение пилотного проекта
Пилотный проект представляет собой первоначальное реальное использование CASE-средства в предназначенной для этого среде и должен обладать многими из характеристик реальных проектов, для которых предназначено данное средство. Пилотный проект преследует следующие цели:
подтвердить достоверность результатов оценки и выбора;
определить, действительно ли CASE-средство годится для использования
в данной организации, и если да, то определить наиболее подходящую область
его применения;
собрать информацию, необходимую для разработки плана практического
внедрения;
приобрести собственный опыт использования CASE-средства.
Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования CASE-средства. Провал пилотного проекта позволяет избежать более значительных и дорогостоящих неудач в дальнейшем, поскольку пилотный проект обычно связан с приобретением относительно небольшого количества лицензий и обучением узкого круга специалистов.
Пилотный проект включает следующие шаги:
определение характеристик пилотного проекта;
планирование пилотного проекта;
выполнение пилотного проекта;
оценка пилотного проекта и принятие решения о внедрении.
Пилотный проект должен обладать следующими характеристиками:
представительность. Пилотный проект не должен быть необычным
или уникальным, его предметная область должна быть типичной для обычной
деятельности организации. CASE-средство должно использоваться для решения
задач, относящихся к предметной области, хорошо понимаемой всей организацией;
масштабируемость. Результаты, полученные в пилотном проекте,
должны дать четкое представление о масштабах проектов, для которых данное
средство применимо;
критичность. Пилотный проект должен иметь существенную значимость,
чтобы оказаться в центре внимания, но не должен быть критичным для успешной
деятельности организации в целом. При выборе пилотного проекта приходится
решать следующую дилемму: успех незначительного проекта может остаться
незамеченным, с другой стороны, провал значимого проекта может вызвать
чрезмерную критику;
авторитетность проектной группы. Группа специалистов, участвующих
в проекте, должна обладать высоким авторитетом, при этом результаты проекта
будут всерьез восприняты остальными сотрудниками организации. Проектная
группа должна обладать готовностью к нововведениям, технической зрелостью
и приемлемым уровнем опыта и знаний в данной технологии и предметной области.
С другой стороны, группа должна отражать в миниатюре характеристики всей
организации в целом.
Пилотный проект должен быть таким, чтобы перечисленные выше характеристики были сбалансированы с реальными условиями организации. Кроме того, организация должна учитывать продолжительность пилотного проекта (и в целом процесса внедрения). Слишком продолжительный проект связан с риском потери интереса к нему со стороны руководства.
Планирование пилотного проекта должно по возможности вписываться в обычный процесс планирования проектов в организации. План должен содержать следующую информацию:
цели, задачи и критерии оценки. Для определения целей, задач
и критериев оценки необходимо выполнить следующие действия: а) описать
проект в терминах ожидаемых результатов; б) определить общие цели проекта;
в) определить конкретные задачи, реализующие поставленные цели; г) определить
критерии оценки результатов. Примером критерия может быть степень непротиворечивости
проектной документации и контролируемости выполнения требований к ПО;
персонал. Он должен включать как технических специалистов, так
и менеджеров, заинтересованных в новой технологии и разбирающихся в ее
использовании. Группа должна обладать высокими способностями к коммуникации,
знанием особенностей организационных процессов и процедур, а также предметной
области. Группа не должна, тем не менее, состоять полностью из специалистов
высшего звена, она должна представлять средний уровень организации;
процедуры и соглашения. Примерами процедур и соглашений являются
методология, технические соглашения (в частности, по наименованиям и структуре
каталогов, стандарты проектирования и программирования) и организационные
соглашения (в частности, учет использования ресурсов, авторизация, контроль
изменений, процедуры экспертизы и подготовки отчетов, стандарты проверки
качества);
обучение. Должны быть определены виды и объем обучения, необходимого
для пилотного проекта. Ресурсы, требуемые для обучения (учебные аудитории
и оборудование, преподаватели и учебные материалы), должны соответствовать
плану пилотного проекта. Обучение, которое проводится в период выполнения
проекта, должно начинаться как можно быстрее после начала проекта. Обучение
средствам, процессам или методам, которые не будут использоваться в течение
нескольких месяцев после начала проекта, должно планироваться в то время,
когда в них возникнет реальная потребность;
график и ресурсы. Ресурсы включают персонал, технические средства,
ПО и финансирование. Данные о персонале могут определять конкретных специалистов
или требования к квалификации, необходимой для успешного выполнения пилотного
проекта. Финансирование должно определяться отдельно по каждому виду работ:
приобретение CASE-средств, установка, обучение, отдельные этапы проектирования.
Пилотная природа проекта требует специального внимания к вопросам приобретения, поддержки, экспертизы и обновления версий. После того как CASE-средство выбрано, оно должно быть приобретено, интегрировано в проектную среду и настроено в соответствии с требованиями пилотного проекта. Процесс приобретения может включать подготовку контракта, переговоры, лицензирование и другую деятельность, которая выходит за рамки данных рекомендаций. Эта деятельность требует затрат времени и человеческих ресурсов, которые должны быть учтены при планировании. План должен предусматривать отказ от выбранного средства на данном этапе из-за договорных разногласий.
После того как процесс приобретения завершен, средство должно быть установлено, оттестировано и принято в эксплуатацию. Тестирование позволяет убедиться, что поставленный продукт соответствует требованиям контракта, обладает необходимой полнотой и корректностью. Этап приемки может быть предусмотрен контрактом, его реальный срок может отличаться от того, который был предусмотрен первоначально в плане пилотного проекта. Особое внимание необходимо уделить соблюдению всех требований поставщика к параметрам среды функционирования CASE-средства.
После завершения приемки может потребоваться некоторая настройка и интеграция. Настройка может включать модификацию интерфейсов, связанную с требованиями специалистов проектной группы, а также с установкой прав доступа и привилегий. Настройка должна оставаться в рамках тех возможностей, которые предоставляет само средство. Не следует заниматься модификацией готовых продуктов на уровне исходных кодов.
Если новое средство должно использоваться в совокупности с некоторыми другими средствами, необходимо определить взаимодействие средств и требуемую интеграцию. Для интеграции новых средств с существующими может потребоваться построение специальных оболочек. Сложная интеграция может потребовать привлечения сторонних экспертов.
Доступная поддержка должна включать (по соглашению) "горячую линию" поставщика и поддержку местного поставщика, поддержку в самой организации, контакты с опытными пользователями в других организациях и участие в работе групп пользователей. Внутренняя поддержка должна включать доступ к специалистам, знакомым с установкой средств и работой с ними. Существует несколько возможных вариантов получения такой поддержки (например, от специалиста данной организации, имеющего опыт предшествующей работы со средством; участников процесса оценки и выбора или опытного консультанта). Такой тип поддержки должен специальным образом планироваться и администрироваться. Особое внимание должно быть уделено средствам, работающим в сетях или обладающих репозиториями, поддерживающими многопользовательскую работу.
Пользователи CASE-средства могут ожидать периодического обновления версий со стороны поставщика в течение выполнения пилотного проекта. При этом необходимо тщательное отношение к интеграции этих версий. Следует заранее оценить влияние этих обновлений на ход проекта. Новые версии могут как обеспечить новые возможности, так и породить новые проблемы. В то же время новая версия может потребовать видоизмененного или дополнительного обучения, а также может оказать отрицательное воздействие на уже выполненную к этому моменту работу.
После завершения пилотного проекта его результаты необходимо оценить и сопоставить их с изначальными потребностями организации, критериями успешного внедрения CASE-средств, базовыми метриками и критериями успеха пилотного проекта. Такая оценка должна установить возможные проблемы и важнейшие характеристики пилотного проекта, которые могут повлиять на пригодность CASE-средства для организации. Она должна также указать проекты или структурные подразделения внутри организации, для которых данное средство является подходящим. Помимо этого, оценка может дать информацию относительно совершенствования процесса внедрения в дальнейшем.
Возможным решением о внедрении должно быть одно из следующих:
внедрить средство. В этом случае рекомендуемый масштаб внедрения должен
быть определен в терминах структурных подразделений и предметной области;
выполнить дополнительный пилотный проект. Такой вариант должен рассматриваться
только в том случае, если остались конкретные неразрешенные вопросы относительно
внедрения CASE-средства в организации. Новый пилотный проект должен быть
таким, чтобы ответить на эти вопросы;
отказаться от средства. В этом случае причины отказа от конкретного
средства должны быть определены в терминах потребностей организации или
критериев, которые остались неудовлетворенными. Перед тем как продолжить
деятельность по внедрению CASE-средств, потребности организации должны
быть пересмотрены на предмет своей обоснованности;
отказаться от использования CASE-средств вообще. Пилотный проект может
показать, что организация либо не готова к внедрению CASE-средств, либо
автоматизация данного аспекта процесса создания и сопровождения ПО не дает
никакого эффекта для организации. В этом случае причины отказа от CASE-средств
должны быть также определены в терминах потребностей организации или критериев,
которые остались неудовлетворенными. При этом необходимо понимать отличие
этого варианта от предыдущего, связанного с недостатками конкретного средства.
Переход к практическому использованию CASE-средств
Процесс перехода к практическому использованию CASE-средств начинается с разработки и последующей реализации плана перехода. План перехода должен включать:
информацию относительно целей, критериев оценки, графика и возможных
рисков, связанных с реализацией плана;
информацию относительно приобретения, установки и настройки средства
(совокупность программных компонентов, документации и обучения, которые
необходимо приобретать для каждой отдельной платформы; механизм получения
новых версий; настройка средства, необходимая для выполнения существующих
в организации процедур и соглашений; лицо или подразделение, ответственное
за установку, интеграцию, настройку и эксплуатацию средства; план конвертирования
данных и снятия старых средств с эксплуатации). Задачи приобретения, установки
и настройки должны быть как можно быстрее переданы из группы пилотного
проекта в существующую службу системной поддержки ПО организации;
информацию относительно интеграции средства с существующими средствами,
включая как интеграцию CASE-средств друг с другом, так и их интеграцию
в процессы разработки и эксплуатации ПО, существующие в организации;
ожидаемые потребности в обучении и ресурсы, используемые в течение
и после завершения процесса перехода;
определение стандартных процедур использования средств, включающих
следующее:
- - стандарты использования средств;
- - руководства по моделированию и проектированию;
- - соглашения по присвоению имен;
- - процедуры контроля качества и процессов приемки, включая расписание
экспертиз и используемые методологии;
- - процедуры резервного копирования, защиты мастер-копий и конфигурирования
базы данных;
- - процедуры интеграции с существующими средствами и базами данных;
- - процедуры совместного использования данных и контроля целостности
БД;
- - стандарты и процедуры обеспечения секретности;
- - стандарты документирования.
Стандарты использования CASE-средств, выработанные во время пилотного проекта, должны использоваться в качестве отправной точки для разработки более полного набора стандартов использования средств в данной организации. При этом должен учитываться опыт участников пилотного проекта.
Реализация плана перехода требует постоянного мониторинга использования CASE-средств, обеспечения текущей поддержки, сопровождения и обновления средств по мере необходимости.
Достигнутые результаты должны периодически подвергаться экспертизе, план перехода должен корректироваться при необходимости. Постоянное внимание должно уделяться степени удовлетворения потребностей организации и критериев успешного внедрения CASE-средств. Периодические экспертизы должны продолжаться и после завершения процесса внедрения. Такие экспертизы могут анализировать метрики и другую информацию, получаемую в процессе работы с CASE-средствами, чтобы определять, насколько хорошо они продолжают выполнять требуемые функции. Такие экспертизы могут также указать на необходимость дополнительной модификации процессов.
Необходимо определить источники для текущей поддержки CASE-средств. Такая поддержка необходима для следующего:
ответов на вопросы, связанные с использованием средств;
передачи информации о достигнутых успехах и полученных уроках другим
специалистам организации;
модификации и совершенствования стандартов, соглашений и процедур,
связанных с использованием средства;
интеграции новых средств с существующими и сопровождения интегрированных
средств по мере появления новых версий;
помощи новым сотрудникам в освоении средств и связанных с ними процедур;
планирования и контроля обновления версий;
планирования внедрения новых возможностей средств в организационные
процессы.
Результатом данного шага является внедрение CASE-средств в повседневную практику организации, при этом больше не требуется какого-либо специального планирования. Кроме того, поддержка CASE-средств включается в план текущей поддержки ПО в данной организации.
Александр Михайлович Вендров
Департамент информатизации ЦБ РФ
Тел.: (095) 237-57-44