Техническое описание парадигмы онлайн-проектов (в рамках Народного проекта)

30 октября 2019

Это вторая тема "Народного проекта" по созданию онлайн войны силами игроков, на бескорыстной и добровольной основе.

В ней есть описание проекта и технических требований.

Вступление:

Spoiler

Хочу сразу сказать посетителям темы, что эта информация специфичная. Тема находится в Разделе "Выделенные сервера", но при этом это не описание работающего сервера, и не тема где выложен софт или руководства. Это информация для людей интересующихся информацией по созданию онлайн проекта, кого интересует сотрудничество и взаимопомощь, что хотят помочь в создании такого проекта, или получить помощь. Сам сервер "Народного проекта", где можно поиграть, будет создан еще не скоро, пока только идет разработка, причем еще только начальная фаза разработки. Сейчас только созданы нужные условия для работы будущего коллектива, было сделано объявлении о старте Народного проекта, была проведена работа по изучению и выбору методов разработки с учетом того, что проект создается только силами энтузиастов без финансирования и без найма специалистов, поэтому на данный момент у онлайн проекта есть только начальные техническое описание и технические требования. Не нужно думать что этого мало. Создание этих ТТ для проекта это сложный труд, требующий определенных знаний и времени. Я надеюсь, что начав с этого, шаг за шагом проект будет доделан до действительно качественной онлайн-войны, причем которую сможет установить на своем сервере каждый игрок по ридми, без знания программирования. Для создания такого проекта нужно конечно знать что делать, а не просто двигать туда-сюда домики в редакторе игры. Я играю в Ил-2 с 2001г. и знаю почти всё о проходивших онлайн войнах. Но при этом мне нужно чтобы единомышленники тоже узнали эту информацию, для этого проект должен быть оформлен в виде технического описания, с которыми могут ознакомиться другие заинтересованные участники Народного проекта.

Т3:

Spoiler

Для начала я объясню почему нет Технического Задания, которое мог бы взять какой-то программист и быстренько мне сделать проект.

Т3 подразумевает заказчика и исполнителя.
Т3 пишется исполнителем, в противовес на согласованные требования.
Т3 пишется с участием специалиста.

Вы можете увидеть, что Заказы на сайтах фриланса выглядят так:

Заказчик. Мне нужна утилита с такими-то свойствами.

Исполнитель. Готов помочь. Большой опыт данных делах. Если заинтересует, то отпишите в л.с. обсудим детально.

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

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

Но честно говоря, я больше рассчитываю на силы таких же энтузиастов непрофессионалов как и я, чем на то, что появится профи и всё быстро сделает. А энтузиастам предстоит еще организовать свою работу, самообучаться, как-то пытаться что-то сделать своими силами, и Т3 для работы специалистов будет только мешать. А вот описание и требования к проекту при совместной работе нужно обязательно. Таким образом "Народный проект" будет лишен проблем, возникающих перед создателями проектов, что без опыта и знаний видят только то, что им предлагает игра, и начинают двигать домики в редакторе, иногда делая простые скрипты в блокноте. И так как это тоже требует времени, и энтузиазм заканчивается, то разработка стопорится и больше никому кроме автора не нужна. Иногда кажется что это работает, так как игроки что смотрят на такую работу, тоже видят только карту в игре и думают, что так и должны делаться онлайн проекты, средствами самой игры, только тем что двигаются домики на этой карте. Но мы ведь говорим о настоящей войне, например чтобы цикл движения фронта был хотя бы несколько месяцев. Честно говоря я был удивлен, что в БзС до сих пор делают онлайн проекты в блокноте по гуглю. Поэтому я занялся собственной разработкой с применением стандартов настоящего качества Мировой Онлайн войны, чтобы сделать наконец все как нужно. Теперь о том как нужно делать онлайн проект, каждый сможет увидеть из ТТ.

Базовые ТТ "Народного проекта".

Spoiler

Для начала определимся что такое ТТ. Технические Требования появляются в результате видения заказчика и потребителя основных свойств проекта. Я на данный момент являюсь Потребителем, потому что интересуюсь игрой в онлайн проекты Ил-2 с 2001г. (например я знаю о проектах Clon War, Forgotten War, Chesh War, Virtual World War, Ilyushin Online War, Virtual Easten Front, Bellum, Pandora) и поэтому могу знать, что было интересно этим игрокам за эти 18 лет, почему они играли, как играли, во что играли, и как не печально, почему и чем эта игра закончилась. Одновременно я являюсь Заказчиком и могу высказать видение того, что может быть интересно игрокам в целом, без учета форс-мажорных обстоятельств, когда разработчики онлайн проектов делают только "авторское видение", но не то что нужно игрокам или бросают работу. Поэтом ТТ должны быть такими:

Создание софта, набора утилит, скриптов для стороннего (не только средствами игры) управления выделенными серверами БзС через игровую консоль, создания миссий для проекта, создание СУБД для этого софта, создание стороннего интерфейса на сайте для отображения информации о проекте.
Этот софт в итоге должен быть создан в таком виде, чтобы пользователь с базовыми знаниями о пользовании компьютером, мог установить и настроить его самостоятельно по ридми, без специальных знаний о программировании и т.д. Это нужно для того, чтобы любой из игроков, мог создавать простым способом разные сервера в зависимости от своих предпочтений в игре.
Этот софт должен разрабатываться с учетом того, что он будет разрабатываться разными людьми с разной квалификацией и знаниями о программировании и эти люди могут бросать работу, и к этой же работе могут подключаться новые люди. Это нужно для того, чтобы если один человек бросил работу над своей частью проекта, то его работу мог закончить новый.
Иметь возможность модификации для добавления новых функций.
Иметь возможность использоваться на следующем поколении Ил-2, через 10-20-30 лет и т.д. Т.е. поменять может только формат миссий и логов, это значит что в самом онлайн проекте достаточно поменять принцип чтения этих логов парсером и привязать работу коммандера к соотвествующему генератору.
Учитывать особенности клиента игры как боевого авиасимулятора, а именно где воспроизводится процесс применения авиационной техники Второй Мировой войны и сопутствующее окружение.

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

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

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

Вместо Т3 в "Народном проекте" для воплощения ТТ силами энтузиастов, применяется гибкая методология разработки, а именно OpenUp.

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

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

Что дает нам OpenUP?

Spoiler

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

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

Философия гибкой разработки: OpenUP удовлетворяет принципам Manifesto for Agile Software Development (Манифеста гибкой (agile) разработки программного обеспечения).

Расширяемость: Это значит, что можно будет начать с облегченного процесса с открытым исходным кодом и по мере необходимости добавлять необходимые материалы, что позволит создавать различные варианты RUP и других процессов.

Микрошаги: В XP есть понятие baby-step (детских шажков). В Scrum работа осуществляется аналогичным образом через очередность итераций.

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

Жизненный цикл итерации:

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

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

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

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

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

Для самоорганизации необходимо, чтобы выполнялись следующие условия:

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

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

Микрошаги

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

Разработка промежуточных вариантов решения: В идеале рекомендуется использовать при разработке промежуточных вариантов решения принципы разработки с учетом результатов тестирования (Test-Driven Development).

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

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

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

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

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

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

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

Жизненный цикл проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы не расписывать заново из чего может состоять проект и как он может действовать, я скопировал информацию с сайта ADW - Air Domination War в качестве примера.

Spoiler

Правила ADW

редакция КС от 01.08.2006

1. Введение.

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

2. Силы в ADW.

2.1. Передвижение сил по карте.

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

2.2. Точки снабжения.

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

2.3. Ударные силы и силы обороны.

