Компьютерная анимация



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

Maya для начинающих

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

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

Введение
Новая книга не содержит никаких основ, только острова удовольствия. Если вы знакомы с интерфейсом Мауа, то, как и я, будете наслаждаться этими уроками. В основе каждой главы лежит обычный вопрос в том виде, в каком он приходит в голову: Как скатить мяч с горы? Как получить тень от березы (с трепетанием всех листьев и веток) внутри моей скучной трехмерной комнаты? Как получить извержение вулкана?

Анимация
Первый урок, кстати, самый простой в этой книге. Может быть, задача переворачивания страницы трехмерной книги покажется вам банальной и даже скучной. Я думал точно так же, пока не предложил это задание десяти студентам университета в классе 3D анимации. Я дал им 30 минут на то, чтобы смоделировать лист бумаги и перевернуть его справа налево.

Пожалуйста, переверните страницу
Живая камера
Забавы со скручиванием
Зззвоним в звонок
Куда он делся?
Посемафорим
Катись, мяч, катись!
Управляем велосипедом и отвлекаем внимание

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

Моток кабеля
Узловатый человечек
Изогнутое крыло автомобиля
Нос с бородавкой
Четыре чемодана
Полигональный чемодан
Чемодан из SDS-поверхностей
Чемодан из NURBS-сферы
Округленный чемодан
Два глаза и рот

Динамика
Настоящие крэш-тесты очень дороги, поскольку в них разбиваются настоящие машины. Моделирование аварий также весьма дорого, но уже по другой причине. В отличие от реальных тестов компьютерную модель можно повторять бесконечное количество раз однако, они требуют очень мощных компьютерных ресурсов. Эти ресурсы необходимы, поскольку тесты имеют дело с еле заметными, крошечными изменениями материалов. Они не только тестируют типы материалов, из которых сделана машина, но также и качество их плавки и соединения. Эластичность - это определяющий фактор для таких тестов. Однако важна и специфичная точка , в которой каждая часть машины теряет эту эластичность и ломается. Когда она ломается, как она ломается?

Крэш-тест
Извержение вулкана
Пусть они улягутся
Атака частиц
Толкаем вверх, тянем вниз
Пончо

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

Освещение с настроением.
Пешеходный переход
Дикая растительность
Маска черной дыры
Тень от деревьев
Блуждающее свечение.
Спасательный круг и любовь
Подсказки при использовании Paint Effects
Волшебные линзы
Китайский иероглиф Жи

Cамоучитель по Maya 6

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

Введение в компьютерную 3D-графику
В последние десятилетия интерес к компьютерной графике значительно возрос. В немалой степени это является следствием появления на рынке мощных компьютеров по относительно низким ценам. Начиная с конца 90-х годов оборудование для создания анимации стало доступным для индивидуальных пользователей.

Компьютерная графика
Создание трехмерных сцен
Анимация
Стадии производства
Подготовительная работа
Производство
Последующая обработка
Заключение
Последовательность действий при анимации
Моделирование

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

Управление Maya
Интерфейс Maya
Главное меню
Строка состояния
Строка состояния - 2
Строка состояния - 3
Строка состояния - 4
Строка состояния - 5
Вкладки Shelf
Панель инструментов

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

Обзор проекта Солнечная система
Планирование
Создание проекта
Моделирование объектов и их анимация
Создание Солнца и планет
Создание Солнца и планет - 2
Сохранение сцены
Создание спутников
Назначение материалов
Назначение материалов - 2

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

Методы моделирования
NURBS-поверхности, полигональные поверхности
Использование примитивов
NURBS-моделирование
Способы создания NURBS-поверхностей
История конструирования поверхностей
Неоднородные рациональные В-сплайны
Начало работы над проектом
Перемещение плоскости изображения за сетку
Создание контура

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

Основы полигонального моделирования
Создание полигональных примитивов
Инструмент Create Polygon Tool
NURBS-поверхностей для полигональных сеток
Преобразование NURBS в полигональные сетки
Инструменты редактирования полигонов
Операция выдавливания
Выдавливание по дуге
Разбиение с выдавливанием
Выдавливание со скосом

Дополнительные приемы моделирования
Как вы имели возможность убедиться в предыдущих главах при изучении полигонального моделирования и моделирования на основе неоднородных рациональных сплайнов Безье, деформаторы играют большую роль при создании и редактировании формы объектов. Например, нелинейный деформатор Bend (Изгиб) вызывает изгиб объекта, к которому он присоединен. Это простая деформация. Более сложное воздействие можно получить, например, с помощью деформатора Lattice (Решетка).

Моделирование с помощью деформатора Lattice
Создание решетки
Поверхности с иерархическим разбиением
Создание морской звезды
Преобразование в поверхность с разбиением
Построение металлического чайника
Создание базовой полигональной модели
Поверхность с иерархическим разбиением
Преобразование в сетку полигонов
Дальнейшее редактирование модели чайника

Материалы и текстуры
Назначение материалов подразумевает присвоение объекту видимого при визуализации цвета, рельефа, прозрачности, зеркальных бликов и других характеристик поверхности. С этим процессом тесно связано назначение текстур, то есть Процесс сопоставления определенного рисунка выбранному атрибуту материала. Этот способ позволяет даже имитировать детали на поверхности объекта. Например, назначив атрибуту Color (Цвет) изображение кирпичей, вы, по сути, назначите материалу карту текстуры. Назначение еще одной отсканированной фотографии с изображением впадин и выпуклостей той же самой кирпичной стены атрибуту Bump Mapping (Карта рельефа) также рассматривается как назначение текстуры

Назначение материалов
Типы раскрасок
Раскраска по Ламберту
Раскраска по Фонгу
Раскраска по Блинну
Расширенная раскраска по Фонгу
Анизотропная раскраска
Многослойная раскраска
Градиентная раскраска
Атрибуты материалов

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

