Сообщений в теме: 43

[Alfa]

Так если менеджер не может выставить приоритеты, то он не может ничего сказать о качестве!

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

[zemljak]

Ага, главное чтобы такая погрешность не была 100% А если менеджер не понимает, какие фичи в ПО имеют первостепенное значение, а какие - второстепенное, то примерно такая погрешность и будет. Отсюда вопрос - оно (оценка\сравнение качества билдов) вам надо?

[Alfa]

Ага, главное чтобы такая погрешность не была 100% А если менеджер не понимает, какие фичи в ПО имеют первостепенное значение, а какие - второстепенное, то примерно такая погрешность и будет. Отсюда вопрос - оно (оценка\сравнение качества билдов) вам надо?

Можно получить неоднозначные (или бредовые) результаты даже если погрешность первоначалных значений будет меньше 100%, например 10%. Я это показал ранее. Менеджер вероятно знает какие фичи первостепенны, какие нет. Но если эта значимость выражается численно, то он не знает это с абсолютной точностью.

Пусть есть две сборки с показателем качества 0.573 и 0.546 посчитанно как в примере AHP.
Вопрос: Какая из них более качественна?
Ответ: они одинаковые. т.к. применяя предложенный вами метод расчетов (AHP) мы получим погрешность 20%.
Имеем 0.573+-0.1 и 0.546+-0.1 т.е. на самом деле 0.6+-0.1 и 0.5+-0.1.
Это два одинаковых значения. Если не учитывать погрешности то значения разные, но только потому, что вычисления некорректны.

zemljak у вас есть свой вариант ответа на этот вопрос?

[Green]

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

1. Малый – Косметические дефекты, опечатки.
2. Средний - Дефект, проявляющийся в неправильной работе функциональности
3. Большой - Дефект, проявляющийся в отказе функциональности
4. Критический – Дефект, приводящий к сбою в работе ПО, но не вызывающий фатальных последствий.
5. Фатальный – Дефект, приводящий к непредвиденному разрушению баз данных, порче файлов, поломке или зависанию операционной среды и.т.д.

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

III. Важность требования. Это заполняется при разработке требований, тем кто их разрабатывает.

В результате, Получаем матрицу, по Х - серьёзность, по У - важность требований, в пересечении количество дефектов. Весовые коэффициенты на каждую "серьёзность" у меня пока не выработаны окончательно, это скорее статистические данные по предыдущим разработкам. Приоритет в данном случае является неким поправочным коэффициентом, влияющим на важность. Ибо 150 грамматических ошибок в приложении типа Sovereign Application имеют приоритет выше чем "средний" дефект в требовании с низкой важностью.

Перемножая Важность, Серьёзность, Вес, Количество и суммируя их все мы можем получить некий "Вес дефектов ПО". К нему уже можно присматриваться и оценивать. Понятно, что весовые коэфициенты могут и даже должны корректироваться.

+5

Самый правильный подход тот, который прост в понимании и в реализации.

