[iosifk 3]

25 минут назад, AndyBig сказал:

Особенно iosifk за несколько дельных мыслей и советов в разговоре по скайпу :)

Чтобы никто не обижался за "сокрытие идей"... :) Вот что обсуждалось:

1. Написание ПО для входного тестирования железа как на столе, так и на объекте. Это надо сделать, так сказать "до того как...", чтобы не было претензий. 

2. ПО должно содержать возможность прочесть состояние всех входов и выходов железа в "сыром виде, т.е. без обработки", причем как локально, так и удаленно.

3. Логгирование всех возможных параметров. Напряжение, температура и пр...

4. Логгирование поведения софта в рабочем режиме...

5. Сопровождение и оказание тех.помощи.

6. Доработки по результатам испытаний и по замечаниям заказчика...

 

Просто буквами это долго, ну а кто захочет услышать - обращайтесь... 

 

[aaarrr 63]

2 hours ago, AndyBig said:

Согласен, но думаю, что в случае глюков железа я смогу доказать что это глюки именно из-за железа.

Доказать - возможно. Но ведь Вам нужно не доказать, а получить 100% оплаты за 100% работы, а не 50% за 120% (вместе с доказательствами).

Так что в договоре этот момент нужно учитывать в обязательном порядке.

[AndyBig 5]

6 hours ago, aaarrr said:

Но ведь Вам нужно не доказать, а получить 100% оплаты за 100% работы, а не 50% за 120%

С одной стороны - да, но с другой стороны у заказчика тоже ведь цель (я надеюсь) - получить в разумные сроки результат, а не только его демонстрацию. А результат он не получит пока не оплатит его :)

[AlexandrY 2]

11 hours ago, AndyBig said:

Согласен, но думаю, что в случае глюков железа я смогу доказать что это глюки именно из-за железа.

Хм, звучит наивно. 
Помню случай как я два года доказывал глюки железа в подобном дивайсе.
Заказчик вправе ожидать от программиста мер по улучшению кондиции сигналов и помехоустойчивости. 
Доказать что программными средствами никак нельзя улучшить качество сигналов неимоверно трудная задача, особенно если у заказчика есть более дорогой и более качественный образец аналогичного устройства и никакого специального оборудования. 
Со сбоями при работе GSM тож веселая тема. Это идеальное место для взаимных выяснений кто накосячил между железячниками и програмистами.

Мой прогноз - проект на полгода, год. С головной болью еще года на два. 
 

[AndyBig 5]

13 minutes ago, AlexandrY said:

Хм, звучит наивно. 

Да, согласен, этот вопрос довольно скользкий. Тем не менее, на мой взгляд, если девайс работает без сбоев на столе, в тепличных условиях, когда выходы датчиков укладываются в оговоренные пределы, питание не прыгает, температура не -30 и не +70 и т.п., то это уже показывает работоспособность софта. Если, например, при температуре минус 30 перестает работать кварц или питание падает ниже предела, или с датчиков начинает сыпаться фигня - ну, это уже явно проблемы не прошивки. Я, конечно, могу заняться еще и оптимизацией железа под конкретные условия, но это уже отдельная задача :)

[jcxz 184]

7 минут назад, AndyBig сказал:

Тем не менее, на мой взгляд, если девайс работает без сбоев на столе, в тепличных условиях, когда выходы датчиков укладываются в оговоренные пределы, питание не прыгает, температура не -30 и не +70 и т.п., то это уже показывает работоспособность софта.

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

Не случайно, как этап отладки устройств, придумана опытная эксплуатация устройств на объектах. Никакие ваши испытания "на столе" ни о какой работоспособности устройства в боевых условиях не говорят.

[AlexandrY 2]

24 minutes ago, AndyBig said:

 или с датчиков начинает сыпаться фигня - ну, это уже явно проблемы не прошивки. 

В этом вся шутка. Да это не проблема прошивки - это ее задача. 
Но она не ставится в ТЗ поскольку заказчик не знает что может случится с датчиков.  
Критерием будет только - "а вот у других работает".
Тут потеха и начнется. Вы против R&D контор которые на этом собаку съели. 

Заказчики склонны упрощать ТЗ, а исполнители сокращать заявленные сроки.  
 

9 minutes ago, jcxz said:

Не случайно, как этап отладки устройств, придумана опытная эксплуатация устройств на объектах. Никакие ваши испытания "на столе" ни о какой работоспособности устройства в боевых условиях не говорят.