Анимация по методу ключевых кадров
Создание мячика
Анимация мячика
Анимация полета топора
Предварительная подготовка
Настройка сцены
Ключевые кадры и изучение движения
Анимация топора: создание ключевых кадров
Завершение движения
Вторичные движения

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

Скелеты и кинематика
Скелеты и иерархия
Метод прямой кинематики
Создание скелета
Соединение скелета с оболочкой
Моделирование ходьбы
Моделирование руки
Сборка руки
Связывание с оболочкой
Жесткое связывание руки

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

Базовые концепции освещения
Учимся видеть
Что нужно создать в сцене?
Освещение с трех точек
Реальное освещение
Источники света в Maya
Общие атрибуты источников света
Типы источников света
Освещение сцены
Тени

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

Настройки визуализации
Общие параметры визуализации
Выбор визуализатора
Предварительный просмотр
Сохранение/загрузка изображения
Хранение изображения/удаление из буфера
Интерактивная фотореалистичная визуализация
Отражения и преломления
Трассируемые отражения
Визуализация эффекта преломления

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

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

Программирование стратегических игр с DirectX 9.0

Привет и добро пожаловать в восхитительный мир программирования стратегических игр! Стратегия всегда была одинм из моих любимых игровых жанров. Ничто в игровом мире не сравнится с длительной стратегической игрой с другом или противником.
Как новичок или начинающий разрвботчик, вы вероятно задаетесь вопросом о том, как создаются подобные игры. Хотя есть множество составляющих, и разработка игры представляет собой длительный процесс, есть некоторые базовые компонеты, о которых я расскажу в этой книге:
Механика игры
Планирование проекта
Блочная графика
Дизайн и разработка интерфейса
Воспроизведение звука
Контроль и управление соединениями
Инструментальные средства разработчика
Трехмерная анимация
Мнногопользовательская игра
Как вы можете видеть, просмотрев список тем, книга охватывает широкий диапазон тем, относящихся к программированию стратегических игр. Вы можете воспринимать эту книгу как набор строительных блоков для разработчика. Каждая тема, или блок, могут рассматриваться отдельно, а соединенные вместе эти блоки дают великолепный результат.

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

Ранние стратегии реального времени
Также, как история древних веков содержит много загадок, прошлое стратегических игр реального времени не является полностью ясным. Многие люди утверждают, что первая стратегия реального времени — это Dune от Westwood, но я вспоминаю намного более ранние примеры игр этого жанра.

Utopia от Intellivision
Игровое поле
Земля
Здания
Форт в игре Utopia
Фабрика в игре Utopia
Океан
Корабли
Рыба погода и пираты
Трусливые пираты бороздят океан игры Utopia

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

Сайты аукционов
Издатели
Итоги
Основы блочной графики
Что такое блок?
Мозаика из блоков на экране
Пример ландшафтных блоков
Зачем использовать блоки?
Использование блоков для экономии памяти
Пример карты для размещения блоков

Загрузка текстур
Буфер вершин полностью наряжен, но пока нет места куда он мог бы пойти. Как насчет нескольких текстур? Оставшаяся часть кода инициализации осуществляет загрузку текстур, необходимых программе TitleScreen. Для загрузки текстур я использую функцию D3DXCreateTextureFromFile() предоставляемую вспомогательной библиотекой DirectX. Вот как выглядит ее прототип:
HRESULT D3DXCreateTextureFromFile( LPDIRECT3DDEVICE9 pDevice, LPCSTR pSrcFile, LPDIRECT3DTEXTURE9 *ppTexture );

Функция vRender()
Функция vDrawInterfaceObject()
Отображение текстуры на экране
Расположение текстур на титульном экране
Горячие точки
Обнаружение активных зон
Окно программы D3D_MouseZones
Архитектура проекта D3D_MouseZones
Заголовочный файл Main h
Глобальные данные активных зон

Самоучитель по введению в экспертные системы

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

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

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

Текущее состояние проблемы
Текущее состояние проблемы - 2
Распределение материал книги по главам
Распределение материал книги по главам - 2
Рекомендуемая литература
Упражнения
Смысл экспертного анализа
Смысл экспертного анализ- 2
Характеристики экспертных систем
Характеристики экспертных систем - 2

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

Упражнения
Упражнения - 2
Упражнения - 3
Упражнения - 4
Поиск в пространстве состояний
Поиск в пространстве состояний - 2
Поиск в пространстве состояний - 3
Поиск в пространстве состояний - 4
Поиск в пространстве состояний - 5
Поиск в пространстве состояний - 6

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

Символические вычисления
Символические вычисления - 2
Почему LISP не является языком знаний
Символический уровень и уровень знаний
LISP и разработкпрограмм
Языки представления знаний
Языки представления знаний - 2
Рекомендуемая литература
Упражнения
Символическое представление

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

Системы, основанные нзнаниях
Рекомендуемая литература
Упражнения
Упражнения - 2
Упражнения - 3
Канонические системы
Канонические системы - 2
Системы правил для решения проблем
Синтаксис представления правил
Синтаксис представления правил - 2

Ассоциативные сети и системы фреймов
В предыдущей главе уже отмечалось, что порождающие правила очень подходят для представления связей состояния некоторой проблемы с действиями, которые необходимо предпринять для продвижения к искомому решению. Однако иногда для решения проблемы больший интерес представляет не ответ на вопрос "Что делать, если...?", а свойства и взаимоотношения между сложными объектами в предметной области. Представлять знания о таких объектах и событиях и их взаимосвязях (таких как тип — подтип, часть — целое, до — после и т.д.) с помощью формальных правил далеко не всегда удобно.

Ассоциативные сети и системы фреймов
Множественное наследование
Множественное наследование - 2
Множественное наследование - 3
Сравнение сетей и фреймов
Рекомендуемая литература
Упражнения
Упражнения - 2
Графы, деревья и сети
Графы, деревья и сети - 2

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

