От Hokum
К Claus
Дата 31.01.2012 16:30:42
Рубрики Современность; Космос;

Именно так

В любом нормально организованном проекте ошибка и даже злой умысел одного исполнителя не ведут ни к провалу, ни даже к заметному смещению сроков. Все прекрасно отлавливается на этапе тестирования. И отвечают за организацию процесса люди, что малость повыше простого кодера. А на самые нижние позиции можно хоть индусов нанимать - при правильно построенном процессе будут работать не хуже прочих.
От Лейтенант
К Hokum (31.01.2012 16:30:42)
Дата 01.02.2012 00:11:09

Re: Именно так

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

Это заблуждение. Правильно построенный процесс предьявляет определенные требования к персоналу и при невыполнении этих требований првильный результат выдавать не будет. Любых индусов нанимать не получиться, только годных. Годные индусы есть, но они в общем случае не дешевле, чем годные не индусы.
От Hokum
К Лейтенант (01.02.2012 00:11:09)
Дата 01.02.2012 04:03:23

Re: Именно так

Правильно построенный процесс позволяет очень быстро отфильтровать неправильный персонал и заменить его правильным :)
Большинство низовых специалистов приходят в проект с улицы, через рекрутинговое агентство или аутсорсиногвую компанию. В ходе грамотно построенного интервью можно получить хорошее представление о человеке, но гарантию дает только страховой полис. И замена части персонала с формулировкой "не тянет" - абсолютно нормальное явление.
От Лейтенант
К Hokum (01.02.2012 04:03:23)
Дата 01.02.2012 08:59:09

Re: Именно так

>Правильно построенный процесс позволяет очень быстро отфильтровать неправильный персонал и заменить его правильным :)
> И замена части персонала с формулировкой "не тянет" - абсолютно нормальное явление.

Именно так. Но если "заменить правильным" нет возможности (например финансовой), то процесс работать не будет.
От Василий Фофанов
К Hokum (31.01.2012 16:30:42)
Дата 31.01.2012 23:53:29

Re: Именно так

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

Так ведь нормально организованный проект включает в себя и нормально организованную кадровую политику :)

> Все прекрасно отлавливается на этапе тестирования.

Странно. А меня учили что обнаружение дефекта на этапе тестирования - это вероятностностное событие. Уже отменили? А уж злой умысел установить тестированием - это вообще наив полный. Технология тестирования в организации секретная что ли? Злоумышленик доступа не имеет? :)

> И отвечают за организацию процесса люди, что малость повыше простого кодера.

А если злоумышленик - кодер непростой, только прикидывается - как тогда? ;)

> А на самые нижние позиции можно хоть индусов нанимать - при правильно построенном процессе будут работать не хуже прочих.

Какой-то расизм. Что значит "хоть индусов"? Там как и везде в мире люди разные, при правильно построенном процессе не из говна конфета получается, а просто говно для изготовление конфет не используется ;)
От Hokum
К Василий Фофанов (31.01.2012 23:53:29)
Дата 01.02.2012 03:57:09

Re: Именно так

>Странно. А меня учили что обнаружение дефекта на этапе тестирования - это вероятностностное событие. Уже отменили? А уж злой умысел установить тестированием - это вообще наив полный. Технология тестирования в организации секретная что ли? Злоумышленик доступа не имеет? :)

Тестирование в IT несколько отличается от ОТК на производстве. Представьте, что у Вас 100% деталей проходят разрушающий контроль - будет хорошая аналогия. Информация - не железо, система может быть скопирована сколько угодно раз и подвержена любым издевательствам. Тестируются абсолютно все процессы во всем диапазоне параметров с достаточно небольшим шагом. Не руками, понятно, а специальным софтом, что подороже компьютера раз в несколько. Кстати, в серьезных конторах штат тестеров превышает штат разработчиков в полтора-два раза.

>Какой-то расизм. Что значит "хоть индусов"?

