Качество разработки
От: cruse  
Дата: 01.09.09 23:37
Оценка: 8 (1) +3 -1
Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.

Интересно было бы узнать ваше мнение.
Re: Качество разработки
От: jazzer Россия Skype: enerjazzer
Дата: 02.09.09 00:20
Оценка: 4 (1) +1
Здравствуйте, cruse, Вы писали:

C>Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


C>Интересно было бы узнать ваше мнение.


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

http://en.wikipedia.org/wiki/Software_metrics
http://en.wikipedia.org/wiki/Programming_Complexity
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Качество разработки
От: Sinix  
Дата: 02.09.09 00:22
Оценка:
Здравствуйте, cruse, Вы писали:

C>Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


Определение качества по косвенным индикаторам? Интересная метрика. По крайней мере не хуже метрик кода. Добавил бы "стоимость изменений" и "стоимость вхождения в проект". Измерять в процентах, 100 — та самая легендарная кнопка "сделай мне всё".

На самом деле качество — весьма больная тема, особенно из-за популярности ИСО-9000 и ко. Там вообще заходят ещё дальше и определяют качество как степень удовлетворённости потребителя. Для массовых продуктов (особенно в сфере услуг) достаточно эффективно, если употреблять с умом. Мне в этом плане куда больше нравятся японские принципы управления качеством, например дзидока+канбан, т.к. они больше ориентированы на достижение качества, чем на управление формальной стороной процесса. Для начала можно посмотреть http://msd.com.ua/articles/14prinmenedj/, если хватит терпения

Но это я увлёкся
Re[2]: Качество разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.09.09 06:45
Оценка: :))) :))) :))
Здравствуйте, Sinix, Вы писали:

S>Но это я увлёкся

Да ну.

Вообще, на чем держался авторитет отдела, мне было совершенно непонятно. Время от времени сотрудники делали доклады на странные темы, вроде: "Относительно выражения глаз авгура" или "Предикторские свойства гущи из-под кофе мокко урожая 1926 года". Иногда группе менеджеров удавалось что-нибудь правильно предсказать, но каждый раз они казались такими удивленными и напуганными своим успехом, что весь эффект пропадал даром. Архитектор проекта, человек деликатнейший, не мог, как было неоднократно отмечено, сдержать неопределенной улыбки каждый раз, когда присутствовал на заседаниях семинара проджект и програм менеджеров.

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Качество разработки
От: cruse  
Дата: 02.09.09 09:40
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Определение качества по косвенным индикаторам? Интересная метрика. По крайней мере не хуже метрик кода. Добавил бы "стоимость изменений" и "стоимость вхождения в проект". Измерять в процентах, 100 — та самая легендарная кнопка "сделай мне всё".


S>На самом деле качество — весьма больная тема, особенно из-за популярности ИСО-9000 и ко. Там вообще заходят ещё дальше и определяют качество как степень удовлетворённости потребителя. Для массовых продуктов (особенно в сфере услуг) достаточно эффективно, если употреблять с умом. Мне в этом плане куда больше нравятся японские принципы управления качеством, например дзидока+канбан, т.к. они больше ориентированы на достижение качества, чем на управление формальной стороной процесса. Для начала можно посмотреть http://msd.com.ua/articles/14prinmenedj/, если хватит терпения


На мой взгляд, время жизни тесно связано с удовлетворенностью потребителя. В конечном итоге будет ли заказчик держать в поле своего внимания не нужную ему разработку? Скорее всего переключиться на что либо другое, а сама разработка рассыпится, растает в пространстве.
Re[2]: Качество разработки
От: cruse  
Дата: 02.09.09 10:04
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Критериев миллион, начиная от того, как программа работает (фичи, скорость, эргономичность и т.п.), до того, как она написана (количество багов, читабельность кода, легкость поддержки и т.п.)


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

Мое мнение, каждый критерий из миллиона сыграет свою роль и отразиться на времени жизни. Вот смотрите. Разработчик не уловил цели проекта — проект оказался не нужным заказчику. Сдал сырой — посыпались глюки, эксплуатация застопорилась. Не смог доступно представить, внедрить — не вызвал интереса, либо эксплуатация заказчиком "через силу". Если нет качественной документации/справки, то даже если было проведено обучение текущих пользователей, все равно это скажется, когда у заказчика примут новых. А новые как правило приходят со своим инструментарием, так что если программа не ахти, то и жить ей недолго.
Re: Качество разработки
От: Mamut Швеция http://dmitriid.com
Дата: 03.09.09 07:13
Оценка:
c> Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.

c> Интересно было бы узнать ваше мнение.



Программа выполняет то, что надо, без вмешательства разработчика. Под «то, что надо» подразумевается (правильные вычисления + примелемые сроки). Причем если первое еще более-менее объективно, то второе зависит от заказчика
avalon 1.0rc2 rev 295, zlib 1.2.3 (01.08.2009 02:47:12 EEST :z)(Qt 4.5.1)