Я как раз собираюсь делать доклад на конференции RIT2008 (http://www.rit2008.ru/) про управление качеством. Подход который я предлагаю - это использование трассировочной матрицы (требование - функция (код) - тест - дефект). Только так можно проследить текущее состояние продукта.

Прием очень прост в применении и может быть полностью автоматизирован (при условии высокой дисциплины документирования - configuration management). При этом уровень детализации может быть разлтчным. Для not critical systems - на более высоком уровне описания, для critical systems следует использовать более детальное документирование.

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

[zemljak]

2Alfa.

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

Пусть есть две сборки с показателем качества 0.573 и 0.546 посчитанно как в примере AHP.
Вопрос: Какая из них более качественна?
Ответ: они одинаковые. т.к. применяя предложенный вами метод расчетов (AHP) мы получим погрешность 20%.

Согласен в вашим ответом лишь в том плане, что разница в качестве несущественна.
Касательно погрешностей - они будут всегда для случаев, когда оценивает человек. И никогда в жизни от погрешностей такого рода не избавиться - будь то оценки длительности проекта, либо оценки важности определенных features.

И AHP старается минимизировать эти погрешности. Для этого существуют рекомендации, кому и как выставлять данные коэффициенты. Ведь некоторые люди в принципе не могут оценить важность некоторых features для клиента.
Для минимизации погрешностей в AHP и применяется метод попарного сравнения. Кстати затем коэффициенты, полученные методом попарного сравнения, можно довольно легко перепроверить.

[KaNoN]

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

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

Логично. С этим я согласен, потому как со здравым смыслом не соглашаться, как минимум глупо. И тут даже дело не в том, какое приложение, а в том, что ошибки в ключевых компонентах важнее в рассмотрении, чем аналогичные ошибки во вспомагательных компонентах. Соответственно, вполне вероятен случай, когда серьезный баг во вспомагательном компоненте ( некорректно работает бизнес-функционал ) может быть равноценен багу средней тяжести ( отдельная часть функционала по поведению расходится с ожидаемым результатом ) в ключевом компоненте. Фактически это одна из ситуаций которую может учитывать шкала оценивания веса бага. А уже определение ключевых и неключевых компонентов и их влияние на систему - это то, что должно быть сделано еще до того, как мы начинаем мерять качество. Так что это как бы одни из входных данных, которые как-то могут повлиять на оценку качества.

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

[Bars Master]

Логично. С этим я согласен, потому как со здравым смыслом не соглашаться, как минимум глупо. И тут даже дело не в том, какое приложение, а в том, что ошибки в ключевых компонентах важнее в рассмотрении, чем аналогичные ошибки во вспомагательных компонентах. Соответственно, вполне вероятен случай, когда серьезный баг во вспомагательном компоненте ( некорректно работает бизнес-функционал ) может быть равноценен багу средней тяжести ( отдельная часть функционала по поведению расходится с ожидаемым результатом ) в ключевом компоненте. Фактически это одна из ситуаций которую может учитывать шкала оценивания веса бага. А уже определение ключевых и неключевых компонентов и их влияние на систему - это то, что должно быть сделано еще до того, как мы начинаем мерять качество. Так что это как бы одни из входных данных, которые как-то могут повлиять на оценку качества.

подписываюсь под каждой буквой.

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

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

[Alfa]

Пусть есть две сборки с показателем качества 0.573 и 0.546 посчитанно как в примере AHP.
Вопрос: Какая из них более качественна?
Ответ: они одинаковые. т.к. применяя предложенный вами метод расчетов (AHP) мы получим погрешность 20%.

Согласен в вашим ответом лишь в том плане, что разница в качестве несущественна.

Вы упустили из виду следующую мою строку.

Имеем 0.573+-0.1 и 0.546+-0.1 т.е. на самом деле 0.6+-0.1 и 0.5+-0.1.

Я утверждаяю, что разницы между значениями 0.6+-0.1 и 0.5+-0.1 нет. Это два одинаковых значения, равных с точностью до погрешности. Даже между 0.7+-0.1 и 0.5+-0.1 нет разницы, хотя это уже спорно, тут как повернуть. А вот между 0.8+-0.1 и 0.5+-0.1 есть разница.

И AHP старается минимизировать эти погрешности.

Нельзя минимизировать погрешность если не принимать ее в расчет. В методе AHP она в расчет не принимается.

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

Самое смешное, что они будут даже если оценивает машина или прибор. И для того, чтобы эту погрешность узнать или расчитать используется теория измерений. Я так понял Вы, zemljak, не знакомы с теорией измерений. Я прав?

Для этого существуют рекомендации, кому и как выставлять данные коэффициенты. Ведь некоторые люди в принципе не могут оценить важность некоторых features для клиента.
Для минимизации погрешностей в AHP и применяется метод попарного сравнения. Кстати затем коэффициенты, полученные методом попарного сравнения, можно довольно легко перепроверить.

Метод попарного сравнения там используется потому, что сравнить билд можно только с другим билдом того же приложения и сравнить пару объектов для человека проще, чем сразу упорядочить ряд. Если что-то можно перепроверить это не значит, что у величины нет погрешности. Для уменьшения погрешности можно использовать более точный прибор или усреднить по набору измерений. В методе AHP этого нет, даже если туда ввести усреднение, придется расчитывать погрешность т.к. нельзя уменьшить то, чего нет.

Суммирую вышесказанное, мое утверждение состоит в том, что использовать метод AHP без расчетов погрешности нельзя т.к. он дает не применимые результаты. А если провести расчет погрешности, то он покажет, что точность этого метода очень плохая. И снова полученный результат бесполезен.
Вот наверно об этом и спорим.

[LeshaL]

Мне описанный подход АНР понравился, хотя глубоко пока не вникал. zemljak - спасибо за ссылку! Любопытно будет попробовать применить что-либо подобное на практике и посмотреть насколько оно полезно. Я когда-то что-то подобное уже придумывал :), правда область применения несколько другая предполагалась. В данный момент идея пылится - ждет "лучших времен", может данная статья вдохнет в нее жизнь.

