Реферат: Оценка и выбор CASE-средств - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

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

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 1001 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Оценка и выбор CASE-средств 1. Общ ие сведения Модель процесса оценк и и выбора [17], рассматриваемая ниже (рисунок 4.2), описывает наиболее общую ситуацию оценки и выбора , а также показывает з ависимость между ними . Как можно видеть , о ценка и выбор могут выполняться независимо друг от друга или вместе , каждый из этих проце с сов требует применения определенных критериев . Процесс оценки и выбора может преслед овать несколько целей , включая одну или бо лее из следующих : · оценка нескольких CASE-средств и выбор одного или более из них ; · оценка одного или более CASE-средств и со хранение результато в для последующего использования ; · выбор одного или более CASE-средств с использованием результатов предыдущих оценок . Рис . 4.2. Модель процесса оценки и выбора Как вид но из рисунка , входной информацией для про цесса оценки является : · определение пользовательских потребностей ; · цели и ограничения проекта ; · данные о доступных CASE-с редствах ; · список критериев , исп ользуемых в процессе оценки . Результаты оценки могут включать результаты предыдущих оценок . При этом не следует забывать , что наб ор критериев , использовавшихся при предыдущей оценке , должен быть совместимым с текущим набо ром . Конкретный вариант реализации пр оцесса (оценка и выбор , оценка для будущег о выбора или выбор , основанный на предыдущ их оценках ) определяется перечисленными выше целями . Элементы процесса включают : · цели , предположения и ограничения , ко торые могут у точняться в ходе процесс а ; · потребности пользователе й , отражающие количественные и качественные т ребования пользователей к CASE-средствам ; · критерии , определяющие набор параметров , в соответствии с которыми производится оценка и принятие решения о выбо ре ; · формализованные результа ты оценок одного или более средств ; · рекомендуемое решение (обычно либо решение о выборе , либо даль нейшая оценка ). Процесс оценки и /или выбора может быть начат только тогда , когда лицо , группа или организация полностью опр еделила для себя конкретн ые потребности и формализовала их в виде количественных и качественных требований в заданной предметной области . Термин "пользова тельские требования " далее означает именно та кие формализованные требования . Пользователь должен опре делить конкре тный порядок действий и принятия решений с любыми необходимыми итерациями . Например , пр оцесс может быть представлен в виде дерев а решений с его последовательным обходом и выбором подмножеств кандидатов для более детальной оценки . Описание пос л едов ательности действий должно определять поток д анных между ними . Определение списка критериев основано на пользовательских требованиях и включает : · выбор критериев для использования и з приведенного далее перечня ; · определение дополнительн ых критерие в ; · определение области использования каждого критерия (оценка , выбор или оба процесса ); · определение одной ил и более метрик для каждого критерия оценк и ; · назначение веса кажд ому критерию при выборе . Процесс оценки Целью процесса оценки является опр еделение функциональнос ти и качества CASE-средств для последующего в ыбора . Оценка выполняется в соответствии с конкретными критериями , ее результаты включают как объективные , так и субъективные данны е по каждому средству . Процесс оценки включает следующие д ействия : · формулировка задачи оценки , включая информацию о цели и масштабах оценки ; · определение критериев оценки , вытекающее из определения задачи ; · определение средств-канд идатов путем просмотра списка кандидатов и анализа информации о конкретных средства х ; · оценка средств-кандидато в в контексте выбранных критериев . Необходимы е для этого данные могут быть получены путем анализа самих средств и их докум ентации , опроса пользователей , работы с демо-ве рсиями , выполнения тестовых примеров , эксперимен тального применения средств и анализа результатов предшествующих оценок ; · подготовка отчета по результатам оценки . Одним из важне йших критериев в процессе оценки может бы ть потенциальная возможность интеграции каждого из средств-кандидатов с другими сре дс твами , уже находящимися в эксплуатации или планируемыми к использованию в данной орга низации . Масштаб оценки должен устанавливать требу емый уровень детализации , необходимые ресурсы и степень применимости ее результатов . Наприм ер , оценка должна выполнять ся для набо ра из одного или более конкретных CASE-средст в ; CASE-средств , поддерживающих один или более конкретных процессов создания и сопровождения ПО или CASE-средств , поддерживающих один или более проектов или типов проектов . Список CASE-средств - возм ожных кандидатов формируется из различных источников : обзоров рынка ПО , информации поставщиков , обзоров CASE-средств и других подобных публикаций . Следующим шагом является получение информ ации о CASE-средствах или получение их самих или и то , и другое . Эт а информ ация может состоять из оценок независимых экспертов , сообщений и отчетов поставщиков CASE-средств , результатов демонстрации возможностей CASE-средств со стороны поставщиков и информации , полученной непосредственно от реальных поль зователей . Сами C A SE-средства могут б ыть получены путем приобретения , в виде оц еночной копии или другими способами . Оценка и накопление соответствующих данны х может выполняться следующими способами : · анализ CASE-средств и документации пост авщика ; · опрос реальных польз о вателей ; · анализ результатов п роектов , использовавших данные CASE-средства ; · просмотр демонстраций и опрос демонстраторов ; · выполнение тестовых примеров ; · применение CASE-средств в пилотных проектах ; · анализ любых доступн ых результатов предыдущих оценок . Существуют как объективные , так и субъективные критерии . Ре зультаты оценки в соответствии с конкретным критерием могут быть двоичными , находиться в некотором числовом диапазоне , представлять собой просто числовое значение или иметь какую-либо дру гую форму . Для объективных критериев оценка должна выполняться путем воспроизводимой процедуры , чтобы любой другой специалист , выполняющий оц енку , мог получить такие же результаты . Ес ли используются тестовые примеры , их набор должен быть заранее определен , унифициров ан и документирован . По субъективным критериям CASE-средство долж но оцениваться группой специалистов , использующих одни и те же критерии . Необходимый ур овень опыта специалистов или групп должен быть заранее определен . Результаты оценки должны быть станд артным образом документированы (для облегчения последующего использования ) и , при необходимост и , утверждены . Отчет по результатам оценки должен со держать следующую информацию : · введение . Общий обзо р процесса и перечень основных результатов ; · предпосылки . Цель оценки и желаемые результаты , период времени , в течение которого выполнялась оценка , определение ролей и с оответствующего опыта специалистов , выполнявших о ценку ; · подход к оценке . Описание общего под хода , включая полученные CASE-средс тва , информ ацию , определяющую контекст и масштаб оценки , а также любые предположения и ограничени я ; · информация о CASE-средствах . Она должна включать следующее : 1) наименование CASE-средства ; 2) ве рсию CASE-средства ; 3) данные о поставщике , включая конта ктный адрес и телефон ; 4) конфигур ацию технических средств ; 5) стоимостные данные ; 6) описание CASE-средства , включающее поддерживаемые да нным средством процессы создания и сопровожде ния ПО , программную среду CASE-средства (в час тности , поддерживаемые язы к и программ ирования , операционные системы , совместимость с базами данных ), функции CASE-средства , входные /в ыходные данные и область применения ; · этапы о ценки . Конкретные действия , выпол няемые в процессе оценки , должны быть опис аны со степенью детализации, необходимой как для понимания масштаба и глубины о ценки , так и для ее повторения при нео бходимости ; · конкретные результаты . Результаты оценки должны быть представлены в терминах критер иев оценки . В тех случаях , когда отчет охватывает целый ряд CASE-сред ств или рез ультаты данной оценки будут сопоставляться с аналогичными результатами других оценок , нео бходимо обратить особое внимание на формат представления результатов , способствующий такому сравнению . Субъективные результаты должны быть отделены от объе к тивных и до лжны сопровождаться необходимыми пояснениями ; · выводы и заключения ; · приложения. Формулировка задачи оценки и уточненный список критериев . Процесс выбора Процессы оценки и выбора тесно взаимосвязаны друг с др угом . По результатам оценки цели выбора и /или критерии выбора и их веса могут потребовать модификации . В таких случая х может потребоваться повторная оценка . Когда анализируются окончательные результаты оценки и к ним применяются критерии выбора , мо жет быть рекомендовано приобретение CAS E -средства или набора CASE-средств . Альтернатив ой может быть отсутствие адекватных CASE-средств , в этом случае рекомендуется разработать новое CASE-средство , модифицировать существующее или отказаться от внедрения . Процесс выбора тесно взаимосвязан с п роце ссом оценки и включает следующие действия : · формулировка задач выбора , включая ц ели , предположения и ограничения ; · выполнение всех необ ходимых действий по выбору , включая определен ие и ранжирование критериев , определение сред ств-кандидатов , сбор необхо димых данных и применение ранжированных критериев к результ атам оценки для определения средств с наи лучшими показателями . Для многих пользователей важным критерием выбора является интегрируемос ть CASE-средства с существующей средой ; · выполнение необходим ого количества итераций с тем , чтобы выбрать (или отвергнуть ) средства , имеющие сходные показатели ; · подготовка отчета по результатам выбора . В процессе выб ора возможно получение двух результатов : · рекомендаций по выбору конкретного CASE-средства ; · запроса на получение дополнительной информации к процессу оценки . Масштаб выбора должен устанавливать требуемый уровень детализ ации , необходимые ресурсы , график и ожидаемые результаты . Существует ряд параметров , которы е могут быть использованы для определ ения масштаба , включая : · использование предварительного отбора (н апример , отбор только средств , работающих на конкретной платформе ); · использование ранее полученных результатов оценки , результатов оценки из внешних источников или комбинации тог о и друг ого ; В том случае , если предыдущие оценки выполнялись с исп ользованием различных наборов критериев или в ыполнялись с использованием конкретных критериев , но различными способами , результаты оценок должны быть представлены в согласованной ф орме . После заве ршения данного шага оц енка каждого CASE-средства должна быть представл ена в рамках единого набора критериев и должна быть непосредственно сопоставима с другими оценками . Алгоритмы , обычно используемые для выбора , могут быть основаны на масштабе или ранге. Алгоритмы , основанные на масштабе , вычисляют единственное значение для каждого CASE-средства путем умножения веса каждого крите рия на его значение (с учетом масштаба ) и сложения всех произведений . CASE-средство с наивысшим результатом получает первый ран г . Алгоритмы , основанные на ранге , используют ранжирование CASE-средств - кандидатов п о отдельным критериям или группам критериев в соответствии со значениями критериев в заданном масштабе . Затем , аналогично предыдущ ему , ранги сводятся вместе и вычисляются общие значения рангов . При анализе результатов выбора предполага ется , что процесс выбора завершен , CASE-средство выбрано и рекомендовано к использованию . Те м не менее , может потребоваться более точн ый анализ для определения степени зависимости значений кл ючевых критериев от разли чий в значениях характеристик CASE-средств - канди датов . Такой анализ позволит определить , наско лько результат ранжирования CASE-средств зависит от оптимальности выбора весовых коэффициентов критериев . Он также может использоватьс я для определения существенных различий между CASE-средствами с очень близкими значени ями критериев или рангами . Если ни одно из CASE-средств не удовл етворяет минимальным критериям , выбор (возможно , вместе с оценкой ) может быть повторен д ля других CASE-сре дств - кандидатов . Если различия между самыми предпочтительн ыми кандидатами несущественны , дополнительная инф ормация может быть получена путем повторного выбора (возможно , вместе с оценкой ) с использованием дополнительных или других критери ев . Рекомендац ии по выбору должны быт ь строго обоснованы . В случае отсутствия а декватных CASE-средств , как было отмечено выше , рекомендуется разработать новое CASE-средство , мод ифицировать существующее или отказаться от вн едрения . Критерии оценки и выбора Критерии форм ируют базис для процессов оценки и выбора и могут принимать различные формы , включая : · числовые меры в широком диапазоне значений , например , объем требуемой памяти ; · числовые меры в ограниченном диапазоне значений , например , простот а освоения , выраженн ая в баллах от 1 до 5; · двоичные меры (истина /ложь , да /нет ), например , способность генера ции документации в формате Postscript; · меры , которые могут принимать одно или более из конечных множеств значений , например , платформы , для которых поддерживается CASE-средство . Типичный процесс оценки и /или выбора может использовать набор критериев различных типов . Структура набора критериев приведена на рисунке 4.3. Каждый критерий должен быть выб ран и адаптирован экспертом с учетом особ енностей конкретного про цесса . В большинс тве случаев только некоторые из множества описанных ниже критериев оказываются приемлемы ми для использования , при этом также добав ляются дополнительные критерии . Выбор и уточн ение набора используемых критериев является к ритическим шагом в процессе оценки и /или выбора . Функциональные характеристики Критерии первого класса предназначены для определения функциональных характеристик CASE-средс тва . Они в свою очередь подразделяются на ряд групп и подгрупп . 1. Среда функционирования : a. Проек тная среда : § поддержка пр оцессов жизненного цикла . Определ яет набор процессов ЖЦ , которые поддерживает CASE-средство . Примерами таких процессов являютс я анализ требований , проектирование , реализация , тестирование и оценка , сопровождение , обеспечен ие каче ства , управление конфигурацией и управление проектом , причем они зависят от принятой пользователем модели ЖЦ . § область применения. Примерами являются системы обработки транзакций , системы реального времени , информационные системы и т.д . § размер поддерж иваемых приложений . Определяет ограничения на такие величины , как количество строк кода , уровней вложенности , размер базы данных , количество элементов да нных , количество объектов конфигурационного управ ления . b. ПО /технические средства : § требуемые те хни ческие средства . Оборудова ние , необходимое для функционирования CASE-средства , включая тип процессора , объем оперативной и дисковой памяти . § поддержива емые технические средства . Элемен ты оборудования , которые могут использоваться CASE-средством , например , устройства ввода /вывод а . § требуемое ПО . ПО , необходимое для ф ункционирования CASE-средства , включая операционные с истемы и графические оболочки . § поддержива емое ПО . Программные продукты , которые могут использоваться CASE-средством . Рис . 4.3. Структура набора критериев c. Технологическая среда : § соответствие стандартам технологической среды . Такие стандарты ка саются языка , базы данных , репозитория , коммуникаций , графического интерфейса пользователя , документации , разработки , управления конфигурацией , безопасности , стандартов обмена информацией и интеграции по данным , по управлению и по пользовательскому инт ерф е йсу . § совместимо сть с другими средствами . Спо собность к взаимодействию с другими средствам и , включая непосредственный обмен данными (при мерами таких средств являются текстовые проце ссоры , базы данных и другие CASE-средства ). Воз можность преобразования ре позитория или е го части в стандартный формат для обработ ки другими средствами . § поддержива емая методология . Набор методов и методик , поддерживаемых CASE-средством . Примера ми являются структурный или объектно-ориентирован ный анализ и проектирование . § по ддерживаемые языки . Все языки , используемые CASE-средством . Примерами таких языко в являются языки программирования (Кобол , Ада , С ), языки баз данных и языки запросов (DDL, SQL), графические языки (Postscript, HPGL), языки спецификации проектных требований и интерфейсы операц ионных систем (языки управления заданиями ). 2. Функции , ориенти рованные на фазы жизненного цикла : a. Моделирование : Данные критерии определяют способность выполне ния функций , необходимых для спецификации тре бований к ПО и преобразован ию их в проект : § построение д иаграмм . Возможность создания и редактирования диаграмм различных типов , пре дставляющих интерес для пользователя . Наиболее распространенные типы диаграмм описаны в р азделе 2. § графически й анализ . Возможность анализа графиче ских объектов , а также хранения и представления проектной информации в г рафическом представлении . В большинстве случаев графические анализаторы интегрированы со средс твами построения диаграмм . § ввод и редактирование спецификаций требований и про ектных сп ецификаций . К сп ецификациям такого рода относятся описания фу нкций , данных , интерфейсов , структуры , качества , производительности , технических средств , среды , за трат и графиков . § язык с пецификации требований и проектных спецификаций . Возможность импорта , экспо рта и редактирования спецификаций с использов анием формального языка . § моделирова ние данных . Возможность ввода и редактирования информации , описывающей элемен ты данных системы и их отношения . § моделирова ние процессов . Возможность ввода и редактиро вания информации , описывающей процессы системы и их отношения . § проектиров ание архитектуры ПО . Проектирован ие логической структуры ПО - структуры модулей , интерфейсов и др . § имитационн ое моделирование . Возможность дин амического моделирования различных аспектов функционирования системы на основе спецификаци й требований и /или проектных спецификаций , включая внешний интерфейс и производительность (например , время отклика , коэффициент использо вания ресурсов и пропускную способность ). § прототипир ование. Во зможность проектиро вания и генерации предварительного варианта в сей системы или ее отдельных компонент на основе спецификаций требований и /или про ектных спецификаций . Прототипирование в основном касается внешнего пользовательского интерфейса и осуществляе т ся при непосредств енном участии пользователей . § генерация экранных форм . Возможность г енерации экранных форм на основе спецификаций требований и /или проектных спецификаций . § возможност ь трассировки . Возможность сквозн ого анализа функционирования систем ы от спецификации требований до конечных результа тов (установления и отслеживания соответствий и связей между функциональными и другими внешними требованиями к ИС , техническими реше ниями и результатами проектирования ). Прямая т рассировка (проверка учета в с ех тр ебований ) и обратная трассировка (поиск проект ных решений , не связанных ни с какими внешними требованиями ). § синтаксиче ский и семантический контроль проектных специ фикаций . Контроль синтаксиса диаг рамм и типов их элементов , контроль декомп озиции фун кций , проверка спецификаций на полноту и непротиворечивость . § другие виды анализа . Конкретные допол нительные виды анализа могут включать алгорит мы , потоки данных , нормализацию данных , использ ование данных , пользовательский интерфейс . § автоматизи рованно е проектирование отчетов. b. Реализация : Р еализация затрагивает функции , связанные с со зданием исполняемых элементов системы (программны х кодов ) или модификацией существующей систем ы . Многие из перечисленных ниже критериев зависят от конкретных языков и включают следующие : § синтаксически управляемое редактирование . Возмож ность ввода и редактирования исходных кодов на одном или нескольких языках с одн овременным синтаксическим контролем . § генерация кода . Возможность генерации кодов на одном или нескольк их языках на основе проектных спецификаций . Типы ге нерируемого кода могут включать обычный прогр аммный код , схему базы данных , запросы , экр аны /меню . § компиляция кода . § конвертиро вание исходного кода . Возможность преобразования кода из одного языка в др угой . § анализ надежности . Возможность количестве нно оценивать параметры надежности ПО , такие , как количество ошибок и др . § реверсный инжиниринг . Возможность анализа существующих исходных кодов и формирования на их основе проектных спецификаций . § рест руктуризация исходного кода . Возможность модификации формата и /или структуры существующего исходного кода . § анализ исходного кода . Примерами тако го анализа могут быть определение размера кода , вычисление показателей сложности , генерац ия перекрестных ссыл ок и проверка на соответствие стандартам . § отладка . Типичные функции отладки - тр ассировка программ , выделение узких мест и наиболее часто используемых фрагментов кода и т.д . c. Тестирование : Критерии тестирования включают следующие : § описание тес тов . Типичные возможности включаю т генерацию тестовых данных , алгоритмов тести рования , требуемых результатов и т.д . § фиксация и повторение действий оператора . Возможность фиксировать данные , вводимые оператором с помощью клавиатуры , мыши и т.д ., редактирова ть их и воспроизводить в тестовых примерах . § автоматиче ский запуск тестовых примеров . § регрессион ное тестирование . Возможность пов торения и модификации ранее выполненных тесто в для определения различий в системе и /или среде . § автоматизи рованный анали з результатов тестирования . Типичные возможности включают сравнение ожидаемых и реальных результатов , с равнение файлов , статистический анализ результато в и др . § анализ тестового покрытия . Оснащенность средствами контроля исходного кода и анали з тестового покрытия . Проверяются , в част ности , обращения к операторам , процедурам и переменным . § анализ производительности . Возможность ан ализа производительности программ . Анализируемые параметры производительности могут включать испо льзование центрального процес сора , памяти , обращения к определенным элементам данных и /или сегментам кода , временные характеристики и т.д . § анализ исключительных ситуаций в процессе тестировани я . § динамическ ое моделирование среды. В час тности , возможность автоматически генерироват ь моделируемые входные данные системы . 3. Общие функции : Приведенные ниже критерии определяют функции CASE-средств , охватывающие всю совокупность фаз ЖЦ . Поддержка всех этих функций осуществл яется посредством репозитория . a. Документирование : § редакти р ование текстов и графики . Воз можность вводить и редактировать данные в текстовом и графическом формате . § редактиров ание с помощью форм . Возможно сть поддерживать формы , определенные пользователя ми , вводить и редактировать данные в соотв етствии с формами. § возможност и издательских систем . § поддержка функций и форматов гипертекста . § соответств ие стандартам документирования . § автоматиче ское извлечение данных из репозитория и г енерация документации по спецификациям пользоват еля. b. Управление кон фигу рацией : § контроль дос тупа и изменений . Возможность контроля доступа на физическом уровне к элементам данных и контроля изменений . Конт роль доступа включает возможности определения прав доступа к компонентам , а также изв лечения элементов данных для модифи кации , блокировки доступа к ним на время мо дификации и помещения обратно в репозиторий . § отслеживан ие модификаций . Фиксация и ве дение журнала всех модификаций , внесенных в систему в процессе разработки или сопровож дения . § управление версиями . Ведение и ко нтроль данных о версиях системы и всех ее коллективно используемых компонентах . § учет с остояния объектов конфигурационного управления . Возможность получения отчетов о всех последовательных версиях , содержимом и состоянии различных объектов конфигураци он ного управления . § генерация версий и модификаций . Поддер жка пользовательского описания последовательности действий , требуемых для формирования версий и модификаций , и автоматическое выполнение этих действий . § архивирова ние . Возможность автоматическог о архивирования элементов данных для последующего использования . c. Управление про ектом : § управление р аботами и ресурсами . Контроль и управление процессом проектирования ИС в терминах структуры заданий и назначения исполнителей , последовательности их вы полнени я , завершенности отдельных этапов проекта и проекта в целом . Возможность поддержки план овых данных , фактических данных и их анали за . Типичные данные включают графики (с уч етом календаря , рабочих часов , выходных и др .), компьютерные ресурсы , распред е лени е персонала , бюджет и др . § оценка . Возможность оценивать затраты , график и другие проектные параметры , вводимые пользователями . § управление процедурой тестирования . Поддерж ка управления процедурами и программой тестир ования , например , управления ра списанием п ланируемых процедур , фиксация и запись резуль татов тестирования , генерация отчетов и т.д . § управление качеством . Ввод соответствующих данных , их анализ и генерация отчетов . § корректиру ющие действия . Поддержка управлен ия корректирующими дейст виями , включая об работку сообщений о проблемных ситуациях . Надежность · администрирование репозитория . Контроль и обеспечение целостности проектных данных . · автоматическое резервиро вание (определяемое поставщиком или планируемое пользователем ). · безоп асность . Защ ита от несанкционированного доступа . · обработка ошибок . Обн аружение ошибок в работе системы , извещение пользователя , корректное завершение работы или сохранение состояния к моменту прерывания . · анализ отказов в критических приложениях . 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-средства по отношению к тому , который был достигнут во время оценки . Пило тный проект должен обладать многими из ха рактеристик реальных проектов , для которых пр едназначено данное средство . Он преследует сл едующие цели : · подтвердить достоверность результатов оц енки и выбора ; · определить , действительн о ли CA SE-средство годится для использова ния в данной организации , и если да , то определить наиболее подходящую область его применения ; · собрать информацию , н еобходимую для разработки плана практического внедрения ; · приобрести собственный опыт использования C ASE-средства . Пилотный проект позволяет получить важную информацию , необходим ую для оценки качества функционирования CASE-сре дства и его поддержки со стороны поставщи ка после того , как средство установлено . Важной функцией пилотного проекта являетс я прин ятие решения относительно приобрете ния или отказа от использования CASE-средства . Провал пилотного проекта позволяет избежать более значительных и дорогостоящих неудач в дальнейшем , поскольку пилотный проект обычн о связан с приобретением относительно небо л ьшого количества лицензий и обуч ением узкого круга специалистов . Первоначальное использование новой CASE-технолог ии в пилотном проекте должно тщательно пл анироваться и контролироваться . Пилотный проект включает следующие шаги (рисунок 4.4). Определение х арактеристик п илотного проекта Пилотный проект должен обладать следующим и характеристиками : · Область применения . Чтобы облегчить окончательное определение области применения CASE-средства , предметная область пилотног о проекта должна быть типичной для об ычной деятельности организации . Пилотный проект должен помочь определить любую дополни тельную технологию , обучение или поддержку , ко торые необходимы для перехода от пилотного проекта к широкомасштабному использованию сред ства . В рамках этих ограничений пи л отный проект должен иметь небольшой , н о значимый размер . · Масштабируемо сть . Результаты , полученные в пи лотном проекте , должны показать масштабируемость средства . Цель - получить четкое представление о масштабах проектов , для которых данное средство приме нимо . Рис . 4.4. Шаги пилотного проекта · Представительность . Пилотный проект не должен быть необычным или ун икаль ным для организации . CASE-средство должн о использоваться для решения задач , относящих ся к предметной области , хорошо понимаемой всей организацией . · Критичность . Пилотный проект должен иметь существенную значимость , чтобы оказаться в центре внимания , но н е должен быть критичным для успешной деятельности организаци и в целом . Необходимо осознавать , что перв оначальное внедрение новой технологии подразумев ает определенный риск . При выборе пилотного проекта приходится решать следующую дилемму : успех незначител ь ного проекта може т остаться незамеченным , с другой стороны , провал значимого проекта может вызвать чрезм ерную критику . · Авторитетност ь . Группа специалистов , участвующих в проекте , должна обладать высоким автори тетом , при этом результаты проекта будут в се рьез восприняты остальными сотрудниками организации . · Характеристик и проектной группы . Проектная гр уппа должна обладать готовностью к нововведен иям , технической зрелостью и приемлемым уровн ем опыта и знаний в данной технологии и предметной области . С дру гой стор оны , группа должна отражать в миниатюре ха рактеристики всей организации в целом . В большинстве случаев существует баланс между желанием реал изовать идеальный пилотный проект и реальными ограничениями организации . Организация должна выбрать пилотны й проект таким образом , чтобы , во-первых , способ использования CASE-средс тва в нем совпадал с дальнейшими планами , и , во-вторых , перечисленные выше характеристик и были сбалансированы с реальными условиями организации . Кроме того , организация должна учитыв ать продолжительность пилотного проекта ( и в целом процесса внедрения ). Слишком про должительный проект связан с риском потери интереса к нему со стороны руководства . Планирование пилотного проекта Планирование пилотного проекта должно по возможности впис ываться в обычный пр оцесс планирования проектов в организации . Пл ан должен содержать следующую информацию : · цели , задачи и критерии оценки ; · персонал ; · процедуры и соглашен ия ; · обучение ; · график и ресурсы . Цели , задачи и критерии оценки Ожидаем ые результаты пилотного проект а должны быть четко определены . Степень со ответствия этим результатам представляет собой основу для последующей оценки проекта . Для определения целей , задач и критериев оцен ки необходимо выполнить следующие действия : · описат ь проект в терминах ож идаемых результатов (т.е . конечного продукта ). Описание должно включать форму пр едставления и содержание результатов . Должны быть четко определены договорные требования и соответствующие стандарты . · определить общие цели проекта . Пр име ром цели может быть определение степени у лучшения качества проектной документации в ре зультате применения CASE-средств . · определить конкретные задачи , реализующие поставленные цел и . Каждой цели можно поставить в соответствие одну или несколько конкре т ных задач с количественно оцениваемыми результатами . Примером такой задачи может быть сравнительный анализ качества документаци и , полученной с помощью CASE-средства и без него . Документация может включать спецификацию требований к ПО , высокоуровневые и де т альные проектные спецификации . · определить критерии оценки результатов . Чтоб ы определить степень успеха пилотного проекта , необходимо использовать набор критериев , осн ованных на упомянутых выше задачах . Примером критерия может быть степень непротиворечив ости проектной документации и контролируе мости выполнения требований к ПО . Значения критериев должны сравниваться с базовыми з начениями , полученными до выполнения пилотного проекта . Персонал Специалисты , выбранные для участия в п илотном проекте , должны и меть соответству ющий авторитет и влияние и быть сторонник ами новой технологии . Группа должна включать как технических специалистов , так и менед жеров , заинтересованных в новой технологии и разбирающихся в ее использовании . Группа должна обладать высокими с п особностям и к коммуникации , знанием особенностей органи зационных процессов и процедур , а также пр едметной области . Группа не должна , тем не менее , состоять полностью из специалистов высшего звена , она должна представлять сред ний уровень организации . Многи е CASE-средства обеспечивают возмож ности , связанные с генерацией проектной докум ентации и конфигурационным управлением . Специалис ты , связанные с этими и другими смежными аспектами разработки и сопровождения ПО , также должны быть включены в состав групп ы . После завершения пилотного проекта группа должна быть открыта для обмена информаци ей с остальными специалистами организации отн осительно возможностей нового средства и опыт а , полученного при его использовании . Может оказаться желательным рассредоточить чл е нов проектной группы по всей организа ции с целью распространения их опыта и знаний . Процедуры и соглашения Необходимо четко определить процедуры и соглашения , регулирующие использование CASE-средств в пилотном проекте . Эта задача скорее всего может оказа ться более долгой и сложной , чем ожидается , при этом может оказаться необходимым привлечение сторонних эк спертов . Примерами процедур и соглашений , кото рые могут повлиять на успех пилотного про екта , являются методология , технические соглашения (в частности, по наименованиям и стр уктуре каталогов , стандарты проектирования и программирования - см . подраздел 1.3) и организационны е соглашения (в частности , учет использования ресурсов , авторизация , контроль изменений , про цедуры экспертизы и подготовки отчетов , с т андарты проверки качества ). В пилотном проекте по возможности дол жны использоваться принятые в организации про цедуры и соглашения . С другой стороны , в течение пилотного проекта процедуры и согл ашения имеют тенденцию к развитию и совер шенствованию по мере накопления опыта п рименения средства . Существующие процедуры и соглашения могут оказаться неэффективными или чересчур ограничивающими . При этом те измен ения , которые предлагается в них вносить , должны документироваться . Обучение Должны быть определены ви ды и объем обучения , необходимого для выполнения пилотного проекта . При планировании обучения нужно иметь в виду три вида потребност ей : технические , управленческие и мотивационные . Ресурсы , требуемые для обучения (учебные ау дитории и оборудование , препода в атели и учебные материалы ), должны соответствовать плану пилотного проекта . График обучения должен определять как специалистов , подлежащих обучению , так и вид ы обучения , которое они должны пройти . Обу чение , которое проводится в период выполнения проекта , должно начинаться как можно быстрее после начала проекта . Обучение сред ствам , процессам или методам , которые не б удут использоваться в течение нескольких меся цев после начала проекта , должно планироватьс я на то время , когда в них возникнет реальная потреб н ость . Поставщики 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-ср едств . · Информацию относительно интеграции каждого средства с существующими средствами , включая как интеграцию CASE-средств друг с другом , так и их интеграцию в процессы разработки и эксплуатации ПО , существующие в организации . · Ожи даемые потреб ности в обучении и ресурсы , используемые в течение и после завершения процесса пере хода . · Определение стандартных процедур использования средств . Цели , критерии оценки , график и риски , связанные с план ом перехода Данная информация должна в ключать следующее : · Типы проектов , в которых в конечн ом счете будет использоваться средство . · График перехода к практическому использованию средства в отдельн ых проектах , который включает необходимую под готовку к его широкому использованию . · График в недрения средства в терминах количества пользователей , включая необходимое обучение . · Возможные риски и непредвиденные обстоятельства . · Источники существующих (базовых ) данных и метрики для оценки изменений , вызванных использованием средств . В дополне н ие к сказанному , следует уделить особое вн имание вопросам контроля изменений . Роли высш его руководства , субъектов и объектов изменен ий должны быть уточнены по сравнению с пилотным проектом , поскольку технология подлежи т широкому распространению в организ а ции . Подразумевается , что план перехода успешн о выполнен , когда не требуется больше спец иального планирования поддержки использования ср едства . В этот момент использование средства согласуется с тем , что от него ожидал ось , и план работы с ним включается в общий план текущей поддержки ПО , су ществующий в организации . Приобретение , установка и настро йка средств Приобретение , установка и настройка , выпол ненные в рамках пилотного проекта , могут п отребоваться в более широком масштабе . При этом необходима следу ющая информация : · Совокупность программных компонент , докум ентации и обучения , которые необходимо приобр етать для каждой отдельной платформы . · Механизм получения н овых версий . · Настройка средства , н еобходимая для выполнения существующих в орга низации процедур и соглашений . · Лицо или подразделен ие , ответственное за установку , интеграцию , нас тройку и эксплуатацию средства . · План конвертирования данных и снятия старых средств с экспл уатации . Задачи приобретен ия , установки и настройки должны быть как можно быстрее переданы из группы п илотного проекта в существующую службу систем ной поддержки ПО организации . Интеграция средства с существую щими средствами и процессами Интеграция нового средства с существующим и средствами и процессами является важным ш агом в полномасштабном внедрении сред ства . В большинстве случаев такая интеграция в процессе пилотного проектирования не о существляется , однако накапливаемая в этом пр оцессе информация может помочь в разработке планов интеграции . Для планирования интеграц и и необходима следующая информация : · Наименования и версии существующих с редств , с которыми должно интегрироваться нов ое средство . · Описания данных , кото рые должны совместно использоваться новым и существующими средствами , а также предварите льная информ ация об источниках этих д анных . · Описания других взаи мосвязей между новым и существующими средства ми (таких , как связи по передаче управлени я и порядку использования ), а также предва рительная информация о механизмах поддержки э тих взаимосвязей . · Оценки затрат , сроков и рисков , связанных с интеграцией ( и , возможно , переходом от существующих средств и данных ). · Определение способа внедрения данного средства в деятельность по совершенствованию существующих процессов . · Ожидаемые изменения в существующих процессах и продуктах , яв ляющиеся следствием использования нового средств а и оцениваемые , по возможности , количественно . Риск , связанный с интеграцией нового средства с существующ ими средствами и процессами , снижается , если потребности в интеграции учиты ваются в процессе оценки и выбора средства . Обучение и ресурсы , используемые в течение и после завершения процесса перехода Данная информация должна включать следующ ее : · Персонал (включая пользователей , администр аторов и интеграторов ), нуждающийся в об учении использованию средства . · Вид обучения , необход имого для каждой категории пользователей и обслуживающего персонала , с учетом особой в ажности обучения совместному использованию разли чных средств , а также методам и процессам , связанным с данными сред ствами . · Вид обучения , необход имого для различных специалистов (например , дл я группы тестирования и независимой службы сертификации ). · Частота обучения . · Виды и доступность поддержки . Определение стан дартов и процедур использования средств План пер ехода должен определять с ледующие стандарты и процедуры использования средств : · Руководства по моделированию и проек тированию . · Соглашения по присво ению имен . · Процедуры контроля к ачества и процессов приемки , включая расписан ие экспертиз и используем ые методологии . · Процедуры резервного копирования , защиты мастер-копий и конфигуриров ания базы данных . · Процедуры интеграции с существующими средствами и базами данных . · Процедуры совместного использования данных и контроля целостности БД . · Стандар ты и процедуры обеспечения секретности . · Стандарты документирован ия . Стандарты использ ования CASE-средств , выработанные во время пилотн ого проекта , должны использоваться в качестве отправной точки для разработки более пол ного набора стандартов использов ания сред ств в данной организации (см . подраздел 1.3). П ри этом должен учитываться опыт участников пилотного проекта . Реализация плана перехода Реализация плана перехода требует постоян ного мониторинга использования CASE-средств , обеспече ния текущей подд ержки , сопровождения и обновления средств по мере необходимости . Периодические экспертизы Достигнутые результаты должны периодически подвергаться экспертизе в соответствии с г рафиком , план перехода должен корректироваться при необходимости . Постоянное вн имание должно уделяться степени удовлетворения потребно стей организации и критериев успешного внедре ния CASE-средств . Периодические экспертизы должны продолжаться и после завершения процесса внедрения . Та кие экспертизы могут анализировать метрики и другую информацию , получаемую в процесс е работы с CASE-средствами , чтобы определять , насколько хорошо они продолжают выполнять тре буемые функции . Такие экспертизы могут также указать на необходимость дополнительной моди фикации процессов . Текущая поддержка Теку щая поддержка необходима для следующего : · Ответов на вопросы , связанные с и спользованием средств . · Передачи информации о достигнутых успехах и полученных уроках другим специалистам организации . · Модификации и соверш енствования стандартов , соглашений и процеду р , связанных с использованием средства . · Интеграции новых сре дств с существующими и сопровождение интегрир ованных средств по мере появления новых в ерсий . · Помощи новым сотрудн икам в освоении средств и связанных с ними процедур . · Планирования и контроля обновления версий . · Планирования внедрения новых возможностей средств в организационные процессы . Действия , выполня емые в процессе перехода Для поддержки процесса перехода к пра ктическому использованию средств желательно выпо лнение следующи х действий : · Поддержка текущего обучения. Потребность в обучении может возникать периодически вследствие появления новых верс ий средств или вовлечения в проект новых сотрудников . · Поддержка ролевых функций , связанных с процессом внедре ния . Поскольку вн едрение 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 U K 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. Edwa rd 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 Desi gners' 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. Us er's Guide. 11. PVCS Tracker. User's Guide. 12. QA Partner. User's Guide. 13. Новоженов Ю.В . Объектн о-ориентированные технологии разработки сложных п рограммных систем . М ., 1996. 14. Панащук С.А . Разработк а информационных систем с использованием CASE-си стемы Silverrun. "СУБД ", 1995, № 3. 15. Горчинская О.Ю . Designer/2000 - но вое поколение CASE-продуктов фирмы ORACLE. "СУБД ", 1995, № 3. 16. Горин С.В ., Тандоев А.Ю . Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки д ан ных . "СУБД ", 1995, № 3. 17. Горин С.В ., Тандоев А.Ю . CASE-средство S-Designor 4.2 для разработки структуры ба зы данных . "СУБД ", 1996, № 1. 18. DATARUN Concepts. Computer Systems Advisers Research Ltd., 1994. 19. SE Companion Installation and Administrat ion Manual. SECA Inc., 1995. 20. Петров Ю.К . JAM - инструмен тальное средство разработки приложений в инфо рмационных системах архитектуры "клиент /сервер ", построенных на базе РСУБД . "СУБД ", 1995, № 3.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
«Или пить или водить» — говорит социальная реклама ГИБДД на улицах. То есть человеку без автомобиля они выбора просто не оставляют.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru