Сколько будет стоить?...

Предупреждение раз — это не вакансия, это попытка оценить непонятную мне работу.

Предупреждение два — в дальнейшем мы закажем эту разработку. Сейчас нужно просто ее оценить.

Предупреждение три — если не в том подфоруме, прошу извинить...: о (

Преамбула.

Мы разрабатываем навигационную систему. На выходе будем иметь географические координаты объекта (перемещающегося). Необходимо положение объекта выводить на карту. В первом приближении — Google Maps. Во втором — на оцифрованную карту заказчика.

Платформа.

Не понятно. То бишь функциональный состав нашего «черного ящика»™ понятен. Протокол, в котором мы выдаем — тоже. Дальше или х86 в конструктиве U3 или ARM11 (если успеет появится).

Особенности

На платформе будет крутится наше приложение. Таким образом, нам будет нужен модуль или Win-App или Linux-App, созданный на С/С++, и вызываемый нами. Скорее всего с исходниками. От украинского юрлица.

Вопрос

Сколько времени займет его разработка и сколько будет стоить.

Пояснение

Это не скрытый тендер. Просто нужно знать порядок цен и особенности реализации в неизвестной мне области.

Ctrl + Enter

anonymous 18.06.2009 20:04

:)
дело Ваше -) ,

а прототип я имел в виду именно этого «визуализатора», а не всей системы. Всё остальное — mock’ами сделать.

Відповісти

Підтримати

anonymous 17.06.2009 09:05

to Алексей

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

Дикая смесь TMS, ADuc (7& 8), Xmega & Cygnal. Основной принцип: одна задача — один камень.

2. Большую роль играет target OS. Часто разработчики аппаратных комплексов для военных/транспортников тяготеют к решениям на микроконтроллерах либо на «взрослых» процессорах, но без операционки как таковой. В определенной ситуации это может снизить риски и добавить надёжности, но обычно выливается только в проблемы. Основная — отсутствие богатых и оттестированных API на базе которых будет строится функционал (в итоге разработчики пишут всё с нуля == изобретают велосипед). Не совершайте таких ошибок:)

В наших целевых камнях никаких RTOS не будет. Работаем напрямую. Наш «ящик» ™ выдает пакет информации (географические координаты, скорости, ускорения etc). Географически расположен далеко от оператора (или трюм, или борт ракетоносителя, или...) В некоторых случаях эту информацию нужно будет визуализировать. Понятно, что не в составе ракетоносителя: о:)

3. Конечная стоимость очень зависит от не функциональных требований к софту (используемая память, CPU, доступ к картам (если через GSM/WiFi — минимизация трафика итд), минимальное время работы от батареи) и прочих характеристик. Для примера, написать такое приложение для обычного десктопа в среднем в 5 раз проще, чем для embedded системы, работающей на батарейках.

Это наши проблемы. Нужен будет модуль который можна будет портировать, я так думаю. Условия для функционирования мы обеспечим.

4. Начните с прототипа. Прототип Вам оценят очень точно и легко (могу сказать что для ARM’a на WinCE/Linux это будет полтора человекомесяца максимум). После прототипирования Вы пересмотрите свои требования (можно будет выдвигать их субконтрактеру в более структурированном виде), будете лучше представлять условия приёмки, и сам подрядчик с большей точностью сможет оценить полную стоимость.

Прототип будет готов через год, минимум: о (

5. Выбор платформы и вообще архитектуру системы в целом лучше тоже согласовать с подрядчиком. На таких «черных ящиках» часто вылезают большие проблемы интеграции, просто изза того, что заказчики не потрудились рассказать как это будет использоваться.

В целом согласен, в частности нет: о)

anonymous 16.06.2009 23:16

ARMы не очень дружат с многопоточностью и это может сыграть злую шутку:)

???

Имел в виду что у них переключение контекста происходит не так шустро как, скажем, на ultra sparc или тех же интелах. Было замечено падение производительности перенесённого на АРМ многопоточного кода, в то время как тот же алгоритм реализованный в одном потоке может работать значительно быстрее чем на интеле аналогичной мощности. Но это вопрос производительности:)

Что мешает посадить на железку Линукс/ВинЦЕ?

Я не говорил, что что-то мешает (на самом деле мешать может многое. отсутствие драйверов для определённой переферии — самому писать драйвера => + effort). Речь о том, что выбор в качестве ОС куцого linux, помещающегося на 16Мб флеше может сделать разработку в 2−3 раза более трудоёмкой изза недостатка библиотек, а выбор wince для самодельной платформы добавит к разработке чудную фазу системной интеграции включающую сборку операционки практически из исходников (примерно от недели до 2 месяцев при наличии драйверов). Пример с контроллерами — для пущей наглядности.

А причем здесь батарейки? Батарейками ведает операционка, а аппликационщику о них и знать не надобно.

А вот это очень распространённое заблуждение. Не буду вдаваться в подробности про спин блокировки, таймеры, эффективность кода и т.д. Для примера: у меня инернет таблетка на линуксе. Софт написанный производителем работает нормально. Таблетка живет до 10 дней на батарее. Софт портированный с PC Linux (в основном с debian) садит батарейку за сутки даже когда свёрнут и по логике вещей (глядя на UI) делать ничего не должен...

eugene_n 16.06.2009 22:12

ARMы не очень дружат с многопоточностью и это может сыграть злую шутку:)

???

