Zádor Dániel Kelemen Budapest University of Technology and Economics, SQI - Hungarian Software...

Zádor Dániel Kelemen Budapest University of Technology and Economics, SQI - Hungarian Software Quality Consulting Institute

Supervisors:Katalin Balla Budapest University of Technology and Economics, SQI - Hungarian Software Quality Consulting InstituteJos Trienekens, Rob Kusters Technical University of Eindhoven

EuroSPI 2008, Dublin

Software Process Evolution Quality assurance at Hungarian

companies A practical problem in using multiple

quality approaches A possible solution

… Structure of Process-based Quality Approaches

▪ Comparison of QAP elements vs. process elements▪ Observations

…

Software lifecycle models (eg. waterfall model -idealised processes)

Methodologies (eg. JSP, JSD - recipes, paperwork)

Formal development (proving correctness, not scalable)

Automation (Software Development Environments – eg. requirements

specification cannot be automated) Quality Management and Process Improvement

(ISO, CMMI - increased bureaucracy) Process Modeling and Process Programming

(BPMN, EPCs, UML Activity diagrams , Little JIL, etc.)

Companies want / are forced to use multiple quality approaches simultaneously eg. ISO 9001, CMMI and ITIL in the same time. Hundreds of quality assurance

documentation pages are produced at organizational level▪ even more at organizational & project level

Problem:• Separate documentation, process descriptions exists for

different quality approaches.• The separated process descriptions are not unified /

harmonized. • Project managers and other workers are forced to

choose between approaches.• Projects are focusing in only one way on quality.

• Eg focusing on requirements management but not on the customer’s property (even if both are important for the company)

• Processes built on different quality approaches include different descriptions of same areas (eg. change management or measurement).• Inconsistences, contradictions may happen

…could be to describe / model the needed approaches all together, in a common format In order to do so, the following steps may be

required:▪ Discovering possible representation / modeling

solutions▪ Selecting the quality approaches to be modeled▪ Building a common meta-model (if it is needed)▪ Describing the quality approaches in a common

format▪ …

Software lifecycle models (eg. waterfall model -idealised processes)

Methodologies (eg. JSP, JSD - recipes, paperwork)

Formal development (proving correctness, not scalable)

Automation (Software Development Environments – eg. requirements

specification cannot be automated) Quality Management and Process Improvement

(ISO, CMMI - increased bureaucracy) Process Modeling and Process Programming

(BPMN, EPCs, UML Activity diagrams , Little JIL, etc.)

Modelingquality

approaches

In order to quickly create process models, would be useful to know, what kind of elements could be converted directly from textual information to graphical representation.

Aspects considered important:▪ to analyse the structure of the widespread

approaches,▪ to describe the structure of approaches analysed

in a very simple and understandable format. ->▪ UML class diagrams are suitable for describing structures

The most used and “mandatory” quality approach: ISO 9001:2000 Quality management systems – requirementsBesides ISO 9001:2000, most used approaches are: CMMI & SPICEFurther, well known approaches at Hungarian companies: ISO 9004:2000 Quality management systems – Guidelines for

performance improvements ISO/IEC 90003:2000 Software Engineering – Guidelines for the

application of ISO9001:2000 to computer software ISO/IEC 15939-2002 – “Information technology - Software

measurement process” ISO/IEC 12207-95 – “Information technology - Software life

cycle process”Continuing with: ITIL, Agile methods etc.

Elements:• Chapter• Subchapter• Sub-subchapter• Requirement

in (simple) sentences

Elements:• Process area• Specific Goal• Specific Practice• Typical Work Product• Sub Practice• Generic Goal• Generic Practice• Generic Practice Elaboration

Elements:• Process• Process

Description• Activity• Task• Option• Condition• Documentation

requirement• Responsibility

Chapter Subchapter Sub-subchapter Requirement (in /simple/

sentences) Guideline Process Process Description Activity Task Option Condition Documentation

requirement Responsibility Chapter / process activity Subchapter /sub-activity Sub-sub-activity Activity description

• Process area• Specific Goal• Specific Practice• Typical Work Product• Sub Practice• Generic Goal• Generic Practice• Generic Practice Elaboration• Process• Mission Statement• Goal• Activity• Benefit• Critical Success Factor• Key Performance Indicator• Further Specific Informative

Components• Method• Practice• Value• Feature• Process

Process Elements:• Purpose• Inputs• Entry criteria• Activities• Roles• Measures• Verification steps• Outputs• Exit criteria

QAP Elements:

ChapterSubchapterSub-subchapterRequirement (in /simple/ sentences)GuidelineProcessProcess DescriptionActivityTaskOptionConditionDocumentation requirementResponsibilityChapter / process activitySubchapter /sub-activitySub-sub-activityActivity descriptionProcess areaSpecific GoalSpecific PracticeTypical Work ProductSub PracticeGeneric GoalGeneric PracticeGeneric Practice ElaborationProcessMission StatementGoalActivityBenefitCritical Success FactorKey Performance IndicatorFurther Specific Informative ComponentsMethodPracticeValueFeatureProcess

Chapter Subchapter Sub-subchapter Requirement (in /simple/

sentences) Guideline Process Process Description Activity Task Option Condition Documentation

requirement Responsibility Chapter / process activity Subchapter /sub-activity Sub-sub-activity Activity description

• Process area• Specific Goal• Specific Practice• Typical Work Product• Sub Practice• Generic Goal• Generic Practice• Generic Practice Elaboration• Process• Mission Statement• Goal• Activity• Benefit• Critical Success Factor• Key Performance Indicator• Further Specific Informative

Components• Method• Practice• Value• Feature• Process

6 QAPs were analysed Similar elements are present in the QAPs and

processes• Process, process description, activity, process

activity, activity description and task are proportional to the activity element of processes.

• Documentation requirements and typical work products are proportional are similar to inputs and outputs.

• ... Element which have no similarities to process

elements are also present.• Such elements are eg. benefits, critical success

factors, features or key performance indicators in ITIL.

• Will be difficult to convert ISO chapters, sentences...

Analising the structure and content further well-known quality approaches and methods;

Analysing process modelling languages, models and methods.

Selecting the main elements to be used for the meta-model

Examining information loss during transformations.

Testing the solution in practice and refine the meta-model

…

This project has been supported by BME (IT)2 (BME Innovation and Knowledge Centre of Information Technology) within the frame of Peter Pázmány Programme, National Office for Research and Technology, Hungary.

Required activity

A possible activity

Required artifact2

Required artifact1

Possible artifact1

Possible artifact2

Elements:• Chapter• Subchapter• Sub-subchapter• Guideline for ISO 9001

(in simple sentences)

Elements:• Chapter / process

activity• Subchapter /sub-

activity• Sub-sub-activity• Activity description

QAPs focuses on: Suppliers Customers Configuration

management Change management SW Life cycle Coding Verification Validation Project Management Project tracking Requirements life PPQA …

• Differences in:– approach– elements– terminology

• Common:• Giving a solution

for the problems faced

Real world - things and/or phenomena interesting for actors (modelers and users)

View - understanding of the real world involved in the process (contains elements considered meaningful to the situation)

Description – Externalization of the cognitive (internal) view. Eg. verbal descriptions, transcripts, drawings.

Representation – formalized, model-based description

Understanding – user’s cognitive interpretation of the representation

Theory – underlying “inspiration”

Model – “lens for the mind”, filters and shapes the world is seen

Language – grammar and vocabulary of the model

Perception – The individual’s process of viewing and understanding of the real world within their own context

Elicitation – The process of extracting the meaningful description from an individual or a group of individuals

Analysis – The process of “filtering” the description through the theoretically-based model and language of a particular mindset

Interpretation - The process of understanding the representation, putting it back into the original context.

Implementation - The process of cycling the representation back to create new representations and interpretations. For example, creating a database implementation from an ER diagram.

Quality is achieved when there is a high degree of correspondence between the real world and the actor’s view

of the real world (perceptual quality)

actor’s view and the elicited description (descriptive quality)

description and representation (semantic quality)

representation and language (syntactic quality)

representation and understanding (representation must be legible and explainable: pragmatic quality)

understanding and view (inferential quality)▪ Correspondence between inferences

(conclusions) made from understanding the representation and those made from the view of the real world

CMMI Change Management CM SG 2 Track and Control Changes

Changes to the work products under configuration management are tracked and controlled.

The specific practices under this specific goal serve to maintain the baselines after they are established by the specific practices under the Establish Baselines specific goal.

SP 2.1 Track Change Requests ▪ Track change requests for the configuration items.

SP 2.2 Control Configuration Items ▪ Control changes to the configuration items.

ISO 9001:2000 Change Management 4.2.3 Control of documents

Documents required by the quality management system shall be controlled. Records are a special type of document and shall be controlled according to the requirements given in 4.2.4.

7.3.7 Control of design and development changes B: The changes shall be reviewed, verified and validated, as

appropriate, and approved before implementation. C: The review of design and development changes shall include

evaluation of the effect of the changes on constituent parts and product already delivered.

D: Sentence Records of the results of the review of changes and any necessary actions shall be maintained (see 4.2.4).

7.5.3 Identification and traceability A: Where appropriate, the organization shall identify the product by

suitable means throughout product realization. C: Where traceability is a requirement, the organization shall control

and record the unique identification of the product.

ITIL Change Management Goal : Ensure that standardized methods and procedures

are used for efficient and prompt handling of all changes, in order to minimize the impact of Change-related incidents upon service quality, and consequently to improve the the day-to-day operations of the organization

Input : RFCs, CMDB, Forward Schedule of Changes(FSC) Activities

Filtering changes Managing changes and the change process Chairing the CAB and CAB/EC Reviewing and closing RFCs Management reports

Required activity

A possible activity

Required artifact2

Required artifact1

Possible artifact1

Possible artifact2

Flow Objects Events Activities Gateways

Connecting Objects Sequence Flow Message Flow Association

Swimlanes Pool Lane

Artifacts Data Objects Group Annotation

Before modeling we need to understand the connected elements, requirements A matrix can be built for extracting the

process elements

www.itpcommerce.com