Характеристики качества программного продукта: Управление качеством программного обеспечения — Краткое руководство

Качество программного обеспечения — Википедия

Материал из Википедии — свободной энциклопедии

Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014)^[1].

Другие определения из стандартов:

• весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94)^[2][3];
• степень, в которой система, компонент или процесс удовлетворяют потребностям или ожиданиям заказчика или пользователя (IEEE Std 610.12-1990)^[4].

Ранние подходы к определению

Том Демарко в 1999 году предлагал при оценке качества программного обеспечения учитывать, что «качество программного продукта является показателем того, насколько он меняет мир к лучшему»^[5].

Джеральд Вайнберг в своей работе 1992 года Quality Software Management: Volume 1, Systems Thinking давал определение качества как «значимого для какого-либо человека»^[6][7], подчеркивая тем самым, что понятие качества является по своей природе субъективным — разные люди будут оценивать качество одного и того же программного обеспечения по-разному. Одной из сильных сторон этого определения являются вопросы, на которые должны ответить команды разработчиков программного обеспечения, такие как «Кто те люди, которые будут оценивать наше программное обеспечение?» и «Что будет ценным для них?».

Модели качества

Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)^[8] определяет модель качества продукта, которая включает восемь характеристик верхнего уровня:

В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от субъективного качества в использовании, которое может сильно отличаться для различных стейкхолдеров^[9]. Модель качества в использовании (англ. quality in use model) включает следующие характеристики верхнего уровня^[8]:

Роберт Гласс в известной книге «Факты и заблуждения профессионального программирования» утверждает, что большинство профессиональных разработчиков согласны с выделением семи показателей качества как основных^[10]:

Среди относительно новых моделей качества программного обеспечения можно упомянуть SQUALE и Quamoco^[11], которые были применены в промышленных условиях, но пока не получили широкого распространения.

См. также

Примечания

1. ↑ Software quality — capability of software product to satisfy stated and implied needs when used under specified conditions: ISO/IEC 25000:2014(en) Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE
2. ↑ ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению
3. ↑ ISO 8402:94. Управление качеством и обеспечение качества. Словарь
4. ↑ The degree to which a system, component, or process meets customer or user needs or expectations: IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology
5. ↑ DeMarco, T., Management Can Make Quality (Im)possible, Cutter IT Summit, Boston, April 1999
6. ↑ Weinberg, Gerald M. (1992), Quality Software Management: Volume 1, Systems Thinking, New York, NY: Dorset House Publishing, с. 7 
7. ↑ Weinberg, Gerald M. (1993), Quality Software Management: Volume 2, First-Order Measurement, New York, NY: Dorset House Publishing, с. 108 
8. ↑ ^{1 2} ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
   ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов
9. ↑ Wijnholds, et al, 2016.
10. ↑ Роберт Гласс. Факты и заблуждения профессионального программирования. = Facts and Fallacies of Software Engineering. — 2004. — ISBN 5-93286-092-8; 978-5-93286-092-2.
11. ↑ Wagner, Stefan (2015). «

Принципы обеспечения показателей качества программного продукта

Инфоурок
›

Другое
›Презентации›Принципы обеспечения показателей качества программного продукта

Описание презентации по отдельным слайдам:

1 слайд

Описание слайда:

Принципы обеспечения показателей качества программного продукта

2 слайд

Описание слайда:

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

3 слайд

Описание слайда:

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

4 слайд

Описание слайда:

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

5 слайд

Описание слайда:

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

6 слайд

Описание слайда:

Важным аспектом создания качественного ПО является: Защищенность определяет степень безопасности системы от повреждений, утраты, несанкционированного доступа и преступной деятельности. Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты исправления дефектов, внесения корректив для соответствия новым требованиям, управления измененной средой.

7 слайд

Описание слайда:

Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться создания качественного ПО, избегать потерь времени на переделку, повторное проектирования и перепрограммирование ПО.

8 слайд

Описание слайда:

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

9 слайд

Описание слайда:

На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования для гарантии того, что промежуточные версии отвечают заданным показателям качества. При этом применяются автоматические и ручные тесты.

10 слайд

Описание слайда:

Модульное тестирование — предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных.

11 слайд

Описание слайда:

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

12 слайд

Описание слайда:

Интеграционное тестирование используется для проверки корректности совместной работы компонентов программного продукта.

13 слайд

Описание слайда:

Функциональное тестирование предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций.

14 слайд

Описание слайда:

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

15 слайд

Описание слайда:

Регрессионное тестирование применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом.

16 слайд

Описание слайда:

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

17 слайд

Описание слайда:

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

18 слайд

Описание слайда:

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

19 слайд

Описание слайда:

Для улучшения качества кода программных приложений применяют рефакторинг. По определению Фаулера М. рефакторинг определяется как «процесс изменения программной системы таким образом, что её внешнее поведение не изменяется, а внутренняя структура улучшается». Следовательно, в процессе проектирования для создания высококачественного программного продукта необходимо не только обеспечить выполнение функциональных требований, но и нефункциональных, в частности, удобства сопровождения, что предполагает возможность и простоту внесения изменений в код, а также возможность легкого понимания созданного кода.

20 слайд

Описание слайда:

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

21 слайд

Описание слайда:

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

22 слайд

Описание слайда:

Принцип инверсии зависимостей определяет два положения: модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций; абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Принцип разделения интерфейсов определяет, что клиенты должны знать только об абстрактных интерфейсах, обладающих свойством сцепленности.

23 слайд

Описание слайда:

Паттерны проектирования предлагают универсальные, проверенные практикой решения. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда, Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/шлюз, Заместитель и Шлюз, Посетитель и Состояние. Использование паттернов при разработке позволяет создавать программное обеспечение, которое легко модифицировать и сопровождать.

24 слайд

Описание слайда:

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

25 слайд

Описание слайда:

Итог Качество программного продукта определяется по нескольким критериям и качественный программный продукт должен отвечать функциональным и нефункциональным требованиям. В жизненном цикле приложения качество должно отслеживаться на всех его этапах. Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования.

26 слайд

Описание слайда:

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

Курс профессиональной переподготовки

Педагог-библиотекарь

Курс повышения квалификации

Курс профессиональной переподготовки

Специалист в области охраны труда

Обеспечение качества программного продукта / Хабр

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

Далее по тексту будет находится краткий обзор инструментов с помощью которых можно анализировать различные характиристики в приложениях созданных на PHP. Данный материал появился на свет в результате некоторых экспериментов в области непрерывной интеграции, и должен был являться частью статьи про непрерывную интеграцию (спойлерить пока не буду, боюсь сглазить) все в том же РНР, но я решил все-таки выделить его в самостоятельный обзор, так как возможно, в последующих статьях я буду ссылаться на него, а так же надеюсь узнать об аналогичных инструментах еще не попавших мне на глаза. Некоторые инструменты уже были рассмотрены достаточно подробно, но тем не менее полного списка всех доступных еще не было.

PHP_CodeCoverage

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

PhpDocumentor

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

PHP Copy/Paste Detector [phpcpd]

Название говорит само за себя: находит дублированный код и сообщает о нем.

PHP_Depend

Собирает и отображает статистическую информацию о проекте.

PHP_PMD

Ответвление от PHP_Depend: отображает информацию о размерах кода, используемых именах, неиспользуемом коде. Обзор от DevMan

PHP_CodeSniffer

Позволяет наблюдать за состоянием PHP, JavaScript и CSS файлов и определять отклонения от принятых стандартов кодирования. Обзор от DevMan

PHPUnit

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

PHP_CodeBrowser

Обеспечивает просмотр кода с синтаксической подсветкой, имеет богатые возможности по визуализации, может использовать отчеты от: phpunit, phpcpd, padawan, phpcs. Из этого обзора можно понять насколько инструмент перспективный.

phploc

Еще один инструмент собирающий статистическую информацию о проекте.

phpdcd

Детектор неиспользуемого кода (Dead Code Detector) для PHP. Он сканирует PHP проект на предмет всех определенных функций и методов и сообщает о них как о неиспользуемых если из вызов не встречается хотя бы однажды

Padawan

Инструмент для обнаружения антипаттернов, обходных путей и прочих неприятностей.

PHP_CachegrindParser

Обработчик для cachegrind файлов создающий xml отчеты для последующего использования в CI.

В следующей статье рассмотрим как применять на практике эти инструменты с пользой и попробуем определить их потенциальную полезность.

% PDF-1.2
%
232 0 объект
>
endobj
xref
232 1044
0000000016 00000 н.
0000021234 00000 п.
0000045964 00000 п.
0000046186 00000 п.
0000061810 00000 п.
0000067459 00000 п.
0000067922 00000 п.
0000068472 00000 п.
0000069045 00000 п.
0000069871 00000 п.
0000070380 00000 п.
0000071161 00000 п.
0000071342 00000 п.
0000071648 00000 п.
0000072960 00000 п.
0000073271 00000 п.
0000073393 00000 п.
0000079504 00000 п.
0000080150 00000 п.
0000080394 00000 п.
0000080952 00000 п.
0000080975 00000 п.
0000083099 00000 п.
0000083122 00000 п.
0000084974 00000 п.
0000084997 00000 п.
0000086655 00000 п.
0000086871 00000 п.
0000087563 00000 п.
0000087586 00000 п.
00000

00000 п.
00000

