Добрый день, коллеги!

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

В инете нашел статью с кратким перечнем таких критериев:

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

1) Количество открытых (неисправленных) функциональных дефектов на продукт.

2) Количество успешно выполненных тестовых сценариев.
...
Стабильность системы. Стабильность определяется, как способность продукта корректно функционировать при длительном использовании с ожидаемым объемом нагрузки.
...
Производительность. Под производительностью программного продукта обычно понимают скорость выполнения базовых функциональных операций продукта.
...
Поддерживаемые платформы (конфигурации). Основные функциональные тесты выполняются на всех поддерживаемых платформах.
...
Количество инцидентов на проданную копию (на пользователя) – количество обращений в службу поддержки после выпуска продукта. Так как значение показателя можно измерить только после выпуска, его можно использовать исключительно для мониторинга (не в качестве условия для релиза).
...

Полный текст статьи здесь.

Понятно, что все мы так или иначе стремимся улучшить перечисленные характеристики продукта, но определяете ли вы какие-либо целевые значения перед стартом проекта? И если определяете, то согласовываете ли их с заказчиком?

Здравствуйте, Auditor,

A> Если нет, то как вы понимаете, что продукт дописали, дотестили и его можно релизить?

Дык, эта.... все делается по фен-шую.
У меня есть ПиМИ — Программа и методика испытаний, обязательно согласованная (а на ГИ и утвержденная) представителем Заказчика. И в ней подробно расписано, как и в какой последовательности проверяется выполнение требований ТЗ. И в каждом пункте ПиМИ есть магическая фраза: "Результат испытания считается успешным, если.... " Ну и испытания проходят последовательно — заводские, предварительные, Государственные или межведомственные. И если продукт успешно прошел этап ГИ — никто не позволит его не зарелизить (не передать Заказчику).

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

V_S>Здравствуйте, Auditor,

A>> Если нет, то как вы понимаете, что продукт дописали, дотестили и его можно релизить?

V_S>Дык, эта.... все делается по фен-шую.
V_S>У меня есть ПиМИ — Программа и методика испытаний, обязательно согласованная (а на ГИ и утвержденная) представителем Заказчика. И в ней подробно расписано, как и в какой последовательности проверяется выполнение требований ТЗ. И в каждом пункте ПиМИ есть магическая фраза: "Результат испытания считается успешным, если.... " Ну и испытания проходят последовательно — заводские, предварительные, Государственные или межведомственные. И если продукт успешно прошел этап ГИ — никто не позволит его не зарелизить (не передать Заказчику).

То есть, имеется некий сценарий (ну или набор тестов), успешное прохождение которого является обязательным условием для выпуска продукта?

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

A>В инете нашел статью с кратким перечнем таких критериев:
A>Полный текст статьи здесь.
1. Зачем придумывать какие-то показатели, когда они уже определены в стандартах ?

В стандартах устанавливается более короткий перечень показателей. ГОСТ 28195-89 содержит следующий список комплексных показателей качества программного продукта: надежность, корректность, удобство применения, сопровождаемость, эффективность и универсальность. В международном стандарте ISO 9126 прописаны следующие показатели: эффективность, надежность, сопровождаемость, функциональность, практичность и мобильность. Комплексные показатели называют также факторами качества или характеристиками качества.

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

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

2. Измерение качества ПО — научно-исследовательская работа.

К сожалению, показатели качества в большинстве своем не могут быть измерены количественно, хотя ГОСТ 28195-89 и предписывает использовать для показателей качества на всех уровнях (факторы, критерии, метрики, оценочные элементы) единую шкалу оценки от 0 до 1. Например, для фактора качества «универсальность» на этапе проектирования оценивается критерий «гибкость», значение которого складывается из значений метрик «широта охвата функций», «простота архитектуры проекта», сложность архитектуры проекта». На этапе реализации (программирования) добавляются метрики «сложность структуры кода программы», «применение стандартных протоколов связи», «применение стандартных интерфейсных программ».

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

Здравствуйте, Auditor,

A>То есть, имеется некий сценарий (ну или набор тестов), успешное прохождение которого является обязательным условием для выпуска продукта?

