Гарантируют ли стандарты качество продукта?

Viktor,

Вы полностью соответствуете выбранному Вами псевдониму!

Какова основная мысль в Вашем предыдущем сообщении?

B)

Viktor,

Вы полностью соответствуете выбранному Вами псевдониму!

Спасибо

Какова основная мысль в Вашем предыдущем сообщении?

B)

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

Нельзя бросать дело, не доделав его до конца. Особенно, когда за этот конец заплатили и его ждут :).

А разве, кто-то с этим спорит?

B)

Нельзя бросать дело, не доделав его до конца. Особенно, когда за этот конец заплатили и его ждут :).

А разве, кто-то с этим спорит?

B)

Никто, наверное, просто размышляем :)
Вот, например, если все с этим согласны, то как это гарантировать?
Мой тезис такой - Качество процесса - гарантия доведения проекта до качественного конца.
Чем меньше качество процесса - тем меньше гарантии.
Алексей требует ответа "Да или Нет". Я сказал "Да"
Человек 8, мне кажется, вот здесь уже возразят.

Возьмите такой пример: без ТЗ нельзя оказывать качественных услуг, с этим все согласны (кроме бабушки :)).

Не только бабушка, я тоже с этим не согласен :)

Возьмите такой пример: без ТЗ нельзя оказывать качественных услуг, с этим все согласны (кроме бабушки :)).

Не только бабушка, я тоже с этим не согласен :)

Хорошо, заменяю "нельзя" на "сложно". Хотя для меня это одно и тоже.

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

Для этого нужен не стандарт, а правильно договор заключать. Если прыгуну скажут, что деньги он получит только после того, как прыгнет на 2 метра, он будет прыгать, чтобы их получить. Даже без всякого сертификата, вот так просто: прыгнет -- получит, не прыгнет -- не получит. Вот и всё.

Заказчик не любит случайностей. Все должно быть определено и измерено. ГОСТ нужен заказчику, а не производителю изначально.

Вот это уже, по-моему, очень близко к истине. Кто был на докладе С.И.Мильмана на QA Days должно быть слышал, что он говорил по этому поводу: проблема русских не в том, что они плохо работают и делают некачественные продукты, нет, проблема в том, что нужно это показать, продемонстрировать. И вот тут приходят на помощь стандарты. Нет, они не гарантируют выпуск качественного продукта. Но они помогают убедить заказчика, в том, что организация может выпустить качественный продукт. А чтобы она его действительно выпустила, нужен хороший договор с приложением, в котором описано, какие именно характеристики качества требуются и что с ней (организацией) будет, если она не достигнет заданных показателей. Вот это -- стимул!

Хороший договор - тоже требование процессного ГОСТа

Хороший договор - тоже требование процессного ГОСТа

Кто спорит. Я просто имел в виду, что иногда его (хорошего договора) и одного достаточно.
Стандарт не гарантирует, что разработчик будет за свои деньги исправлять ошибки, а договор -- гарантирует.

Стандарт не гарантирует, что разработчик будет за свои деньги исправлять ошибки, а договор -- гарантирует.

За чьи деньги - это к качеству продукта не относится. Гарантия стандарта, что ошибки (если возникнут) будут исправляться (если это необходимо).

Тут уже было сказано что процесс гарантирует повторяемость но вот вопрос чего хорошего продукта или плохого с моей точки зрения главной причиной успеха является квалификация разработчиков и тестировщиков. Процесс и соблюдения стандартов это лишь способ как говорил уважаемый Остап про автомобиль. Так вот процесс это средство передвижения
Если у вас супер супер супер разработчики то они будут гнать качественный продукт в любом случае если нет то соблюдения ни каких ГОСТ и ISO вам не поможет. Простите за излишнию злобность
Второй аспект безусловное соблюдения стандартов требует дополниетльных ресурсов финанасовых и временных и вот вопрос нужен ли будет ваш возможно качественный продукт за деньги большие чем у конкурентов и за большее время. Прошу понять меня правильно я не против стандартов и процессов я как раз за только за разумное использование оных. Конфуций кажется говорил так " среднее положение мать всех положений" То есть за тспользование в качестве средства передвижения и еслт оно плохое то лучше пройтись пешком

Не могу пройти мимо!
:P

To samurai_
Однако... надо иметь хотя бы представление о вопросе, прежде чем ввязываться в драку.
(или правильно формулировать свои мысли)
<_<

1. Одна из задачь стандарта - сделать процесс разработки ПО повторяемым и не зависимым от внешних факторов, в том числе и от личности разработчика.

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

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

3. "Второй аспект"
Никто не спорит, что применение стандартов требует дополнительных ресурсов. Но сравнение по стоимости и скорости выпуска - ничто, без учета еще одной категории. КАЧЕСТВА.

1. Одна из задачь стандарта - сделать процесс разработки ПО повторяемым и не зависимым от внешних факторов, в том числе и от личности разработчика.

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

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

Если провести аналогию с правилами дорожного движения они по сути описывают процесс движения на дороге но прости плохой водитель рано или поздно попадет в аварию каккие бы не были замаечательные водители. До сих пор почему то не написано процессов и стандартов на создание теорий относительности так что абстрагироваться от уровня сотрудника крайне сложно

Никто не спорит, что применение стандартов требует дополнительных ресурсов. Но сравнение по стоимости и скорости выпуска - ничто, без учета еще одной категории. КАЧЕСТВА

Пример Windows есть много притензий к качеству этой системы обоснованных и не очень. Лично мне так очень нравится эта система не смотря на то что я провел много времени работая под UNIX подобными системами. Причина очень проста они воввремя заняли пустующую нишу пускай не очень качественным продуктом теперь они бессмертны.
Еще раз я за стандарты и процессы только в разумных пределах в этом мы с вами кажется солидарны и без утопических целей

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

А как же принцип Наполеона? :) Я не комментирую саму тему, только это предложение.

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

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

PS
Если не сложно используйте заглавные буквы и знаки препинания. Читать - глаза сломаешь.

Пример Windows есть много притензий к качеству этой системы обоснованных и не очень. Лично мне так очень нравится эта система не смотря на то что я провел много времени работая под UNIX подобными системами. Причина очень проста они воввремя заняли пустующую нишу пускай не очень качественным продуктом теперь они бессмертны.
Еще раз я за стандарты и процессы только в разумных пределах в этом мы с вами кажется солидарны и без утопических целей

При чём тут одно к другому?.. Ниша, качество...

Простите, вы творческий разработчик? Ничего личного, я просто никак не поспеваю за вашим прыжком мысли. Если есть желание поговорить на тему ниши и бессметрия корпораций - нет проблем, новая тема в соответсвующем разделе форума, к примеру в Баре "CheckPoint". Можете найти много единомышленников и спорщиков.

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

А как же принцип Наполеона? :) Я не комментирую саму тему, только это предложение.

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

:D

Цитата из кого-то:
"Самый удачный экспромт - заранее подоготовленный."

Простите, вы творческий разработчик?

Я творческий тестировщик

Про творчество в тестировании, тоже лекцию прочтёте?

зачем "сервер тестировщиков" доказывает это своим успешным существованием