00000 п.
0000091862 00000 п.
0000091885 00000 п.
0000093785 00000 п.
0000093808 00000 п.
0000095470 00000 п.
0000095652 00000 п.
0000095840 00000 п.
0000096022 00000 п.
0000096207 00000 п.
0000096387 00000 п.
0000096580 00000 п.
0000096762 00000 п.
0000096945 00000 п.
0000097127 00000 п.
0000097309 00000 п.
0000097494 00000 п.
0000097679 00000 п.
0000097861 00000 п.
0000098053 00000 п.
0000098238 00000 п.
0000098423 00000 п.
0000098609 00000 п.
0000098794 00000 п.
0000098980 00000 п.
0000099165 00000 п.
0000099351 00000 п.
0000099536 00000 н.
0000099725 00000 п.
0000099911 00000 н.
0000100097 00000 п.
0000100298 00000 н.
0000100487 00000 н.
0000100679 00000 н.
0000100868 00000 н.
0000101053 00000 п.
0000101238 00000 п
0000101423 00000 п.
0000101628 00000 н.
0000101826 00000 н.
0000102008 00000 н.
0000102193 00000 п.
0000102378 00000 п.
0000102570 00000 н.
0000102758 00000 н.
0000102937 00000 п.
0000103119 00000 п.
0000103305 00000 н.
0000103484 00000 н.
0000103672 00000 п.
0000103851 00000 н.
0000104030 00000 н.
0000104218 00000 п.
0000104403 00000 н.
0000104608 00000 н.
0000104790 00000 н.
0000104984 00000 н.
0000105172 00000 н.
0000105369 00000 н.
0000105560 00000 н.
0000105745 00000 н.
0000105930 00000 н.
0000106116 00000 п.
0000106302 00000 н.
0000106516 00000 н.
0000106698 00000 н.
0000106883 00000 н.
0000107069 00000 н.
0000107249 00000 н.
0000107435 00000 п.
0000107618 00000 п.
0000107797 00000 п.
0000107994 00000 н.
0000108180 00000 п.
0000108363 00000 п.
0000108546 00000 н.
0000108728 00000 н.
0000108921 00000 н.
0000109103 00000 п.
0000109282 00000 п.
0000109464 00000 н.
0000109643 00000 п.
0000109826 00000 н.
0000110009 00000 н.
0000110198 00000 п.
0000110383 00000 п.
0000110565 00000 н.
0000110747 00000 н.
0000110929 00000 н.
0000111111 00000 н.
0000111300 00000 н.
0000111480 00000 н.
0000111662 00000 н.
0000111842 00000 н.
0000112024 00000 н.
0000112209 00000 н.
0000112391 00000 н.
0000112573 00000 н.
0000112755 00000 н.
0000112937 00000 н.
0000113117 00000 н.
0000113299 00000 н.
0000113479 00000 п.
0000113661 00000 н.
0000113841 00000 н.
0000114030 00000 н.
0000114216 00000 н.
0000114410 00000 н.
0000114592 00000 н.
0000114775 00000 н.
0000114957 00000 н.
0000115154 00000 н.
0000115336 00000 н.
0000115516 00000 н.
0000115696 00000 п.
0000115876 00000 н.
0000116059 00000 н.
0000116239 00000 н.
0000116419 00000 н.
0000116602 00000 н.
0000116784 00000 н.
0000116964 00000 н.
0000117144 00000 н.
0000117324 00000 н.
0000117504 00000 н.
0000117687 00000 н.
0000117867 00000 н.
0000118047 00000 н.
0000118227 00000 н.
0000118406 00000 н.
0000118588 00000 н.
0000118770 00000 н.
0000118955 00000 н.
0000119150 00000 н.
0000119335 00000 п.
0000119517 00000 н.
0000119699 00000 н.
0000119881 00000 н.
0000120063 00000 н.
0000120246 00000 н.
0000120428 00000 н.
0000120610 00000 н.
0000120795 00000 н.
0000120977 00000 н.
0000121159 00000 н.
0000121341 00000 н.
0000121520 00000 н.
0000121717 00000 н.
0000121896 00000 н.
0000122078 00000 н.
0000122260 00000 н.
0000122442 00000 н.
0000122621 00000 н.
0000122800 00000 н.
0000122982 00000 н.
0000123164 00000 н.
0000123343 00000 п.
0000123525 00000 н.
0000123707 00000 н.
0000123887 00000 н.
0000124070 00000 н.
0000124263 00000 н.
0000124445 00000 н.
0000124627 00000 н.
0000124809 00000 н.
0000124991 00000 н.
0000125174 00000 н.
0000125356 00000 н.
0000125542 00000 н.
0000125724 00000 н.
0000125906 00000 н.
0000126104 00000 н.
0000126286 00000 н.
0000126472 00000 н.
0000126654 00000 н.
0000126836 00000 н.
0000127018 00000 н.
0000127204 00000 н.
0000127386 00000 н.
0000127568 00000 н.
0000127750 00000 н.
0000127936 00000 н.
0000128118 00000 н.
0000128300 00000 н.
0000128486 00000 н.
0000128672 00000 н.
0000128855 00000 н.
0000129035 00000 н.
0000129217 00000 н.
0000129399 00000 н.
0000129578 00000 н.
0000129764 00000 н.
0000129953 00000 н.
0000130132 00000 н.
0000130311 00000 п.
0000130490 00000 н.
0000130672 00000 н.
0000130861 00000 п.
0000131046 00000 н.
0000131228 00000 н.
0000131416 00000 н.
0000131607 00000 н.
0000131789 00000 н.
0000131971 00000 н.
0000132153 00000 н.
0000132335 00000 н.
0000132517 00000 н.
0000132696 00000 н.
0000132894 00000 н.
0000133076 00000 н.
0000133264 00000 н.
0000133443 00000 н.
0000133622 00000 н.
0000133811 00000 н.
0000133990 00000 н.
0000134173 00000 н.
0000134352 00000 н.
0000134534 00000 н.
0000134713 00000 н.
0000134892 00000 н.
0000135071 00000 н.
0000135263 00000 н.
0000135442 00000 н.
0000135624 00000 н.
0000135817 00000 н.
0000135999 00000 н.
0000136181 00000 п.
0000136369 00000 н.
0000136551 00000 н.
0000136736 00000 н.
0000136918 00000 п.
0000137100 00000 н.
0000137279 00000 н.
0000137458 00000 н.
0000137646 00000 н.
0000137828 00000 н.
0000138010 00000 н.
0000138192 00000 н.
0000138392 00000 н.
0000138574 00000 н.
0000138756 00000 н.
0000138939 00000 н.
0000139121 00000 н.
0000139307 00000 н.
0000139489 00000 н.
0000139671 00000 н.
0000139853 00000 н.
0000140035 00000 н.
0000140227 00000 н.
0000140413 00000 н.
0000140595 00000 п.
0000140781 00000 п.
0000140967 00000 н.
0000141149 00000 н.
0000141335 00000 н.
0000141517 00000 н.
0000141700 00000 н.
0000141880 00000 н.
0000142062 00000 н.
0000142256 00000 н.
0000142442 00000 н.
0000142628 00000 н.
0000142810 00000 н.
0000143001 00000 п.
0000143183 00000 н.
0000143365 00000 н.
0000143547 00000 н.
0000143729 00000 н.
0000143915 00000 н.
0000144098 00000 п.
0000144284 00000 п.
0000144467 00000 н.
0000144660 00000 н.
0000144843 00000 н.
0000145026 00000 н.
0000145217 00000 п.
0000145399 00000 н.
0000145587 00000 н.
0000145770 00000 н.
0000145959 00000 н.
0000146151 00000 н.
0000146333 00000 п.
0000146519 00000 п.
0000146701 00000 н.
0000146881 00000 н.
0000147063 00000 н.
0000147245 00000 н.
0000147427 00000 н.
0000147606 00000 н.
0000147788 00000 н.
0000147967 00000 н.
0000148149 00000 н.
0000148338 00000 п.
0000148517 00000 н.
0000148702 00000 н.
0000148884 00000 н.
0000149066 00000 н.
0000149248 00000 н.
0000149434 00000 н.
0000149616 00000 н.
0000149798 00000 п.
0000149984 00000 н.
0000150166 00000 н.
0000150346 00000 п.
0000150532 00000 н.
0000150714 00000 н.
0000150893 00000 н.
0000151072 00000 н.
0000151251 00000 н.
0000151430 00000 н.
0000151612 00000 н.
0000151801 00000 н.
0000151983 00000 н.
0000152178 00000 н.
0000152361 00000 н.
0000152544 00000 н.
0000152730 00000 н.
0000152916 00000 н.
0000153098 00000 н.
0000153284 00000 н.
0000153472 00000 н.
0000153654 00000 н.
0000153833 00000 н.
0000154012 00000 н.
0000154194 00000 н.
0000154373 00000 н.
0000154552 00000 н.
0000154734 00000 н.
0000154923 00000 н.
0000155106 00000 н.
0000155289 00000 н.
0000155477 00000 н.
0000155672 00000 н.
0000155860 00000 н.
0000156048 00000 н.
0000156236 00000 п.
0000156431 00000 н.
0000156614 00000 н.
0000156797 00000 н.
0000156983 00000 н.
0000157163 00000 н.
0000157358 00000 н.
0000157541 00000 н.
0000157721 00000 н.
0000157910 00000 п.
0000158090 00000 н.
0000158270 00000 н.
0000158450 00000 н.
0000158632 00000 н.
0000158812 00000 н.
0000158992 00000 н.
0000159172 00000 н.
0000159369 00000 н.
0000159549 00000 н.
0000159732 00000 н.
0000159914 00000 н.
0000160099 00000 н.
0000160285 00000 н.
0000160465 00000 н.
0000160661 00000 н.
0000160843 00000 н.
0000161025 00000 н.
0000161207 00000 н.
0000161389 00000 н.
0000161571 00000 н.
0000161750 00000 н.
0000161932 00000 н.
0000162128 00000 н.
0000162311 00000 н.
0000162490 00000 н.
0000162669 00000 н.
0000162851 00000 н.
0000163033 00000 н.
0000163212 00000 н.
0000163392 00000 н.
0000163574 00000 н.
0000163763 00000 н.
0000163952 00000 н.
0000164138 00000 н.
0000164321 00000 н.
0000164501 00000 н.
0000164706 00000 н.
0000164889 00000 н.
0000165078 00000 н.
0000165261 00000 н.
0000165444 00000 н.
0000165627 00000 н.
0000165807 00000 н.
0000165996 00000 н.
0000166182 00000 н.
0000166403 00000 н.
0000166583 00000 н.
0000166762 00000 н.
0000166942 00000 н.
0000167128 00000 н.
0000167307 00000 н.
0000167486 00000 н.
0000167672 00000 н.
0000167854 00000 н.
0000168048 00000 н.
0000168252 00000 н.
0000168431 00000 н.
0000168614 00000 н.
0000168793 00000 н.
0000168972 00000 н.
0000169152 00000 н.
0000169335 00000 н.
0000169518 00000 н.
0000169701 00000 н.
0000169899 00000 н.
0000170082 00000 н.
0000170276 00000 н.
0000170461 00000 н.
0000170650 00000 н.
0000170832 00000 н.
0000171014 00000 н.
0000171197 00000 н.
0000171380 00000 н.
0000171563 00000 н.
0000171746 00000 н.
0000171926 00000 н.
0000172112 00000 н.
0000172301 00000 н.
0000172487 00000 н.
0000172670 00000 н.
0000172853 00000 н.
0000173036 00000 н.
0000173222 00000 н.
0000173419 00000 н.
0000173599 00000 н.
0000173793 00000 н.
0000173972 00000 н.
0000174151 00000 н.
0000174331 00000 н.
0000174510 00000 н.
0000174707 00000 н.
0000174889 00000 н.
0000175071 00000 н.
0000175253 00000 н.
0000175435 00000 н.
0000175627 00000 н.
0000175813 00000 н.
0000175999 00000 н.
0000176181 00000 н.
0000176363 00000 н.
0000176545 00000 н.
0000176730 00000 н.
0000176912 00000 н.
0000177107 00000 н.
0000177289 00000 н.
0000177471 00000 н.
0000177650 00000 н.
0000177829 00000 н.
0000178020 00000 н.
0000178214 00000 н.
0000178408 00000 н.
0000178590 00000 н.
0000178776 00000 н.
0000178958 00000 н.
0000179144 00000 н.
0000179326 00000 н.
0000179512 00000 н.
0000179694 00000 н.
0000179891 00000 н.
0000180076 00000 н.
0000180261 00000 п.
0000180443 00000 н.
0000180629 00000 н.
0000180812 00000 н.
0000180997 00000 н.
0000181182 00000 н.
0000181361 00000 н.
0000181541 00000 н.
0000181723 00000 н.
0000181905 00000 н.
0000182087 00000 н.
0000182269 00000 н.
0000182448 00000 н.
0000182627 00000 н.
0000182809 00000 н.
0000183002 00000 н.
0000183186 00000 н.
0000183371 00000 н.
0000183554 00000 н.
0000183739 00000 н.
0000183924 00000 н.
0000184106 00000 н.
0000184291 00000 н.
0000184471 00000 н.
0000184656 00000 н.
0000184838 00000 н.
0000185021 00000 н.
0000185206 00000 н.
0000185386 00000 н.
0000185568 00000 н.
0000185762 00000 н.
0000185947 00000 н.
0000186129 00000 н.
0000186311 00000 н.
0000186504 00000 н.
0000186686 00000 н.
0000186868 00000 н.
0000187051 00000 н.
0000187233 00000 н.
0000187415 00000 н.
0000187598 00000 н.
0000187778 00000 н.
0000187958 00000 н.
0000188138 00000 н.
0000188318 00000 н.
0000188498 00000 н.
0000188677 00000 н.
0000188857 00000 н.
0000189040 00000 н.
0000189222 00000 н.
0000189402 00000 н.
0000189584 00000 н.
0000189766 00000 н.
0000189952 00000 н.
00001 00000 н.
00001 00000 н.
00001

