Привет всем.
Подскажите пожалуйста, сколько мне запросить за программу. Работа не оффициалная, чернуха
Программа достаточно простая, небольшая база данных. Сколько времени на это уйдет - без понятия, т.к. довольно давно базы не программировал, навык потерял. Но уверен что осилю. Разрабатывать придется в свободное от работы время (т.е. не больше 2 часов в рабочии дни, ну и выходные поболее). Для скорости реализации решил воспользоваться средствами на Дельфи. Какую оплату просить? Если почасовую то сколько, или уже за готовый продукт цену назначить? как в 500 ┬? не много? а за дороботки может уже по часам брать?

мало инфы.
Пикинь хотяьы примерно количество форм - можно будет дать примрную оценку времени.

500 это минимум ...

Форм, так на вскидку - штук 20-30, таблиц будет около 10 таблиц.
Но я так не умею время оценивать, на какую-то уйдет 20-30 минут, на другую пару дней.

Боюсь переборщить, лицо часное, слишком много запрошу - испугается.
Думаю 500 ┬ самое то, больше не надо.

времени уйдёт куда больше.....20 формуляров и 10 таблиц логически соединить..всё это проверить..
месяц...

Форм, так на вскидку - штук 20-30, таблиц будет около 10 таблиц.
------
Немного странно по соотношению формы/таблицы, ну да ладно.
По минимуму - только показывать и писать данные без сложных рассчетов у меня получается примерно 1500 еврорублей. После того как с базой и функциональностью форм определишься можно сказать точнее.

20 формуляров...
всё это проверить..
месяц...
-----
Эээ... после того, как база создана и все прозрачно - слепить формы - микросекунды...
Вот бизнес-логику прописывать - там, да, побольше...

20-30 форм вполне себе требуют продуманной архитектуры. Я не знаю, что там у тебя за задача, но думаю, ты недооцениваешь время затрачиваемое, говоря про 20-30 минут для простых форм. Я не говорю, что я не могу за 15 минут слепить форму на которой будет пара текстбоксов и пара кнопок, дело не в этом.
Когда есть пара десятков форм в проекте, сходу садиться лепить морды это глупо, в итоге ты всегда проиграешь. Сначала надо нарисовать архитектуру, что требует времени. Ориентироваться на количество морд не совсем правильно, первична структура и функциональность, морды же вторичны, являясь интерфейсом между человеком и программой. B подавляющем большинстве случаев весьма разумно выносить всю функциональность за пределы класса формы, оставляя в последней только интерфейсные вызовы в обработчиках событий. "Рабочие" классы со своей стороны требуют порой кучу всяких вспомогательных вещей. Всё это требует времени.
Также необходимо учитывать время на тестирование.
Сaдись, рисуй архитектуру, после чего ты сможешь задать разумный вопрос о временных затратах на то или иное действие самому себе. Т.к. никто кроме тебя самого не знает твоeй квалификации и сколько времени у тебя потребует реализация какой-нибудь нетривиальной логики.
А желание услышать, простите, aбcолютно ничем необоснованый совет: "минимум 500" - это глупо.
За копейки, чтобы клиента не напyгать, можно, конечно, корячиться. А смысл? Лучше время потратить, ИМХО, на чтение литературы, чтобы поднять свою квалификацию.

Когда есть пара десятков форм в проекте, сходу садиться лепить морды это глупо, в итоге ты всегда проиграешь.
-----
Почти всегда, но все же не всегда. Посмотри, как я давно советовал, линию Link-15(-16). Правда там система не для 30-формовой халтуры.
"Рабочие" классы со своей стороны требуют порой кучу всяких вспомогательных вещей.
------
Угу... Поэтому они изначально делаются, минимум, двухуровневыми, а если появляется необходимость стандартного взаимодействия между объектами - то и трех или с реализацией отдельных интерфейсов..
Всё это требует времени.
------
Нее, это - не это _уже_ не требует.

Последнее предложение абсолютно не понял.

Генерится _уже_ работающим.
Максимум, что можно напутать - присвоение свойств в бизнес объектах. Но мой босс говорит, что он, в своем диссере, доказал, при определенных (т.е. с возможностью их автоматической проверки) ограничениях, уже можно справится и с трансляцией семантики действий.

знать бы ещё как правильно подходить к разработке базы данных...
как создавать прозрачную базу ...
я например совсем не умею...

Мда, про 20-30 форм, это я наверное загнул (наверное 10 ограничимся, хотя, может быть чего-нибудь упустил), и про время в 20 минут тоже. Я просто хотел показать, что зная количество форм я не смогу подсчитать время, требуемое на создание проги.
А про копейки: я не против и за "копейки" (если конечно же для кого-то 500 как доп. приработок - копейки), мне в шпас мозги размять, а то в силу обстаятельств все болшье физическим трудом занимаюсь . Так на вскидку: за 3-4 недели управлюсь. Просто не хотел цену перегибать, но как вижу - не перегибаю.

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

как правильно подходить к разработке...
-----
...приложений.
Есть целая куча методик - как. Они работают, но каждая - при определенном уровне квалификации персонала.
Что до базы - прозрачная - это когда ты мельком смотришь на схему базы и можешь объяснить где, когда и какая и откуда с какими параметрами форма будет вызвана и какое, приблизительно, расширение функциональности может быть у данной формы.
Вообще-то - ничего сложного в этом нет. Мой молодой ирландский коллега освоил это за два приема - первый - было объяснено что к чему, второй - у него на глазах была "исправлена" созданная им база и объяснено - почему именно такие "исправления".
Ну, блиииинннн... я сегодня и сготовил!!! УжО сожрал огромную полную тарелку и сейчас же побегу на кухню за второй... ням-ням-ням...

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

