Скорость разработки проектов

[zubr]

Если в программе есть клуджи и нет тестов, ее можно считать испорченной уже на этапе написания с достаточно высокой вероятностью. Штаны при таком подходе, пожалуй, лучше и не надевать вовсе, чтобы потом не тратить на их съем лишнее время, - все равно щеголять в них долго вряд ли придется.

P.S. Дабы не разводить бесплодных дискуссий, сразу же оговорюсь, что я не имею в виду совершенно неведомую мне область "социального программирования". Там действуют свои собственные законы и правила, ортогональные известным мне. Речь скорее о более привычных мне встроенном софте реального времени и серверных приложениях.

Ok. Извиняюсь, что не в тему. Но исходя из вышесказанного, мучает любопытство. Вот проект:

Автоматизированная зарядно-разрядная установка (АЗРУ) предназначена для обслуживания аккумуляторных батарей (АКБ). В основу работы установки положен цикл заряда-разряда АКБ, специфичный для каждого конкретного типа батарей. Заряд-разряд осуществляется силовым блоком (БС), управляемым центральным контроллером. Этот же контроллер обменивается информацией с управляющим компьютером (РС) через USB- интерфейс. Центральный контроллер способен самостоятельно (без подключения к РС) обеспечить полноценную работу установки с выводом информации на индикаторную панель.
Расширенный вариант АЗРУ оснащен периферийным контроллером, который отслеживает напряжение и температуру каждой банки АКБ и передает их на центральный контроллер соответствующие данные (команды).
Требуется:
1. Для контроллеров ATMEGA  (центрального и периферийного) написать программы, реализующие алгоритм циклограммы заряда-разряда. Для каждого типа АКБ возможны несколько циклограмм, выбор нужной осуществляется оператором.
2. Написать интерфейсную программу для управляющего компьютера, которая позволяет визуализировать весь процесс, управлять им, автоматически формировать,  хранить и обрабатывать протоколы обслуживания АКБ. На управляющем компьютере должен вестись учет АКБ, отслеживаться их движение (ввод в эксплуатацию, передача со склада в подразделение, из подразделения в подразделение, сдача на склад, списание) и соблюдение графика технического обслуживания АКБ.
3. Крайне желательна программа высокого  уровня, позволяющая на основе имеющейся циклограммы автоматически создавать программы для контроллеров.
4. Все программные средства должны быть написаны на распространенных языках программирования. Интерфейс программ должен быть мультиязычным (минимально: русский, английский, испанский языки). Весь программный комплекс должен быть задокументирован.
5. Как отдельная тема могут быть рассмотрены встроенные средства самоконтроля, диагностики, поиска неисправностей.

Dale, меня интересует сколько у тебя времени займет на разработку встроенного софта (только софта, без железа) по данной задаче.

[Dale]

Ok. Извиняюсь, что не в тему. Но исходя из вышесказанного, мучает любопытство. Вот проект:
Dale, меня интересует сколько у тебя времени займет на разработку встроенного софта (только софта, без железа) по данной задаче.

Сказать по правде, долгосрочное планирование - не моя сильная сторона. Предпочитаю работать итерациями в духе agile и следующую итерацию планировать в зависимости от успехов предыдущей. "Водопадная" модель плохо мне знакома. Но рискнул бы сделать очень грубую прикидку в пределах от 0.5 до 1 человеко-года. После сбора требований можно было бы сказать точнее.

Ну и пара пунктов не вполне понятны:

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

Не понял необходимости создавать программу для контроллера под каждую циклограмму. Я бы рассматривал циклограмму просто как данные. Или под программой имеется в виду не машинный код, а компактное представление данных для интерпретации в контроллере?

4. ... Весь программный комплекс должен быть задокументирован.

Тоже туманный пункт. "Экстремалы" считают, что исходный код - единственно ценный вид документации, все прочие лишены смысла. Другая крайность - на каждую строку кода десять пояснительных. Я бы включил в спецификации перечень и содержание документов, передаваемых заказчику. Может оказаться, что там одной писанины года на полтора.

[zubr]

0.5 до 1 человеко-года - это очень много. На проект установлены сроки - 2 месяца, бюджет 8000$. На мой взгляд, сроки и бюджет адекватны данной задаче.
По пункту 3: Тут подразумевается программа, которая на основе входных данных, к примеру в виде xml-файла или еще лучше в виде блок-схемы, которая будет менять алгоритм работы контроллера. Я бы за этот пункт дополнительно к бюджету взял бы 1500-2000$ и под эту задачу задействовал отдельного человека.
По пункту 4: Подразумевается подробный хелп к программно-аппаратному комплексу. Что касается исходников, то это как правило за отдельные деньги.

[Dale]

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

Одни только подробные спецификации составить - недели две хорошей работы. Да и автономный контроллер с хорошо продуманным пользовательским интерфейсом - та еще задача. Взаимодействие трех процессоров - тоже не сахар, нужен протокол прикладного уровня с восстановлением в случае сбоев, не за час проектируется. Даже хорошую документацию написать - и то нужно время (написав некоторое количество статей, представляю себе объем работы не понаслышке). При графике 24x7 за 2 месяца сделать все это добросовестно очень трудно; ну а если недобросовестно - кому это барахло нужно, еще и за такие деньги?

Вот что касается третьего пункта - это, можно сказать, моя родная стихия, я интерпретацией специализированных предметных языков давненько занимаюсь, да и замечательную книгу не так давно проштудировал: https://forum.shelek.ru/index.php/topic,26526.msg273850.html#msg273850 . Поэтому лично я с этим пунктом вполне уложился бы в бюджет, поскольку есть опыт. Но это просто случайное совпадение, при других условиях потребовалось бы куда больше сил и времени (== денег).

В первом приближении что-то отдаленно похожее делали ребята из Atomic Objects: https://club.shelek.ru/viewart.php?id=335 . Над платой мониторинга аккумуляторных батарей они работали 4 месяца (правда, не указано, сколько человек; полагаю, 2 или 3). Не думаю, что они нарочно затягивали сроки. Но сюда не входит софт для управляющего компьютера.

[Dimka]

zubr, по-моему, если циклограммы простые (не подразумевают разработки сложного DSL - из нескольких последовательных пунктов, состав которых может различаться для разных циклограмм, с параметрами), и если не нужно по неделе ждать ответов на вопросы, и если спецификации по железу известны и не содержат сюрпризов, то 2-х месяцев плотной работы достаточно.

А вот если ничего не известно, спецификаций на железо нет, если сложность DSL может оказаться всякой, а нужные люди могут пропадать неделями, не отвечая на вопросы, то вполне может затянуться и на год. Был у меня проектик, где работы - 3 чел.-месяца, а потом заказчик 5 месяцев "смотрел", хотя на самом деле не смотрел, а мотался по командировкам.

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

[zubr]

Dimka, ну там заказчик обещал подробное ТЗ с необходимыми спецификациями. Я пока в ожидании ТЗ, поэтому конкретный ответ заказчику не дал.
В моей практике (не как разработчика, а как руководителя) была похожая по сложности задача.
Испытательный стенд на надежность и электробезопасность для клавишных выключателей. Суть работы стенда - нажатие на клавишу выключателя (вкл-выкл) с кратковременными задержками и контролем тока после выключения-включения в течение нескольких милисекунд.
Первоначальный вариант механической части стенда напоминал по конструкции газораспределительный механизм двигателя внутреннего сгорания, электрическая часть стенда пускатели, реле и никакой электроники. Но стенд работал не совсем надежно, не выдерживались точно интервалы в милисекндах, механика из за износа выходила из строя, так как один цикл испытаний предполагал несколько миллионов циклов вкл-выкл.
Благодаря тому, что в моей службе был молодой парень-самоучка, осваивающий АВРы, мы смогли сделать стенд на основе шагового двигателя, управляемого микроконтроллером. Также микроконтроллер обеспечивал все режимы испытаний по току.
 В общем на всю эту работу от закупки комплектующих, электрокомпонентов, плюс еще городили самопальный программатор, самописный софт под программатор, создание железа, софта, отладка, написание техпаспорта стенда и методики аттестации потребовалось 3,5 месяца. Задействовано было 2 человека - парень-самоучка и девушка конструктор, которая писала паспорт и методику аттестации. Ну и я лично поучаствовал - писал софт для программатора и ломал (каюсь) триальную среду разработки АВР. Добавлю, что делался этот проект в обход заводских СТП - закупались компоненты за личные деньги, затем эти расходы компенсировались премией. Ну и был энтузиазм, так как для парня это был первый серьезный проект по микроконтролерам и он его делал с интересом.

[Sla]

Лехка!!! Любой каприз.

[Dimka]

zubr, получается, в этом стенде ты сам себе был заказчик. В таких условиях можно делать быстро. Львиная доля времени обычно тратится на взаимонепонимание.

[zubr]

Ну, чтобы максимально снизить издержки на взаимонепонимание, надо, имхо:
1. Требовать от заказчика четкого и подробного ТЗ. В случае отсутствия такового, самому его разрабатывать, согласовывая с заказчиком за дополнительную плату, естественно.
2. Требовать как минимум 30% предоплаты от заказчика, что будет стимулировать его на оперативность решения вопросов по проекту.
3. Оговаривать в договоре компенсацию издержек на затягивание сроков разработки, как со стороны исполнителя, так и со стороны заказчика.

