Обсуждение космических программ
9,138,650 41,202
 

  kostroma ( Слушатель )
13 дек 2011 15:27:56

Тред №370547

новая дискуссия Дискуссия  88

Цитата: НАлЕ
Разработка ПО - это всего лишь составная часть разработки чего-либо, причем не самая трудоемкая и не самая дорогая.


уважаемый чего вы к этому ПО привязались. я же 2 раза уже повторил что технологии управления разработкой ПО перенести на управление разработкой АМС. а вы упорно мне объясняете что ПО это не серьёзно что это часть большего и пр. и пр.  :)

Цитата
Разработка "всего остального" гораздо сложнее, потому как это работа разноплановая, включающая в себя проектирование (расчеты, выбор схемы функционирования, определение облика разрабатываемого комплекса в целом и его составных частей), конструирование (разработка документации на каждый узел, агрегат, систему, деталь, увязка их между собой), отработку, включающую в себя целый комплекс испытаний. В приложении к ракетно-космической технике это:
- прочностные испытания (СИ, ВИ);
- тепловые ;
- ресурсные (надежность);
- функциональные;
- и еще много каких, всех и не упомню и не знаю (например на электромагнитную совместимость) ...
Причем, сначала  это  автономные (для каждого узла, системы, прибора, агрегата), тут Перегрев может рассказать об объеме экспериментальной отработки "всего-лишь" какого-нибудь отдельно взятого ЖРД.Улыбающийся Потом комплексные ("изделие" в сборе).


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

Цитата
Отдельно надо сказать (хоть уже и упомянул) об увязке. Даже два относительно несложных узла увязать между собой не так просто (например, двигатель и систему подачи топлива. И тут опять Перегреву карты в руки)Подмигивающий) А еще надо увязать инерциальную часть СУ с вычислительным комплексом, с навигацией и радиокомандными системами, с телеметрическим комплексом, системой электроснабжения, терморегуляции. и т. д. , т. п., и пр . ... Зачастую узлы (системы, агрегаты) выставляют взаимоисключающие требования, их надо как-то "мирить".
Нужно "увязаться" с носителем, с "наземкой". При этом, да - это все усложняет жизнь программистам, так как каждая система, каждый агрегат в процессе отработки все время меняют некоторые свои параметры, что приводит к изменению (корректировке) исходных данных для разработчиков ПО. Но точно также, это усложняет и жизнь разработчиков "всего остального" из-за очень тесного переплетения механики, гидравлики, пневматики, электроники, радиотехники, баллистики, газодинамики, материаловедения и, наконец, математики (ПО) в весьма ограниченном габарите.


при изготовлении ПО тоже приходится мирить и увязывать, это нормально. Для минимизации влияния таких проблем на конечный результат нужно применять гибкие методики разработки, повторяю  ::)
  • +0.55 / 4
  • АУ
ОТВЕТЫ (0)
 
Комментарии не найдены!