Основной ударной силой являются танковые группировки. Одна такая группировка состоит из танковой колонны, колонны снабжения и топливной колонны, которые идут на некотором удалении от танковой колонны. В штатной ситуации вышеперечисленные колонны идут друг за другом. Для взятия городов будет необходима гаубичная артиллерия, которая будет выдвинута из точки снабжения, после того как танковая колонна достигнет какого-либо населённого пункта/города. Основой обороны будут позиции ПТА, которые разворачиваются в случае потери танков из сил колонны снабжения.

2.4. Аэродромы.

Существует три вида аэродромов в зависимости от их размера. Соответственно, на них будет находиться различное количество запасов топлива и боеприпасов.

2.5. Авиация.

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

3. Наземные силы. Виды действий, цели и задачи в зависимости от сложившейся ситуации.

3.1. Танковая колонна в наступлении.

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

Для успешного продвижения колонны в наступлении вам необходимо осуществлять её прикрытие с воздуха, т.к. колонна не сможет долго двигаться без колонн снабжения и топлива.

3.2. Захват городов или населённых пунктов.

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

Для успешного захвата города или населённого пункта необходимо наличие гаубичной артиллерии не далее чем в 20-ти километрах от города, наличие колонны снабжения и некоторого количества танков. Иначе захват не сможет быть осуществлён.

3.3. Оборона.

Если во время наступления, при столкновении наступающих танков с танками противника, силы которых были выше и наступающие танки были уничтожены, то на месте уничтоженных танков будут развернуты позиции ПТА.

Для успешной обороны обязательно наличие колонны снабжения, в противном случае ПТА развернута не будет и танки противника продвинутся вперед.

4. Восполнение потерь наземных сил.

После того как были уничтожены какие-либо силы на земле, в размере более 25% от колонны или какой-либо группы, из точки снабжения будет выдвинута колонна соответствующего типа для пополнения потерь.

5. Аэродромы. Потери и пополнение.

5.1. Захват аэродрома.

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

5.2. Ресурсы аэродрома.

Так же на каждом аэродроме находятся склад топлива, склад боеприпасов и склад ремкомплектов. Причём размер и вместимость этих складов зависит от размера аэродрома.

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

5.3. Средства обороны аэродрома.

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

5.4 Снабжение аэродромов воздушным транспортом.

Существует возможность пополнения потерь на аэродромах при помощи воздушного транспорта. Для этого вам нужно взлететь на транспортном самолете (Не111,ТБ3 или B-25 со стандартной загрузкой вооружением) с ближайшего к железнодорожному узлу аэродрома и произвести посадку на аэродром, требующий пополнения потерь. Если самолет был потерян, то и ресурсы, которые на нём находились, тоже будут считаться потерянными.

Чтобы узнать есть ли возможность миссии снабжения с данного поля, выберите поле и наберите команду < supply .

ПРИМЕЧАНИЕ: Миссию снабжения можно проводить для любого аэродрома, независимо от того, где базируется ваше подразделение.

Для того, чтобы провести миссию снабжения, вы должны:

- после нажатия кнопки «вылет» ( до взлета !) на самолете типа Не111, ТБ-3 или B-25 со стандартным вооружением, ввести в чат одну из команд:

< load fuel (миссия снабжения топливом)
< load ammo (миссия снабжения боеприпасами)
< load repair (миссия снабжения ремкомплектами)

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

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

После посадки в точке назначения, вы должны выгрузить груз путем ввода команды <unload.

6. Авиация. Доступность самолётов на аэродромах.

Доступность типов самолётов будет зависеть:

- от того, какие полки базируются на данном аэродроме;
- от того, какие типы самолётов в наличии у данных полков.

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

Система распределения самолетов.

6.1. Всем полкам, не прошедшим "квалификацию", для выбора линейки будет доступен только резервный тип.

6.2. Набрав определенное количество баллов, т.е. пройдя "квалификацию", (вылеты, сбитые, уничтоженное и т.п.) полк получает право выбрать базовую линейку.

