1. 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 Institute Jos Trienekens, Rob Kusters Technical University of Eindhoven EuroSPI 2008, Dublin

2. 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 …

3. 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.)

4. 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

5. 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 customers 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

6. …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 …

7. 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.) Modeling quality approaches

8. 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

9. The most used and mandatory quality approach: ISO 9001:2000 Quality management systems – requirements Besides ISO 9001:2000, most used approaches are: CMMI & SPICE Further, 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.

11. Elements: Chapter Subchapter Sub-subchapter Requirement in (simple) sentences

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

13. Elements: Process Process Description Activity Task Option Condition Documentation requirement Responsibility

14. 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

15. Process Elements: Purpose Inputs Entry criteria Activities Roles Measures Verification steps Outputs Exit criteria QAP Elements: 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

16. 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

17. 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...

18. 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 …

19. 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. Acknowledgement

20. Required activity A possible activity Required artifact2 Required artifact1 Possible artifact1 Possible artifact2 Thank you for attention! Questions?Contact: kelemen.daniel@cmmi.hu www.sqi.hu www.cmmi.hu

21. Elements: Chapter Subchapter Sub-subchapter Guideline for ISO 9001 (in simple sentences)

22. Elements: Chapter / process activity Subchapter /sub- activity Sub-sub-activity Activity description

23. 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

24. 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 – users cognitive interpretation of the representation

25. Theory – underlying inspiration Model – lens for the mind, filters and shapes the world is seen Language – grammar and vocabulary of the model

26. Perception – The individuals 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.

27. Quality is achieved when there is a high degree of correspondence between the real world and the actors view of the real world (perceptual quality) actors 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

29. 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.

30. 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.

31. 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

32. Required activity A possible activity Required artifact2 Required artifact1 Possible artifact1 Possible artifact2

33. Flow Objects Events Activities Gateways Connecting Objects Sequence Flow Message Flow Association Swimlanes Pool Lane Artifacts Data Objects Group Annotation

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

35. www.itpcommerce.com