Статистика: очередной КА убит софтом

Dem_anywhere> Ну как сказать? Вот например возьмём типичную прогу на мсбейсике. Что мы видим? Кучу объектов с эвентами.
Dem_anywhere> А как эти эвенты будут выполняться - последовательно или параллельно - создатель проги и знать не обязан.

Как это не обязан?! Обязан, естественно. Если он не будет знать, будет полная жопа. Даже на уровне UI, не говоря уже о вещах пониже. Кстати, в Java именно для избежания жопы Swing крутится в одном треде. Но, конечно, это все равно не означает, что программист может не заботиться о параллельности. С какой стати вам пришло в голову, что "создатель не обязан знать"? Вернее, создатель библиотеки, например, может и не обязан знать, как его эвенты будут выполняться. Но предусмотреть, чтобы они выполнялись корректно хоть в одном треде хоть во многих - разумеется, обязан.

Dem_anywhere> Ну как сказать? Вот например возьмём типичную прогу на мсбейсике. Что мы видим? Кучу объектов с эвентами.
Dem_anywhere> А как эти эвенты будут выполняться - последовательно или параллельно - создатель проги и знать не обязан.

Винда гарантирует, что все события на одном окне выполняются ПОСЛЕДОВАТЕЛЬНО!

Из типичной проги на МСБасике придется выкинуть ВСЕ глобальные объекты, либо все думать про синхронизацию. Сейчас что на VB не попадется - везде куча глобальных объектов. Собственно все VB наследство останется непараллелизируемым.

Mishka>При этом все железячные недоделки пытались решить за счёт софта.

Ну сие есть классика... Так везде происходит. Ведь, как ни крути, проектированную и собранную конструкцию нужно пересобрать для исправления недостатков, а ПО можно обновить удалённо и без заказа, изготовления и доставки новых деталей. Как всегда...

pokos> Эх, Мишаня, железячникам обновлять ничего не нужно, у них и на Земле всё прекрасно работало. Они и не обновляют.

Не обновляют потому, что не могут. Они ничего не "обновляли" ещё и на Земле: всё железо уже спроектировано и произведено, а, возможно, уже и смонтировано... За день до запуска, а программистам нужно теперь на первом рабочем устройстве за одну ночь добиться устойчивой работы.

Всё-таки, прав au: "Либо как положено, с гарантией, либо под вашу ответственность, сэр, приказ прошу предоставить в письменной форме".

pokos>Это как раз чудо-программисты не смогли уложиться в срок,

Одну ночь? У меня уже был подобный опыт создания ПО для системы сигнализации о начале землетрясения. Судя по описаниям от mishka, NASA недалеко ушло.

pokos>поэтому возможности железа не используются на 100%.

Потому что во время проектировки забыли создать систему железной проверки положения какого-нибудь важного рычага. Теперь приходится по числу шагов шагового электродвигателя ориентироваться. Потому и не используются. Кто виноват? Опять программисты? "Если в кране нет воды..."

pokos>Поэтому и всякие дурацкие патчи во время полёта ставят. По заветам Билла Хейса прямо-таки.

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

Хотя я и недолюбливаю "дядю Билли", но в данном случае он тоже жертва.

Mishka>Вопрос не просто поддержки обновления. А в необходимой и достаточной поддержке. Тут никто не хочет слушать программёров. Все борятся за вес, за место. Поэтому поставить аппаратную поддержку не хотят. Значит всё на программистов. А дать времени на разработку-отладку систем столько же, сколько железячникам не хотят. Вся разработка идёт на живом железе, которое меняется и плавает. Кто даст программёрам тот же спутник ещё на 5 лет после того, как железо не меняется на тестирование и доводку софта?

Золотые слова!!!

pokos> Вообще, управление софтовыми проектами - это гемор ещё тот. С железом куда проще. Это я вам говорю как человек, имевший опыт и в том, и в другом.

А чем проще с "железными проектами"? Там не так сильно за сроки спрашивают? Иные причины?

pokos>> Вообще, управление софтовыми проектами - это гемор ещё тот. С железом куда проще. Это я вам говорю как человек, имевший опыт и в том, и в другом.
anybody> А чем проще с "железными проектами"? Там не так сильно за сроки спрашивают? Иные причины?

Там цикл разработки дольше и не так сильно зависишь от ошибок/изменениях в третьих модулях. Интерфейс практически не меняется никогда.

pokos>>Поэтому и всякие дурацкие патчи во время полёта ставят. По заветам Билла Хейса прямо-таки.
anybody> Потому что утром после запуска управляющего осенило: нужно обязательно добавить аппарату и такую возможность! Или это опять программисты виноваты, что инженеры-разработчики не предугадали гениальный полёт мысли управляющих?

Инженерия, как и политика, есть исскусство возможного. Сделать все идеально иногда можно, но почти всегда очень дорого и долго. Поэтому обычно делают так, чтоб выполнение такой-то конкретной задачи было достаточно вероятным в принятые сроки. Иногда можно добиться этой вероятности в 99.9999999999% за небольшие деньги. А иногда и 50% вероятности таких ресурсов требует, что лучше добиться 25% вероятности выполнения, но зато в десять раз дешевле.

Сергей-4030>Там цикл разработки дольше

По-видимому, это надо понимать так: "Руководство выделяет больше времени на "железо".

Сергей-4030>и не так сильно зависишь от ошибок/изменениях в третьих модулях. Интерфейс практически не меняется никогда.

