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

 
1 2 3 4 5 6 7 8
US Сергей-4030 #08.05.2008 21:22  @Дем#08.05.2008 21:06
+
-
edit
 

Сергей-4030

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

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

au

   
★★☆
Граждане, давайте с параллельным с отдельную тему в компутерном. Тут всё же о грустном [читаем тему]. Последние записи здесь перенесу туда.
 
+
-
edit
 

timochka

опытный

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

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

Из типичной проги на МСБасике придется выкинуть ВСЕ глобальные объекты, либо все думать про синхронизацию. Сейчас что на VB не попадется - везде куча глобальных объектов. Собственно все VB наследство останется непараллелизируемым.
 
au: П. 11 оффтоп после предупреждения; предупреждение (+1)

pokos

аксакал



NASA потеряло связь с марсоходом "Феникс"


NASA потеряло связь с марсоходом Феникс. Выполнение задач, запланированных на второй день нахождения на Марсе американского космического аппарата Феникс, отложено из-за возникших неполадок, ...

// top.rbc.ru
 
 
+
-
edit
 

Mishka

модератор
★★★

Phoenix Mars Mission - Home — вот центр миссии. Это был momentary glitch. Связь была тут же восстановлена. Да. И глюк был не софтовый. :P

Не читайте советских газет. :F
 

pokos

аксакал

Ф-ф-ф-фуууу, гора с плеч.
 
BG Реконструктор #30.05.2008 13:32
+
-
edit
 
Пока для таких проектов нанимают индийских студентов, практикантов java, ничего не изменится.
 
RU Владимир Малюх #31.05.2008 11:58
+
-
edit
 
А кого как не студентов привлекать к университетскому проекту? %) Тем более что проблема совсем не с ПО...
Maschinen muessen "idiotensicher" werden  
Это сообщение редактировалось 02.06.2008 в 10:39
BG Реконструктор #02.06.2008 10:24
+
-
edit
 
Не думаю, что Mars Global Surveyor это студентский проект.
 
+
-
edit
 

Mishka

модератор
★★★

В том числе и студенческий.
 
+
-
edit
 

anybody

координатор

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

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

anybody

координатор

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

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

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

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

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

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

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

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

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

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

anybody

координатор

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

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

anybody

координатор

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

А чем проще с "железными проектами"? Там не так сильно за сроки спрашивают? Иные причины?
 
US Сергей-4030 #03.06.2008 18:27  @anybody#03.06.2008 17:46
+
-
edit
 

Сергей-4030

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

Там цикл разработки дольше и не так сильно зависишь от ошибок/изменениях в третьих модулях. Интерфейс практически не меняется никогда.
 
US Сергей-4030 #03.06.2008 18:33  @anybody#03.06.2008 17:15
+
-
edit
 

Сергей-4030

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

Инженерия, как и политика, есть исскусство возможного. Сделать все идеально иногда можно, но почти всегда очень дорого и долго. Поэтому обычно делают так, чтоб выполнение такой-то конкретной задачи было достаточно вероятным в принятые сроки. Иногда можно добиться этой вероятности в 99.9999999999% за небольшие деньги. А иногда и 50% вероятности таких ресурсов требует, что лучше добиться 25% вероятности выполнения, но зато в десять раз дешевле.
 
RU anybody #03.06.2008 19:05  @Сергей-4030#03.06.2008 18:27
+
-
edit
 

anybody

координатор

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

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

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

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

Я прав?
 
US Сергей-4030 #03.06.2008 19:26  @anybody#03.06.2008 19:05
+
-
edit
 

Сергей-4030

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

Нет. Просто когда нужны новые фичи для железа, их реализуют программно, через попу, а уж потом, когда все обкаталось и более-менее понятны requirements, их переносят в железо - если эффективности программного решения не хватает. А в софте requirements меняются чаще. И это, между прочим, объективный процесс. Вы извините, но когда вы говорите "не в состоянии продумать интерфейс" - это фигня. Методом waterfall'а решать сложные задачи нельзя. Вы можете как угодно относиться к глупым архитекторам, которые по недообразованию не способны сделать элементарнейшую вещь - идеальный дизайн - и отдать его на реализацию, но на практике это ничего не изменит. Так сделать просто нельзя. Теоретически - можно, практически - в мозгах человека не уместится. Потому и только потому и существует RUP. А если вы можете сделать сначала идеальные требования к системе, потом идеальный дизайн, потом идеальную имплементацию (про тестированию не говорю, потому что в идеальном случае оно не нужно) и на каждом шаге у вас будет все хорошо и прекрасно и не придется возвращаться и менять - в reqs, в дизайне - то вам прямая дорога в Майкрософт, или в любую другую крупную софтверную компанию. Там вам, между прочим, заплятят мильон.
 
RU anybody #03.06.2008 19:39  @Сергей-4030#03.06.2008 19:26
+
-
edit
 

anybody

координатор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знаете, я давно уже отвык мечтать о недостижимом... :rolleyes:
 
US Сергей-4030 #03.06.2008 19:57  @anybody#03.06.2008 19:39
+
-
edit
 

Сергей-4030

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

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

Mishka

модератор
★★★

waterfall — это когда каждая стадия следует за другой и нет возможности вернуться назад (дешёвой — можно, конечно, с 0 всё сделать ещё раз). Т.е. вот мы сядем на год и продумаем спецификации, а потом сядем ещё на год и определим интерфейсы, а потом ещё на год и запрограммируем. В этой модели любая ошибка на предыдущей стадии очень дорого стоит. Поэтому в софтовой индустрии сейчас развивают по спирали — с обратной связью, с прототипами, пробами, редезайном и респецификацией.
 
RU Серокой #03.06.2008 20:00  @Mishka#03.06.2008 19:57
+
-
edit
 

Серокой

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

Mishka

модератор
★★★

И в железе есть. И смена спецификаций, а значит всего то же в железо уже пробирается. :(
 
+
-
edit
 

anybody

координатор

админ. бан
Благодарю!

Поясню причину моего вопроса: терминология есть вещь крайне запутанная, изобилующая неожиданностями. Вот я и решил лишний раз спросить.

**************************************
И всё-таки, почему управлять "железными проектами" проще, чем программными? :) Пока что, из разговора с Сергеем, ответ у меня получается где-то такой ответ: "Потому что руководство выделяет на такие задачи приемлемое время и наряд сил". Иными словами: "Потому что руководство не умеет правильно расчитывать потребные время и силы на выполнение задач создания и доработки ПО". Так это? Или нет?
 
US Сергей-4030 #03.06.2008 20:05  @Серокой#03.06.2008 20:00
+
-
edit
 

Сергей-4030

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

Конечно. Но итерации в железе обычно длиннее, а спецификации все-таки меняются реже.
 
1 2 3 4 5 6 7 8

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru