CTIS 359 PRINCIPLES OF SOFTWARE ENGINEERING

1
CTIS 359 PRINCIPLES OF SOFTWARE ENGINEERING

• WEEK 14
• SOFTWARE PROCESS IMPROVEMENT
• (Chapter 28 of the Textbook)

2
Quiz 3 Final

• Quiz 3 is postponed to 21 December 2006
• Multiple Choice
• Final will most probably be on 8-9-10 January
  2007
• Multiple Choice

3
OBJECTIVES

• To explain the principles of software process
  improvement
• To explain how software process factors influence
  software quality and productivity
• To explain how to develop simple models of
  software processes
• To explain the notion of process capability and
  the CMMI process improvement model
• To intoduce ISO/IEC 15504 international standard
  for process assessment

4
Software Quality Process Improvement

• Quality of the development process? Quality of
  the software product
• SPI (Software Process Improvement)
• is one way of enhancing the quality of their
  software

5
PROCESS IMPROVEMENT

• Understanding existing processes and introducing
  process changes to improve product quality
  (reduce the of defects delivered)
• ALSO reduce costs, or accelerate schedules.
• Most process improvement work so far has focused
  on defect reduction. This reflects the increasing
  attention paid by industry to quality.
• However, other process attributes can also be the
  focus of improvement.

6
PROCESS ATTR. and CHARAC.
Not possible to OPTIMIZE ALL attributes
SIMULTANEOUSLY Ex rapidity vs visibility
7
Process Improvement

• NOT simply adopt particular method, tool, or
  model of process used elsewhere.
• COMMON factors LOCAL ORGANIZATIONAL factors

8
PROCESS IMPROVEMENT CYCLE
9
PROCESS IMPROVEMENT STAGES

• Process measurement
• Attributes of the current product or project are
  measured. These are a baseline for assessing
  improvements.
• Process analysis
• The current process is assessed and bottlenecks
  and weaknesses are identified.
• Process change
• Changes to the process that have been identified
  during the analysis are introduced

10
PROCESS AND PRODUCT QUALITY

• SPI is based on the assumption that the quality
  of the product depends on its development
  process.
• A good process is usually required to produce a
  good product.
• For manufactured goods, process is the principal
  quality determinant.
• Deming (others) introduced the idea of SPC.
• SPC Reduce the of product defects by PI until
  it is REPEATABLE.
• For design-based activity, other factors are also
  involved especially the capabilities of the
  designers.

11
PRINCIPAL PRODUCT QUALITY FACTORS
Ex For small projects
Ex For large projects
Influence of these factors depend size and type
of the project
12
PROCESS CLASSIFICATION

• Classfied degree of formality, type of the
  product, size of org. and etc.
• Informal Processes
• No defined process model. Development team chose
  their own way of working.
• Managed Processes
• Defined process model which drives the
  development process.
• Methodical Processes
• When some defined dev. methods are used, these
  processes benefit from CASE tool support.
• Improving Processes
• Processes that have inherent improvement
  objectives with budget and procedures.

13
Process Applicability
14
PROCESS TOOL SUPPORT
Most SP have some CASE tool support so they are
supported proccesse
15
PROCESS IMPROVEMENT STAGES

• Process measurement
• Process analysis
• Process change

16
PROCESS MEASUREMENT

• Process Measurements are QUANTATIVE data about
  the software process.
• Measure
• Process and product attributes
• Personal process (PSP) ? small-scale
• TSP

17
PREDICTOR AND CONTROL METRICS
For SPI, you should measure product quality as
well
Process metric average time required to repair
reported defect
Product metric average length of identifiers in
a program
18
PROCESS MEASUREMENT

• Wherever possible, quantitative process data
  should be collected.
• However, where organisations do not have clearly
  defined process standards this is very difficult
  as you dont know what to measure. A process may
  have to be defined before any measurement is
  possible.
• Process measurements should be used to assess
  process improvements.
• But this does not mean that measurements should
  drive the improvements. The improvement driver
  should be the organizational objectives.

19
PROCESS MEASUREMENT

• Three classes of process metric
• The time for a particular process to be completed
  ex t spent for process X
• The resources required for a particular process
  ex travel costs, total effort
• The of occurrences of a particular event ex
  of defects discovered in the code inspection

20
PROCESS IMPROVEMENT STAGES

• Process measurement
• Process analysis and modelling
• Process change

21
PROCESS ANALYSIS AND MODELING

• Process analysis
• The study of existing processes to understand the
  relationships between parts of the process and to
  compare them with other processes.
• Process modelling
• The documentation of a process which records the
  tasks, the roles and the entities used
