Содержание:

Введение

Глава 1. Общие сведения

1.1 Процесс оценки

1.2 Процесс выбора

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

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

2.1. Среда функционирования:

2.2. Функции, ориентированные на фазы жизненного цикла:

2.3 Общие функции

Глава 3. Выполнение пилотного проекта

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

3.2. Планирование пилотного проекта

Заключение

Список литературы

Введение

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

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

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

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

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

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

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

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

• негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Глава 1. Общие сведения

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

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

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

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

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

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

• определение пользовательских потребностей;

• цели и ограничения проекта;

• данные о доступных CASE-средствах;

• список критериев, используемых в процессе оценки.

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

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

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

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

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

• формализованные результаты оценок одного или более средств;

• рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

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

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

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

• определение дополнительных критериев;

• определение области использования каждого критерия (оценка, выбор или оба процесса);

• определение одной или более метрик для каждого критерия оценки;

• назначение веса каждому критерию при выборе.

1.1 Процесс оценки

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

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

• формулировка задачи оценки, включая информацию о цели и масштабах оценки;

• определение критериев оценки, вытекающее из определения задачи;

• определение средств-кандидатов путем просмотра списка кандидатов и анализа информации о конкретных средствах;

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

• подготовка отчета по результатам оценки.

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

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

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

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

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

• анализ CASE-средств и документации поставщика;

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

• анализ результатов проектов, использовавших данные CASE-средства;

• просмотр демонстраций и опрос демонстраторов;

• выполнение тестовых примеров;

• применение CASE-средств в пилотных проектах;

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

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

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

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

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

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

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

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

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

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

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

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

• выводы и заключения;

• приложения. Формулировка задачи оценки и уточненный список критериев.

1.2 Процесс выбора

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

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

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

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

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

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

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

• рекомендаций по выбору конкретного CASE-средства;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1. Среда функционирования:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2. Функции, ориентированные на фазы жизненного цикла:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Общие функции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность

• администрирование репозитория. Контроль и обеспечение целостности проектных данных.

• автоматическое резервирование (определяемое поставщиком или планируемое пользователем).

• безопасность. Защита от несанкционированного доступа.

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

• анализ отказов в критических приложениях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 3. Выполнение пилотного проекта

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

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

• подтвердить достоверность результатов оценки и выбора;

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

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

• приобрести собственный опыт использования CASE-средства.

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

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

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

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

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

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

• Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость средства. Цель - получить четкое представление о масштабах проектов, для которых данное средство применимо.

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

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

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

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

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

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

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

3.2. Планирование пилотного проекта

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

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

• персонал;

• процедуры и соглашения;

• обучение;

• график и ресурсы.

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

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

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

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

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

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

Персонал

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

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

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

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

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

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

Обучение

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

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

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

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

• квалификация преподавателей;

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

• возможность проведения курсов непосредственно на рабочих местах;

• возможность проведения расширенных курсов;

• возможность подготовки собственных преподавателей.

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

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

Заключение

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

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

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

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

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

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

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

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

Список литературы

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

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

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

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

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

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

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

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

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

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