00000 н.
00001

00000 н.
00001

00000 н.
00001

00000 н.
00001

00000 н.
00001
00000 н.
0000191613 00000 н.
0000191801 00000 н.
0000191981 00000 н.
0000192169 00000 н.
0000192351 00000 н.
0000192533 00000 н.
0000192722 00000 н.
0000192908 00000 н.
0000193088 00000 н.
0000193273 00000 н.
0000193458 00000 н.
0000193643 00000 н.
0000193848 00000 н.
0000194030 00000 н.
0000194221 00000 н.
0000194403 00000 н.
0000194585 00000 н.
0000194770 00000 н.
0000194959 00000 н.
0000195139 00000 н.
0000195319 00000 н.
0000195499 00000 н.
0000195679 00000 н.
0000195859 00000 н.
0000196039 00000 н.
0000196219 00000 н.
0000196399 00000 н.
0000196585 00000 н.
0000196767 00000 н.
0000196953 00000 н.
0000197133 00000 н.
0000197312 00000 н.
0000197492 00000 н.
0000197677 00000 н.
0000197862 00000 н.
0000198056 00000 н.
0000198264 00000 н.
0000198447 00000 н.
0000198641 00000 н.
0000198823 00000 н.
0000199005 00000 н.
0000199187 00000 н.
0000199367 00000 н.
0000199550 00000 н.
0000199730 00000 н.
0000199922 00000 н.
0000200111 00000 п.
0000200305 00000 н.
0000200487 00000 н.
0000200673 00000 н.
0000200855 00000 н.
0000201041 00000 н.
0000201223 00000 н.
0000201412 00000 н.
0000201597 00000 н.
0000201776 00000 н.
0000201960 00000 н.
0000202142 00000 н.
0000202321 00000 н.
0000202507 00000 н.
0000202693 00000 н.
0000202875 00000 н.
0000203054 00000 н.
0000203236 00000 н.
0000203416 00000 н.
0000203596 00000 н.
0000203786 00000 н.
0000203969 00000 н.
0000204152 00000 н.
0000204341 00000 н.
0000204539 00000 н.
0000204718 00000 н.
0000204898 00000 н.
0000205078 00000 н.
0000205263 00000 н.
0000205445 00000 н.
0000205627 00000 н.
0000205816 00000 н.
0000205998 00000 н.
0000206180 00000 н.
0000206368 00000 н.
0000206550 00000 н.
0000206747 00000 н.
0000206927 00000 н.
0000207113 00000 н.
0000207296 00000 н.
0000207479 00000 н.
0000207662 00000 н.
0000207854 00000 н.
0000208037 00000 н.
0000208227 00000 н.
0000208424 00000 н.
0000208604 00000 н.
0000208783 00000 н.
0000208969 00000 н.
0000209152 00000 н.
0000209347 00000 н.
0000209536 00000 н.
0000209721 00000 н.
0000209903 00000 н.
0000210088 00000 н.
0000210270 00000 п.
0000210452 00000 п.
0000210634 00000 п.
0000210816 00000 н.
0000211011 00000 н.
0000211193 00000 п.
0000211375 00000 п.
0000211557 00000 н.
0000211736 00000 н.
0000211918 00000 н.
0000212107 00000 н.
0000212298 00000 н.
0000212477 00000 н.
0000212659 00000 н.
0000212838 00000 н.
0000213017 00000 н.
0000213199 00000 п.
0000213378 00000 п.
0000213561 00000 п.
0000213740 00000 н.
0000213920 00000 н.
0000214103 00000 п.
0000214282 00000 н.
0000214464 00000 н.
0000214644 00000 н.
0000214826 00000 н.
0000215009 00000 н.
0000215191 00000 н.
0000215370 00000 н.
0000215555 00000 н.
0000215735 00000 н.
0000215915 00000 н.
0000216094 00000 н.
0000216274 00000 н.
0000216459 00000 н.
0000216647 00000 н.
0000216827 00000 н.
0000217010 00000 н.
0000217198 00000 н.
0000217383 00000 п.
0000217571 00000 н.
0000217759 00000 н.
0000217939 00000 н.
0000218122 00000 н.
0000218302 00000 н.
0000218484 00000 н.
0000218670 00000 н.
0000218852 00000 н.
0000219040 00000 н.
0000219225 00000 н.
0000219404 00000 н.
0000219592 00000 н.
0000219777 00000 н.
0000219959 00000 н.
0000220144 00000 н.
0000220332 00000 н.
0000220517 00000 н.
0000220699 00000 н.
0000220884 00000 н.
0000221066 00000 н.
0000221252 00000 н.
0000221431 00000 н.
0000221613 00000 н.
0000221813 00000 н.
0000221999 00000 н.
0000222182 00000 н.
0000222371 00000 н.
0000222553 00000 н.
0000222744 00000 н.
0000222926 00000 н.
0000223111 00000 п.
0000223293 00000 н.
0000223484 00000 н.
0000223666 00000 н.
0000223862 00000 н.
0000224044 00000 н.
0000224226 00000 н.
0000224405 00000 н.
0000224610 00000 н.
0000224792 00000 н.
0000224990 00000 н.
0000225175 00000 н.
0000225357 00000 н.
0000225542 00000 н.
0000225727 00000 н.
0000225915 00000 н.
0000226094 00000 н.
0000226273 00000 н.
0000226455 00000 н.
0000226644 00000 н.
0000226823 00000 н
0000227005 00000 н.
0000227191 00000 н.
0000227376 00000 н.
0000227558 00000 н.
0000227740 00000 н.
0000227919 00000 п.
0000228101 00000 п.
0000228283 00000 н.
0000228465 00000 н.
0000228644 00000 н.
0000228823 00000 н.
0000229005 00000 н.
0000229184 00000 п.
0000229366 00000 н.
0000229546 00000 н.
0000229725 00000 н.
0000229904 00000 н.
0000230083 00000 н.
0000230271 00000 н.
0000230455 00000 н.
0000230642 00000 п.
0000230829 00000 н.
0000231012 00000 н.
0000231195 00000 н.
0000231385 00000 н.
0000231568 00000 н.
0000231772 00000 н.
0000231955 00000 н.
0000232138 00000 н.
0000232331 00000 п.
0000232517 00000 н.
0000232700 00000 н.
0000232887 00000 н.
0000233070 00000 н.
0000233264 00000 н.
0000233445 00000 н.
0000233626 00000 н.
0000233810 00000 н.
0000233991 00000 н.
0000234175 00000 н.
0000234356 00000 н.
0000234537 00000 п.
0000234724 00000 н.
0000234905 00000 н.
0000235086 00000 н.
0000235270 00000 н.
0000235454 00000 п.
0000235635 00000 п.
0000235816 00000 н.
0000235997 00000 н.
0000236178 00000 н.
0000236365 00000 н.
0000236548 00000 н.
0000236734 00000 н.
0000236920 00000 н.
0000237103 00000 н.
0000237286 00000 н.
0000237469 00000 н.
0000237658 00000 н.
0000237847 00000 н.
0000238031 00000 н.
0000238215 00000 н.
0000238401 00000 п.
0000238584 00000 н.
0000238770 00000 н.
0000238953 00000 н.
0000239137 00000 п.
0000239323 00000 п.
0000239509 00000 н.
0000239698 00000 н.
0000239881 00000 н.
0000240067 00000 н.
0000240256 00000 н.
0000240439 00000 н.
0000240628 00000 н.
0000240826 00000 н.
0000241020 00000 н.
0000241207 00000 н.
0000241391 00000 н.
0000241580 00000 н.
0000241776 00000 н.
0000241960 00000 н.
0000242149 00000 н.
0000242329 00000 н.
0000242513 00000 н.
0000242694 00000 н.
0000242875 00000 н.
0000243056 00000 н.
0000243237 00000 н.
0000243418 00000 н.
0000243602 00000 н.
0000243786 00000 н.
0000243970 00000 н.
0000244159 00000 н.
0000244340 00000 н.
0000244524 00000 н.
0000244708 00000 н.
0000244889 00000 н.
0000245072 00000 н.
0000245255 00000 н.
0000245438 00000 п.
0000245621 00000 н.
0000245801 00000 н.
0000245992 00000 н.
0000246178 00000 н.
0000246364 00000 н.
0000246547 00000 н.
0000246730 00000 н.
0000246916 00000 н.
0000247099 00000 н.
0000247279 00000 н.
0000247459 00000 н.
0000247642 00000 н.
0000247828 00000 н.
0000248011 00000 н.
0000248194 00000 н.
0000248377 00000 н.
0000248560 00000 н.
0000248743 00000 н.
0000248936 00000 н.
0000249132 00000 н.
0000249319 00000 п.
0000249502 00000 н.
0000249692 00000 н.
0000249887 00000 н.
0000250077 00000 н.
0000250260 00000 н.
0000250446 00000 н.
0000250629 00000 н.
0000250812 00000 н.
0000250992 00000 н.
0000251178 00000 н.
0000251361 00000 н.
0000251547 00000 н.
0000251730 00000 н.
0000251913 00000 н.
0000252096 00000 н.
0000252279 00000 п.
0000252468 00000 н.
0000252651 00000 н.
0000252837 00000 н.
0000253023 00000 н.
0000253206 00000 н.
0000253390 00000 н.
0000253573 00000 н.
0000253762 00000 н.
0000253949 00000 н.
0000254129 00000 н.
0000254309 00000 н.
0000254495 00000 н.
0000254678 00000 н.
0000254864 00000 н.
0000255047 00000 н.
0000255227 00000 н.
0000255410 00000 н.
0000255599 00000 н.
0000255795 00000 н.
0000255981 00000 н.
0000256170 00000 н.
0000256350 00000 н.
0000256533 00000 н.
0000256719 00000 н.
0000256903 00000 н.
0000257086 00000 н.
0000257267 00000 н.
0000257457 00000 н.
0000257640 00000 н.
0000257823 00000 н.
0000258006 00000 н.
0000258190 00000 н.
0000258379 00000 н.
0000258568 00000 н.
0000258751 00000 н.
0000258931 00000 н.
0000259111 00000 п.
0000259291 00000 н.
0000259480 00000 н.
0000259666 00000 н.
0000259849 00000 н.
0000260029 00000 н.
0000260212 00000 н.
0000260395 00000 н.
0000260578 00000 н.
0000260761 00000 н.
0000260945 00000 н.
0000261131 00000 н.
0000261317 00000 н.
0000261504 00000 н.
0000261690 00000 н.
0000261873 00000 н.
0000262059 00000 н.
0000262239 00000 н.
0000262425 00000 н.
0000262608 00000 н.
0000262791 00000 н.
0000262974 00000 н.
0000263155 00000 н.
0000263336 00000 н.
0000263534 00000 н.
0000263717 00000 н.
0000263900 00000 н.
0000264083 00000 н.
0000264267 00000 н.
0000264450 00000 н.
0000264630 00000 н.
0000264816 00000 н.
0000264996 00000 н.
0000265177 00000 н.
0000265360 00000 н.
0000265546 00000 н.
0000265736 00000 н.
0000265919 00000 п.
0000266112 00000 н.
0000266295 00000 н.
0000266478 00000 н.
0000266661 00000 п.
0000266859 00000 н.
0000267058 00000 н.
0000267241 00000 н.
0000267427 00000 н.
0000267608 00000 н.
0000267794 00000 п.
0000267987 00000 н.
0000268170 00000 н.
0000268356 00000 н.
0000268546 00000 н.
0000268727 00000 н.
0000268907 00000 н.
0000269090 00000 н.
0000269273 00000 н.
0000269456 00000 н.
0000269639 00000 н.
0000269820 00000 н.
0000270017 00000 н.
0000270204 00000 н.
0000270388 00000 п.
0000270572 00000 н.
0000270756 00000 н.
0000270937 00000 н.
0000271121 00000 н.
0000271311 00000 н.
0000271494 00000 н.
0000271681 00000 н.
0000271864 00000 н.
0000272047 00000 н.
0000272236 00000 н.
0000272417 00000 н.
0000272601 00000 н.
0000272792 00000 н.
0000272975 00000 н.
0000273158 00000 н.
0000273341 00000 н.
0000273524 00000 н.
0000273707 00000 н.
0000273891 00000 н.
0000274075 00000 н.
0000274265 00000 н.
0000274448 00000 н.
0000274631 00000 н.
0000274814 00000 н.
0000274997 00000 н.
0000275183 00000 п.
0000275378 00000 п.
0000275561 00000 н.
0000275741 00000 н.
0000275924 00000 н.
0000276104 00000 н.
0000276284 00000 н.
0000276467 00000 н.
0000276650 00000 н.
0000276830 00000 н.
0000277017 00000 н.
0000277201 00000 н.
0000277384 00000 н.
0000277571 00000 н.
0000277769 00000 н.
0000277962 00000 н.
0000278145 00000 н.
0000278329 00000 н.
0000278516 00000 н.
0000278710 00000 н.
0000278897 00000 н.
0000279084 00000 н.
0000279271 00000 н.
0000279460 00000 н.
0000279643 00000 н.
0000279830 00000 н.
0000280017 00000 н.
0000280198 00000 н.
0000280222 00000 н.
0000282893 00000 н.
0000282973 00000 н.
0000021291 00000 п.
0000045939 00000 п.
трейлер
]
>>
startxref
0
%% EOF

