Порядок проектирования и обоснование выбора технических решений

Обычно принято думать, что основой для проектирования микроконтроллера является “хорошо” сформулированное техническое задание. На практике такие случаи крайне редки. Процесс проектирования является обычно сложным взаимодействием между двумя сторонами, которые мы в дальнейшем будем обозначать словами “Заказчик” и “Разработчик”.

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

Уточнение задачи всегда происходит во взаимодействии Заказчика и Разработчика. При практическом проектировании выбор тех или иных технических решений входит в обязанности разработчиков на всех уровнях - от руководителя проекта до рядовых исполнителей, поэтому учащимся надо представлять особенности этого взаимодействия.

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

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

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

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

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