Alfa, во-первых, если вы считаете, что там не учитываются погрешности - улучшите формулу! Получайте значения с учетом погрешности. Или трактуйте полученные значения не забывая о погрешности.
Еще, не обязательно рассматривать получившееся в результате число - как абсолютную величину (0.5 - плохо -- 0.7 - хорошо). Если регулярно проводить подобные расчеты, то можно увидеть тенденцию, куда мы катимся (пол-года назад 0.5 - круто -- а сейчас и 0.7 - провал). В таком случае, и вправду, колебание вокруг какой-о величины с точностью +/-сколько-то не будет говорить о том, что у нас проблемы - рабочий процесс. Но общий график отразит, что колебаемся мы в пределах погрешности, но с каждым днем наш продукт становится все хуже и хуже или же лучше и лучше или мы топчемся на одном месте - может быть это и есть good enough уровень для данного проекта.
Так же будут заметны "корявые" билды, например где резко просел перформанс. Сомневаюсь, что если один из показателей сильно пострадал - то небольшие улучшения во всех остальных смогут его компенсировать. Во всяком случае, если веса расставить правильно, то так быть не должно.
И еще, данная цифра - вершина айсберга. Никто ведь не говорит, что вы должны прятать информацию по каждому параметру. Просто чем выше должность - тем меньше интересуют детали. Для руководителя проекта важна одна результирующая цифра - что текущий показатель не хуже предыдущего (с какой-то погрешностью - не спорю). Для техлида больше интересно отклонения по каждому из показателей, вы ведь можете их легко подсчитать, не так ли? Где-то они будут трактоваться как допустимые, где-то как сигнал к исправлению. Для инженера, работающего над улучшением производительности, врядли вообще будут интересны другие параметры.

[saezar]

2Green Потом с докладом можно будет ознакомиться?

[Green]

2Green Потом с докладом можно будет ознакомиться?

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

[Green]

За что я люблю русских, так за то, что хлебом их не корми, дай все усложнить и довести до абсурда. Они всегда стремятся из простой задачи сделать rocket science!


Мне как раз нужно написать тезисы доклада. Вот сейчас их и сформулирую. Пишу длинно. За что заранее прошу меня извинить. Хочу передать суть проблемы, что бы читатель мог понимать всю "подноготную" данной теории и мог воспользоваться ей на практике.



Конференция РИТ 2008

Доклад "Управление качеством".

1. Разработка программного обеспечения - это моделирование. В процессе реализации проектная команда создает целый ряд моделей, которые должны описывать или, другими словами, повторять сам продукт, его функциональность и полезные свойства. Фактически, за весь проект программа создается многое количество раз, но ее каждое "воплощение" имеет разные формы.

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

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

Третья модель - архитектура программы. В этот пункт можно включить целый ряд sub-моделей: системная, информационная, конфигурационная, дизайн пользовательского интерфейса и т.д. Каждая из них описывает отдельный аспект программы.

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

Четвертая - тестовая модель. Фактически это набор тестов, описывающих поведение системы. Это та же программа, но описанная в других терминах.

2. Если кратко выразить определение качества ПО (коих огромное множество), то оно сводится к двум понятиям:
а). программа должна делать то, что она должна делать и не должна делать того, чего она делать не должна;
б). заказчик должен быть удовлетворен.

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

Если рассмотреть логику разработки программ, то видно, что Бизнес-модель должна максимально приближаться к модели заказчика. Именно на этом основании ее пускают в работу.

Модель реализации должна максимально приближаться к Бизнес-модели, а созданная на базе Бизнес-модели Тестовая модель должна проверять и выявлять несоответствие Модели реализации первоначальным условиям.

Следовательно, программа будет качественной, если Тестовая модель выявит минимум отклонений Модели реализации от Бизнес-модели.

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

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

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

Что получаем в результате? Трассировочную матрицу, где каждому требованию в соответствие поставлена функция и тест. Отклонение моделей - дефект. Чем больше отклонений, тем больше дефектов. Чем больше дефектов устранено, тем выше степень совпадения моделей.

