> как правило разработчики придерживаются некоего баланса памяти и количества выводов
Да вот прям нифига. Количества памяти больше на многогерцовых числодробилках, а выводов - на том, что скорее будет использоваться как шлюз от умного центра к сети тупых датчиков. И его единственная задача - собрать данные в кучку и протолкнуть в центр. (ну или распихать управляющие команды, посчитанные по сложной и большой программе по исполнителям.
АФАИР:
Соц налоги не совсем помимо 6% - если ты ИП без сотрудников, то налог (6%) можешь уменьшать на сумму соц налогов.
То есть, пока 6% меньше соцстраха - платишь только соцстрах, как больше - платишь 6% (фактически соц налоги и (6%-соц налоги))
Эдуард Тибет: Эдуард, насколько я понимаю путь 2 это не совсем то. Если только не считать АЗ, ТЗ и инструкцию одним документом, написанным на разных языках. Вроде при этом подходе мы пишем один раз и по разному отображаем на разные выходные форматы. А тут текст будет сильно разным - в разных документах мы скорее не копируем куски разными словами, а ссылаемся вверх по иерархии, обосновывая решение. В итоге связь между кусками документов не один к одному, а скорее многие ко многим.
По первому пункту погряз в перекрестных ссылках, а IBM кажется бесплатно не пощупать.
Боюсь, что у нас разные области применения софта. У вас похоже важен внешний вид/удобство использования, у меня - связность движений в базе. В итоге фаза прототипа остается на уровне экселя, а не кода. До удобства оператора дело может и не дойти. А вот когда через пару лет возникает вопрос, а "зачем мы делаем такие движения", то прочитать это из АЗ проще, чем из инструкции, ТЗ и тем более кода. Так как АЗ не обременено деталями реализации и именами таблиц БД, зато там есть ссылки на законодательство. И если документ по ссылке устарел, то пора менять реализацию. А если нет, то надо понять - у нас ошибка в реализации, или пользователь со стороны заказчика хочет странного и его надо слать к методологам.
Близко, налаживаем 1С в крупной конторе, которая работает с госзаказчиком.
Но в ситуации скорее наложились проблемы при разработке (самая актуальная "документация" это почта, потом код, потом инструкции пользователей, а документы верхнего уровня отражают видение на 3 года назад) с курсом Introduction to Systems Engineering на курсере, где много говорится про важность отслеживания требований в обе стороны, но (по крайней мере пока) ничего про инструменты.
Контрольный пример в моем случае (КП) это ручные приемочные тесты для крупной фичи (документ ворд с картинками). Автор КП - разработчик со скриншотами описывает типовую операцию от начала до конца (как правило цепочка из 5-7 документов + отчет с результатами). Используются заказчиком двояко - как приемочный тест при сдаче работы и как инструкция "в картинках" для операторов, которым сложно разбираться с пользовательской документацией.
Так же. Плясать от структур, а не поля. Ну или анализировать на предмет удачности идеи установки клетки в радиусе двух длинн выигрышной комбинации от существующих помеченных полей и границ поля. Реально все правильные ходы будут расположены ближе. Грубо говоря, считаем для каждой клетки вектор, за сколько ходов мы сможем выиграть партию при постановке крестика в нее для каждого направления. И за сколько ходов это направление может быть заблокировано. а дальше стараемся построить выигрышную комбинацию (типа 1 ход до победы, два хода на блокирование, 3 раза по 2 хода до победы, и тд)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Да вот прям нифига. Количества памяти больше на многогерцовых числодробилках, а выводов - на том, что скорее будет использоваться как шлюз от умного центра к сети тупых датчиков. И его единственная задача - собрать данные в кучку и протолкнуть в центр. (ну или распихать управляющие команды, посчитанные по сложной и большой программе по исполнителям.