dmitriid.comGitHubLinkedIn
Re: Качество разработки
От: Кодёнок  
Дата: 03.09.09 08:36
Оценка: 12 (1)
Здравствуйте, cruse, Вы писали:

C>Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


Можно определить так. Программа — это решение какой-то проблемы. Качество решений в общем случае имеет такую градацию:

1. Гениальное — малыми и конечными усилиями превратить проблему в полезное свойство.

2. Талантливое — малыми и конечными усилиями решить проблему или сделать чтобы она самоустранялась.

3. Нормальное — раз и навсегда решить проблему сопоставимым с ней количеством усилий.
Пример: на рабочем столе из ниоткуда появляются файлы. Найти процесс-источник и удалить его.

4. Уровень уборщика — приставить к проблеме "уборщика" который будет работать вместе с ней и устранять ее.
Пример: на рабочем столе из ниоткуда появляются файлы. Написать процесс, убивающий эти файлы по мере их появления.

5. Уровень халтурщика — приставить к проблеме нечто, что будет работать вместе с ней и маскировать ее присутствие.
Пример: на рабочем столе из ниоткуда появляются файлы. Сделать из скриншота засранного рабочего стола обои, на фоне которых лишние файлы просто не видны

6. Отсутствие решения или усугубление проблемы.

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

ур.1 разработки — если удалось не только не писать программу, но еще и пользу извлечь
ур.1 программы — если пользователю не только ни о чем заботиться не надо, но еще и польза какая-то идет

ур.2 разработки — если нашли уже готовую живую программу (которую кто-то другой разрабатывает и поддерживает)
ур.2 программы — если пользователь решает свои задачи однократным применением (установкой или одним запуском)

ур.3 разработки — написать так, чтобы потом апдейты не требовались
ур.3 программы — чтобы решить свои проблемы, юзеру надо что-то дополнительно сделать в программе

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

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

В жизни бывает, что решить не удалось или выше уровня 4 не пройти, но нормальные работники интуитивно держат планку не ниже уровня 3 и время от времени выдают талантливые решения. Одной из задач главного программиста в этой модели — пресекать попытки провести решение 4/5, например выставление try catch (...) {} вместо поиска причины эксепшена это уровень 5 и поэтому идет лесом по причине ужасного качества.
Re: Качество разработки
От: bkat  
Дата: 03.09.09 16:21
Оценка:
Здравствуйте, cruse, Вы писали:

C>Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


Если исходить из того, что все делается для людей,
то качество — это в первую очередь довольный пользователь (они бывают очень разные).

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

2) Работа с программой должна быть комфортной.
Сюда можно отнести и скорость реакции, дружесвенный интерфейс, надежность и пр...

3) В случае новых фич или багов, пользователь не будет ждать годами,
пока его проблема будет решена. Это можно обеспечить расширяемостью,
хорошим дизайном, качественным кодом и хорошей внутренней документацией.

А в общем тема очень обширная, сложная и в общем-то хорошо исследована.
Твое же определение слишком общее, допускает кучу интерпретаций и потому бесполезное.
Re: Качество разработки
От: IT Россия linq2db.com
Дата: 03.09.09 17:36
Оценка:
Здравствуйте, cruse, Вы писали:

C>Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


Это не качество разработки, а качество продукта. Например, из посредственного кода можно вытянуть приемлемого качества приложение путём более тщательного тестирования. Но код как был плохого качества, так таким и останется, а скорее всего станет ещё хуже из-за хаков, применяемых при латании дыр.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Качество разработки
От: cruse  
Дата: 04.09.09 14:49
Оценка:
Здравствуйте, IT, Вы писали:

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


C>>Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


IT>Это не качество разработки, а качество продукта.


Ок, пусть будет продукт.

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


Хорошо, а разве одно с другим не связано? Я имею ввиду латание дыр и закат продукта, утраты интереса к нему со стороны пользователя.
Re[3]: Качество разработки
От: IT Россия linq2db.com
Дата: 04.09.09 15:51
Оценка:
Здравствуйте, cruse, Вы писали:

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


C>Хорошо, а разве одно с другим не связано? Я имею ввиду латание дыр и закат продукта, утраты интереса к нему со стороны пользователя.


Связано, но как я уже сказал, эта связь может быть существенно ослаблена тщательным тестированием.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Качество разработки
От: fmiracle  
Дата: 06.09.09 14:34
Оценка: 21 (4)
Здравствуйте, cruse, Вы писали:

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


C>Хорошо, а разве одно с другим не связано? Я имею ввиду латание дыр и закат продукта, утраты интереса к нему со стороны пользователя.


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

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

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

Как правильно сказано было — критериев миллион, и первым делом для оценки качества продукта нужно из них выбрать те, которые реально важны в данном случае.


