25976-1 (Технология внедрения CASE-средств), страница 2

Как правило, большинство организаций осуществляет внедрение CASE-средств для того, чтобы повысить продуктивность процессов разработки и сопровождения ПО, а также качество результатов разработки. Однако, ряд организаций не занимаются и не занимались ранее сбором количественных данных по указанным параметрам. Отсутствие таких данных затрудняет количественную оценку воздействия, оказываемого внедрением CASE-средств. В этом случае рекомендуется разработка соответствующих метрик. Информация о таких метриках приведена в стандартах IEEE Std 1045-1992 (IEEE Standard for Software Productivity Metrics) и IEEE Std 1061-1992 (IEEE Standard for a Software Quality Metrics Methodology).

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

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

• согласованность проектных результатов;

• точность стоимостных и плановых оценок;

• изменчивость внешних требований;

• соблюдение стандартов организации;

• степень повторного использования существующих компонентов ПО;

• объем и виды необходимого обучения;

• типы и моменты обнаружения проектных ошибок;

• вычислительные ресурсы, используемые CASE-средствами.

Разработка стратегии внедрения CASE-средств

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

• организационные потребности;

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

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

• подразделения организации, в которых должно выполняться внедрение CASE-средств;

• влияние, оказываемое на другие подразделения организации;

• стратегии и планы оценки и выбора, пилотного проектирования и перехода к полномасштабному внедрению;

• основные факторы риска;

• ориентировочный уровень расходов и источники финансирования процесса внедрения CASE-средств;

• ключевой персонал и другие ресурсы.

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

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

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

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

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

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

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

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

Недостатки данного подхода заключаются в следующем:

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

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

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

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

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

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

• небольшая автоматизация может быть выполнена при минимальных затратах;

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

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

Недостатки данного подхода заключаются в следующем:

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

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

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

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

Литература

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

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

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

4. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., "МетаТехнология", 1993.

5. Международные стандарты, поддерживающие жизненный цикл программных средств. М., МП "Экономика", 1996

6. Создание информационной системы предприятия. "Computer Direct", 1996, N2

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

8. Barker R. CASE*Method. Entity-Relationship Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

1. Barker R. CASE*Method. Function and Process Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

2. Boehm B.W. A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, Aug. 1986

3. Chris Gane, Trish Sarson. Structured System Analysis. Prentice-Hall, 1979.

4. Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.

5. Tom DeMarco. Structured Analysis and System Specification. Yourdon Press, New York, 1978.

6. Westmount I-CASE User Manual. Westmount Technology B.V., Netherlands, 1994.

7. Uniface V6.1 Designers' Guide. Uniface B.V., Netherlands, 1994.

8. IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools.

9. IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools.

10. PVCS Version Manager. User's Guide.

11. PVCS Tracker. User's Guide.

12. QA Partner. User's Guide.