Chapter 2: SWE Qualities

1
Chapter 2 SWE Qualities
Prof. Steven A. Demurjian Computer Science
Engineering Department The University of
Connecticut 371 Fairfield Road, Box
U-2155 Storrs, CT 06269-2155
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 4818 (860) 486 3719 (office)
2
Software Engineering Qualities

• Software is a Malleable Product that is Human
  Intensive (High People to Machine Ratio)
• Software Engineering Qualities
• Correctness and Reliability
• Robustness and Performance
• User Friendliness and Verifiability
• Maintenance and Reusability
• Repairability and Evolvability
• Portability, Understandability, and
  Interoperability
• Productivity, Timeliness, and Visibility
• Requirements for Information, Real-Time,
  Distributed, and Embedded Systems

3
What is a Software Quality?

• A Software Quality is a Characteristic to be
  Attained throughout an Applications Lifetime
• Software Qualities are the Goals of Product and
  Process
• Types of Software Qualities
• Internal - within the Software - Developers
• External - Look-and-Feel of Software -
  UsersOften Difficult to Distinguish Ext. vs.
  Int.
• Process - Related to a Softwares Production
• Product - Artifacts Produced during Process
• Software Quality Assurance Assess and Evaluate
  the Attainment of Qualities by Finished Product
• Security Assurance
• Information Assurance

4
The Correctness Software Quality

• Functional Correctness Software Behaves
  According to Requirements Specification
• Assessing Correctness - Potential Problems
• Assumes Requirements Specifications are Available
  and Up-to-Date
• Assumes Correctness Testing is Possible
• Assumes Mathematical Properties can be
  Established Between Software and Specs
• Correctness - Absolute Quality (Yes/No)
• Correctness in Practice
• Focus on Components at Varying Levels
• Addressed via Public Interface, Private
  Implementation, Testing of Classes/Components
• Components in Distributed Apps

5
The Reliability Software Quality

• Software Performs as User Expects
• User Can Depend on Software
• Different Reliability Requirements per Domain
• Computer Games Low?
• Flight Control Software (Mars) High?
• Banking, Insurance, Stocks, High?
• Correct Software is Reliable but Reliable
  Software May Not be Correct, that is
• Reliability in Practice
• Focus on Reliability of Components (Classes) and
  their Composition into Systems
• Critical for Commercial Success of Consumer
  Products and Services

6
The Robustness Software Quality

• Software Behaves Reasonably, Even in Unexpected
  Circumstances
• Different Robustness Requirements per Domain
• Computer Games Low or High?
• ATM Machine High - Hard to Break
• May Include Hardware Robustness (ATM Story)
• Incorrect Behaviors Acceptable, as Long as a
  Consistent, Workable Outcome Occurs
• Robustness in Practice
• Java Provides Exception Handling that Can be
  Built into Each Class (Component) for Robustness
• Robustness Transcends D D Paradigm
• Robustness Critical for Commercial Success

7
The Performance Software Quality

• Performance is Equated with Efficiency,
  Scalability, Reliability, User-Acceptance, etc.
• Growing Problem Impacts Strongly on Software
• Varied OS Platforms (NT, Win2K/XP, Solaris)
• Different HW Capabilities (Memory Size, 32 vs. 64
  bit, Disk Capacity, Display, etc.)
• Measurement vs. Queuing Analysis vs. Simulation
• Impact from Specification through Delivery
• Performance in Practice
• Identify Key Classes/Components with Hard
  Performance Constraints
• Embedded Applications (Elevators, Avionics, etc.)
• Versions of Classes/Components for OS/HW
  Platforms?

8
The Performance Software Quality

• Measurement Measure Actual Performance of
  Working Systems
• Analysis Build a Model and Analyze
• General Understanding of System
• Queueing Models During Specification/Design
• Redo Queueing Models After Implementation by
  Providing Hard Numbers to Fine-Tune
• Simulation Model Simulates Actual System
• Predict Exact Performance of Components
• Expensive and Time Consuming to Build
• Yields an Accurate Estimate
• System Performance Must Be Addressed from Day One
  Throughout Lifetime