А "качество разработки" — это вообще в другую степь и относится к оценки собственно разработки в плане возможности получения в заданный срок продукта, удовлетворяющего заранее выбранным критериям.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[4]: Качество разработки
От: cruse  
Дата: 06.09.09 22:47
Оценка:
Здравствуйте, fmiracle, Вы писали:

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

F>Подобный проект может не выйти никогда, особенно если речь идет о какой-то внутренней системе.

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

F>Далее, ты оцениваешь только качество продукта в плане "хорошести, самодостаточности и надежности".

F>Но если мы говорим про софт под заказ, то встает очень важный вопрос — цена. Очень может оказаться, что в плане цены заказчику будет значительно выгоднее получить продукт, при котором будет постоянно сидеть разработчик и каждую неделю править баги, чем сразу оплатить более дорогую (протестированную, доведенную) версию продукта, которая вообще не требует поддержки.

Точно ли выгоднее по цене? Например, один разработчик на 30000 руб (в год 360000) будет выгоднее какого продукта?

F>Или критерий время разработки. Запросто может оказаться так, что нужно выпустить пусть даже сырой и дырявый продукт к какому-то сроку (застолбить нишу, успеть заключить контракты на выставке, начать вести работы над чем-то при помощи данного средства) и потом его постепенно доводить до ума уже в производстве. И при этом неуспевание к сроку означает полную ненужность проекта. Или неполную ненужность, а есть какая-то кривая, по которой чем раньше выпустишь, тем гораздо-гораздо больше пользы, оправдывающей даже частичную недееспособность проекта.


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

F>А "качество разработки" — это вообще в другую степь и относится к оценки собственно разработки в плане возможности получения в заданный срок продукта, удовлетворяющего заранее выбранным критериям.


Ранее я уже поправился, что имел ввиду разработка в значении результат, а не процесс. Самая наверное близкая аналогия — это кино. После выпуска в прокат первый раз его может посмотрят все, но во второй, третий плохой фильм смотреть не будут (может только если нет альтернатив ).
Re[5]: Качество разработки
От: bkat  
Дата: 07.09.09 06:41
Оценка:
Здравствуйте, cruse, Вы писали:


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


Аналогии практически всегда лживы.
В ресторане то, что ты описал не пройдет. Не пройдет и со многими другими продуктами.
А с программными продуктами проходит, если он уже на ранних стадиях способен
решать задачи пользователя.
Сырое же мясо на твоем столе твои ожидания скорей всего вообще никак не удовлетворяет.
Re[3]: Качество разработки
От: jazzer Россия Skype: enerjazzer
Дата: 09.09.09 03:11
Оценка:
Здравствуйте, cruse, Вы писали:

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


J>>Критериев миллион, начиная от того, как программа работает (фичи, скорость, эргономичность и т.п.), до того, как она написана (количество багов, читабельность кода, легкость поддержки и т.п.)


C>А хорошо ли это, когда миллион критериев? Когда я пытаюсь "приложить" их к проекту, возникает целый лабиринт, причем эти критерии еще и воюют между собой.


Что значит — хорошо, не хорошо?
У каждого проекта свои нужды, и в каждом будет свой набор критериев, которые именно для этого проекта важны.
Например, критерии программы для удаленного заказчика радикально отличаются от критериев программы, которую ты пишешь для себя.
И т.д. и т.п.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Качество разработки
От: ili Россия  
Дата: 09.09.09 12:41
Оценка:
Здравствуйте, cruse, Вы писали:

C>Интересно было бы узнать ваше мнение.


1. удовлетворенность заказчика
2. удовлетворенность разработчика

это продукта, у кода тоже есть своё качаство, но об этом IT выше писал
Re[4]: Качество разработки
От: cruse  
Дата: 09.09.09 19:34
Оценка:
Здравствуйте, IT, Вы писали:

IT>Связано, но как я уже сказал, эта связь может быть существенно ослаблена тщательным тестированием.


"Некрасивые самолеты не летают" А. Туполев
Re[5]: Качество разработки
От: IT Россия linq2db.com
Дата: 09.09.09 20:09
Оценка: :)
Здравствуйте, cruse, Вы писали:

IT>>Связано, но как я уже сказал, эта связь может быть существенно ослаблена тщательным тестированием.


C>"Некрасивые самолеты не летают" А. Туполев


В софтостроении летают, но нызэнько, например как тут.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Качество разработки
От: LaptevVV Россия  
Дата: 10.09.09 13:33
Оценка:
Здравствуйте, cruse, Вы писали:

C>Помню спросили "по каким критериям вы оцениваете программу (разработку, проект)". Сам не ожидая, выпалил "По времени, которое программа может жить без вмешательства разработчика". С одной лишь оговоркой, расширение не требуется или расширение функциональности это другая разработка.


Вообще качества два.
1. Внешнее качество для пользователя.
2. Внутреннее качество самой программы.
Это разные качества, хотя кореллируют. Вернее, внутреннее качество, как правило, определяет и внешнее качество, хотя у внешнего качества есть свои фишки, внутренним качеством не определяемые.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.