Тут можно просто использовать кофе перед совещанием (повышает количество выдаваемых идей на 30%
2 Ұнайды
В итоге было признано:
• Важны не требования, а непрерывно уточняющиеся поведенческие модели (модели изменения состояний в ходе функционирования), то есть сценарии использования. Эти модели отражают непрерывно меняющийся набор гипотез о том, что должна делать успешная система. Поскольку вопрос об успешности системы (успешности подсистемы, и т. д. по уровням), то в этих моделях должны учитываться и внешние проектные роли (а внутренние проектные роли вполне могут быть внешними проектными ролями для подпроектов: разработчик самолёта будет внешней проектной ролью по отношению к разработчику авиадвигателя).
1 Ұнайды
Концепция системы – это описание основной идеи модульного синтеза: каким образом какой-то набор конструктивных частей целевой системы исполняет роли функциональных частей системы, чтобы в конечном итоге выдать требуемый от системы сервис на уровень надсистемы. Архитектура системы при этом накладывает на концепцию системы ограничения: говорит о такой разбивке на модули, которые дают необходимые архитектурные характеристики: высокую скорость развития/evolvability для времени создания системы, возможность масштабирования как увеличения производительности по мере роста потребности в сервисе системы, собственно самой производительности системы, и т. д.
1 Ұнайды
Один из студентов-бакалавров предыдущей версии курса на вопрос, что ему пригодилось больше всего из материала, сказал: «я понял из курса, что есть проверка и приёмка. И я начал проверять всё, что выходит из моих рук перед тем, как отдавать работу. И моя жизнь драматически изменилась к лучшему». Не ленитесь делать инженерные обоснования с самого начала до самого конца проекта, и ваша жизнь тоже драматически изменится к лучшему! Но будьте готовы, что на это уйдёт половина вашего времени, а то и больше!
маленький беспорядок может нанести существенный убыток в большом проекте
Начинать управление конфигурацией нужно с себя:
• Не пишешь — не думаешь. Управление конфигурацией собственных идей. Мышление письмом, на память надежды нет. Все ходы записываются, как в шахматных партиях: или конфигурацию шахматной партии держит доска, которая не может быть забыта или неправильно вспомнена, или запись шахматной партии (что много удобней: её можно переслать через чат, а физическую шахматную доску не перешлёшь). Собранность у человека поддерживается инструментально, голым мозгом не работают, биологической памяти не верим, она сбоит!
• Всё, что кому-то передаётся (hand-over, release), должно оставлять след во внешней по отношению к мозгу памяти, а не только запоминаться головой. Например, должны храниться входящие и исходящие письма, полуфабрикаты и готовые рабочие продукты. Если было не письмо, а разговор, то должен остаться след: minutes/заметки по содержанию разговора, issue в issue tracker, хоть что-нибудь. Над этим всем должен работать компьютерный поиск, чтобы не искать перебором или «я это оставлял где-то вот тут, но где это лежит сейчас, почему не видно?». Если это материальные рабочие продукты, то работаем со складским учётом: ищем по карточкам, быстро находим.
• Все предстоящие дела (работы, а не только рабочие продукты) записываются, на память надежды нет. Используются разные системы ведения дел по мотивам старинного «Getting things done»[4] или «Джедайских техник»[5].
• Все рабочие продукты имеют версии, для которых должно быть уникальное имя и время последнего изменения, а также кто что изменял. Нужно, чтобы можно было сравнить «что было» и «что стало» после изменения. Прошлые версии документов сохраняются «на всякий случай» (бэкап).
Всё то же самое нужно делать в масштабах всего проекта, какой бы большой он ни был (и чем больше проект, тем строже это отслеживать: маленький беспорядок может нанести существенный убыток в большом проекте).
Инженерия — это практика изменения физического мира к лучшему
Качество продукта обеспечивается быстрым внесением изменений, непрерывным улучшением, а не дословным выполнением стремительно устаревающих инструкций. Иногда эту практику совмещают с практикой compliance (проверка соответствия), но часто compliance выводится из практики управления жизненным циклом.
А эволюционный алгоритм принципиально может.
нейросеть обычно не может сгенерировать оптимизацию, которая выходит за рамки тех примеров, которые ей показывали в ходе обучения.