Обсуждение космических программ

Цитата: Liss от 09.12.2011 18:35:30

Кстати, интервью Хартова "Известиям" читали?

       Ссылкой не поможете?

Цитата: Stalky от 11.12.2011 04:39:14
       Ссылкой не поможете?

http://www.izvestia.ru/news/508997

Цитата: Nobody от 11.12.2011 04:40:49
http://www.izvestia.ru/news/508997

     Спасибо.

     Некоторые вещи вообще стали выглядеть затейливо.

     Цитата из 2-х томника НПОЛ и ИКИ РАН :Фобос-Грунт, проект космической экспедиции, М., 2011, а конкретно из раздела 2-7 Организация управления КА, том 1, стр.101:

     "...для обеспечения управления КА  готовится группа наземных станций...в Уссурийске, Медвежьих озерах и Евпатории...Поскольку  в отличии от всех предыдущих экспедиций связь с КА будет осуществляться в Х-диапазоне, на всех наземных станциях будет использоваться вновь разрабытываемый наземный радиотехнический комплекс. В Уссурийске и Медвежьих озерах обеспечиваются функции НРТК в полном объеме, включая прием ТМИ, выдачу команд и проведение траекторных измерений...в Евпатории обеспечивается только режим приема ТМИ. Для обеспечения связи с наземными станциями на каждом КА комплекса (ПМ и ВА) устанавливаются радиокомплексы Х-диапазона...
      Перечисленный выше состав средств относится к обеспечению управления на всех этапах полета, но на околоземных орбитах используются и другие средства контроля за полетом КА. На борту КА используется телеметрический передатчик РПТ111, который позволяет получать ТМИ в С-диапазоне практически сразу после отделения КА от РН, и прибор 38Г6, обеспечивающий траекторные измерения орбиты КА на расстояниях до 8000 км от Земли. Взаимодействие с указанными приборами осуществляют стандартные наземные станции, расположенные на территории России"

     Ну и куда они подевались - эти чудные приборы С-диапазона?  Да не включились - не подал на них питание замечательный бортовой вычислительный комплекс. Программисты блин аппарат разрабатывали

     PS Вообще-то это штатные приборы Фрегатов.Вот не хрен было отработанную систему управления РБ курочить на коленке.
Уж элеконовский ответчик (38Г6) могли бы в автономе от сырого БВК использовать - вот и не было бы проблем с определением траектории, а то в аппарат они узким лучом попасть не могли...комики: "Особенностью организации взаимодействия с КА на околоземной участке является практическая невозможность обеспечения двухсторонней связи с КА, в первую очередь на опорной орбите..." (оттуда же, том 1, стр.102)
     РS И что это за режим сохранения такой при котором РПТ111 и 38Г6 молчат в тряпочку, а в Х-диапазоне какая-то телеметрия идет?
БВК по ходу сам по себе к Марсу летит...все у него хорошо

С космодрома Байконур сегодня стартует ракета-носитель "Протон-М" с российским спутником-ретранслятором "Луч-5А" и израильским спутником связи AMOS-5.
Спутник-ретранслятор "Луч-5А" создан в ОАО "Информационные спутниковые системы" /ИСС/ имени Решетнева. Масса космического аппарата - 950 кг. Он войдет в многофункциональную космическую систему ретрансляции "Луч". Спутник предназначен для ретрансляции информации с низколетящих /на орбитах высотой до 2 тысяч км над поверхностью Земли/ космических аппаратов, включая пилотируемые космические комплексы, а также с других объектов ракетно-космической техники - ракет-носителей и разгонных блоков. "Луч-5А" будет принимать от них телеметрическую и целевую информацию на активных и пассивных участках полета, находящихся вне зон видимости с территории России, и передавать ее в режиме реального времени на российские наземные пункты приема информации.

Ракета "Протон-М" с израильским и российским спутниками стартовала с Байконура

Ну что, держим кулаки, фиги в карманах или каменюки за пазухой... =)

Цитата: Stalky от 11.12.2011 04:53:12
Перечисленный выше состав средств относится к обеспечению управления на всех этапах полета, но на околоземных орбитах используются и другие средства контроля за полетом КА. На борту КА используется телеметрический передатчик РПТ111, который позволяет получать ТМИ в С-диапазоне практически сразу после отделения КА от РН, и прибор 38Г6, обеспечивающий траекторные измерения орбиты КА на расстояниях до 8000 км от Земли. Взаимодействие с указанными приборами осуществляют стандартные наземные станции, расположенные на территории России"