А как же! То есть, успешное прохождение тестового набора сценариев (ну или ПиМИ, название тут не принципиально) является обязательным (но не единственным!) условием релиза. А иначе, как ты (и Заказчик, ведь он подписывает протоколы испытаний) можешь убедиться, что ПО действительно выполняет те требования, которые к нему предъявляются?

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

LVV>1. Зачем придумывать какие-то показатели, когда они уже определены в стандартах ?
...
LVV>Каждому из комплексных показателей соответствует определенный набор критериев качества. В свою очередь, каждый из критериев определяется своими метриками, которые составляются из оценочных элементов, определяющих заданное в метрике свойство. На разных этапах ЖЦ для разных классов программных продуктов применяются разные критерии качества.

Согласен, но вот я и хотел узнать применяются ли они (критерии) у кого то на практике? Если применяются, то каким образом определяются метрики? Исходя из чего?

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

Да, но тут другой вопрос возникает: как измерить такой фактор как, например, эффективность?

LVV>2. Измерение качества ПО — научно-исследовательская работа.

LVV>К сожалению, показатели качества в большинстве своем не могут быть измерены количественно...
...
LVV>Понятно, что непосредственно измерить такие метрики невозможно, поэтому они могут быть только оценены экспертами. Такие оценки, естественно, являются в значительной мере субъективными. Фактически непосредственному измерению поддаются только показатели производительности-эффективности, но они относятся к внешним показателям качества продукта.

Тут вынужден не согласиться. Если показатели качества нельзя измерить количественно, то зачем они тогда вообще нужны? Какой от них толк?

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

V_S>А как же! То есть, успешное прохождение тестового набора сценариев (ну или ПиМИ, название тут не принципиально) является обязательным (но не единственным!) условием релиза.
....

Скажите, а какие ещё есть у Вас условия (если прохождение ПиМИ обязательное, но не единственное условие)? Они как то относятся к метрикам качества продукта?

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

A>

LVV>>1. Зачем придумывать какие-то показатели, когда они уже определены в стандартах ?
A>...
LVV>>Каждому из комплексных показателей соответствует определенный набор критериев качества. В свою очередь, каждый из критериев определяется своими метриками, которые составляются из оценочных элементов, определяющих заданное в метрике свойство. На разных этапах ЖЦ для разных классов программных продуктов применяются разные критерии качества.

A>Согласен, но вот я и хотел узнать применяются ли они (критерии) у кого то на практике? Если применяются, то каким образом определяются метрики? Исходя из чего?
A>Да, но тут другой вопрос возникает: как измерить такой фактор как, например, эффективность?
A>Тут вынужден не согласиться. Если показатели качества нельзя измерить количественно, то зачем они тогда вообще нужны? Какой от них толк?
Посмотрите, например, такую книжку:
http://www.ozon.ru/context/detail/id/7625538/
Там довольно много о метриках написано.
Показатели качества нужны.
Хотя бы для начальной формализации оценки качества.
Вот, например, как мы этот вопрос исследуем:

Анализ метрических показателей впервые стал применяться еще в 70-х годах прошлого столетия. Метрические показатели (метрики) — это статистические показатели, рассчитывающиеся непосредственно на основе знаний о структуре проекта и программного кода. Метрические показатели непосредственно не связаны с показателями и метриками качества, перечисленными выше, хотя их можно попытаться использовать в качестве оценочных элементов.
...
Исторически первыми метриками были размерно-ориентированные метрики , основанные на LOC-оценках (Lines Of Code — количество строк кода). Однако с переходом к объектно-ориентированным методам разработки все большую роль стали играть объектно-ориентированные метрики внутренней сложности.
На сегодняшний день разработано достаточное количество наборов метрик и по многим из них уже собрана достаточная историческая и аналитическая информация для различных типов проектов.

С точки зрения метрик выделяют пять характеристик объектно-ориентированных систем: локализацию, инкапсуляцию, информационную закрытость, наследование и способы абстрагирования объектов. Эти характеристики оказывают наибольшее влияние на объектно-ориентированные метрики. Примерами широко используемых наборов метрик являются QMOOD (Quality Model for Object-Oriented Design), MOOSE (Metrics for Object-Oriented Software Engineering), MOOD (Metrics for Object-Oriented Design) и MOOD2
...
Важно понимать, что сами по себе рассчитанные значения метрик ничего не говорят о качестве объектно-ориентированной структуры проекта и кода. Для правильной интерпретации значений метрик необходимы знания и опыт экспертов (менеджеров, исследователей, разработчиков, руководителей), или же большая база накопленной статистической информации по сходным проектам, что позволит оценивать качество по аналогии.
...
Таким образом, существует научная и техническая проблема, состоящая в разработке методов измерения показателей качества, причем нужно измерять показатели в процессе разработки, а не только по конечному продукту.