Определить стоимость программы трудно. Если оценивать по методике ИБМ, то оценка может быть дана по готовому коду - 20 у.е. за строку. Выбор языка (среды) программирования определяется только опытом программиста. В любом случае, нужно ориентироваться на рынок - спрос на данную программу. Я, обычно беру 1/2 рыночной стоимости. Еще одна методика учитывает только выходные формы (справки). Одна форма (на папире) у меня стоит порядка 20 у.е.
Не претендую на авторитет в этой области.

Определить стоимость программы трудно.
-----
Стоимость разработки - легко.
Если оценивать по методике ИБМ, то оценка может быть дана по готовому коду - 20 у.е. за строку.
-----
Это та, которая применялась еще к Фортрановскому коду? Во современных языках количество строк - показатель совершенно бессмыссленный. Кроме этого, принятие заказчиком построчной оценки количества кода приводит к легкому, в три-пять раз, увеличению объема кода и почти совершенной потерее его сопровождаемости.
Выбор языка (среды) программирования определяется только опытом программиста.
------
Исключительно - задачей. Разработчики, не говоря уж об кодерах, набораются потом.

Если оценивать по методике ИБМ, то оценка может быть дана по готовому коду - 20 у.е. за строку
Ассмблер рулит.
Выбор языка (среды) программирования определяется только опытом программиста.
Это неверно, если обобщать, а не брать отдельного "вольного стрелка". Я не раз читал высказывания о мегапрограммистах лабающих мегасистемы, которые сами себе инструмент выбирают. Но, сда╦тся мне, это выдача желаемого за действительное. Безусловно, выбор инструмента должен быть под задачу, но на практике выбор весьма и весьма ограничен и уж не программист решает, на ч╦м проект будет писаться.
В любом случае, нужно ориентироваться на рынок - спрос на данную программу.
О каком спросе Вы вообще говорите??
p.s. В совке была комплексная методика основаная на количестве строк, количестве выходных форм, всякие коэффициeнты сложности задачи были, что ещ╦ не помню. В общем, помню насколько оно было далеко от действительности. Кончилось тем, что сдохла методика, всех перевели на поврем╦нку и оклад назначал шеф исходя из опыта программиста.
p.p.s. Я просто флужу, занимаясь болтологией. Дае╦шь топик на пару сотен постов!

p.s. В совке была комплексная методика основаная на количестве строк, количестве выходных форм, всякие коэффициeнты сложности задачи были, что ещё не помню.
------
У меня где-то даже книжка (сколько не пытались ее зажать всякие кульцменеджеры) по этому делу. Тоненькая - страничек 50-60. Коротко - условия применимости методики, основные формула пересчета, таблицы коэфициентов. Выходила где-то году в 89-90 при цене что-то около рубля. Поскольку прочел ее достаточно внимательно, то могу сказать, что в оговоренных условиях она вполне себе пригодна.
Что до методик. Пару лет назад листал переводной трактат по тому же самому вопросу. Трактат отличался твердым переплетом и фундаментальностью изложения материала. Изложение настолько фундаментальное, что падение данного фолианта на чью-нибудь голову было бы с тяжелыми последствиями - в фолианте было порядка 10см толщины, при весьма впечатляющем формате - размер примерно как у Техника-Молодежи... А листал, потому, что в данном фундаментальном трактате изложено все тоже самое, что и тонюсенькой брошюрке. Ничего принципиально нового.

2Скопи_
Ладно, не звезди. В 89-90, в совке! какие-либо теории на данную тему могли быть только в зачаточном состоянии.
------
От того, что конфектку завернут в другой фантик ее качества не изменятся. Аналогично с расчетами времени имплементации - пока применяется не ООП методология и производится отдельное кодирование каждой формы - работают базовые нормы. При применении ООП - работают те же нормы, но с другими коэфициентами. Появится популярная среда, аналогичная Линку, в которой будет возможность рисовать только форму и получать работающее приложение - остануться те же нормы, но еще раз сменятся коэфициенты.
Лично я пользуюсь Funktion Point методом, работает сносно.
-----
Если ты понимаешь, что именно ты считаешь, то какая разница как называется методика?
Что же касается данного проекта, то хотя данных явно недостаточно, он тянет часов так на сто... плюс-минус 30-40...
-----
Да, около 3-х недель. Смотри выше по постам.

Ты по всей видимости, не очень-то с этими методиками знаком? Конфетки бывают весьма разными...
Говоришь куча коэффициентов там была? CoCoMo поди, или с неё спизженная...

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

Ну вот и повод раздуть ветку на 200 постов.
Я сегодня правда не в боевом настроении, может быть завтра.
Я, вообще-то, довольно плотненько "знаком" с Industrial Engeneering
Ну да, аж позабыл как оно пишется...
Да, и viel Spaß с применением твоего IBM-метода в современных проектах...

Это у меня стандартная ошибка. Что-то типа - колЛичество - лет двадцать писал с двумя Эль...
Ну может и завтра. Просто сегодня мне Ышо ждать прилета флота с часок...

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