Please enable JavaScript.

Coggle requires JavaScript to display documents.

Sweebok классификация требований к ПО - Coggle Diagram

- - - - Функциональные требования
        Определяет то, как устроен сам продукт
        и его функционал
      - Пользовательские требования
        Описывает цели и задачи,
        которые должны достигаться
        пользователями приложения
        (Кто и как взаимодействует с продуктом)
      - Бизнес-требования
        Определяет цели заказчика.
        Для чего ему продукт,
        какие цели он будет решать,
        какие возможности он будет
        предоставлять, и в каком-то смысле
        ещё и как будет создаваться продукт
      - Функциональные и
        нефункциональные
        требования
        
        Функциональные требования
        описывает функции которые
        выполняет ПО
        
        Нефункциональные требования
        требования накладывают
        определенные ограничения
        
        Бизнес-правила включают или связаны с
        корпоративными
        регламентами, политиками, стандартами,
        законодательными актами,
        внутрикорпоративными инициативами
        (например, стремление достичь зрелости
        процессов по CMMI 4-го уровня),
        учетными практиками, алгоритмами
        вычислений и
        т.д.
        
        Внешние интерфейсы
        Часто заменяются на "пользовательский
        интерфейс". Безусловно вопросы
        организации пользовательского интерфейса
        очень важны в данной категории, однако,
        конкретизация аспектов взаимодействия
        с другими системами, операционной средой,
        возможностью мониторинга при эксплуатации -
        это всё больше не функциональные требования, а вопросы интерфейсов
        
        Атрибуты качества
        Дополнительные характеристики
        продукта в различных "измерениях",
        важных для пользователя или разработчика.
        Атрибуты касаются вопросов прототипируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.д
        
        Ограничения
        Условия или набор каких-то требований,
        которые сужает круг возможных решений их реализации. Сюда можно отнести параметры производительности, влияющие на выбор платформы для реализации.
        
        Системные требования
        Примерное описание характеристик которым должен соответствовать компьютер, для поддержания использования определенного ПО
    - - Полнота
        Полнота системы требований - это свойство, означающее, что совокпуность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.
      - Ясность
        Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
      - Корректность и согласованность
        Требования не должны противоречить , соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня.
      - Верифицируемость
        проверка требования.
      - Необходимость и полезность при эксплуатации
        Необходимость требований пользователя может вытекать из соответствующих бизнес-требований. Кроме того, требования пользователя могут мотивироваться эргономичностью(способностью создавать ощущения удобства, комфортности) продукта и особенностями его отдела(подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований
      - Осуществимость
        Требования на практике определяются балансом между ценностью (степенью необходимости и полезности) и потребительскими ресурсами
      - Тестируемость
        повысить управляемость проектом: при изменении отдельно взятого требования становится понятно - какие из проектных рабочих и других артефактов подлежат изменению
      - Упорядоченность по важности
        Приоритет требования представляет собой количественную оценку степени значимости требования. Приоритеты требований обычно назначает Заказчик или его представитель
    - - Системные и
        программные
        требования
        относятся к системе
        в целом или к
        программной
        составляющей
        
        Системные
        Описание примерных характеристик, которым должен соответствовать компьютер для того, чтобы на нём могло использоваться какое-либо определённое программное обеспечение.
        
        Программные
        Совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
  - - - Пользователи
        Группа людей, которая будет непосредственно использовать ПО. Они могут описать задачи, которые они сами будут решать используя ПО.
      - Заказчики
        Люди, которые отвечаю за заказ ПО, или являются целевой аудиторией на рынке ПО (образуют целевой рынок ПО)
      - Аналитики
        Продукты массового рынка ПО(и других массовых рынок), не обладают "заказчиками", т.е. теми, кто непосредственно заказывают разработку ПО. В то же время люди, которые отвечают за маркетинг,нуждаются в идентификации своих способностей и обращению к тем лицам, которые могут сыграть роль "квалифицированных представителей" потребителей.
      - Регуляторы
        Лица, которые делают всё по закону (Следят,чтобы разработка ПО и само ПО соответствовало всем законодательным актам и никак не нарушало закон, чтобы избежать проблем в дальнейшем.
      - Инженеры по ПО
        Лица, обладающие определенным интересом к разработке ПО. Именно они ответственны за техническую оценку путей решения задач и последующую реализацию требований заказчиков.
    - - Распределение ресурсов
      - Инициация и определение содержания
      - Управление в программной инженерии
  - - - Интервьюирование
        
        Подготовка
        
        Проведение интервью
        
        Завершение
      - Анкетирование
        метод, в котором в качестве средства для сбора информации от участника используется специально оформленный список вопросов - анкета
      - Наблюдение
        Через наблюдение, а возможно и участие, аналитики получают информацию о происходящих день за днём операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал или разговаривал с экспертами.
      - Самостоятельное описание требований
        Документы - источник, они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - способ получить представление о системе и сформулировать вопросы к экспертам.
      - Совместный семинар
        Первое правило мозгового штурма - "полный запрет на любую критику". Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
      - Разработка + проведение переговоров и нахождение компромисса
      - Сценарии
        контекст для сбора пользовательских требований, определяющий ответы на вопросы "что если" и "как это делается" в отношении бизнес-процессов, реализуемых пользователями
      - Прототипирование
        Это ключевая стратегия выявления требований в большинстве современных методологий.
        Программный прототип - "зеркало", в котором видно отображение того, как понял Исполнитель требования Заказчика
    - - Заказчик
      - Группа работников предприятия
      - Документация
      - Важные работники предприятия
  - - - Функциональные
        
        Пользовательские требования
        Кто и как взаимодействует с продуктом
        
        Функциональные требования
        
        Системные требования
      - Нефункциональные
        
        Требования к продукту
        
        Требования к переносимости
        
        Требования к эффективности
        
        Требования к эксплуатации
        
        Требования к надежности
        
        Организационные требования
        
        Выходные требования
        
        Внешние требования
        
        Требования на взаимодействия
        
        Этические требования
        Те, которые не прописаны в законодательстве, но соблюдаются всеми порядочными людьми
        
        Юридические требования
        
        Требования о сохранности конфиденциальности
        
        Требования о технике безопасности
    - - Природа проблемы
        (область проблемы)
      - Экспертиза и опыт инженеров
      - Требования заказчика к процессу
      - Доступность методов и инструментов
      - Внутрикорпоративные стандарты и регламент
      - Культура разработки
    - - Стандарт IEEE 1471-2000
      - Модель Захмана Link Title
        (Кликабельно)
      - TOGAF (Кликабельно)
  - - - Терминологические неопределенности
      - Отсутствие представления классификации требований
      - Фокусировка на деталях пользовательского интерфейса
      - Излишнее акцентирование внимания на деталях реализации
      - Слабая формализация бизнес-процессов
  - - - Смещение внимания с целевых функций прототипа и как следствие неудовлетворение пользователей
      - Превращение прототипа в реальную систему
  - - - Приемочный текст
- - - - Архитектурное проектирование
        декомпозиция структуры(статической) и организации (динамической) компонентов
      - Детализация архитектуры
        Описывает специфическое поведение и характеристики отдельных компонентов
    - - Абстракция
        Модель, упрощающую поставленную проблему до рамок, значимых для заданного контекста
      - Связанность и соединение
        Связанность - определяет силу связи между модулями
        Соединение - определяет как тот или иной элемент обеспечивает связь внутри модуля, внутреннюю связь
      - Декомпозиция и разбиение на модули
        Производится с целью получения более мелких и относительно независимых программных компонентов, каждый из которых несет различную функциональность.
      - Инкапсуляция/сокрытие информации
        Данная концепция предполагает группировку и упаковку элементов и внутренних деталей абстракции в отношении реализации с тем, чтобы эти детали были недоступны пользователям
      - Разделение интерфейса и реализации
        Данная техника предполагает определение компонента через специфицирование интерфейса, известного (описанного) и доступного клиентам (или другим компонентам), от непосредственных деталей реализации
      - Достаточность, полнота и простота
        Этот подход подразумевает что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией(моделью), но не более того. То есть не включают функциональность, отсутствующую в модели
  - - - Языки описания структуры
      - Диаграммы классов и объектов
      - Диаграммы компонентов или компонентные диаграммы
      - Карточки <функциональной> ответственности и связей класса
      - Диаграммы развертывания
      - Диаграммы сущность-связь
      - Языки описания/определения интерфейса
      - Структурные диаграммы Джексона
      - Структурные схемы
    - - Диаграммы деятельности или операций
      - Диаграммы поток данных
      - Таблицы и диаграммы <принятия> решений
      - Блок=схемы и структурированные блок-схемы
      - Диаграммы последовательности
      - Диаграммы перехода и карты состояний
      - Формальные языки спецификации
      - Псевдокод и программные языки проектирования
  - - - "разделяй и властвуй" и пошаговое уточнение
      - Проектирование "сверху-вниз" и "снизу-вверх"
      - Абстракция данных и сокрытие информации
      - Итеративный и инкрементный подход
      - Другое..
- - - - Стандарты в конструировании
        Стандарты, которые напрямую применяются при конструировании включают в себя 4 пункта
        
        коммуникационные методы (например, стандарты форматов документов и <оформления> содержания)
        
        Языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка программирования Java)
        
        Платформы (например, стандарты программных интерфейсов для вызовов функций
        операционной среды, такие как прикладные программные интерфейсы платформы Windows - Win32 API, Application Programming Interface или .NET Framework SDK, Software Development Kit).
        
        инструменты (не в терминах сред разработки, но возможных средств конструирования – например, UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода)
  - - - Инструментальный язык
        язык конструирования из повторно-используемых элементов; обычно строится как сценарный язык (script), выполняемый в соответствующей среде.
      - Язык программирования
        – наиболее гибкий тип языков конструирования. Содержит минимальный объем информации о конкретных областях приложения и процессе разработки, требуя больше всего (по сравнению с другими типами языков конструирования) усилий на изучение и наработку опыта для эффективного применения при решении конкретных задач.
    - - Практика конструирования программного обеспечения показывает активное применение следующих соображений и техник:
      - использование классов, перечисляемых типов, переменных, именованных констант и других выразительных сущностей;
      - организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры)
      - организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры)
      - обработка ошибочных условий и исключительных ситуаций
      - предотвращение возможных брешей в безопасности (например, переполнение буфера или выход за пределы индекса в массиве)
      - использование ресурсов на основе применения механизмов исключения (из рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, на основе блокировки данных, использования потоков и их синхронизации и т.п.)
      - документирование кода
      - тонкая “настройка” кода
    - - модульное тестирование (unit testing)
      - • интеграционное тестирование
    - - Задачи, связанные с повторным использованием в процессе конструирования и тестирования, включают:
        
        выбор единиц (units), баз данных тестовых процедур, данных <полученных в результате> тестов и самих тестов, подлежащих повторному использованию
        
        Оценку потенциала повторного использования кода и тестов
        
        Отслеживание информации и создание отчетности по повторному использованию в новом коде, тестовых процедурах и данных, полученных в результате тестов
    - - модульное (unit) и интеграционное (integration) тестирование
      - Разработка с первичностью тестов (test-first development - тесты пишутся до конструирования кода)
      - пошаговое кодирование (деятельность по конструированию кода разбивается на мелкие шаги, только после тестирования результатов которых производится переход к следующему шагу кодирования; известен также как итеративное кодирование с тестированием)
      - использование процедур утверждений
      - статический анализ
      - отладка
      - технические обзоры и оценки
