1

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

« : 11 Сентября 2018, 23:35:32 »

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

2

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

« : 07 Сентября 2018, 11:56:14 »

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

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

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

3

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

« : 07 Сентября 2018, 11:43:36 »

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

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

4

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

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

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

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

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

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

Спасибо.

5

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

« : 15 Декабря 2016, 18:59:10 »

Отдельный вопрос - как КТ-178В (или другой стандарт) связать с ЕСПД, чтобы не возникало никаких вопросов (наш заказчик требует следования ЕСПД). Состав документов ведь разный. Да и жизненный цикл, как я понимаю, предполагается разный. Или тут я зря беспокоюсь?

6

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

« : 15 Декабря 2016, 18:24:47 »

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

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

Взял этот формат за основу (других вариантов и не было). Принципиально старался переломить традиции в нескольких местах:
1. Постарался сделать каждое требование отдельным подпунктом, чтобы на него можно было ссылаться. Уже после передачи исполнителю понял, что много где это не получилось - требования можно еще разбить.
2. Постарался избавиться от неполноты требований: если даются параметры входных/выходных сигналов, то давать все, например. Тоже не вышло идеально.
3. Не разрабатывал структуру, а разбил все на функциональные модули, описал, какие функции они должны решать. Предоставил конкретную структуру выбрать разработчикам.
4. Добавил требование использовать SVN или Git и предоставить доступ Заказчику.
5. Добавил требование перед созданием всех составных частей и ПО разработать и согласовать на них требования, а затем и проект.
6. Добавил требование согласовать стандарт  на кодирование (сам же его и разработал, пока шли споры).
7. Добавил требование разработать и согласовать программу и методику тестирования составных частей устройства и самого устройства. Раньше принимали работы бессистемно. Методику разрабатывали уже при постановке на производство. И то очень короткую, не покрывающую почти никаких требований.
8. Добавил требование разработать словарь данных. Хотя, теперь уже сомневаюсь, что правильно смысл термина понимаю. Вижу его как докумет, присваивающий каждой сущности идентификатор, который должен быть использован во всем ПО, на всех схемах.
9. Пытался формулировать требования так, чтобы они были проверяемы. Тоже не все гладко.

Нет, к КТ-178В никаких претензий нет. Есть еще, кажется, с него же списанный ГОСТ 51904-2002. Проблема в том, что я просто запутался - никогда раньше не поднимался выше роли кодировщика. В частности, дорожка от ТЗ до требований к ПО - как в тумане. В КТ-178В есть упоминание "Требований к системе" и "Программы функционирования". Не понятно, это одно и то же, или нет. Не понятно, является ли ТЗ синонимом одного или обоих из этих терминов. В общем, в системной области - полная дезориентация. Буду рад, если участники форума пояснят, что из этих трех документов за чем следует и чем они отличаются.

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

7

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

« : 14 Декабря 2016, 16:54:39 »

Спасибо всем ответившим. И снова здравствуйте.
Galogen, спасибо за контакт. Но пока что вряд ли будет какое-либо финансирование для привлечения специалиста. И пока что "с ходу" не понял, что такое "Модель трассировки".
1. К сожалению, главная проблема - именно отсутствие культуры разработки на всех уровнях - предприятие старое и закостенелое. Исполнители тоже не в восторге от планов ввести даже SVN и Trac, но часть менеджмента видит, что по предыдущим проектам соисполнителям вообще не было выдано никаких требований, поэтому позволяют тратить на изучение вопроса время.
2. Название документов, наверное, позволит объяснять, чего же хочу в итоге. Некоторое время работал кодировщиком в организации, где использовался стандарт КТ-178B, но погружен в эти вопросы был только менеджмент. Планировал пока что опираться на него, как хоть немного знакомый. Или этот стандарт "из другой оперы"?

Denis Beskov, приходилось пользоваться Jira, но думал, что она только для учета времени, потраченного на конкретные задачи, служит. Так же думал, что она бесплатная. Спасибо, буду искать картинки, как в Jira выглядят спецификации требований и матрицы трассировки.

Почитал, что такое user story и use case. Use case очень похож на то описательное объяснение работы, что я хотел бы разработать. А user story для железа, не имеющего пользовательского интерфейса, наверное, не подходит. В прочем, теперь я дезориентирован и думаю, является ли мое ТЗ бизнес-требованиями или чем-то еще. Или, может быть, оно должно чем-то являться, но я написал что-то другое По традиции нашей организации в ТЗ оказались и требуемые функции, и требовния к точности, и то, какая структура будет у системы, и какие технические решения должны обеспечивать выполнение функций. Наверное, это должны быть несколько документов: в ТЗ только требуемые функции и требования к точности, времени исполнения, а на его основе уже документ со структурой системы, взаимосвязями частей.

Спасибо, буду как-то укладывать всю эту информацию в сознании.

8

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

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

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

Спасибо.