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

[SEgorushkin]

Привет, коллеги!

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

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

Единственная статья с детальным описанием каждого показателя (критерия) качества, которую я нашел по этой теме:

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

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

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

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

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

[Vita]

После совместной работы команды разработчиков, у руководства по определенным причинам складывается впечатление, что техническое задание (или его минимум) выполнено, основные функциональности работают, соблюдены необходимые стандарты и нормы, требования (возможно потенциальных) заказчиков, готова рабочая документация, не буду повторять за Вами прочее. Советую проводить испытания на опытном полигоне (полигонах). По результатам делать выводы о необходимых важных замечаниях и доработках для данного "релиза". Если пользователи прошли обучение, ПО установлено, НСИ наполнено, есть готовность - распоряжение приступить к его (опытной, далее - постоянной) эксплуатации, определен регламент работы пользователей, начата эксплуатация, согласован комплект документов – акт, протокол членов комиссии. Можно считать, внедрение проведено. Удобство использования можно так же определить, проведя анализ замечаний пользователей, мнение специалистов ИТ и области применения программного обеспечения.
Мне помогает принимать любые решения – о публикации версии, что я сама по своей зоне ответственности сделала все возможное, проведены основные этапы и виды тестирования, важные моменты исправлены, пользователи обучены изменениям, информированы о дате обновлений, документация доработана, что есть предыдущая версия и механизм отката новой.
Порой при публикации и эксплуатации версии могут проявляться важные ошибки, поэтому она либо оперативно правится – обновляется, либо откатывается на предыдущую стабильную версию.

[clipsa]

Сергей, а Вам для чего нужны данные показатели? Для улучшения качества продукта или для отчетности руководству?
Если первый вариант, то тут на каждый продукт могут быть свои критерии, которые можно получить, ответив на вопросы - кто будет пользоваться ПО? Какие задачи должно решать ПО? Есть ли документация (ТЗ, АЗ и пр.)? И т.д и т.п.
А если второй вариант, то, конечно можно придумать какие угодно метрики - какие хочет видеть начальство.
ИМХО

[SEgorushkin]

Сергей, а Вам для чего нужны данные показатели? Для улучшения качества продукта или для отчетности руководству?

Ольга, скорее всё таки для отчетности руководству. Собственно и хотелось бы узнать, как в различных проектах можно ответить на вопрос:
из чего следует, что продукт готов к релизу? Обычно руководство требует какие то количественные показатели (а не просто экспертное мнение).

[SEgorushkin]

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

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

[Vita]

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

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

[clipsa]

Сергей, тут надо смотреть по обстоятельствам. Может быть руководство хочет что-то конкретное, надо выяснить что именно. Наладить процесс так скажем "сдачи" задач/релизов.
У нас отчет руководству для получения акцепта на обновление боевой среды выглядит следующим образом: есть список задач, вошедших в релиз. Для каждой из задач есть требования (что логично... :-) ). Соответственно мы пишем в отчете список задач с "доказательствами" выполнения требований - это могут быть скриншоты, логи, отчеты и т.п. Т.е. критерием "готовности" задачи к выпуску "в свет" является выполнение требований плюс тот факт, что все обнаруженные баги были "обезврежены".
Как то так :-)

[SALar]

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

Я использую последние три года.
Ориентируюсь на ГОСТ 9126 (с него и начните). Отличнейшая, я вам скажу штука.
Дальнейшая версия - зарубежный стандарт ISO/IEC 9126-1:2001 и еще какой то стандарт.

PS. Вот на этом семинаре эти вопросы разбираются: http://school.system...soft-qual-reqs/

[jjjzmey]

Если взять самый минимум, получится примерно следующее:

1. Выполняются контрольные примеры из ПМИ
2. Нет открытых багов с высоким и критическим приоритетом