233 0 объект
>
endobj
1274 0 объект
>
ручей
HWT / PE RHB7)! Q

Какие атрибуты качества?

Для начала давайте вкратце разберемся Что такое качество ? Качество можно определить по-разному.Определение качества может отличаться от человека к человеку. Но, наконец, должны быть какие-то стандарты. Таким образом, Качество можно определить как

• Степень совершенства — Оксфордский словарь
• Соответствие назначению — Эдвард Деминг
• Лучшее для использования покупателем и продажной цене — Фейгенбаум
• Совокупность характеристик объекта, которые влияют на его способность удовлетворить заявленные или подразумеваемые потребности — ISO

Как разработчик продукта определяет качество? — Товар соответствует требованиям заказчика.
Как клиент определяет качество? — Необходимая функциональность предоставляется в удобном для пользователя виде.

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

Следующие факторы используются для измерения качества разработки программного обеспечения. Каждый атрибут можно использовать для измерения производительности продукта. Эти атрибуты могут использоваться как для обеспечения качества, так и для контроля качества.

Мероприятия по обеспечению качества направлены на предотвращение появления дефектов, а Действия по контролю качества направлены на обнаружение дефектов в продуктах и ​​услугах.

Надежность

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

Ремонтопригодность

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

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

Удобство использования

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

Система должна быть:

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

Переносимость

Это можно измерить с точки зрения затрат на перенос, технических проблем, связанных с переносом, поведенческих проблем, связанных с переносом.

Правильность

Приложение должно быть правильным с точки зрения его функциональности, внутренние вычисления и навигация должны быть правильными. Это означает, что приложение должно соответствовать функциональным требованиям.

Эффективность

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

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

Рекомендуемая литература = >> Что такое тестирование эффективности

Целостность или безопасность

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

Тестируемость

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

Гибкость

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

Возможность повторного использования

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

Взаимодействие

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

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

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

Разработка программного обеспечения | Качественные характеристики хорошего SRS

Статья по теме: Написание хорошей SRS для вашего проекта

Ниже приведены характеристики хорошего документа SRS:

1. Правильность:
   Пользовательская проверка используется для подтверждения правильности требований, изложенных в SRS.SRS считается правильной, если она покрывает все требования, которые фактически ожидаются от системы.
2. Полнота:
   Полнота SRS указывает на полное завершение, включая нумерацию всех страниц, максимальное разрешение подлежащих определению частей, а также надлежащее покрытие всех функциональных и нефункциональных требований.
3. Согласованность:
   Требования в SRS считаются согласованными, если нет конфликтов между каким-либо набором требований.Примеры конфликтов включают различия в терминологии, используемые в разных местах, логические конфликты, такие как период времени создания отчета и т. Д.
4. Однозначность:
   SRS считается однозначной, если все изложенные требования имеют только одну интерпретацию. Некоторые из способов предотвратить однозначность включают использование методов моделирования, таких как диаграммы ER, надлежащие обзоры, проверки партнеров и т. Д.
5. Рейтинг по важности и стабильности:
   Должен быть критерий для классификации требований как менее или более важных или более конкретно как желательных или существенных.Идентификационный знак может использоваться с каждым требованием, чтобы указать его ранг или стабильность.
6. Возможность модификации:
   SRS должна быть сделана настолько модифицируемой, насколько это возможно, и должна быть способна легко принимать изменения в системе до некоторой степени. Изменения должны быть правильно проиндексированы и снабжены перекрестными ссылками.
7. Проверяемость:
   SRS поддается проверке, если существует определенный метод количественного измерения степени, в которой каждое требование выполняется системой.Например, требование о том, что система должна быть удобной для пользователя, не поддается проверке, и следует избегать перечисления таких требований.
8. Отслеживаемость:
   Необходимо уметь отследить требование для разработки компонента, а затем кодировать сегмент в программе. Точно так же можно отследить требование до соответствующих тестовых примеров.
9. Независимость дизайна:
   Должна быть возможность выбора из нескольких альтернативных вариантов дизайна для окончательной системы.В частности, SRS не должна включать никаких деталей реализации.
10. Тестируемость:
    SRS должна быть написана таким образом, чтобы можно было легко генерировать тестовые примеры и планы тестирования из документа.
11. Понятно для клиента:
    Конечный пользователь может быть экспертом в своей конкретной области, но может не быть экспертом в области компьютерных наук. Следовательно, следует по возможности избегать использования формальных обозначений и символов.Язык должен быть простым и понятным.
12. Правый уровень абстракции:
    Если SRS написана для этапа требований, детали должны быть объяснены явно. В то время как для технико-экономического обоснования можно использовать меньше деталей. Следовательно, уровень абстракции зависит от цели SRS.

Вниманию читателя! Не прекращайте учиться сейчас. Получите все важные концепции теории CS для собеседований SDE с курсом теории CS по доступной для студентов цене и будьте готовы к отрасли.

