1. Chapter ? Quality Assessment
CSE784 Software Studio Class Notes
Chapter ? Quality Assessment
Jim Fawcett
Copyright ©

2. Software Product Model
Architecture – Operational Concept Document (OCD)
defines product components and allocates processing to them
defines external product behavior
Software Requirements Specification (SRS)
describes what constitutes correct operation
it is the basis for testing and evaluation
Software Design Document (SDD)
defines an architecture for the system
describes software design and implementation
specifies a software build process
Test Plan
defines procedures for unit, integration, validation, qualification, and regression testing
qualification test procedures are emphasized
Prototype Code
verifies design for critical processing, analyzes implementation problems as they arise
Product Code
Code for each component of the product, implemented as software modules.
test stub attached to each module, used to establish basic software cycling and nearly correct operation
Test Code
test drivers for unit, integration, and qualification tests
Test Report
The Architecture
defines a partition of the product into component parts
describes in detail the product’s public interface
lists critical processing
may define major data structures

3. Requirements Analysis
Software requirements analysis and preliminary design are processes of breaking down or decomposition in the application domain:
Application requirements are decomposed to processes and data flows.
Process is a logical model of some part of the program’s activities necessary to satisfy part of its requirements model.
Data flows represent the information necessary to sustain activities allocated to the process.
Each process is allocated part of the program’s requirements model and may derive additional requirements necessary to complete or disambiguate its processing model.
A design structure is developed by associating major processes with modules.
Each such process and its data flows represents the public interface of its module.
Each stage of the decomposition needs to flow down, or allocate, requirements to its component parts, otherwise there is no basis for deciding the correctness of the design.

4. SRS Quality Measures Legally Complete Unambiguous
All requirements are specified.
Complete description of behavior and appearance.
Traceability between A and B levels.
Unambiguous
Requirements need no interpretation and should be read very literally.
This depends to some extent on the expertise of the participants – customer and developers.
Absolutely Consistent
Context diagram and all levels of Data Flow Diagrams balance. Flow names match in spelling and case.
Data Dictionary lists all data flows as shown on the above diagrams with exact spelling and case.
Fairly uniform level of detail in each leaf node process description, e.g., DFDs are balanced.
Paragraph numbers match Data Flow Diagram numbering.
Testable and No Design Detail
Requirements have no adjectives or adverbs, e.g., no best, maximum, highest, lowest, etc.
No design details, e.g., no requirements on data transfer, implementation strategy, data structures, control.

5. Software Design Issues
Abstraction
logical model of component’s responsibilities
Modularity
partitioning into cohesive components
Encapsulation
separating public interface from private implementation
building firewalls
Hierarchy
delegating responsibilities
Cohesion
each component should be focused on only one or two activities
Coupling
narrow coupling to maximize independence
each component should need to know as little as possible about other components
Locality of reference
data referenced by a component should be defined or declared by the component
Size and Complexity
each component is small and simple enough to test thoroughly
Object Oriented Design
an object takes care of itself, allocating any resources it needs, and cleaning up after itself
it is a self contained processing entity which serves others through calls to its public interface

6. Design Quality Measures
Software decomposed into executive and server modules
Graphical user interfaces delegate all their computation
Server modules are cohesive, focused on a single activity or intimately related set of activities
High level server modules have well-defined application domain abstractions and support salvage reuse.
A module supports salvage reuse if:
it has a strong abstraction
Has no recursive dependencies on sibling modules
depends only on modules it calls, not on modules calling it, e.g., no assumptions
Makes very few assumptions about its environment
Low-level server modules have well-defined solution domain abstractions and are reusable in a bottoms-up development.
All modules are self-documenting
Manual and Maintenance Pages
Comments to describe complex or tricky code
Support testing
Provide test stubs
Catch exceptions, provide meaningful error messages
Modules are relatively small and simple
Can be represented with a single structure chart
Functions are small and simple
Source Lines of Code (SLOCs) < 50
Cyclomatic Complexity (CC) < 10

7. Design Document Quality Measures
Complete Description of “As-Built” Product
Descriptions of:
Structure
Modular structure and modules
Classes and class relationships
Function calling relationships
Responsiblities
Operation
Object creation, lifetime, and messaging relationships
Events
States and state transitions

8. Software Implementation Issues
Modular Structure
manual page
maintenance page
public interface
private implementation
test stub
test drivers
The importance of correct operation
design attributes, e.g., size, complexity,
The role of testing
pre and post conditions, formalizing assumptions
checking invariants
Honoring the logical model
Good Neighbor policy
Good Housekeeping policy
Object Oriented Software
building sets of objects
empowering objects
client-server model
Error handling
Managing interfaces
Developer’s responsibilities for maintenance

9. Implementation Quality Measures
To Be Defined

10. Software Testing Construction testing (build a little, test a little)
test stubs
testing invariants
incremental development
Unit testing (did I do it correctly?)
striving to make each component operate correctly, e.g., according to its specifications
Integration testing (will they come together?)
bringing separately developed components into the same build
Performance testing (are there adequate margins?)
examine critical time-lines
random access and disk memory use
Validation testing (does it crash?)
stress tests, pattern tests, random inputs
Qualification testing (did we meet all requirements?)
a legal verification that requirements have been meet
Regression testing (does it still work?)
high level test of public operations
used when porting to new platforms, after maintenance modifications, and when re-installing

11. Test Quality Measures
To Be Defined

12. End of Presentation