6.3. Для выбора линеек и бомбардировщикам и истребителям нужно набрать 2 балла на каждого пилота (считая из заявленной численности, а не зарегистрированных пилотов. Т.е. если для сквада 4 человеека претендующих на 20 самолетов нужно - 40 баллов, и если сквад на 20 человек претендующих на 20 самолетов тоже нужно - 40 баллов), при этом выполнив условие:
S>N/2 и Q>N*2
где:
N - максимально-возможное количество пилотов в полку.
Q - необходимое количество баллов.
S - количество успешных боевых вылетов(с возвращением домой, должно быть не меньше N/2.

Бальная шкала:
1 балл = 1 сбитый
1 балл = 1 танк
1 балл = 3 машинки, 3 зенитки, 3 статика

6.4. Боевой вылет - вылет продолжительностью более 15 минут и/или уничтожение самолета или техники противника с обязательным условием - пилот должен остаться живой (посадка, аварийная посадка, прыжок над своей территорией, побег из плена). Вылеты, закончившиеся аварией на взлете и вылеты снабжения короче 15 минут как боевой засчитываться не будут.

6.5. Призовые самолеты

а) При достижении полком результатов оценивающихся генератором присвоением лычки "гвардейский полк", появляется возможность выбрать призовые самолеты
б) При достижении каждого нового статуса полка, полку дается право на выбор самолета из призовой линейки на карту. После окончания данной карты, полку возвращается его основной тип, выбранный ранее. Всего возможно будет получить призовой самолет на трех картах.
в) Выбор призового самолета возможен только на карту, которая идет в данный момент. Если на этой карте, полк не выбрал призовой самолет и остался на основном типе, то возможность переносится на следующую карту. И так до тех пор, пока возможность не будет использована, либо не закончится текущая война.
г) После выбора призового самолета, полку будет выданы самолеты только на активных пилотов за прошедшие 2 недели. Остальные самолеты будут состоять из основного типа. Потеря любого самолета будет восполняться по общему принципу, как будто то бы полк летает на основном типе. Призовые самолеты пополняться не будут.
д) Активный пилот - пилот, имеющий в своем активе за указанный промежуток времени (14 суток) Q баллов, удовлетворяющее условию: Q>10
е) У призовых самолетов есть особенность в том, что по условиям генератора этот самолет не должен совпадать с самолетами из основных линеек. Поэтому в призовых самолетах есть "испытательные" типы в ограниченных количествах и массовые типы. К "испытательным" относится техника которая появляется раньше на 1-2 карты чем положено, есть реактивная техника, самолеты использовавшиеся в реале ограниченно и эпизодически и представлена на последних картах авиация союзников.

6.6. Если полк прекратил полеты после выбора линейки, то выбранная им линейка сбрасывается в общую копилку, а полк автоматически переводится на резервный тип. Условием, дающее право считать полк не летающим: Обнуление буде проводиться перед началом каждой нечетной недели (шаг в 2 недели) при этом обязательное условие для полка за прошедший отчетный отрезок времени:

Q>N при S не равно 0
Где:
Q - необходимое количество баллов.
N - максимально-возможное количество пилотов в полку.
S - количество уничтоженной техники и/или самолетов противника

В случае возобновления полетов полку будет предложено заново пройти квалификацию для выбора основной линейки.

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

7. Глобальные ресурсы на карте.

7.1. Ресурсы на операцию.

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

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

7.2. Склады на точках снабжения.

Соответственно, в крупных железнодорожных узлах или морских/речных портах находятся крупные склады топлива, боеприпасов и ремкомплектов. Если в железнодорожном узле/порту, в случае атаки, будут уничтожены склады с ресурсами, то данная точка снабжения не сможет осуществлять пополнение войск до того момента пока на железнодорожный узел данной точки не прибудет ж/д состав снабжения извне, или в порт не прибудет транспортный корабль.

Точки снабжения являются исключительно важными стратегическими объектами и требуют защиты. Так же ж/д составы и транспортные корабли являются основными средствами пополнения точек снабжения и требуют особого к ним внимания.

8. Регистрация для полетов.

Командир подразделения, для начала полетов, должен сначала зарегистрировать подразделение.