• Process models may be presented from different
  perspectives.
• Simplifies views of software processes
• Activities
• Outputs, Inputs

22
PROCESS IMPROVEMENT STAGES

• Process measurement
• Process analysis and modelling
• Process change

23
PROCESS CHANGE

• Involves making modifications to existing
  processes.
• This may involve
• Introducing new practices, methods or processes
• Changing the ordering of process activities
• Introducing or removing deliverables
• Introducing new roles or responsibilities.
• Change should be driven by measurable goals.

24
PROCESS CHANGE PROCESS
25
PROCESS CHANGE

• If you are a project manager/director,
• you have to be sensitive to the feelings of the
  people in your team when introducing process
  change
• People feel threatened by change and concerned
  that
• lose their jobs
• unable to cope with the new process
• Solution User involvement

26
CMM(I) FRAMEWORK

• Mid-1980s Software Engineering Institute
  initiated a study of ways assessing capabilities
  of the contractors
• Mid-1990s Capability Maturity Model
• Tremendous impact on SWE industry
• CMM the early 1990s.
• P-CMM
• SPICE (assesmentPI)
• Revised maturity framework (CMMI) introduced in
  2001.

27
CMMI

• Complex but simlified version
• Process Areas (4 Groups of 24 PAs)
• Goals desirable state
• Practices ways of achieving goals

28
CMMI PROCESS AREAS 12
29
CMMI PROCESS AREAS 34
30
CMMI (6 scales)

• Not performed goal ? PA not satisfied
• Performed goal ? PA satisfied
• Managed Documented plan resource man. and
  process monitoring
• Defined Measurments must be collected and used
  for future projects
• Quantitatively Managed Use SPC and quantitative
  methods.
• Optimizing Product and process metrics are used
  for SPI

31
STAGED CMMI MODEL

• Comparable with the software CMM.
• 5 levels
• Each maturity level has process areas and goals.
• Ex the process area associated with the managed
  level include
• Requirements management
• Project planning
• Project monitoring and control
• Supplier agreement management
• Measurement and analysis
• Process and product quality assurance.
• Configuration Management

32
CMM STAGES

• Initial
• Essentially uncontrolled
• Repeatable
• Product management procedures defined and used
• Defined
• Process management procedures and strategies
  defined and used
• Managed
• Quality management strategies defined and used
• Optimising
• Process improvement strategies defined and used

33
STAGED CMMI MODEL
34
CONTINUOUS CMMI MODEL

• No discerete levels for organization
• This is a finer-grain model that considers
  individual or groups of practices and assesses
  their use.
• The maturity assessment is not a single value but
  is a set of values showing the organizations
  maturity in each area.
• The CMMI rates each process area from levels 1 to
  6.
• The advantage of a continuous approach is that
  organizations can pick and choose process areas
  to improve according to their local needs.

35
CMM STAGES

• Practices associated with model levels
• Companies could be using practices from different
  levels at the same time but if all practices from
  a lower level were not used, it was not possible
  to move beyond that level
• Discrete rather than continuous
• Did not recognize distinctions between the top
  and the bottom of levels
• Practice-oriented
• Concerned with how things were done (the
  practices) rather than the goals to be achieved.

36
CMMI MODEL

• An integrated capability model that includes
  software and systems engineering capability
  assessment.
• The model has two instantiations
• Staged where the model is expressed in terms of
  capability levels
• Continuous where a capability rating is computed.

37
ISO/IEC 15504

• ISO 15504 was initiated in 1993 as the SPICE
  (Software Process Improvement and Capability
  dEtermination) project.
• The project then moved into the International
  Organization for Standardization and the
  International Electrotechnical Commission
  (ISO/IEC)
• The principle of ISO/IEC 15504 is tha the
  assessments of software process cabability will
  yield results which are comparable.
• The goal of 15504 is to create a world standard
  that can be used to link assessment results to
  improvement actions.
• It alllows different assesments models and
  methods (like CMMI) to be used.

38
KEY POINTS

• Process improvement involves process analysis,
  standardization, measurement, and change.
• Process models include descriptions of
  activities, sub-processes, and deliverables.
• The CMMI process maturity model is an integrated
  process improvment model that supports both
  staged and continous process improvement.

39
Measurement Theory

• Absolute All math operations
• Ex 9 students (4 female, 5 male)
• Ratio All math operations
• Ex 5 Ko
• Interval or operations
• Ex 5 Co
• Ordinal No opeartions
• Ex 5-4-3-2-1 notlarinda 10 tane 5, 2 tane 4, ...
• Nominal No operation simply a categorization
• Ex C, C, Java