В IT понятие "индусский программист" имеет свой сакральный смысл :))
От writer123
К Hokum (01.02.2012 03:57:09)
Дата 01.02.2012 17:45:05

Re: Именно так

>Тестирование в IT несколько отличается от ОТК на производстве. Представьте, что у Вас 100% деталей проходят разрушающий контроль - будет хорошая аналогия. Информация - не железо, система может быть скопирована сколько угодно раз и подвержена любым издевательствам. Тестируются абсолютно все процессы во всем диапазоне параметров с достаточно небольшим шагом. Не руками, понятно, а специальным софтом, что подороже компьютера раз в несколько. Кстати, в серьезных конторах штат тестеров превышает штат разработчиков в полтора-два раза.
Вера в чудодейственную силу автотестов, на которую сейчас повесеместная мода меня просто убивает. Да не сможете вы никакой 100% контроль провести ни при каких обстоятельствах, это утопия. Вы можете порубить систему на куски и оттестировать их тривиальными лобовыми тестами (по сути - на соответствие спецификации, а не на несоответствие ей) в статике - но у вас сложная динамическая система и вы никогда и никакими разумными автотестами не покроете её комплексное функционирование во времени и во всей совокупности составных частей.
Имхо автоматизированное тестирование позволяет более-менее надёжно судить только об отсутствии регресса в уже проверенной функциональности. Никаких других выводов с высокой точностью сделать оно не позволяет.
А для программно-аппаратных вещей всё вообще втройне сложно, потому как даже просто целостная эмуляция воздействий весьма затруднена.
Межпланетная станция - не CMSка на PHP, у которой вся работа сводится к модели "показал формочку->обработал формочку".
От Василий Фофанов
К Hokum (01.02.2012 03:57:09)
Дата 01.02.2012 13:47:46

Re: Именно так

>Тестирование в IT несколько отличается от ОТК на производстве. Представьте, что у Вас 100% деталей проходят разрушающий контроль - будет хорошая аналогия. Информация - не железо, система может быть скопирована сколько угодно раз и подвержена любым издевательствам. Тестируются абсолютно все процессы во всем диапазоне параметров с достаточно небольшим шагом. Не руками, понятно, а специальным софтом, что подороже компьютера раз в несколько.

Ж8-)))) Спасибо, буду знать теперь!!!!!! Два только вопроса - "диапазон параметров с небольшим шагом" - он от минус бесконечности до плюс бесконечности, или меньше? ;) И еще - а у скольких параметров у нас такой диапазон? Один... два... 75... 100500? Как там с комбинаторной сложностью, не возникает проблем?

> Кстати, в серьезных конторах штат тестеров превышает штат разработчиков в полтора-два раза.

Всего в полтора-два раза? И это при таких амбициях как выше?! Боюсь если бы штат был в полторы-две СОТНИ раз больше, и то не справлялись бы люди :)

>>Какой-то расизм. Что значит "хоть индусов"?
>
>В IT понятие "индусский программист" имеет свой сакральный смысл :))

В IT вообще удивительно много суеверий и предубеждений. Но статистика не подтверждает. В частности в математике и логике индийские программисты превосходят американских. В целом как я уже сказал это вопрос кадровой политики а не расового профайлинга.
От Claus
К Hokum (01.02.2012 03:57:09)
Дата 01.02.2012 10:39:15

Re: Именно так

>Тестируются абсолютно все процессы во всем диапазоне параметров с достаточно небольшим шагом. Не руками, понятно, а специальным софтом, что подороже компьютера раз в несколько. Кстати, в серьезных конторах штат тестеров превышает штат разработчиков в полтора-два раза.
Вообще то сложную систему, с большим количеством цепочек решений Вы за разумное время таким образом не протестируете. И в такой ситуации как раз могут применяться методы тестирования обеспечивающие определенную вероятность отсутствия ошибки, а не 100%.
От alexio
К Claus (01.02.2012 10:39:15)
Дата 01.02.2012 11:33:50