Хотя конечно бывают очень неадекватные заказчики, у которых основа ТЗ "Хочу чтобы все...". Тут наверно надо или отказываться от проекта или в бюджет закладывать неадекват.

[Dimka]

Тут наверно надо или отказываться от проекта или в бюджет закладывать неадекват.

Выходит завышенная стоимость...

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

А можешь на глаз прикинуть по твоему опыту, какова зависимость стоимости человеко-часа в проекте (по выставляемому заказчику счёту) от количества задействованных разработчиков:

В одиночку - $ чел-час
Вдвоём - $ чел-час
Втроём - $ чел-час
Вчетвером - $ чел-час
Впятером - $ чел-час

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

[zubr]

Тут наверно надо или отказываться от проекта или в бюджет закладывать неадекват.

Выходит завышенная стоимость...

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

Ну за все в жизни надо платить, за неадекват в том числе. Тем более же в случае неадеквата заказчика, нагрузка (человеко-часы) в виде дополнительных переговоров, обсуждений, объяснений, выяснений на разработчика увеличивается, так что тут все по честному.
С неадекватными заказчиками я стараюсь минимально общаться. Чтобы минимизировать риски без предоплаты (причем процент чем выше, тем надежнее) к работе не приступать. Тут важно выяснить, что заказчик хочет получить на выходе, вникнуть в тему и делать как для себя с учетом в перспективе расширения функционала. По окончании работы, заказчика ставить перед фактом выполненной работы. Из моего опыта в большинстве случаев этот вариант прокатывает. Обычно после получения готового решения заказчик оживляется, более того, у него начинают генерироваться идеи (задним умом то все умны), как сделать лучше и т. п. Вот тут и начинается новая фаза переговоров. Я обычно по мелочам иду на компромисс и вношу изменения в проект без изменения бюджета. По более крупным новым возникшим идеям заказчика предлагаю ему создать новый этап проекта с соответственно новым бюджетом. Важно то, что он уже на "крючке", так как смог "пощупать" результат.

А можешь на глаз прикинуть по твоему опыту, какова зависимость стоимости человеко-часа в проекте (по выставляемому заказчику счёту) от количества задействованных разработчиков:

В одиночку - $ чел-час
Вдвоём - $ чел-час
Втроём - $ чел-час
Вчетвером - $ чел-час
Впятером - $ чел-час

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

Ну у меня опыт только с фрилансом, а тут риски гораздо выше, чем работа в команде, когда все под боком. Да и больше чем с 2-мя фрилансерами над проектом (со мной 3) мне не приходилось работать. Укрупненно можно, имхо, так считать:
2 чел - 1 чел/час *1,3
3 чел - 1 чел/час *1,5

[Dimka]

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

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

[zubr]

Dimka, чтобы минимизировать риски, я стараюсь:
-Крупные, долгоиграющие проекты не брать. Средние, по временным затратам от 2-х недель до 2-х месяцев - самое то. Мелкие на несколько часов-несколько дней работы, проекты тоже не беру, потому как нерентабельно.
-Из проектов, где планирую привлечь дополнительных разработчиков, все таки стараюсь придерживаться правила, что если этот разработчик вдруг пропадет или не справится, то я смогу это сделать сам.
-На стадии обсуждения прорабатываю для себя спорные вопросы (имеются в виду вопросы, где мне на данный момент недостаточно знаний или опыта), то есть смогу ли я потянуть проект, в процессе обучаясь.
-На мелкие проекты закладываю в калькуляцию 15-20 часов на вопросы согласований, обсуждений, на более крупные - 50-60. Тестирование, хелп идут в калькуляции отдельной статьей.
-Чтобы минимизировать простои из за согласований, ожидания решений от заказчика и т. п., как правило в текущих 2 проекта.

А вообще фриланс, есть фриланс - рискуют как заказчики, так и исполнители.
У меня уже был печальный опыт пропадания заказчика, даже при наличии предоплаты за проект. Благо, что проект был небольшой. Правда был и обратный опыт, когда брошенный проект, практически один в один удалось продать другому заказчику.

[zubr]

Оцените, пожалуйста, по трудозатратам в чел/час проект:

Визуальный конструктор форм MDI, SDI, Dialog для Win 32 приложений.
Суть проги, написать плагин для vision studio 2008, в которой как и в билдере можно накидывать окошки, кнопки и другие функции и чтобы генерировался автоматом код.

[Dimka]