9
The Maintenance Software Quality

• Modifications and Enhancements Made to Product
  After Release - 60 of Total Software Cost
• Three Types of Maintenance
• Corrective Remove Errors Post Delivery(20)
• Adaptive Adjust Per OS/HW Changes(20)
• Perfective Improve Qualities/Features(50)
• Modification to Legacy Software for Major
  Improvement or Software Evolution
• Maintenance in Practice
• Can OO Reduce Corrective Maintenance?
• Can OO Facilitate Adaptive and Perfective
  Maintenance?
• How do we Maintain Web/Distributed Apps?

10
Maintenance of Web Applications

• Three Types of Maintenance
• Corrective, Adaptive, and Perfective
• Need to have Strategy for Making Changes
• Web Apps Typically Developed in Staged Setting
• Development/Testing Environment Web
  Application Server on Intranet
• Actual Web Application Servers on Internet
• May be Replicated Web/Application Pairs that are
  Geographically Separated
• Changes/Testing on Intranet
• Migration to Internet in a Staged Manner for
  Upgrades
• Note
• Maintenance Requires Version Management
• Source Code Control System

11
The Reusability Software Quality

• Strive for Domain-and-Organization Specific Reuse
• Products Most Likely to be Developed in Future
• Focused on Software Components
• Scientific Math and String Libraries
• Windowing and GUI Building Blocks
• Java APIs for Enterprise, Embedded, etc.
• Reusability Evolving to Larger Components (e.g.,
  Java Beans) and Subsystems
• Reusability in Practice
• In OO, Achieved via Inheritance and Generics
• Defined/Controlled by Designers and Developers
• Components Play a Major Role in Reuse and in
  Distributed/Web Applications
• Reuse Shopping Cart, Checkout Procedures, etc.

12
The Repairability Software Quality

• Ability to Correct Problems with Limited Amount
  of Work and a Minimal Impact
• A Well Modularized Product is Easier to Modify
  than a Monolithic Project
• Programming Language Role in Repairability
• What is Classic Repairability Problem Today?
• Repairability Related to Reusability/Evolvability
  
• Repairability in Practice
• Repairs Focused on Class or Component
• If Public Interface Remains UnchangedThen No
  Impact as a Result of Repair
• May have to Rebuild
• Key Concern in Web Application that Must Always
  be Up and Available

13
The Evolvability Software Quality

• Field of Dreams If you Build it, it Will Change!
• Key Evolvability Issues
• Ease of Modifications - Add New Features and
  Change Existing Features
• Function of System Size
• Modularization vs. Monolithic
• Over Time, Evolvability Reduces as Subsequent
  Versions of Same Software are Released
• Reach of Limit of Change w.r.t. Look-and-Feel
• Evolvability in Practice
• Achieved via Inheritance and Polymorphism
• Public Interface Must Remain Unchanged!
• Adding Capabilities and Features to Web and
  Distributed Applications the Norm

14
The Portability Software Quality

• Software Works on Different Platforms
• Origins and Popularity of C and Unix
• Hard in Practice - All Cs Not Created Equal
• Borland C vs. Visual C vs. Sun C
• Java Compiler Addons and Competing Versions
• 32 vs. 64 bits
• Core Language Same? (Operator Precedence)
• Compiler/Product Specific Libraries
• Newer Languages (Ada95, Java) Stress Ability to
  Port without Rewriting Any Code
• Portability in Practice
• Isolate Specifics into Dedicated Classes
• Portability Transcends D D Paradigm
• Web App works in Multiple Browsers/Versions

15
The Understandability Software Quality

• System Has Predictable Behavior
• Internal Understandability
• Is the Software Easy to Learn and Understand?
• Varies Based on Application Domain
• OS vs. Tool vs. Small Application
• Strongly Related to Evolvability/Verifiability
• External Understandability
• From the Perspective of User
• Is the Software Easy to Understand and Use?
• Emerging Applications/Games for Children starting
  at 6 months on up
• Understandability in Practice
• Easy to Change and Evolve
• External is Key to Successful Web Apps