И это нужно понимать немного иначе: "Руководство, как правило, в состоянии продумать интерфейс для "железа", с ПО же всё меняется местами".

Я прав?

Сергей-4030>>и не так сильно зависишь от ошибок/изменениях в третьих модулях. Интерфейс практически не меняется никогда.
anybody> И это нужно понимать немного иначе: "Руководство, как правило, в состоянии продумать интерфейс для "железа", с ПО же всё меняется местами".
anybody> Я прав?

Нет. Просто когда нужны новые фичи для железа, их реализуют программно, через попу, а уж потом, когда все обкаталось и более-менее понятны requirements, их переносят в железо - если эффективности программного решения не хватает. А в софте requirements меняются чаще. И это, между прочим, объективный процесс. Вы извините, но когда вы говорите "не в состоянии продумать интерфейс" - это фигня. Методом waterfall'а решать сложные задачи нельзя. Вы можете как угодно относиться к глупым архитекторам, которые по недообразованию не способны сделать элементарнейшую вещь - идеальный дизайн - и отдать его на реализацию, но на практике это ничего не изменит. Так сделать просто нельзя. Теоретически - можно, практически - в мозгах человека не уместится. Потому и только потому и существует RUP. А если вы можете сделать сначала идеальные требования к системе, потом идеальный дизайн, потом идеальную имплементацию (про тестированию не говорю, потому что в идеальном случае оно не нужно) и на каждом шаге у вас будет все хорошо и прекрасно и не придется возвращаться и менять - в reqs, в дизайне - то вам прямая дорога в Майкрософт, или в любую другую крупную софтверную компанию. Там вам, между прочим, заплятят мильон.

Сергей-4030>Просто когда нужны новые фичи для железа, их реализуют программно, через попу, а уж потом, когда все обкаталось и более-менее понятны requirements, их переносят в железо - если эффективности программного решения не хватает.

Это ответ на все высказывания au. Простой и понятный. Идём дальше.

Сергей-4030>А в софте requirements меняются чаще. И это, между прочим, объективный процесс. Вы извините, но когда вы говорите "не в состоянии продумать интерфейс" - это фигня.

Попридержите лошадей! Мы не в "Политическом" разделе. Надеюсь, договорились.

Сергей-4030>Методом waterfall'а решать сложные задачи нельзя.

Опишите более подробно "метод waterfall-а", пожалуйста. Сдаётся мне, вы взяли на себя роль Папы римского, произнося азбучные истины с воображаемой высокой трибуны, или узрели и развили совершенно новый подход в управлении. Покорно жду более подробного описания "метод waterfall-а".

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

Как уже было сказано мною выше, лошади с такой скоростью вас долго нести не смогут. Пожалейте животинку!

Вы перескочили с уровня исполнения на уровень управления. Я же пытался разобраться в трудностях на уровне исполнения. Вернитесь с небес на землю.

Сергей-4030>Так сделать просто нельзя. Теоретически - можно, практически - в мозгах человека не уместится.

Вы есть Папа римский?

Сергей-4030>Потому и только потому и существует RUP.

Много что существует по причине ограниченности человеческих возможностей. Например, самолёты.

Сергей-4030>А если вы можете сделать сначала идеальные требования... идеальный дизайн... идеальную имплементацию... то вам прямая дорога в Майкрософт... Там вам, между прочим, заплятят мильон.

Знаете, я давно уже отвык мечтать о недостижимом...

anybody> Опишите более подробно "метод waterfall-а", пожалуйста. Сдаётся мне, вы взяли на себя роль Папы римского, произнося азбучные истины с воображаемой высокой трибуны, или узрели и развили совершенно новый подход в управлении. Покорно жду более подробного описания "метод waterfall-а".

В компьютерной литературе словосочетание вполне устоявшееся, что вам не нравится? Значит следующее - вырабатываем все requirements, потом дизайним систему, потом имплементируем, потом тестируем - и все, готовый продукт. На практике схема непригодна к использованию, поэтому текущий взгляд на разработку такой - последовательность этих водопадов aka итераций. Т.е. на n-ной итерации правим reqs, правим/добавляем дизайн, имплементируем изменения/добавления, тестируем, получаем начало итерации n+1. В какой-то момент итерация становится альфой, потом бетой, потом релизом и т.п. и т.д. Схема не идеальная, ибо, например, первая итерация всегда имеет свойство быть много сложнее и протяженнее по времени, чем вторая. Но на практике все сейчас работают именно так.

Mishka> Поэтому в софтовой индустрии сейчас развивают по спирали — с обратной связью, с прототипами, пробами, редезайном и респецификацией.
Знаешь, но в железе то же самое... Нельзя сделать последовательно. Не получится. Потому как надо начать, а потом увидеть, как пойдёт и где что править. Хотя в рамках ТЗ надо держаться обязательно, но они позволяют, как правило довольно широкие трактования.

Mishka>> Поэтому в софтовой индустрии сейчас развивают по спирали — с обратной связью, с прототипами, пробами, редезайном и респецификацией.
Серокой> Знаешь, но в железе то же самое... Нельзя сделать последовательно. Не получится. Потому как надо начать, а потом увидеть, как пойдёт и где что править. Хотя в рамках ТЗ надо держаться обязательно, но они позволяют, как правило довольно широкие трактования.

Конечно. Но итерации в железе обычно длиннее, а спецификации все-таки меняются реже.