Помогите с материалами на эту тему. Интересуют как теоретические , Так и практически оправдавшие себя способы оценки качества работы.

Здравствуйте, Аноним, Вы писали:

А>Помогите с материалами на эту тему. Интересуют как теоретические , Так и практически оправдавшие себя способы оценки качества работы.

Для каких целей?

B>Для каких целей?

для целей подготовки выступления перед математиками на эту тему.

Здравствуйте, Аноним, Вы писали:


B>>Для каких целей?

А>для целей подготовки выступления перед математиками на эту тему.

Это не цель, это повод или способ рассказать о цели и том, как ее достичь

А цель — это что иное.
А вообще качество работы команды определить можно только по тому,
насколько довольны клиенты (заказчики).
Довольны клиенты — значит качество хорошое, какой бы "бред" не писали бы программеры...

Оценка работы программиста может быть осложнена тем, что не всегда можно определить роль программиста в проекте. Например, если у Петрова в процессе работы консультируются Иванов и Сидоров, то обычно это никак не отражается на оценке Петрова, зато роль его в команде незаменима...

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Аноним, Вы писали:


B>А цель — это что иное.
B>А вообще качество работы команды определить можно только по тому,
B>насколько довольны клиенты (заказчики).
B>Довольны клиенты — значит качество хорошое, какой бы "бред" не писали бы программеры...

Увы, но это только одна из граней качества ... хотя для проектов типа "fire and forget" вполне прокатит.

Здравствуйте, byur, Вы писали:

B>Здравствуйте, bkat, Вы писали:

B>>Здравствуйте, Аноним, Вы писали:


B>>А цель — это что иное.
B>>А вообще качество работы команды определить можно только по тому,
B>>насколько довольны клиенты (заказчики).
B>>Довольны клиенты — значит качество хорошое, какой бы "бред" не писали бы программеры...

B>Увы, но это только одна из граней качества ... хотя для проектов типа "fire and forget" вполне прокатит.

Если действовать по принципу "fire and forget", то клиенты долго довольны не будут
Так что критерий качества "доволен ли клиент" в целом верен.
Сделать клиента довольным очень непросто, а вот недовольным — раз плюнуть.
Тут тебе и сроки, и гибкость, и нужные фичи в срок и все все все...

Здравствуйте, bkat, Вы писали:


B>>>А вообще качество работы команды определить можно только по тому,
B>>>насколько довольны клиенты (заказчики).
B>>>Довольны клиенты — значит качество хорошое, какой бы "бред" не писали бы программеры...

B>>Увы, но это только одна из граней качества ... хотя для проектов типа "fire and forget" вполне прокатит.

B>Если действовать по принципу "fire and forget", то клиенты долго довольны не будут
B>Так что критерий качества "доволен ли клиент" в целом верен.
B>Сделать клиента довольным очень непросто, а вот недовольным — раз плюнуть.
B>Тут тебе и сроки, и гибкость, и нужные фичи в срок и все все все...

Повторю свою мысль -- то что клиент доволен тем что софт реализует все что нужно клиенту, не имеет существенных дефектов, сделан в срок -- это *одна из граней качества*. Естественно важная, ибо за это заказчик и платит .. но, если у вас достаточно навороченная по функционалу система, сделанная в очень сжатые сроки, и сделана "в лоб" с логикой на "OnButtonClick", то такая система как спагетти -- ее сложно поддерживать, модифицировать и тиражировать. А это отнюдь НЕ КАЧЕСТВЕННАЯ система! Что толку от выкрашенного фасада здания, если у него гнилые перекрытия! Понятие качества -- многогранно. Посему я и говорю, что если это одноразовый проект, то это видимо допустимо. Но при условии поддержки и развития такого проекта -- это влетает в конечном счете в копеечку, как заказчику, так и разработчику.

Здравствуйте, byur, Вы писали:

B>Здравствуйте, bkat, Вы писали:


B>>>>А вообще качество работы команды определить можно только по тому,
B>>>>насколько довольны клиенты (заказчики).
B>>>>Довольны клиенты — значит качество хорошое, какой бы "бред" не писали бы программеры...

B>>>Увы, но это только одна из граней качества ... хотя для проектов типа "fire and forget" вполне прокатит.

B>>Если действовать по принципу "fire and forget", то клиенты долго довольны не будут
B>>Так что критерий качества "доволен ли клиент" в целом верен.
B>>Сделать клиента довольным очень непросто, а вот недовольным — раз плюнуть.
B>>Тут тебе и сроки, и гибкость, и нужные фичи в срок и все все все...

B>но, если у вас достаточно навороченная по функционалу система, сделанная в очень сжатые сроки, и сделана "в лоб" с логикой на "OnButtonClick", то такая система как спагетти -- ее сложно поддерживать, модифицировать и тиражировать. А это отнюдь НЕ КАЧЕСТВЕННАЯ система!

Совершенно согласен! Но почему эта система не качественна?
Что и кто в итоге страдает от плохих требований, дизайна-спагетти и прочих
прелестей?

Здравствуйте, bkat, Вы писали:


B>>но, если у вас достаточно навороченная по функционалу система, сделанная в очень сжатые сроки, и сделана "в лоб" с логикой на "OnButtonClick", то такая система как спагетти -- ее сложно поддерживать, модифицировать и тиражировать. А это отнюдь НЕ КАЧЕСТВЕННАЯ система!

B>Совершенно согласен! Но почему эта система не качественна?
B>Что и кто в итоге страдает от плохих требований, дизайна-спагетти и прочих
B>прелестей?

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

Здравствуйте, Аноним, Вы писали:

А>Помогите с материалами на эту тему. Интересуют как теоретические , Так и практически оправдавшие себя способы оценки качества работы.

Способы оценки качества труда программиста мне не попадались. В основном работа ведется вокруг метрик ПО. Программы сравниваются на основе метрик. и уж тут косвенно получается, какая метрика лучше — значит и программист работает лучше. Метрики можно поискать по фразе metrics of program или аналогичной английский на гугле. Я помнится, кое-что выкачивал таким образом. Их очень много разных.
Немного есть на эту тему в книжке Орлова Технология разработки программного обеспечения — на сайте издательства Питер в серии Учебник.