Мало сведений.

Конструкторы работают двумя разными способами: либо генерируют некое промежуточное описание, которое затем преобразуется в код отдельным препроцессором/компилятором, либо сразу генерируют код. Второй вариант сложнее из-за необходимости обратного парсинга кода, но зато он "человечнее" для программиста. Второй немаловажный вопрос, что лежит под конструктором: чистый WinAPI или же некая библиотека-оболочка. В-третьих (тесно увязанное с 1 и 2): язык программирования. Ибо для .NET в общем-то оно и так уже есть. С++?

Мои опыты с разработкой компонент, годных для использования в дизайнере форм VS 2005/2008 для .NET, говорят, что время разработки такого компонента можно смело умножать на 1,5-2,5. Ко всему прочему разработка высококачественного GUI сама по себе - один из самых трудозатратных процессов в программировании. И как правило требует разработки процедуры тестирования, если это не простейший MessageBox. (Без этого обязательно будут косяки вроде кривого расположения элементов, ошибок в TabOrder, забытых Enabled/Disabled в разных режимах и т.п. мелочей. В уме это всё удержать невозможно, нужен check-list с пунктами и систематическая проверка.)

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

В общем, у меня картинка в голове не складывается, чтобы это оценивать.

[zubr]

Конструкторы работают двумя разными способами: либо генерируют некое промежуточное описание, которое затем преобразуется в код отдельным препроцессором/компилятором, либо сразу генерируют код. Второй вариант сложнее из-за необходимости обратного парсинга кода, но зато он "человечнее" для программиста.

Второй вариант.

Второй немаловажный вопрос, что лежит под конструктором: чистый WinAPI или же некая библиотека-оболочка. В-третьих (тесно увязанное с 1 и 2): язык программирования. Ибо для .NET в общем-то оно и так уже есть. С++?

Язык любой, хоть Delphi, ,библиотеки, компоненты допускаются.

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

Ну раз речь о билдере, то это должны быть аналоги стандартных борландских GUI-компонент - TEdit, TMemo, TCombobox, TListbox, TListview, TStringGrid.

Для Delphi я делал нечто подобное, там из конструктора генерился код для флеш/флекс. Заняло у меня это дело месяц. Но с VS в плане разраработки конструкторов никогда не связывался. К примеру в борланде есть пакеты designtime, позволяющие осуществлять связь с средой разработки, а есть ли такие возможности у VS?

[Dimka]

zubr, в .NET есть designtime элементы. Только это не пакеты, а части компонентов, помеченные особыми атрибутами - дизайнер форм через Reflection затем их отбирает и работает с ними.

Но в .NET также есть и конструктор форм - готовый. Нет лишь конструктора приложения в смысле мастера MFC. А конструктор форм такой же, как в Delphi.

Раз язык любой, в том числе .NET-овские, тогда непонятна сама проблема: ради чего огород городить?

[zubr]

Dimka, судя по всему, как раз этот конструктор не для Net-проектов (буду уточнять). Под любым языком понимается то на чем сам конструктор будет написан.

[Dimka]

zubr, а я спрашиваю про язык, с которым должен работать конструктор. И библиотеки тоже. Нужно же какой-то код генерировать.

[zubr]

Dimka, C++, стандартные библиотеки, WinAPI, допускается MFC

[Dimka]

zubr, видишь в чём дело. Если брать конструкторы типа Windows.Forms .NET или как в Delphi, там сама структура конструируемой формы описывается прямо в коде языка программирования. С MFC и тем фактом, что любой элемент должен описываться в разных местах в разных файлах (как минимум h и cpp), со всякими макросными костылями - с этим всем делать такой конструктор врагу не пожелаешь. Сама студия ограничивается мастерами-генераторами и простейшими функциями рефакторинга.

Лучше взять какую-нибудь лёгкую обёртку над WinAPI, прячущую сложные многопараметровые WinAPI вызовы. И всё равно понадобится парсер C++ вплоть до семантического уровня. Причём в VS он есть, но можно ли к нему подключиться - не знаю.

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

[zubr]

Dimka, ясно, спасибо.

[zubr]

Предложили проект:

Приложение для Windows 8
Нужна команда программистов, которая быстро и качественно разработает поисковое приложение по торговым и инвестиционным счетам брокерских и управляющих компаний на Финансовых рынках для браузерной версии на Flex и Windows 8. Приложение для Windows 8 должно удовлетворять всем требованиям Майкрософт, что бы попасть в Windows Store. Графику мы предоставим.

http://www.free-lance.ru/projects/1192859/prilojenie-dlya-windows-8.html

Есть желающие подключиться? Бюджет вроде неплохой.