- - - - Определение тестирования и связанной терминологии достаточно полно даѐтся в “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90
      - Недостатки и сбои
        В литературе, посвященной программной инженерии, встречается множество терминов, описывающих нарушение функционирования программных систем – недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др.
        Важно чѐтко разделять причину нарушения работы прикладных систем, обычно описываемую терминами недостаток или дефект, и наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям.
      - Ключевые вопросы
        
        Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования
        Критерии отбора тестов могут использоваться как для создания набора тестов, так и для проверки, насколько выбранные тесты адекватны решаемым задачам (тестирования). При этом, обсуждаемые критерии помогают определить, когда можно или необходимо прекратить тестирование.
        
        Эффективность тестирования/Цели тестирования
        Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий.
        
        Тестирование для идентификации дефектов
        Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда тесты запускаются для демонстрации того, что программное обеспечение удовлетворяет предъявляемым требованиями и, соответственно, тест считается успешным, если не найдено дефектов.
        
        Проблема оракула
        “Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден (“pass”) или нет (“fail”).
        
        Теоретические и практические ограничения тестирования
        Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. К сожалению, большинство установленных результатов теории тестирования – негативны, означая, по словам Дейкстры (Dijkstra), то, что “тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие”.
        Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения.
        
        Проблема неосуществимых путей
        Эта сложнейшая проблема автоматизированного тестирования связана с тем, что путь, по которому выполняются потоки работ тестируемой программной системы, не могут быть заданы входными параметрами.
        
        Тестируемость
        Это понятие может подразумевать две различных идеи. Первая описывает степень легкости описания критериев покрытия тестами для заданной программной системы. Вторая определяет возможность вероятность, возможность статистического измерения того, что при тестировании проявится сбой программной системы. Обе интерпретации этого понятия одинаково важны для тестирования.
  - - - Модульное тестирование
        Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.
      - Интеграционное тестирование
        Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода
      - Системное тестирование
        Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п.
        На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.
    - - Наиболее распространенные и обоснованные цели тестирования:
        
        Приѐмочное тестирование
        Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как сторона “принимающая” программную систему, или специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика.
        Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них.
        
        Установочное тестирование
        Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.
        
        Альфа- и бета-тестирование
        Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки.
        Данный вид тестирования не может быть заранее спланирован
        
        Функциональные тесты/тесты соответствия
        Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.
        
        Достижение и оценка надежности
        Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться при использовании моделей повышения надежности.
        
        Регрессионное тестирование
        Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых.
        
        Тестирование производительности
        Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения.
        
        Нагрузочное тестирование
        Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.
        
        Сравнительное тестирование
        Единичный набор тестов, позволяющих сравнить две версии системы.
        
        Восстановительные тесты
        Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды, в которой выполняется система.
        
        Конфигурационное тестирование
        В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.
        
        Тестирование удобства и простоты использования
        Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько
        эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.
        
        Разработка, управляемая тестированием
        По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке удовлетворения требований программной системой.
  - - - Специализированное тестирование
        Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. Данный вид тестирования может быть полезен для идентификации тех тестов, которые не охватываются рассматривавшимеся выше более формализованными техниками.
      - Исследовательское тестирование
        Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тесты создаются, выполняются и модифицируются динамически, по мере необходимости.
    - - Эквивалентное разделение <приложения>
        Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов эквивалентных классов (или наборов классов).
      - Анализ граничных значений
        Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести (robustness testing) системы, проводимые с величинами, выходящими за рамки
        специфицированных пределов значений
      - Таблицы принятия решений
        Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице.
      - Тесты на основе конечного автомата
        Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний приложения).
      - тестирование на основе формальной спецификации
        Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований. В ряде случаев могут строится на основе модели, являющейся частью спецификации, не использующей формального языка описания.
      - Случайное тестирование
        В отличие от статистического тестирования , сами тесты генерируются случайным образом по списку заданного набора специфицированных характеристик.
    - - Тесты, базирующиеся на блок-схеме
        Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов
      - Тесты на основе потоков данных
        В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования.
      - Ссылочные модели для тестирования, ориентированного на код
        Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов
    - - Предположение ошибок
        Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате анализа рисков.
      - тестирование мутаций
        Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаются для оригинального и всех “мутировавших” вариантов тестируемой программы.
      - Техники, базирующиеся на условиях использования
        
        Операционный профиль
        Базируется на условиях использования системы.
        Тестирование для оценки надѐжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы. Результаты таких тестов позволяют оценить поведение системы в реальных условиях.
        
        Тестирование, базирующееся на надежности инженерного процесса
        Базируется на условиях разработки системы.
        Соответствующие тесты (обозначаемые также аббревиатурой SRET) проектируются в контексте используемого процесса разработки и методик тестирования.
        
        техники, базирующиеся на природе приложения
        Описанные выше техники могут применяться к любым типам программных систем. В то же время, в зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения. Среди таких техник
        
        Объектно-ориентированное тестирование
        
        Объектно-ориентированное тестирование
        
        Объектно-ориентированное тестирование
        
        Тестирование на соответствие протоколам
        
        Тестирование на соответствие протоколам
        
        Выбор и комбинация различных техник
        
        Функциональное и структурное
        Техники тестирования, строящиеся на основе спецификаций или кода часто называют функциональными или структурными, соответственно. Оба подхода не должны противопоставляться, но дополнять друг друга.
        
        Определенное или случайное
        Обычно тесты можно распределить по данным группам на основе используемой политики выбора или определения входных параметров тестов.
  - - - Оценка программ в процессе тестирования
        Данные измерения могут базироваться на размере программ (например, в терминах количества строк кода или функциональных точек) или их структуре (например, с точки зрения оценки ее сложности в тех или иных архитектурных терминах). Структурные измерения могут также включать частоту обращений одних модулей программы к другим.
      - Типы дефектов, их классификация и статистика возникновения
        В литературе по тестированию встречается большое количество различных классификаций дефектов. Эффективность тестирования может быть достигнута в том случае, если мы понимаем какие типы дефектов могут быть найдены в процессе тестирования программной системы и как изменяется их частота во времени (подразумевая историческую перспективу развития системы, а неВ литературе по тестированию встречается большое количество различных классификаций дефектов. Эффективность тестирования может быть достигнута в том случае, если мы понимаем какие типы дефектов могут быть найдены в процессе тестирования программной системы и как изменяется их частота во времени (подразумевая историческую перспективу развития системы, а не
      - Плотность дефектов
        Тестируемая программа может оцениваться на основе подсчета и классификации найденных дефектов. Для каждого класса дефектов можно определить отношение между количеством соответствующих дефектов и размером программы (в терминах выбранных метрик оценки размера).
      - Жизненный цикл тестов, оценка надежности
        Статистические ожидания в отношении надежности программной системы могут использоваться для принятия решения о продолжении или прекращении (окончании) тестирования, исходя из заданных параметров приемлемого качества (например, плотности дефектов заданного класса).
      - Модели роста надежности
        Данные модели обеспечивают возможности прогнозирования надежности системы, базируясь на обнаруженных сбоях . Модели такого рода разбиваются на две группы – по количеству сбоев и времени между сбоями .
    - - Метрики покрытия/глубины тестирования
        Критерии “адекватности” тестирования, в ряде случаев, требуют систематического выполнения тестов для определенных набора элементов программы, задаваемых ее архитектурой или спецификацией. Соответствующие метрики позволяют оценить степень охвата характеристик
        системы.
        Критерии “адекватности” тестирования, в ряде случаев, требуют систематического выполнения тестов для определенных набора элементов программы, задаваемых ее архитектурой или спецификацией. Соответствующие метрики позволяют оценить степень охвата характеристик
        системы
      - Введение искусственных дефектов
        Этот подход помогает классифицировать возможные ошибки и следующие за ними сбои, применяя в дальнейшем полученные результаты для моделирования (пусть, часто, и интуитивного) возможных причин реальных сбоев, обнаруженных в процессе тестирования.
      - Оценка мутаций
        Получаемое в процессе тестирования мутаций отношение “убитых” к общему числу сгенерированных мутантов помогает измерить эффективность выполняемых тестов. В силу
        специфики такой техники тестирования, количественные оценки мутаций имеют практическое значение только для определенных типов систем.
      - Сравнение и относительная эффективность различных техник тестирования
        Различные исследования в области тестирования связаны с попытками сравнения (с точки зрения достигаемого качества продукта) разных подходов к тестированию. Когда мы говорим об “эффективности” тестирования надо чѐтко договориться, что именно мы подразумеваем под
        эффективностью, желательно, в количественном выражении. Возможные варианты интерпретации этого понятия – число тестов (данной техники), необходимых для обнаружения первого дефекта; отношение количества всех обнаруженных дефектов к дефектам, найденным с применением заданного подхода и т.п. Только обладая такого рода данными можно говорить о корректности сравнения и оценки эффективности.
  - - - Программирование без персоналий
        Очень важным компонентом успешного тестирования является совместное стремление участников проекта обеспечить необходимое качество продукта. Менеджеры играют ключевую роль в организации этой деятельности и на стадии разработки и в процессе сопровождения программных систем.
      - Руководства по тестированию
        Работы по тестированию могут руководствоваться различными соображениями и критериями – от управления рисками до специфицированных сценариев работы программных систем. В любом случае, желательно, исходя из ресурсов, количественных оценок и других характеристик, обеспечить использование различных техник тестирования для многосторонней оценки и улучшения качества получаемого продукта.
      - Управление процессом тестирования
        Работы по тестированию, ведущиеся на разных уровнях , должны быть организованы в единый (однозначно интерпретируемый) процесс, на основе учета 4 элементов и связанных с ними факторов: людей (в том числе, в контексте организационной структуры и культуры), инструментов, регламентов и количественных оценок (измерений).
      - Документирование тестов и рабочего продукта
        Документация – составная часть формализации процесса тестирования. Существует стандарт IEEE 829-98 “Standard for Software Test Documentation”, предоставляющий прекрасное описание тестовых документов, их связей между собой и с процессом тестирования. Среди таких документов могут быть:
        
        План тестирования
        
        Спецификация процедуры тестирования
        
        Спецификация тестов
        
        Лог тестов
        
        Внутренние и независимые команды тестирования
        Формализация процесса тестирования может включать и организационную формализацию команд(ы) тестирования. В нее могу входить как члены проектной команды, в частности, разрабатывающие код, так и внешние лица и группы. В идеале – желательно иметь как внутреннюю команду тестирования, так и внешнюю группу тестирования (обеспечения качества).
        
        Оценка стоимости и усилий, а также другие измерения процесса
        Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и оценка
        эффективности тестирования на разных этапах и уровнях, основывается на точке зрения и практиках менеджмента проекта (подразделения, компании...) и используется для оценки и улучшения (оптимизации) процесса тестирования.
        
        Окончание тестирования
        Очень важным аспектом тестирования является решение о том, в каком объеме тестирование достаточно и когда необходимо завершить процесс тестирования. Тщательные измерения, такие как достигнутое покрытие кода тестами или охват функциональности, безусловно, очень полезны.
        Однако, сами по себе они не могут определить критериев достаточности тестирования. Приятие решения об окончании тестирования также включает рассмотрение стоимости и рисков, связанных с потенциальными сбоями и нарушениями надѐжности функционирования тестируемой программной системы.
        
        Повторное использование и шаблоны тестов
        Доведение тестов до конца и обеспечение сопровождения программной системы необходимо каждый фрагмент системы тестировать систематическим образом, повторно используя наработанные тесты.
      - Тестовые работы
        Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, что успешное управление тестовыми работами сильно зависит от процессов конфигурационного управления
        
        Планирование
        Также как и другие аспекты управления проектами, работы по тестированию должно планироваться заранее. Как минимум, на уровне организации соответствующего процесса. Ключевые аспекты планирования тестовой деятельности включают:
        
        координацию персонала
        
        управление оборудованием и другими средствами, необходимыми для организации тестирования
        
        планирование обработки нежелательных результатов
        
        Генерация сценариев тестирования
        Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты должны находиться под управлением системы конфигурационного управления и описывать ожидаемые результаты тестирования.
        
        Разработка тестового окружения
        Используемое для тестирования окружение должно быть совместимо с инструментами программной инженерии (будут рассматриваться позднее как тема самостоятельной области знаний). Это окружение должно обеспечивать разработку и контроль тестовых сценариев, ведение журнала тестирования, и возможности восстановления ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также других активов тестирования
        
        Выполнение тестов
        Выполнение тестов должно содержать основные принципы ведения научного эксперимента:
        
        должны фиксироваться все работы и результаты процесса тестирования
        
        форма журналирования таких работ и их результатов должна быть такой, чтобы соответствующее содержание было понятно, однозначно интрепретируемой и повторяемо другими лицами
        
        тестирование должно проводиться в соответствии с заданными и документированными процедурами
        
        тестирование должно производиться над однозначно идентифицируемой версией и конфигурацией программной системы
        
        Анализ результатов тестирования
        Для определения успешности тестов их результаты должны оцениваться, анализироваться. В большинстве случаев, “успешность” тестирования подразумевает, что тестируемое программное обеспечение функционирует так, как ожидалось и в процессе работы не приводит к непредусмотренным последствиям.
        
        Отчѐты о проблемах/журнал тестирования
        Во многих случаях, в процессе тестовой деятельности ведѐтся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы и т.п.
        
        Отслеживание дефектов
        Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками, присутствующими в тестируемой программной системе (также они могут быть следствием поведения операционного и/или тестового окружения).
- - - - Природа сопровождения
        Сопровождение поддерживает функционирование программного продукта на протяжении всего операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения фиксируются и отслеживаются запросы на модификацию
        оценивается влияние предлагаемых изменений, модифицируется код и другие активы (артефакты) продукта, проводится необходимое тестирование и, наконец, выпускается обновленная версия продукта.
        
        Потребность в сопровождении
        Сопровождение необходимо для обеспечения того, чтобы программный продукт на протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. Деятельность по сопровождению применима для программного обеспечения, созданного с использованием любой модели жизненного цикла (например, спиральной) и методологии разработки.
        
        Приоритет стоимости сопровождения
        Работы по сопровождению потребляют если не большую (как отмечает SWEBOK), то значительную часть финансовых ресурсов жизненного цикла программного обеспечения.
        
        Существуют как технические, так и другие (например, организационные, являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат) факторы, оказывающие влияние на стоимость сопровождения, в целом:
        
        тип приложения
        
        новизна программного обеспечения
        
        наличие и квалификация персонала по сопровождению
        
        длительность использования программной системы
        
        характеристики и специфика аппаратной части
        
        качество дизайна
        
        Эволюция программного обеспечения
        Существующее (особенно, корпоративное) программное
        обеспечение никогда не бывает полностью завершенным и продолжает эволюционировать в течение всего срока эксплуатации. В процессе эволюционирования, программная система становится все более сложной до тех пор, пока не предпринимаются специальные усилия (в том числе, в рамках специального проекта по модификации) по уменьшению его сложности.
        
        Категории сопровождения
        Сегодня говорят о четырех категориях сопровождения ПО
        
        • Корректирующее сопровождение: “реактивная” модификация программного продукта, выполняемая уже после передачи в эксплуатацию для устранения сбоев;
        
        • Адаптирующее сопровождение : модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной
        эффективностью в изменившемся или находящемся в процессе изменения окружении;
        
        • Совершенствующее сопровождение : модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения;
        
        Профилактическое сопровождение: модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям.
        
        В общем случае, работы по сопровождению должны проводиться для решения следующих задач:
        
        улучшение дизайна
        
        устранение сбоев
        
        реализация расширений <функциональных возможностей>
        
        создание интерфейсов взаимодействия с другими (внешними) системами
        
        адаптация (например, портирование) для возможности работы на другой аппаратной платформе (или обновленной платформе), применения новых системных возможностей, функционирования в среде обновленной телекоммуникационной инфраструктуры и т.п.
        
        миграции унаследованного (legacy) программного обеспечения
        
        вывода программного обеспечения из эксплуатации
        
        Деятельность персонала сопровождения включает четыре ключевых аспекта
        
        поддержка контроля (управляемости) программного обеспечения в течение всего цикла эксплуатации
        
        поддержка модификаций программных систем
        
        совершенствование существующих функций*
        
        падения производительности программной системы до неприемлемого уровня
  - - - Ограниченное понимание
        Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять где необходимо внести исправления или изменения в код системы, которую он не разрабатывал.
      - Тестирование
        одним из ключевых вопросов сопровождения является организация работ по тестированию модификаций эксплуатируемых систем, вплоть до предварительного планирования и разработки регламентов, в соответствии с которыми, например, основываясь на оценке критичности запросов на изменения, затрагиваемых модулях, персоналом сопровождения будут проводиться стандартные процедуры.
      - Анализ влияния
        Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат) полный анализ возможных последствий и влияний изменений, вносимых в существующую систему
        
        Цели анализа влияния могут быть сформулированы следующим образом:
        
        Определение содержания изменений для задания работ по планированию и реализации
        
        Получение максимально возможной оценки ресурсов, необходимых для проведения соответствующих работ
        
        Анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается пожеланий, запросов на расширение системы)
        
        Обсуждение сложности вопросов, связанных с внесением соответствующих изменений
      - Возможность сопровождения
        Возможность сопровождения или сопровождаемость программной системы определяется как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований, ИЛИ как одну из характеристик качества
      - Управленческие вопросы
        
        Согласование с организационными целями
        Организационные цели описывают как продемонстрировать возврат инвестиций от деятельности по сопровождению программного обеспечения. Сопровождение системы преследует цели максимального продления срока эксплуатации программного обеспечения. Такой подход может основываться на необходимости
        обновления и расширения программного обеспечения, как отклика на изменяющиеся потребности пользователе
        
        Проблемы кадрового обеспечения
        Данная тема касается вопросов привлечения и удержания квалифицированного персонала по сопровождению.
        
        Процесс
        Процесс является набором работ, методов, практик и, своего рода, трансформаций, которые используются людьми для разработки и сопровождения программных систем и ассоциированных с ними продуктов.
        
        Организационные аспекты сопровождения
        В первую очередь, организационные вопросы подразумевают какая организация будет отвечать и/или какие функции необходимо выполнять для обеспечения деятельности по сопровождению.
        
        Аутсоурсинг
        Суть этого термина заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) “на сторону”. Крупные корпорации передают в управление другим организациям целые портфели программных систем, а,
        иногда, и целиком всю ИТ-инфраструктуру.
        
        Оценка стоимости сопровождения
        Инженеры должны понимать разницу в различных категориях сопровождения. Это, в большой степени, необходимо для оценки соответствующих затрат. С точки зрения планирования, как составной части проектной и управленческой деятельности, оценка стоимости является важным аспектом деятельности по сопровождению программного обеспечения.
        
        Оценка стоимости
        ISO/IEC 14764 (Standard for Software Engineering
        Software Maintenance)определяет, что “существует два наиболее популярных метода оценки стоимости сопровождения – параметрическая модель и использование опыта”. Чаще всего, оба этих подхода комбинируются для повышения точности оценки.
        
        Параметрические модели
        SWEBOK приводит ряд источников, подробно рассматривающих вопросы оценки стоимости сопровождения и, в частности, параметрические модели. Для использования таких моделей используются данные предыдущих проектов. Наравне с историческими данными используется метод функциональных точек (см. стандарт IEEE 14143.1-00).
        
        Опыт
        Среди тех подходов, которые позволяют повысить точность оценок, полученных при использовании параметрических моделей – применение опыта, аналогий, а также структуры декомпозиции работ.
        Наилучшие результаты получаются в случае сочетания эмпирических методов с имеющимся опытом. Получаемые данные используются как результат программы измерения аспектов сопровождения.
        
        Измерения в сопровождении программного обеспечения
        Формы и данные измерений в процессе сопровождения могут объединяться в единую программу корпоративную программу количественных оценок, проводимых в отношении программного
        обеспечения. Многие организации используют популярный и практичный подход для измерений, базирующийся на оценке количества проблем и статуса их решений
        
        Специализированные метрики
        Существуют различные методы внутренней оценки продуктивности персонала сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы.
        
        Типичные метрики оценки работ по сопровождению, соответствующих распространенной классификации эксплуатационных характеристик программного обеспечения:
        
        Анализируемость : оценка (в первую очередь, дополнительных) усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть
        модифицированы.
        
        Изменяемость: оценка усилий, необходимых для проведения заданных модификаций.
        
        Стабильность: оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования
        
        Тестируемость: оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.
  - - - Работы по сопровождению в стандарте 14764 разбиты на задачи:
        
        Реализация процесса
        
        Анализ проблем и <необходимых> модификаций
        
        Проведение модификаций (реализация изменений)
        
        Оценка и принятие <проведенных работ> при сопровождении
        
        Миграция (на модифицированную или новую версию программного обеспечения)
        
        Вывод из эксплуатации (прекращение эксплуатации программного обеспечения)
      - Работы по сопровождению
        Многие работы по сопровождению похожи на аспекты деятельности по разработке. В обоих случаях необходимо проводить анализ, проектирование, кодирование, тестирование и документирование. Специалисты по сопровождению должны отслеживать требования так же, как и инженеры-разработчики и обновлять документацию по мере разработки и/или выпуска обновленных или новых релизов продукта.
        . В то же время, деятельность по сопровождению обладает и определенными уникальными чертами, что приводит к необходимости использования
        специализированных процессов.
        
        Уникальные работы
        Существует ряд процессов, работ и практик, уникальных для деятельности по сопровождению.
        SWEBOK приводит следующие примеры такого рода уникальных характеристик:
        
        Передача: контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей • Передача (Transition): контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей
        
        Принятие/отклонение запросов на модификацию: запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться по различным обоснованным причинам – объему и/или сложности требуемых изменений, а также необходимых для этого усилий.
        
        Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках:
        функция поддержки конечных пользователей, инициирующая работы по оценке (assessment, подразумевая в том числе оценку необходимости), анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой.
        
        Анализ влияния: анализ возможных последствий изменений, вносимых в существующую систему
        
        Поддержка программного обеспечения: работы по консультированию пользователей, проводимые в ответ на их информационные запросы
        
        Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса - Service Level Agreement, а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.
        
        Дополнительные работы, поддерживающие процесс сопровождения
        Работы персонала сопровождения, не включающие явного взаимодействия с пользователями, но необходимые для осуществления соответствующей деятельности. К таким работам относятся: планирование сопровождения. Конфигурационное управление, проверка и аттестация, оценка качества ПО и т.п.
        
        Работы по планированию сопровождения
        Планирование является более чем необходимым для адекватного проведения работ по сопровождению и должно касаться связанных с этим вопросов с нескольких точек зрения:
        
        Бизнес-планирование (организационный уровень)
        
        Планирование непосредственных работ по сопровождению
        
        Планирование релизов/версий (уровень программного обеспечения)
        
        Планирование обработки конкретных запросов на изменение (уровень запроса)
        
        Конфигурационное управление
        Стандарт IEEE 1219, посвященный организации сопровождения программного обеспечения, определяет конфигурационное управление как критически важный элемент процесса сопровождения. Процедуры конфигурационного управления должны обеспечивать проверку, аттестацию и аудит на всех шагах, требуемых для идентификации, авторизации, реализации и выпуска программного продукта.
        
        Качество программного обеспечения
        Для поддержки процесса сопровождения должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества. Работы и техники по обеспечению качества, проверке и аттестации, обзору, анализу и оценке, а также аудиту, должны отбираться в контексте взаимодействия и согласования со всеми другими
        процессами, направленными на достижение желаемого уровня качества.
  - - - Реинжиниринг
        Реинжиниринг определяется как детальная оценка и перестройка программного обеспечения для формирования понимания, воссоздания) и дальнейшей реализации его <функций> в новой форме.
        
        Обратный инжиниринг
        “Обратный” инжиниринг это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга).