Продолжаю делать интересные выдержки из книг, соблазняя читателей купить оригинал и узреть полную версию. Сегодня пример будет из книги Карла Вигерса "Разработчка требований к программному обеспечению". Все статьи по книжке:
[1] [2] [3] [4]
Пользователи, разумеется, хотят всего и сразу. Если им предложить, то они сразу же захотят и мобильность, и эффективность, и надежность, и прочая-прочая. При этом пока не задумываясь о приоритетах - раз предлагают, то почему бы и не согласиться?
А потом может оказаться, что предложили как-то много всего... Для того, чтобы избежать такой ситуации, Карл предлагает использовать кубик типичных взаимосвязей различный атрибутов качества.
Знак "+" в ячейке означает, что увеличение величины атрибута в соответствующей строке позитивно влияет на атрибут в соответствующем столбце. Например, при повышении легкости перемещения программного компонента повышается гибкость ПО, упрощается подключение к компонентам лругого ПО и возможность повторного использования и тестирования.
Знак "-" означает, что увеличение величины атрибута в соответствующей строке негативновлияет на атрибут в соответствующем столбце. Пустая ячейка означает, что атрибут в строке незначительно влияет на атрибут в столбце.
Стоит заметить, что матрица несимметрична, так как влияние при увеличении атрибута А на атрибут В не обязательно такое же, как влияние, которое оказывает увеличение атрибута В на атрибут А. Так, например, модификация системы с целью повышения эффективности не оказывает влияния на целостность (ограничение доступа неавторизованного пользователя). Однако повышение целостности вероятнее всего весьма отрицательно отращится на эффективаности, поскольку системе придется выполнять множество проверок аутентификации пользователей, зашифрованных данных, проверок на наличие вирусов...
Таким образом, можно использовать эту диаграмму для того, чтобы не ставить перед собой несовместимые цели. Это если смотреть с точки зрения аналитика. А с точки зрения тестировщика - можно помедитировать над картинкой, размышляя, о чем мы могли забыть при тестировании. Рассматривая атрибуты, на которые модификация системы должна была повлиять отрицательно, можно увеличить число проверок, которые мы задумали провести для проверки новой функциональности!
А вы все учли при тестировании?
[1] [2] [3] [4]
Пользователи, разумеется, хотят всего и сразу. Если им предложить, то они сразу же захотят и мобильность, и эффективность, и надежность, и прочая-прочая. При этом пока не задумываясь о приоритетах - раз предлагают, то почему бы и не согласиться?
А потом может оказаться, что предложили как-то много всего... Для того, чтобы избежать такой ситуации, Карл предлагает использовать кубик типичных взаимосвязей различный атрибутов качества.
Знак "+" в ячейке означает, что увеличение величины атрибута в соответствующей строке позитивно влияет на атрибут в соответствующем столбце. Например, при повышении легкости перемещения программного компонента повышается гибкость ПО, упрощается подключение к компонентам лругого ПО и возможность повторного использования и тестирования.
Знак "-" означает, что увеличение величины атрибута в соответствующей строке негативновлияет на атрибут в соответствующем столбце. Пустая ячейка означает, что атрибут в строке незначительно влияет на атрибут в столбце.
Стоит заметить, что матрица несимметрична, так как влияние при увеличении атрибута А на атрибут В не обязательно такое же, как влияние, которое оказывает увеличение атрибута В на атрибут А. Так, например, модификация системы с целью повышения эффективности не оказывает влияния на целостность (ограничение доступа неавторизованного пользователя). Однако повышение целостности вероятнее всего весьма отрицательно отращится на эффективаности, поскольку системе придется выполнять множество проверок аутентификации пользователей, зашифрованных данных, проверок на наличие вирусов...
Таким образом, можно использовать эту диаграмму для того, чтобы не ставить перед собой несовместимые цели. Это если смотреть с точки зрения аналитика. А с точки зрения тестировщика - можно помедитировать над картинкой, размышляя, о чем мы могли забыть при тестировании. Рассматривая атрибуты, на которые модификация системы должна была повлиять отрицательно, можно увеличить число проверок, которые мы задумали провести для проверки новой функциональности!
А вы все учли при тестировании?
http://dl.rutracker.org/forum/dl.php?t=103273
ОтветитьУдалитьПредлагаю сделать шаги дальше.
ОтветитьУдалить* Составить матрицу приоритетов атрибутов качества, причем с временной шкалой развития проекта. Желательны также численные критерии.
* По каждому атрибуту отдельно пишутся меры которые обеспечивают и отдельно, какие контролируют необходимый уровень качества.
Матрица приоритетов - это понятно. А меры зачем выписывать?
УдалитьЕсть еще два маленьких ньюанса:
ОтветитьУдалить1. Перечисленные атрибуты качества не для всех продуктов актуальны. Для некоторых можно без особого вреда выкинуть несколько и ничего не изменится.
2. У каждого проекта свой список актуальных атрибутов качества.