Proposed Unified “ility” Definition Framework Andrew Long

Slides:



Advertisements
Similar presentations
1/17 Non Functional Requirements by: Dr. Timothy Korson CPIS 443.
Advertisements

OPM Cybersecurity Competencies by Occupation (Technical Competencies) Information Technology Management Series Electronics Engineering.
02/12/00 E-Business Architecture
1 Quality Objects: Advanced Middleware for Wide Area Distributed Applications Rick Schantz Quality Objects: Advanced Middleware for Large Scale Wide Area.
SWE Introduction to Software Engineering
SE 555 Software Requirements & Specification Requirements Quality Attributes.
Ch2: Software: Its Nature and Qualities. 1 Introduction  Difference between a software and other engineering products.  Difference between software.
Chapter 13 Embedded Systems
1 Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
1 IS112 – Chapter 1 Notes Computer Organization and Programming Professor Catherine Dwyer Fall 2005.
1 FM Overview of Adaptation. 2 FM RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Project Investigators: Philip McKinley, Kurt.
IV&V Facility Model-based Design Verification IVV Annual Workshop September, 2009 Tom Hempler.
An Agile View of Process
Software Quality SEII-Lecture 15
Desired Quality Characteristics in Cloud Application Development Leah Riungu-Kalliosaari.
 The software systems must do what they are supposed to do. “do the right things”  They must perform these specific tasks correctly or satisfactorily.