Хуже то что в договоре не оговоришь сколько времени заказчик должен тестировать, это будет влезанием в его личные дела. 
А он может и год тестировать, а потом только расплатиться. 

[jcxz 184]

12 часов назад, AndyBig сказал:

Согласен, но думаю, что в случае глюков железа я смогу доказать что это глюки именно из-за железа.

Не факт. Ведь разработчик железа тоже так думает. И тут всё будет зависеть от того - кому больше доверяет заказчик. И если у него железячник сидит рядом и они общаются с ним "вась-вась", то у него в 100 раз больше шансов доказать заказчику свою правоту и повесить всех собак на вас.  

Цитата

Если бы не GSM-модем, я бы дней за 10 справился, включая обновление прошивки (по USB или UART) :) Но модем для меня - неизвестная переменная, поэтому предполагаю 4-5 недель...

С таким подходом - никогда не справитесь. Так как сначала нужно написать и согласовать ТЗ с заказчиком и железячником. А это уже займёт скорее всего больше 10 дней.

23 минуты назад, AndyBig сказал:

или с датчиков начинает сыпаться фигня - ну, это уже явно проблемы не прошивки.

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

[jcxz 184]

10 минут назад, AlexandrY сказал:

Хуже то что в договоре не говоришь сколько времени заказчик должен тестировать, это будет влезанием в его личные дела. 
А он может и год тестировать, а потом только расплатиться. 

Это вполне нормально прописывается в договоре. У меня был заказчик (удалённый), который производил опытную эксплуатацию полгода. И в течение всего этого времени наш договор продолжался, он регулярно платил мне деньги, а я в свою очередь консультировал его тестировщиков по возникающим вопросам и корректировал технологическое ПО по мере необходимости. Тестирование - это точно такой же этап работы как и согласование ТЗ и сама разработка.

[AndyBig 5]

2 minutes ago, jcxz said:

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

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

5 minutes ago, AlexandrY said:

Но она не ставится в ТЗ поскольку заказчик не знает что может случится с датчиков.

Ну так ТЗ для того и составляется, чтобы потом не возникало непонятных претензий со стороны разработчика или заказчика :) Дополнительные работы за пределами ТЗ - это отдельная тема. Может быть я доделаю что-то сверх ТЗ просто по доброте душевной, а может быть на это будет отдельный договор со своим ТЗ.

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

 

[jcxz 184]

1 минуту назад, AndyBig сказал:

Но если изменилась температура -> поплыли показания датчиков, то это уже не ко мне :)

Если в результате этих плывущих показаний ваше ПО стало глючить - к Вам. Если ПО штатно обработало эту ситуацию - тогда всё ок.

[gosha-z 2]

Как-то в разговоре промелькнула фраза "Проблемы программистов схемотехников не волнуют"...

[AlexandrY 2]

2 minutes ago, AndyBig said:

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

В свое время я с заказчиком спорил о свойствах нормального распределения.
Он утверждал что програма, а вернее мой ADC неправильно настроен и вносит нехарактерный шум в данные.
Чисто схоластический спор на ровном месте, закончившийся неудовлетворенностью обеих сторон, но  я был вынужден изучать всю физику его датчиков.    

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

[AndyBig 5]

9 minutes ago, jcxz said:

если у него железячник сидит рядом и они общаются с ним "вась-вась", то у него в 100 раз больше шансов доказать заказчику свою правоту и повесить всех собак на вас.  

Ну опять же - я предполагаю, что заказчику нужен результат, а не козел отпущения с потерей месяца-двух, то есть он будет заинтересован в том, чтобы девайс работал, а не в том, чтобы найти виновного. Если возникнет ситуация, в которой недостатки железа начинают вешаться на меня - я просто разорву договор, не взяв оплаты и не отдав имеющиеся наработки. У меня есть источник дохода, так что с голода я не помру :)

12 minutes ago, jcxz said:

сначала нужно написать и согласовать ТЗ с заказчиком и железячником. А это уже займёт скорее всего больше 10 дней.

Я ведь говорил о сроках непосредственно разработки, согласование ТЗ и договора в них не входят :)

14 minutes ago, jcxz said:

Если ПО начинает глючить когда "с датчиков начинает сыпаться фигня" это уже не ПО, а быдлокод

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

[AlexandrY 2]

3 minutes ago, AndyBig said:

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

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