Здравствуйте, BuildAll, Вы писали:
BA>Для небедной организации (Россия) необходимо сделать следующую программу. BA>Срок выполнения — 4 месяца. BA>Скажите, сколько такая работа будет стоить?
А "небедная организация" не может пойти к коммерческим компаниям, получить коммерческие предложения и не бомжить на RSDN?
Здравствуйте, landerhigh, Вы писали:
BA>>Имеется лаборатория, в которой около 40-ка разных контрольно-измерительных приборов, которые могут передавать результаты измерений в компьютер. Метод передачи — последовательные порты (преимущественно) или через промежуточную СУБД. В варианте с СУБД используется поставляемое с прибором ПО.
BA>>Срок выполнения — 4 месяца.
BA>>Скажите, сколько такая работа будет стоить?
L>Имея такую вводную, могу сказать, что нисколько. Ибо за 4 месяца это провернуть принципиально невозможно. Вариант, когда 4 месяца педалим код, а потом два года заставляем его работать, не рассматриваем.
Принципиально — возможно. И за $100К пара моих знакомых напишет искомое за 4 месяца с вероятностью, скажем, 80%. Ибо делала подобные вещи уже не раз. Все дело в наличии опыта. 80% — потому что я не знаю, что там за девайсы и протоколы.
L>С железом есть определенный прикол. Конечно, если повезет и весь интерфейс общения с прибором сводится к прослушиванию порта и записыванию в базу цифр, которые периодически приходят, то это еще не так страшно. Но если там используется специальный протокол, даже если он простейший, то все, сушите весла.
Если взять не осциллограф, а хороший логический анализатор, например, Tektronix TLA5202 и уметь использовать прилагаемое к нему ПО, то можно проделать очень много интересных штук с анализом неизвестных протоколов. Шифрованный протокол, разумеется, не вскрыть, но отделить заголовки от данных и набрать материал для анализа данных можно очень быстро. Хотя, конечно, какое-нибудь молодое дарование может, неизвестно зачем, встроить помехоустойчивое кодирование в протокол передачи по RS-232 и тогда придется сложнее. Но в любом случае, будет проще, чем с обычным сниффером порта.
>Если используется стандартный протокол, то тоже не сильно легче. Придется либо реализовывать протокол, либо покупать готовые либы. Последний вариант отпадает, если протокол велосипедный. Да и либы могут стоить многаденех и/или быть тем еще глюкалом.
L>Особенно весело, когда оказывается, что девайс не совсем следует собственному же протоколу и собственной документации, или в ночь на пятницу 16 в полнолуние начинает фигню нести. Еще бывает, что аффтары девайса сначала взяли стандартный протокол, а потом его "улучшили", в результате чего стандартные либы его понимать перестают.
Тот риск, о котором ты говоришь, называется стандартно — нечетко специфицированные требования. Реагируем на этот риск тоже стандартно, переносом этого риска на заказчика — перед подписанием договора составляется ТЗ и протоколы, известные на тот момент, идут к нему приложением. Если протокола нет — в цену либо включается обследование, либо данный прибор выносится за рамки контракта.
Все изменения протоколов — через допсоглашения. Набрался десяток изменений — подписывается допник с коррекцией цены и сроков, если заказчик отказывается подписывать — работаем по первоначальному ТЗ.
Оно понятно, что писать ТЗ — это бесплатная работа, но кто сказал, что риски устраняются бесплатно? Можно этот риск принять и надеяться, что все будет в порядке со спецификациями. Каждый сам делает свой выбор.
L>Потом, не забывайте, что весь этот фестиваль еще и тестировать придется. Запросто может оказаться, что понадобится в два раза больше тестеров, нежели разработчиков.
Ну..да. Но тестирование приемников данных — это сильно проще, чем тестирование АРМа или игрушки, комбинаций не так много. Можно включить в контракт поддержку 2 месяца и пусть заказчик сам тестирует в процессе Это ведь не массовый продукт, 24х7 поддержка не нужна.
Скорее, там будут проблемы с переносом продукта на другую машину, но и это можно зафиксировать в ТЗ — материнская плата такая-то, при переносе на другую конфигурацию работа продукта не гарантируется.
Здравствуйте, nvb, Вы писали:
BA>>>Скажите, сколько такая работа будет стоить?
L>>Имея такую вводную, могу сказать, что нисколько. Ибо за 4 месяца это провернуть принципиально невозможно. Вариант, когда 4 месяца педалим код, а потом два года заставляем его работать, не рассматриваем.
nvb>Принципиально — возможно. И за $100К пара моих знакомых напишет искомое за 4 месяца с вероятностью, скажем, 80%. Ибо делала подобные вещи уже не раз. Все дело в наличии опыта. 80% — потому что я не знаю, что там за девайсы и протоколы.
Не знаю насчет твоих знакомых, но я конкретно этим на жизнь зарабатываю. Немного в другом масштабе, правда. Это 80% вероятности имеют близкую к 100% вероятность выродиться означенное "пишем 4 месяца, отлаживаем 2 года". Не знаю, может быть в том конкретном случае это будет приемлимо, но конкретно мы пишем коробочный продукт и это совсем не вариант.
L>>С железом есть определенный прикол. Конечно, если повезет и весь интерфейс общения с прибором сводится к прослушиванию порта и записыванию в базу цифр, которые периодически приходят, то это еще не так страшно. Но если там используется специальный протокол, даже если он простейший, то все, сушите весла.
nvb>Если взять не осциллограф, а хороший логический анализатор, например, Tektronix TLA5202 и уметь использовать прилагаемое к нему ПО, то можно проделать очень много интересных штук с анализом неизвестных протоколов. Шифрованный протокол, разумеется, не вскрыть, но отделить заголовки от данных и набрать материал для анализа данных можно очень быстро. Хотя, конечно, какое-нибудь молодое дарование может, неизвестно зачем, встроить помехоустойчивое кодирование в протокол передачи по RS-232 и тогда придется сложнее. Но в любом случае, будет проще, чем с обычным сниффером порта.
И все это для 40 разных девайсов за 4 месяца?
L>>Особенно весело, когда оказывается, что девайс не совсем следует собственному же протоколу и собственной документации, или в ночь на пятницу 16 в полнолуние начинает фигню нести. Еще бывает, что аффтары девайса сначала взяли стандартный протокол, а потом его "улучшили", в результате чего стандартные либы его понимать перестают.
nvb>Тот риск, о котором ты говоришь, называется стандартно — нечетко специфицированные требования. Реагируем на этот риск тоже стандартно, переносом этого риска на заказчика — перед подписанием договора составляется ТЗ и протоколы, известные на тот момент, идут к нему приложением. Если протокола нет — в цену либо включается обследование, либо данный прибор выносится за рамки контракта.
Очень вероятно, что выносить за рамки контракта тогда придется все девайсы. Вот, например, один из довольно интересный тип граблей, которые так любят оставлять разработчики железа и прошивок. Девайс имеет встроенные часы и умеет передавать лог событий на хост. Это все описано в документации, приведены все форматы и так далее — пиши не хочу. Написали, протестировали, все работает. Заказчик доволен, работа принята. Через пару недель возникает ситуация — пропадают события. Команда ловит багу долго, потому что в лаборатории баг никак не проявляется. В конце концов совершенно случайно выясняется, что иногда, в день высокого прилива на островах Фиджи, девайс в формате даты передает бред вроде "32 глюкабря 2045 года до нашей эры". Долгая возня с техподдержкой девайса (если такая есть) через месяц проясняет, что это он так сообщает о необходимости синхронизации часов. А в документации это отразить забыли. Ну бывает.
Такое веселье случается сплошь и рядом даже при 100% документированном, стандартном протоколе.
nvb>Все изменения протоколов — через допсоглашения. Набрался десяток изменений — подписывается допник с коррекцией цены и сроков, если заказчик отказывается подписывать — работаем по первоначальному ТЗ.
В таком случае один только ТЗ и его согласования займут больше, чем 4 месяца.
L>>Потом, не забывайте, что весь этот фестиваль еще и тестировать придется. Запросто может оказаться, что понадобится в два раза больше тестеров, нежели разработчиков.
nvb>Ну..да. Но тестирование приемников данных — это сильно проще, чем тестирование АРМа или игрушки, комбинаций не так много.
Ой. Остается только сказать, что мужики-то и не знают
Здравствуйте, landerhigh, Вы писали:
L>>>Имея такую вводную, могу сказать, что нисколько. Ибо за 4 месяца это провернуть принципиально невозможно. Вариант, когда 4 месяца педалим код, а потом два года заставляем его работать, не рассматриваем.
nvb>>Принципиально — возможно. И за $100К пара моих знакомых напишет искомое за 4 месяца с вероятностью, скажем, 80%. Ибо делала подобные вещи уже не раз. Все дело в наличии опыта. 80% — потому что я не знаю, что там за девайсы и протоколы.
L>Не знаю насчет твоих знакомых, но я конкретно этим на жизнь зарабатываю. Немного в другом масштабе, правда. Это 80% вероятности имеют близкую к 100% вероятность выродиться означенное "пишем 4 месяца, отлаживаем 2 года". Не знаю, может быть в том конкретном случае это будет приемлимо, но конкретно мы пишем коробочный продукт и это совсем не вариант.
Не знаю про ваши критерии качества, поэтому ничего сказать не могу. Но в то, что у вас не бывает апдейтов ПО — не верю (с)
L>>>С железом есть определенный прикол. Конечно, если повезет и весь интерфейс общения с прибором сводится к прослушиванию порта и записыванию в базу цифр, которые периодически приходят, то это еще не так страшно. Но если там используется специальный протокол, даже если он простейший, то все, сушите весла.
nvb>>Если взять не осциллограф, а хороший логический анализатор, например, Tektronix TLA5202 и уметь использовать прилагаемое к нему ПО, то можно проделать очень много интересных штук с анализом неизвестных протоколов. Шифрованный протокол, разумеется, не вскрыть, но отделить заголовки от данных и набрать материал для анализа данных можно очень быстро. Хотя, конечно, какое-нибудь молодое дарование может, неизвестно зачем, встроить помехоустойчивое кодирование в протокол передачи по RS-232 и тогда придется сложнее. Но в любом случае, будет проще, чем с обычным сниффером порта.
L>И все это для 40 разных девайсов за 4 месяца?
Я же сказал — я не знаю, что это за 40 девайсов. Кстати, я думаю, что они вряд ли сильно разные, если они стоят в одной лаборатории. Производителей наверняка не более десятка, а это упрощает ситуацию. Хотя, конечно, вспоминая свои попытки десятилетней давности получить по RS-232 скриншот с Tektronix TDS 1001 — да, сложностей может быть много
L>>>Особенно весело, когда оказывается, что девайс не совсем следует собственному же протоколу и собственной документации, или в ночь на пятницу 16 в полнолуние начинает фигню нести. Еще бывает, что аффтары девайса сначала взяли стандартный протокол, а потом его "улучшили", в результате чего стандартные либы его понимать перестают.
nvb>>Тот риск, о котором ты говоришь, называется стандартно — нечетко специфицированные требования. Реагируем на этот риск тоже стандартно, переносом этого риска на заказчика — перед подписанием договора составляется ТЗ и протоколы, известные на тот момент, идут к нему приложением. Если протокола нет — в цену либо включается обследование, либо данный прибор выносится за рамки контракта.
L>Очень вероятно, что выносить за рамки контракта тогда придется все девайсы. Вот, например, один из довольно интересный тип граблей, которые так любят оставлять разработчики железа и прошивок. Девайс имеет встроенные часы и умеет передавать лог событий на хост. Это все описано в документации, приведены все форматы и так далее — пиши не хочу. Написали, протестировали, все работает. Заказчик доволен, работа принята. Через пару недель возникает ситуация — пропадают события. Команда ловит багу долго, потому что в лаборатории баг никак не проявляется. В конце концов совершенно случайно выясняется, что иногда, в день высокого прилива на островах Фиджи, девайс в формате даты передает бред вроде "32 глюкабря 2045 года до нашей эры". Долгая возня с техподдержкой девайса (если такая есть) через месяц проясняет, что это он так сообщает о необходимости синхронизации часов. А в документации это отразить забыли. Ну бывает.
L>Такое веселье случается сплошь и рядом даже при 100% документированном, стандартном протоколе.
Это достаточно распространенная проблема, которая достигает своего апогея в случае передачи данных измерений по ненадежному радиоканалу. CRC контроль здесь не всегда помогает, поскольку, например, в диапазоне 2,4ГГц в принятом пакете может быть все, что угодно — даже при совпавшем CRC, wi-fi — это неиссякаемый источник помех. Поэтому используются дополнительные методы контроля — например, в случае соединения точка-точка ясно, что временные метки и номера пакетов должны инкрементироваться в следующем пакете, а если это не так, или инкремент слишком велик, то имеем глюк или помеху. То же самое и с учетом полосы пропускания прибора — если два соседних значения напряжения расположены (пример) в верхней и нижней части шкалы, то это либо помеха, либо глюк ПО прибора. То же самое для значений напряжения питающей батарей — не может оно быть равным 0,5В, поскольку передатчик работает выше 1,9В. Ну и так далее.
Соответственно, перед тем, как попасть на индикаторы, значения проходят через все эти фильтры, и если они ловят глюк — значение пишется в лог и не выводится, при этом оно может быть обрамлено временными метками с РС, значениями до и после, и т.п. Все это у заказчика, в реальных условиях, без присутствия разработчиков. А потом логи забираются и смотрятся на предмет странностей — раз в неделю, даже ехать необязательно, пришлют по почте. И если попадается повторяющаяся странность — тут надо разбираться, с производителем переписываться, при этом на руках имеется "доказательная база" — просто так послать производитель уже не может. Торчать у заказчика для этого неделями совсем не обязательно, это делается в фоновом режиме.
nvb>>Все изменения протоколов — через допсоглашения. Набрался десяток изменений — подписывается допник с коррекцией цены и сроков, если заказчик отказывается подписывать — работаем по первоначальному ТЗ.
L>В таком случае один только ТЗ и его согласования займут больше, чем 4 месяца.
Ты выбросил чересчур много из моего текста. Спецификации на протоколы передачи имеют одно хорошее свойство — либо они есть в данный момент, либо их нет.
Никто же не мешает, например, разбить работу на 3-4 этапа с оплатой после каждого — на первом делается известное (протоколы есть и они понятны), на втором — известное неизвестное (протоколов сейчас нет, но понятно, что будут к началу работ по этому этапу) и на третьем — неизвестное неизвестное (протоколов нет, и где взять — непонятно). Естественно, если в первом этапе цена 1 прибора — Х, то в третьем — 10Х. Соответственно, в интересах заказчика становится быстрей нарыть всю документацию, что у него есть и перенести возможно больше приборов на первый этап. Все прозрачно, никто не в обиде.
А если заказчик не хочет возиться с ТЗ и предпочитает переносить риски на исполнителя — ну что ж, это повод задуматься о том, стоит ли иметь с ним дело.
Здравствуйте, nvb, Вы писали:
nvb>Не знаю про ваши критерии качества, поэтому ничего сказать не могу. Но в то, что у вас не бывает апдейтов ПО — не верю (с)
Наши криетрии качества относят желание поиметь 40 девайсов через 4 месяца в категорию "you must be dreaming".
L>>И все это для 40 разных девайсов за 4 месяца?
L>>>>Особенно весело, когда оказывается, что девайс не совсем следует собственному же протоколу и собственной документации, или в ночь на пятницу 16 в полнолуние начинает фигню нести. Еще бывает, что аффтары девайса сначала взяли стандартный протокол, а потом его "улучшили", в результате чего стандартные либы его понимать перестают.
nvb>>>Тот риск, о котором ты говоришь, называется стандартно — нечетко специфицированные требования. Реагируем на этот риск тоже стандартно, переносом этого риска на заказчика — перед подписанием договора составляется ТЗ и протоколы, известные на тот момент, идут к нему приложением. Если протокола нет — в цену либо включается обследование, либо данный прибор выносится за рамки контракта.
Еще раз — по спецификации девайс 100% поддерживает протокол А. При реализации или тестировании, месяце так на четвертом, вдруг выясняется, что реализация протокола в девайсе своеобразная.
L>>Такое веселье случается сплошь и рядом даже при 100% документированном, стандартном протоколе.
nvb>Это достаточно распространенная проблема, которая достигает своего апогея в случае передачи данных измерений по ненадежному радиоканалу. CRC контроль здесь не всегда помогает, поскольку, например, в диапазоне 2,4ГГц в принятом пакете может быть все,
Ты прочитал мое сообщение по диагонали. Это не ошибка и не потерянный пакет и не шум на линии. Девайс специально шлет мусор, чтобы на что-то пожаловаться. А в мануале это отразить "забыли". Бывает. Вы не знали, клиент не знал, зачастую даже разработчик девайса тоже забыл. В итоге клиент будет несколько обескуражен.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, BuildAll, Вы писали:
BA>>Скажите, сколько такая работа будет стоить?
UA>Допустим 1 человек сумеет качественно разрулить 1 прибор в месяц
Мой опыт показывает что 1 человек сумеет качественно разрулить 1 прибор в день если документация в порядке.
UA>= так как есть 4 месяца в запасе = имеем 10 человек только на одни приборы. + 3 человека на унификацию интерфейса (один из них архитект (строит архитектуру и общается с заказчиком) и 2 лида которые будут педалить код унификации и паралельно смотреть за людьми которые педалят приборы и фиксить проблемы взаимодействия) + 3 тестера + 1 человек на деплоймент. Итого: 17 человек * 100 тыс. рублей * 4 месяца = 6.8 млн. рублей + риски + надо что заработать = порядка 15 миллионов.
17 человек на такой проект? не дофига ли? 17 технарей выльется еще в десяток управленцев и обслуживающего состава...
Итого примерно 25 человек на 4 месяца кормить, несколько миллионов только на ЗП персоналу уйдет.
Здравствуйте, BuildAll, Вы писали:
BA>Для небедной организации (Россия) необходимо сделать следующую программу.
BA>Имеется лаборатория, в которой около 40-ка разных контрольно-измерительных приборов, которые могут передавать результаты измерений в компьютер. Метод передачи — последовательные порты (преимущественно) или через промежуточную СУБД. В варианте с СУБД используется поставляемое с прибором ПО.
BA>Необходимо "забрать" результаты, привести к требуемой форме и отправить в центральную СУБД. Основные задачи, которые придётся решать — разбор протоколов передачи (документация есть) и структур таблиц БД, ну и создание унифицированного интерфейса. Программа должна уметь настроиться и работать с любым из 40-ка приборов или с несколькими одновременно. Ну и по мелочи — авторизация пользователя, администрирование, настройка автономной работы при сбое связи с центральной БД.
BA>Срок выполнения — 4 месяца.
BA>Скажите, сколько такая работа будет стоить?
тут стоит заострить внимание на том что с 40 приборами за 4 месяца вы не справитесь. В идеальном случае на прибор уйдет один день (я видел идеальный случай один раз в жизни), 40 раб. дней это два месяца. А еще нужно нарисовать интерфейсы, схемы БД, предварительное исследование провести и развернуть у заказчика. Даже если будет несколько человек на проекте, то вряд ли это сильно ускорит, так как долго будете приводить кучу разных приборов к "одному знаменателю".
Здравствуйте, landerhigh, Вы писали:
L>Еще раз — по спецификации девайс 100% поддерживает протокол А. При реализации или тестировании, месяце так на четвертом, вдруг выясняется, что реализация протокола в девайсе своеобразная.
L>>>Такое веселье случается сплошь и рядом даже при 100% документированном, стандартном протоколе.
Ну и что ужасного случится? Если программа так написана, что от этого упадет — да, плохо, но необязательно ее так писать.
nvb>>Это достаточно распространенная проблема, которая достигает своего апогея в случае передачи данных измерений по ненадежному радиоканалу. CRC контроль здесь не всегда помогает, поскольку, например, в диапазоне 2,4ГГц в принятом пакете может быть все,
L>Ты прочитал мое сообщение по диагонали. Это не ошибка и не потерянный пакет и не шум на линии. Девайс специально шлет мусор, чтобы на что-то пожаловаться. А в мануале это отразить "забыли". Бывает. Вы не знали, клиент не знал, зачастую даже разработчик девайса тоже забыл.
Итак. Тип сообщения не отображен в мануале. Иногда даже разработчик девайса об этом сообщении забыл. Тогда это именно что мусор, который не надо выводить и учитывать.
Или ты в релизе все мусорные фильтры отключаешь? А зачем? В рамках договора у тебя с большой вероятностью будет поддержка, вот и заглядывай периодически в логи. Можно размер лога ограничить... впрочем, что я элементарные вещи говорю
А по поводу жалоб девайса... Обычно у девайсов с интерфейсами индикатор есть, на который он выводит серьезные жалобы, или светодиод, или пищалка. А жаловаться по интерфейсу, который имеет право быть неподключенным, да еще и недокументированно жаловаться... Скорее всего это мелочь, на которую можно просто не обращать внимания. Вероятность налететь на что-то серьезное при таких условиях очень мала.
L>В итоге клиент будет несколько обескуражен.
Не надо осчастливливать заказчика знанием, что пришел пакет, который невозможно разобрать. У него своих проблем хватает.
Здравствуйте, nvb, Вы писали:
L>>Еще раз — по спецификации девайс 100% поддерживает протокол А. При реализации или тестировании, месяце так на четвертом, вдруг выясняется, что реализация протокола в девайсе своеобразная. L>>>>Такое веселье случается сплошь и рядом даже при 100% документированном, стандартном протоколе. nvb>Ну и что ужасного случится? Если программа так написана, что от этого упадет — да, плохо, но необязательно ее так писать.
Опять читаем по диагонали? Написал же ничего не упало. "Всего-навсего" — событие до БД не дошло. Хотя на морде девайса оно есть. Заказчик рвет и мечет, если у него из-за этого чего похуже не стряслось.
nvb>>>Это достаточно распространенная проблема, которая достигает своего апогея в случае передачи данных измерений по ненадежному радиоканалу. CRC контроль здесь не всегда помогает, поскольку, например, в диапазоне 2,4ГГц в принятом пакете может быть все,
L>>Ты прочитал мое сообщение по диагонали. Это не ошибка и не потерянный пакет и не шум на линии. Девайс специально шлет мусор, чтобы на что-то пожаловаться. А в мануале это отразить "забыли". Бывает. Вы не знали, клиент не знал, зачастую даже разработчик девайса тоже забыл.
nvb>Итак. Тип сообщения не отображен в мануале. Иногда даже разработчик девайса об этом сообщении забыл. Тогда это именно что мусор, который не надо выводить и учитывать.
Заказчику не нужна система, которая собирает "почти все данные", иначе бы он бабу Машу нанял данные записывть в журнал каждые 5 минут (или как получится) за 1/100 тех денег, в которые ему встанет разработка автоматизированной системы.
Тип сообщения отображен. И обрабатывается правильно. Только с такой интересной датой в пакете оно упало на самое дно базы и там и осталось, причем выкидывать сообщения или модифицировать данные (поставить другое время) в них мы не имеем права. В индустрии, где я работаю, подобное выкинутое сообщение может привести к человеческим жертвам.
nvb>Или ты в релизе все мусорные фильтры отключаешь? А зачем? В рамках договора у тебя с большой вероятностью будет поддержка, вот и заглядывай периодически в логи. Можно размер лога ограничить... впрочем, что я элементарные вещи говорю
Это разговор глухого со слепым получается. Ты отказываешься понять суть проблемы.
nvb>А по поводу жалоб девайса... Обычно у девайсов с интерфейсами индикатор есть, на который он выводит серьезные жалобы, или светодиод, или пищалка. А жаловаться по интерфейсу, который имеет право быть неподключенным, да еще и недокументированно жаловаться... Скорее всего это мелочь, на которую можно просто не обращать внимания. Вероятность налететь на что-то серьезное при таких условиях очень мала.
Вероятность налететь на серьезное здесь строго равна единице. Те, кто считал иначе, сейчас в Японии вокруг раскуроченной атомной станции со шлангами бегают.
Здравствуйте, landerhigh, Вы писали:
L>>>Ты прочитал мое сообщение по диагонали. Это не ошибка и не потерянный пакет и не шум на линии. Девайс специально шлет мусор, чтобы на что-то пожаловаться. А в мануале это отразить "забыли". Бывает. Вы не знали, клиент не знал, зачастую даже разработчик девайса тоже забыл.
nvb>>Итак. Тип сообщения не отображен в мануале. Иногда даже разработчик девайса об этом сообщении забыл. Тогда это именно что мусор, который не надо выводить и учитывать.
L>Заказчику не нужна система, которая собирает "почти все данные", иначе бы он бабу Машу нанял данные записывть в журнал каждые 5 минут (или как получится) за 1/100 тех денег, в которые ему встанет разработка автоматизированной системы.
Я понимаю, что человек ты ответственный и все такое. Вот только не надо брать на себя все грехи мира. Ты не можешь и не имеешь права реагировать на сообщение, не отраженное в официальном мануале, иначе можешь получить — и совершенно справедливо — по шее, за реакцию на такое сообщение. Потому что оно может быть умышленным "пакетом смерти", ХЗ откуда пришедшим в канал связи — например, увольняемый программист девайса решил отомстить своей фирме. Если ты отрапортовал заказчику о подозрительных пакетах и заказчик официально дал добро на их отлов и разбор — вместе с деньгами и временем — только тогда вперед.
Вариант отмазки постфактум "я затянул сроки на месяц, потому что отлавливал и интерпретировал не отраженное в мануале сообщение" вызовет у заказчика в лучшем случае непонимание.
L>Тип сообщения отображен. И обрабатывается правильно. Только с такой интересной датой в пакете оно упало на самое дно базы и там и осталось, причем выкидывать сообщения или модифицировать данные (поставить другое время) в них мы не имеем права.
А за каким оно упало на самое дно базы? Что, трудно ввести дополнительное поле, назвать его "время прихода сообщения", и писать в него системное время из РС? И анализировать на лету разницу временных меток в пришедшем пакете и системного времени? И индицировать подозрительную разницу в видное место?
Вообще-то, я даже не представляю, как можно иначе. Если этого не сделать, то любая севшая батарейка, питающая часовую мелкосхему на девайсе, приведет к тем же самым последствиям.
L>В индустрии, где я работаю, подобное выкинутое сообщение может привести к человеческим жертвам.
Ты все-таки определись. Либо "выкинутое сообщение может привести к человеческим жертвам" либо "клиент не знал, зачастую даже разработчик девайса тоже забыл". Если это сообщение достаточно серьезное, чтобы быть индицированным на морде и чем угодно еще, тогда надо искать его в потоке данных в первую очередь. Если же это не так — копи информацию в логах и анализируй их периодически. Сделай в программе текстовое окошко, назови его "ХЗ" и сыпь непонятные сообщения туда. В конце концов, прикрути почтового клиента и пусть он высылает тебе инфу о непонятном сообщении сразу же, как оно пришло.
Ждать, пока система свалится в аут или заказчик запрыгает от пакета непонятного формата — ну, можно и так. У каждого свой путь. Тогда действительно надо 2 года на отладку.
Хорошо, я понял, что описанные мной методы тебе не подходят. Твой-то метод отлова этих сообщений какой? Расскажи.
nvb>>Или ты в релизе все мусорные фильтры отключаешь? А зачем? В рамках договора у тебя с большой вероятностью будет поддержка, вот и заглядывай периодически в логи. Можно размер лога ограничить... впрочем, что я элементарные вещи говорю
L>Это разговор глухого со слепым получается. Ты отказываешься понять суть проблемы.
Я правда не могу понять суть. Объясни. Как человеку, посвятившему этой области некоторую часть своей жизни, мне действительно интересно понять, в чем тебе видятся действительно неразрешимые проблемы? Сейчас, по прошествии лет, 95% проблем, с которыми я сталкивался, я смело отношу на счет собственного незнания и раздолбайства, а в оставшихся 5% я просто не уверен
nvb>>А по поводу жалоб девайса... Обычно у девайсов с интерфейсами индикатор есть, на который он выводит серьезные жалобы, или светодиод, или пищалка. А жаловаться по интерфейсу, который имеет право быть неподключенным, да еще и недокументированно жаловаться... Скорее всего это мелочь, на которую можно просто не обращать внимания. Вероятность налететь на что-то серьезное при таких условиях очень мала.
L>Вероятность налететь на серьезное здесь строго равна единице. Те, кто считал иначе, сейчас в Японии вокруг раскуроченной атомной станции со шлангами бегают.
Вот только не надо присобачивать Японию как аргумент, когда говоришь с технарями. Не поймут (с). Как аргумент для выбивания у заказчика денег на дополнительное тестирование — пожалуйста, но здесь — не надо.
И посмотри на стартовое сообщение. Вряд ли организация, которая дает 4 месяца на разработку и обращается к частному лицу, делает что-то, что может привести к человеческим жертвам. Хотя бы из-за разделения будущей ответственности.
Существует риск и последствия от реализации риска. Последствия риска от сломавшейся китайской игрушки — почти никакой, и коэффициент запаса ее прочности — 1, поэтому она ломается на вторую неделю. Последствия риска от разрушения механизма подъема пассажирского лифта — человеческие жертвы, поэтому там коэффицент запаса прочности — 30, и я пока не слышал об оборвавшемся тросе лифта. Никто не станет платить за реагирование на риск больше, чем это действительно необходимо.
Здравствуйте, iHateLogins, Вы писали:
BA>>Для небедной организации (Россия) необходимо сделать следующую программу. BA>>Срок выполнения — 4 месяца. BA>>Скажите, сколько такая работа будет стоить?
HL>А "небедная организация" не может пойти к коммерческим компаниям, получить коммерческие предложения и не бомжить на RSDN?
Может конечно. Но, скорее всего хотят подешевле, а у топикстартера есть шанс получить хороший заказ. Осталось только прикинуть — реально ли его вытянуть.
