SOFTWARE QUALITY CONTROL IN AN OO
DEVELOPMENT PROCESSLedis Chirinos & Francisca Losavio
ISYS Center - LaTecS Laboratory
SQUAD Workshop
Budapest, June 7, 2001
Agenda
• Goals
• Configuration of the SQUID tool for OOMGRIN– Definition of the process model– Definition of the quality model
• Case Study• Conclusion & Future Work
GOALS• Apply the SQUID (Software Quality In the
Development process) method&tool to an OO process based on OOMGRIN (OO Method for GRaphical user Interface development)
• Enrich the SQUID data base with data on an OO development process
• Improve the GUI development process based on the OOMGRIN method
OOMGRIN - Characteristics• OO method for developing interactive
systems, where GUI plays a major role
• Use case based for functional requirements elicitation
• Multiagent model style for the system architecture
• Reusable design elements (frameworks or architectural patterns, design patterns) for specifying the system architecture
OOMGRIN - Elements
• Use cases, as defined in OOSE and now in UML, to capture the system functionality with respect to the user of the system (actor)
• Entity, interface and control objects, as defined in OOSE, and now in UML
• Interface agents to model GUI objects
Requirements model –Use-case model-
Semantics level
GUI Level
A
A
A A
AC
C C
C
P
P
P P
Domain objects model(optional)
–Objects organization schema - analysisModel
Use-case-PAC Model-
PAC agent framework- Design model
p
C
–-
Configuration of the SQUID tool for OOMGRIN
• The development process model– The ISYS (Ingeniería de Software Y Sistemas)
research center is an academic organization• 15 researchers leading projects
• 30-45 undergraduate or graduate students (license, MSc, PHD)
– Establish the review points, deliverables, activities
Development process review points
Review points Type Description1. Requirements model Non repeatable Date of delivery of the requirements model document2. Analysis model Non repeatable Date of delivery of the analysis model document3. System architecture (Use-Case-Agent model).
Non repeatable Date of delivery of the document containing the systemarchitecture using the Use-Case-Agent model.
4. Design of the interface agents Non repeatable Date of delivery of the document containing theinstantiated framework for each interface agent.
5. Generation of the GUI prototype Non repeatable Date of delivery of the executable GUI prototype.6. Completed system Non repeatable Date of delivery of the final system.
Development process deliverables
Deliverables Type Description1.1. Use-Cases model Non
RepeteableDocument where the actors interacting with the system areidentified through the system functionality. (Use-Cases).
1.2. Relations of extend and use for each use-case
Repeatable Document containing the diagrams used for representing therelations of extend and use identified for each use-case.
1.3. Description or specification of each use-case
Nonrepeatable
Document containing the textual specification or description ofeach Use-Case for each actor.
1.4. Description of the GUI Nonrepeatable
Document containing a first GUI prototype, consisting ofinformal drawings or textual description.
1.5. Model of the problem domain objects (optional).
Nonrepeatable
Document containing the diagram of the problem domain objectmodel
2.1. Structural model of the interface objects
Repeatable Document containing the diagram representing the interfaceobjects and their relationships.
2.2. Schema for structuring the identity, control and interface objects for each actor.
Repeatable Document containing the schema for organizing the identity,control and interface objects for each system actor.
3.1. Use-case-agent model Nonrepeatable
Document containing the diagram representing the globalarchitecture of the system. The GUI is represented bycooperating interface agents.
3.2. Detailed description of each use-case
Repeatable Document containing the textual specification of the tasks foreach use-case
3.3. Design of the interaction diagrams
Repeatable Document containing the interaction diagrams with the objects(control, entity and interface) involved in each use-case.
4.1. Design of the GUI component using a framework for each interface agent.
Repeatable Document containing the specification of the instantiatedframework used for each interface agent.
Development process activities
Activity Type Description1.1. Identification of actors and use- cases.
Nonrepeatable
Specify the functionality of the system with respect to itsactors, according to [ 9].
2.2. Development of the schema for organizing the entity, control and interface objects for each actor.
Repeatable Identify control objects. Take entity objects from the problemobject domain model. Draw the schema for organizing theentity, control and interface objects, according to [13].
3.1.Develop the Use-Case-Agentmodel.
Nonrepeatable
Define the system architecture where user interface aspects arefocused by applying the use-case-agent model [13].
ISO 9126 quality modelReliability (E)
Reusability (I)Instanciability (I)
Abstraction(I)Robustness (E)
Usability (E)Understandability (E)
Complexity (I)Learnability (E)
Complexity (I)Operability (E)
Complexity (I)Maintainability (E)
Reusability (I)Modularity (I)
Cohesion (I)Coupling
Flexibility (I)Coupling (I)
Modifiability (I)Complexity (I)
Coupling (I)Extensibility (I)
Coupling (I)
External view of quality model
Characteristic External Subcharacteristic
External attribute
Reliability Robustness - Failure rate- Recovery time between failures (time in revive an execution)- Mean time between failures
Usability Understandability
Learnability
Operability
- Time spent to understand the functionality offered by theGUI.-Time spent to learn to operate the functionality offered by theGUI-Mean time of response, for each of the functionality offeredby the GUI.
Maintainability -Time spent to modify an existing GUI functionality-Time spent to change a data requirement. (time spent by thesoftware engineer to diagnostic, find and/or correct a failure).-Time spent to add a new GUI functionality.
External measures of quality model
External attribute Unit Counting RuleFailure rate Percentage
Scale type:
Ratio (Float) 0-1
Percentage of user incorrect inputs where the system isnot able to recover. It is computed dividing the totalnumber of user incorrect inputs, where the system isnot recovering by the number of user incorrect inputs.An execution time of 60 minutes is considered. Thisvalue has been obtained from previous projects
Counting ruleX= 1-((B-A)/ B) if B > 0X= 0 if B=0
A: Number of user incorrect inputsB: Total number of incorrect inputs, where the systemis not able to recover.
Internal view for MaintainabilityExternalcharacteristic
Int. Sub-charact. Int. Sub-Sub-caract.
Int. Sub-Sub-Sub-caract.
Attribute
Maintainability Modifiability
Extensibility
Reusability
Complexity -modifiability
Coupling -extensibility.
Modularity
Flexibility
Coupling-complexity-modifiability
-----Cohesion-modularity
Coupling-Modularity
Coupling-Flexibility
- Size- Depth of the hierarchy in thearchitecture topology (Number oflevels)- Top level agents (average number of agents of thetop level)
- Fan - Out (average of sub-agents)- Fan – In(average number of agents fromwhich an agent is derived).
- Fan - Out (average of sub-agents)- Fan – In(average number of agents fromwhich an agent is derived).
- Size
- Lack of cohesion between themethods of the classes for an agent(LCOM [4]).
-Fan - Out (average number of sub-agents)-Fan – In (average number of agentsfor which an agent is derived).
-Fan - Out (average number of sub-agents)-Fan – In(average number of agents fromwhich an agent is derived).
Models Integration
Internal attribute Project Object(Deliverable)
Unit Counting rule
Depth of the tree inthe architecturetopology (Number oflevels).
3.1. Use-Case-PACmodel
Levels
Scale type:interval-integer 0-10
Record the number of levels identified in theUsee-Case-PAC model (see OOMGRIN step 3),corresponding to the GUI objects hierarchy.
Counting ruleX = MM: Number of levels identified in the Use-Case-PAC model. ( it will be considerd the longest pathfrom the root to one of the leaf)
Case Study
• SQUID (method&tool) applied to the construction of the HIGOO tool
• HIGOO: CASE tool for interactive systems development supporting OOMGRIN
• Specification, planning and control activities were carried out completely
Quality SpecificationMaintainability:
Requirements and target values forthe GUI component
Qualitycharacteristic
Sub-characteristic External attribute Requirementname
Targetvalue
Maintainability Time spent by the software engineer tomodify an existing GUI functionality
Req. Nº 112 hours
Time spent to change a data requirement.(time spent by the software engineer todiagnostic, find and/or correct a failure). .
Req. Nº 21 hours
Time spent by the software engineer to add anew GUI functionality
Req. Nº 3 48 hours
Quality Planning
• Development process for GUI component– OOMGRIN
• Assign target values to internal quality attributes– based on the experience of previous projects
developed with OOMGRIN
. Qualitycharacteristic
Internal Sub-chracteristic
Internal Sub-Sub-
characteristics.
Internal Sub-Sub-Sub-
characteristic
Internal Sub-Sub- Sub-Sub-characteristic
Internal attribute Targetvalues
Maintainability Modifiability
Extensibility
Complexity
Coupling
Coupling
-Size 1 (N° of use-cases)-Size 2 (Nº of tasks)-Size 3 (Nº of interactiondiagrams)-Size 4 (Nº of classes)-Size 5 (Nº of actors)-Size 6 (Nº of use-cases byeach actor).- Depth of the tree in thearchitecture topology (N°.of levels)- Top level agents(average number of agentsof the top level)
-Fan -Out (N° sub-agents)-Fan-In (Nº of agents fromwhich an agent isderived).).
-Fan-Out(N° sub-agents)-Fan-In (Nº of agentswhich an agent isderived).)
16 4 4
12 4 4
5
4
4 1
4 1
Quality Control
CONCLUSION• Quality management of an OO software
project has been carried out using the SQUID method&tool
• The SQUID configuration step, based on ISO 9126, has been used for quality requirements specification
• The ISO 9126 quality model has been customized to get the quality attribute measures for interactive systems developed with the OOMGRIN method
CONCLUSION• OOMGRIN has benefited from the SQUID
approach in the sense that– the method specification has improved,
following the SQUID configuration step
• The OO development with OOMGRIN has the advantage that– since the objects involved are reusable design
components (frameworks and design patterns), it was relatively easy to get the internal attribute measures
Future Work
• ISO 9126 quality model for capturing and specifying non functional quality requirements
• SQUID configuration step for being used as a first step in an architectural design method