Software quality assurance : in large scale and complex software-intensive systems

Software quality assurance in large scale and complex software-intensive systems

Software Quality Assurance in Large Scale and Complex Software-intensive Systems presents novel and high-quality research related approaches that relate the quality of software architecture to system requirements, system architecture and enterprise-architecture, or software testing. Modern software...

Descripción completa

Detalles Bibliográficos
Otros Autores: Mistrik, Ivan, author (author), Mistrík, Ivan, editor (editor), Abran, Alain, 1949- contributor (contributor)
Formato: Libro electrónico
Idioma:Inglés
Publicado: Amsterdam, [Netherlands] : Morgan Kaufmann 2016.
Edición:1st edition
Materias:
Computer software > Quality control.
Ver en Biblioteca Universitat Ramon Llull:https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009629824906719
Tabla de Contenidos:
  • Front Cover
  • Software Quality Assurance
  • Copyright Page
  • Contents
  • List of Contributors
  • Biography
  • Deployability
  • Release Plan
  • Moving Through the Tool Chain
  • Trade-offs
  • General Scenarios and Tactics
  • Microservices
  • Continuous Deployment
  • Roll Back
  • The Number of Quality Attributes Is Growing
  • References
  • Foreword
  • References
  • Preface
  • Introduction
  • Why a New Book on Software Quality
  • Book Outline
  • 1 Quality concerns in large-scale and complex software-intensive systems
  • 1.1 Introduction
  • 1.2 Software Quality Management
  • 1.3 Software Quality Models
  • 1.4 Addressing System Qualities
  • 1.5 Assessing System Qualities
  • 1.5.1 Assessment Processes
  • 1.5.2 Metrics and Measurements
  • 1.6 Current Challenges and Future Directions of Software Quality
  • 1.7 Conclusion
  • References
  • 2 An introduction to modern software quality assurance
  • 2.1 Introduction
  • 2.2 Requirement Conformance Versus Customer Satisfaction
  • 2.3 Measurement
  • 2.4 Quality Perspectives
  • 2.5 Quality Models
  • 2.6 Non-Functional Requirements
  • 2.7 Cost of Quality
  • 2.8 Verification and Validation
  • 2.9 Role of Formal Methods
  • 2.10 Role of Testing and Automated Testing
  • 2.11 Reliability
  • 2.12 Security
  • 2.13 Safety
  • 2.14 Reviews and Usability
  • 2.15 Reviews and Postmortems
  • 2.16 User Experience
  • 2.17 Social Media, Cloud Computing, and Crowdsourcing
  • 2.18 Maintenance and Change Management
  • 2.19 Defect Analysis and Process Improvement
  • 2.20 Role of Product and Process Metrics
  • 2.21 Statistical SQA
  • 2.22 Change Management
  • 2.23 Agile Development Processes
  • 2.24 Conclusions/Best Practices
  • References
  • 3 Defining software quality characteristics to facilitate software quality control and software process improvement
  • 3.1 Overview
  • 3.2 Process Based Approaches to Software Quality.
  • 3.3 Review of the Structure and Utility of Software Quality characterization Models
  • 3.3.1 Quality Factor Perspectives and Definitions
  • 3.3.2 Defining Criteria for Quality Factors
  • 3.3.3 Metrics for Defining the Presence of Quality Factors
  • 3.3.3.1 Metric versus measurement
  • 3.4 Defining an Organization's Software Quality Characterization Model
  • 3.4.1 Step 1: Document the Quality Factors and Model Hierarchy
  • 3.4.2 Step 2: Document the Quality Characterization Model's Internal Metrics
  • 3.4.3 Step 3: Document the Quality Characterization Model's External Metrics
  • 3.4.3.1 Which external metrics should be documented as requirements?
  • 3.4.3.2 Which external metrics should be subjected to dynamic testing?
  • 3.5 Software Quality Control's Utilization of the Quality Characterization Model
  • 3.5.1 Systems Analysis
  • 3.5.2 Systems Design
  • 3.5.3 Development
  • 3.5.4 Testing the Presence of External Metrics for a Given Quality Factor
  • 3.6 SPI Utilization of the Quality Characterization Model
  • 3.6.1 Measuring and Monitoring Quality Factors and Related Metrics
  • 3.6.2 Process Improvements Related to Software Quality Characterization Models
  • 3.7 Concluding Remarks
  • References
  • 4 Quality management and software process engineering
  • 4.1 Motivation
  • 4.2 Our Notion of Process
  • 4.3 Quality Management
  • 4.4 Software Process (SP)
  • 4.5 Software Quality
  • 4.6 Quality Management Through SP Engineering
  • 4.6.1 Localizing Focus on Quality
  • 4.6.1.1 Requirements engineering and management
  • 4.6.1.2 Engineering technical specifications
  • 4.6.1.3 System architectural design
  • 4.6.1.4 System engineering design
  • 4.6.1.5 Software architectural design
  • 4.6.1.6 Software engineering design
  • 4.6.1.7 Software construction engineering
  • 4.6.1.8 Software installation engineering
  • 4.6.1.9 Software commissioning engineering.
  • 4.6.1.10 Software operations engineering
  • 4.6.1.11 Software maintenance engineering
  • 4.6.1.12 Software re(verse) engineering
  • 4.6.2 Controls Based on "Progress" and Life cycle Models of SP
  • 4.6.3 Process Quality and Quality Management
  • 4.6.4 Contextual Constraints
  • 4.7 Conclusion
  • References
  • 5 Architecture viewpoints for documenting architectural technical debt
  • 5.1 Introduction
  • 5.2 Background and Related Work
  • 5.2.1 Architectural Technical Debt
  • 5.2.2 Technical Debt Documentation
  • 5.3 Typical Stakeholders and Concerns
  • 5.3.1 ATD Stakeholders
  • 5.3.2 Concerns on ATD
  • 5.4 ATD Viewpoints
  • 5.4.1 ATD Detail Viewpoint
  • 5.4.2 ATD Decision Viewpoint
  • 5.4.3 ATD-Related Component Viewpoint
  • 5.4.4 ATD Distribution Viewpoint
  • 5.4.5 ATD Stakeholder Involvement Viewpoint
  • 5.4.6 ATD Chronological viewpoint
  • 5.5 Case Study
  • 5.5.1 Study Objective and Research Questions
  • 5.5.2 Study Execution
  • 5.5.2.1 Case description
  • 5.5.2.2 Data collection
  • 5.5.2.2.1 Data to be collected
  • 5.5.2.2.2 Data collection method
  • 5.5.2.2.3 Data collection process
  • 5.5.3 Results
  • 5.5.3.1 Understandability of ATD viewpoints (RQ1)
  • 5.5.3.2 Ease of collecting the required information and documenting ATD views (RQ2)
  • 5.5.3.3 Usefulness in understanding ATD (RQ3)
  • 5.5.4 Interpretation
  • 5.5.4.1 Interpretation of the results regarding RQ1
  • 5.5.4.2 Interpretation of the results regarding RQ2
  • 5.5.4.3 Interpretation of the results regarding RQ3
  • 5.5.5 Implications for Research and Practice
  • 5.5.6 Threats to Validity
  • 5.6 Conclusions and Future Work
  • Acknowledgment
  • Appendix A. ATD Concerns
  • Appendix B. Viewpoint Definitions and Correspondence Rules
  • B.1 Metamodel of ATD Viewpoints
  • B.2 ATD Decision Viewpoint
  • B.2.1 Model kind
  • B.3 ATD-Related Component Viewpoint
  • B.3.1 Model kind.
  • B.4 ATD Distribution Viewpoint
  • B.4.1 Model kind
  • B.5 ATD Stakeholder Involvement Viewpoint
  • B.5.1 Model kind
  • B.6 ATD Chronological Viewpoint
  • B.6.1 Model kind
  • B.7 ATD Detail Viewpoint
  • B.7.1 Model kind
  • B.8 Correspondences Between Viewpoints
  • References
  • 6 Quality management and Software Product Quality Engineering
  • 6.1 Limitations of the Current Software Practices
  • 6.1.1 Quality Management During the Lifecycle
  • 6.1.2 Managing Software Quality Requirements
  • 6.1.3 Support for Utilizing Institutional Knowledge
  • 6.2 Principles of Software Product Quality Engineering
  • 6.2.1 Holistic View of Product Quality
  • 6.2.2 Engineering Quality with Patterns
  • 6.2.2.1 Structure of a quality pattern
  • 6.2.2.2 Catalog of quality patterns
  • 6.2.2.3 Functional Correctness Patterns
  • 6.2.3 Compositional Traceability
  • 6.2.4 Process-Product Correlation
  • 6.3 Case Study
  • 6.3.1 Process Instantiation and Configuration Structure
  • 6.3.2 Software Quality Requirements
  • 6.3.3 Consistency Tracker
  • 6.4 Conclusion
  • References
  • 7 "Filling in the blanks": A way to improve requirements management for better estimates
  • 7.1 Introduction
  • 7.2 Meeting the "Voice of the Customer": QFD
  • 7.3 "Filling in the Blanks": How to Further Improve Estimation Capability?
  • 7.3.1 What Could be Missing? Coming Back to Early Phases…
  • 7.3.2 Working on Requirements
  • 7.3.3 Working with Stakeholders (with the Proper Requirements)
  • 7.4 Improving QFD: QF2D
  • 7.5 QF2D: Example Calculation
  • 7.6 Conclusions and Next Steps
  • References
  • 8 Investigating software modularity using class and module level metrics
  • 8.1 Introduction
  • 8.2 Software Quality Measurement
  • 8.3 Software Measurement
  • 8.4 Software Modularity
  • 8.5 Coupling and Cohesion Metrics
  • 8.6 Coupling and Cohesion Metrics at Higher Levels of Granularity.
  • 8.7 Coupling and Cohesion Metrics Utilized in This Study
  • 8.8 Empirical Study
  • 8.9 Objectives and Research Questions
  • 8.10 Empirical Design
  • 8.10.1 System Selection
  • 8.10.2 Data Collection and Analysis
  • 8.11 Results
  • 8.11.1 RQ1: Can we Characterize through Metrics, HLMs in Weka, and Thus Indicate Good/bad Candidate, HLMs?
  • 8.11.2 RQ2: Are Coupling Metrics at this High Level of Modularity Reflective of Coupling Metrics at Lower Levels of Granula...
  • 8.12 Discussion
  • 8.13 Validity and Reliability
  • 8.14 Conclusion
  • Acknowledgment
  • References
  • 9 Achieving quality on software design through test-driven development
  • 9.1 Introduction
  • 9.2 Evidences on the Influence of TDD on Software Quality
  • 9.3 TDD as a Design Technique
  • 9.4 Modeling Relations with TDD
  • 9.4.1 Mock Objects
  • 9.4.2 Designing Dependencies
  • 9.4.3 Hierarchy and Abstractions
  • 9.5 Large Refactorings
  • 9.6 Combining TDD with Other Design Techniques
  • 9.6.1 Architectural Design
  • 9.6.2 Domain Modeling
  • 9.6.3 Design Patterns
  • 9.7 Preparing for TDD in a Software Project
  • 9.8 Continuous Inspection
  • 9.9 Conclusions
  • References
  • 10 Architectural drift analysis using architecture reflexion viewpoint and design structure reflexion matrices
  • 10.1 Introduction
  • 10.2 Reflexion Modeling
  • 10.3 Reflexion Modeling Using Software Architecture Viewpoints
  • 10.4 Reflexion Viewpoint
  • 10.5 Design Structure Matrix
  • 10.6 Design Structure Reflexion Matrix
  • 10.7 Possible Applications
  • 10.8 Conclusion
  • References
  • 11 Driving design refinement: How to optimize allocation of software development assurance or integrity requirements
  • 11.1 Introduction
  • 11.2 Safety Requirements in ARP4754-A
  • 11.3 The Issue of Independence in ARP4754-A
  • 11.4 Challenges in Requirements Allocation-The Research Problem
  • 11.5 Automatic Allocation of DALs.
  • 11.5.1 HiP-HOPS.

Ejemplares similares