Ну и куда они подевались - эти чудные приборы С-диапазона?  Да не включились - не подал на них питание замечательный бортовой вычислительный комплекс. Программисты блин аппарат разрабатывали

Прекраснейшим образом включились после отделения от второй ступени "Зенита" и передали вполне штатную телеметрию, зафиксировав построение солнечной ориентации и ток заряда аккумуляторных батарей. Работали и на втором витке, информация принималась на собственный пункт приема НПО имени С.А.Лавочкина. Первый отлетный импульс (длинный!) должен был начаться в конце второго витка и кончиться в начале третьего. Вот после него не пищало уже ничего -- до 23 ноября во всяком случае.

Да, Луч-5А и Amos-5 успешно выведены на заданные орбиты. А поскольку оба они -- изделия ОАО ИСС (бывш. НПО ПМ) на негерметичных платформах типа "Экспресс-1000" и -1000Н, то у нас намечается двойной праздник

Цитата: Liss от 12.12.2011 02:28:39
Прекраснейшим образом включились после отделения от второй ступени "Зенита" и передали вполне штатную телеметрию, зафиксировав построение солнечной ориентации и ток заряда аккумуляторных батарей. Работали и на втором витке, информация принималась на собственный пункт приема НПО имени С.А.Лавочкина. Первый отлетный импульс (длинный!) должен был начаться в конце второго витка и кончиться в начале третьего. Вот после него не пищало уже ничего -- до 23 ноября во всяком случае.

          А что такой тон менторский? Или не уловили иронию? Ну, хорошо - будем считать, что я плохо владею словом и не смог ее до Вас донести.
          ФГ - не кавалерийский наскок(Хартов), а Глобальная Авантюра (это снова, в некотором смысле, ирония).

          Если у Вас большая часть комплекса КА состоит из неотработанных изделий(речь ессно о платформе а не о научной аппаратуре) Вы бы стали брать на борт дополнительную нагрузку(китайскую) или же приняли бы решение применить в составе комплекса резервную КРЛ традиционного диапазона, доступную с любого отечественного НИПа?  Ну уж если Вы взяли китайца, то смените носитель - думаете, не выделили бы Протон?

         Обидно же до слез, что блистательная по замыслу миссия столь бездарно реализована.
http://video.yandex.…9057-07-12

         
         Не в оппозицию ФГ, а просто потому что Марс и потому что красиво привожу ролик про американца (не помню был он здесь или нет)

         http://trinixy.ru/pi…ry_new.flv

настало время напомнить, что "кавалерийский наскок" в СССР назывался волюнтаризмом и авантюризмом и имел довольно печальные статьи в Уголовном Кодексе- и на этой ответственности и зиждились успехи СССР

а сейчас за это по головке гладят?
языком...
девочки...
в Куршавеле...

Цитата: НАлЕ от 10.12.2011 12:35:15
Мы всю жизнь отставали от американцев по такому параметру, как продолжительность активного функционирования КА.

это я слышу уже 20 лет
вопрос в деталях
что именно у нас делают плохо как минимум в 30 раз по сравнению с?
и какие действия за всю жизнь были сделаны чтобы этот негатив снять?

хочется разобраться в чём же проблема, я думаю это многим интересно

Цитата
Они не были простыми. даже для американцев это были эксклюзивные изделия.

я не понимаю, то говорят что пионеры простые как пять копеек (этим объясняют кстати что они работают по 30 лет и больше). то говорят что не простые а очень даже сложные. где правда?

Цитата
Атомная бомба давным-давно не секрет ни для кого, но много ли стран могут позволить ее себе? Наличием лицензий, конструкторской и прочей документацией такой вопрос не решается.

это к делу не относится, не уводите дискуссию об АМС в сторону

Цитата: НАлЕ от 10.12.2011 12:40:43
Программное обеспечение - это только часть (далеко не самая большая) всего процесса разработки проекта межпланетной экспедиции. Так что "организация процесса в программерской конторе" - это слишком примитивная для этого вещь.