Большую роль играет target OS

Для примера, написать такое приложение для обычного десктопа в среднем в 5 раз проще, чем для embedded системы, работающей на батарейках.

anonymous 16.06.2009 21:39

Владимир,
Несколько комментариев/советов.
1. Немаловажным является вопрос, что еще будет крутиться на устройстве? ARMы не очень дружат с многопоточностью и это может сыграть злую шутку:)
2. Большую роль играет target OS. Часто разработчики аппаратных комплексов для военных/транспортников тяготеют к решениям на микроконтроллерах либо на «взрослых» процессорах, но без операционки как таковой. В определенной ситуации это может снизить риски и добавить надёжности, но обычно выливается только в проблемы. Основная — отсутствие богатых и оттестированных API на базе которых будет строится функционал (в итоге разработчики пишут всё с нуля == изобретают велосипед). Не совершайте таких ошибок:)
3. Конечная стоимость очень зависит от не функциональных требований к софту (используемая память, CPU, доступ к картам (если через GSM/WiFi — минимизация трафика итд), минимальное время работы от батареи) и прочих характеристик. Для примера, написать такое приложение для обычного десктопа в среднем в 5 раз проще, чем для embedded системы, работающей на батарейках.
4. Начните с прототипа. Прототип Вам оценят очень точно и легко (могу сказать что для ARM’a на WinCE/Linux это будет полтора человекомесяца максимум). После прототипирования Вы пересмотрите свои требования (можно будет выдвигать их субконтрактеру в более структурированном виде), будете лучше представлять условия приёмки, и сам подрядчик с большей точностью сможет оценить полную стоимость.
5. Выбор платформы и вообще архитектуру системы в целом лучше тоже согласовать с подрядчиком. На таких «черных ящиках» часто вылезают большие проблемы интеграции, просто изза того, что заказчики не потрудились рассказать как это будет использоваться.

Т.е., как Вы, надеюсь, поняли, тыкать пальцем в небо тут бессмысленно. Я бы советовал набросать черновик SRS и по нему спрашивать цены. Ибо можно больно просчитаться.

Володимир Лещенко 16.06.2009 13:51

слишком много непонятного. определитесь на чем и какие карты выводить будите, а потом считайте.
ну, а если прикинуть, то нормальные разработчики с вас за это по рейту меньше $20 не возьмут (а юр.лица возьмут еще больше), а затянеться это на 2 месяца минимум. так что минимально нужную сумму посчитать можно.

Заказчик сам еще не определился — какие карты ему нужны и какая платформа будет стоять на финише.

Я так понимаю 50 в час на 6 человекомесяцев будет более/менее похоже? Предпочтение будет отдаваться юрлицам — эт точно: о)

Ostap Vyshnya 16.06.2009 13:39

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

ну, а если прикинуть, то нормальные разработчики с вас за это по рейту меньше $20 не возьмут (а юр.лица возьмут еще больше), а затянеться это на 2 месяца минимум. так что минимально нужную сумму посчитать можно.

Володимир Лещенко 16.06.2009 09:20

Спасибо за первое приближение: о)
Мы не создаем диспетчерскую программу — мы создаем комплекс, который отслеживает перемещения объекта, на который он установлен. Без GPS и/или Глонасс. Инерциальная система.
По сути, отображение на карте — всего лишь GUI, для оператора системы. А полученные географические данные являются промежуточными.
Применение — артилерия, ракетные комплексы, флот.

"Часу і натхнення“© влезать в “картежные дела”: о) нет. Слишком много работы по самому комплексу. Нанимать человека на разовую работу — тоже не хочется. Решено отдать разработку на сторону. И узнать цены для калькуляции разработки.

anonymous 16.06.2009 07:29

По интеграции — ну у нас как-то была задча по интеграции с ними (но задача была сложнее чем отслеживания координат): заняло два человеко месяца собственно задача клиента + интеграция с vnetgist + изучение API. Еще просто карту к сайту прикрепить с навигацией по своим объектам обычно пару дней занимает
Но это просто пример трудоемкости залач, особенно с вашей не пересекающееся. Обычно в подобныз задачах столько нюансов (ТЗ, фороматы, железо), что без подробного анализа даже приблизительно прикидывать цену не берусь.
Однако если вы не конкурируете, то думаю, что просто взять у них готовую диспетчерскую систему будет дешевле всего

// (я не знаю, опубликовано ли описание, но движущиеся объекты на сайтах они отображают. И размалевать движок в своем стиле тоже можно)

Володимир Лещенко 16.06.2009 06:40

Нет, не подойдет... Может только в качестве карт...

Зручний протокол доступу до картографічного серверу дозволяє інтегрувати картографічне наповнення в проекти довільної складності, в не залежності від мови програмування, що було використано.
На даний час наші клієнти використовують:
* PHP
* Perl
* ASP (JScript, VBScript)
* Lotus (LotusScript/Java)
* и др.

А вот это меня интересует — сколько будет стоить интеграция.

P.S. Мы не конкурируем, у нас совсем другая задача под определенного заказчика.

anonymous 16.06.2009 05:35

Можно просто сервисом пользоваться: http://vnetgis.com/ua/4a372dde638e2.htm

Они же и продают диспетчерские комплексы как софт. (По вопросу непонятно — конкурируете вы с ними или можете использовать)

Сколько будет стоить?...

11 коментарів

Підписатись на коментарі