Здравствуйте, уважаемые участники форума.

На проекте, близком к железу, стоит задача выбора языка программирования.
Средства разработки поставляются производителем железа, поэтому выбор ограничен поддерживаемыми языками C и C++.
Традиционно в компании такие задачи решались на С, есть большой объем реализованных библиотек.
 
1. Мы с командой (участвую в проекте со стороны разработчиков) считаем обоснованным применение C++ и видим в этом возможность за счет ООП дизайна улучшить качество кода и, как следствие, снизить расходы на исправление дефектов.
Сейчас предложение такое - прикладной уровень реализовать на C++, уровни системы и библиотек использовать прежние (реализованные на C). Переписывать с нуля - очень дорого. Рассматриваем проведение работ в несколько этапов:
- Заимствование всего необходимого в C - проект. (Фактически реализовано уже).
- Перевод сборки прикладных модулей на компилятор C++, сохранив стиль Си. Здесь нужно будет добиться сборки - язык C++ более типизированный, имеет больше проверок, поэтому сразу не соберется. Здесь появятся Первые выгоды за счет большей помощи компилятора в поиске ошибок.
- Перевести функции с переменным количеством аргументов и макросы на средства С++. Здесь будет извлечена вторая выгода - неправильное применение функций будет обнаруживаться на этапе компиляции.
- Перевести управление ресурсами на ООП средства. Третья выгода - минимизируется угроза образования утечек памяти, ошибок пропущенной инициализации.
- Разработать стратегию преобразования архитектуры к ООП дизайну.
- Во время внесения новых функций (feature) в проект, постепенно рефакторить проект, переводя модули в классы.
2. Кроме того, у нас есть предложение по применению технологий, доступных именно на C++.

Для принятия решения необходимо "Продать" руководству эти две идеи. Хотим разработать с этой целью следующие артефакты:
- Обоснование. Нужны какие-то метрики, позволяющие сравнить нынешнее положение дел и предполагаемый результат, позволяющие оценить выгоду.
- Стратегию внесения изменений.

Может кто-нибудь поделиться ссылкой на хороший пример таких артефактов? Может, кто-то готов поделиться своим трудом в этой области?
Буду благодарен, если дадите советы.

Спасибо.

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

На C++ есть STL. Это сокращает разработку велосипедов на порядок.

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

В любом случае, сначала я бы попробовал выяснить его аргументы.

Заставить компилятор помогать искать ошибки, а для этого перейти на С++ -- я правильно поняло аргументацию?  "Разработать стратегию преобразования архитектуры к ООП дизайну" как один из завершающих шагов? Постепенный рефакторинг проекта из неОО к ОО чтобы... была применимость технологий, доступных именно на C++?
Я не Ваше начальство, но звучит не очень убедительно на мой инопланетный слух.
Представьте, что сохраняется статус кво, т. е. Си. Опишите негативные (и позитивные) возможные последствия этого (те самые искомые компиллером ошибки?). Продумайте как переход на С++ сглаживает негатив / не портит позитив. Оцените что стоит дороже -- разгребать последствия залипания на С или переходить на С++.
Ну, Вы поняли, мне советовать со стороны легко, и всё такое.

Но это же широченная дорога, по которой прошло множество компаний. Можно использовать старые библиотеки и все преимущества ООП.
На C++ есть STL. Это сокращает разработку велосипедов на порядок.
Я, честно говоря, не понимаю, почему руководство может быть против. Разве что потому что оно само и разрабатывало эти милые сердцу библиотеки?
В любом случае, сначала я бы попробовал выяснить его аргументы.

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

Заставить компилятор помогать искать ошибки, а для этого перейти на С++ -- я правильно поняло аргументацию?  "Разработать стратегию преобразования архитектуры к ООП дизайну" как один из завершающих шагов? Постепенный рефакторинг проекта из неОО к ОО чтобы... была применимость технологий, доступных именно на C++?
Я не Ваше начальство, но звучит не очень убедительно на мой инопланетный слух.
Представьте, что сохраняется статус кво, т. е. Си. Опишите негативные (и позитивные) возможные последствия этого (те самые искомые компиллером ошибки?). Продумайте как переход на С++ сглаживает негатив / не портит позитив. Оцените что стоит дороже -- разгребать последствия залипания на С или переходить на С++.
Ну, Вы поняли, мне советовать со стороны легко, и всё такое.

По сути да - все, что мы сейчас готовы высказать - уменьшение количества дефектов (и расходов на их исправление) за счет применения более строгого языка и более поддерживаемого дизайна Продукта.
Технологии, доступные на С++ - это, скорее всего, не аргумент. Их придется "продавать" отдельно. В сумме эти две идеи слишком дорого будут стоить. Но, возможно, их стоит отразить где-то на диаграмме, чтобы обозначить приобретение дополнительных перспектив и гибкости продуктовых решений.

Как делается оценка гипотетических выгод от гипотетических изменений, чтобы получилось не совсем "с потолка"?

По сути да - все, что мы сейчас готовы высказать - уменьшение количества дефектов (и расходов на их исправление) за счет применения более строгого языка и более поддерживаемого дизайна Продукта.
Технологии, доступные на С++ - это, скорее всего, не аргумент. Их придется "продавать" отдельно. В сумме эти две идеи слишком дорого будут стоить. Но, возможно, их стоит отразить где-то на диаграмме, чтобы обозначить приобретение дополнительных перспектив и гибкости продуктовых решений.

Как делается оценка гипотетических выгод от гипотетических изменений, чтобы получилось не совсем "с потолка"?

1) Составьте таблицу по ГОСТ (или ИСО/МЭК) 25010 и укажите, какие атрибуты вы собираетесь изменить.
2) Сделайте трассировку на финпоказатели фирмы. Об этом стоит прочитать в книге "Цель-3", а можно было прийти на вебинар (в июне кажется), там эта трассировка довольно подробно разбиралась. Если все сложится, буду показывать эту трассировку на одной из конференций в этом году. На какой - не знаю.

Спасибо большое, коллеги.
Запланировал ознакомление с ГОСТ Р ИСО/МЭК 25010 и книгой "Цель-3".
Сейчас начал составлять списки выгод от применения С++ и недостатков применения на данном проекте С. Пока что отдельные, потом взаимно дополню их друг из друга.
Подыскиваю нотацию для наглядного отображения этапов внедрения и ожидаемых результатов.