Для полетов в ADW , подразделение должно состоять минимум из 4-х пилотов.

По адресу http://www.adwwar.com/reg/index.html в подменю «управление» выберите пункт «новый полк»
Далее, заполните все пункты, которые представлены в меню создания полка. Название полка: - полная расшифровка приставки подразделения, например – 123 Istrebitelniy Avia Polk ;
Приставка: - приставка подразделения, например – 123 IAP , причем, если в вашем полном никнейме, между пристав есть нижнее подчеркивание, то обязательно поставьте его здесь, т.е. пример – 123 IAP _ ;
Сторона: - сторона, за которую будет летать ваше подразделение;
Специализация: - род деятельности подразделения, то есть истребительное или бомбардировочное;
Страница полка: - ссылка на веб страницу подразделения;
Командир, Имя: - никнейм командира подразделения ( без приставки! ), например – Ivan ;
e - mail * : - почтовый адрес командира подразделения;
Заместитель командира, Имя: - никнейм заместителя командира подразделения ( без приставки! ), например – Fedor ;
e - mail *: - почтовый адрес заместителя командира подразделения;
Далее следуют поля для ввода еще двух пилотов подразделения, т.к. условие участия – состав из 4-х человек минимум;
Пилот 3, Имя: - никнейм пилота №3 ( без приставки! ), например – Vasiliy ;
e - mail *: - почтовый адрес пилота №3*;
Пилот 4, Имя: - никнейм пилота №4 ( без приставки! ), например – Dmitriy ;
e - mail *: - почтовый адрес пилота №4*;
Максимальное число пилотов: - максимально возможный размер подразделения. Будьте внимательны при вводе данного числа, т.к. вы не сможете добавить пилотов свыше данного количества!

Старайтесь вводить максимальное число пилотов в подразделении (максимальный размер подразделения) как можно близкое к числу активных пилотов (уже зарегистрированных и летающих в данный момент). Это очень важное число, потому как “пустые” места для пилотов будут сильно осложнять действия вашего подразделения;

Язык по умолчанию: - язык, на котором будут выдаваться сообщения в чате.

* Будьте внимательны и указывайте рабочий e - mail , потому как на него вам будет выслан пароль для администрирования вашего подразделения и пароли для пилотов.

После заполнения полей и нажатия кнопки «зарегистрировать» вы увидите сообщение об успешной регистрации полка. После этого, используя пароль управления полком и полное имя командира или заместителя командира (т.е. вместе с приставкой, пример 123 IAP _ Ivan ), войдите в административную панель «управления полком» и продолжите дальнейшее администрирование полка для полетов:

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

8.2. После выбора списка самолётов вам будет доступна административная страничка подразделения со следующей информацией:

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

8.3. Для того, чтобы начать полёты, вам сперва нужно выбрать аэродром базирования вашего полка. Для этого в разделе "изменение статуса базирования" выберите из, доступного там, списка аэродромов тот, с которого вы хотите летать и нажмите кнопку " перебазировать" . В статусе вашего подразделения будет написано "в процессе перебазирования" до того момента, как произойдет перезагрузка карты (~1 час) и после этого вы сможете летать с данного аэродрома.

8.4. Для перебазирования полка на другой аэродром, выберите из списка доступных аэродромов тот, на который вы хотите перебазироваться и нажмите кнопку "перебазировать" . Процесс перебазирования произойдет после перезагрузки карты.

Статус аэродрома (топливо, боеприпасы, ремкомплекты), на который вы хотите перебазироваться, будет указан в скобках.

8.5. Так же, в разделе "статус снабжения", вам будет доступна информация о количестве потраченных вами ресурсов и ресурсов, которые вы пополнили в процессе миссий по снабжению.

8.6. В разделе "расписание полётов" вы сможете редактировать ростер пилотов.

Для отстранения от полётов какого-либо пилота поставьте галочку напротив его никнейма и нажмите "сохранить изменения". Для добавления дополнительных пилотов нажмите "добавить пилотов" и введите требуемое вам количество пилотов с заполнением требуемых полей.

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

8.8. Звания и распределение их в подразделении зависят от нескольких вещей:

8.8.1. - от количества пилотов в подразделении зависит высшее звание по штату реального аналога подразделения;

Таблица званий подразделения.

Размер подразделения	Количество пилотов		Начальное звание CO	Максимальное звание CO
Размер подразделения	от	до	Начальное звание CO	Максимальное звание CO
Звено	4	8	Лейтенант	Майор
Эскадрилия	8	20	Ст. Лейтенант	Подполковник
Полк	20	60	Майор	Ген. майор
Дивизия	60	80	Полковник	Ген. полковник
Корпус	80	99	Ген. лейтенант	Ген. полковник

Таблица максимально возможных званий и их количества в зависимости от размера подразделения.

Размер подразделения	Количество пилотов		Максимальное количество званий в подразделении
Размер подразделения	от	до	Капитан.	Майор.	П-Пк.	Пк.	Ген. майор .	Ген. лейт.	Ген. Пк .
Звено	4	8	3	1	-	-	-	-	-
Эскадрилия	8	20	5	2	1	-	-	-	-
Полк	20	60	11	4	2	2	1	-	-
Дивизия	60	80	31	12	6	6	3	1	1
Корпус	80	99	41	16	8	8	4	2	1

8.8.2. - максимальное звание пилотов не может быть выше, чем звание командира подразделения, которое присваивается ему по результатам действий всего подразделения (он не имеет права давать звания себе самому), то есть линейка званий в подразделении зависит от коллективных усилий всего подразделения;

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

ВВС	Гвардейский	Краснознаменный	Ордена Ленина
Люфтваффе	Образцовый	Элитный	Экспертный
Повышение в звании командира подразделения к текущему званю	+1	+1	+1

9. Вход на сервер ADW.

В данный момент у нас есть два различных способа авторизации для полетов на сервере, вы можете выбрать любой из них

9.1.Ручной ввод пароля.

Это такая же система, как и на сервере G1:

войдите на сервер с указанным при регистрации позывным;
выберите сторону, за которую Вы зарегистрировались;
в окошке чата введите следующие символы: <logon<pass , где pass – пароль, который вы получили при регистрации пилота;
создайте в чате канал Server и отправьте пароль через этот канал (этот канал не является публичным и ваш пароль никто не увидит):
если Вы не указали пароль или неверно его ввели, то Вам в чате поступит следующее сообщение: Пароль не верен или Пароль Принят
Завершив процедуру ввода пароля Вы можете приступать к полетам.
9.2. Web авторизация

Перед вылетом вам необходимо пройти авторизацию на сайте ADW по адресу http://www.adwwar.com/В нижнем поле пройти авторизацию введя логин и пароль пилота, нажать кнопку войти.

Далее в нижней части вы увидите добавленную систему авторизации по вашему IP адресу. Система автоматически считывает ваш IP поэтому он сразу отображается в верхнем поле. Если все правильно то вам необходимо подтвердить системе этот IP адрес нажатием кнопки OK. После этого IP адрес окажется в красном окне как разрешенный. По умолчанию (из за того что IP не у всех статический) система принимает ваш IP сроком на 1 час. Но вы можете изменить срок действия IP на любое удобное вам время.

ВНИМАНИЕ!! Тем у кого IP динамический необходимо подтверждать IP адрес после каждого рестарта компьютера или отключения-подключения к сети. Это же верно для тех кто для полетов использует разные компьютеры.

PS: напомним еще раз, вы можете выбрать любую из двух систем авторизации, ту которая вам более удобна.

10. Понятие кворума.

10.1. Уничтожение наземной техники и ресурсов влияет на их реальное количество при нахождении пилотов обеих сторон на сервере в соотношении 3 на 3, либо наличие 10 пилотов одной стороны.
10.2. Пилот учитывается для кворума после введения пароля и выбора аэродрома.
10.3. Уничтожение самолетов противника и собственные потери идут в статистику при любом соотношении пилотов.