Метаклассы в CLOS и CLIPS
Метаклассы в CLOS и CLIPS - 2
Множественное наследование в C++
Множественное наследование в C++ - 2
Множественное наследование в C++ - 3
Множественное наследование в C++ - 4
Множественное наследование в C++ - 5
Объектно-ориентированный анализ
Рекомендуемая литература
Упражнения

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

PROLOG и MBASE
Правилпоискв языке PROLOG
Правилпоискв языке PROLOG - 2
Управление поиском в системе MBASE
Управление поиском в системе MBASE - 2
Управление поиском в системе MBASE - 3
Управление поиском в системе MBASE - 4
Управление поиском в системе MBASE - 5
Рекомендуемая литература
Упражнения

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

Теория возможности
Теория возможности - 2
Неопределенное состояние неопределенности
Рекомендуемая литература
Источники неопределенности
Источники неопределенности - 2
Экспертные системы и теория вероятностей
Условная вероятность

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

Эксперты для извлечения знаний в COMPASS
Эксперты для извлечения знаний в COMPASS - 2
Эксперты для извлечения знаний в COMPASS - 3
Автоматизация извлечения знаний в OPAL
Графический интерфейс модели области
Графический интерфейс модели области - 2
Графический интерфейс модели области - 3
Графический интерфейс модели области - 4
Графический интерфейс модели области - 5
Графический интерфейс модели области - 6

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

Структурзадач в системе NEOMYCIN
Структурзадач в системе NEOMYCIN - 2
Структурзадач в системе NEOMYCIN - 3
Рекомендуемая литература
Упражнения
Упражнения - 2
Инструментальные средстви задачи
Инструментальные средстви задачи- 2
Инструментальные средстви задачи - 3
Эвристическая классификация в MUD и MORE

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

Эвристическая классификация (I)
Эвристическая классификация (I) - 2
Классификация задач экспертных систем
Классификация задач экспертных систем - 2
Классификация задач экспертных систем - 3
Классификация задач экспертных систем - 4
Классификация методов решения проблем
Эвристическое сопоставление
Эвристическое сопоставление - 2
Общность эвристической классификации

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

Рабочая срединженерии знаний TDE
Рабочая срединженерии знаний TDE - 2
Рабочая срединженерии знаний TDE - 3
Рекомендуемая литература
Упражнения
Упражнения - 2
Упражнения - 3
Влияние сложности на организацию системы
Влияние сложности на организацию системы - 2
Влияние сложности на организацию системы - 3

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

Решение проблем конструирования (I)
Рекомендуемая литература
Упражнения
Упражнения - 2
Области применения методов
Области применения методов - 2
СистемR1/XCON
СистемR1/XCON - 2
Компоненты и ограничения
Компоненты и ограничения - 2

Решение проблем конструирования (II)
В предыдущей главе мы рассматривали экспертные системы для решения проблем конструирования, в которых по ходу процесса никогда не возникала необходимость отмены уже принятых решений. Однако такая стратегия подходит далеко не для всех задач конструирования, поскольку мы не всегда располагаем всеми необходимыми для этого знаниями о предметной области. В этой главе мы проанализируем применение двух стратегий — наименьшего принуждения (least commitment) и предложение и пересмотр (propose and revise). Завершит главу обзор некоторых инструментальных средств приобретения знаний, которые используются в системах решения проблем конструирования

Стратегии конструирования
Стратегии конструирования - 2
Стратегии конструирования - 3
Стратегии конструирования - 4
Архитектура систем планирования
Архитектура систем планирования - 2
Архитектура систем планирования - 3
Архитектура систем планирования - 4
Архитектура систем планирования - 5
Архитектура систем планирования - 6

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

Системы ВВи ACCORD
Системы ВВи ACCORD - 2
СистемPROTEAN
Интеграция стратегий логического вывода
Общая характеристикВВ
Эффективность и гибкость модели с доской объявлений
Организация доски объявлений в системе GBB
Организация доски объявлений в системе GBB - 2
Организация доски объявлений в системе GBB - 3
Компоновкдоски объявлений в среде ERASMUS

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

Отслеживание зависимостей
Релаксация в сети
Пересмотр допущений
Пересмотр допущений - 2
Пересмотр допущений - 3
Пересмотр теорий высказываний
Пересмотр теорий высказываний - 2
Немонотонное обоснование
Немонотонное обоснование - 2
Немонотонное обоснование - 3

Формирование знаний на основе машинного обучения
В главе 1 мы уже вскользь упоминали о связи между приобретением знаний экспертной системой и использованием автоматизированных методов формирования знаний на базе машинного обучения (machine learning). Было отмечено, что в ряду тех проблем, с которыми сталкивается разработчик экспертной системы, приобретение знаний является одной из наиболее трудоемких. В главе 10 было рассмотрено множество методов извлечения знаний, но ни один из них не позволяет избавиться от услуг человека-эксперта и соответственно от значительного объема работы, выполняемой "вручную".

Формирование знаний носнове машинного обучения
Формирование знаний носнове машинного обучения - 2
Алгоритм формирования дереврешений по обучающей выборке
Алгоритм формирования дереврешений по обучающей выборке - 2
Алгоритм формирования дереврешений по обучающей выборке - 3
Алгоритм формирования дереврешений по обучающей выборке - 4
Алгоритм формирования дереврешений по обучающей выборке - 5
Алгоритм формирования дереврешений по обучающей выборке - 6
Алгоритм формирования дереврешений по обучающей выборке - 7
Алгоритм формирования дереврешений по обучающей выборке - 8