Quality Assurance ITEC Rick Price. Expectations This course is not purely a lecture course – Classroom participation is a large portion – Everyone.
Strategy #5. IT Architecture and IT Infrastructure are Metaphors Architecture - the relationship between planning and building Infrastructure - examples.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
Rational Unified Process Fundamentals Module 4: Disciplines II.
An Introduction to Software Architecture
CSE 303 – Software Design and Architecture
Architecture-Based Runtime Software Evolution Peyman Oreizy, Nenad Medvidovic & Richard N. Taylor.
1 Software Quality CIS 375 Bruce R. Maxim UM-Dearborn.
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
2 Systems Architecture, Fifth Edition Chapter Goals Describe the activities of information systems professionals Describe the technical knowledge of computer.
Ranga Rodrigo. The purpose of software engineering is to find ways of building quality software.
Service Transition & Planning Service Validation & Testing
© Mahindra Satyam 2009 Decision Analysis and Resolution QMS Training.
Other Quality Attributes Other Important Quality attributes Variability: a special form of modifiability. The ability of a system and its supporting artifacts.
Question To know that quality has improved, it would be helpful to be able to measure quality. How can we measure quality?
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Software Testing and Quality Assurance Software Quality Assurance 1.
1 Panel on New Air Traffic Control and Management Technology February 23, 2007 The Potential and Realities of Research in Air Traffic Management Harry.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
NA-MIC National Alliance for Medical Image Computing UCSD: Engineering Core 2 Portal and Grid Infrastructure.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
When concepts fail, words arise Faust, Goethe Mephistopheles. …Enter the templed hall of Certainty. Student. Yet in each word some concept there must be.
LESSON 3. Properties of Well-Engineered Software The attributes or properties of a software product are characteristics displayed by the product once.
1 آزمايشگاه سيستم های هوشمند ( معماری سيستمهای با مقياس بزرگ آزمايشگاه سيستمهای هوشمند پاييز 93.
HND Computing Unit 8 Quality Management Prepared by S Hargrave
CSE 303 – Software Design and Architecture
CSPC 464 Fall 2014 Son Nguyen.  Attendance/Roster  Introduction ◦ Instructor ◦ Students  Syllabus  Q & A.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Lecture Videos will no longer be posted. Assignment 3 is due Sunday, the 8 th, 7pm. Today: –System Design,
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 9: Design Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
February 19, February 19, 2016February 19, 2016February 19, 2016 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific.
Software Design and Architecture
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
Decisive Themes, July, JL-1 ARTEMIS Decisive Theme for Integrasys Pedro A. Ruiz Integrasys July, 2011.
Chapter 1 Computer Technology: Your Need to Know
TOTAL QUALITY MANAGEMENT
Overview Software Maintenance and Evolution Definitions
Non-functional requirements as Gordian knot
Classifications of Software Requirements
Rekayasa Perangkat Lunak Part-10
Rekayasa Perangkat Lunak
Source & Courtesy: Doc. S. Dapkūnas
Software Engineering Development of procedures and systematic applications that are used on electronic machines. Software engineering incorporates various.
مقدمه اي بر مهندسي نيازمنديها
Rekayasa Perangkat Lunak
Software Quality Engineering CS- 449
NSF CSR PI Meeting Breakout Session: Integrated Networked Systems and Internet of Things Saurabh Bagchi Purdue University.
An Introduction to Software Architecture
ISO/IEC Systems and software Quality Requirements and Evaluation
Tomaž Špeh SURS TF SERV, Luxembourg,
Presentation transcript:

Proposed Unified “ility” Definition Framework Andrew Long

Motivation  Increased interest in system “ilities”  Lack of common understanding among practitioners Definitions Relationships between one ility and another Metrics  Objective: Provide a framework to promote shared discussion of system “ilities”

What are system “ilities”?  -ility Latin: a suffix; meaning, ability, ability to [do something] In systems engineering “ilities” are desired system properties  “ilities” describe the system (non-functional) rather than specific system behaviors (functional) Functional requirements define what a system is supposed to do; e.g. Performance Non-functional requirements define how a system is supposed to be.

Some examples?  Accessibility  Accountability  Adaptability  Administrability  Affordability  Auditability  Availability  Credibility  Compatibility  Configurability  Correctness  Customizability  Debugability  Degradability  Determinability  Demonstrability  Dependability  Deployability  Distributability  Durability  Effectiveness  Evolvability Extensibility Fidelity Flexibility Installability Integrity Interchangeability Interoperability Learnability Maintainability Manageability Mobility Modifiability Modularity Operability Portability Predictability Provability Recoverability Reliability Repeatability Reproducibility Resilience Responsiveness Reusability Robustness Safety Scalability Sustainability Serviceability (a.k.a. supportability) Securability Simplicity Stability Survivability Sustainability Tailorability Testability Timeliness Traceability Ubiquity Understandability Upgradability Usability Versatility “List of system quality attributes” – Wikipedia, May 2012

How are they related to one another? "Engineering Systems: Meeting Human Needs in a Complex Technological World" by de Weck O., Roos D. and Magee C, MIT Press, January 2012

Common element: Uncertainty  System “ilities” account for a system’s ability to change / react to uncertainty Figure adapted from: Ross, A.M., and Rhodes, D.H., "Using Natural Value-centric Time Scales for Conceptualizing System Timelines through Epoch-Era Analysis," INCOSE International Symposium 2008, Utrecht, the Netherlands, June 2008  In system engineering, uncertainties occur in performance & value expectations Performance: Variance between actual and desired system performance resulting from uncertainty within contexts (e.g. design, production, operations, etc.) Value: Variance in “expected value” resulting from feedback of delivered value, resulting from changing context, stakeholders, needs, etc.

Designing for Uncertainty  System “Changeability” taxonomy (Ross et al.) provides start for defining system ilities.  Change Effect: The difference in states (performance or value) before and after a change has taken place –Robustness (No Change) –Scalability (Do More / Less) □ To deconflict w/ more common scalability definitions, will refer to as Expandability –Modifiability (Add, Remove, Alter ) Change Objective: The specific approach / plan / goal / strategies one employs to achieve a desired change effect (Think of these as common “ility” families). Objectives enabled by change enablers and must account for change considerations Change Enablers: System design elements / operational decisions that enable the change objective Change Considerations: Constraints, Conditions, resources, etc. Change Agent: The instigator, or force, for the change Ross, A.M., Rhodes, D.H., and Hastings, D.E., "Defining Changeability: Reconciling Flexibility, Adaptability, Scalability, Modifiability, and Robustness for Maintaining Lifecycle Value," Systems Engineering, Vol. 11, No. 3, pp , Fall 2008.

Proposed “ility” Framework Change Effect Performance Change Objectives Value Change Objectives RobustnessQuality (Assurance and control) Safety Reliability Availability Maintainability Testability Resiliency Awareness Susceptibility Vulnerability Recoverability ExpandabilityScalabilityExtensibility ModifiabilityConfigurabilityEvolvability Change Enablers Accessibility Compatibility Commonality Distributability Durability Homogeneity Heterogeneity Interchangeability Interoperability Mobility Modularity Portability Repairability Reusability Serviceability (a.k.a. supportability) Understandability Usability / operability Change Considerations Affordability Sustainability Agility / Responsiveness Manufacturability Change Agents Flexibility (External) Adaptability (Internal)

Maintaining Performance  Quality: Ability of a product / service to deliver desired performance in spite of internal contextual uncertainties System performance change objectives Robustness (No Change) change effect strategies  Examples: Toyota Production System, Six Sigma, Taguchi loss function, Telecommunications, …  Quality Aspects Assurance: Activities designed to ensure that quality requirements are fulfilled (includes Safety, Reliability, Availability, Maintainability) Control: Examination activities (i.e. manufacturing, production, operations) to assess system status (includes testability) A A A A

Increasing / Decreasing Performance  Scalability: Ability of a system to provide more / less functionality as a response to internal contextual uncertainties in order to delivery desired performance System performance change objectives Expandability (Do More / Less) change effect strategies  Examples: Electronics / Networking. Performance improves after adding hardware, proportionally to the capacity added Peer-to-Peer (P2P): Facebook, Pinterest, LinkedIn, Groupon, and many, many more… A B A A

 Configurability: Ability of a system to change its behavior as a response to internal contextual uncertainties in order to delivery desired performance System performance change objectives Modifiability (Add, Remove, Alter) change effect strategies  Examples: Swiss Army knife High Mobility Multipurpose Wheeled Vehicle (HMMWV) Adding / Removing Performance A B A A

Maintaining Value  Resiliency: Ability of a system to continue to satisfy value expectations despite changes in context and /or value-based uncertainties  System value change objectives  Resiliency (No Change) change effect strategies  Example: Survivable communications systems, Network design / topology, Combat systems / aircraft survivability Ability of an architecture to support the functions necessary for mission success in spite of hostile or adverse conditions - DoD  Resiliency aspects Awareness (Identification changing in value expectations) Survivability (Susceptibility, Vulnerability, Recoverability) A A B A + B

Increasing / Decreasing Value  Extensibility: Ability of a system to satisfy expanded / contracting value expectations as a response to changes in context and value-based uncertainties  System value change objectives  Expandability (Do More / Less) change effect strategies  Examples: Software APIs (Application Programming Interface) that allows software behavior to be extended / modified (used) by people who don't have access to the original source code. Software languages (e.g. JAVA) that allow for software applications to run on a variety of operating platforms Infrastructure (e.g. Highway, Rail, Telecommunications) Large scale defense systems (e.g. Air Bases, Aircraft Carriers, Lockheed C-130 Hercules, Satellites) A A B A + B

Adding / Removing Value  Evolvability: Ability of a system to satisfy new / eliminated value expectations as a response to changes in context and value-based uncertainties  System value change objectives  Modifiability (Add, Remove, Alter) change effect strategies  Examples: Biological systems Internet / World Wide Web A A B A + B

Change Enablers  System design / operational approaches employed to achieve desired change objective Accessibility Compatibility Commonality Distributability Durability Homogeneity Heterogeneity Interchangeability Interoperability Mobility Modularity Portability Repairability Reusability Serviceability (a.k.a. supportability) Usability / operability …

Change Considerations  Design considerations (e.g. conditions, resources, constraints, etc.) applied to design / operational approaches Affordability (Budget) Sustainability (Resources) Agility / Responsiveness (Schedule / Response time) Manufacturability (Technology) Manageability (Organizational)

Change Agents  The instigator, or force, which employs a given change mechanism in order to achieve a desired change effect  Flexibility: External decision-maker imposed change Associated with future / delayed decisions to respond to change (i.e. Real options)  Adaptability: System self-imposed change Associated with upfront / current decisions to respond to change (i.e. Pre-planned / Baked – in)  Flexibility / Adaptability are meaningless without specifying change objectives, enablers, etc.

Questions ? Change Effect Performance Change Objectives Value Change Objectives RobustnessQuality (Assurance and control) Safety Reliability Availability Maintainability Testability Resiliency Awareness Susceptibility Vulnerability Recoverability ExpandabilityScalabilityExtensibility ModifiabilityConfigurabilityEvolvability Change Enablers Accessibility Compatibility Commonality Distributability Durability Homogeneity Heterogeneity Interchangeability Interoperability Mobility Modularity Portability Repairability Reusability Serviceability (a.k.a. supportability) Understandability Usability / operability Change Considerations Affordability Sustainability Agility / Responsiveness Manufacturability Change Agents Flexibility (External) Adaptability (Internal)