CC BY
71
АВТОМАТИЗАЦИЯ ДЕЯТЕЛЬНОСТИ ПО ПРЕДОТВРАЩЕНИЮ ДЕФЕКТОВ В ПРОГРАММНОМ ПРОЕКТЕ
А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Как известно [1], во время выполнения программного проекта его исполнители допускают ошибки, часть которых переходит в дефекты. При этом оценка общего количества возможных ошибок в ходе выполнения программного проекта и оценка плотности поставляемых дефектов в программном изделии (ПИ) определяется уровнем качества разрабатываемого ПИ и привязывается к размеру его нового кода [2-4]. Деятельность по выявлению и предупреждению возможности возникновения ошибок и дефектов в программном проекте называется предотвращением дефектов. Выполнение этой деятельности в ходе разработки ПИ способствует достижению желаемого уровня качества как самой разработки, так и поставляемого ПИ [4].
С целью облегчения чтения последующего изложения определим основные термины, которые встречаются в настоящей статье.
Отклонение - любая неправильность в совокупности принятых характеристик объекта, ухудшающая какое-либо его свойство.
Ошибка - отклонение, обнаруженное на той же фазе жизненного цикла разработки ПИ, где оно и возникло.
Дефект - отклонение, допущенное на одной из предшествующих его обнаружению фаз жизненного цикла разработки ПИ.
Предъявленный дефект - любой дефект, обнаруженный в объекте.
Открытый дефект - предъявленный дефект, не устраненный к моменту измерения.
Закрытый дефект - предъявленный дефект, устраненный к моменту измерения.
Поставленный дефект - дефект, обнаруженный в поставленном продукте при его эксплуатации, или дефект, предъявленный до поставки, но не закрытый и содержащийся в поставленном продукте.
Уровень серьезности ошибки или дефекта - некоторая классификация последствий от проявления ошибки или дефекта. Обычно последствия проявления ошибок или дефектов оцениваются в баллах, например, от 1 до 3 по мере увеличения серьезности последствий. Высший бал приписывается проявлению, которое приводит к краху программной системы. Остальные значения баллов для уровней серьезности устанавливаются исходя из накопленного опыта на предприятии или из других соображений.
Деятельность по предотвращению дефектов включает в себя сбор реальных данных о выявленных отклонениях, анализ типов отклонений и уровня их серьезности. Кроме того, в нее входит выявление причин возникновения повторяющихся отклонений, идентификация причин и упорядочение их по приоритету. К этой деятельности также относится причинно-следственный анализ обнаруженных проблем и выработка по его результатам мероприятий по ис-
ключению найденных первопричин возникновения исследуемых проблем. После этого необходимо соблюдать систематическое выполнение выработанных мероприятий по предотвращению дефектов в повседневной работе над проектом.
Для повышения эффективности деятельности по предотвращению дефектов ее выполнение необходимо планировать. Причем эта деятельность должна быть обеспечена всеми необходимыми ресурсами и финансированием на уровне каждого проекта [6]. В каждой группе исполнителей программного проекта должен быть ответственный за деятельность по предотвращению дефектов. Ему, как правило, вменяются основные обязанности по разработке ПИ, а деятельность по предотвращению дефектов планируется на неполный рабочий день [4-5]. Для эффективного исполнения своих новых обязанностей ответственный за предотвращение дефектов должен обладать дополнительными знаниями по методам статистического анализа ошибок и дефектов, способам проведения собраний по причинно-следственному анализу и т.п.
Деятельность по предотвращению дефектов в проектной группе претворяется в жизнь по результатам анализа реальных данных, собранных в ходе выполнения проекта. В данные по предотвращению дефектов входит название продукта, в котором обна-
Обнаружение отклонения
Обнаружение (октрытие) отклонения
БАЗА ДАННЫХ ОТКЛОНЕНИИ
Принятие решения
ОТЛОЖЕНО [отложенный]
Рассмотрение .отклонений и принятие решения
ОТКЛОНЕНО
[не подтверждено
проверкой] [следствие другого
[уже закрыто] [неактуально]
ПРИНЯТО К УСТРАНЕНИЮ [открытое]
Закрытие
[ххх.. .хх] - статус отклонения
Работа по устранению отклонения разработчиком [устраняемое]
Проверка результатов работы над устранением отклонения [исправленный
Рассмотрение всех отклонений, готовых к закрытию [подт еержденн ый]
Закрытие отклонения
Рис.1. Модель жизненного цикла отклонения, обнаруженного в ходе выполнения проекта
2
ружено отклонение, описание отклонения, его уровень серьезности. Кроме того, к этим данным относится описание причин возникновения отклонений, фаза жизненного цикла разработки, на которой отклонение было порождено и на которой оно было обнаружено, ФИО лица, обнаружившего отклонение, и ФИО лица, устранившего его, трудоемкость обнаружения и устранения отклонения и т.п.
Модель жизненного цикла отклонения, которая используется на предприятии АОЗТ "Информационные деловые услуги" (ИДУ), г. С.-Петербург, представлена на рисунке 1.
Как видно из рисунка 1, жизненный цикл отклонения включает в себя четыре фазы: "Обнаружение", "Принятие решения", "Устранение" и "Закрытие отклонения". На каждой фазе жизненного цикла отклонения должны собираться реальные данные с целью обеспечения эффективной деятельности по предотвращению дефектов, должна обеспечиваться их достоверность и накопление данных в течение всего жизненного цикла проекта. В ИДУ для осуществления деятельности по предотвращению дефектов используются метрики, представленные ниже.
На фазе "Обнаружение" собираются такие метрики, как имя продукта, в котором обнаружено отклонение, вид отклонения, уровень серьезности отклонения, описание отклонения, трудоемкость его обнаружения, фаза, на которой обнаружено отклонение, ФИО лица, обнаружившего отклонение, дата обнаружения отклонения.
На фазе "Принятие решения" используются такие метрики, как статус отклонения, фаза возникновения отклонения, причина возникновения отклонения; на фазе "Устранение" - трудоемкость устранения отклонения, ФИО лица, осуществившего устранение отклонения, дата устранения отклонения; на фазе "Закрытие" - дата закрытия отклонения, ФИО лица, осуществившего закрытие отклонения.
Практический опыт по выполнению программных проектов, накопленный в АОЗТ ИДУ, подтвердил, что набор представленных метрик является достаточным для обеспечения возможности эффектив-ното исполнения деятельности по предотвращению дефектов в соответствии с установками, изложенными в модели СММ [5].
Для определения области автоматизации деятельности по предотвращению дефектов обратимся к рисунку 1. Нетрудно заключить, что все фазы жизненного цикла отклонения действия по выявлению, принятию решений, устранению и закрытию отклонений осуществляются разработчиками ПИ. К сожалению, их творческая деятельность пока не поддается автоматизации. Однако автоматизации под силу процесс сбора метрик, которые впоследствии накапливаются и хранятся в базе данных отклонений. Можно также автоматизировать некоторые виды анализа собранных метрик и создать автоматическую генерацию различного вида
Автоматизированный сбор метрик на всех фазах жизненного цикла программного проекта
Автоматизированный
сбор метрик при открытии отклонений
Автоматизированный
сбор метрик при закрытии отклонений
База метрических данных по программному проекту
Автоматический анализ
и генерация метрических отчетов по
предотвращению дефектов и качеству ПИ
Метрические отчеты по
предотвращению дефектов и качеству ПИ
Рис. 2. Структура модуля автоматизации деятельности по предотвращению дефектов
метрических отчетов с целью облегчения исполнения деятельности по предотвращению дефектов.
Именно по такому пути пошли мы, создавая специальный модуль автоматизации деятельности по предотвращению дефектов, который был включен в ранее созданную автоматизированную систему советчик (АСС) для руководителя программного проекта [4]. Структура этого модуля представлена на рисунке 2. Основой модуля является база метрических данных программного проекта. Для записи текущих значений метрик в базу данных используется персонифицированная электронная таблица, показанная на рисунке 3.
При вызове этой таблицы на экран монитора она автоматически привязывается к сетевым системным часам. В центре экранной формы над таблицей высвечивается дата текущего календарного дня, изменение даты разработчику недоступно. Кроме того, эта таблица автоматически привязывается к ФИО исполнителя, работающего на компьютере, на экран монитора которого вызвана настоящая таблица. Подробней о персонифицированной метрической таблице изложено в [4].
Для автоматизированной записи метрик при открытии отклонения используется экранная форма (ведомость обнаруженных отклонений), представленная на рисунке 4, которая вызывается из экранной формы (рис. 3) путем нажатия соответствующей кнопки.
ПРОЕКТ DEMO Григорьева A.C.
[а метрик | 03.0i.00 |
ВНЕСТИ ДАННЫЕ ОБ ОЕНАРУЖЕНЫХ ОТКЛОНЕНИЯХ
ВНЕСТИ ДДННЫЕ О ЗАКРЫ1ЫХ ОТКЛОНЕНИЯХ
Наименование работы затраченное время Объем работы, выло лненной чя день
Текст Код
Новый Побтлип. Удаленный
часы страницы KAELOC KAELOC KAELOC
'азрабопса Алгоритма классификации объектов 6,00 2,00
кодирование алгоритма классификации объектов 2,00 1,00
ИТОГ ОВАЯ СТРОКА: 8,00 1 ДО ОЯО 1,00 ода
ПРОИЗВЕСТИ ЗАПИСЬ В БАЗУ ДАННЫХ
Рис. 3. Персонифицированная метрическая электронная таблица
3
| НАИМЕНОВАНИЕ РАБОТЫ А
| ВИД ОТКЛОНЕНИЯ_ м
| УРОВЕНЬ СЕРЬЕЗНОСТИ ч
| ПРИЧИНЫ ОТКЛОНЕНИЯ ч
| ФАЗА ВОЗНИКНОВЕНИЯ ОТКЛОНЕНИЯ ч
| КОДЫ ПРОДУКТА, СОДЕРЖАЩЕГО ОТ1-^|
ВОЗВРАТ В ПЭТ
ПРОИЗВЕСТИ ЗАПИСЬ В БАЗУ ДАННЫХ
Трудоемкость |
ОПИСАНИЕ ОТКЛОНЕНИЯ
Рис. 4. Ведомость обнаруженных отклонений
Заполнение ведомости обнаруженных отклонений выполняет разработчик ПИ, которому поручена роль ответственного за предотвращение дефектов в проектной группе. Одному отклонению в таблице ведомости отведена одна строка. В каждой строке таблицы (см. рис. 4) первые пять столбцов наполняются надлежащим содержанием из списка, который формируется из метрической базы данных проекта. Выбор требуемого содержания производится путем
нажатия соответствующей клавиши в левом верхнем углу экранной формы (рис. 4). Эти клавиши обозначены как "Ввод данных для 1-5, 8 столбцов". Описание отклонения вводится разработчиком при помощи клавиатуры и, как правило, включает следующую информацию: в чем именно оно заключается и как проявляется, к чему приводит это проявление и т.п. Для описания отклонения зарезервировано 256 символов. В предпоследний столбец строки заносится реальное значение трудоемкости обнаружения данного отклонения, а в последний - код продукта, содержащего отклонение, который также выбирается из списка. Описанным образом заполняются данные по всем отклонениям, подготовленным к записи в базу данных в текущий календарный день.
Заметим, что после осуществления записи в базу данных отклонений (после нажатия кнопки "Произвести запись в базу данных", см. рис. 4) каждой строке таблицы в базе данных приписывается уникальный номер, а данные из таблицы привязываются к текущему календарному дню. При этом в ведомости обнаруженных отклонений из строк убираются все внесенные данные и запрещается любая последующая запись в них. Таким способом решена задача
защиты данных об отклонениях от несанкционированного изменения.
Из экранной формы нажатием соответствующей кнопки вызывается электронная таблица для записи метрик при закрытии отклонений (ведомость закрываемых отклонений).
Ведомость заполняется аналогичным образом, что и ведомость открываемых отклонений. В ведомости также предусмотрена блокировка повторной записи данных в базу данных отклонений. Записи данных из таблиц в базу данных отклонений производятся систематически в течение всего жизненного цикла проекта. В результате чего в базе данных происходит накопление реальных данных об отклонениях. Вид данных об отклонениях, предъявленных за определенный период наблюдения и хранящихся в базе данных отклонений, показан на рисунке 5.
Набор данных (рис. 5) позволяет осуществить практически любой вид анализа, необходимый для оценки текущего состояния качества разработки и создаваемого ПИ, а также для обоснованного формирования механизмов и мероприятий по предотвращению дефектов. Приведем несколько диаграмм, полученных в результате автоматической обработки метрических данных об отклонениях.
Для отслеживания изменения количества обнаруженных и устраненных отклонений в АОЗТ ИДУ используется диаграмма, показанная на рисунке 6.
Граф нк устранен — на 28-04 ЛС
1120
ё
1
1
1 1 1 1 1 1 1 1 1 ! 3 1
1 ^—ПРОГНОЗ I —й-мкрьпо -о—открыто
| 22.05.00 |
СОЗДАТЬ ЭЛЕКТРОННУЮ КОПИЮ
Рис. 6. Графики динамики обнаружения и устранения отклонений при разработке ПИ
Рис. 5. Вид данных об отклонениях, предъявленных за определенный период _наблюдения и хранящихся в базе данных отклонений_
4
Рис. 7. Распределение отклонений по категориям продуктов
Эта диаграмма состоит из графиков отклонений: предъявленных, открытых и закрытых. Все графики строятся с нарастающим итогом. Кроме того, на диаграмме прочерчена прямая линия, параллельная оси абсцисс. Ордината линии равна оценке количества допустимых отклонений в проекте ПИ с определенным размером и заданным качеством (подробнее см. [6]).
На рисунке 7 представлена диаграмма Парето, отражающая распределение отклонений по категориям продуктов, упорядоченным по количеству отклонений.
Такая наглядная диаграмма позволяет быстро определить, в какой категории продуктов наблюдается более всего отклонений, где можно ожидать возникновения проблем. Кроме того, она может использоваться в качестве исходных данных для планирования деятельности по предотвращению дефектов.
На рисунке 8 показана другая диаграмма Парето, представляющая распределение дефектов с учетом стоимости их устранения по категориям продуктов.
Из рисунка 8 видно, что устранение дефектов из программных кодов стоит дороже, чем их устранение из документации, хотя в документации их значительно больше. Эта диаграмма помогает принять правильное решение при определении первоочередных задач в деятельности по предотвращению де-
фектов. Заметим, что диаграммы рисунков 7, 8 используются также и при проведении причинно-следственного анализа.
На рисунке 9 показана еще одна диаграмма Паре-то - распределение отклонений по причинам за некоторый период наблюдения. Слева на этой диаграмме расположено окно, при помощи которого можно уточнить вид диаграммы и получить распределение по причинам ошибок или дефектов. Диаграмма наглядно показывает причину, вызывающую наибольшее число отклонений. По диаграмме можно сделать заключение о том, на решение какой проблемы следует обратить внимание в первую очередь.
В АОЗТ ИДУ для обеспечения качества ПИ и деятельности по предотвращению дефектов используются диаграммы, которые строятся автоматически: "Распределение отклонений по способам выявления за период, по уровням серьезности и фазам возникновения" и диаграмма "Все предъявленные отклонения за период" (см. рис. 5). Обратим внимание на то, что на диаграмме рисунка 5 в каждом столбце установлен автофильтр данных. Руководитель проекта или любой другой сотрудник может использовать эти автофильтры по своему усмотрению для проведения углубленного анализа возникновения отклонений. Например, можно выяснить, кто из сотрудников больше всего обнаруживает ошибок или на какой фазе обнаруживается больше всего дефектов.
Важное место в деятельности по предотвращению дефектов занимает причинно-следственный анализ. Такой анализ должен проводиться на предприятии в каждой проектной группе [5]. В процессе этого анализа строится причинно-следственная диаграмма Ишикавы [7], получившая название рыбий скелет, потому что такая диаграмма, детально проработанная, напоминает именно его. Диаграмма Ишикавы предназначена для наглядного представления связей между проблемой (следствием) и вызвавшими ее причинами (рис. 10).
Причинно-следственные диаграммы в процессе осуществления деятельности по предотвращению дефектов строят для того, чтобы наглядно представить различные обстоятельства или проблемы, влияющие на возникновение отклонений. Практический опыт показывает, что каждое обстоятельство или проблема обусловлены несколькими категориями причин. Категории причин, вызывающих откло-
Рис. 8. Распределение дефектов с учетом стоимости их устранения по категориям продуктов
5
нения в продуктах программного проекта, в АОЗТ ИДУ обозначены как "Люди", "Инструментальные средства", "Методы", "Процесс". Выбор этих категорий причин продиктован прежде всего тем, что имеющийся практический опыт подтверждает возникновение большинства проблем именно от них. Кроме того, использование категории "Процесс" в причинно-следственном анализе обеспечивает дополнительные возможности в выявлении слабых сторон стандартного процесса. Однако причинно-следственный анализ полезно расширять и проводить, не ограничиваясь лишь приведенным набором категорий. Подойдет любой набор категорий причин, который облегчит нахождение первопричины возникновения отклонений и поможет участникам причинно-следственного анализа в творческом мышлении.
При проведении причинно-следственного анализа в проектной группе в АОЗТ ИДУ используется экранная форма. Изображение этой формы вызывается на экран монитора при нажатии клавиши "Причинно-следственный анализ" в меню отчетов по качеству в системе АСС. В голову рыбьего скелета при причинно-следственном анализе отклонений в качестве следствия автоматически заносится первая слева категория из диаграммы рисунка 7. Если причинно-следственному анализу подвергаются ошибки в продуктах проекта, дефекты в них или дефекты с учетом стоимости их устранения, то в голову рыбьего скелета в качестве следствия помещается первая слева категория из соответствующих диаграмм, которые автоматически генерируются из базы данных отклонений. В голову рыбьего скелета в качестве следствия можно занести и другие данные в зависимости от того, какая проблема подвергается анализу. Для обеспечения такой возможности на экранной форме предусмотрена возможность выбора необходимого для
этого следствия. Полученные таким путем заготовки рыбьего скелета в дальнейшем служат основой для проведения причинно-следственного анализа.
В АОЗТ ИДУ причинно-следственный анализ проводится у экрана монитора или с использованием твердых копий заготовок рыбьего скелета при участии полного состава проектной группы. В любом случае причины для анализа выбираются коллективно из диаграммы "Распределение отклонений по причинам за период" (см. рис. 9) и распределяются по костям рыбьего скелета под подходящими категориями. Затем осуществляется поиск ответа на вопрос "чем вызвана эта причина?" и изображение его в виде ветвей диаграммы. Для нахождения первопричины исследуемой проблемы следует искать повторяющиеся причины, сравнивать частоту различных причин и достигать взаимопонимания в команде участников анализа. Причинно-следственный анализ является творческим коллективным процессом, поэтому при его проведении необходимо поощрять любую инициативу к стремлению более глубокого продвижения в поиске первопричин возникновения исследуемых проблем, а также добиваться полного согласия всех членов команды в установлении каждой первопричины.
По результатам причинно-следственного анализа для устранения выявленных первопричин строится таблица действий. Сроки выполнения запланированных действий и их эффективность находятся под постоянным контролем как со стороны руководителя проекта, так и со стороны группы процесса.
Собрания по причинно-следственному анализу в АОЗТ ИДУ проводятся в каждой проектной группе один раз в месяц в соответствии с формальной процедурой стандартного процесса.
В заключение отметим, что в АОЗТ ИДУ причинно-следственный анализ проводился в течение нескольких лет одновременно в разном количестве проектных групп (максимально в пяти). Результаты проведенных мероприятий из таблицы действий, построенной по данным выполненного причинно-следственного анализа, продемонстрировали, что в тех проектных группах, где наблюдалась тенденция к снижению количества предъявленных отклонений, как в текущем проекте, так и в последующих к причинно-следственному анализу относились серьезно. А в тех проектных группах, где причинно-следственный анализ проводился лишь "для галочки", снижения количества предъявленных отклонений не наблюдалось ни в текущем, ни в последующих проектах. Это наблюдение свидетельствует о том, что причинно-следственный анализ отклонений является эффективным средством повышения качества и самой разработки, и поставляемого ПИ.
Список литературы 1. Boehm B.W. Software Engineering Economics. - Englewood Cliffs: Prentice Hall, 1981. - 767 p. - Русский перевод: Боэм Б.У. Ин-
6
женерное проектирование программного обеспечения: / Пер. с англ. - М.: Радио и связь, 1985. - 512 с.
2. Six Sigma Producibility Analysis and Process Characterization, by M.J. Harry and J.R. Lawson, Motorola University Press, Chapter 6.
3. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при создании программных изделий. // Программные продукты и системы. - 1998. - №2. - С.2-6.
4. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. - М.: Наука, 2000. - 182 с.
5. Paulk M.C., Curtis В., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.
6. Домарацкий А.Н., Домарацкий Я.А. Вероятность обнаружения дефектов во время тестирования программных изделий. // Программные продукты и системы. - 1999. - №4. - С.12-15.
7. "Семь инструментов" управления качеством. / Материалы проекта ISO 9000. http://www.iso9000.ru/.
ОРГАНИЗАЦИЯ И МОДЕЛИ СИСТЕМЫ МОБИЛЬНЫХ АГЕНТОВ
В.С. Фомичев, И.И. Холод
Многие авторы отмечают наличие аналогии между структурами программных систем и социальными структурами. Некоторые даже предлагают создать специальную научную дисциплину для изучения социальных структур - хамонику.
Примеры таких аналогий известны: отдел снабжения и система управления ресурсами компьютера, структура хранилища библиотек и файловая система, организация ограниченного доступа к секретным материалам и подсистема администрирования.
С появлением компьютерных сетей расширились возможности реализации децентрализованных распределенных систем. Прототипами таких систем в обществе являются: искатели, научные экспедиции, ревизоры, курьеры, коммивояжеры и т.д. Все они обладают способностью автономных действий и изменения местоположения. Аналогиями подобных децентрализованных структур в области программного обеспечения являются системы мобильных агентов.
Следует отметить, что в социальной среде централизованные и децентрализованные организации мирно сосуществуют, поскольку они, как правило, используются для решения различных классов задач. По-видимому, такое положение должно сохраниться и в области разработки и применения программных систем.
Мобильным агентом называется автономная программа, способная перемещаться с машины на машину в неоднородной среде. Выполняя свои задачи, она на каждой машине взаимодействует со служебными агентскими компонентами и другими ресурсами, по окончании работы возвращается вместе с результатами [2,6,9-11,17].
Возможность перемещения позволяет системам, использующим мобильных агентов, динамически перераспределять вычислительную нагрузку в зависимости от состояния сети. Если выполнение вычислений на одном из узлов стало не эффективно, агент может приостановить свою работу, переместиться на менее загруженный компьютер и продолжить работу на нем. Другим преимуществом данной технологии является возможность перемещения вычислительной нагрузки ближе к данным, над которыми производятся какие-либо операции (изменение, поиск, фильтрация и т.д.), что позволяет не только повысить эффективность работы, но и снизить загруженность
сети. Еще одним достоинством мобильных агентов является их автономность, то есть агент, наделенный некоторыми полномочиями, может в дальнейшем без участия пользователя выполнить поставленную перед ним задачу.
Преимущества технологии мобильных агентов позволяют использовать ее в самых разных областях человеческой деятельности.
Система Agent Tcl [2,4,8], разработанная в Дорт-мундском университете, в первую очередь используется в приложениях, осуществляющих распределенную выборку информации. Мобильный агент запускается на компьютере пользователя, принимает от него запрос на поиск, последовательно перемещается по узлам сети, где хранятся группы отчетов, и вступает во взаимодействие с местными специальными агентами, которые ищут для него необходимые документы. По мере продвижения агент объединяет и упорядочивает полученные материалы.
Агенту не обязательно посещать последовательно один за другим интересующие его узлы. Вместо этого он может клонировать множество дочерних агентов, которые будут выполнять свои функции параллельно. Как только главный агент получает в свое распоряжение материалы, выбранные из каждого архива документов, он объединяет и фильтрует их, а затем возвращается с окончательным вариантом на исходную машину.
С развитием инфраструктуры коммуникаций все большую популярность приобретает беспроводная связь, обеспечивающая качественно более высокий уровень мобильности и оперативности. И хотя для некоторых относительно несложных применений характеристики таких мобильных каналов связи вполне приемлемы, имеются области, в частности задачи, связанные с работой с корпоративными базами данных, в которых использование каналов связи сильно затруднено [2, 5].
Автономность, присущая мобильным агентам, позволяет им существовать и выполнять свои задачи без вмешательства со стороны пользователя. Это снимает необходимость постоянного соединения исходного компьютера с сетью. Подключение требуется лишь при пересылке агента в сеть и при его возвращении с результатами. При таком подходе к коммуникации компьютера с сетью предъявляются са-
7