вы передёргиваете или не поняли
я имел ввиду о применении свежих технологий управления не только к изготовлению программной части АМС (это нужно 100% тут и обсуждать нечего). а о применении их, может в несколько иной форме - специфика своя, это понятно, ко всему процессу изготовления АМС и спутников в комплексе.

и в чём кстати примитивизм?
хоть какие-то сравнения предоставьте или это будет засчитано в какчестве наброса

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

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

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

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

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

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

Цитата: НАлЕ
Как это выглядит в натуре? На каком-нибудь примитивном примере, если можно.

Гибкая методология разработки (Aglie)
scrum
дальше сами  :)
если есть конкретные предложения, пишите в личку. я подумаю.

зы
не удержусь процитирую кое-что тут

Цитата
Основные идеи:[3]

   Личности и их взаимодействия важнее, чем процессы и инструменты;
   Работающее программное обеспечение важнее, чем полная документация;
   Сотрудничество с заказчиком важнее, чем контрактные обязательства;
   Реакция на изменения важнее, чем следование плану.

Принципы, которые разъясняет Agile Manifesto[4]:

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

пмсм такой подход будет работать в любой сфере производства (включая и космическую отрасль)
советую обратить внимание

ззы
сам использую scrum (уже более 2х лет) в компании где сейчас работаю. там упор сделан на прогнозируемость и контроль за процессом.

Цитата: kostroma от 13.12.2011 15:46:24
Гибкая методология разработки (Aglie)
scrum
дальше сами  :)
если есть конкретные предложения, пишите в личку. я подумаю.

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

ззы
сам использую scrum (уже более 2х лет) в компании где сейчас работаю. там упор сделан на прогнозируемость и контроль за процессом.

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

Ну а вот это просто лозунги на тему, как хорошо быть молодым, здоровым и богатым, чем старым, бедным и больным:

ЦитатаПринципы, которые разъясняет Agile Manifesto[4]:

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

Первый частный космический корабль причалит к МКС в феврале.
НАСА назначило полет частного грузового космического корабля Dragon на орбиту на 7 февраля 2012 года, сообщает сайт американского космического агентства. "Ракета Falcon 9 выведет корабль Dragon к Международной космической станции  для стыковки", - говорится в пояснении к планам НАСА.
НАСА и компания SpaceX намерены объединить два тестовых полета: подлет к МКС и стыковку к станции. Тестовый полет американского частного корабля ранее планировался на конец этого года.
В сентябре американские СМИ сообщили, что российская сторона не удовлетворена проведенным в декабре 2010 года первым тестовым полетом корабля Dragon и до сих пор не дала "добро" на проведение его стыковки к МКС во время второго полета.Со ссылкой на президента SpaceX Гвинн Шотвелл американские СМИ также ранее сообщали, что запуск грузовика Dragon может быть осуществлен только после старта 20 декабря пилотируемого корабля "Союз ТМА-03М", на котором на МКС прибудут астронавты, подготовленные к приему первого корабля Dragon.
Согласно контракту между частной компанией SpaceX (производитель ракеты Falcon-9 и корабля Dragon) и Национальным аэрокосмическим агентством США на сумму $278 млн, в ходе второго демонстрационного полета корабль Dragon подлетит к МКС, после чего астронавты должны захватить грузовик с помощью канадского дистанционного манипулятора SSRMS и пристыковать его к станции.
В случае успеха демонстрационного полета компания SpaceX по другому контракту с НАСА на сумму $1,6 млрд начнет регулярные полеты кораблей Dragon к МКС. Всего намечается не менее 12 таких миссий, - сообщает "Интерфакс".
Корабль Dragon может привозить на МКС до шести тонн грузов и возвращать с нее до 3 т грузов. Для размещения аппаратуры и оборудования на грузовике имеются герметичный объем размером 10 куб. м и негерметичный объем - 14 куб. м. http://rus.ruvr.ru/2…22009.html
---
А без "грузчиков" то он состыковаться не может похоже ?

Цитата: НАлЕ от 13.12.2011 16:03:46
С одной стороны, все это очень похоже на пособие для "эффективных менеджеров", с другой стороны,  очень многое давным давно применяется. Тот же итерационный подход при определении облика разрабатываемого продукта. Но этот же итерационный подход вряд-ли можно применить при разработке того же ЖРД, когда его облик уже определен проектантами.

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

