Проектирование информационных систем с использованием метода основанного на прецедентах

• Автор: Нечипоренко, Олег Анатольевич
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2003
• Место защиты: Краснодар
• Количество страниц: 146 с. : ил.

СОДЕРЖАНИЕ
ВВЕДЕНИЕ.

1 УПРАВЛЕНИЕ ЗНАНИЯМИ И КОРПОРАТИВНАЯ

1.1 Сложность программного обеспечения и пути ее преодоления

1.2 Основные понятия об управлении знаниями

1.3 Извлечение знаний

1.4 Формализация знаний

1.4.1 Продукционные правила

1.4.2 Фреймы.

1.4.3 Семантические сети.

1.4.4 Исчисление предикатов

1.4.5 Системы, основанные на прецедентах.
1.5 Теория СВЯсистем
1.5.1 Технология СВЯсистем
1.5.2 СВЯ и поисковые системы
1.5.3 СВЯ и продукционные системы
1.5.4 СВЯ и машинное обучение
1.5.5 СВЯ и нейронные сети
1.5.6 СВЯ и статистический анализ
1.6 Применение СВЯ метода в проектировании систем
1.7. Выводы
2 КОНЦЕПТУАЛЬНЫЕ МОДЕЛИ ПРЕДСТАВЛЕНИЯ ЗНАНИЙ
2.1. Основные понятия
2.2 Повторное использование концептуальных моделей.
2.3. Расчет меры сходства для концептуальных моделей.
2.4. Онтологии.
2.5. Поиск моделей с использованием онтологий.
2.6. Образцы проектирования
2.7. Архитектура СПИР
2.8. Выводы
3 АВТОМАТИЗИРОВАННЫЙ ПРОЦЕСС ИЗВЛЕЧЕНИЯ ОБРАЗЦОВ ПРОЕКТИРОВАНИЯ
3.1. Образцы проектирования и повторное использование кода.
3.2 Выделение образцов проектирования
3.3 Выводы
4. РАЗРАБОТКА И АНАЛИЗ ЭФФЕКТИВНОСТИ СППР
4.1. Этапы разработки ПО
4.2. Оценка эффективности работы СППР.
4.3 Выводы
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ


Достаточно трудно понять, даже в общих чертах, как работает каждая такая система. Теперь прибавьте к этому дополнительные требования (часто не формулируемые явно), такие как удобство, производительность, стоимость, выживаемость и надежность! Сложность задачи и порождает ту сложность программного продукта, о которой пишет Брукс []. Эта внешняя сложность обычно возникает из-за «нестыковки» между пользователями системы и ее разработчиками: пользователи с трудом могут объяснить в форме, понятной разработчикам, что на самом деле нужно сделать. Бывают случаи, когда пользователь лишь смутно представляет, что ему нужно от будущей программной системы. У пользователей и разработчиков разные взгляды на сущность проблемы, и они делают различные выводы о возможных путях ее решения. На самом деле, даже если пользователь точно знает, что ему нужно, мы с трудом можем однозначно зафиксировать все его требования. Обычно они отражены на многих страницах текста, «разбавленных» немногими рисунками. Такие документы трудно поддаются пониманию, они открыты для различных интерпретаций и часто содержат элементы, относящиеся скорее к дизайну, чем к необходимым требованиям разработки. Дополнительные сложности возникают в результате изменений требований к программной системе уже в процессе разработки []. В основном требования корректируются из-за того, что само осуществление программного проекта часто изменяет проблему. Рассмотрение первых результатов — схем, прототипов, — и использование системы после того, как она разработана и установлена, заставляют пользователей лучше понять и отчетливей сформулировать то, что им действительно нужно. В то же время этот процесс повышает квалификацию разработчиков в предметной области и позволяет им задавать более осмысленные вопросы, которые проясняют темные места в проектируемой системе []. Большая программная система — это крупное капиталовложение, и мы не можем позволить себе выкидывать сделанное при каждом изменении внешних требований. Тем не менее, даже большие системы имеют тенденцию к эволюции в процессе их использования: следовательно, встает задача о том, что часто неправильно называют сопровождением программного обеспечения. Чтобы быть более точными, введем несколько терминов: под сопровождением понимается устранение ошибок; под эволюцией — внесение изменений в систему в ответ на изменившиеся требования к ней; под сохранением — использование всех возможных и невозможных способов для поддержания жизни в дряхлой и распадающейся на части системе. Наше неумение создавать сложные программные системы проявляется в проектах, которые выходят за рамки установленных сроков и бюджетов и к тому же не соответствуют начальным требованиям. Мы часто называем это кризисом программного обеспечения, но, честно говоря, недомогание, которое тянется так долго, становится нормой. К сожалению, этот кризис приводит к разбазариванию человеческих ресурсов — самого драгоценного товара — и к существенному ограничению возможностей создания новых продуктов. Сейчас просто не хватает хороших программистов, чтобы обеспечить всех пользователей нужными программами. Более того, существенный процент персонала, занятого разработками, в любой организации часто должен заниматься сопровождением и сохранением устаревших программ. С учетом прямого и косвенного вклада индустрии программного обеспечения в развитие экономики большинства ведущих стран, нельзя позволить, чтобы существующая ситуация осталась без изменений [7]. Процесс разработки ПО определяет действия и организационные процедуры, направленные на усиление совместной работы в бригаде разработчиков с целью поставки заказчикам высококачественных программных продуктов. На модель процесса возлагаются следующие функции []. Установление порядка выполнения действий. Определение состава и времени поставки артефактов, создаваемых в процессе разработки. Закрепление действий и артефактов за разработчиками. Введение критериев отслеживания хода проекта, измерение результатов и планирование будущих проектов.