Гарантируют ли стандарты качество продукта?
#21
Отправлено 06 октября 2004 - 11:26
Перефразируя анекдот, я бы сказала, что гарантируется 50% качества. Либо получится КАЧЕСТВЕННЫЙ продукт, либо не получится :).
В любом случае, это будет субъективное мнение одного определенного человека.
#22
Отправлено 06 октября 2004 - 11:40
Но той же бабушке проще, удобнее и выгодней поймать за руку человека, который явно собирается переходить через дорогу в приблизительно нужном направлении, чем искать сертифицированного специалиста по переводу бабушек через улицу, знающего ПДД города №, подходящего роста, возраста и т.д., после чего объяснять ему как ее нужно переводить через дорогу, какими шагами, как сильно держать ее за руку и т.д....Я потому и усомнился в качестве, так как требования бабушки Вы ведь не узнали? Просто повели ее в неизвестном (удача - если совпало :)) направлении. Ваше качество будет очень субъективное. Бабушка может думать совсем по-другому.Я смогу перевести бабушку, вполне случайно, так что полностью удовлетворю все её требования по переводу: скорость движения, давление на руку, конечній пункт (другая сторона).
То есть у неё будут невысокие требования - я окажу услуги согласно её требованиям, то есть окажу качественную услугу, соответсвующую требованиям + в нужное время, в нужном месте.
Другое дело, если нужно перевезти выручку из супермаркета в банк.
PS: Есть цель и есть средства. Есть стандарты, которые помогают найти общий язык при требованиях выше низкого :). Но не больше.
#23
Отправлено 06 октября 2004 - 12:10
:P
Case абсолютно прав, возможно оказать качественную услугу совершенно не заморачиваясь на всякие стандарты. Если у вас есть слаженная сильная команда, способная ответственно трудиться над проектом, то возможно, что вы и преуспеете в нем.
:ph34r:
Стандарты нужны совершенно для другого!
Их задача описать принципы построения процессов по разработке РАЗЛИЧНЫХ проектов ЛЮБОГО РАЗМЕРА и ЛЮБОЙ СЛОЖНОСТИ командой ЛЮБОГО УРОВНЯ ПОДГОТОВКИ с ОДИНАКОВЫМ УРОВНЕМ УСПЕХА.
Это означает, что независимо от того какая бабушка вам попадется, вы с высокой степенью вероятности сможете определить ее нужды и предложить ей адекватное решение в рамках приемлемого бюджета в согласованные сроки. И потом сможете повторить свой успех на других проектах даже если вместо ваших разработчиков придут новые сотрудники.
Одним словом это называется ТЕХНОЛОГИЯ!
B)
#24
Отправлено 06 октября 2004 - 12:29
Прошу прощения: качество продукта, это соответсвие продукта требованиям. Качество процесса -- его соответсвие требованиям к процессу. Если в требованиях к проекту не стоит уложится в срок - то мы будем его делать качественным, но долго. Если нет требований по бюджету (а это требование не к продукту и не к процессу, а к проекту или организации) - то мы в него и не вложимся, но при этом выпустим качественный продукт. Бюджет то каким местом к качеству? :)
Редактор портала www.it4business.ru
#25
Отправлено 06 октября 2004 - 12:30
Также как и политическая обстановка в стране и мире. А по существу? Бюджет и сроки - это параметры проекта по разработке, а не параметры продукта.
Редактор портала www.it4business.ru
#26
Отправлено 06 октября 2004 - 12:35
Технология абсолютно не гарантирует высокое качество продукта.Одним словом это называется ТЕХНОЛОГИЯ!
B)
Она всего лишь описывает best practices на основании предыдущих успешных проектов различных организаций. Ее задача систематизировать деятельность по созданию продукта и ввести количественные характеристики, позволяющие контролировать процесс разработки.
#27
Отправлено 06 октября 2004 - 13:19
Case,А по существу? Бюджет и сроки - это параметры проекта по разработке, а не параметры продукта.
формально ты прав.
Только я не представляю, как проект по разработке продукта и продукт, получаемый в результате разработки, могут жить отдельно друг от друга.
Это софистика!
:P
#28
Отправлено 06 октября 2004 - 13:30
На самом деле все очень просто.Стандарт к бюджету каким местом?..
Прошу прощения: качество продукта, это соответсвие продукта требованиям. Качество процесса -- его соответсвие требованиям к процессу. Если в требованиях к проекту не стоит уложится в срок - то мы будем его делать качественным, но долго. Если нет требований по бюджету (а это требование не к продукту и не к процессу, а к проекту или организации) - то мы в него и не вложимся, но при этом выпустим качественный продукт. Бюджет то каким местом к качеству? :)
Берем одну и туже организацию, один и тот же проект в одни и теже сроки, но даем два разных бюджета. Качество какого будет выше?
B)
Теперь берем один и тот же проект с одинаковым бюджетом и одинаковыми сроками, но предлагаем его разным организациям (ни одна из которых не имеет опыта в этой области разработки), но одна из них сертифицирована на CMMI 5 уровня, а другая не имеет вообще ни какого сертификата.
Какой из этих двух организаций вы предпочтете отдать заказ?
B)
Ответ на эти простые вопросы покажет связь технологии и бюджета с качеством продукта.
#29
Отправлено 06 октября 2004 - 13:41
Нельзя сказать. Можно и денег дать и времени и ничего не выйдет. Можно убиться об стенку и ничего из них не выжать. Я работал над такими проектами :) Ещё будучи студентом. И денег давалось много и времени. А проект как был... там и лежит. НИКАКОЙ строгой взаимосвязи с качеством.Качество какого будет выше?
Будет мало - с большей вероятностью получат фигню. Дадут больше - никто качества не гарантирует.
Второй пример чётче - однако так можно сравнить всё-что угодно. Вопрос в том, что соимость проекта будет ОЧЕНЬ разная если отдать в контору где СММ есть (тем паче СММ 5) и там где его нет.
На качество продукта влияет только качество процесса. На качество процесса влияет его отточеность и формализация. Но никак не стоимость проекта и его бюджет.
Хотите другой пример? Художник. На работе по всем стандартам делает картинки на ширпортеб. Стабильно - в срок и рамках бюджета. Дома для себя делает шедевр. Один раз - продаёт за миллионы. Вопрос только в том что нужнее - раз в жизни шедевр или каждый день картинка. Вы сравниваете примерно также, Сергей.
Редактор портала www.it4business.ru
#30
Отправлено 06 октября 2004 - 13:48
Запросто. Ты оперируеш ситауцией когда продукт=проект. Абстрагируйся от реалий. Мы не конкретную проблему разбираем. Прикинь чуть шире. Оторвись от ситуцаии когда над тобой заказчик со сроками и деньгами - над тоой заказчик с желанием качества. DOD!Только я не представляю, как проект по разработке продукта и продукт, получаемый в результате разработки, могут жить отдельно друг от друга.
Есть компания, которая производит софт. Есть два подразделения, которые делают один и тот же проект не опираясь ни на бюджет ни на сроки. Лаборатория, раз уж мы говорим о качестве. Я утверждаю, что можно достичь результатов и там и там - сделать качественный продукт. Но вот делать это постоянно, гарантируемо повторяемо можно только с помощью применения стандартов, которые будут адаптированны в процессу. Я только это и пытаюсь говорить.
Внедрение и применения стандартов будет гарантировать качество продукта, если это стандарт описывает процесс, который уже приносил качественный продукт. То есть стандарт может гарантировать только повтояремость. Делай также - получишь тоже. Какое тоже? Какое получили в результате того, с чего писали стандарт.
Редактор портала www.it4business.ru
#31
Отправлено 06 октября 2004 - 14:12
Я молчал, не высказывал своё мнение, хотя неявно агитировал за ответ "нет" на поставленный вопрос :)Только я не представляю, как проект по разработке продукта и продукт, получаемый в результате разработки, могут жить отдельно друг от друга.
Пришло время сказать несколько слов в защиту стандартов и моделей, а то "нет" стало перевешивать. :)
USDP (и, видимо, следом за ним RUP) даёт такие соотношения:
* процесс -- это шаблон проекта
* продукт -- это результат проекта
Логика за этим скрывается следующая (как и за другими моделями и за стандартами).
Предположим, что некая организация выполнила 10 проектов, которые удовлетворяли определённому шаблону, иными словами -- следовали определённому процессу. Предположим также, что в этих 10-ти проектах были достигнуты определённые значения показателей качества продукта (то есть произведённого результата).
Из этого делается вывод, что если очередной 11-ый проект будет удовлетворять тому же шаблону, значения показателей качества продукта будут не ниже.
Согласитесь, вполне разумное предположение.
Конечно, гарантий никаких нет. Почему? Нет, не потому что "стандарты не могут". Причина в другом. Давайте на какое-то время поверим во всемогущество стандартов.
Посмотрим на описанную выше ситуацию с 10-ю проектами. Предположим, что в этих 10-ти проектах выполнялись все мыслимые и немыслимые стандарты, и процесс, который суть шаблон этих проектов, тоже удовлетворяет всем стандартам, каких только душа пожелает.
Начинается очередной 11-ый проект. Начинается с благими намерениями удовлетворить всем тем же стандартам, потому что он будет следовать тому же самому процессу. Но заранее гарантировать, что он будет ему следовать нельзя. Только когда проект завершится, можно сказать -- да, он следовал процессу, да, он соответствовал всем требованиям и стандартам. Но только после того, как он завершится.
А во время выполнения проекта можно пользоваться шаблоном как руководством к действию, как путеводной нитью, которая поможет не уйти в неправильном направлении.
С этой точки зрения предлагаемые модели и стандарты есть не что иное как обобщённый опыт многих людей, которые уже наступали на разные грабли и знают, где они разложены и дожидаются очередную жертву. Это -- механизм переиспользования процессов. Статья в журнале Methods & Tools, которую я не так давно анонсировал в колонке новостей очень хорошо и понятно этот тезис излагает. Весьма рекомендую.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#32
Отправлено 06 октября 2004 - 14:35
мы про одно и тоже!
:P
Хотя я не согласен с некоторыми доводами Case-а, но мы втроем выразили одно и тоже мнение.
При применении на предприятии устоявшихся процессов качество разработок будет выше (при условии соблюдении стандартов на эти процессы).
#33
Отправлено 06 октября 2004 - 14:42
Эту тему читают:
3 Пользователей: Case, barancev, Green
Идеологи, блин :)
Редактор портала www.it4business.ru
#34
Отправлено 06 октября 2004 - 14:52
Соглашусь.При применении на предприятии устоявшихся процессов качество разработок будет выше
Но не следование стандартам! Ну вот есть станарт, его адаптировать надо - и от этого будет зависеть как применять. Я уже не говорю что стандарт для начала нужно выбрать :)
Редактор портала www.it4business.ru
#35
Отправлено 07 октября 2004 - 04:37
Это, кстати, одно из первых требований стандарта 12207Ну вот есть станарт, его адаптировать надо - и от этого будет зависеть как применять.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#36
Отправлено 07 октября 2004 - 05:45
Программный продукт - результат процесса разработки. Есть в 12207 и процесс обеспечения качества - его результат качественный продукт :). Выполняешь требования процессса - получаешь качественный продукт.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#37
Отправлено 07 октября 2004 - 05:50
Не уверен, цель устоявшихся (адаптированных?) процессов может быть далека от целей обеспечения качества.При применении на предприятии устоявшихся процессов качество разработок будет выше (при условии соблюдении стандартов на эти процессы).
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#38
Отправлено 07 октября 2004 - 05:56
Почему нельзя гарантировать заранее, что проект будет следовать качественному процессу?Начинается очередной 11-ый проект. Начинается с благими намерениями удовлетворить всем тем же стандартам, потому что он будет следовать тому же самому процессу. Но заранее гарантировать, что он будет ему следовать нельзя. Только когда проект завершится, можно сказать -- да, он следовал процессу, да, он соответствовал всем требованиям и стандартам. Но только после того, как он завершится.
Сертификация как раз это и подтверждает.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#39
Отправлено 07 октября 2004 - 06:15
Давайте рассмотрим пример из со-о-овсем другой области.Почему нельзя гарантировать заранее, что проект будет следовать качественному процессу?Начинается очередной 11-ый проект. Начинается с благими намерениями удовлетворить всем тем же стандартам, потому что он будет следовать тому же самому процессу. Но заранее гарантировать, что он будет ему следовать нельзя. Только когда проект завершится, можно сказать -- да, он следовал процессу, да, он соответствовал всем требованиям и стандартам. Но только после того, как он завершится.
Сертификация как раз это и подтверждает.
Прыгун в высоту. Хороший прыгун. Гарантированно прыгает 2 метра, даже выше может, но 2 метра -- гаратированно. Имеет сертификат "Прыгун на 2 метра". Как он его получил? Сертификационная организация проверила, что 1000 последних прыжков была не ниже 2 метров и на основании этого выдала сертификат.
Но вот кто-то бросил шкурку от банана как раз в тот момент, когда он собирался сделать 1286-й прыжок, и она упала ему под ноги, и он поскользнулся и сшиб планку. Кошмар! Да нет, ничего страшного, ногу-то не сломал, в следующий раз он снова прыгнет выше двух метров. Не надо отбирать у него сертификат. Он всё ещё хороший прыгун. Но прыгнуть не смог.
Вывод: все предыдущие прыжки вместе взятые и даже подкреплённые сертификатом не гарантируют, что и этот очередной будет тоже успешным.
Сертификация подтверждает, что организация знает как и умеет следовать качественному процессу. Но она не даёт гарантий для данного конкретного проекта.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#40
Отправлено 07 октября 2004 - 08:04
Если это качественный прыгун и он следует требованиям, он не остановится пока не прыгнет на два метра, даже если первый раз ему это не удалось.Прыгун в высоту. Хороший прыгун. Гарантированно прыгает 2 метра, даже выше может, но 2 метра -- гаратированно. Имеет сертификат "Прыгун на 2 метра". Как он его получил? Сертификационная организация проверила, что 1000 последних прыжков была не ниже 2 метров и на основании этого выдала сертификат.
Но вот кто-то бросил шкурку от банана как раз в тот момент, когда он собирался сделать 1286-й прыжок, и она упала ему под ноги, и он поскользнулся и сшиб планку. Кошмар! Да нет, ничего страшного, ногу-то не сломал, в следующий раз он снова прыгнет выше двух метров. Не надо отбирать у него сертификат. Он всё ещё хороший прыгун. Но прыгнуть не смог.
Вывод: все предыдущие прыжки вместе взятые и даже подкреплённые сертификатом не гарантируют, что и этот очередной будет тоже успешным.
Сертификация подтверждает, что организация знает как и умеет следовать качественному процессу. Но она не даёт гарантий для данного конкретного проекта.
Именно для того, чтобы не было таких "брошенных" прыжков и существуют требования стандартов по обеспечению качества. Прыгун должен прыгать до тех пор, пока не перепрыгнет. И заказчик знает, прыгун будет прыгать, а не плюнет и скажет, что "в следующий раз". И вот это я называю гарантия качества и этого требует стандарт. Прыгать не до обеда (или один раз), а прыгнуть на определенную высоту, и не важно сколько раз придется прыгнуть для этого. Хотя в другой ситуации, возможно, потребуется прыгать до обеда. Значит качественный будет тот прыгун, который будет прыгать до обеда.
Заказчик не любит случайностей. Все должно быть определено и измерено. ГОСТ нужен заказчику, а не производителю изначально. Здесь палка о двух концах, на одном конце один поставщик, у которого, возможно, "толковые ребята", на другом - поставщик с гарантированным качеством услуги. Где заказчик? Особенность системы менеджмента качества как раз и заключается в том, что стоимость услуги не увеличивается(даже сокращается). Заказчику должно гарантироваться качественное исполнение заказа. А сколько это стоит (сколько раз нужно прыгнуть), это не проблема качества (хотя, возможно, проблема заказчика). Возьмите такой пример: без ТЗ сложно оказывать качественные услуги, с этим все согласны (кроме бабушки :)). Сколько будет стоить разработка продукта без ТЗ, или по ТЗ? Заказчику? Разработчику? (Я уже не говорю о рисках вообще не получить продукта). Но получение продукта - лишь доля работ по получению прибыли. Его нужно качественно подать, качественно поддержать и т.д. Вот у разработчика есть продуктный стандарт. Продукт удовлетворяет требованиям заказчика сегодня. А завтра? Заказчику, необходимо чтобы и завтра он удовлетворял его требованиям. А где это требование прописано? В процессном стандарте :). Вот и понятие возникло - жизненный цикл. Требования стандарта - обеспечение качества на протяжении всего жизненного цикла. Хочешь мертвую программу - пожалуйста, говорят, есть нетленные тела. Лично мне нужна программа без запаха. "Программа умирает", если не поддерживается и не обслуживается. Прыгун дряхлеет и чахнет, банан гниет. Но появится новый прыгун, вырастет новый банан. Появится другая программа и другой разработчик на нашем месте, если мы не будем качественно исполнять заказ.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных