CHAPTER 2 Slide 2.

- The software process

- Improving the Software Process

© The McGraw-Hill Companies, 2002

 Slide 2.2

 Software process is the way we produce software.

 One dimensional VS two dimensional life cycles
 Different software organizations have different
views to SW development
– Documentation intensive vs self-documented
– Intensity of testing


© The McGraw-Hill Companies, 2002

 The unified process (UP) Slide 2.3

 U.P. is an object-oriented methodology

 U.P. is the primary choice today
 U.P. is not “one size fits all”, it is an adaptable
methodology.
 UML is the standard notation for U.P.
 Different models are used in the U.P.
 A Model is a set of UML diagrams
 U.P. is an iterative and incremental model
– As more knowledge about the real-world system being
modeled is gained, the diagrams are made more
accurate (iteration) and extended (incrimination)

© The McGraw-Hill Companies, 2002

 Core workflows of the U.P. Slide 2.4

 Requirement workflow
 Analysis workflow
 Design workflow
 Implementation workflow
 Testing workflow

© The McGraw-Hill Companies, 2002

 The Requirements workflow Slide 2.5

 Aims to :
– determining the client’s needs and constrains
– Analyze client’s requirements (vague, contradictory, etc)
 Domain analysis
– Banking
– Education
– e-commerce
– etc
 Write a business model (cost-effectiveness of the
product)
 Artifacts of the requirements workflow must be
comprehended by the client (i.e. expressed in a
language understood by the client).
© The McGraw-Hill Companies, 2002
 The Analysis workflow Slide 2.6

 Aims to analyze and refine the requirements to

achieve the detailed understanding of the
requirements essential for developing a software
product.
 Specification document (a set of UML diagrams
and descriptions (cost/timeline))
– Descriptions should not include any ambiguity,
contradictions or incomplete information
 Software project management plan (SPMP)
– Deliverables (What)
– Milestones (when)
– Budget (how much)
– Personnel (who will do it)
© The McGraw-Hill Companies, 2002
 The design workflow Slide 2.7

 Aims to refine the artifacts of the Analysis

workflow until the material is in a form that can be
implemented by the programmers.
 Specifications documents spells out What, and the
design shows the How part.
 Must be open-ended to cater for postdelivery
maintenance.

© The McGraw-Hill Companies, 2002

 The implementation workflow Slide 2.8

 Aims to implement the target software product in

the chosen programming language(s).
 Small software products are implemented by
individual designers or programmers.
 Large software products is partitioned into smaller
subsystems implemented in parallel by coding
teams.

© The McGraw-Hill Companies, 2002

 The Test workflow Slide 2.9

 Aims to test implemented product components

individually (unit testing) and in an integrated form
(integration testing).
 Software quality assurance (SQA) group receive
individually tested components for further testing.
 Traceability is important for testing (why?)

© The McGraw-Hill Companies, 2002

 Retirement Slide 2.10

 Good software is maintained

 Sometimes software is rewritten from scratch

– Software is now unmaintainable because
» A drastic change in design has occurred
» The product must be implemented on a totally new
hardware/operating system
» Documentation is missing or inaccurate
» Hardware is to be changed—it may be cheaper to rewrite
the software from scratch than to modify it

 True retirement is a rare event

© The McGraw-Hill Companies, 2002

 Improving the Software Process Slide 2.11

 U.S. Department of Defense initiative

 Software Engineering Institute (SEI)
 The fundamental problem with software
– The software process is badly managed

© The McGraw-Hill Companies, 2002

 Improving the Software Process (contd) Slide 2.12

 Software process improvement initiatives

– Capability maturity model (CMM)
– ISO 9000-series
– ISO/IEC 15504

© The McGraw-Hill Companies, 2002

 Capability Maturity Model Slide 2.13

 Not a life-cycle model

 Set of strategies for improving the software
process
– SW–CMM for software
– P–CMM for human resources (“people”)
– SE–CMM for systems engineering
– IPD–CMM for integrated product development
– SA–for software acquisition
 These strategies are being unified into CMMI
(capability maturity model integration)

© The McGraw-Hill Companies, 2002

 SW–CMM Slide 2.14

 A strategy for improving the software process

– Put forward in 1986 by the SEI
– Fundamental idea:
– Improving the software process leads to
» Improved software quality
» Delivery on time, within budget
– Improved management leads to
» Improved techniques
 Five levels of “maturity” are defined
– Organization advances stepwise from level to level

© The McGraw-Hill Companies, 2002

 Level 1. Initial Level Slide 2.15

 Ad hoc approach
– Entire process is unpredictable
– Management consists of responses to crises
 Most organizations world-wide are at
level 1

© The McGraw-Hill Companies, 2002

 Level 2. Repeatable Level Slide 2.16

 Basic software management

– Management decisions should be made on the
basis of previous experience with similar
products
– Measurements (“metrics”) are made
– These can be used for making cost and duration
predictions in the next project
– Problems are identified, immediate corrective
action is taken

© The McGraw-Hill Companies, 2002

 Level 3. Defined Level Slide 2.17

 The software process is fully documented

– Managerial and technical aspects are clearly defined
– Continual efforts are made to improve quality,
productivity
– Reviews are performed to improve software quality
– CASE tools are applicable now (and not at levels 1 or 2)

© The McGraw-Hill Companies, 2002

 Level 4. Managed Level Slide 2.18

 Quality and productivity goals are set for

each project
– Quality, productivity are continually monitored
– Statistical quality controls are in place

© The McGraw-Hill Companies, 2002

 Level 5. Optimizing Level Slide 2.19

 Continuous process improvement

– Statistical quality and process controls
– Feedback of knowledge from each project to the next

© The McGraw-Hill Companies, 2002

 Summary Slide 2.20

© The McGraw-Hill Companies, 2002