- •Ю. А. Кравченко cals- и case-технологии таганрог 2005
- •Оглавление
- •Часть 2
- •8.5. Упражнения к части 2……………………………………100
- •Часть 3
- •Глава 9. Подходы реорганизации
- •Глава 10. Определение необходимости
- •10.6. Упражнения к части 3…………………………………..129
- •Аббревиатура
- •Предисловие
- •Введение
- •Часть 1
- •Глава 1. Основы cals - технологий
- •1.1. Основы информационной интеграции
- •1.2. Информационная поддержка изделий
- •1.3. Электронный технический документ (этд)
- •1.5. Система менеджмента качества (смк)
- •1.6. Интегрированная логистическая поддержка (илп)
- •1.7. Нормативная база cals-технологий
- •Глава 2. Стандарт step
- •2.1. Принципы создания стандарта step
- •2.2. Основные компоненты step
- •2.3. Методология тестирования
- •2.4. Схема использования стандарта step
- •Глава 3. Язык описания данных express
- •3.1. Основы языка
- •3.2. Свойства языка express
- •3.3. Объектно-ориентированный подход
- •3.4. Компоненты языка
- •3.5. Типы данных
- •3.6. Понятия
- •3.7. Упражнения к части 1
- •Часть 2
- •Глава 4. Основы имитационного моделирования сложных динамических систем
- •4.1. Теория массового обслуживания
- •4.2. Имитационное моделирование смо
- •4.3. Событийный метод моделирования
- •4.4. Сети Петри
- •Глава 5. Основы сase-технологий
- •5.1. Эволюция case-средств
- •5.2. Case–модель жизненного цикла программного обеспечения
- •5.3. Состав, структура и особенности case-средств
- •5.4. Графические модели
- •5.5. Контроль ошибок
- •5.6. Организация репозитария
- •5.7. Поддержка процесса проектирования и разработки
- •Глава 6. Классификация case-средств
- •Глава 7. Основы проектирования информационных систем (ис)
- •7.1. Основы методологии и технологии
- •Глава 8. Структурный подход проектирования информационных систем (ис)
- •8.1. Основные принципы структурного подхода
- •8.2. Методология sadt
- •8.2.1. Иерархия диаграмм
- •8.2.2. Типы связей между функциями
- •8.3. Построение модели анализируемой ис
- •8.3.1. Внешние сущности
- •8.3.2. Системы и подсистемы
- •8.3.3. Процессы
- •8.3.4. Накопители данных
- •8.3.5. Потоки данных
- •8.3.6. Иерархия диаграмм потоков данных
- •8.4. Case-метод Баркера моделирования данных
- •Р ис. 41. Рекурсивная связь [1]
- •8.5. Упражнения к части 2
- •Часть 3
- •Глава 9. Подходы реорганизации деятельности предприятия
- •9.1. Методика bsp (Business System Planning)
- •9.2. Подход cpi / tqm
- •9.3. Требования смм (Capability Maturity Model)
- •Глава 10. Определение необходимости внедрения case-средств
- •10.1. Определение потребностей внедрения
- •10.2. Анализ существующих case-средств
- •10.3. Критерии успешного внедрения
- •10.4. Стратегии внедрения case-средств
- •10.5. Реализация пилотного проекта
- •10.5.1. Основные цели реализации
- •10.5.2. Характеристики пилотного проекта
- •10.5.3. Разработка пилотного проекта
- •10.5.4. Внедрение выбранного на основе пилотного проекта case - средства
- •10.5.5. Анализ результатов внедрения case-средств
- •10.6. Упражнения к части 3
- •Заключение
- •Контрольные вопросы
- •25. Контроль ошибок.
- •27. Поддержка процесса проектирования и разработки.
- •38. Методология sadt.
- •Библиографический список
10.5.4. Внедрение выбранного на основе пилотного проекта case - средства
Организационная деятельность по выполнению пилотного проекта и подготовке отчетов должна выполняться в установленном порядке. Специального внимания требуют вопросы приобретения, поддержки, экспертизы и обновления версий.
Приобретение, установка и интеграция
Выбранное CASE-средство должно быть приобретено, интегрировано в проектную среду и настроено в соответствии с требованиями пилотного проекта.
Процесс приобретения может включать подготовку контракта, переговоры, лицензирование и другую деятельность, которая выходит за рамки данных рекомендаций. Эта деятельность требует затрат времени и человеческих ресурсов, которые должны быть учтены при планировании. План должен предусматривать возможность отказа от выбранного средства на данном этапе из-за договорных разногласий.
Когда процесс приобретения завершен, средство должно быть установлено, оттестировано и принято в эксплуатацию. Тестирование должно показать, что поставленный продукт соответствует требованиям контракта, обладает необходимой полнотой и корректностью. Этап приемки может быть предусмотрен контрактом, его реальный срок может отличаться от того, который был предусмотрен первоначально в плане пилотного проекта. Особое внимание необходимо уделить соблюдению всех требований поставщика к параметрам среды функционирования CASE-средства.
После завершения приемки может потребоваться настройка и интеграция. Настройка может включать модификацию интерфейсов, связанную с требованиями специалистов проектной группы, а также установкой прав доступа и привилегий. Настройка должна оставаться в рамках тех возможностей, которые предоставляет само средство.
Если новое средство должно использоваться в совокупности с некоторыми другими средствами, необходимо определить взаимодействие средств и требуемую интеграцию. Для интеграции новых средств с существующими может потребоваться построение специальных оболочек. Сложная интеграция может потребовать привлечения сторонних экспертов.
Поддержка
Поддержка должна включать: контакты с опытными пользователями в других организациях и участие в работе групп пользователей.
Внутренняя поддержка должна осуществляться специалистами, знакомыми с установкой средств и работой с ними. Такой тип поддержки должен специальным образом планироваться. Особое внимание должно быть уделено средствам, работающим в сетях или обладающих репозитариями, поддерживающими многопользовательскую работу [19].
Периодические экспертизы
Обычные процедуры экспертизы проектов, существующие в организации, должны выполняться и для пилотного проекта, при этом особое внимание должно уделяться именно пилотным аспектам проекта. Помимо этого, результаты экспертиз должны служить мерой успешного использования CASE-средств.
Обновление версий
Пользователи CASE-средства могут ожидать периодического обновления версий со стороны поставщика в течение выполнения пилотного проекта. При этом необходимо тщательное отношение к интеграции этих версий. Следует заранее оценить влияние этих обновлений на ход проекта. Новые версии могут как обеспечить новые возможности, так и породить новые проблемы. Например, новая версия может потребовать видоизмененного или дополнительного обучения, а также может оказать отрицательное воздействие на уже выполненную к этому моменту работу [19].