Banners System
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #01/97
<< ПРЕДЫДУЩАЯ СТАТЬЯ ] [ ОГЛАВЛЕНИЕ ] [ СЛЕДУЮЩАЯ СТАТЬЯ >>

Практические рекомендации по освоению и внедрению CASE-средств

(по материалам стандартов 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
    Ваше имя:  E-mail: 
    Оценка интересности и/или полезности статьи:
    интересно и/или полезно
    мало интересно или полезно
    вредная статья

    Стиль изложения
    читается легко
    несколько трудна для чтения
    очень трудно читать
    Ваш комментарий:

     
    << ПРЕДЫДУЩАЯ СТАТЬЯ ] [ ОГЛАВЛЕНИЕ ] [ СЛЕДУЮЩАЯ СТАТЬЯ >>
    Banners System