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

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

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

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

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

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

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

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

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

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

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

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

  1. Технологическая среда:
    • соответствие стандартам технологической среды . Такие стандарты касаются языка, базы данных, репозитория, коммуникаций, графического интерфейса пользователя, документации, разработки, управления конфигурацией, безопасности, стандартов обмена информацией и интеграции по данным, по управлению и по пользовательскому интерфейсу.
    • совместимость с другими средствами . Способность к взаимодействию с другими средствами, включая непосредственный обмен данными (примерами таких средств являются текстовые процессоры, базы данных и другие CASE-средства). Возможность преобразования репозитория или его части в стандартный формат для обработки другими средствами.
    • поддерживаемая методология . Набор методов и методик, поддерживаемых CASE-средством. Примерами являются структурный или объектно-ориентированный анализ и проектирование.
    • поддерживаемые языки . Все языки, используемые CASE-средством. Примерами таких языков являются языки программирования (Кобол, Ада, С), языки баз данных и языки запросов (DDL, SQL), графические языки (Postscript, HPGL), языки спецификации проектных требований и интерфейсы операционных систем (языки управления заданиями).
    Функции, ориентированные на фазы жизненного цикла:
  1. Моделирование:
    Данные критерии определяют способность выполнения функций, необходимых для спецификации требований к ПО и преобразованию их в проект:
    • построение диаграмм . Возможность создания и редактирования диаграмм различных типов, представляющих интерес для пользователя. Наиболее распространенные типы диаграмм описаны в разделе 2.
    • графический анализ . Возможность анализа графических объектов, а также хранения и представления проектной информации в графическом представлении. В большинстве случаев графические анализаторы интегрированы со средствами построения диаграмм.
    • ввод и редактирование спецификаций требований и проектных спецификаций . К спецификациям такого рода относятся описания функций, данных, интерфейсов, структуры, качества, производительности, технических средств, среды, затрат и графиков.
    • язык спецификации требований и проектных спецификаций . Возможность импорта, экспорта и редактирования спецификаций с использованием формального языка.
    • моделирование данных . Возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения.
    • моделирование процессов . Возможность ввода и редактирования информации, описывающей процессы системы и их отношения.
    • проектирование архитектуры ПО . Проектирование логической структуры ПО - структуры модулей, интерфейсов и др.
    • имитационное моделирование . Возможность динамического моделирования различных аспектов функционирования системы на основе спецификаций требований и/или проектных спецификаций, включая внешний интерфейс и производительность (например, время отклика, коэффициент использования ресурсов и пропускную способность).
    • прототипирование. Возможность проектирования и генерации предварительного варианта всей системы или ее отдельных компонент на основе спецификаций требований и/или проектных спецификаций. Прототипирование в основном касается внешнего пользовательского интерфейса и осуществляется при непосредственном участии пользователей.
    • генерация экранных форм . Возможность генерации экранных форм на основе спецификаций требований и/или проектных спецификаций.
    • возможность трассировки . Возможность сквозного анализа функционирования системы от спецификации требований до конечных результатов (установления и отслеживания соответствий и связей между функциональными и другими внешними требованиями к ИС, техническими решениями и результатами проектирования). Прямая трассировка (проверка учета всех требований) и обратная трассировка (поиск проектных решений, не связанных ни с какими внешними требованиями).
    • синтаксический и семантический контроль проектных спецификаций. Контроль синтаксиса диаграмм и типов их элементов, контроль декомпозиции функций, проверка спецификаций на полноту и непротиворечивость.
    • другие виды анализа . Конкретные дополнительные виды анализа могут включать алгоритмы, потоки данных, нормализацию данных, использование данных, пользовательский интерфейс.
    • автоматизированное проектирование отчетов.
  1. Реализация:
    Реализация затрагивает функции, связанные с созданием исполняемых элементов системы (программных кодов) или модификацией существующей системы. Многие из перечисленных ниже критериев зависят от конкретных языков и включают следующие:
    • синтаксически управляемое редактирование . Возможность ввода и редактирования исходных кодов на одном или нескольких языках с одновременным синтаксическим контролем.
    • генерация кода . Возможность генерации кодов на одном или нескольких языках на основе проектных спецификаций. Типы генерируемого кода могут включать обычный программный код, схему базы данных, запросы, экраны/меню.
    • компиляция кода.
    • конвертирование исходного кода . Возможность преобразования кода из одного языка в другой.
    • анализ надежности . Возможность количественно оценивать параметры надежности ПО, такие, как количество ошибок и др.
    • реверсный инжиниринг . Возможность анализа существующих исходных кодов и формирования на их основе проектных спецификаций.
    • реструктуризация исходного кода . Возможность модификации формата и/или структуры существующего исходного кода.
    • анализ исходного кода . Примерами такого анализа могут быть определение размера кода, вычисление показателей сложности, генерация перекрестных ссылок и проверка на соответствие стандартам.
    • отладка . Типичные функции отладки - трассировка программ, выделение узких мест и наиболее часто используемых фрагментов кода и т.д.
  1. Тестирование:
    Критерии тестирования включают следующие:
    • описание тестов . Типичные возможности включают генерацию тестовых данных, алгоритмов тестирования, требуемых результатов и т.д.
    • фиксация и повторение действий оператора . Возможность фиксировать данные, вводимые оператором с помощью клавиатуры, мыши и т.д., редактировать их и воспроизводить в тестовых примерах.
    • автоматический запуск тестовых примеров.
    • регрессионное тестирование . Возможность повторения и модификации ранее выполненных тестов для определения различий в системе и/или среде.
    • автоматизированный анализ результатов тестирования . Типичные возможности включают сравнение ожидаемых и реальных результатов, сравнение файлов, статистический анализ результатов и др.
    • анализ тестового покрытия . Оснащенность средствами контроля исходного кода и анализ тестового покрытия. Проверяются, в частности, обращения к операторам, процедурам и переменным.
    • анализ производительности . Возможность анализа производительности программ. Анализируемые параметры производительности могут включать использование центрального процессора, памяти, обращения к определенным элементам данных и/или сегментам кода, временные характеристики и т.д.
    • анализ исключительных ситуаций в процессе тестирования.
    • динамическое моделирование среды. В частности, возможность автоматически генерировать моделируемые входные данные системы.
    Общие функции:
    Приведенные ниже критерии определяют функции CASE-средств, охватывающие всю совокупность фаз ЖЦ. Поддержка всех этих функций осуществляется посредством репозитория.
  1. Документирование:
    • редактирование текстов и графики . Возможность вводить и редактировать данные в текстовом и графическом формате.
    • редактирование с помощью форм . Возможность поддерживать формы, определенные пользователями, вводить и редактировать данные в соответствии с формами.
    • возможности издательских систем.
    • поддержка функций и форматов гипертекста.
    • соответствие стандартам документирования.
    • автоматическое извлечение данных из репозитория и генерация документации по спецификациям пользователя.
  1. Управление конфигурацией:
    • контроль доступа и изменений . Возможность контроля доступа на физическом уровне к элементам данных и контроля изменений. Контроль доступа включает возможности определения прав доступа к компонентам, а также извлечения элементов данных для модификации, блокировки доступа к ним на время модификации и помещения обратно в репозиторий.
    • отслеживание модификаций . Фиксация и ведение журнала всех модификаций, внесенных в систему в процессе разработки или сопровождения.
    • управление версиями . Ведение и контроль данных о версиях системы и всех ее коллективно используемых компонентах.
    • учет состояния объектов конфигурационного управления . Возможность получения отчетов о всех последовательных версиях, содержимом и состоянии различных объектов конфигурационного управления.
    • генерация версий и модификаций . Поддержка пользовательского описания последовательности действий, требуемых для формирования версий и модификаций, и автоматическое выполнение этих действий.
    • архивирование . Возможность автоматического архивирования элементов данных для последующего использования.
  1. Управление проектом:
    • управление работами и ресурсами . Контроль и управление процессом проектирования ИС в терминах структуры заданий и назначения исполнителей, последовательности их выполнения, завершенности отдельных этапов проекта и проекта в целом. Возможность поддержки плановых данных, фактических данных и их анализа. Типичные данные включают графики (с учетом календаря, рабочих часов, выходных и др.), компьютерные ресурсы, распределение персонала, бюджет и др.
    • оценка . Возможность оценивать затраты, график и другие проектные параметры, вводимые пользователями.
    • управление процедурой тестирования . Поддержка управления процедурами и программой тестирования, например, управления расписанием планируемых процедур, фиксация и запись результатов тестирования, генерация отчетов и т.д.
    • управление качеством . Ввод соответствующих данных, их анализ и генерация отчетов.
    • корректирующие действия . Поддержка управления корректирующими действиями, включая обработку сообщений о проблемных ситуациях.

Надежность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение характеристик пилотного проекта

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

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

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

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

К-во Просмотров: 181
Бесплатно скачать Реферат: Оценка и выбор CASE-средств