Основные понятия Case технологий
Case технологии включают в себя методы, с помощью которых строятся диаграммы, которые поддерживаются инструментальной средой.
Метод - процедура или техника генерации описания компонентов системы.
Нотация – отображение структуры системы, элементов данных, этапов обработки, а также описание проекта системы на формальных и естественных языках.
Инструментальные средства Case – это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Архитектура Case средств
- Ядром системы является репозиторий. Он представляет собой специализированную БД, которая используется для отображения состояния системы в любой момент времени. Репозиторий содержит информацию о всех объектах проектной ИС. В репозитории хранятся описания следующих объектов:
1. Имена проектировщиков и их права доступа
2. Организованные структуры
3. Компоненты диаграмм и диаграммы в целом
4. Структуры данных
5. Взаимосвязи между диаграммами
6. Программные модули, процедуры и библиотеки модулей
- ГРД используется для отображения в графическом виде заданной нотации проектной ИС. Он позволяет выполнять следующие операции:
1. Создавать элементы диаграмм и взаимосвязи между ними
2. Задавать описание элементов диаграмм
3. Редактирование элементов диаграмм и их взаимосвязь
- Верификатор диаграмм – используется для контроля правильности построения диаграмм заданной методологии проектирования. Он выполняет следующие функции:
1. Мониторинг правильности построения диаграмм
|
|
|
2. Диагностика и выдача сообщений об ошибках
3. Выделение на диаграмме ошибочных элементов
- Документатор – позволяет получить информацию о состоянии объекта в виде различных отчетов.
- Администратор проекта – инструменты, необходимые для выполнения следующих функций:
1. Инициализация проекта
2. Задание начальных параметров проекта
3. Назначение и изменение прав доступа к объектам проекта
- Сервис – набор системных утилит для обслуживания репозитория.
В область Case средств попадают как относительно дешевые системы с ограниченными возможностями, так и дорогостоящие системы, которые охватывают целиком процесс создания системы.
Всё большую популярность приобретают системы, ориентированные на создание и генерацию БД, а также интерфейсов к ним, поэтому стратегия выбора Case средств зависит как от целей и потребностей самого проекта, так и квалификации персонала. При выборе Case средств необходимо учитывать следующие аспекты:
1. Наличие БД, архива или словаря
2. Интерфейсы с другими Case системами
3. Возможности экспорта и импорта информации
|
|
|
4. Открытая архитектура
5. Наличие необходимых методологий
6. Графические средства поддержки проекта
7. Генерация кода программа
8. Планирование и управление проектом
К Case средствам относят любое ПО, автоматизирует совокупность ЖЦ и обладает следующими характеристиками:
1. Мощное графическое средство для описания ИС, которое обеспечивает удобство работы пользователя
2. Интеграция отдельных компонентов с Case средства
3. Использование организованного хранилища проектных метаданных
Классификация Case средств
Все Case средства могут быть классифицированы по типам и категориям. Классификация по типам отражает функциональность Case средств. Классификация по категориям отражает степень интегрированности.
- Современные Case системы классифицируются по следующим категориям:
1. По поддерживаем методологиям
- функциональный или структурно-ориентированный
- объектно-ориентированный
- комплексно-ориентированный
2. По поддерживаем графическим нотациям
3. По степени интегрированности
4. По типу и архитектуре вычислительной техники
5. По типу коллективной разработки
6. По типу операционной среды
|
|
|
- Классификация по типам:
1. Средства анализа (Design, BpWin)
2. Средства анализа и проектирования (Designer 2000 - Oracle)
3. Средства проектирования БД (ErWin, Designer 2000 - Oracle)
4. Средства разработки приложений (Developer 2000 – Oracle, Delphi)
5. Средства реинженеринга (ErWin, Rational Rose)
Оценка и выбор Case средств
Процесс оценки и выбора может преследовать несколько целей:
- оценка нескольких Case средств и выбор одного
- оценка нескольких Case средств и сохранение результата для последующей оценки
- выбор одного или нескольких Case средств с использованием результатов предыдущих оценок.
1 – уточнение критериев
2 – оценка Case средств
3 – выбор Case средств
4 – список критериев
5 – пользовательские потребности
6 – цели предположения и ограничения
7 – доступные Case средства
8 – уточненный список критериев
9 – потребность в дополнительной информации
10 – результаты оценки
11 – рекомендуемое решение
Входной информацией для процесса оценки является:
1. Определение пользовательских потребностей
2. Цели и ограничения проекта
3. Данные о доступных Case средствах
4. Список критериев, используемых для оценки
Процесс оценки может быть начат только тогда, когда организация полностью определила свои потребности и формализовала их в виде требований для данной предметной области.
|
|
|
Определение списка критериев основано на пользовательских требованиях и включает:
1. Выбор критериев для использования из приведенного списка
2. Определение области использования каждого критерия
3. Назначение удельного веса каждому критерию
Процесс оценки
Целью процесса оценки – является определение функционирования и качества Case средств для последующего выбора. Оценка выполняется в соответствии с выбранными критериями и включает в себя следующие действия:
1. Формулировка задачи
2. Определение критериев оценки
3. Определение средств кандидатов
4. Оценка средств кандидатов на основе критериев
5. Подготовка отчета по результатам оценки
Список Case средств формируется на основе информации из различных источников. Следующим шагом является получение информации о каждом Case средстве.
Все выбранные Case средства оцениваются по двум критериям:
1. Объективные критерии, оценка выполняется путем воспроизведения процедуры с той целью, чтобы любой специалист мог получить те же результаты.
2. Субъективные критерии. Case средства оцениваются группой специалистов, которые используют одни и те же критерии.
Данный этап заканчивается заключением в виде оценки Case средств. Выполняется в виде отчета, который содержит:
1. выбранные подходы и оценки
2. информация о Case средствах кандидатах
3. этапы оценки
4. конкретные результаты оценки
5. выводы и заключения
Процесс выбора
Процесс выбора включает следующие действия:
1. формулировка задачи выбора
2. выполнение всех необходимых действия по выбору
3. выполнение необходимого количества итераций с целью выбора Case средств имеющих схожие результаты
4. подготовка отчета по результатам выбора
Алгоритмы, которые используется для выбора, основаны на масштабе или ранге. В первом случае вычисляют единственное значение для каждого Case средства путем умножения каждого критерия на его значение и сложение всех произведений. Алгоритм, основанный на ранге, используется ранжирование по отдельным критериям, в соответствии со значением критерия и в заданном масштабе.
Критерии оценки и выбора
Критерии формируют базис для оценки и выбора и могут принимать различные формы, включая:
1. числовые меры в широком диапазоне
2. числовые меры в ограниченном диапазоне
3. двоичные меры
4. меры, которые могут принимать одно или более значений
1 – надежность
2 – простота использования
3 – эффективность
4 – сопровождаемость
5 – общие критерии
6 – переносимость
7 – функциональные характеристики
8 – среда функционирования
9 – проектная среда
10 – ПО
11 – технологическая среда
12 – функции, ориентированные на фазы ЖЦ
13 – моделирование
14 – реализация
15 – тестирование
16 – общие функции
17 – документирование
18 – управление конфигурацией
19 – управление проектом
Выполнение пилотного проекта
Перед масштабным внедрением выбранного Case средства в организации выполняется пилотный проект. Целью такого проекта является экспертная проверка правильности решений, принятых на предыдущих этапах, и начальная подготовка к внедрению.
Пилотный проект представляет собой первоначальное реальное использование Case средства, он преследует следующие цели:
1. подтверждение результатов оценки
2. сбор необходимой информации для внедрения Case средств
3. накопление собственного опыта в использовании Case средств
1 – определение характеристик ПП
2 – планирование ПП
3 – выполнение ПП
4 – оценка ПП
5 – принятие решения о внедрении
6 – внедрение Case средств
7 – выполнение дополнительного ПП
8 – отказ от внедрения
ПП должен обладать следующими характеристиками:
1. Требуемая область применения
2. Масштабируемость
3. Представительность
4. Критичность
5. Авторитетность
6. Характеристики проектной мощности
Планирование ПП должно по возможности вписываться в процесс разработки организации. План должен содержать следующие пункты:
1. Цели, задачи, критерии оценки
2. Персонал
3. Процедуры и соглашения
4. Обучение
5. График и ресурсы
После завершения ПП, его результаты необходимо оценить и сопоставить с начальными потребностями организации.
В результате оценки организация должна определиться в ответах на следующие вопросы:
1. Целесообразно ли внедрять Case средства
2. Какие конкретные особенности ПП привели к его успеху
3. Какие проекты или подразделения организации могли получить выгоду от внедрения Case средств
После ответа на них, принимается решение о внедрении Case средства. Варианты могут быть следующими:
1. Внедрить Case средство
2. Выполнить дополнительный ПП
3. Отказаться от внедрения Case средства
4. Отказаться от использования Case средства вообще
После оценки результатов внедрения Case средства, организация оценивает – реально ли повысилась производительность разработки ПО. Для оценки используются следующие критерии:
1. Используемое время
2. Время, выданное для конкретного специалиста
3. Размер, сложность и качество ПО
4. Удобство сопровождения ПО
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ (2 семестр)
Типовое проектирование
Методы ТП предполагают создание системы из готовых, покупных, типичных элементов. Для этого проектирования система должна быть декомпозирована на множество составляющих подсистем, для которых подбираются и закупаются готовые типовые решения.
В зависимости от уровня, декомпозиции различают:
- элементарная
- подсистемная
- объектная
Методы проектирования
Сущность применения ТПР при элементном методе заключается в комплектации системы из множества решений по отдельным, разрозненным задачам.
Недостатки:
1. большие затраты времени
2. плохая адаптивность к особенностям предприятия
При использовании подсистемного метода в качестве элементов типизации выступают отдельные подсистемы, которые обеспечивают функциональную полноту, параметрическую настраиваемость и альтернативность схем в пределах входных параметров.
Типовые решения реализуются по средствам прикладных программ. Данные пакеты позволяют осуществлять:
1. Модульное проектирование
2. Параметрическую настройку
3. Сокращение затрат на проектирование
4. Хорошее документирование
Недостатки:
1. Недостаточная адаптивность с позиции инженеринга деловых позиций
2. Недостаточная компенсируемость при создании систем
3. Малая совместимость между пакетами прикладных программ
При объектном методе ТП в качестве типового элемента использовался типовой проект для объектов управления определенной области, обеспечение полной компенсируемости.
Проектные комплексы отличаются следующими параметрами:
- Открытость архитектуры
- Масштабируемость
- Удобство настройки конфигурации
Данная методика имеет преимущество перед подсистемным методом, который заключается в компенсируемости всех компонентов, за счет единства методологии, программной и технической совместимости компонент.
Дата добавления: 2018-04-15; просмотров: 1253; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!