К Луне!

При снижении HAKUTO-R пролетел над трехкилометровым обрывом, что вызвало резкий скачок показаний альтиметра, после чего система контроля высоты перестала учитывать его данные, посчитав альтиметр неисправным (у них что, не было дублирующего датчика?! – не понял этот момент).
А чем бы тут помог дублирующий датчик?
 
Реклама
А я всегда говорил, что этот мир погубят программисты!
Как и в большинстве проблем приписываемых программистам, тут виноваты составители ТЗ (isoace отдельно это подчеркнули, сказав, что хотя софт разрабатывала компания Draper, Ispace берет ответвеность за сбой на себя, так как ПО отработало а соответвии с ТЗ). Так что руки прочь от программистов :)
 
Как и в большинстве проблем приписываемых программистам, тут виноваты составители ТЗ (isoace отдельно это подчеркнули, сказав, что хотя софт разрабатывала компания Draper, Ispace берет ответвеность за сбой на себя, так как ПО отработало а соответвии с ТЗ). Так что руки прочь от программистов :)
Ааа, так у них было ТЗ на софт!
С ТЗ и дурак сможет )))
 
Письба софта без requirements
- или никогда не кончается,
- или кончается плохо.
Да ладно, я сто раз так делал! Десятки из них нормально прокатило)))
Правда, я всегда с пиететом относился к людям, которые пишут код для бегающего, плавающего, летающего и т.д. У которых "ууупс" означает не "звони в бухгалтерию, пусть они там все откатят и руками проведут", а трахбабамс)))
 
Да ладно, я сто раз так делал! Десятки из них нормально прокатило)))
Правда, я всегда с пиететом относился к людям, которые пишут код для бегающего, плавающего, летающего и т.д. У которых "ууупс" означает не "звони в бухгалтерию, пусть они там все откатят и руками проведут", а трахбабамс)))
ТЗ составленное в голове, и даже прямо по ходу написания программы не перестает быть ТЗ как его не обзывай. "Хочу, чтобы при нажатии красной кнопки, в кофе добавлялся коньяк" - это ТЗ, А реализовать это в программе - это программирование. И если ТЗ у вас в голове и вы сами пишите программу, то вы, конечно, понимаете, что имеется в виду ваш кофе, а вот если вы то же ТЗ излагаете программисту, то потом не удивляйтесь, что коньяк льется в его кофе, а не в ваш 😉
 
ТЗ составленное в голове, и даже прямо по ходу написания программы не перестает быть ТЗ как его не обзывай. "Хочу, чтобы при нажатии красной кнопки, в кофе добавлялся коньяк" - это ТЗ, А реализовать это в программе - это программирование. И если ТЗ у вас в голове и вы сами пишите программу, то вы, конечно, понимаете, что имеется в виду ваш кофе, а вот если вы то же ТЗ излагаете программисту, то потом не удивляйтесь, что коньяк льется в его кофе, а не в ваш 😉
Программист не знает ничего(и не обязан) о компонетнах и порядке залива кофе в коньяк. это должны ему предоставить составители ТЗ, что, очевидно, японцы не сделали.
 
Реклама
Программист не знает ничего(и не обязан) о компонетнах и порядке залива кофе в коньяк. это должны ему предоставить составители ТЗ, что, очевидно, японцы не сделали.
Да, не. Насколько я смог понять дело было так: разработчики зонда подумали: если откажет высотомер, в принципе сесть можно, примерно прикинув положение по расчетным данным и аккуратненько паркуясь до удара садясь пока не сядет. Но как понять, что высотомер показывает ерунду? Решили, сравнивать его показания с расчетным и если числа сильно отличаются, то считать высотомер врунишкой.
И вот в этом "сильно отличаются" и была загвостка: выбранная разница подходила для первоначального равнинного места посадки. И алгоритм прошел основную тщательную проверку. А затем поменяли место посадки на более пересеченную местность и тесты уже были не такими скурпулезными. И во время этих тестов разница в 5 км как я понял ни разу не попалась (видимо не прошерстили местность на предмет максимальных перепадов). А в реальном полете выпал блэк -джек наоборот - худший рельеф за границами протестированного. Такая вот невезуха.
 
Программист не знает ничего(и не обязан) о компонетнах и порядке залива кофе в коньяк. это должны ему предоставить составители ТЗ, что, очевидно, японцы не сделали.
Если я буду писать ТЗ с точностью до того, в чью кружку должен литься коньяк, то я буду молодец, но без работы.
Потому что илеалтное ТЗ нудно писать долгими месяцами.
А если пригласить толковых Программистов и дать им в ТЗ основные идеи, то дальше они сами всё расширят и углубят, напишут требования, и принесут мне на утверждение.
Таких мало... но они есть!
А те, кто отключает высотомер при любом алёрте, потому что в ТЗ чего-то там не дописали заказчики -- это кодеры, а не программисты.

По теме: Жалко девайс, разбили по глупости (
 
А те, кто отключает высотомер при любом алёрте, потому что в ТЗ чего-то там не дописали заказчики -- это кодеры, а не программисты.
Зачем вы придумываете то,чего не было? Всё заказчики дописали. Просто после изменения места посадки указанное в ТЗ значение стало неверным. Никакой сколь угодно гениальный программист этого знать не мог. А вы хотите, чтобы программисты сами определяли значения физических величин от которых зависит поведение аппарата в полёте? Может программисты тогда будут и траекторию просчитывать, и научные задачи аппарату ставить и статьи в научные журналы писать по результатам исследований? Они у вас походу всезнайки 😁
 
если пригласить толковых Программистов и дать им в ТЗ основные идеи, то дальше они сами всё расширят и углубят, напишут требования, и принесут мне на утверждение.
Это если программист в теме прикладной задачи. Не думаю, что на рынке много программистов, которые в теме полетов над Луной
 
Зачем вы придумываете то,чего не было? Всё заказчики дописали. Просто после изменения места посадки указанное в ТЗ значение стало неверным. Никакой сколь угодно гениальный программист этого знать не мог.
какие данные стали неверными?
 
Вообще, конечно, интересный подход: считать датчик отказавшим, если данные кажутся нерасчетными. Чего бы тогда просто по расчётам не садиться... Второй датчик для сверки по массе не прошёл? :unsure:
 
Чего бы тогда просто по расчётам не садиться.
похоже, что после отбраковки данных (датчик(и) корабля зафиксировали резкое изменение высоты, а ПО посчитало этот скачок аномалией) садились ориентируясья на высоту, рассчитанную в ходе симуляций.
 
похоже, что после отбраковки данных (датчик(и) корабля зафиксировали резкое изменение высоты, а ПО посчитало этот скачок аномалией) садились ориентируясья на высоту, рассчитанную в ходе симуляций.
ну вот и интересно, как они балансировали риск отказа датчика с риском ошибиться в расчетах. Вроде как датчик должен быть надежным достаточно, расчеты - хз. Короче, второй датчик зря зажали :)
 
Реклама
ну вот и интересно, как они балансировали риск отказа датчика с риском ошибиться в расчетах. Вроде как датчик должен быть надежным достаточно, расчеты - хз. Короче, второй датчик зря зажали :)
Второй датчик показал бы тот же самый овраг.
Алгоритм пррверки входных данных оказался плохой.
 
Назад