Труд, доход и нормирование :)

[igor]

Ну а мне просто недавно понадобилась работающая схема оценки "эффективности проэктов"... схематичная, как и всякая модель...

Проекты шибко разные бывают. Например, технические проекты, образовательные и т.д. Всех под одну гребёнку не получится. Далее под проектом я буду подразумевать разработку какой-либо технической системы.

Схему оценки эффективности "проэктов" не приведу, но зато напомню одно мегасуперправильное изречение (дословно не помню):

Маленькую и простую систему создать намного труднее, чем большую и сложную.

Разумеется, имеется в виду при неизменном техническом задании. Вот Вам и критерий эффективности. 

Эффективность системы напрямую зависит квалификации её создателей. Здесь действуют особые законы, когда количество не переходит в качество. Сто неквалифицированных (в данной области) специалистов не заменят одного квалифицированного.

PS: Попробовал ответить на угад.    Но боюсь, что Вы ждёте не этих сведений для того, "чтобы закрыть тему".

[valexey_u]

Схему оценки эффективности "проэктов" не приведу, но зато напомню одно мегасуперправильное изречение (дословно не помню):

Маленькую и простую систему создать намного труднее, чем большую и сложную.

Разумеется, имеется в виду при неизменном техническом задании. Вот Вам и критерий эффективности. 

Это не всегда так, а иногда совсем не так. Для начала нужно определить, что значит "создать" и что значит "труднее".

[igor]

А Вы случайно не помните, кому принадлежит это изречение и как оно звучит в оригинале?

[valexey_u]

А Вы случайно не помните, кому принадлежит это изречение и как оно звучит в оригинале?

Возможно Тони Хоар:
«Есть два способа спроектировать систему. Один — сделать ее настолько простой, что в ней очевидно не будет недостатков, а второй — сделать ее настолько сложной, что в ней не будет очевидных недостатков. Первый способ намного более труден.»

Замечу, что в такой формулировке очевидно, что полученные системы решают РАЗНЫЕ задачи (разное ТЗ по сути).

[igor]

Думаю, что теперь я понял, что Вы имели в виду. В процесс создания системы часто входит и формирование (либо корректирование) технического задания. Так?

[valexey_u]

Думаю, что теперь я понял, что Вы имели в виду. В процесс создания системы часто входит и формирование (либо корректирование) технического задания. Так?

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

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

Да, ну и опять таки - систем первого рода по Хоару я не видел ни разу. Пожалуй я видел три типа систем - маленькие где очевидно есть недостатки, большие в которых очевидно есть недостатки, и большие где недостатки не очевидны. В текущем проекте у меня первое из перечисленного :-)

[igor]

Да, всё это действительно так. Но ведь я сразу оговорил границы применимости изречения:

Разумеется, имеется в виду при неизменном техническом задании.

Если же это условие нарушается, то я под изречением не подписываюсь. 

[valexey_u]

Да, всё это действительно так. Но ведь я сразу оговорил границы применимости изречения:

Разумеется, имеется в виду при неизменном техническом задании.

Если же это условие нарушается, то я под изречением не подписываюсь. 

Это называется "если б у нас был грааль, то мы бы...". :-) Четкое, однозначное, непротиворечивое да еще и неизменное во времени ТЗ - это и есть священный грааль всех программистов. Только вот его не бывает :-)

[igor]

Да, уж... Никогда не забуду, как я бегал однажды (давно уже) за одним заказчиком, чтобы согласовать с ним то ли техническое задание, то ли технические условия на новое изделие. Когда же я его настиг в каком-то коридоре, он повернулся ко мне и презрительно заявил: "Пишите что хотите. Мы всё подпишем!" И, пока я там свою челюсть подбирал, развернулся и ушёл.

[igor]

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

[valexey_u]

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

Да даже для таких внутренних задач постоянно ТЗ меняется. То есть инструментарий свой я под себя периодически подпиливаю. Сейчас вот например подпиливаю чтобы оно выводило результат через gnuplot.

[igor]

Это называется "если б у нас был грааль, то мы бы...". :-)

На изречение, которое я привёл, можно посмотреть и с другой стороны. Допустим, есть две конторы, которые независимо друг от друга создали системы А и Б, являющиеся полными функциональными аналогами. Так вот, если при этом система А заметно меньше и проще, чем система Б, то система А эффективнее. В этом случае ограничение на неизменность ТЗ в процессе создания систем можно снять, и оценивать эффективность по конечному результату.

[valexey_u]

Это называется "если б у нас был грааль, то мы бы...". :-)

На изречение, которое я привёл, можно посмотреть и с другой стороны. Допустим, есть две конторы, которые независимо друг от друга создали системы А и Б, являющиеся полными функциональными аналогами. Так вот, если при этом система А заметно меньше и проще, чем система Б, то система А эффективнее. В этом случае ограничение на неизменность ТЗ в процессе создания систем можно снять, и оценивать эффективность по конечному результату.

Она эффективней при условии, что она также расширяема как и система Б (то есть также приспособлена к тому, что условия изменятся, в том числе ТЗ).

Кстати, приведи пожалуйста пример из програмной инженерии таких систем :-) Потому как я примеров придумать не могу.

Да, и нужно уже определиться что мы сравниваем - эффективность контор которые эти системы делают/поддерживают, или же эффективность самих систем :-)

[valexey_u]

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

[igor]

На изречение, которое я привёл, можно посмотреть и с другой стороны. Допустим, есть две конторы, которые независимо друг от друга создали системы А и Б, являющиеся полными функциональными аналогами. Так вот, если при этом система А заметно меньше и проще, чем система Б, то система А эффективнее. В этом случае ограничение на неизменность ТЗ в процессе создания систем можно снять, и оценивать эффективность по конечному результату.

Она эффективней при условии, что она также расширяема как и система Б (то есть также приспособлена к тому, что условия изменятся, в том числе ТЗ).

Кстати, приведи пожалуйста пример из програмной инженерии таких систем :-) Потому как я примеров придумать не могу.

Да, и нужно уже определиться что мы сравниваем - эффективность контор которые эти системы делают/поддерживают, или же эффективность самих систем :-)

1. Критериев эффективности может быть несколько. Я назвал один критерий, ты - второй (расширяемость). Кто-нибудь назовёт третий. При этом один критерий не отменяет другой. Такой критерий эффективности, как расширяемость, не являтеся однозначным. Потому что расшрияемость достигается не бесплатно, а при этом есть ли в ней необходимость, - ещё большой вопрос. Например, ты бы согласился при покупке автомобиля доплатить штуку баксов за возможность установки на крыше автомобиля бильярдного стола? 

2. Примеры каких систем? Подобных А и Б? Можно, наверное, привести примеры эффективных и неэффективных систем. Но вряд ли среди них будет пара, являющаяся полными функциональными аналогами. Да и какой смысл в этих примерах, ведь мы обсуждаем не какие-то конкретные системы.

3. Разумеется мы сравниваем эффективность систем (кто бы их ни создал).