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

[Oldman]

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


Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.

Фактор качества ПО — это нефункциональное требование к программе, которое является требованием, повышающим качество программы.

Основные факторы качества:
• Надежность
o Устойчивость к отказам
o Способность к восстановлению работоспособности при отказах
• Практичность, удобство использования
o Понятность (Назначение ПО должно быть понятным, из самой программы и документации)
o Удобство обучения
o Простота и удобство использования программы. (Это требование относится прежде всего к интерфейсу пользователя).
• Эффективность
o Временные характеристики
o Использование ресурсов (Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач)
• Сопровождаемость
o Анализируемость (оценка усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы)
o Изменяемость, удобство внесения изменений (Насколько сложно изменить программу для удовлетворения новых требований.)
o Риск возникновения неожиданных эффектов при внесении изменений
o Контролируемость, удобство проверки (Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.)
• Переносимость, мобильность
o Адаптируемость (Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии)
o Удобство установки
o Способность к сосуществованию с другим ПО
o Удобство замены другого ПО данным

[Murlika]

Уважаемый Oldman,

Ваш список выглядит отлично.

Из собственного опыта могу предложить еще пару пунктов:
1. Возможность изменять систему "на лету", т.е. без перезагрузки всей системы, возможно с перезагрузкой какой-то части. Необходимо для hot fix`ов на продукции, когда проблему надо решить немедленно.
2. Возможность отката на предыдущую версию (roll-back). Работала с системой, где roll-back делался от трех до семи дней. Пользователи в это время могли работать только с архивной базы, с мизерной скоростью.
3. Возможность интеграции с автоматическими тестерами (типа Rational Robot и т.д.). Некоторые роботы не любят определенные компоненты определенных языков. К примеры Compuare (вроде так пишется) не любит тулбаров Делфи.
4. Простота конфигурации системы. Часто сталкиваемся с проблемами конфигурации системы и новых проектов, когда после нескольких релизов уже никто не понимает какая конфигурация к чему относиться.

Это все что пока пришло мне в голову. А вообще системы идеальными быть не могут, всегда есть что улучшать.

[LeshaL]

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

Аспекты, которые можно добавить:
- "безопасность 1"(safety) - если система каким-то образом может привести к риску утраты жизни или работоспособности, например ПО для каких-нибудь станков которое должно выключаться в критических ситуациях
- "безопасность 2"(security) - защищеность данных
- "стабильность работы", неприятно же когда система делает что-то нерегулярно или имеет время от времени воспроизводящиеся ошибки
- "наличие исчерпывающей и точной документации", по идее документация должна позволять освоить систему "с нуля"
- "соответсвтвие стандартам, спецификациям, RFC и проч.", ну или по крайней мере непротиворечие им
- "обратная совместимость с предыдущей версией", т.е. показатель того, что новая версия может заменить предыдущую версию той же самой системы без каких-либо потерь (функциональность, данные)
- "отсутствие серьезных дефектов в функциональности", под серьезными, я понимаю те, которые ведут к
--- потере данных
--- полной или частичной неработатоспособности какой-либо функциональности
--- неправильной работе какой-либо функциональности
--- зависанию или падению системы (даже если система может потом восстановиться без проблем)

[Alfa]

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

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

Я бы еще добавил функциональную полноту — система должна уметь выполнять все задачи, которые от нее требует пользователь. Например калькулятор должен уметь складывать, умножать, вычитать, делить и т.д.

[LeshaL]

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

Согласен, это не всегда легко и скорее всего оценка будет несколько субъективна, но это возможно. Лучше всего привлекать usability специалиста для оценки данного аспекта качества.
Вот возможные способы:
- сравнение с конкурирующими продуктами
- количество непофикшеных дефектов с пометкой "usability issue"
- количество непофикшеных дефектов с пометкой "documentation"
- использование стандартных подходов, практик итд
- если предусмотрена менторская программа, то можно оценить как сами менторы будут обучаться работе с системой
- доступность исходных кодов программы
- наличие специальных курсов по обучению работы с системой
- наличие форумов, группы поддержки(support) и тп, на которых есть возможность напрямую задавать вопросы представителям компании разработчика.

Риск возникновения неожиданных эффектов при внесении изменений можно оценить.

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

[SALar]

Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.

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

Расширяемость.

А функциональную полноту принято ставить на первое место.

[SALar]

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

Можно открыть какое ни будь старое руководство. RUP или ГОСТ или еще что-то. Где то там в забытых талмудах есть метрики оценки понятности, удобства обучения, простоты и удобствао использования программы.

[Alfa]

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

Согласен, это не всегда легко и скорее всего оценка будет несколько субъективна, но это возможно. Лучше всего привлекать usability специалиста для оценки данного аспекта качества.

Сначала я бы хотел пояснить, что различаю термины «оценка» и «измерение».
По данным критериям качества я говорю о измерении.
А теперь вопрос: чему равно (по результатам измерения) удобство использования стандартной программы «калькулятор» из комплекта Windows? Ответ на этот вопрос подразумевает число и единицу измерения (минимальный набор).

Риск возникновения неожиданных эффектов при внесении изменений можно оценить.
Буду признателен, если вы расскажете как это можно сделать.

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

[saezar]

Для своих условий (у нас отдельная служба пусконаладки) я бы добавил пункт Конфигурируемость.
Туда бы перенёс "простоту установки" и добавил масштабируемость, и может ещё чего ни будь...
2 Alfa:

А теперь вопрос: чему равно (по результатам измерения) удобство использования стандартной программы «калькулятор»

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

[barancev]

http://software-test...ious_models.htm

[Oldman]

http://software-test...ious_models.htm

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

Вот последний вариант

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

[Alfa]

2 Alfa:

А теперь вопрос: чему равно (по результатам измерения) удобство использования стандартной программы «калькулятор»

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

Я у спрашиваю чему равна длина комнаты. Вы отвечаете, что ее можно измерить в количестве помидоров съеденных пока по ней идешь. Ответ будет 1.5 помидора, но длина измеряется не в помидорах, а удобство не в матюках.
Вопрос остался без ответа.

[Alfa]

Можно открыть какое ни будь старое руководство. RUP или ГОСТ или еще что-то. Где то там в забытых талмудах есть метрики оценки понятности, удобства обучения, простоты и удобствао использования программы.

Метрики оценки это не способ измерения. Способ измерения это амперметр, а метрика оценки -- сила боли при касании оголенного провода.

[Oldman]

Можно открыть какое ни будь старое руководство. RUP или ГОСТ или еще что-то. Где то там в забытых талмудах есть метрики оценки понятности, удобства обучения, простоты и удобствао использования программы.

Метрики оценки это не способ измерения. Способ измерения это амперметр, а метрика оценки -- сила боли при касании оголенного провода.

@Alfa

в последнем своем посте я добавил кое-где метрики
Например:
Понятность: Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач

Помоему вполне измеряемо

[Alfa]

в последнем своем посте я добавил кое-где метрики

Спасибо, я не очень внимательно посмотрел.

Например:
Понятность: Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач

Помоему вполне измеряемо

А усилия в чем измеряются? У меня одна идея в ваттах*час = джоуль, поправьте если ошибся. Т.е. понятность измеряется в обратных джоулях? Я правильно понял? Удобство обучения и удобство работы тоже в обратных джоулях измеряется?

[Oldman]

в последнем своем посте я добавил кое-где метрики

Спасибо, я не очень внимательно посмотрел.

Например:
Понятность: Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач

Помоему вполне измеряемо

А усилия в чем измеряются? У меня одна идея в ваттах*час = джоуль, поправьте если ошибся. Т.е. понятность измеряется в обратных джоулях? Я правильно понял? Удобство обучения и удобство работы тоже в обратных джоулях измеряется?

ну не надо доводить до абсурда :)

человеко/часы

[LeshaL]

Вот последний вариант
....

Теперь кое-чего прояснилось с риском внесения изменений. Я это теперь понимаю таким образом, объясню на примере. В нашем ПО, есть интерфейсы, которые пользовать обязан имплементить самостоятельно, т.е. дописывать свои классы реализации, чтобы у него что-то заработало. Есть вероятность, что пользователь сделает это криво. Мы должны убедиться, что в случае такой кривой реализации наша система не зависнет, упадет или еще чего, а адекватно отреагирует на ошибки в пользовательской имплементации. Более того, мы делаем такие тесты, убеждаясь в стабильности нашей системы, даже в случае кривости одного из компонентов. У нас это называется robustness тестированием.

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

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

[Oldman]

Вот последний вариант
....

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

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

[saezar]

2 Alfa: Вообще то, я просто попытался привнести долю юмора в обсуждение. Однако в каждой шутке есть доля шутки. Удобство использования можно измерить по
1. Количеству ошибочных действий пользователя
2. Количеству обращений к пользователя к документаци
3. Количеству движений мыши и нажатий на клавиши
на одно функционально законченное действие.
Ну и много ещё можно перечислять..

[Alfa]

ну не надо доводить до абсурда :)

человеко/часы

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

Понятность: Показатель, обратный к времени, которое затрачивается пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач