Ричард Хэмминг: Глава 28. Системная Инженерия

Первое правило системной инженерии: «Если оптимизировать компоненты, то, вероятнее всего, производительность системы будет испорчена.»

Помните офигенную статью «Вы и ваша работа» (+219, 2146 в закладки, 339k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

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

Мы уже перевели 4 главы.

Глава 28. Системная Инженерия

(За перевод спасибо Юлии Перуновской, которая откликнулась на мой призыв в «предыдущей главе».) Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

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

Если бы в обычном кампусе вы решили опросить некоторую выборку профессоров о том, что они собираются делать в следующий академический час, то услышали бы, что они будут: «преподавать наипростейшие дроби», «показывать, как найти момент нормального распределения», «объяснять модуль упругости и его измерение» и т.д. Я сомневаюсь, что вы бы часто слышали от профессора фразу «Я собираюсь обучить студентов и подготовить их к будущей карьере».

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

Чтобы взобраться на вершину, вам нужно иметь более широкое видение — по крайней мере, когда вы уже будете там. Системная инженерия — это попытка всегда держать основные цели в голове и понимать, для чего совершается каждое локальное действие, и как оно влияет на общий результат. Тем не менее, здесь нет какой-то одной конкретной большой картинки. Например, когда у меня впервые появился свой собственный компьютер, я предполагал, что основная цель — это ежедневно использовать его для максимально большого количества арифметических операций. Прошло чуть больше времени до того как я понял, что главная идея — это важность расчетов, а не объемы вычисляемой информации. Позже я осознал, что наиболее важные расчеты совершались не для Математического отделения, на котором я находился, а для исследовательского подразделения. Естественно, я очень скоро понял, что наибольшую ценность от новых машин могут извлечь только сами ученые при работе напрямую. Тогда бы они смогли понять всю ценность компьютеров, которую можно использовать в их работе, уменьшив фактическое количество расчетов, но, при этом увеличив их ценность для Телефонных Лабораторий Белла (Bell Telephone Laboratories). Тем не менее, позже я понял, что мне стоит обращать внимание не только на нужды Исследовательского Отдела, но и на все потребности Лабораторий. Потом это был AT&T, Страна за пределами AT&T, научные сообщества и сообщества инженеров, и, в итоге, весь мир. Таким образом, у меня появились обязательства перед самим собой, моим отделом, подразделением, компанией, родительской компанией, страной, миром ученых и инженеров и каждым жителем планеты. Не было каких-то четко очерченных границ, я в любой момент мог их нарисовать сам и игнорировать все, что не попало внутрь.

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

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

Первое правило системной инженерии

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

Это очень сложный для понимания момент. Обычно кажется очень разумным, что вся система улучшится, если улучшить отдельный её компонент, но это неверно. Более вероятно, что производительность системы ухудшится. Как простой пример, я работал с дифференциальным анализатором и так преуспевал в решении важных проблем, что появилась необходимость приобрести еще два анализатора. Мы заказали второй с целью подключить его к текущему, чтобы они могли производить вычисления либо отдельно друг от друга, либо совместно. Они построили вторую модель и захотели улучшить ее, на что я согласился, но с условием, что это никак не помешает работе всей машины. Наступил день проверки перед демонтажем и перевозкой машины в наше место. Я начал тестировать её, мне неохотно помогал мой друг, который утверждал, что я просто теряю время. Машина провалила первый же тест! Тест был классическим решением дифференциального уравнения.

Решением которого, конечно, является y=cost. Затем вы рисуете графики y(t) и y?(t), и у вас должен получиться круг. Мерой точности является то, насколько хорошо он замыкает себя, цикл за циклом.

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

Вы, вероятнее всего, всё еще не верите в это правило, поэтому позвольте применить его к вам. Большинство из вас при подготовке к сдаче экзамена перечитывают и заучивают материал в самый последний момент в конце семестра, что по большей части абсолютно не продуктивно по отношению к самому образованию, которое вы хотите получить. Вы воспринимаете свою проблему, как необходимость успешно сдавать экзамены по каждому курсу в отдельности, успешно закрывая каждый семестр в отдельности, в то время как на самом деле вы понимаете, что важно именно то, что сложится из ваших знаний в конце обучения, а не на каждом из его этапов. В течение двух моих последних лет обучения в бакалавриате Чикагского Университета существовали правила, по которым нужно было сдавать один экзамен, основанный на 9 курсах основной специализации, и еще один, основанный на 6 курсах дополнительной специализации. И именно этот результат был важен, а не те оценки, которые студенты получали в течение всего обучения. В тот момент я впервые понял, что такое системный подход в образовании. Когда выбираешь конкретный курс, важно не то, на какую оценку я сдам экзамен или как порадую профессора своими знаниями, а то, что я выучу и пойму предмет так, что даже через некоторое время, например, через два года, я все еще смогу применить знания, полученные на этом курсе.

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

В качестве еще одного примера влияния оптимизации компонентов системы, рассмотрим преподавание математических курсов в колледже. На протяжении многих лет мы оптимизировали курсы по Математическому анализу и Линейной алгебре, и убрали все, что напрямую не связано с каждым из этих курсов. В итоге, если смотреть в целом, в обучении Математике появились большие пробелы. Мы практически не затрагиваем (1) важный метод Математической индукции, (2) после краткого упоминания в связи с квадратичными уравнениями в алгебре мы практически полностью игнорируем любое упоминание комплексных чисел до того рокового дня, когда появляются сложные собственные значения и собственные функции, и бедный студент знакомится с двумя новыми сложными концепциями одновременно и, естественно, это сбивает его с толку, (3) вкратце упоминается полезный метод неопределенных коэффициентов, (4) практически полностью игнорируются доказательства невозможности, (5) игнорируется дискретная математика, (6) не прилагаются усилия к тому, чтобы вывести размышления студентов из обучающих примеров к значимым концепциям, применимым в реальном мире. Так можно продолжать и дальше, больш?е части хорошего математического образования опущены в результате стремления оптимизировать индивидуальные курсы. Обычно внутренняя структура Математического анализа и центральная роль пределов представляется как несущественная.

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

Системный подход в обучении не расцветает, лишь энтузиасты разных точек зрения пытаются сами слепить вещи, которые бы хорошо подходили к местным инициативам. В большинстве ситуаций вопрос «Какова общая проблема, в которую входит вот эта часть?» рассматривается как слишком обширный и, следовательно, субоптимизация курсов продолжается. Мало кто среди людей, планирующих реформы в любой системе, сначала пробуют понять основную проблему всей системы, они сразу атакую самый первый симптом, который удалось обнаружить. В итоге, то, за что первым зацепляется глаз, не важно, что это, — это не то, что нужно системе.

Недавно я попытался задуматься об истории системной инженерии. И то, что система была спроектирована, совсем не значит, что проектировщик держал в уме именно саму систему, а не ее отдельные компоненты. Самая ранняя система, о которой я читал в подробностях — это венецианский арсенал в период его рассвета около 1200-1400. У них была производственная линия, и к моменту, когда корабль сходил с линии, веревки, мачты, паруса и даже обученная команда были на своих местах и корабль сразу же отплывал! Через регулярные интервалы времени новый корабль выходил из арсенала. Это ранний пример производства типа «вовремя», включая людей, которые были должным образом подготовлены к моменту производства оборудования.

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

Я подозреваю, что именно телефонная компания первой столкнулась с проблемой системной инженерии. Чтобы предоставить соответствующий сервис, все части должны быть взаимосвязаны, и обеспечивать высокую надежность. С начала работы компания предоставляла не только оборудование, но и сервис. Это большая разница. Если вы просто создаете что-то, и потом оставляете это в пользование другим людям — это одно, но если вы собираетесь в том числе поддерживать это как сервис, то это совсем другое! Многие явно сталкивались с небольшими системами и до этого, но телефонная система была более большой и сложной, чем что-либо до её возникновения. Они также обнаружили, возможно, впервые, что в расширении нет экономии масштаба. Это, наоборот, влечет за собой убытки. Каждого нового клиента нужно было соединить с другими уже существующими, поэтому на каждого нового клиента расходы были выше, чем на предыдущего. Соответственно, система должна быть хорошо продумана.

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

Управляемые ракетные системы проекта Nike, компьютерные системы, над которыми я работал, и множество других аспектов работы в Телефонных Лабораториях Белла научили меня системной инженерии — при чем не абстрактно, а ежедневными примерами тех идиотов, которые не понимали целое как целое и видели только его компоненты. Я уже заметил, что не сразу понял как работает системный подход, так как я работал с компьютерами, но тем не менее я понемногу осознавал, что компьютеры были построены как часть организации, занимавшейся развитием исследований, безусловно очень важной. Но именно ценность компьютеров в этой системе была важна в долгосрочной перспективе: насколько хорошо машины помогали достичь целей организации и общества, а не просто облегчить работу персоналу, который ими пользовался.

Тут нужно вспомнить еще один момент, который сейчас четко прослеживается в создании программного обеспечения и оборудования и раскрывает новую проблему дизайна системы. Все так быстро меняется, что система будет постоянно обновляться, и сложно понять изначально, какие изменения вообще могут произойти в дальнейшем. Гибкость должна быть частью современного дизайна вещей и процессов. Гибкость в проектировании дает не только возможность лучше справляться с изменениями, которые неизбежно возникнут после установки системы, но также вносит вклад в вашу собственную работу в виде небольших изменений, которые неизбежно возникают как на более поздних этапах проектирования, так и во время полевых испытаний системы. Я не понимал, насколько много может быть изменений в ходе испытаний, до того как принял участие в полевом тесте проекта Nike на островах Кваджалейн. Мы устанавливали оборудование, и параллельно процессу шел постоянный поток изменений, вносимых в установку!

Второе правило

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

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

Третье правило

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

Истина этого правила очевидна при построении моста с определенной нагрузкой. Чем ближе соответствие к предписанной нагрузке, тем быстрее мост обрушится, когда лимит будет превышен. То же самое можно увидеть и в центральном офисе телефонной компании. Если вы спроектируете систему под максимальную нагрузку, то даже при небольшом превышении трафика работа всей системы сразу же ухудшается. Следовательно, хороший дизайн проекта постепенно снижает производительность при превышении установленных спецификаций.
Во время подготовки к написанию этой главы, я еще раз перечитал комплект неопубликованных эссе: «One Man’s Systems Engineering» Г.Р. Вестермана (1975), тогда еще работавшего в Телефонных Лабораториях Белла. Эти эссе — единственная глубоко философская дискуссия на тему «что, как и почему» в системной инженерии. Я буду немного отходить в определенных моментах от слов автора, но в целом я согласен с его тезисами. Я могу только подытожить, о чем он рассуждает в своих эссе, под названиями:

1. One Man’s Systems Engineering. / Системная Инженерия одного человека
2. What is Systems Engineering? / Что такое Системная Инженерия?
3. On the Objective. / О цели
4. What Does a Systems Engineer Do? / Что делает системный инженер?
5. The Framework of Systems Engineering. / Структура Системной Инженерии
6. Organization and Systems Engineering. / Организация и Системная Инженерия
7. Objectives and Policy Makers. / Цели и лица, определяющие политику
8. On the Methodology of Systems Engineering. / О методологии в Системной Инженерии
9. Evaluation and (Un)Common Sense. / Оценка и здравый смысл/необычные подходы
10. Envoy. / Посланник

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

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

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

Мы оба согласны с тем, что процесс системной инженерии никогда не заканчивается. Одна из причин заключается в том, что решение проблемы меняет саму среду и создает новые задачи, которые нужно решить. Например, когда я только начал руководить компьютерным центром, я верил, что маленькие задачи были относительно более важными, чем большие. Хотелось предоставлять постоянный и надежный сервис. Поэтому я установил по одному часу в утреннее и обеденное время, в течение которых допускалось запустить только 3-х (или менее) минутные задачи (в основном — программное тестирование) и, если задача выполнялась дольше 5-ти минут, нужно было её останавливать. Даже если задача уже была почти завершена. В итоге люди с 10-ти минутными проблемами разбивали их на три небольших кусочка, распределяя их по другим сотрудникам, и проводили их в рамках установленных мной правил. Тем самым они увеличивали нагрузку на системы ввода/вывода данных. Наличие моего решения поменяло реакцию системы. Оптимальная стратегия одного сотрудника явно противоречила оптимальной стратегии всей лаборатории. Одна из функций системного инженера — останавливать б?льшую часть локальной оптимизации отдельных лиц и достигать глобальной оптимизации всей системы.

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

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

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

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

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

Вестерман полагает, что, по-видимому, искусство системной инженерии лучше изучать в команде, включающей как старые, так и новые лица. При этом он говорит о том, что более опытных коллег стоит постепенно убирать из процесса и вводить новых людей в команду. Я не знаю, как передать мой личный опыт «одинокого волка». Я могу только рассказать о том, что делал и как себя вел в определенных ситуациях. Обычно фактические обстоятельства оказываются настолько сложными, что требуется очень много времени, чтобы преодолеть факторы внешней политики, организационные привычки, личные качества команды, которая будет запускать финальную систему, условия работы в поле, традиции и др. Все эти факторы оказывают сильное влияние на решение проблемы системы. Как правило, решение становится больш?м компромиссом между противоречивыми целями и редким пониманием важности неосязаемых частей границы, которая формирует структуру ответа, со стороны студента. Таким образом, реальные проблемы системной инженерии практически невозможно проявить четко и в деталях. Вместо этого, стоит использовать обучающие ситуации и рассказы, которые, хоть и упрощают некоторые детали, не слишком искажают общую картину. Если вы еще раз вернетесь к предыдущим главам, вы найдете много примеров — во многом упрощенные истории о ситуациях системной инженерии. Я полагаю, что я убежденный системный инженер и неизбежно буду всегда склоняться именно в этом направлении. Но позвольте уточнить еще раз. Системная инженерия должна строиться на прочной основе классического упрощения до конкретных проблем с определенным решением. Я сомневаюсь, что этому можно научить ab initio.

Я видел очень много предложенных решений, которые корректно решали неправильную проблему. В определенном смысле системная инженерия пытается решать правильные проблемы, но, возможно, немного неправильным путем. Тем не менее, в своей реализации решение является временным, и во время следующих итераций проектирования совершенные ошибки будут выявлены, повышая общее понимание системы. Я уже упоминал об этом, но позвольте заметить еще раз: решение, которое не дает более глубокого понимания — плохое решение, но, возможно, что это всё, что возможно сделать в текущем временном ограничении. Целью системной инженерии должно быть более глубокое и долгосрочное понимание сущности проблемы, в то время как клиент всегда хочет увидеть оперативное избавление от текущих симптомов. Опять же, конфликт, ведущий к мета-системной инженерии!

Как пример углубленного понимания системы и её проблем, я хочу рассмотреть проект управляемых ракет Nike. Сначала целью было построить ракету, которая бы сбивала единичную цель. После того как мы выполнили эту цель, мы начали думать над батареей ракет Nike и как координировать каждую из ракет под атакой авиационного флота врага. Потом пришел день, когда мы начали размышлять о том, какие цели и города защищать, а какие нет. Мы стали понимать, что все цели должны одинаково дорого обходиться врагу, не должно быть целей, которые были бы менее или более защищены, чем другие. Каждая цель должна была быть защищена прямо пропорционально тому, какой урон, мог бы нанести противник, атакуя её. Таким образом, мы стали видеть ракеты Nike как всего лишь устройство, которое заставит противника заплатить за нанесенный им ущерб, при этом мы не оставляли ему «дешевых» целей. Как же этот взгляд отличается от того, с которого мы начали разработку! Это хорошая иллюстрация того, что каждое решение должно привносить развитие понимания проблемы. Те первые симптомы, на которые вам укажут, быстро исчезнут из поля зрения, как только вы преуспеете в этом. Цель будет постоянно меняться по мере того, как вы и ваш клиент будете углубляться в понимании.

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

Продолжение следует...

Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

Содержание книги и переведенные главы

1. Intro to The Art of Doing Science and Engineering: Learning to Learn (March 28, 1995) (в работе)
2. «Foundations of the Digital (Discrete) Revolution» (March 30, 1995) Глава 2. Основы цифровой (дискретной) революции
3. «History of Computers — Hardware» (March 31, 1995) (в работе)
4. «History of Computers — Software» (April 4, 1995) (в работе)
5. «History of Computers — Applications» (April 6, 1995) (в работе)
6. «Artificial Intelligence — Part I» (April 7, 1995) (в работе)
7. «Artificial Intelligence — Part II» (April 11, 1995) (в работе)
8. «Artificial Intelligence III» (April 13, 1995) (в работе)
9. «n-Dimensional Space» (April 14, 1995) (в работе)
10. «Coding Theory — The Representation of Information, Part I» (April 18, 1995) (в работе)
11. «Coding Theory — The Representation of Information, Part II» (April 20, 1995)
12. «Error-Correcting Codes» (April 21, 1995) (в работе)
13. «Information Theory» (April 25, 1995) (в работе)
14. «Digital Filters, Part I» (April 27, 1995)
15. «Digital Filters, Part II» (April 28, 1995)
16. «Digital Filters, Part III» (May 2, 1995)
17. «Digital Filters, Part IV» (May 4, 1995)
18. «Simulation, Part I» (May 5, 1995) (в работе)
19. «Simulation, Part II» (May 9, 1995)
20. «Simulation, Part III» (May 11, 1995)
21. «Fiber Optics» (May 12, 1995)
22. «Computer Aided Instruction» (May 16, 1995) (в работе)
23. «Mathematics» (May 18, 1995) (в работе)
24. «Quantum Mechanics» (May 19, 1995) Глава 24. Квантовая механика
25. «Creativity» (May 23, 1995). Перевод: Глава 25. Креативность
26. «Experts» (May 25, 1995) (в работе)
27. «Unreliable Data» (May 26, 1995)
28. «Systems Engineering» (May 30, 1995) Глава 28. Системная Инженерия
29. «You Get What You Measure» (June 1, 1995) (в работе)
30. «How Do We Know What We Know» (June 2, 1995)
31. Hamming, «You and Your Research» (June 6, 1995). Перевод: Вы и ваша работа

Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru