Здравствуйте, Кодёнок, Вы писали:

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

Во-первых, оно и в грамотно спроектированном софте не растет по экспоненте. Во-вторых, в микроэлектронике разработка несколько отличается от софта — там акцент на других сложностях. В-третьих, на активности по верификации там тратится почти столько же времени, как и на разработку. Помимо программирования, я два с половиной года руководил отделом разработки микроэлектроники, и могу раскрыть тему подробно, на примере вот этого проекта разработки достаточно сложного микроэлектронного блока, который велся в моей лаборатории.
http://rnd.cnews.ru/tech/electronics/news/line/index_science.shtml?2008/06/02/302983
Это, вероятно, наиболее успешный наш проект — 9 месяцев, 7 человек, строго на графике, сделано ровно то, что требовалось. В этом проекте, ironically, мы задействовали как раз _программистские_ практики организации разработи, что позволило нам сильно снизить затраты не в ущерб качеству. У микроэлектронщиков вообще организация разработки отстает от программистов лет на десять (если сравнивать их практики с лучшими практиками организации разработки ПО, а не с тем бардаком, который мы наблюдаем на практике на многих местах у нас).

Для начала, остановимся на разнице в микроэлектронике и программировании с точки зрения проектировщика/архитектора.
1. Их системы сильно проще программных систем по одному показателю. Там сильно меньше юз-кейсов, и они сами по себе существенно проще. Кроме того, в этих системах состояние хорошо локализовано (нет памяти — нет состояния), и не может меняться откуда попало. Оно по большей части локально. То есть, аппаратчики почти не имеют проблем программистов, связанных с мутабельным состоянием, которое неконтроллируемо меняется откуда попало, а это важно в плане природы самых геморройных ошибок.
2. Сложнее же они тем, что это hard-realtime системы. Представьте, что у вас на каждую функцию есть жесткое ограничение по времени, за которое она должна отработать при любых входных данных.
3. На задержки влияет геометрия и взаимное положение элементов — еще один фактор, в принципе отсутствующий в разработке ПО. Не то, чтобы это слишком сильно играло для встраиваемых систем на этапе проектирования, но это принимается во внимание, потому что может влиять на архитектуру.
4. Площадь — один из самых критичных факторов. Каждый лишний миллиметр площади кристалла — это бабки, прибавляемые к стоимости каждого кристалла. Это порядка 6 центов для техпроцесса 0,13. И такие безобидные вещи, как память — жрут площадь особенно быстро.
5. Вы можете получить ошибку на каждом этапе работы — в том числе, вы не застрахованы от ошибки САПР-ов.
6. Ошибок в кристалл должно попасть как можно меньше. Одна итерация с прототипом — это минимум 4 месяца (два из них фабрика делает прототип, если это быстрая фабрика), и в реальности будет больше. Ошибки, как вы видите, очень дороги.
7. В конечном кристалле ошибок для работы в заявленных режимах быть по возможности не должно. Перевыпуск фотошаблона — это от сотен тысяч баксов до порядка миллиона (или выше), если речь идет о современных тонких техпроцессах. Плюс, конечно, задержка времени с поставками.

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

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

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

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

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

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

Что поменяли в традиционных процессах мы, когда делали видеоконтроллер. У нас был жесткий бюджет, и я выкинул из проекта отдельных верификаторов. Кроме того, в проект на правах архитектора был включен программист, который знаком с видеообработкой, и умеет писать модели аппаратуры. Штука в том, что нам прототип ключевых аспектов архитектуры нужен был до того, как закончен архитектурный этап, и готова документация по ней. Поэтому, группу высокоуровневого моделирования не привлекали, а обошлись одним Сергеем Зефировым (thesz), включив его в состав команды как архитектора, и подчинив непосредственно руководителю проекта. Модели он писал на Хаскеле, в одиночку, без ТЗ, потому что сам был автором ТЗ и соавтором архитектуры. Таким образом, мы устранили тормозное звено в коммуникации "через бумагу", и ускорили "итерации" дизайна. Применяй мы на этом этапе SystemC как все — нихрена бы нас это не прокатило, для модели бы отдельная спецификация потребовалась.

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

Тестовый план, разработанный также на раннем этапе, являлся следтсвием ТЗ, перечисляющего все юзкейсы, и стратегии тестирования, перечисляющей виды тестов. Он определял уже конкретный план работ по обеспечению качества, которые распределялись по разработчикам блоков, и программистам. В результате, мы обошлись ОДНИМ выделенным апарратчиком, который отвечал за стратегию тестирования и тестплан, и смогли обеспечить великолепное качество.

Тем временем, Женя Янкевич (руководитель проекта) заранее зарядил разработку эмуляторов памяти и внешней обвязки, которая позволила бы нам прогонять общесистемные тесты на модели, а программисты усиленно писали скрипты на Перле, которые позволяли задувать картинки во все модели, и просматривать выход видеоконтроллера также в виде картинок.

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

В результате, когда на переговорах по сдаче второго этапа работ (на котором, по условиям контракта, у нас должно быть собранная вместе модель устройства, но она не обязына проходить системные тесты), я в ответ на вопрос о работоспособности модели сообщил заказчику, что она уже показывает картинки в разрешении SECAM, у заказчика, который в микроэлектронном бизнесе не в первый год (Фомин, 1-й зам НТЦ Модуль), случился шок. В сугубо положительном смысле этого слова. Он не мог понять, как такое возможно. Мы объяснили, и показали картинки .

Итак, все завершилось хорошо, ребята молодцы, и сработали великолепно. Мы здесь-то во многом эффективно сработали потому, что смогли избежать "традиционного" для разработки аппаратуры сдвига акцента на документацию, сохранили маленький размер команды, и очень вдумчиво и к месту применили элементы PSP/TSP и agile-практик. Действуй мы "традиционно" — мы бы вылетили за бюджет и график к чертям и качество не смогли бы обеспечить. Но главное, конечно, в том, что у нас была отличная команда. Парни молодцы.

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