brutal_lobster

Скорее не из соображений безопасности - а из соображений простоты управления :)
Храните в конфигурационном файле.

А при компрометации сервиса, который подключается к БД, вас не спасет сокрытие реквизитов доступа.

А что значит связанная?)
Так то - криптография, моделирование, графика, big data..
Можно посмотреть предыдущие дипломы/диссертации - и добавить туда ваше IT.
Начните лучше с того, что именно вам интересно :)

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

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

А НСД - слишком обширный термин - тем более "ПК в ЛВС". На самом деле смысл вообще непонятен :) Конкретнее, конкретнее!

Загляните в стандарт по с++, например: 5.3.3 Sizeof

The result of sizeof applied to any other fundamental type (3.9.1) is
implementation-defined. [ Note: in particular, sizeof(bool), sizeof(char16_t), sizeof(char32_t), and
sizeof(wchar_t) are implementation-defined

Ошибки такие же как и в других задачах - почитайте книжку по ООП - особенно в части инкапсуляции.

У окружности только два параметра - координаты центра и радиус. Их вы должны передавать при создании объекта. После создания их нельзя изменять напрямую.
Если есть необходимость, то можно создать два доп. метода - move() и enlarge()/shrink()/...

Ну и форматирование, сериализация..

1. При создании юзера неплохо было бы указывать его имя и дату рождения
2. Возраст не является его свойством и зависит от конкретной даты
3. У юзера может меняться имя
4. Зачем там internal ?
5. Сериализация
6. Форматирование

Очень неудобная и немного не понятная схема :) Софтины как-то сильно связаны, нужно ли разделять процессы их разработки?
Чтобы ничего не отваливалось при изменении - пишите тесты! :)

А миграции однозначно помогут. Инкрементальная разработка - все дела :)

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

upstart.ubuntu.com