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