Jump to content

    
Sign in to follow this  
AndyBig

Сколько стоит разработка ПО для микроконтроллеров?

Recommended Posts

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

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

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

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

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

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

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

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

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

 

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

 

Share this post


Link to post
Share on other sites
2 hours ago, AndyBig said:

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

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

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

Share this post


Link to post
Share on other sites
6 hours ago, aaarrr said:

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

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

Share this post


Link to post
Share on other sites
11 hours ago, AndyBig said:

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

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

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

Share this post


Link to post
Share on other sites
13 minutes ago, AlexandrY said:

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

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

Share this post


Link to post
Share on other sites
7 минут назад, AndyBig сказал:

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

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

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

Share this post


Link to post
Share on other sites
24 minutes ago, AndyBig said:

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

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

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

9 minutes ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites
12 часов назад, AndyBig сказал:

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

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

Цитата

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

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

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

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

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

Share this post


Link to post
Share on other sites
10 минут назад, AlexandrY сказал:

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

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

Share this post


Link to post
Share on other sites
2 minutes ago, jcxz said:

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

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

5 minutes ago, AlexandrY said:

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

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

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

 

Share this post


Link to post
Share on other sites
1 минуту назад, AndyBig сказал:

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

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

Share this post


Link to post
Share on other sites
2 minutes ago, AndyBig said:

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

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

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

Share this post


Link to post
Share on other sites
9 minutes ago, jcxz said:

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

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

12 minutes ago, jcxz said:

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

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

14 minutes ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites
3 minutes ago, AndyBig said:

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

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this