4. Что делать?
Любое управление - это измерение. Вначале определяется текущее состояние системы. Затем осуществляется управленческое воздействие на систему. После чего измеряется новое состояние системы.

Для управления качеством необходимо высокая дисциплина документооборота - configuration management (* сноска). Необходимо знать сколько требований запланировано к реализации в текущей версии продукта, сколько требований было реализовано и сколько тестов показали неудовлетворительный результат (сколько дефектов было обнаружено и какова их "тяжесть").

Все!
Дальше сравниваете числовые результаты с критериями качества и определяете, "проходит" или "не проходит" текущая версия программы условиям приемки.


* Сноска.
Прошу обратить внимание, что я не говорю о степени детализации документов. Здесь имеется ввиду поддержание учета в постоянном актуальном состоянии. Другими словами, вы можете не использовать use cases, не использовать test cases, не использовать описание архитектуры. Вы можете вообще не вести проектную документацию! Но для управления качеством необходимо всегда иметь три описанных категории: название требования, название функции, название тест кейса.

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

Для ознакомления с полной версией доклада предлагаю посетить конференцию РИТ 2008, либо дождаться появления видео записи выступлания в сети.

[Alfa]

Alfa, во-первых, если вы считаете, что там не учитываются погрешности - улучшите формулу! Получайте значения с учетом погрешности. Или трактуйте полученные значения не забывая о погрешности.

Я написал как ее улучшить, как внести погрешность в формулу.

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

В приведенном примере из статьи про AHP, если учитывать погрешность, 0.5 и 0.7 - одно и тоже число. По нему нельзя сделать вывод о каких-то изменениях. Нельзя увидеть тенденцию т.к. погрешность мешает.

Так же будут заметны "корявые" билды, например где резко просел перформанс. Сомневаюсь, что если один из показателей сильно пострадал - то небольшие улучшения во всех остальных смогут его компенсировать.

В приведенном примере производительность занимала 20% общего показателя. Если она будет полностью отстойной (ноль баллов), а при этом все остальные параметры не изменяться, то значение останется тем же в пределах погрешности (как и прикидывал раньше 20%). Даже компенсировать ничего не надо.

И еще, данная цифра - вершина айсберга. Никто ведь не говорит, что вы должны прятать информацию по каждому параметру.

Используйте метод AHP и Вы спрячите столько информации, что ее вообще не останется. Данная цифра - большая профанация.

Просто чем выше должность - тем меньше интересуют детали.

Точность по вашему тоже интересует все меньше с ростом должности? Вы скажите менеджеру вчера было 0.564343326887, а полгода назад 0.564343326786 - значит стало лучше??? Он вам поверит???

Господа, пока вы не поймете, что 0.5+-0.1 и 0.7+-0.1 это одно и тоже, я бессилен вас переубедить.

За что я люблю русских, так за то, что хлебом их не корми, дай все усложнить и довести до абсурда. Они всегда стремятся из простой задачи сделать rocket science!

Я так понял это комментарий мне? Это совсем не rocket science. Просто метод правильной обработки экспериментальных данных, придумал не я, а умные люди. Совсем не сложный на самом деле. Пример абсурда я привел выше в "диалоге с менеджером".

[Green]

За что я люблю русских, так за то, что хлебом их не корми, дай все усложнить и довести до абсурда. Они всегда стремятся из простой задачи сделать rocket science!

Я так понял это комментарий мне? Это совсем не rocket science. Просто метод правильной обработки экспериментальных данных, придумал не я, а умные люди. Совсем не сложный на самом деле. Пример абсурда я привел выше в "диалоге с менеджером".

Что Вы, я не имел ввиду конкретно Вас. Не стоит принимать все на личный счет.

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

Это для МЕНЯ данный метод rocket science.

[Alfa]

Это для МЕНЯ данный метод rocket science.

Так вроде James McCaffrey - автор статьи про AHP, далеко не русский. Вот я и подумал.

[Green]

Это для МЕНЯ данный метод rocket science.

Так вроде James McCaffrey - автор статьи про AHP, далеко не русский. Вот я и подумал.

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

[Green]

Небольшое отступление от темы беседы.

Я читал об одном показательном случае эффективного консультирования. К сожалению, не помню точно имен участников. Кажется, это был первый сталелитейный король Эндрбю Карнеги (если кто скинет ссылку на первоисточник, буду очень благодарен). Он объявил премию в 10000 долларов (бешеные деньги по тем временам) за эффективный совет по организации своего рабочего времени.