16
The Interoperability Software Quality

• Enterprise Computing The Problem of Today and
  Future!
• New Products Must Coexist and Cooperate with
  Legacy, COTS, Databases, etc.
• Success in Interoperability Traced to
• Programming Interface for COTS/Legacy
• DCOM/OLE, CORBA, DCE, JINI, .NET
• Emerging Languages Java, Active-X, C
• Open Systems, Standards, Multiple Vendors, etc.
• Interoperability in Practice
• Focus on Public Interface Concept
• Interoperability Transcends D D Paradigm
• Norm for Web and Distributed Applications

17
Typical Process Qualities

• Process Qualities Involve the Steps and Actions
  that are Integral to Software Development
• Productivity
• Denotes the Efficiency and Performance of
  Software
• A Measurable Quality (Empirical)
• Timeliness
• Ability to Deliver a Product on Time
• Meeting Deadlines and High Quality Products
• Visibility
• All of Its Steps and Current Status are
  Documented Clearly
• Open Software Process (All Stakeholders)

18
The Productivity Software Quality

• Efficiency Measure of Software Production Process
• Measurable in Many Ways
• Individuals
• Team
• Number of Classes/Lines of Code
• Impacted by Problem Domain and its Complexity
• Productivity in Practice
• Potential for Significant Increases with OO
• Short-Term Investment for Long-Term Gain
• Cant Fall Into Trap of Simply Counting Code
• Web Code Counts Much Higher (and Often
  Automatically Generated)
• Lousy Developers Often Write More Code

19
The Timeliness Software Quality

• Meeting Deadlines and Market Demands
• Requires Careful Scheduling, Accurate Estimation,
  and Clear Milestones
• Impacted by
• Changing User Requirements
• Skills (or Lack Thereof) of SW Engineers
• Incremental Delivery
• Product Released in Stages
• Complete and Incremental Requirements
• Timeliness in Practice
• Promotes Increments and Components
• Classes Facilitate Evolution, Testing and
  Integration
• For All Applications (Centralized to Distributed)

20
Timeliness Visual Description of Mismatch

• Often the Development Process Does Not Follow the
  Evolution of User Requirements
• A Mismatch Occurs Between User Requirements And
  Status of the Product

21
The Visibility Software Quality

• Software Process is an Open and Transparent
  Activity that is Shared by Developers/Managers
• SW Engineers Apprised of Decisions and Choices
• Strong Visibility Results in
• Team Members Working in Same Direction
• Management and Users Understand Problem
• Easier Integration of New Personnel
• Visibility in Practice
• Open Systems, Free Software Foundation
• Java, CORBA, ODBC, .NET
• New Open Document Standard - Reality
• Companies/State/Governments Looking for
  Guarantees that Todays Documents Usable Tomorrow
• State of MA Standoff with Microsoft (Blinked)

22
What is OpenDocument?

• Open Source Document File Format for Saving and
  Exchanging Documents Across Multiple Editors
• Editors Include OpenOffice, StarOffice, KOffice,
  IBM Workplace, and Abiword
• All Information is stored in XML Files
• Constantly Evolving to Incorporate Newest Ideas
• Currently Trying to Become ISO Certified
• Developed by OASIS Consortium
• OASIS is Composed of Multiple Large Vendors
  Including Adobe, Corel, IBM, KDE, and Sun
• Based on OpenOffice File Format Modified per
  Input from Different Vendors

23
Why is OpenDocument Important?

• Allows the Use of Multiple Document Editors
• Stored in XML Compared to .Doc Binaries Allows
  Easy Access to Data
• Example Pre-MSWord 95 Unreadable in Office03
• European Union Requiring Document Formats to be
  Approved by Standards Body
• Microsoft No
• Opendocument Being Reviewed
• Massachusetts Recommending All State Documents
  Being in Non Proprietary Format
• Recently, Microsoft Blinked and Agreed to
  OpenDocument Format Compatibility

24
Application-Specific Qualities

• Consider Information, Embedded, Distributed, and
  Web-Based Systems
• Many Common Application-Specific Qualities
• Data Integrity Tracking Information Content
• Negative Salaries, Dependencies Among Values,
  etc.
