Kuznetsov Alexey, 20 September 2005.
Здесь будет дана оценка трудозатрат на модификацию системы BOINC для использования в проекте Test Grid.

Стоимость развертывания системы, основанной на BOINC.

Развертывание системы BOINC без написания какого-либо крда невозможна в принципе. Т.к. в этой системе отсутствуют некоторые компоненты, которые пишутся под конкретную задачу:
		1. Work Generator - Для каждого проекта свой. Он создает workunit'ы и 
				    соответствующие входные файлы для каждого такого unit'а.
				    Имеется специальное API для регистрации всего этого в 
				    базе данных BOINC-сервера.
		2. Validator      - Для каждого проекта свой. Управляет избыточностью и контролирует
				    принятие согласованных результатов, как предположительно верных.
		3. Assimilator    - Для каждого проекта свой. Управляет теми заданиями, которые были
				    помечены как выполненные, вернувшие предположительно верный 
				    результат или сообщение об ошибке. Успешное завершение может 
				    инициировать его фиксацию в БД, и/или генерацию новой работы 
				    для клиентов.

Общие сведения о том, что нужно переделать.

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

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

Общие сведения о том, что придется сделать с нуля.

Необходимо изучить соответствующий API, и создать с нуля компоненты, необходимые для развертывания.

Система позволяет смотреть за состоянием работы, но результаты просто складываются в БД и не доступны для просмтотра. Поэтому нужно клиентское ПО, осуществляющее отображение результатов. На самом деле, в каждом проекте BOINC для подогревания интереса добровольцев в участии, такое ПО имеет некий web-интерфейс, но обработка и представление результатов ложится на разработчиков.

Одна из проблем - то, что те единицы исполнения, которые могут быть разосланы BOINC - это исполняемый код, поэтому Java-классы могут быть переданы только как входные данные для этого исполняемого кода. Фактически это означает, что нам придется организовать сложную структуру:

Таким образом нам оказывается недостаточно воспользоваться тем ПО, которое отвечает за исполнение заданий, поэтому мы вынуждены делать прослойку, которая может выполняться как задача, а на самом деле запускает JVM и запускает на ней код тестировщика.

Cтоимость решения проблем.

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

Красным помечены те подсистемы, которые требуют либо модификации, либо создания с нуля.

Проблемы, стоимость решения которых неясна.

Проблема отказа от screen-saver подхода, вероятно после этого придется вносить изменения в ядра клиентского ПО, которое не распространяется в открытых исходниках.

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

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