Требования к качеству ПО
#1
Отправлено 11 июля 2008 - 09:17
в рамках концепции нового продукта пишу раздел Требования к качеству. Ниже то что получилось у меня.
Приветствуется критика, дополнения, отсылка на стандарты (желательно гиперссылкой, а не просто названием).
Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.
Фактор качества ПО — это нефункциональное требование к программе, которое является требованием, повышающим качество программы.
Основные факторы качества:
• Надежность
o Устойчивость к отказам
o Способность к восстановлению работоспособности при отказах
• Практичность, удобство использования
o Понятность (Назначение ПО должно быть понятным, из самой программы и документации)
o Удобство обучения
o Простота и удобство использования программы. (Это требование относится прежде всего к интерфейсу пользователя).
• Эффективность
o Временные характеристики
o Использование ресурсов (Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач)
• Сопровождаемость
o Анализируемость (оценка усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы)
o Изменяемость, удобство внесения изменений (Насколько сложно изменить программу для удовлетворения новых требований.)
o Риск возникновения неожиданных эффектов при внесении изменений
o Контролируемость, удобство проверки (Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.)
• Переносимость, мобильность
o Адаптируемость (Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии)
o Удобство установки
o Способность к сосуществованию с другим ПО
o Удобство замены другого ПО данным
#2
Отправлено 11 июля 2008 - 20:10
Ваш список выглядит отлично.
Из собственного опыта могу предложить еще пару пунктов:
1. Возможность изменять систему "на лету", т.е. без перезагрузки всей системы, возможно с перезагрузкой какой-то части. Необходимо для hot fix`ов на продукции, когда проблему надо решить немедленно.
2. Возможность отката на предыдущую версию (roll-back). Работала с системой, где roll-back делался от трех до семи дней. Пользователи в это время могли работать только с архивной базы, с мизерной скоростью.
3. Возможность интеграции с автоматическими тестерами (типа Rational Robot и т.д.). Некоторые роботы не любят определенные компоненты определенных языков. К примеры Compuare (вроде так пишется) не любит тулбаров Делфи.
4. Простота конфигурации системы. Часто сталкиваемся с проблемами конфигурации системы и новых проектов, когда после нескольких релизов уже никто не понимает какая конфигурация к чему относиться.
Это все что пока пришло мне в голову. А вообще системы идеальными быть не могут, всегда есть что улучшать.
#3
Отправлено 12 июля 2008 - 15:01
Единственно, на мой взгяд, выбивается, из стройного списка Риск возникновения неожиданных эффектов при внесении изменений
Все остальные факторы вожно измерить и оценить качество системы. Измерить же риск возникновения неожиданных эффектов при внесении изменений мне представляется невозможным. Особенно, если не знать какие изменения могут потребоваться.
Аспекты, которые можно добавить:
- "безопасность 1"(safety) - если система каким-то образом может привести к риску утраты жизни или работоспособности, например ПО для каких-нибудь станков которое должно выключаться в критических ситуациях
- "безопасность 2"(security) - защищеность данных
- "стабильность работы", неприятно же когда система делает что-то нерегулярно или имеет время от времени воспроизводящиеся ошибки
- "наличие исчерпывающей и точной документации", по идее документация должна позволять освоить систему "с нуля"
- "соответсвтвие стандартам, спецификациям, RFC и проч.", ну или по крайней мере непротиворечие им
- "обратная совместимость с предыдущей версией", т.е. показатель того, что новая версия может заменить предыдущую версию той же самой системы без каких-либо потерь (функциональность, данные)
- "отсутствие серьезных дефектов в функциональности", под серьезными, я понимаю те, которые ведут к
--- потере данных
--- полной или частичной неработатоспособности какой-либо функциональности
--- неправильной работе какой-либо функциональности
--- зависанию или падению системы (даже если система может потом восстановиться без проблем)
Alexey
#4
Отправлено 13 июля 2008 - 10:43
Список в этом смысле не такой и стройный, потому что далеко не все приведенные факторы можно измерить.Единственно, на мой взгяд, выбивается, из стройного списка Риск возникновения неожиданных эффектов при внесении изменений
Все остальные факторы вожно измерить и оценить качество системы. Измерить же риск возникновения неожиданных эффектов при внесении изменений мне представляется невозможным.
Например не измерить понятность, удобство обучения, простоту и удобство использования программы и т.д.
Риск возникновения неожиданных эффектов при внесении изменений можно оценить.
Я бы еще добавил функциональную полноту — система должна уметь выполнять все задачи, которые от нее требует пользователь. Например калькулятор должен уметь складывать, умножать, вычитать, делить и т.д.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#5
Отправлено 13 июля 2008 - 13:46
Согласен, это не всегда легко и скорее всего оценка будет несколько субъективна, но это возможно. Лучше всего привлекать usability специалиста для оценки данного аспекта качества.Например не измерить понятность, удобство обучения, простоту и удобство использования программы и т.д.
Вот возможные способы:
- сравнение с конкурирующими продуктами
- количество непофикшеных дефектов с пометкой "usability issue"
- количество непофикшеных дефектов с пометкой "documentation"
- использование стандартных подходов, практик итд
- если предусмотрена менторская программа, то можно оценить как сами менторы будут обучаться работе с системой
- доступность исходных кодов программы
- наличие специальных курсов по обучению работы с системой
- наличие форумов, группы поддержки(support) и тп, на которых есть возможность напрямую задавать вопросы представителям компании разработчика.
Буду признателен, если вы расскажете как это можно сделать.Риск возникновения неожиданных эффектов при внесении изменений можно оценить.
Можно иметь хороший дизайн системы, с четкими зависимостями между компонентами. Хороший процесс внесения изменений и своевременное тестирование и тд. Но это все возможность снизить риск, но не оценить.
И еще, я говорю о ситуации, когда неизвестно какие в будущем потребуются изменения. Ведь на момент выпуска релиза зачастую непонятно как и что будет сделано в следующем релизе.
Alexey
#6
Отправлено 13 июля 2008 - 16:18
Эту фразу предлагаю убрать. Продукт может соответствовать кривым требованиям, но быть при этом отвратительного качества. "Ожидания заказчика" - уже лучше, хотя тоже не идеально.Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.
Расширяемость.
А функциональную полноту принято ставить на первое место.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
Отправлено 13 июля 2008 - 16:24
Можно открыть какое ни будь старое руководство. RUP или ГОСТ или еще что-то. Где то там в забытых талмудах есть метрики оценки понятности, удобства обучения, простоты и удобствао использования программы.Например не измерить понятность, удобство обучения, простоту и удобство использования программы и т.д.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#8
Отправлено 13 июля 2008 - 16:29
Сначала я бы хотел пояснить, что различаю термины «оценка» и «измерение».Согласен, это не всегда легко и скорее всего оценка будет несколько субъективна, но это возможно. Лучше всего привлекать usability специалиста для оценки данного аспекта качества.Например не измерить понятность, удобство обучения, простоту и удобство использования программы и т.д.
По данным критериям качества я говорю о измерении.
А теперь вопрос: чему равно (по результатам измерения) удобство использования стандартной программы «калькулятор» из комплекта Windows? Ответ на этот вопрос подразумевает число и единицу измерения (минимальный набор).
Риск здесь — это вероятность. Ее можно оценить используя методы теории вероятности. Подробнее писать, как говорит SALar, получится книга.Риск возникновения неожиданных эффектов при внесении изменений можно оценить.
Буду признателен, если вы расскажете как это можно сделать.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#9
Отправлено 14 июля 2008 - 01:56
Туда бы перенёс "простоту установки" и добавил масштабируемость, и может ещё чего ни будь...
2 Alfa:
Вобщем то можно померить. Например число матюков за час работы. Я вот регулярно матерюсь, когда пытаюсь в его строке мышкой что то выделить :).А теперь вопрос: чему равно (по результатам измерения) удобство использования стандартной программы «калькулятор»
#10
Отправлено 14 июля 2008 - 03:44
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#11
Отправлено 14 июля 2008 - 06:18
Леш, конечно я пользовался поиском и смотрел эту ссылку. Проблема в том что по данной ссылке только перечисление пунктов, но не раскрывается что же они значат.
Вот последний вариант
• Функциональная полнота
Способность ПО в определенных условиях решать задачи, нужные пользователям. Определяет, что именно делает ПО, какие задачи оно решает.
o Функциональная пригодность. (Способность решать нужный набор задач)
o Точность. (Способность выдавать нужные результаты)
o Способность к взаимодействию. (Способность взаимодействовать с нужным набором других систем.)
o Соответствие стандартам и правилам. (Соответствие ПО имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам)
o Защищенность. (Способность предотвращать неавторизированный, т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к данным и программам.)
• Надежность.
Способность ПО поддерживать определенную работоспособность в заданных условиях.
o Зрелость, завершенность. (Величина, обратная частоте отказов ПО. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени)
o Устойчивость к отказам. (Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением)
o Способность к восстановлению. (Способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы.)
• Удобство использования или практичность.
Способность ПО быть удобным в обучении и использовании, а также привлекательным для пользователей.
o Понятность. (Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач.)
o Удобство обучения. (Показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с ПО)
o Удобство работы. (Показатель, обратный усилиям, предпринимаемым пользователями для решения своих задач с помощью ПО)
• Производительность или эффективность.
Способность ПО при заданных условиях обеспечивать необходимую работоспособность по отношению к выделяемым для этого ресурсам. Можно определить ее и как отношение получаемых с помощью ПО результатов к затрачиваемым на это ресурсам всех типов.
o Временная эффективность. (Способность ПО выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время)
o Эффективность использования ресурсов. (Способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода и пр.)
• Удобство сопровождения
Удобство проведения всех видов деятельности, связанных с сопровождение программ.
o Анализируемость или удобство проведения анализа. (Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий)
o Удобство внесения изменений. (Показатель, обратный трудозатратам на выполнение необходимых изменений)
o Стабильность. (Показатель, обратный риску возникновения неожиданных эффектов при внесении необходимых изменений)
o Удобство проверки. (Показатель, обратный трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам)
• Переносимость.
Способность ПО сохранять работоспособность при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения.
o Адаптируемость. (Способность ПО приспосабливаться различным окружениям без проведения для этого действий, помимо заранее предусмотренных)
o Удобство установки. (Способность ПО быть установленным или развернутым в определенном окружении)
o Способность к сосуществованию. (Способность ПО сосуществовать с другими программами в общем окружении, деля с ними ресурсы)
o Удобство замены другого ПО данным. (Возможность применения данного ПО вместо других программных систем для решения тех же задач в определенном окружении.)
#12
Отправлено 14 июля 2008 - 06:47
Я у спрашиваю чему равна длина комнаты. Вы отвечаете, что ее можно измерить в количестве помидоров съеденных пока по ней идешь. Ответ будет 1.5 помидора, но длина измеряется не в помидорах, а удобство не в матюках.2 Alfa:
Вобщем то можно померить. Например число матюков за час работы. Я вот регулярно матерюсь, когда пытаюсь в его строке мышкой что то выделить :).А теперь вопрос: чему равно (по результатам измерения) удобство использования стандартной программы «калькулятор»
Вопрос остался без ответа.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#13
Отправлено 14 июля 2008 - 06:53
Метрики оценки это не способ измерения. Способ измерения это амперметр, а метрика оценки -- сила боли при касании оголенного провода.Можно открыть какое ни будь старое руководство. RUP или ГОСТ или еще что-то. Где то там в забытых талмудах есть метрики оценки понятности, удобства обучения, простоты и удобствао использования программы.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#14
Отправлено 14 июля 2008 - 07:07
Метрики оценки это не способ измерения. Способ измерения это амперметр, а метрика оценки -- сила боли при касании оголенного провода.Можно открыть какое ни будь старое руководство. RUP или ГОСТ или еще что-то. Где то там в забытых талмудах есть метрики оценки понятности, удобства обучения, простоты и удобствао использования программы.
@Alfa
в последнем своем посте я добавил кое-где метрики
Например:
Понятность: Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач
Помоему вполне измеряемо
#15
Отправлено 14 июля 2008 - 07:42
Спасибо, я не очень внимательно посмотрел.в последнем своем посте я добавил кое-где метрики
А усилия в чем измеряются? У меня одна идея в ваттах*час = джоуль, поправьте если ошибся. Т.е. понятность измеряется в обратных джоулях? Я правильно понял? Удобство обучения и удобство работы тоже в обратных джоулях измеряется?Например:
Понятность: Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач
Помоему вполне измеряемо
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#16
Отправлено 14 июля 2008 - 09:06
Спасибо, я не очень внимательно посмотрел.в последнем своем посте я добавил кое-где метрики
А усилия в чем измеряются? У меня одна идея в ваттах*час = джоуль, поправьте если ошибся. Т.е. понятность измеряется в обратных джоулях? Я правильно понял? Удобство обучения и удобство работы тоже в обратных джоулях измеряется?Например:
Понятность: Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач
Помоему вполне измеряемо
ну не надо доводить до абсурда :)
человеко/часы
#17
Отправлено 14 июля 2008 - 09:19
Теперь кое-чего прояснилось с риском внесения изменений. Я это теперь понимаю таким образом, объясню на примере. В нашем ПО, есть интерфейсы, которые пользовать обязан имплементить самостоятельно, т.е. дописывать свои классы реализации, чтобы у него что-то заработало. Есть вероятность, что пользователь сделает это криво. Мы должны убедиться, что в случае такой кривой реализации наша система не зависнет, упадет или еще чего, а адекватно отреагирует на ошибки в пользовательской имплементации. Более того, мы делаем такие тесты, убеждаясь в стабильности нашей системы, даже в случае кривости одного из компонентов. У нас это называется robustness тестированием.Вот последний вариант
....
Непонятно, почему вы пренебрегаете таким показателем как безопасность для здоровья? Есть целый ряд ПО, где это чрезвычайно важно. Медицинкое ПО, авиационное, автомобильное итд. Например, что будет хорошего, если ваш автомобиль резко остановиться посреди хайвея, если бортовой компутер почует запах спирта от стеклоочистительной жидкости?
Еще, непонятно, почему не учитывается такой показатель как наличие документации системы. По-моему, очевидно, что при прочих равных более качественной будет система имеющая документацию, чем та у которой документация отсутствует. Мне тут один коллега выдал - написал тул и собрался поместить его исходники в нашу систему контроля версий. На вопрос, а где хоть какое-то описание: что это, как использовать. Получил такой ответ - мол есть исходники и так все понятно. Пришлось убедить написать.
Alexey
#18
Отправлено 14 июля 2008 - 09:35
LeshaL я писал не абстрактно, а применительно к своему продукту поэтому нет показателя безопасности для здоровья....Вот последний вариант
....
Непонятно, почему вы пренебрегаете таким показателем как безопасность для здоровья? Есть целый ряд ПО, где это чрезвычайно важно. Медицинкое ПО, авиационное, автомобильное итд. Например, что будет хорошего, если ваш автомобиль резко остановиться посреди хайвея, если бортовой компутер почует запах спирта от стеклоочистительной жидкости?
...
Еще, непонятно, почему не учитывается такой показатель как наличие документации системы. По-моему, очевидно, что при прочих равных более качественной будет система имеющая документацию, чем та у которой документация отсутствует. Мне тут один коллега выдал - написал тул и собрался поместить его исходники в нашу систему контроля версий. На вопрос, а где хоть какое-то описание: что это, как использовать. Получил такой ответ - мол есть исходники и так все понятно. Пришлось убедить написать.
Наличие документации - да надо подумать куда вставить и как это описать (например инфо-киоск нет документации для конечного пользователя, только для инженера)
#19
Отправлено 14 июля 2008 - 09:43
1. Количеству ошибочных действий пользователя
2. Количеству обращений к пользователя к документаци
3. Количеству движений мыши и нажатий на клавиши
на одно функционально законченное действие.
Ну и много ещё можно перечислять..
#20
Отправлено 14 июля 2008 - 10:14
Я думаю вы имеете ввиду человеко*часы? Которые на самом деле просто часы, потому что один пользователь не может потратить усилий на два человеко*часа в один астрономический час.ну не надо доводить до абсурда :)
человеко/часы
Т.е. понятность использования измеряется в обратных часах.
Тогда надо переделать определение понятности и др.
Понятность: Показатель, обратный к времени, которое затрачивается пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных