Вопрос к мировому разуму-кто как начинает разработку нового проекта?

1.Софт-что используется при начальном проектировании-что-нить типа UML,квадратики на листике бумаги,начнем писать-там видно будет или что-нибудь еще?Необходимость и выбор RTOS для проекта.
2.Как оценивается потребная призводительность контроллера?
3.Оценка требуемого обьема флэша и озу?
4.Периферия-ну тут проще(пляшем от ТЗ) но тоже интересно.
5.Время/стоимость разработки?
6.Какие еще пункты необходимы или наоборот лишние?

Спасибо.

1. Пропускаю, т.к. RTOS не пользуюсь, "многозадачность" искусственная, давно отработанная, диаграммы не нужны.
2. Ориентировочно, по самому скоростному процессу, плюс запас >=100 %. Оценивается необходимость вложенных прерываний, желательно уложиться до этой точки.
3. По коду - экстраполируется старый подобный проект, по константам - можно и посчитать (сообщения, знакогенераторы). Озу... Хороший вопрос.
4. Ну да, от проекта зависит.
5. Время. Впервые проект сделал раньше, чем обещал Методика расчета стоимости (трудозатраты/стоимость часа) * фактор (2..20) +/- востребованность.
6. Пункт сбора и проверки команды пропущен. Одиночные проекты мало кто делает. Нужно не то, чтобы детально планировать, но учитывать возможности каждого члена команды необходимо. И грузить их, грузить! Ну и автономных систем не бывает - из нужно к чему-то подключать, как-то тестировать - пропущен пункт продумывания внешних систем симуляции, тестирования и проч.

Может мне проще - у меня есть комманда. Мы садимся перед большим чистым листом с карандашами в руках и начинается мозговой штурм задачи. После которого определяются основные направления реализации проекта. Далие каждый профильный специалист уходит в проработку своего направления, время на это можно потратить от пары часов до недели.
Подход №2 профильные специалисты уже имеют набор решений и предложений. Опять садимся, только уже перед доской и рисуем, крутим-вертим. Анализ слабых-сильных сторон каждого решения. Потом принимаем коллегиально окончательное решение. По результату составляется внутренне ТЗ с указанием технологий, алгоритмов, средств и методов тестирования, ну и ориентировочный срок по каждой части. По этому ТЗ и работаем. Из ориентировочных сроков выбирается максимальный + 50% запас, и этот срок оглашается заказчику. Стоимость - работа людей в указанный период + интерес компании + расходники + доплата за срочность, если клиент захочет убрать +50% от срока (причем увеличение логарифмическое).
Документирование программной части: различные диаграммы UML
Аппаратная: блок схемы и времянки.
Строгих требований к компьютерному рисованию нет. Главное, чтоб работало, а не красиво было нарисовано, поэтому чаще всего это карандаш(ручка) на бумаге и сканер для электронной популяризации.

Объемы ресурсов определяем по готовым проектам, либо на этапе моделирования. Например для ПЛИС - это реализация конкретной функции, которая является самой ресурсоемкой в МС.

Напишу с точки зрения "фрилансера".
1. Рисую в основном на бумаге, но в последнее время стараюсь делать электронную версию, поскольку бумага имеет свойство теряться ОС не использую, поскольку нет надобности.
2. Стараюсь делать "интернет" обзор на предмет готовых кусков, советуюсь со старшими товарищами, если возникют вопросы делаю тестовые проги, дабы оценить вживую работу скажем нужной функции. Ну и плюс опыт уже реализованых проектов куда же без него
3. Плавно вытекает из п2.
4. Определяется ТЗ и существующими наработками, плюс набором применяемых МК.
5. Сложный вопрос, можно сказать больной Но обычно не меньше месяца на оригинальный проект, если что - то подобное делал, то можно меньше, но тут уже больше организационных проблем. Стоимость особый вопрос, и зависит от расценок в данной конкретной местности, тут трудно что - то сказать.
6. Добавил бы "железный" пункт, поскольку отделить софт +МК от остальной схемы невозможно, за исключением конечно, написания софта на готовую железку.

Добавлю мелочь. Она здесь неявно указана у chds.

Существует два подхода к проектированию. "Сверху" и "снизу". "Сверху" это когда создаётся сначала скелет проекта с разбитием на мелкие куски, а они уже потом дописываются (возможно разными программерами из команды). "Снизу" когда берутся мелкие куски и собираются в одну кучу. (Утрированно конечно). В связи с этим и пункты будут разные.