Сети доверия
В этой главе мы рассмотрим два количественных метода реализации логических рассуждений при наличии неопределенности в структурированном пространстве гипотез, базирующихся на теории свидетельств Демпстера—Шефера [Gordon and Shortliffe, 1985] и Байесовском формализме [Pearl, 1986]. Каждый из этих подходов предполагает, что на множестве гипотез каким-то способом определена функция доверия (belieffunction), а затем по мере накопления новых свидетельств применяется специфический механизм обновления текущего множества допущений.

Теория Демпстера—Шефера
Функции доверия
Функции доверия - 2
Применение теории Демпстера—Шеферк системе MYCIN
Применение теории Демпстера—Шеферк системе MYCIN - 2
Применение теории Демпстера—Шеферк системе MYCIN - 3
Применение теории Демпстера—Шеферк системе MYCIN - 4
МетодикПерла
МетодикПерл- 2
МетодикПерл- 3

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

Рассуждения, основанные нпрецедентах
Рассуждения, основанные нпрецедентах - 2
Сравнение систем, основанных нправилах и прецедентах
Рекомендуемая литература
Упражнения
Упражнения - 2
Базпрецедентов
ПрограммCHEF
ПрограммCHEF - 2
Методы извлечения и адаптации прецедентов

Гибридные системы
Раньше уже неоднократно высказывалась идея, что экспертная система может содержать не одну форму представления знаний. Даже в таких ранних системах, как MYCIN (см. главу 3), информация, специфическая для предметной области, хранилась в разных формах — например, в виде порождающих правил и в виде таблиц медицинских параметров. Программы, аналогичные CENTAUR (см. главу 13), уже можно было считать гибридными в том смысле, что в них объединялись разные способы представления знаний, а затем эти знания использовались с разной целью — для решения проблемы и формирования пояснений.

Организация обучения в системе SCALIR
Будущее гибридных систем
Рекомендуемая литература
Упражнения
Методы обучения в системе ODYSSEUS
Методы обучения в системе ODYSSEUS - 2
Методы обучения в системе ODYSSEUS - 3
Методы обучения в системе ODYSSEUS - 4
Системы ODYSSEUS и MINERVA
Оболочкэкспертной системы MINERVA

Загадки искусственного интеллекта
Тема искусственного интеллекта всегда была в информатике "страной плохишей", населенной массой "неправильных" проблем, не поддающихся решению традиционными способами. Эта область привлекла внимание прежде всего разносторонних специалистов, которых не испугало ее открытое, лишенное всякой организации пространство, — людей, которых влечет задача узнать, как мы мыслим. Такие исследователи, как Марвин Минский (Marvin Minsky), Джон Мак-Карти (John McCarthy), Герберт Саймон (Herbert Simon), Пат Хейес (Pat Hayes), Дональд Мичи (Donald Michie) и Бернард Мельтцер (Bernard Meltzer), стали первопроходцами для тех, кто следовал за ними по пути, пролегающем через информатику, психологию и математическую логику.

Загадки искусственного интеллекта
Загадки искусственного интеллекта- 2
Загадки искусственного интеллекта - 3
Представление знаний
Представление знаний - 2
Представление знаний - 3
Языки программирования систем ИИ
Языки программирования систем ИИ - 2
Решение практических проблем
Решение практических проблем - 2

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

Характерные сложности
Характерные сложности - 2
Инструментарий для экспертной системы
Инструментарий для экспертной системы - 2
Инструментарий для экспертной системы - 3
Инструментарий для экспертной системы - 4
Освоение инструментальных средств
Освоение инструментальных средств - 2
Освоение инструментальных средств - 3
Освоение инструментальных средств - 4

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

Проект Explainable Expert Systems
Проект Explainable Expert Systems - 2
Проект Explainable Expert Systems - 3
Проект Explainable Expert Systems - 4
Планирование текстов пояснений в PEA
Планирование текстов пояснений в PE- 2
Планирование текстов пояснений в PE- 3
Перспективы дальнейших исследований методов
Рекомендуемая литература
Упражнения

Литература

Литература
Литература- 2
Литература- 3
Литература- 4
Литература- 5
Литература- 6
Литература- 7
Литература- 8
Литература- 9
Литература- 10

Программирование на языке CLIPS
Первым этапом любого программного проекта является анализ решаемой проблемы. Эксперт должен уметь решить проблему, а инженер по знаниям должен разобраться, как именно было получено решение. При решении нашей задачи вам придется выступить в обеих ипостасях.
Предложенные головоломки можно решить, систематически анализируя, что случится, если персонаж, произносящий реплику, является правдолюбцем, а что, если он — лжец. Обозначим через Т(А) факт, что А говорит правду и, следовательно, является правдолюбцем, а через F(A) — факт, что А лжет и, следовательно, является лжецом.

Задач"Правдолюбцы и лжецы"
Анализ проблемы
Анализ проблемы - 2
Онтологический анализ и представление
Онтологический анализ и представление - 2
Онтологический анализ и представление - 3
Разработка правил
Разработка правил - 2
Разработка правил - 3
Разработка правил - 4

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

Современные процессы разработки программного обеспечения, такие как Rational Unified Process (RUP), Extreme Programming (XP) и Scrum, являются эволюционными по своей природе, и многие из них – быстрые (agile). При применении эволюционного подхода вы работаете одновременно в итерационной и инкрементальном режимах; быстрый подход сочетает эволюционность с высоким уровнем сотрудничества. Работая в итерационном режиме, вы в каждый момент времени немного моделируете, немного тестируете, немного кодируете и немного развертываете, потом еще немного, и еще немного, и т.д. При использовании инкрементального подхода вы организуете свою систему в виде последовательности выпусков, а не одного большого выпуска. Когда группа разработчиков прибегает к коллаборативному подходу, ее участники активно стараются найти способы эффективной совместной работы; следует даже добиваться того, чтобы инициаторы проекта (заказчики системы) являлись активными членами группы.

Быстрые методы для объектных баз данных
Скотт Амблер – известный, судя по Internet, специалист в области методологий разработки программного обеспечения. Его даже называют “гуру” быстрых (agile) методов разработки. Сам он ассоциирует себя с двумя компаниями – Ambisoft и Robin International – и называет себя старшим консультантом в обеих компаниях. Судя по фотографиям, Амблер достаточно молодой человек, а судя по числу написанных и изданных им книг, а также объему подготовленных им материалов, размещенных на www.ambysoft.com, исключительно активный. Статью, перевод которой мы вам предлагаем, Амблер написал специально для портала (хотя, похоже, что в этом его стимулировала компания db4objects, о которой мы еще поговорим).

Быстрые методы для объектных баз данных
Быстрые методы для объектных баз данных - 2
Быстрые методы для объектных баз данных - 3
Быстрые методы для объектных баз данных - 4
Быстрые методы для объектных баз данных - 5
Рефакторинг
Быстрое моделирование
Постоянное регрессионное тестирование
Конфигурационное управление
Песочницы разработчиков

Антипаттерны руководства командами разработки ПО
Некоторые руководители программных проектов, в первую очередь начинающие, в работе с людьми постоянно наступают на одни и те же грабли. В компьютерной науке для подобных частонаступаемых граблей придумано название #xab;антипаттерны#xbb; - это повторно используемые практики, которые могут давать видимость эффекта и даже временный эффект, однако, их применение наносит несоизмеримый ущерб конечному результату. Цель статьи - собрать вместе некоторые наиболее тяжелые грабли (антипаттерны), которые встречаются на пути управления командами разработки ПО, и попытаться объяснить, почему на них не стоит наступать.

О чем?
Первоисточники
В какое время мы работаем?
В какое время мы работаем? - 2
Что такое эффективность?
Что такое эффективность? - 2
Антипаттерны некомпетентности
Антипаттерны некомпетентности - 2
Антипаттерны мнительности
Антипаттерны мнительности - 2

Победа любой ценой
Закон Лермана гласит: «любую техническую проблему можно преодолеть, имея достаточно времени и денег». И с этим трудно не согласиться. Впрочем, следствие из этого закона не столь обнадеживающе, сколь он сам: «вам всегда будет не хватать либо времени, либо денег». И на самом деле, любой менеджер, которому хоть раз приходилось сталкиваться с выполнением проекта, знает, что существует определенное соотношение между длительностью выполнения проекта и его стоимостью.

Человеческий фактор
Человеческий фактор - 2
Человеческий фактор - 3
Мотивация в функциональной группе
Мотивация в функциональной группе - 2
Project Risk Management

Как добиться успеха в безнадежных проектах
Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.

Как добиться успеха в безнадежных проектах
Как добиться успеха в безнадежных проектах - 2
Как добиться успеха в безнадежных проектах - 3
Как добиться успеха в безнадежных проектах - 4
Как добиться успеха в безнадежных проектах - 5
Как добиться успеха в безнадежных проектах - 6
Как добиться успеха в безнадежных проектах - 7
Как добиться успеха в безнадежных проектах - 8

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

Жизненный цикл программного продукта
Определение требований
Определение требований - 2
Определение требований - 3
Анализ и проектирование
Анализ и проектирование - 2
Анализ и проектирование - 3
Разработка
Тестирование и профилирование
Тестирование и профилирование - 2

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

Простейший случай диаграмм
Простейший случай диаграмм - 2
Простейший случай диаграмм - 3
Простейший случай диаграмм - 4
Простейший случай диаграмм - 5
Простейший случай диаграмм - 6
Простейший случай диаграмм - 7
Простейший случай диаграмм - 8
Простейший случай диаграмм - 9
Простейший случай диаграмм - 10

Проектирования больше нет?
Тем, кто успел кратко познакомиться с принципами Extreme Programming (ХР), порой кажется, что в этой методологии нет места процессу проектирования программных продуктов. При этом высмеиваются не только "Большое и Подробное Предварительное Проектирование", но и такие техники как UML и гибкие каркасы приложений. Даже значение паттернов либо принижается, либо напрочь отрицается. На самом же деле, в ХР много проектирования, но подается оно по-другому, нежели в обычных устоявшихся процессах разработки ПО. Методология XP оживила эволюционное проектирование новыми техниками, благодаря которым его теперь можно считать вполне жизнеспособной стратегией.

Основополагающие практики ХР
Основополагающие практики ХР - 2
Преимущества простого дизайна
Преимущества простого дизайна - 2
"Простой дизайн" - что же это за зверь такой?
"Простой дизайн" - что же это за зверь такой? - 2
Нарушает ли рефакторинг принцип YAGNI?
Паттерны и ХР
Паттерны и ХР - 2
Наращивание архитектуры

Пересекая границы: специфика разработки ПО распределенной командой
Эта статья написана на основе опыта работы в нескольких проектах по разработке ПО, где участники проектной команды были в большей или меньшей степени удалены друг от друга: начиная от варианта #xab;одна команда в двух офисах в одном городе#xbb;, и заканчивая вариантом #xab;3 команды в разных странах #x2013; из них одна на другом континенте#xbb;. Как появляются такие проекты? В малых компаниях ценность конкретного специалиста для проекта часто выше, чем возможные расходы на коммуникацию, и его местожительство не берется в расчет. В крупных компаниях, наоборот, появляется большой объем работ, не требующих высокой квалификации, и задачи реализуются с привлечением субподрядчиков, в том числе из других стран.

Управляющая информация
Требования
Планы и бизнес-цели
Структура команды
Ответственность команд
Глоссарий
Способы коммуникации
Skype, Icq и другие системы
Телефон
Системы учета заданий и ошибок

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

Экономика производства программ
Экономика производства программ - 2
Экономика производства программ - 3
Экономика производства программ - 4
Организация производства программ
Организация производства программ - 2
Организация производства программ - 3
Организация производства программ - 4
Организация производства программ - 5
Заключение