11. Имитационные самолеты

Bf109 G4 - имитируется Bf109 G6, без мк108
Bf110 C4 - Bf110 G2 без Мк108 и Bk37
Hs123 - Fiat CR42
Hs129 - Bf110 G2 + Bk37
Fw190 A4 (штурмовые модификации) - доступен вариант U3
Fw190 A5 (штурмовые модификации) - доступен вариант U3 или U17
Су2 - SBD-3 без 1600fn
Bf-109G-6_Late_st - Bf-109G-6_Late без мк108
Bf-109G-6AS_st - Bf-109G-6AS без мк108
Bf-109G-6 - Bf-109G-6 с мк108
Bf-109G-2R6 - Bf-109G-2 5-точечный вариант
Do217 - эмуляция G4M1_11
LaGG-3series29st - LaGG-3series29 без ВЯ и РС
Bf110 C4 - эмуляция Bf110 G2

12. Перечень команд серверу.

12.1. Общие команды

<logon<pass - подтверждение входа пилота на сервер

<squad - показывает общие данные сквада, аэродром базирования, состояние ресурсов на нем, количество доступных основных и резервных самолетов

<time - время на сервере и время до конца миссии

<teams - количество и распределение пилотов на сервере по сторонам

<gunstat - процент попаданий

<warn - количество штрафных очков

12.2. Сапплайные команды

<supply - показывает аэродром снабжения, состояние ресурсов на нем, тип доступного транспортного самолета

Загрузка необходимых ресурсов в транспортный самолет:
< load fuel - миссия снабжения топливом
< load ammo - миссия снабжения боеприпасами
< load repair - миссия снабжения ремкомплектами

<unload - выгрузка ресурсов

Чтобы это всё реализовать в БзС в соответствии с ТТ "Народного проекта", онлайн проект изнутри для разработчика и администратора выглядит в такой схеме:

Spoiler

Это элементы, которыми можно манипулировать интерактивным образом в соответствии с некоторыми правилами.

Описание парадигмы онлайн-проекта и назначения каждого элемента.

Игровой клиент БзС, через который игрок подключается к запущенной миссии проекта.
Выделенный сетевой сервер игры, утилита, на котором запускается файл миссий, к которому подключается игрок через клиент.
Файлы лога миссии, в которые записываются действия игроков при игре в миссии.
Парсер - утилита, которая анализирует этот файл логов и выбирает нужную информацию для записи в базу данных, в таком виде значений, чтобы эти значения можно было обрабатывать с помощью других программ.
База данных, в которой хранится информация для работы проекта в удобном виде для дальнейшей обработки и оперированием этой информацией, и к которой могут обращаться другие утилиты.
Движок Войны - набор скриптов, оперирующих значениями из базой данных и создающий новые значения, создающие значения и команды другим утилитам и движку сайта, для изменения информации на сайте. Это может быть отдельная утилита, или эти скрипты могут быть добавлены как система управления базы данных (СУБД).
Сайт на котором выводится статистика игроков, информация из файлов отыгранных миссий, тактическая карта и другая информация выдаваемая Движком Войны.
Панель игрока с собственным интерфейсом, через которую игрок может вносить изменения в базу, созданием уникального пилота, и других значений. Эта панель управления может быть на сайте или в других утилитах.
Сервер Коммандер - утилита дающая команды на консоль управления выделенным сервером после команд от Движка Войны.
Консоль управления выделенным сетевым сервером из игры, дает команды на выделенный сервер.
Коммандер Миссий - утилита работающая с генераторами миссий БзС после команды от Движка Войны.
Генераторы Миссий БзС, создают миссии по команде от Коммандера Миссий, в зависимости от заданных условий.
Файлы миссий, которые запускаются через выделенный сетевой сервер игры.

Это элементы, которыми можно манипулировать интерактивным образом в соответствии с некоторыми правилами.

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