и всё это совсем не лозунги, это построение рабочего процесса.
просто к золотым рукам и смекалке необходимо приложить расчёт и контроль в лице менеджера. это необходимо.
у меня проблема видна практически сразу как только появилась, на одной из текущих итераций, а не в конце разработки или уже после сдачи.
мне не понятно чего это вы так защищаете текущую ситуацию менеджмента в космической отрасли?
и ещё интересно по какой методологии работают разработчики АМС и ИСЗ?

в качестве оффтопа
на примере ssj разве невидно как помогает нормальный мэнеджмент (помимо денег и недостающих технологий) в разработке качественного и конкурентного продукта? в чём тут отличие от космоса по сути?

Цитата: НАлЕ
Совет Главных Конструкторов, а не Главных Инженеров (это весьма разные должности).С чего Вы взяли. Институт СГК никто не отменял.

никто не отменял только такой роли как раньше не имеет или людей соответствующих в нём нет. я по результатам сужу.

Цитата Как можно процесс отработки ЖРД разбить на итерации, в конце каждой из которых должен быть типа законченный продукт.

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

ЦитатаЕстественно. А Вы хотите сказать, что этот процесс никто не строит и он идет сам по себе?

я к тому что надо внедрять самые передовые методики. такое впечатление что идёт сам по себе

ЦитатаДля этого давным давно существует институт ведущих конструкторов, а также подразделений-кураторов (на фирмах "головниках"), курирующих работы смежников.

это хорошо. нужно идти дальше. выстроить систему
   Владелец Продукта (Product Owner)
   Руководитель (ScrumMaster)
   Команда (Scrum Team)
(см.scrum)
это всё не в том ключе что куратор приезжает на приёмку изделия, а каждодневный процесс. в первой половине рабочего дня совещание (можно через интернет - почему нет?) все проблемы вчерашнего дня план на сегодняшний. можно реже - нужный ритм сам определится.

ЦитатаРазработчику болта М24 тоже сразу видны все его проблемы, вот только почему-то разработчик гайки делает ее не М24, а на 3/4''и ему тоже видны все свои проблемы. Вы тот самый разработчик  болта (или гайки) и со своего места (разработчика ПО) не можете видеть всех проблем разрабатываемого супертехнологического чуда-юда.

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

ЦитатаА я  и не защищаю, по той простой причине, что "текущая ситуация менеджмента по управлению процессом разработки в космической отрасли мне практически неизвестна.

мне тоже неизвестна и похоже мало кому понятна. из-за этого и создаётся впечатление что там всё само по себе как-то идёт

Цитата"Методологии" могут быть разными, в зависимости от типа и назначения аппарата (военный или "гражданский", серийный или штучный, "обычный" или супервысокотехнологичный ...).

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

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

где же я напутал? ткните носом!  :)
зачатую программный продукт одноразовый и часто эксклюзивный. хотя согласен тут чаще приходится идти по уже проторенной дороге или хотя бы намеченной
вы не путайте винтики и железяки из которых состоит изделие и само изделие.
ещё надо учесть что одно дело сделать систему которая взаимодействует с человеком и другое дело система которая должна выполнить определённую программу с определёнными допусками. такое даже протестировать проще пмсм  :)

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

Фрегат - это круто, согласен. Но не все программерские конторы используют новые подходы к разработке как видимо и не все космические конторы. но в it сама жизнь вынуждает. никто не будет кормить контору которая пр@ебыв@ет деньги, выводов не делает, оправдывая это всё тем что "слишком уникальные разработки", "очень отстали", "денег надо в 10 раз больше" и прочее. такие конторы обычно закрываются очень быстро  :)
именно по этому технологии управления разработкой тут более конкурентные и здравые.

Цитата: kostroma от 13.12.2011 13:03:53
вы передёргиваете или не поняли
я имел ввиду о применении свежих технологий управления не только к изготовлению программной части АМС (это нужно 100% тут и обсуждать нечего). а о применении их, может в несколько иной форме - специфика своя, это понятно, ко всему процессу изготовления АМС и спутников в комплексе.

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

