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