zádor dániel kelemen budapest university of technology and economics, sqi - hungarian software...
TRANSCRIPT
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