Реализация стандарта ГОСТ Р ИСО/МЭК
Стандарт ГОСТ Р ИСО/МЭК 12207 определяет архитектуру верхнего уровня жизненного цикла программных средств (ЖЦ ПС) и может быть использован для организации работ по одному или нескольким процессам ЖЦ ПС. Вместе с ГОСТ Р ИСО/МЭК ТО 15271-2002 Руководство по применению ГОСТ Р ИСО/МЭК 12207 стандарт ГОСТ Р ИСО/МЭК 12207 предоставляет возможности для адаптации к широкому кругу задач на основе расширения рекомендаций стандарта путем ввода новых процессов, работ, задач или других объектов ЖЦ ПС, не рассматриваемых в стандарте. В качестве примера можно сослаться на раздел 4 приложения D к ГОСТ Р ИСО/МЭК ТО 15271-2002 - Пример сопровождения.

Ключевые особенности Rational Unified Process
Технология адаптации
Взаимодействие с другими процессами ЖЦ ПС
Ролевые функции и организационная структура
Роль артефактов в процессе адаптации
Адаптация и реализация процесса сопровождения
Оформление материалов в виде сайта
Оформление материалов в виде сайта - 2
Оформление материалов в виде сайта - 3
Оформление материалов в виде сайта - 4

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

Инструменты проектного менеджмента
Инструменты проектного менеджмента - 2
Обзор и классификация АСУПП
Обзор и классификация АСУПП - 2
Обзор и классификация АСУПП - 3
Обзор и классификация АСУПП - 4

Четвертое измерение или Как обмануть Железный Треугольник
Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.

Как обмануть Железный Треугольник
Как же обмануть Железный Треугольник?
Пусть все люди работают в одном помещении
Тихая гавань и стратегии управления проектами
Быстрое документирование плюс обсуждение
Одновременная разработка

Понятие «реинжиниринга ИС», его содержание и место в ЖЦ ИС
Сегодня в мире существует большое количество подходов, методов и технологических решений, напрямую или косвенно соотносимых с деятельностью по реинжинирингу ИС. Однако они не интегрированы на уровне методологий (процессов разработки). Как результат, можно наблюдать наличие огромного количества методологий, где основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие «стройных» методологий, целью создания которых являлось бы комплексное, целостное решение задач реинжиниринга ИС.

Понятие реинжиниринга ИС
Понятие реинжиниринга ИС -2
Реинжиниринг ИС и его место в ЖЦ ИС.
Реинжиниринг ИС и его место в ЖЦ ИС - 2
Реинжиниринг ИС и его место в ЖЦ ИС - 3
Реинжиниринг ИС и его место в ЖЦ ИС - 4
Реинжиниринг ИС и его место в ЖЦ ИС. - 5
Реинжиниринг ИС и его место в ЖЦ ИС. - 6
Реинжиниринг ИС и его место в ЖЦ ИС. - 7
Реинжиниринг ИС и его место в ЖЦ ИС - 8

Designing for FAILURE - ключ к успеху?
Трудно найти более квалифицированного специалиста в области проектирования и разработки систем управления базами данных, чем почетный сотрудник IBM (IBM Fellow) Брюс Линдсей. Он начал заниматься архитектурой РСУБД (реляционных систем управления базами данных) еще до того, как появились такие системы. В 1978 г., закончив аспирантуру Калифорнийского университета в Беркли и получив степень PhD, он поступил на работу в Исследовательскую лабораторию IBM в Сан-Хосе, где исследователи тогда работали над тем, что впоследствии стало основой языка SQL и продукта IBM DB2. С того времени Линдсей играет ведущую роль в развитии РСУБД.

Беседа с Брюсом Линдсеем
Беседа с Брюсом Линдсеем - 2
Беседа с Брюсом Линдсеем - 3
Беседа с Брюсом Линдсеем - 4
Беседа с Брюсом Линдсеем - 5
Беседа с Брюсом Линдсеем - 6
Беседа с Брюсом Линдсеем - 7
Беседа с Брюсом Линдсеем - 8
Беседа с Брюсом Линдсеем - 9
Беседа с Брюсом Линдсеем - 10

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

Системные характеристики КМП.
Интерпретация системных свойств к КМП.
Целесообразность.
Иерархическое строение.
Адаптация
Память
Разнообразие состояний
Метатехнология и технология самоорганизации
Область применимости
Условия применимости

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

Краткий обзор
Компоненты и объем методологии
Компоненты и объем методологии - 2
Принципы
Принципы - 2
Принципы - 3
Принципы - 4
Принципы - 5
Приоритеты
Методология и ее автор

Исполнение моделей при помощи виртуальной машины
Прошло уже почти 20 лет со времени появления в 1986 году вызвавшей множество споров статьи Фредерика Брукса «Серебряной пули нет». В данной работе автор предрекал, что в течение ближайшего десятилетия с момента её выхода не возникнет методов, использование которых позволит на порядок величин повысить производительность разработки программного обеспечения. Эта статья вызвала множество споров и работ с опровержениями, и в 1995 году Ф. Брукс опубликовал ответы на некоторые из критических замечаний

Для чего нужны модели
Для чего нужны модели - 2
Почему важно, чтобы модели были исполняемыми
Результат исполнения модели
Способы исполнения моделей
Интерпретация
Генерация автоматной модели
Виртуальная машина
Создание виртуальной машины
Виртуальная машина как строительный компонент

MSF – философия создания IT-решений или голые амбиции лидера
Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление.

Базовые концепции и принципы MSF
Единое видение проекта
Управляйте компромиссами
Треугольник компромиссов
Матрица компромиссов
Проявляйте гибкость – будьте готовы
Концентрация на бизнес-приоритетах
Поощряйте свободное общение
Создавайте базовые версии
MSF – симбиоз итеративного и фазового подхода