Знаете, какой совет победил?

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

Все!
5 минут работы и миллион долларов (приблизительно, в текущих ценах) уже в кармане.

Простота решения - гарантия его эффективности!

[zemljak]

2Alfa.

Про теорию измерений - сэкономьте мое время, дайте ссылку (если можно с примером), где вкратце описываются основы. Хочу почитать (но не хочу мучать google).

Про погрешность - я частично понял, что вы имеете ввиду. Но все же думаю, что погрешность меньше 20%. Хотя смотря по каким критериям выставлять оценки.

[LeshaL]

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

В приведенном примере из статьи про AHP, если учитывать погрешность, 0.5 и 0.7 - одно и тоже число. По нему нельзя сделать вывод о каких-то изменениях. Нельзя увидеть тенденцию т.к. погрешность мешает.
...
В приведенном примере производительность занимала 20% общего показателя. Если она будет полностью отстойной (ноль баллов), а при этом все остальные параметры не изменяться, то значение останется тем же в пределах погрешности (как и прикидывал раньше 20%). Даже компенсировать ничего не надо.
....
Господа, пока вы не поймете, что 0.5+-0.1 и 0.7+-0.1 это одно и тоже, я бессилен вас переубедить

"В греческом зале, в греческом зале"... Такое впечатление, что я с вами спорю, а вы меня переубеждаете. Я наоборот пишу, что согласен - русским по белому. Если вы меня хотите переубедить - значит вы хотите, чтобы я принял противоположную вашей точку зрения. Зачем вот только?
3.

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

Используйте метод AHP и Вы спрячите столько информации, что ее вообще не останется. Данная цифра - большая профанация.

100% обратный смысл тому, что я написал. Зачем вы выдираете одно предложение из контекста? Использовать одну абстрактную величину для оценки качества продукта - бред, ничего не выйдет. Перечитайте еще раз мой комент - я говорю, что такая величина показывает тенденцию, и не должна восприниматься как абсолютный показатель качества.
Может быть у вас монитор не исправен - и каждое второе слово или предложение не отображается?
4.

Просто чем выше должность - тем меньше интересуют детали.

Точность по вашему тоже интересует все меньше с ростом должности? Вы скажите менеджеру вчера было 0.564343326887, а полгода назад 0.564343326786 - значит стало лучше??? Он вам поверит???

Опять полное искажение моих слов и разговор на другую тему.
Я считаю, знаю и уверен на 100%, что чем выше человек занимает должность, тем меньше ему интересны детали. Любые детали.
Про какую точность вы говорите? Если про точность расчета какой-то непонятной абстрактной величины (АНР метод), то да - такая точность не интересует менеджемент. Точность даты выхода релиза - очень даже интересует. Их не интересует сколько у тестеров еще осталось прогнать тестов 2 или 52, интересует финал - когда будет закончено тестирование. Итд итп.

Пример абсурда я привел выше в "диалоге с менеджером".

- вот именно, что отличный пример абсурда. Зачем менеджеру проекта, видеть такие цифры, особенно, если я утверждаю, что его не интересуют детали? Даже если за пример взять АНР и какое-то числа(0.564343326887, а полгода назад 0.564343326786 ) которые, по вашему там получились - то менеджер увидит 0.5 и 0.5 - разницы нет. Проект не ухудшился (трэнд). А чем ближе к релизу - тем важнее это становится для начальства.

Теперь еще раз, основная мысль того, что я написал в прошлом сообщении. То, что такой подход имеет право на жизнь - не именно то, что в статье написано. Хотя надо перечитать несколько раз чтобы понять что там хорошо, а что не очень. Главное, там есть идея. Я думаю, что что-то подобное можно с успехом применять на практике. Как - пока не знаю. Знал бы - писал бы заявку на патент, вместо того, чтобы вернуть своим словам те мысли которые я в них вложил, а не те, которые вы им приписали.

[Alfa]

Про теорию измерений - сэкономьте мое время, дайте ссылку (если можно с примером), где вкратце описываются основы. Хочу почитать (но не хочу мучать google).

Вот тут слова, а тут математика. Но это конечно не все.

Про погрешность - я частично понял, что вы имеете ввиду. Но все же думаю, что погрешность меньше 20%. Хотя смотря по каким критериям выставлять оценки.

Я прикидывал и погрешность больше 20%, но правильный ответ можно получить только если точно посчитать для каждого конктретного случая.