1

Для всех / Обоснование выбора языка программирования (C vs C++)

« : 06 Сентября 2018, 11:52:28 »

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

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

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

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

Спасибо.

2

Для всех / Трассируемые документы.

« : 13 Декабря 2016, 17:04:34 »

Здравствуйте.
Укажите, пожалуйста, нужные ориентиры начинающему.
Пришлось выступать в роли представителя заказчика и писать ТЗ на систему, состоящую из нескольких устройств и ПО к ним.
ТЗ вышло монстром (объем чуть более 100 страниц), хотя сначала все казалось управляемым. В связи с этим появилось желание написать другой документ, повествовательный, объясняющий, как система должна работать в форме каких-то случаев использования, и на этот документ, назовем его "Программа функционирования", протрассировать свое ТЗ, чтобы было понятно, откуда взялись требования и зачем они нужны. Далее подумал, что не плохо и исполнителям свои требования к составным частям системы протрассировать на мое ТЗ, чтобы легче было их проверять, и можно было увидеть неохваченные требования. И, конечно же, программу и методику испытаний протрассировать на ТЗ. И чтобы все это можно было редактировать, не теряя трассировки.
Подскажите, пожалуйста:
1. Есть ли в описанном пожелании то, чего не надо / не возможно делать или стоит делать совсем не так.
2. Если для описанных мною документов или действий есть другие, правильные названия, подскажите их.
3. Есть ли freeware (или платное с триалом на срок, позволяющий успеть разобраться и продемонстрировать всем), чтобы воплотить описанное в жизнь и заинтересовать начальство в автоматизации разработки требований в принципе? Желательно, с возможностью создать репозиторий в сетевой папке и поработать с нескольких учетных записей.

Спасибо.