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

[Alfa]

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

Я для вас сочинил хокку, первый раз в жизни, не судите строго.

Я вижу три варианта.
Мне нужно одно число.
Проблема.

[Oldman]

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

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

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

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

не ко времени а к ресурсам

ко времени только для понятности

а риск изменений там может и 5 человек править

[LeshaL]

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

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

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

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

[Oldman]

Выше перечисленные атрибуты относятся к внутреннему и внешнему качеству ПО согласно ISO 9126

НО

Для описания качества ПО при использовании стандарт ISO 9126-4 предлагает другой, более узкий набор характеристик.
* Эффективность (effectiveness).
Способность ПО предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте.

* Продуктивность (productivity).
Способность ПО предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов.

* Безопасность (safety).
Способность ПО обеспечивать необходимо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде.

* Удовлетворение пользователей (satisfaction).
Способность ПО приносить удовлетворение пользователям при использовании в заданном контексте.

Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута.

Например:

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

[Alfa]

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

Я вижу три варианта.
Мне нужно одно число.
Проблема.

Прочитал пост Oldman`а, понял, что мой текст так же непонятен как его, теперь перевожу.

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

[Alfa]

не ко времени а к ресурсам

ко времени только для понятности

Вот это я вроде понял. Под ресурсами понимается только время или еще и деньги? Но точно не усилия, правильно?

А последняя часть осталась загадкой.

а риск изменений там может и 5 человек править

[galaxer]

Выше вы упомянули соответствие разработанного ПО некоему стандарту ISO, мое мнение не особо Вам что скажет, скорее всего, но все же, имея небольшой опыт разработки в области WEB-ПО, могу с уверенностью сказать(подтвердить чьи-то здесь уже звучавшие слова:), что основным критерием в разработке ПО являетсо удовлетворенность заказчика, - все остальное(отказоустойчивость, переносимость, юзабилити и т.п.) - это Ваш потенциальный хлеб:) - ведь нет ничего Абсолютно надежного, любой разработчик(даже сверхпопулярный типа MicroSoft) - не разработал до сих пор ни одного хоть на 95 процентов соответствующего тем немногим, предъявляемым обычными юзерами критериям ПО. Любые стандарты - лишь обобщение - все зависит и от направления - в какой области(химия,астрофизика, WEB,...), какими людьми(возраст, опыт работы с новым ПО, образование,...) - с какой целью(жизненно необходимо стабильность, некритичность отказоустойчивости,..) разрабатываетсо ПО - список бесконечен:). Если это ПО для крупной компании, то соответственно нужно перебрать все международные стандарты ISO, (вплоть до Стандарта ISO 9000 убедить заказчика в необходимости соответствия им разрабатываемого ПО(а следовательно и удорожания разработки) и учесть требования заказчика, касаемо функциональности ПО(Это основное конечно же:).

[saezar]

Всегда считал, что удобство использования - это usability. Вполне измеряемый показатель, но к сожалению не абсолютный, как амперы или вольты. Нельзя указать в требованиях "Удобство не ниже 4.6". Поэтому числа, уважаемый Alfa, скорее всего не будет. А вот относительный показатель, как изменилось удобство использования, как раз такими способами измерить можно. Хотя, для конкретных случаев можно наверно чего ни будь абсолютное найти.

[Alfa]

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

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

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

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

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

[Green]

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

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

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

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

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

[barancev]

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

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

Ну так надо просто перевести стандарт 9126 :)
Желательно в новой редакции, с метриками.

[Alfa]

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

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

В целом все стало более-менее понятно:
* толком никто не знает, что такое удобство использования или какое-то другое удобство (или кто-то знает и молчит?)
* как его мерять тоже непонятно
* есть два миллиона способов измерить что-то связанное с удобством (время выполнения действий, число матюков, усилия и т.д.) -- так называемые метрики оценки удобства
* главное не забыть усреднить метрику по фокус группе, а то совсем ерунда получится
Или не так?

[LeshaL]

Выше вы упомянули соответствие разработанного ПО некоему стандарту ISO, мое мнение не особо Вам что скажет, скорее всего, но все же, имея небольшой опыт разработки в области WEB-ПО, могу с уверенностью сказать(подтвердить чьи-то здесь уже звучавшие слова:), что основным критерием в разработке ПО являетсо удовлетворенность заказчика, - все остальное(отказоустойчивость, переносимость, юзабилити и т.п.) - это Ваш потенциальный хлеб:) - ведь нет ничего Абсолютно надежного, любой разработчик(даже сверхпопулярный типа MicroSoft) - не разработал до сих пор ни одного хоть на 95 процентов соответствующего тем немногим, предъявляемым обычными юзерами критериям ПО. Любые стандарты - лишь обобщение - все зависит и от направления - в какой области(химия,астрофизика, WEB,...), какими людьми(возраст, опыт работы с новым ПО, образование,...) - с какой целью(жизненно необходимо стабильность, некритичность отказоустойчивости,..) разрабатываетсо ПО - список бесконечен:). Если это ПО для крупной компании, то соответственно нужно перебрать все международные стандарты ISO, (вплоть до [url="http://www.klubok.net/article1428.html""]Стандарта ISO 9000[/url]убедить заказчика в необходимости соответствия им разрабатываемого ПО(а следовательно и удорожания разработки) и учесть требования заказчика, касаемо функциональности ПО(Это основное конечно же:).

Вы не правы.
Раз вы имеете опыт разработки в области WEB представьте такую ситуацию: каждый браузер (IE, FF, Opera итд) изобрел свой аналог CSS и только его и поддерживает, забивая на W3C-шные рекомендации/спецификации. Сколько потребуется труда для написания WEB-приложения, которое будет выглядеть одинаково во всех браузерах?
А про майкрософт в контексте поддержки спецификаций и стандартов говорить как-то... неудобно что-ли. Во-первых потому-что они сами придумывают много различных стандартов. Во-вторых, потому-что они очень часто забивают болт на общепризнаные вещи.

[Green]

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

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

Вот уж совсем не соглашусь.

Любые испытания - это проверка на практике неких предположений.

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

[Alfa]

Вот уж совсем не соглашусь.

Любые испытания - это проверка на практике неких предположений.

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

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

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

[Green]

Вот уж совсем не соглашусь.

Любые испытания - это проверка на практике неких предположений.

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

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

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

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

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

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

В отношении Вашего примера...
Опровержение одной гипотезы - это рождение другой. Предполагайте, что лебеди двух цветов - черного и белого.


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

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



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

[LeshaL]

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

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

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

[greesha]

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

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

А в чём состояла цель испытаний? Гипотеза "все лебеди белые" появилась сама по себе или в рамках достижения каких-то практических целей?

[barancev]

В целом все стало более-менее понятно:
* толком никто не знает, что такое удобство использования или какое-то другое удобство (или кто-то знает и молчит?)
* как его мерять тоже непонятно
* есть два миллиона способов измерить что-то связанное с удобством (время выполнения действий, число матюков, усилия и т.д.) -- так называемые метрики оценки удобства
* главное не забыть усреднить метрику по фокус группе, а то совсем ерунда получится
Или не так?

А отчего такое особое внимание к удобству использования? Метрики для остальных атрибутов качества не вызывают сомнений? Скажем, для самой первой группы, которая относится собственно к функциональности, и самых наиважнейших атрибутов -- пригодность и точность -- всё с метриками ясно?

[Oldman]

А отчего такое особое внимание к удобству использования? Метрики для остальных атрибутов качества не вызывают сомнений? Скажем, для самой первой группы, которая относится собственно к функциональности, и самых наиважнейших атрибутов -- пригодность и точность -- всё с метриками ясно?

Наверное, просто веяние моды :) (юзабилити, удобство использования и т.д.)