Цитата: НАлЕ
И если уж на то пошло, то разработка РБ Фрегат (который становится уже чуть-ли не серийным изделием) - достижение ничуть не меньшее, чем разработка Суперджета.

      Фрегаты - серийные изделия. Уже (около) два года как присвоена соответствующая литера.

Свои две копейки, по поводу позорно мной пропущенной дискуссии
Во-первых - респект уважаемому Stalky за очень точную, ясную, и на мой взгляд, безупречную формулировку.
Во-вторых - привычный респект уважаемому НАлЕ, за точное и детальное понимание ситуации, толерантность и понимание. И просьба убрать АУ.
Ну и собственно два слова уважаемому kostroma. Видите ли дело в том, что попытки создать некую, абсолютно универсальную методику управления предпринимались неоднократно. Равно как и попытки распространить некоторые успешные прецеденты на все сразу - тоже. Результат вполне описывается известным в узких кругах анекдотом: "Достоинства конструкции - простота, надежность, технологичность. Недостатки - не работает..."
Вы меня простите, но вот этот рефрен

Цитата
Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.

На жаргоне называется "лозунгом" и единственным вариантом его использования является размещение на заборе на доске объявлений. Подобные концептуальные подходы к проектированию РКТ неприменимы в принципе, потому как  они описывает принципы существующей и работающей системы проектирования, а не принципы проектирования вообще. Я Вас уверяю, что сплошь и рядом, последовательное выполнения плана (для РКТ) имеет совершенно принципиальное значение для создания надежной техники, а вот оперативная реакция  на малейшее изменение конъюнктуры - наоборот, может привести к тяжелейшим последствиям. Что мы и видим на примере  ФГ, когда для того что уложиться в директивные сроки беспощадно кромсали не только программы испытаний (уповая на "всесилие человеческого" разума в плане "на пальцах" предусмотреть все возможные ситуации) но и похоже конструкцию. К слову, я в свое время, положил немало сил, доказывая, что нельзя РК-98 в чистую применять к разработке, испытаниям и производству программного обеспечения.
P.S. Удивительно, что мы, одними и первых, создавшие и успешно использовавшие такие СМК как "самарская система",  КС УКП теперь раскрыв рот внимаем заокеанским таинствам типа ИСО 9000...
P.P.S. Stalky, не знаю как Фрегату присваивали литеру, знаю как присваивали 14Д30. Мама, не горюй! О₁ и без МВИ и без МВК это надо суметь!

Цитата: перегрев
При все уважении - опять же на жаргоне это называется: "А сделайте мне хорошо" Кто спорит, что надо все рассматривать в комплексе. Вопрос в другом - а как это сделать?

Ну...
Обычно стараются не делать "абсолютно прорывной проект". ИМХО, эволюционность должна рулить. Хотя бы на уровне рабочих макетов. Чтобы хоть за что-то было можно ручаться. Хотя, в РКТ, так, наверное, не всегда возможно.

Цитата: НАлЕ
А по каким результатам? Да, это год можно считать неудачным, аварийность таки повышенная: ФГ загнулся, Прогресс упал (ну этому-то и пора уж было хоть раз) ... . А ГЛОНАСС функционирует в полном объеме, Радиоастрон работает, Союз "прописался" на Гвиане. Всего в 2011 году произведено 29 пусков

началось всё с ФГ. я не говорил что полохо всё.

ЦитатаТам же про итерации говорилось и в конце каждой итерации продукт считается готовым.
Да ЖРД отрабатывается по частям (камера, ТНА, зажигание и пр ...) и там тоже идет отслеживание взаимного влияния каждого элемента на "соседние".

где там написано что продукт считается готовым не вижу. вижу "Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации." но кроме того "Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование." т.е. продукт готов по итогам данной итерации.
если все задачи итерации решены. и можно переходить к следующей итерации и так до победного конца.
к тому же "Подход Agile к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации."

т.е. гибкость не в том что всё разбито на итерации. а в готовности к изменениям как требований от Владельца так и от общих изменений. Т.е. если за пару итераций стало ясно что Владелец постоянно пересматривает свои требования, что приводит к переделкам то нужно увеличивать количество итераций в проекте (т.е. двигать сроки), либо разбивать проект на несколько групп и т.д. и т.п. т.е. действовать