• Security Tracking Access to Information
• Who can do What on Which Data When?
• Data Availability Robustness and Accessibility
• Is Application Up, Running, and Available?
• Transaction Compartmentalizing Functionality
• ATM Transactions
• Database Update Transactions
• Defined Unit Fully Executes or Doesnt

25
Quality Requirements Information Systems

• Manage and Process Information
• Database and Transaction Processing Model
• Typically Characterized by
• Data Integrity Reliability
• Data Security Correctness
• Data Availability Correctness/Performance
• Transaction Processing Performance
• Employs Client/Server Paradigm
• Client GUI for User - Non-technical
• Server Database Management System
• Transactions and Results Across Network
• Emerging Fields Data Mining, Data Warehousing

26
Quality Requirements Real-Time Systems

• Ability of a System to Respond to Events within a
  Predefined Time
• Real-Time Computing via ATMs
• Embedded Computing (Elevators, Avionics, etc.)
• Often Control Oriented
• System Actions Managed to Meet Priorities
• Evaluated by Software Quality Assurance
• Are Requirements Attained?
• Performance, Correctness, Reliability
• Safety The Absence of Undesirable Behavior
• User Friendliness Critical from System Operators
  Perspective

27
Quality Requirements Distributed Systems

• Independent Components Interconnected by Network
  for Communication
• Computing Paradigm for Today and Tomorrow
• Web-Based Applications
• Client/Server and Multi-Tier
• Characterized by
• Degree of Distribution
• Partitioning of System or Information
• Fault Tolerance Across Application
• Keys Correctness, Performance, Reliability
• Recent and Emerging Technologies
• DOC, CORBA, DCE, DCOM, .NET, JINI, etc.
• Java, Jasmine, Oracle, etc.

28
Quality Requirements Embedded Systems

• Another Growing Field in Computing
• Pervasiveness of Computers in
• Consumer Electronic Products
• Appliances and Automobiles
• Keys Correctness, Performance, Reliability
• Embedded Computing and Java
• PersonalJava Java in Game Consoles, Smart
  Phones, Remote Controls, Touch Screens, etc.
• Embedded Java Java in Mobile Phone, Process
  Control Network Routers, etc.
• Java Card Smart Card Technology - Credit Card
  Computer for Personal, Health Data, etc.
• Myriad of Commercial Applications
• MP3, Microwave, Smart Ovens (Appliances), etc.

29
Quality Measurement

• Many Qualities are Subjective
• Qualitative Assessment via Criteria
• Identify Criteria and See If SW Satisfies Them
• No Standard Metrics Defined for Most Qualities
• However, Many Metrics for Assessing Software
• UML Tool Together Architect has Metrics for
• Lines of Code
• Tracking Calls and Dependencies Among Classes
• Average Lines of Code/Class or Method
• Software Quality Assurance
• Security Assurance
• Guarantees that Certain Access Control Achieved
• Information Assurance
• Guarantees on Information Content

30
Software Qualities in 3 Tier Setting
Which Qualities are Most Important and
Why? Correctness Reliability, Robustness and
Performance User Friendliness, Verifiability
Maintenance, Reusability, Repairability and
Evolvability Portability, Understandability, and
Interoperability Productivity, Timeliness, and
Visibility
31
Software Qualities in 4 Tier Setting
Which Qualities are Most Important and
Why? Correctness Reliability, Robustness and
Performance User Friendliness, Verifiability
Maintenance, Reusability, Repairability and
Evolvability Portability, Understandability, and
Interoperability Productivity, Timeliness, and
Visibility
32
Chapter 2 - Summary

• Qualities Determine the Merits of Software
• Correctness and Reliability
• Robustness and Performance
• User Friendliness and Verifiability
• Maintenance and Reusability
• Repairability and Evolvability
• Portability, Understandability, Interoperability
• Productivity, Timeliness, and Visibility
• Software Quality Assurance Focuses on the
  Attainment of the Qualities of Specification in
  Working Prototypes/Product
• Difficult to Quantitatively Measure