0.Как позиционируется система?

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

1. На какую предположительно нагрузку будет рассчитана система?

Тут, думаю, все ясно, а именно, нужно знать, что должна гарантировать система, какое количество тестов должна гарантированно обрабатывать, сколько пользователей должна “держать”, какую динамику работы этих пользователей должна гарантированно поддерживать? От этого во многом зависят все остальные параметры, поэтому вопрос представляется очень важным.

2. Неясен принцип работы системы в целом.

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

Дальше, как распределяются задания? Сразу бросаются в глаза две схемы. Первая, применяемая в BOINC, подразумевает, что клиент запрашивает у сервера работу, и дальше прекращает вести с ним диалог, пока работа не будет выполнена. Фактически, клиенты сами управляют своей работой. Вторая схема заключается в том, что клиент постоянно находится на связи с сервером и испольняет директивы сервера. То есть, работой клиентов управляет сервер (естественно, принимая во внимание особенности каждого клиента). У обоих схем есть преимущества и недостатки (они рассматривались довольно подробно в ранних документах осенью, когда прототип только обсуждался, и обзоры доступны на сайте), и нужно решить, какая из них наиболее удобна для наших целей. В прототипе была выбрана первая схема, но лишь потому, что она диктуется системой BOINC.
Возможно, есть третья (четвертая, пятая?) схема? 

Далее, непонятно, интересуют ли нас какие-либо хитроумные алгоритмы планирования распределения/выполнения заданий, или нас устроит простейшие методы типа “первый попавшийся”? Думается, это во многом зависит от вопроса N1, а именно, на какую нагрузку мы рассчитываем.

3. С чем именно работает система?

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

4. Какие типы приложений тестируем?

Вроде бы ясно, что не нужно ограничиваться только тестированием Java-приложений, но неясно, хотим ли мы видеть в релизе уже первой версии какие-то другие типы тестов, кроме явовских, или же это остается как долгосрочный план работ?

5. Вопросы о требованиях безопасности.

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

В настоящий момент в прототипе системы используется не шифруемое соединение клиента с сервером по протоколу HTTP, данные, передаваемые клиенту содержат ЭЦП. 

Какие требования по безопасности предъявляются к нашей системе?

•Стоит ли использовать SSL при авторизации клиентов?
•Нужна ли цифровая подпись данных?
•Какими правами должны обладать участники, программисты, администраторы системы? Первоначальный список прав таков (один пользователь может совмещать роли):

Участники
- Исполнение заданий с разрешения
   администратора
- Доступ к главной странице web-интерфейса
   (возможность зарегистрироваться участником)
- Просмотр некоторой статистики.

	Программисты:
- То же, что и участники
+ Добавлять задания
+ Смотреть результаты исполнения своих заданий.

	Администраторы:
- То же, что и участники
+ Наделение участников дополнительными полномочиями (делать из них программистов и/или администраторов)
+ Разрешать/запрещать участие пользователей (в т.ч. по IP-адресам в сети)

Подразумевается ли использовать какие-то меры  защиты полученного рабочего модуля (кода, который тестируется) от доступа со стороны участника?

6. Вопрос по развертыванию.

В какой среде предполагается развертывать клиенты и главное серверные компоненты? Интересует, по крайней мере, возможный список ОС, Баз данных, которые могут/должны поддерживаться. 

Итого

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