Внедрение систем управления. Что вначале - процессы или ПО?
В последнее время все большее число предприятий осознают необходимость создания автоматизированных систем управления проектами (далее АСУП). При этом первым и необходимым условием для успешной реализации проекта создания АСУП является наличие у руководства организации заинтересованности в будущей системе и четкого понимания целей, для достижения которых она создается. Это значительно упростит процесс формирования требований к системе.

Объем и подход к проведению внедрения
Объем и подход к проведению внедрения - 2
Описание бизнесс-процессов и ПО
Что первично - процессы или ПО?
Квалификация персонала
Квалификация персонала - 2
Квалификация команды проекта внедрения
Квалификация команды проекта внедрения - 2

О чем и зачем
Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».

Моцарт и Сальери
Моцарт и Сальери - 2
Моцарт и Сальери - 3
Моцарт и Сальери - 4
Моцарт и Сальери - 5
Моцарт и Сальери - 6
Моцарт и Сальери - 7
Моцарт и Сальери - 8
Моцарт и Сальери - 9
Моцарт и Сальери - 10

Семантическая реконсиляция прикладных данных на основе моделей
Рассматривается задача семантически корректной и функционально содержательной реконсиляции прикладных данных. Задача имеет ключевое значение для успешного применения современных технологий оптимистической репликации и создания перспективных распределенных приложений, таких как системы коллективной инженерии, мобильные базы данных, семантические сети. Рассматривается модельно-ориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL.

Роль модельно-ориентированного подхода
Роль модельно-ориентированного подхода - 2
Общий подход к реконсиляции
Этапы реконсиляции
Этапы реконсиляции - 2
Действия
Типы данных и виды ограничений
Семантический анализ транзакций
Понятие корректной транзакции
Понятие корректной транзакции - 2

Рефакторинг архитектуры программного обеспечения: выделение слоев
В последнее время наблюдается тенденция к увеличению продолжительности жизненного цикла успешных программных проектов. Как следствие, растет объем унаследованного кода, поддерживаемого сообществом разработчиков [1]. Именно это объясняет исключительную важность задач, связанных с облегчением сопровождения и развития существующего программного кода. В то же время, этим задачам уделяется недостаточное внимание со стороны научного сообщества и разработчиков инструментальных средств. Как следствие, современные методики переоценивают значение начальной фазы жизненного цикла программной системы и практически игнорируют ее дальнейшую эволюцию

Архитектура ПО и ее рефакторинг
Зачем менять архитектуру?
Как представить архитектуру и ее изменения?
Как представить архитектуру и ее изменения? - 2
Рефакторинг архитектуры
Архитектурный и классический рефакторинг
Фазы архитектурного рефакторинга
Фазы архитектурного рефакторинга - 2
Выделение слоев
Слои в архитектуре ПО

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

Основные понятия
Основные понятия - 2
Диалог с оппонентом
Основные проблемы
Задачи управления рисками
Планирование управления рисками
Выявление рисков
Анализ и оценка приоритетности
Планирование ответных действий
Мониторинг рисков

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

Роли в моделях взаимодействия
Роли в моделях взаимодействия - 2
Формализация понятия роли
Свойства ролей
Свойства ролей - 2
Роли в сценариях взаимодействия
Взаимосвязь с аспектами
Композиция поведения в разных ролях
Уточнение семантики композиции
Уточнение семантики композиции - 2

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

Основные вопросы отбора руководителей
Качества, необходимые руководителю
Качества, необходимые руководителю - 2
Качества, необходимые руководителю - 3
Качества, необходимые руководителю - 4
Подготовка и отбор руководителей проектов.
Подготовка и отбор руководителей проектов. - 2
Привлечение кадров в сферу управления

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

Роли
Скрам Мастер (Scrum Master)
Product Owner
Команда (Team)
Product Backlog
Sprint Backlog
Спринт (Sprint)
Планирование спринта
Планирование спринта, митинг первый
Планирование спринта, митинг второй

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

Описание специфики разработки
Рекомендации по организации разработки
Рекомендации по организации разработки - 2
Выделение основных процессов
Разработка требований
Разработка требований - 2
Планирование реализации требований
Планирование реализации требований - 2
Планирование реализации требований - 3
Управление запросами на поддержку

Структурное руководство проектом. Серебряная пуля?
Этот термин достаточно давно и активно используется в ИТ как символ технологического прорыва, который позволит разрабатывать ПО намного быстрее и качественнее. Дело в том, что Фред Брукс в 1987 году опубликовал очень широко известную статью под названием "No Silver Bullet" - "Серебряной пули не существует" - в которой доказывал, что нет и не предвидится никакого существенного прогресса в процессе разработки программного обеспечения.

Структурное руководство проектом
Структурное руководство проектом - 2
Структурное руководство проектом - 3
Структурное руководство проектом - 4
Структурное руководство проектом - 5
Структурное руководство проектом - 6
Структурное руководство проектом - 7
Структурное руководство проектом - 8

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

Анализ исполняемых UML-моделей
Характеристика конечных автоматов
Характеристика конечных автоматов - 2
Характеристика конечных автоматов - 3
Используемые конструкции
Используемые конструкции - 2
Типичные способы построения автоматов
Трансформация выделение метода для UML
Выделение в метод части конечного автомата
Выделение в метод части конечного автомата - 2

Трансформация UML-моделей и ее применение в технологии MDA
На данный момент разработаны и активно используются множество стандартов, middleware-технологий и платформ (CORBA, DCOM, Dot-Net, WebServices, JAVA-технологии и т.д.), и в будущем их количество будет расти. Попытки создать универсальную платформу, которая бы заменила все существующие, привели только к увеличению количества используемых технологий. Всё более важными становятся вопросы выбора технологии для конкретного проекта, осуществления взаимодействия и интеграции разнородных систем и переносе систем на новую технологическую платформу, когда используемая платформа устаревает и уже не может удовлетворить потребности заказчика. Решение может лежать в использовании новой, более совершенной методики разработки ПО.