к тому же, чтобы вы так буквально не рассматривали, можно разработать свой тех процесс. который будет учитывать особенности разработки АМС или отдельных частей той АМС (например туже двигательную установку).

Цитата
Сетевой график, который постоянно отслеживается и корректируется (при необходимости). А как разбить на итерации процесс разработки топливного отсека, например?

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

ЦитатаИменно так всю жизнь и делается. Любая работа начинается с разработки план-графика работ.

ессно, так и делается. это была часть ответа на ваши вопросы насчёт законченного продукта.
ау всётаки лучше снять. а то разговор наш канет в лету а я дело говорю  ;)

ЦитатаКомплексный подход - это наше все. Не зря, всегда подчеркивалось, что разрабатывается не ракета и не спутник, а ракетный комплекс и космический комплекс. Изначально это отражается в ТЗ (ТТТ), которое выдается именно на комплекс (а не на ракету, спутник), потом уже "головники" делят выделенные деньги разбивают весь объем работ по смежникам.

я про комплексный подход к введению уловной новой методики разработок. на всех этапах и на всех уровнях.

Цитата"Все украдено до нас": Заказчик - Головной исполнитель - Смежные предприятия (подразделения).
(см.scrum)

надо дальше вникать если хотите разобраться. а лучше, если вы этим решите заняться, поработайте в структуре где практикуется такой подход.
   Владелец Продукта (Product Owner)
   Руководитель (ScrumMaster)
   Команда (Scrum Team)
даю наводку
Владелец Продукта (Product Owner) это не Заказчик (пмсм вы подразумеваете под этим того кто выделяет деньги я прав?)
Руководитель (ScrumMaster) это не подрядчик-головник
и Команда (Scrum Team) это не субподрядчики-смежники
да и на уровне конкретного завода-подразделения это совсем уже не так
а на уровне цеха есть такой подход?

ЦитатаНу да, а Вы думаете, что в остальное время эта орава "бездельников" (а их чуть-ли не больше, чем непосредственно конструкторов и расчетчиков) ни хрена не делает, а только ждет, когда их пригласят водки попить "на приемку изделия"?

ну вы наговорили тут. а помимо работы водку пить религия не позволяет?
под куратором я подразумевал Владелец Продукта (Product Owner)
так вот он сам или его представитель (тот кто в курсе как _надо_ сделать не хуже самого) каждый день, каждый на своём уровне приходит в команду и выясняет все ли понимают что нужно сегодня сделать и отвечает на вопросы от команды. кстати эти встречи так и называются - scrum. можно их назвать планёркой, летучкой как угодно. главное чтобы смысл дошёл. и это не ради галочки или проформы делается.

ЦитатаТакие проблемы возникают из-за неудовлетворительной работы "головников"

по разной причине могут быть такие проблемы. тут важно вовремя проблему обнаружить и решить.

ЦитатаКак все сразу и на одном совещании, или все-таки партиями по паре-тройке сотен человек?

а у вас что, в одной группе которая исполняет конкретную задачу сразу от 100 человек?  :D

ЦитатаИ что тут нового?

тут ничего, но это слагаемое будущего успеха  :)

ЦитатаЕму и не надо. Более того, зачастую он и не имеет права видеть дальше своего носа.

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

ЦитатаВы согласны, что процесс разработки массовой легковушки и 8-осного "ракетовоза" - это весьма разные процессы?

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

ЦитатаА в чем я путаю? В отличие от , допустим, автомобиля, в РКТ практически любой "винтик" может оказаться критичным для работоспособности "изделия".

в том что речь идёт о подходе к разработке а не о условиях эксплуатации.

ЦитатаПравильнее будет так: никто не должен кормить. Что касается "Лавки", то выводы будут и не только по ней, но и по Роскосмосу и по всей "своре" смежников.

надеюсь разум возобладает

ЦитатаPS. Все, что Вы тут высказали, все это (или почти все) правильно, но это все разговор на тему "как должно быть" ( а это , в принципе, давно известно), а сейчас важнее тема" как сделать так, чтобы все было, как должно быть".

понятно что всё должно быть хорошо и правильно
я просто попытался навести на мысли как можно улучшить положение с менеджментом