---

Эссе по характеристикам качества программного обеспечения — 1440 слов

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

Возможность. Может ли продукт выполнять ценные функции?
— Полнота: доступны все важные функции, которые нужны конечным пользователям. — Точность: любой вывод или расчет в продукте верны и представлены значащими цифрами.- Эффективность: выполняет свои действия эффективным образом (без выполнения того, что не должно делать.) — Взаимодействие: различные функции взаимодействуют друг с другом наилучшим образом. — Параллелизм: возможность выполнять несколько параллельных задач и запускаться одновременно с другими процессами. — Агностицизм данных: поддерживает все возможные форматы данных и справляется с шумом. — Расширяемость: возможность для клиентов или третьих лиц добавлять функции или изменять поведение.

Надежность. Можете ли вы доверять продукту во многих сложных ситуациях? — Стабильность: продукт не должен вызывать сбоев, необработанных исключений или ошибок скрипта.- Надежность: продукт аккуратно обрабатывает предвиденные и непредвиденные ошибки. — Устранение стресса: как система справляется с превышением различных лимитов? — Восстанавливаемость: можно восстановить и продолжить использование продукта после фатальной ошибки. — Целостность данных: все типы данных остаются нетронутыми во всем продукте. — Безопасность: продукт не будет причинять вред людям или имуществу. — Аварийное восстановление: что, если случится что-то действительно плохое? — Надежность: является ли поведение продукта последовательным, предсказуемым и заслуживающим доверия?

Удобство использования.Продукт прост в использовании?
— Affordance: продукт предлагает раскрыть возможности продукта. — Интуитивность: легко понять и объяснить, на что способен продукт. — Минимализм: нет ничего лишнего в содержании или внешнем виде продукта. — Обучаемость: быстро и легко научиться пользоваться продуктом. — Запоминаемость: как только вы научились что-то делать, вы не забываете об этом. — Обнаруживаемость: информацию и возможности продукта можно обнаружить путем исследования пользовательского интерфейса.- Работоспособность: опытный пользователь может очень быстро выполнять стандартные действия. — Интерактивность: продукт имеет простые для понимания состояния и возможности взаимодействия с приложением (через графический интерфейс или API). — Контроль: пользователь должен чувствовать контроль над работой программного обеспечения. — Ясность: все ли указано четко и подробно, языком, который можно понять, не оставляя места для сомнений? — Ошибки: есть информативные сообщения об ошибках, ошибки трудно сделать и легко исправить после их исправления.- Последовательность: поведение одинаково во всем продукте, и есть единый внешний вид. — Возможность адаптации: для гибкости можно указать настройки и поведение по умолчанию. — Доступность: продукт можно использовать как можно большему количеству людей и соответствует применимым стандартам доступности. — Документация: есть справка, которая помогает и соответствует функциональности.

Харизма. Есть ли в продукте «это»?
— Уникальность: товар отличим и в нем есть то, чего нет ни у кого.- Удовлетворенность: как вы себя чувствуете после использования продукта? — Профессионализм: обладает ли продукт должным профессионализмом и соответствует ли его назначению? — Привлекательность: все ли аспекты продукта привлекательны для глаз и других органов чувств? — Любопытство: заинтересуются ли пользователи и попробуют ли они, что они могут делать с продуктом? — Вовлеченность: зацепляются ли пользователи, получают ли они удовольствие, находятся в потоке и полностью вовлечены при использовании продукта? — Шумиха: следует ли использовать в продукте новейшие и лучшие технологии / идеи? — Ожидание: продукт превосходит ожидания и удовлетворяет потребности, о которых вы не знали.- Отношение: правильное ли отношение к продукту и информации в нем и правильное ли обращение к нему с правильным языком и стилем? — Прямолинейность: впечатляют (первые) впечатления? — История: есть ли интересные истории о создании продукта, его создании …

Продолжить чтение

Присоединяйтесь к StudyMode, чтобы прочитать полный документ

ISO — ISO / IEC 25010: 2011 — Разработка систем и программного обеспечения — Требования и оценка качества систем и программного обеспечения (SQuaRE) — Модели качества систем и программного обеспечения

ISO / IEC 25010: 2011 определяет:

1. Модель качества использования, состоящая из пяти характеристик (некоторые из которых далее подразделяются на подхарактеристики), которые относятся к результату взаимодействия, когда продукт используется в конкретном контексте использования.Эта системная модель применима ко всей системе человек-компьютер, включая как используемые компьютерные системы, так и используемые программные продукты.
2. Модель качества продукции, состоящая из восьми характеристик (которые далее подразделяются на подхарактеристики), которые относятся к статическим свойствам программного обеспечения и динамическим свойствам компьютерной системы. Модель применима как к компьютерным системам, так и к программным продуктам.

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

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

ISO / IEC 25012 содержит модель качества данных, которая дополняет эту модель.

Объем моделей не включает чисто функциональные свойства, но включает функциональную пригодность.

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

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

Характеристики качества архитектуры программного обеспечения1

