OSDev

Хорошая ссылка, вот только это из той же песни, поэтому я вам дам ссылку в ответ
http://gilroks.livejournal.com/18085.html

[оффтоп]
Вообще тема как бы называется "NewOS - Новая российская ОС", а не "США vs. СССР 60-х годов" и не "Менеджеры vs. Инженеры".
Эти холивары стары как мир, и на этом форуме они явно не разрешатся. Забили бы уже давно.

Хотелось бы почитать что-то более полезное и конструктивное.
[/оффтоп]

Ну, за этим точно в какую-нибудь другую тему

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

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

Вопрос к участникам форума, разрабатывающим собственные ОС,
чем пользуетесь и что посоветуете?

Здесь волки одиночки. Наши ответы вам не помогут.
Надо спрашивать на других форумах.
У нас нет надобности в поддержании версий и отслеживать ошибки по дерево. Нет надобности в выпуске патчей для старых программ. Нет надобности в написание документации - не нужно вести дневник изменений. Хватает текстового файла. Нет надобности в написание документации как программной так и пользовательской. Не нужно делать отчётов по экспериментам.

Одно могу сказать ЕСПД - пользоваться не стоит. 1. Устарело. 2. Не дает никаких указаний.
короче говоря тут нет подхода.

Так что тут всё надо строить с нуля. Да есть опыт крупных и успешных фирм и его надо перенимать.

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

Чуть конкретно нужно
1. требовать написание исходного кода согласно правилам единого стиля.
За основу взять "Совершенный код".
2. Требование написание программной документации со 100% документированием функций. По форме как в МСДН или справке Борланд.
Описание должно передавать смысл, семантику. Т.е внутренний смысл который не отражает интерфейс. "CodeData - Данные кода" не есть правильное описание. А то очень частот комментарии и описание в таком духе, а это неправильно!!! Возможно следует просто по требовать не менее 100 слов и процент воды не более 70%. Методика измерения воды и подсчета слов должна быть обще доступны и представлена софтино.

Также требовать описание библиотек классов модулей, концепций и тд - объем и формат надо оговорить.
3. Требовать на каждую библиотеку примеры от 1 до 5, можно больше за тежи деньги.
4. Требовать пользовательскую документацию.
5. Требовать тестирования. Тестами должно покрываться 100% кода - на каждую исходную функцию нужны тесты.
6. Двойной-тройной контроль. Не надо конечно доводить до абсурда, как во ФГУП и причастных где по 10-15 подписей и никто ни за что не отвечает.
7. Требовать безопасность к параллельному исполнению кода. Распараллеливание очень дорогое удовольствие, поэтому хотя бы безопасность.
8. Требования устойчивости. Требования нужно формировать после проведения научных изысканий которые должны сформулировать эти требования.

Выполнение этих пунктов дорогого стоит, а во вторых требует не мало человеческих ресурсов.
В современном подходе к программированию, как правило данные пункты выполняются на 1%.
В макрософт в свое время вливалось много денег поэтому они все эти пункты выполнили. И я молчу про эскизное/техническое проектирование.
Требовать обоснования: научного-технического. А также сравнений с аналогами.
Требования к эскизному/техническому проекту можно взять из ГОСТа.


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

По поводу софта для написания, редактирования исходного кода. Отладки. Оптимизации. Документирования. А также архивирования.
Не нужно ограничивать, разработчиков пусть пользуются тем чем им проще. Но единый стиль документации стоит выработать и единый открытый формат.

По поводу софта - по хорошему нужна среда разработки где весь софт объединен вместе. Но на первых порах можно обойтись тем что есть:
VisualStudia, RadStudia embargo, Eclips и тп.
Отладчик должен быть простым как в первых двух, а не как gdb или BochsDbg где надо по 10 кнопок нажать за тот же результат.
Архивирование.
git, CVS
В архив должна помещаться проверенная, компилирующаяся без ошибок и от тестирования версия.
Резервное копирование должно быть устойчиво к ошибках и выходу из строя источника информации.

Документацию я бы делал в DokuWiki или в RTF. Либо свой формат. Но он должен быть простым и открытым для автоматизации сборки результирующей версии и коррекции.
Сейчас делаю в DokuWiki.


PS. Это далеко не полный список организационных вопросов.

pavia,
Вы все верно пишите, все это нужно закладывать с самого начала
разработки, иначе бардак будет транслироваться дальше.

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

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

Это называется система документа оборота предприятия. В которую видимо входит система контроля версий документов, а ещё и облако в котором эти документы хранятся.
К примеру у Simence есть такое.
Дорогое удовольствие и как я понимаю проблемы с внедрением. С учётом что у нас в России нет специалистов по ИБ и как следствие никаких нормативных документов. То я бы побоялся внедрять.
Мелкие и средние формочки используют системы попроще.
Программисты обычно используют только систему контроля версий такие как - CVS, GIT.
У макрософта есть система совместного редактирования документов. Не помню как называется толи аутлук толи офис.

Имел ввиду CASE системы

https://ru.wikipedia.org/wiki/CASE

Чем в основном пользуются российские разработчики системного ПО ?
Есть ли отечественные продукты подобного класса ?

Мы все же по взрослому собираемся ОСь созидать.

Сильно навороченное ни к чему, но все же какой-то органайзер нужен.

А это вообще самое правильное в вашем подходе - тупой начальник должен видеть, что попил будет вестись на научной основе, что под попил будут куплены новейшие CASE-системы (о которых начальник слышал лишь одно слово - КРУТО), что всё будет организовано на высшем уровне и если какой дурачок из начальников повыше поинтересуется, мол куда это вы деньги тратите, то ему в зубы можно будет выдать мегатонны документации, мегарекламу CASE-систем, ссылки на мелкософт и других монстров, мол смотри дурачок-начальник - вот особо умные экземпляры программописателей тоже так деньги пилят.

Ну и конечно же, после такой обработки дурачок-начальник никогда даже и не задумается спросить - а какой толк от всего этого для конечного продукта ? И что это вообще за конечный продукт ? Так что правильно вы всё делаете, много блестящей мишуры очень привлекает внимание недалёких начальников. И за мишурой легко можно спрятать отсутствие ДЕЛА.

А если всё же про ОС говорить (хотя зачем?), то нужно понимать - нахрена козе баян. Что даст ОС стране ? Зачем все эти НП и к ним приложенное гос.финансирование ? А в ответ - мишура про платформу, про отставание, про перспективы, про "мы так всё организуем, что у нас просто обязательно всё получится". А что получится-то ?

Я вам в ответ ссылку не дам, но дам совет. Во первых - много читайте, а во вторых - много думайте. И через сколько-то лет вы многое сами осознаете. А если поведётесь на стандартный развод про "везде обман, верить никому нельзя, но мне можно", то тогда действительно ни читать ни думать нет нужды, ведь зачем ? Ведь можно верить.