Подходы к трансформации UML-моделей
Подходы к трансформации UML-моделей - 2
Подходы к трансформации UML-моделей - 3
Схема инструмента трансформации
Пример простейшей трансформации
Язык описания трансформации
Язык описания трансформации - 2
Язык описания трансформации - 3
Выполнение трансформации
Выполнение трансформации - 2

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

Теория для победителя
Теория для победителя - 2
Теория для победителя - 3
Теория для победителя - 4
Теория для победителя - 5
Теория для победителя - 6

Экстремальное программирование и быстрая разработка ПО
Любая идея, доведенная до абсурда, вырождается в собственную противоположность. Именно такая ситуация складывается в североамериканской промышленности ПО с RAD-средствами разработки. В некоторый момент инструменты, предназначенные для быстрой разработки приложений, стали вытеснять в умах менеджеров все остальное, в том числе разработчиков, заказчиков и сам проект. Неоправданное, гипертрофированное внимание к Процессу в ущерб другим факторам разработки породило массу формальных процедур — но качество полученных продуктов и количество успешных проектов оказалось разочаровывающим.

Экстремальный цикл
Позднее принятие решений
Кодирование в глубину
Идеальный день разработчика и фактор загрузки
Скорость проекта
История пользователей
План релиза
План итераций
Тесты приемки
Представители заказчиков

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

Игра в планирование
Тестирование до начала разработки
Парное программирование
Постоянная переработка
Простота разработки
Коллективное владение кодом
Продолжающаяся интеграция
Заказчик на рабочей площадке
Быстрый выпуск версий
Сорокачасовая рабочая неделя

Руководство командой разработчиков программного обеспечения

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

Продолжение
В какое время мы работаем? - 2
Изменение жизненной парадигмы
Прежние методы управления не работают?
Прежние методы управления не работают? - 2
Специфика разработки программ
Специфика разработки программ - 2
Специфика разработки программ - 3
Специфика разработки программ - 4
Специфика разработки программ - 5

Объектно-ориентированное проектирование с примерами

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

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

Концепции
Метод
Примеры приложений
Дополнительный материал
Дополнительный материал - 2
Дополнительный материал - 3
Концепции
Сложность
Простые и сложные программные системы
Простые и сложные программные системы - 2

Выбор реализации
Представление классов и объектов почти всегда должно быть инкапсулировано (скрыто). Это позволяет вносить изменения (например, перераспределение памяти и временных ресурсов) без нарушения функциональных связей с другими классами и объектами. Как мудро отметил Вирт: "выбор способа представления является нелегкой задачей и не определяется одними лишь техническими средствами. Он всегда должен рассматриваться с точки зрения операций над данными" [60]. Рассмотрим, например, класс, соответствующий расписаниям полетов самолетов. Как его нужно оптимизировать - по эффективности поиска или по скорости добавления/удаления рейса? Поскольку невозможно реализовать и то, и другое одновременно, нужно сделать выбор, исходя из целей системы. Иногда такой выбор сделать непросто, и тогда создается семейство классов с одинаковым интерфейсом, но с принципиально разной реализацией для обеспечения вариативности поведения.

Классификация
Классификация и ООП
Трудности классификации
Трудности классификации - 2
Трудности классификации - 3
Трудности классификации - 4
Классический и современный подходы
Классический и современный подходы - 2
Классический и современный подходы - 3
Классический и современный подходы - 4

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

Примеры приложений
Система сбора данных: метеорология
Определение границ рассматриваемой задачи
Определение границ рассматриваемой задачи - 2
Определение границ рассматриваемой задачи - 3
Определение границ рассматриваемой задачи - 4
Определение границ рассматриваемой задачи - 5
Определение границ рассматриваемой задачи - 6
Определение границ рассматриваемой задачи - 7
Определение границ рассматриваемой задачи - 8

Определение границ проблемной области
Для большинства люден, живущих в США, поезда являются символом давно ушедшей эпохи. В Европе и странах Востока ситуация совершенно противоположная. В отличие от США, в Европе мало национальных и международных автомобильных магистралей, а цены на бензин и газ сравнительно высоки. Поэтому поезда составляют основу транспортной сети континента; по десяткам тысяч километров путей ежедневно перевозится множество людей и грузов - и в отдельных городах, и между различными странами. Ради справедливости отметим, что в США поезда играют по-прежнему важную роль в перевозке грузов. С разрастанием городов их центры становятся все более и более перегруженными, и на легкий рельсовый транспорт возлагаются надежды решить проблему перегрузки и загрязнения окружающей среды двигателями внутреннего сгорания.

Определение границ проблемной области
Определение границ проблемной области - 2
Определение границ проблемной области - 3
Определение границ проблемной области - 4
Определение границ проблемной области - 5
Системные и программные требования
Системные и программные требования - 2
Системные и программные требования - 3
Ключевые абстракции и механизмы
Ключевые абстракции и механизмы - 2


Ассемблер для Windows
Справочник Ассемблер
Справочник по языку Ассемблера IBM PC
Как написать игру для ZX Spectrum на ассемблере
Сборник по задачам и примерам Assembler
Атеев Алексей - Серебряная Пуля
Асприн Роберт - Кровные Узы
Введение в схемы, автоматы и алгоритмы
Расширяемый язык разметки
Статьи по Assembler
Продукты Pinnacle
Разработка компиляторов
Автоматизация работы с текстом
CISCO порусски. Набор статей
Архитектура Unix
AutoCAD 2005 - среда проектирования
Программа AutoCAD 2004 - руководство
Система топологической трассировки печатных плат TopoR
ObjectARX, AutoCAD. Среда программирования библиотеки C++
Методы описания встраиваемой аппаратуры и построения инструментария кросс-разработки