Re: Именно так

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

Ну не весть какие сложные алгоритмы у этого Ф-Г. Подозреваю достаточно тривиальную модель поведения. Соответственно - тривиальная проверяющая софтина.
От Iva
К alexio (01.02.2012 11:33:50)
Дата 01.02.2012 18:04:20

Там одна целочисленная математика чего стоит :-( (-)
От Claus
К alexio (01.02.2012 11:33:50)
Дата 01.02.2012 12:01:27

Re: Именно так

>Ну не весть какие сложные алгоритмы у этого Ф-Г. Подозреваю достаточно тривиальную модель поведения. Соответственно - тривиальная проверяющая софтина.
Здесь сложно сказать - надо ведь точно знать какие у него функции.
Но по любому, уж такие вещи как включение двигателей и т.п. по любому должно быть тестированием охвачено.
От Василий Фофанов
К Claus (01.02.2012 12:01:27)
Дата 01.02.2012 13:53:48

Re: Именно так

>Но по любому, уж такие вещи как включение двигателей и т.п. по любому должно быть тестированием охвачено.

А кто сказал что не было охвачено их включение? Проблема то в том что команда на их включение не поступила :) И вообще, этот самый БВК мог быть оттестирован вдоль и поперек "с достаточно небольшим шагом" - но вот что оттого толку если он выключился :) Весь оттестированный софт успешно свалился в Тихий океан не показав себя в деле.
От Claus
К Василий Фофанов (01.02.2012 13:53:48)
Дата 01.02.2012 14:35:54

Re: Именно так

>А кто сказал что не было охвачено их включение? Проблема то в том что команда на их включение не поступила :) И вообще, этот самый БВК мог быть оттестирован вдоль и поперек "с достаточно небольшим шагом" - но вот что оттого толку если он выключился :) Весь оттестированный софт успешно свалился в Тихий океан не показав себя в деле.
Так ведь и сам факт поступления команды на включение относится к ключевым функциям. И тестироваться точно так же должен.
Все ж таки, при нормально организованном тестировании, получить результат, когда система не запускается вообще, довольно сложно.

А вот если там второпях, в последний момент, что то подкрутили, то очень даже вероятно.
От Василий Фофанов
К Claus (01.02.2012 14:35:54)
Дата 01.02.2012 14:53:03

Re: Именно так

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

Проблема-то в том что система функционировала в нештатных условиях похоже. Чтобы такое тестированием по спецификациям ловить, нештатные условия должны быть предусмотрены штатно ;)

>А вот если там второпях, в последний момент, что то подкрутили, то очень даже вероятно.

Это один из вариантов, бесспорно. Но коли вы допускаете возможность такого грубого нарушения технологии разработки программно-аппаратного комплекса на этом этапе, следует допускать эту возможность и на всех остальных этапах. Разницы то ведь нет особой.
От Cyril-69
К Василий Фофанов (01.02.2012 13:53:48)
Дата 01.02.2012 14:12:54

ну тогда это не "ошибка программистов" (-)
От Василий Фофанов
К Cyril-69 (01.02.2012 14:12:54)
Дата 01.02.2012 14:49:35

Что угодно может быть, надо подробный отчет комиссии смотреть

...а не напев Каррузо Рабиновичем.

Формулировка "ошибка программистов" в любом случае не корректна, потому что ошибка могла быть на любом этапе разработки аппаратно-программного комплекса, а не только на этапе собственно кодирования. В частности был ли останов БВК после его аварийной перезагрузки предусмотрен спецификацией? Если да - то вуаля, возможно тут и первичная ошибка, и понятно что никакая реализация ошибочной спецификации, и никакая тщательность тестирования этой реализации, исходную ошибку исправить не может, ее можно исправить только случайно допустив компенсирующую ошибку где-то еще ;)