Франциска Лосавио и Ледис Чиринос , Центральный университет Венесуэлы, Каракас, Венесуэла Николь Леви и Амар Рамдан-Шериф , Университет Версаль, Сен-Кантен, Франция ССЫЛКА СТАТЬЯ Версия PDF Аннотация По общему мнению, вопросы качества следует рассматривать на самых ранних этапах процесса разработки программного обеспечения, чтобы снизить риски и облегчить достижение всей системы программного обеспечения.Более того, архитектура системы управляет всем процессом разработки. Выполнение нефункциональных требований к качеству архитектурой-кандидатом имеет решающее значение для выбора удобной архитектуры, на которой будет построена вся система. Этот вопрос очень важен при создании надежных эволюционных приложений. Методы разработки программного обеспечения не дают подробностей об этом важном этапе. Эта работа связана со спецификацией требований к качеству архитектуры программного обеспечения, представляя методику, основанную на стандарте ISO 9126-1.Качественные характеристики модели качества ISO преобразуются в атрибуты, которые можно измерить, чтобы обогатить информацию об архитектуре. Наша методика используется, чтобы помочь выбрать подходящую архитектуру среди набора кандидатов, путем сравнения значений соответствующих атрибутов качества. Практический пример иллюстрирует применение этого метода в системе мониторинга. Наш подход облегчает выбор правильных решений в процессе анализа архитектуры. Его можно легко интегрировать в общий процесс разработки программного обеспечения или в конкретные методы архитектурного проектирования. 1 ВВЕДЕНИЕ Требования к качеству, зафиксированные как нефункциональные требования на ранних этапах разработки программного обеспечения, сильно влияют на архитектуру программной системы. Однако также основные абстракции системы, которые являются функциональными требованиями, также играют важную роль в определении исходной архитектуры. С другой стороны, требования к качеству должны быть «сбалансированы» в процессе проектирования [Kazman et al. 2000]. Только недавно важность точного проектирования архитектуры программного обеспечения, не ограничиваясь графическими обозначениями прямоугольников и линий, значительно возросла для построения надежных эволюционных систем [Bachmann et al.1996], [Bosch 2000], [Krutchen 2000]. Современные приложения, включающие распространение, адаптируемость, функциональную совместимость, возможность многократного использования компонентов и проблемы реального времени, требуют раннего определения архитектуры системы для выполнения требований качества, таких как ремонтопригодность и надежность. Они имеют решающее значение для достижения общей функциональной цели строящейся программной системы. В частности, новые информационные системы, использующие Интернет-сервисы, такие как приложения электронной коммерции на базе Интернета, очень быстро разрабатываются для маркетинговых нужд, без особого внимания к методам разработки программного обеспечения.Тем более, что качество такой продукции не обсуждается. Однако, когда HTML-страница отображается в браузере, мы сразу узнаем, находимся ли мы «хорошее» или «плохое» веб-приложение. В этой быстрой оценке участвуют такие факторы, как удобство использования, надежность (надежность) или эффективность (время или ресурсы). На самом деле проблема в том, что у разработчиков программного обеспечения нет четкого описания качественных характеристик веб-приложения, поскольку при разработке этих систем, как мы уже указывали, часто игнорируются парадигмы программной инженерии.Например, даже когда разделение между семантикой данных приложения и представлением является принятой парадигмой, HTML обычно используется независимо от этой проблемы, и только недавно был принят XML. Тогда возникает интересная проблема — определение требований к качеству. Они могут появляться неявно во время спецификации функциональных требований, как, например, в текстовом описании варианта использования или в сценарии, но в стандартных объектно-ориентированных методах нет явных указаний или явных элементов моделирования о том, как их фиксировать или определять.Более того, мы считаем, что проектирование архитектуры программного обеспечения следует рассматривать не как самостоятельную деятельность, а как шаг вперед в процессе разработки и эволюции программных продуктов. Архитектуры следует рассматривать как главную задачу (Krutchen, 2000), чтобы создать более четко повторно используемые структуры, чтобы гарантировать в определенной степени общее качество конечных программных продуктов. Основная цель этой работы — предложить методику, основанную на ISO 9126-1 [ISO / IEC 1998], для определения соответствующих характеристик качества, уточненных до уровня атрибутов или измеримых элементов, участвующих в процессе архитектурного проектирования.Спецификация и оценка этих атрибутов в качестве этапов архитектурного проектирования являются основой процесса архитектурного преобразования, позволяя постепенно адаптировать исходную архитектуру. Этот кандидат, часто выбираемый в соответствии с некоторыми ключевыми функциональными требованиями к системе, адаптируется или трансформируется в процессе проектирования для достижения установленных целей в области качества, которые представляют собой значения, которых система должна достичь при выполнении требований к качеству. В этом процессе требования к качеству часто трансформируются в неявные функциональные требования для конечной системы [Bosch 2000], выражая их, например, как введение дополнительных механизмов.Однако в широко используемых методах анализа и проектирования программного обеспечения спецификация и оценка атрибутов качества выполняются только на основе опыта разработчика. ATAM (метод анализа компромиссов на основе атрибутов) [Kazman et al. 2000] имеет некоторые общие черты с нашим подходом. Он использует один уровень уточнения характеристик (атрибутов) качества, называемый деревом полезности (качества системы), для приоритезации сценариев на основе конкретной характеристики качества. Информация об архитектуре и атрибуте фиксируется в структуре ABAS (Attribute-Based Architectural Style) [Klein and Kazman 1999].Однако неясно, как добраться до дерева полезности, какое представление качества оно выражает и почему только одноуровневое уточнение, а определения атрибутов качества не являются стандартами. Дерево служебных программ используется для определения приоритетов сценариев для определения уязвимых точек, из которых можно получить набор «тестовых» сценариев для архитектуры. Меры для атрибутов даны в терминах стимулов, параметров и ответов. Наш подход рассматривает спецификацию требований к качеству с использованием модели качества в соответствии со стандартом ISO 9126-1.Эта иерархическая модель, которая структурно похожа на дерево качества ATAM, адаптирована к архитектуре программного обеспечения. Модель качества ISO в настоящее время является стандартом в индустрии программного обеспечения и определяется на высоком уровне абстракции с точки зрения внешнего / внутреннего и качественного использования характеристик качества. Характеристики качества (атрибуты для ATAM) точно определены в стандарте, а меры для атрибутов являются довольно общими и могут быть дополнительно уточнены для конкретного приложения.Качество среды, в которой работает программное обеспечение, определяется моделью качества использования, которая представляет собой взгляд пользователя на качество в конкретном контексте использования. В этой работе нас интересует только модель внешнего / внутреннего качества, представляющая взгляды пользователя и разработчика соответственно. Для достижения используемого качества система должна достигать внешних и внутренних целей качества. Характеристики качества преобразуются в субхарактеристики, проявляющиеся извне, когда программное обеспечение используется как часть компьютерной системы, и они также являются результатом оценки внутренних атрибутов программного обеспечения или измеримых свойств объекта, появляющихся в процессе разработки программного обеспечения.В нашем случае мы должны «передать» или «перевести» эти свойства в программную архитектуру, которая является промежуточным программным продуктом. Значения, полученные для атрибутов в процессе разработки, можно использовать для проверки внутренних целей качества, способствуя валидации внешних целей качества, необходимых для окончательной программной системы [SO / IEC 1998]. Наличие точной спецификации атрибутов качества добавляет больше информации в архитектурную спецификацию, облегчая процесс анализа для выбора архитектуры для решения конкретной проектной проблемы. Помимо введения и заключения, основными разделами статьи являются следующие: — Дается описание общей модели качества, основанной на ISO 9126-1, для определения качественных характеристик архитектуры программного обеспечения. — Практический пример, в котором полученная общая модель качества используется для выбора двух различных архитектур для системы мягкого мониторинга в реальном времени с использованием средств Интернета. 2 АДАПТАЦИЯ МОДЕЛИ КАЧЕСТВА ISO 9126-1 К АРХИТЕКТУРЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ISO 9126-1 Модель качества Согласно ISO 9126-1 [ISO / IEC, 1998], качество определяется как набор функций и характеристик продукта или услуги, которые влияют на их способность удовлетворять заявленные или подразумеваемые потребности.Можно рассматривать различные точки зрения качества: — взгляд пользователя как качество конечного продукта; — взгляд разработчика, как качество промежуточных продуктов, созданных различными заинтересованными сторонами в процессе разработки; — вид менеджера конечного пользователя, как маркетинговые требования. Общее качество продукта может быть выражено комбинацией различных точек зрения. В нашем контексте будут использоваться представления пользователя и разработчика (архитектора). Работа МакКолла [McCall et al. 1977] различает два уровня качественных характеристик: факторы и критерии.Первое невозможно измерить напрямую, а второе можно измерить субъективно. Он вдохновил модель ISO 9126-1. Исходя из этого, ISO 9126-1 еще больше упрощает модель МакКолла, превращая ее в модель качества ISO 9126-1, которая в настоящее время является общепринятой в современных спецификациях качества продукции. Он предлагает набор из шести независимых высокоуровневых характеристик качества , которые определяются как набор атрибутов программного продукта, с помощью которых описывается и оценивается его качество. На практике некоторое влияние может проявиться среди характеристик, однако в данной работе они будут считаться независимыми для упрощения нашего представления.Характеристики качества используются в качестве целей для валидации (внешнее качество) и верификации (внутреннее качество) на различных этапах разработки. Они уточняются (см. Рисунок 1) на подхарактеристики, пока не будут получены атрибуты или измеримые свойства . В этом контексте метрика или показатель определяется как метод измерения, а измерение означает использование метрики или меры для присвоения значения. На рисунке 1 показаны эти отношения: Рис.1. Отношения между элементами модели качества Чтобы отслеживать и контролировать качество программного обеспечения в процессе разработки, внешние требования к качеству переводятся или переводятся в требования к промежуточным продуктам, полученным в результате деятельности по разработке. Перевод и выбор атрибутов — нетривиальная деятельность, зависящая от личного опыта заинтересованных сторон, если только организация не предоставляет инфраструктуру для сбора и анализа предыдущего опыта по завершенным проектам.Определение основных характеристик качества стандарта ISO 9126-1 для измерения качества программного обеспечения показано в таблице 1. Модель должна быть адаптирована или настроена для конкретного приложения или области продукта. В этом смысле для конкретного программного продукта у нас может быть подмножество из шести характеристик. В стандарте ISO 9126-1 не дается никаких указаний по настройке модели качества. Характеристики Описание Функциональность Способность программного продукта предоставлять функции, которые соответствуют заявленным и подразумеваемым потребностям, когда программное обеспечение используется в определенных условиях (что программное обеспечение делает для удовлетворения потребностей) Надежность Способность программного продукта поддерживать уровень производительности при указанных условиях в течение указанного периода времени Удобство использования Способность программного продукта быть понятым, изученным, используемым и привлекательным для пользователя при использовании в определенных условиях (усилия, необходимые для использования) КПД Способность программного продукта обеспечивать надлежащую производительность относительно количества используемых ресурсов при установленных условиях Ремонтопригодность Возможность модификации программного продукта.Модификации могут включать исправления, улучшения или адаптации программного обеспечения к изменениям в среде, а также в требованиях и функциональных спецификациях (усилия, которые необходимо изменить) Портативность Возможность переноса программного продукта из одной среды в другую. Среда может включать организационную, аппаратную или программную среду Таблица 1.Характеристики ISO 9126-1 Модель качества Подхарактеристики показаны на рисунке 2. Обратите внимание, что соответствие означает соблюдение стандартов, соглашений или правил, и это представлено в [ISO / IEC 1998] в качестве подхарактеристики всех характеристик. Мы будем рассматривать его здесь только для функциональности, чтобы сократить эту презентацию. Обратите внимание, что наличие подхарактеристики соответствия означает, что остальные свойства в пределах характеристики считаются соответствующими выбранному стандарту. Рис.2: Подхарактеристики модели качества ISO 9126-1 Настройка стандартной модели качества для архитектуры программного обеспечения Чтобы настроить модель качества ISO, мы должны знать свойства, которые ожидаются от архитектуры или общей структуры (базовой линии), на которой должна быть построена программная система, считая ее промежуточным продуктом процесса разработки программного обеспечения.Следовательно, конкретная архитектура, выраженная на высоком уровне компонентами, соединяющими их соединителями и конфигурацией или топологией, должна «удовлетворять» шести характеристикам ISO 9126 или их подмножеству. Каждая характеристика будет связана с оцениваемыми атрибутами. Эти атрибуты будут глобально связаны с архитектурой и / или с каждым компонентом и соединителем. Для количественной оценки атрибутов качества будут использоваться меры. Сначала они определяются как символические выражения, а затем могут быть определены более точно с помощью формального языка [Marcano et al.2000]. Во время пошагового определения архитектуры можно оценить, улучшают ли усовершенствования архитектуры атрибуты качества. Однако в данной работе этот вопрос обсуждаться не будет. Для конечного продукта существуют целевые значения качества, которые должны быть достигнуты или превышены для каждого атрибута. Когда значения достигаются или превышаются, считается, что архитектура удовлетворяет требуемым характеристикам качества. Целевые значения устанавливаются в определении требований.Далее мы объясним, как требования к качеству уточняются в соответствующие подхарактеристики и атрибуты и как они адаптируются к архитектурам программного обеспечения, давая соответствующие метрики для каждого атрибута. Обратите внимание, что характеристики и подхарактеристики считаются независимыми. Характеристика Функциональность Дополнительная характеристика Пригодность : наличие соответствующих функций для требуемых задач. Он включает в себя два аспекта: Присутствие: задачи указываются, например, посредством вариантов использования. Для каждой задачи должен существовать функционал для ее выполнения. Соответствие: спецификация задачи уточнена правильно, например, должны быть выполнены диаграммы последовательности (см. Рисунок 3). На архитектурном уровне: Определены функциональные возможности системы.В этом случае подхарактеристика уточняется до атрибута, значение которого — да (1) или нет (0). Обратите внимание, что есть атрибуты, значения которых принадлежат интервалу целых чисел [n..m], например [0..1], что означает отсутствие или присутствие. Показатель — это шкала для получения рейтинговых уровней. Уточняются диаграммы последовательности, полученные из функциональных требований. В случае наличия спецификации архитектуры указанные функциональные возможности раскладываются на функции, связанные с компонентами, состав которых будет соответствовать функциональным требованиям системы. Рис. 3: Перевод системных требований в архитектуру программного обеспечения Точность подхарактеристики: для обеспечения правильных или согласованных результатов или эффектов с необходимой степенью точности. Его можно измерить с помощью атрибута в исходном коде. Следовательно, он делегируется компонентам, в которых будут определены функции, которые будут вычислять значения. На архитектурном уровне: Идентификация компонентов с функциями, отвечающими за вычисления (функциональные компоненты). Атрибут вычисляется по следующей метрике: Подхарактеристика Взаимодействие: способность взаимодействовать с одной или несколькими указанными системами. Обратите внимание, что он используется вместо совместимости, чтобы избежать двусмысленности с возможностью замены. На архитектурном уровне: Обозначение разъемов для связи с внешними указанными системами.Например, требование совместимости с CORBA подразумевает наличие компонентов CORBA. Он преобразован в атрибут, значение которого — да или нет, в зависимости от наличия или отсутствия соответствующих компонентов промежуточного программного обеспечения. Дополнительная характеристика Безопасность: способность предотвращать несанкционированный доступ к программам или данным. На архитектурном уровне: Это означает наличие механизма или устройства (программного или аппаратного) для явного выполнения этой задачи.Это может быть компонент (например, сервис, предоставляемый промежуточным программным обеспечением) или функциональность, интегрированная в компонент. Он уточняется в атрибуте, значение которого — да или нет, в зависимости от наличия или отсутствия механизма или устройства. Подхарактеристика Соответствие: для соблюдения стандартов, соглашений или правил. Это связано с процессом разработки. На архитектурном уровне: Это очень общее свойство, которое не может быть напрямую применено к архитектурному проекту. Оно преобразовано в атрибут, значение которого — да или нет, в зависимости от применения требуемого стандарта. Соответствие архитектурному стилю можно определить как удовлетворение связанных с ним архитектурных ограничений. Характеристика надежности Подхарактерная зрелость: способность программного продукта избегать сбоев в результате сбоев в программном обеспечении. Он преобразован в атрибут Среднее время до отказа (MTTF), измеренный в исходном коде. На архитектурном уровне: Атрибут вычисляется по следующей метрике: Обратите внимание, что атрибут зрелости компонентов COTS известен или должен быть известен. Подхарактеристика Отказоустойчивость: способность поддерживать заданный уровень производительности в случае ошибки программного обеспечения или нарушения указанного интерфейса. На архитектурном уровне: Означает наличие механизма или программного устройства. Это может быть компонент или интегрированный в компонент, например обработка исключений или резервирование. Он преобразован в атрибут, значение которого — да или нет, в зависимости от наличия или отсутствия механизма или устройства. Его можно преобразовать в атрибут, значение которого связано с механизмом или устройством. Подхарактеристика Восстанавливаемость: Выражается: 1. Возможность восстановить уровень производительности. 2. Возможность восстановить данные. 3. Время и усилия, необходимые для этого. На архитектурном уровне: Это означает наличие механизма или программного устройства, которое может быть компонентом или интегрировано в компонент, для восстановления уровня производительности или восстановления данных, например, избыточности. Если механизм существует, восстанавливаемость уточняется в атрибуте производительность , вычисленном с помощью показателей, включающих время и усилия.Его необходимо рассчитать для каждого компонента, удерживающего механизм. Примечание: доступность зависит от трех вышеуказанных подхарактеристик надежности и используется в [Marcano et al. 2000]. Даже если это свойство прямо не указано в ISO 9126-1, оно определяется как способность программного продукта находиться в состоянии для выполнения требуемой функции в заданный период времени. Его следует учитывать из-за его важности в широко используемых распределенных приложениях и приложениях реального времени.Это как атрибут отказоустойчивости, измеряющий время переключения. Характеристика Удобство использования Подхарактеристика Понятность: возможность программного продукта, позволяющая пользователю понять, подходит ли программное обеспечение и как его можно использовать для конкретных задач и условий использования. Дополнительная характеристика Обучаемость: способность программного продукта позволять пользователю изучать свое приложение Дополнительная характеристика Оперативность: способность программного продукта позволять пользователю управлять им. Эти подхарактеристики могут быть преобразованы в атрибуты, переведенные в компоненты графического интерфейса. На архитектурном уровне они не зависят от архитектуры, которая прозрачна для пользователей, поэтому здесь они не рассматриваются. Характеристика эффективности Подхарактеристика Временное поведение (производительность): способность программного продукта обеспечивать соответствующее время отклика, время обработки и пропускную способность при выполнении своей функции в указанных условиях.Это атрибут, который можно измерить для каждой функциональности системы. На архитектурном уровне: Он измеряется для каждой функции и каждого пользователя функции с помощью атрибутов, вычисляемых с помощью следующей метрики: Влияет поток данных на функциональность. Производительность зависит от: стимул / событие / функциональность; путь, используемый в архитектуре для ответа на стимул для данной функциональности; каждый пройденный компонент, содержащий выполненную функциональность. Подхарактеристика использования ресурсов: количество и тип используемых ресурсов, а также продолжительность такого использования при выполнении своей функции. Он включает атрибут сложности , который вычисляется с помощью метрики, включающей размер ( пространство, для используемых ресурсов и время, , потраченное на использование ресурсов). На архитектурном уровне: Атрибуты могут быть определены и измерены для каждой функциональности, и они являются характеристикой стиля.Пространство и время связаны с компонентами. Значения связаны с каждым компонентом и / или соединителем для каждой функции. Поддерживаемость характеристик Подхарактеристика Анализируемость: способность программного продукта диагностировать недостатки или причины сбоев в программном обеспечении или определять части, которые необходимо модифицировать. Подхарактеристика Изменяемость: способность программного продукта обеспечивать возможность реализации указанной модификации. Подхарактеристика Стабильность: способность программного продукта избегать неожиданных эффектов от модификаций программного обеспечения (риск непредвиденных последствий модификаций) Подхарактеристика Тестируемость: возможности программного продукта подлежит проверке. Они уточняются до атрибута сложность исходного кода, вычисляемого по метрикам, включающим, в частности, размер. На уровне архитектуры: Подхарактеристика Связь — это глобальное свойство архитектуры, относящееся к обменам между компонентами; атрибуты могут быть измерены для каждого компонента с использованием показателей разветвления и разветвления.Это системный атрибут. Подхарактеристика Модульность выражает топологию архитектуры как количество компонентов в зависимости от одного компонента. Это атрибут, вычисляемый для каждого компонента по метрикам, включающим размер. Характеристика Переносимость Подхарактеристика Адаптивность: возможность адаптации программного продукта к различным заданным средам с использованием только его собственных функций. На уровне архитектуры: Наличие механизмов адаптации, например универсальности или параметризации Эта подхарактеристика уточняется до атрибута, значение которого — да или нет, в зависимости от наличия или отсутствия механизм Дополнительная характеристика Возможность установки: возможность установки программного продукта в указанной среде. На архитектурном уровне: Наличие механизма установки Эта подхарактеристика уточняется до атрибута, значение которого — да или нет, в зависимости от наличия или отсутствия механизма Субхарактеристика Сосуществование: способность программного продукта сосуществовать с другим независимым программным обеспечением в общей среде, совместно используя общие ресурсы На архитектурном уровне: Наличие механизма, облегчающего сосуществование Эта подхарактеристика уточняется до атрибута, значение которого — да или нет, в зависимости от наличия или отсутствия механизма Подхарактеристика Заменяемость: возможности программного продукта для использования вместо другого указанного программного продукта для той же цели в той же среде. Он предполагает адаптируемость и возможность установки. На уровне архитектуры: Атрибут выражается списком (именем) заменяемых компонентов для каждого компонента 3 ПРИМЕНЕНИЕ ИНДИВИДУАЛЬНОЙ МОДЕЛИ КАЧЕСТВА К ПРИМЕРУ Модель качества, определенная в предыдущем разделе, будет использоваться для сравнения двух архитектур на основе двух разных архитектурных паттернов: издатель / подписчик с моделью push [Buschman 1996] и репозиторий [Shaw and Garlan 1996].Обратите внимание, что издатель / подписчик также известен как субъект / наблюдатель [Gamma et al. 1995]. Архитектуры используются для реализации системы мониторинга фондовой биржи. Ниже кратко представлены системные требования. Более подробная информация об этом приложении приведена в [Ordaz Jr. 2000]. Требования к системе мониторинга фондовой биржи Основная цель системы мониторинга в реальном времени — фиксировать, анализировать и транслировать события (данные) в реальном времени.Это soft система реального времени, в которой некоторые события могут не соответствовать установленному сроку, не влияя на поведение всей системы. Система представляет собой поставщик данных в реальном времени для мониторинга в режиме реального времени малых и средних фондовых бирж для брокеров и независимых инвесторов. Антенна (сервер подачи, ), внешняя по отношению к системе, предоставляет данные ( канал ) на сервер данных. Канал содержит релевантную информацию о биржевой операции. Корма должны быть надежными и доступными.Клиенты ( брокера, ), распределенные в разных географических точках, подписываются на сервер данных. Когда происходит изменение в канале, на который подписан клиент, он транслируется ему сервером данных в соответствии со строгой временной задержкой. Время задержки будет зависеть от сетевой структуры, используемой для отправки информации клиентам. Тип предлагаемой услуги зависит от этой задержки. Требования к системе: высокая безопасность, доступность, неоднородность платформ, распределение клиентов, достоверная информация со строгими сроками.Известно, что эти характеристики не являются независимыми, и для определения приоритетов должен быть компромисс. Для системы требуется доступ в Интернет через коммерческие браузеры. Архитектура, предлагаемая для системы мониторинга Предлагаемые архитектуры, основанные на двух различных архитектурных шаблонах, издатель / подписчик (модель push) и репозиторий, показаны на рисунках 4 и 5 соответственно. Рис.4. Архитектура, основанная на шаблоне издатель / подписчик . Издатель / подписчик запоминает клиентские подписки и фактические значения в БД клиентских подписок и БД соответственно. Рис. 5: Архитектура на основе шаблона репозитория Репозиторий запоминает фактические значения в БД и запросы клиентов в БД счетов-фактур клиентов для целей выставления счетов. Сравнение архитектур Характеристики Дополнительные характеристики Издатель / подписчик Репозиторий Комментарии и результаты Функциональность Пригодность да да Точность = = Никаких специальных вычислений не требуется Взаимодействие да да Общение через браузеры Безопасность Механизм подписки Механизм под каждый запрос клиента Издатель / подписчик лучше Надежность Срок погашения Срок погашения (прием) + Срок погашения (DB) + Срок погашения (Издатель) + Срок погашения (подписчик) + Срок погашения (подписка DB) Срок погашения (прием) + Срок погашения (БД) + Срок погашения (сервер данных) + Срок погашения (БД счетов-фактур клиента) Репозиторий лучше Отказоустойчивость (наличие) = = Зависит от дополнительных механизмов Восстанавливаемость = = Зависит от дополнительных механизмов Удобство использования = = Зависит от графического интерфейса браузера КПД Поведение во времени (время, затраченное с момента получения данных до доставки) время (прием) + время (сохранение в БД) + время (отправка изменений) + время (издатель) + время (отправка измененных значений) время (запрос клиента) + время (клиентская база данных счетов) + время (сервер данных) + время (запрос) + время (БД) + время (ответный сервер данных) + время (ответ клиенту) Издатель / подписчик лучше Использование ресурсов (время) Браузер отображает всегда Браузер отображает по запросу Репозиторий лучше Использование ресурсов (площадь) Размер (подписка БД) Размер (БД накладных) Зависит от внешних факторов, таких как объем клиентских запросов Ремонтопригодность = = Зависит от кода в модулях Портативность = = Зависит от дополнительных механизмов Таблица 2.Сравнение издателя / подписчика и репозитория по атрибутам качества Результаты, представленные в таблице 2, показывают, что издатель / подписчик лучше репозитория в отношении безопасности и эффективности во времени. Однако репозиторий лучше по зрелости (в архитектуре меньше компонентов) и по эффективности во времени (браузер отображает только по запросу). Следовательно, только своевременное использование ресурсов будет способствовать репозиторию. Теперь анализ состоит в приоритезации характеристик, т.е.е. решить, какие из них наиболее важны для программной системы. Этот шаг соответствует адаптации модели качества ISO 9126-1 к проблемной области [Losavio et al. 2002]. Согласно требованиям к системе мониторинга фондовых бирж, безопасность и эффективность во времени более важны, чем надежность (зрелость) и эффективность использования ресурсов (пространства и времени), в соответствии с исходными нефункциональными требованиями к проблемной области. Следовательно, архитектура, основанная на архитектурном шаблоне издатель / подписчик, выбирается в качестве первоначальной архитектуры кандидата.Обратите внимание, что внешние характеристики, такие как объем клиентских запросов, в основном связанные с поведением пользователя, влияющим на компоненты и / или соединители, не могут быть учтены в нашей оценке и приняты во внимание для сравнения. После того, как этот широкий и быстрый выбор будет выполнен на основе анализа таблицы, окончательное решение может быть дополнительно подтверждено выполнением и оценкой сценариев, связанных только с характеристиками качества, относящимися к приложению. В этом случае профильный подход, предложенный [Bosch 2000], или подход сценариев, предложенный [Kazman et al.2000]. Краткое описание техники Обобщая наш подход, действия, выполняемые для выполнения процесса оценки и сравнения архитектур на основе спецификации характеристик качества, перечислены в таблице 3 следующим образом: Деятельность: Проанализируйте основные функциональные и нефункциональные требования к системе, чтобы установить требования к качеству и цели качества. Используйте настроенную модель качества ISO 9126-1, определенную в разделе 2.2 для архитектуры как каркаса. Некоторые из показателей могут быть дополнительно указаны в соответствии с конкретными компонентами и / или соединителями. Представьте исходные архитектуры-кандидаты Составьте таблицу сравнения для архитектур-кандидатов Назначьте приоритет качественным характеристикам с учетом требований к качеству системы и качественные цели. Адаптация ISO 9126-1 к проблемной области может быть использована для иерархической организации характеристик. Проанализируйте результаты, приведенные в таблице, в соответствии с заданными приоритетами, полученными на этапе 5 Выберите исходную архитектуру среди оцениваемых кандидатов на основе предыдущего анализа Если требуется более точный анализ, Можно использовать сценарии или подходы на основе профилей, учитывая только качественные характеристики, относящиеся к проблемной области, полученные на этапе 5. Таблица 3.Метод сравнения архитектур, основанный на спецификации атрибутов качества ISO-9126-1 4 ЗАКЛЮЧЕНИЕ Подход к определению требований к качеству программной системы был представлен как повторяемый метод. Стандарт ISO / IEC 9126-1 был использован для определения модели качества для архитектуры программного обеспечения. Эта структура была применена к простому тематическому исследованию для сравнения двух архитектур и выбора наиболее подходящей для задачи на основе начальных нефункциональных требований.Наконец, были суммированы действия, связанные с применением техники. Спецификация атрибутов качества с использованием модели качества, основанной на международных стандартах, предлагает глобальный и широкий взгляд на характеристики качества и атрибуты для архитектуры программного обеспечения, формирующий точки зрения пользователя и архитектора. Мы считаем, что наш подход аналогичен методике анализа ATAM, однако отличается от него несколькими важными аспектами: определение характеристик качества, соответствующих промышленному стандарту, и более общее определение мер для атрибутов, которые могут быть дополнительно уточнены. , в зависимости от конкретного приложения.Более того, созданная сравнительная таблица может использоваться для вывода сценариев в смысле ATAM. Однако оба подхода можно легко интегрировать с множеством преимуществ. Наш метод может быть легко интегрирован в общие структуры процесса разработки, такие как Rational Unified Process [Krutchen 2000], или в конкретные методы архитектурного проектирования, такие как метод J. Bosch [Bosch 2000] или метод архитектурно-ориентированного проектирования (ABD). [Bachmann et al. 1996]. Мы считаем, что эта работа — шаг вперед к спецификации требований к качеству, систематизации и совершенствованию процесса архитектурного проектирования, со встроенными проблемами качества.Другие вопросы, требующие исследования, включают интеграцию этой техники в Unified Process и формальную спецификацию архитектурных стилей и паттернов [Marcano et al. 2000], [Meyer and Souquières 2000] с учетом атрибутов качества [Losavio and Levy 2001]. Сноски 1 Эта работа была разработана в результате проекта Европейского сообщества INCO SQUAD EP 962019, Consejo de Desarrollo Científico y Humanístico (CDCH) Центрального университета Венесуэлы, проект ARCAS 03.13.4584.00 и проект РНТЛ Лутина ССЫЛКИ [Bachm00] Бахманн Ф., Басс Л., Частек Г., Донохо П., Перуцци Ф .: Метод архитектурного проектирования . CMU / SEI-2000-TR-001, ESC-TR-2000-001, 2000 [Bosch00] Bosch J .: «Разработка и использование архитектуры программного обеспечения » , ACM Press , Харлоу, Англия, 2000. [Busch96] Бушман Ф., Менье Р., Ронерт Х., Соммерлад П., Сталь, М .: Шаблонно-ориентированная архитектура программного обеспечения. Система паттернов. , John Wiley & Sons Inc., Нью-Йорк, 1996 [Gamma95] Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Шаблоны проектирования — элемент объектно-ориентированного программного обеспечения многократного использования . Эддисон Уэсли, Нью-Йорк, 1995. [ISO / IEC98] ISO / IEC: FCD 9126-1.2: Информационные технологии — Качество программного продукта. Часть 1: Модель качества, 1998 г. [Klein99] Кляйн М., Казман Р .: Архитектурные стили на основе атрибутов , CMU / SEI-99-TR-022, ESC-TR-99-022, 1999. [Krutch00] Крутчен П .: Рациональный единый процесс. Введение , 2-е. Edition, Addison Wesley, Reading, Massachussets, 2000. [Kazm00] Казман Р., Кляйн М., Клементс П .: ATAM: метод оценки архитектуры . CMU / SEI-2000-TR-004, ESC-TR-2000-004, 2000. [McCall77] МакКолл Дж.А., Ричардс П.К., Уолтерс Г.Ф .: Факторы качества программного обеспечения . Vol. 1, 2, 3, AD / A-049-015 / 055. Спрингфилд, 1977. [Losav01] Лосавио Ф., Леви Н .: «Спецификация архитектурных стилей на основе атрибутов » . Proceedings CD-Rom, http://www.umag.cl/ec of XI Encuentro Chileno de Computación, Jornadas Chilenas de Computación 2001 , Punta Arenas, Chile, 2001 [Losavi02] Лосавио Ф., Киринос Л., Перес М .: Атрибутные методы оценки архитектурных стилей.Пример использования интерактивных систем . Acta Cientísica Venezolana, Vol. 53, 2, 2002. [Marca00] Маркано Р., Леви Н., Лосавио Ф .: «Спецификация и специализация паттернов в UML и т. Д.». Proceedings of LMO’2000 — Langages et Modèles à Objets , Ed. Hermès, Монреаль (Калифорния), 245-260, 2000. [Meyer99] Мейер Э. и Сукьер Дж.: «Системный подход к преобразованию диаграмм OMT в спецификацию B » . Труды FM’99: Всемирный конгресс по формальным методам разработки вычислительных систем .Тулуза (Франция), сентябрь 1999 г. [Ordaz00] Ordaz Jr. O.: Aplicaciones Tempo Real en Internet: Arquitecturas, Lenguajes y un Caso de Estudio , Лицензионная диссертация, Центральный университет Венесуэлы, Каракас, 2000. [Shaw96] Шоу М., Гарлан Д.: Архитектура программного обеспечения — Перспектива новой дисциплины , Prentice Hall, Upper Saddle River, Нью-Джерси, 1996. Об авторах Франциска Лосавио получила докторскую степень во Франции, Университет Париж-Юг, Орсе.Она возглавляет исследовательскую лабораторию программных технологий (LaTecS) исследовательского центра программной инженерии и систем (ISYS) факультета естественных наук Центрального университета Венесуэлы, Каракас, где она работает в аспирантуре по программной инженерии. Основные темы ее исследований — архитектура программного обеспечения и качество программного обеспечения. Эл. Почта: [email protected] Ледис Чиринос получила степень магистра наук. Степень в области компьютерных наук в Центральном университете Венесуэлы в 1999 году, где она продолжила обучение по программе PhD.Она работает в лаборатории LaTecS исследовательского центра ISYS, факультет Scence, Центральный университет Венесуэлы. Ее основные интересы — качество программного обеспечения, измерение программного обеспечения и архитектура программного обеспечения. Эл. Почта: [email protected] Николь Леви — профессор Версальского университета, Сен-Кантен-ан-Ивелин, Франция. Она имеет докторскую степень Университета Нэнси.Она является директором ISTY и научным сотрудником лаборатории PRISM в Версале, где она координирует исследовательскую группу SFAL (Spécification Formelle et Architecture Logicielle). Основные научные интересы — формальные и полуформальные методы разработки, формализация стилей и архитектурных паттернов. Электронная почта: [email protected] Амар Рамдане-Шериф получил докторскую степень.Получил степень доктора наук в Парижском университете Пьера и Мари в 1998 году в области нейронных сетей и оптимизации внутреннего управления для робототехнических приложений. С 2000 года он был доцентом лаборатории PRISM Версальского университета, Сен-Кантен-ан-Ивелин, Франция. Его основные текущие исследовательские интересы включают: архитектура программного обеспечения и формальная спецификация, динамическая архитектура, атрибуты архитектурного качества, архитектурные стили и шаблоны проектирования, всеобъемлющие вычисления и коммуникации, архитектура надежных систем, электронная почта: [email protected] Цитируйте эту статью следующим образом: Francisca Losavio et al: «Характеристики качества для архитектуры программного обеспечения», в Journal of Object Technology , vol. 2, вып. 2, март-апрель 2003 г., стр. 133-150. http://www.jot.fm/issues/issue_2003_03/article2

.

No related posts.