ПОСТАНОВКА ЗАДАЧИ И ПРЕДЛАГАЕМЫЙ ПОДХОД
Конкретизируем некоторые начальные условия для решения задачи:
1. Ограничимся проектами, в которых применяется объектно-ориентированный подход в разработке, поскольку в настоящее время он является превалирующим. Программный продукт, получаемый в результате применения объектно-ориентированных методов, назовем объектно-ориентированным программным продуктом (ООПП).
2. Ограничимся тремя этапами процесса разработки в ЖЦ ПО: проектированием, программированием и тестированием. На этапе проектирования необходимо оценивать качество проектной модели, на этапе программирования — проектную модель и код, на этапе тестирования — проектную модель, код и программный продукт.
3. Ограничимся пятью наиболее важными показателями внутреннего качества проекта:
a. Сложность реализации (complexity, CPLX) — отражает объем затрат материальных и человеческих ресурсов, необходимых для первоначальной реализации проектной модели.
b. Сложность модернизации (volatily, VLTL) — отражает объем затрат материальных и человеческих ресурсов, требуемых в случае развития функциональности программного продукта.
c. Сложность сопровождения (maintenance, MNTN) — отражает объем затрат материальных и человеческих ресурсов, необходимых для поддержания в рабочем состоянии программного продукта без изменения его функциональности.
d. Подверженность ошибкам (weakness, WCK) — отражает количество ошибок, которые могут допустить разработчики при реализации программного продукта, основывающегося на анализируемой проектной модели.
e. Возможность повторного использования (recycling, RCCL) — отражает степень готовности проектной модели к повторному использованию для реализации в той же предметной области другого программного продукта.

Основная идея предлагаемого подхода заключается в том, чтобы рассчитывать метрические показатели для оценки характеристик качества на этапе проектирования и программирования, и по рассчитанным характеристикам определять текущее качество ООПП. Для реализации этой идеи требуется решить две задачи:
1. Унифицировать расчет метрических показателей для различных этапов процесса разработки.
2. Связать точные количественные значения метрических показателей с качественными характеристиками;
Для решения первой задачи необходимо построить обобщенную метамодель ООПП, по которой будет возможно единообразно выполнять расчет показателей объектно-ориентированных метрик для любых ООПП. Для этого требуется проанализировать состав элементов проекта на разных этапах разработки, выявить общие для всех этапов элементы проекта. Далее требуется определить способы определения элементов обобщенной модели в конкретном программном продукте на разных этапах разработки.
Для решения второй задачи требуется проанализировать связь между качественными характеристиками ООПП и метрическими показателями модели, формализовать задачу оценки показателей качества и разработать метод оценки.
...

И все это потом на основе нечетких нейронных сетей Ванга-Менделя делалось...

Здравствуйте, Auditor,

нннууу..... Понимаешь, тут засада в том, что "критерии качества для выпуска релиза" — они сильно разные для разных людей, участвующих в проекте.
Несколько упрощенно:
Для программиста-разработчика критерии качества — это количество ошибок, степень серьезности ошибок, плотность ошибок... а еще переносимость, модифицируемость, понятность кода... тут смотри пост уважаемого Валерия Викторовича Лаптева. То есть — для технического специалиста ключевыми являются технические критерии.
Для менеджера критерии качества продукта — это соответствие продукта ожиданиям пользователей и рекламным обещаниям. (Ага, реклама зачастую расписывает еще не реализованные фичи.) А для бухгалтера — это генерируемый продуктом денежный поток (упрощенно, = стоимость копии * количество продаж — затраты на техподдержку пользователей).
А решение о выпуске продукта в релиз принимает Первое Лицо бизнеса (или уполномоченный им Топ-Менеджер), ориентируясь на некую интегральную оценку мнений всех перечисленных лиц, и имея еще свое собственное мнение.