Notes - MCS
Robust Software
Notes - MCS
Robust Software
  • Robust Software
  • Secure Software Design Principles
    • Motivation
    • Secure and Resilient/Robust Software
    • Best Practices for Resilient Applications
    • Designing Applications for Security and Resilience
    • Architecture for the Web/Cloud
  • Software Security Lifecycle
    • Motivation
    • Secure Development Lifecycle
    • Software Security Touchpoints
    • Software Assurance Forum for Excellence in Code (SAFECode)
    • Secure SW Lifecycle Processes Summary
    • Adaptations of the Secure Software Lifecycle
    • Assessing the Secure Software Lifecycle
    • Recommendations
  • Software Quality Attributes
    • Motivation
    • Software Quality Assurance
    • Software Quality Standards
    • Software Quality Attributes
    • Extra Software Quality Assurance Properties
  • Security Requirements
    • Motivation
    • Security Requirements
    • Threats
    • Defenses
    • Confidentiality
    • Integrity
    • Availability
    • What about other goals/properties?
    • Security Requirements Engineering
    • Types of Security Requirements
    • Security Policy
    • Precision
    • Completeness and Consistency
    • Examples of Non-Functional Requirements
    • Goals and Requirements
    • Measures
    • Requirements Interaction
    • Natural Language Requirements
    • Best Practices
  • Common Software Attacks
    • Objectives
    • 10 Major Cyber-Attacks of 21st Century
    • Software Security Basics
    • Defenses Methods
    • SANS SWAT Checklist
  • Safe Programming
    • Secure Coding Practices
    • Top 10 Secure Coding Practices (CERT/SEI)
    • 7 Pernitious Kingdoms
  • Robustness, PenTest, Fuzzy and Static Code Analysis
    • Security/Robustness Testing
    • Robustness Tests Checklist Example
    • Penetration Testing
    • Penetration Testing Roadmap
    • Tools
    • Fuzz Testing
    • Static Code Analysis
    • Side Channels
  • Safety (and Security)
    • Safety
    • A safety Lifecycle Example
    • Risk Management Process
    • System Definition
    • Hazard Identification and Classification
    • Desk-based Hazard Identification
    • Workshop-based Hazard Identification
    • HAZOP
    • Hazard Identification and Classification
      • Broadly acceptable risks
    • Risk Evaluation and Risk Acceptance
    • Use of codes of practice
    • Use of reference system
    • Explicit risk estimation
    • Qualitative risk estimation
    • Quantitative risk estimation
    • Safety measures
    • Safety requirements
    • Hazard Management
    • Hazard life cycle
    • Independent Assessment
    • Safety Plan
    • Safety Case
    • FMEA Example
    • DevSecOps
Powered by GitBook
On this page
  1. Software Quality Attributes

Software Quality Standards

ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.

  • A quality-in-use model is composed of five characteristics (some of which are further subdivided into sub-characteristics) that relate to the outcome of interaction when a product is used in a particular context of use. This system model applies to the complete human-computer system, including both computer systems in use and software products in use.

  • A product quality model is composed of eight characteristics (which are further subdivided into sub-characteristics) that relate to static properties of software and dynamic properties of the computer system. The model applies to both computer systems and software products.

ISO/IEC 25010:2011 quality in-use model

  • Product dev activities that can use the quality models include:

    • identifying software and system requirements;

    • validating the comprehensiveness of a requirements definition;

    • identifying software and system design objectives;

    • identifying software and system testing objectives;

    • identifying quality control criteria as part of quality assurance;

    • identifying acceptance criteria for a software product and/or software-intensive computer system;

    • establishing measures of quality characteristics in support of these activities.

Last updated 1 year ago