1. The Software Engineering Process
and
The Personal Software Process
(PSP)

2. The Software Engineering Process
The Software Product
The Software Process
The Traditional Approach (SDLC)
Software Process Models
SP Modeling – why, what, how
OO Modeling - UML
Software Process Measurement
Software Process Maturity Model (CMM)
The Personal Software Process (PSP)
Appendix – Application Domains

3. Software Engineering Products and Processes
The software customer wants
quality software products at reasonable prices
The software producer wants
a well managed software production process
that consistently produces quality software
in a cost-effective manner
Some organisations have a defined and managed software engineering process

4. The Software Product Composed of programs, data and documents
Delivers hardware computing potential
Delivers information
Software Product Characteristics
developed or engineered,
not manufactured
doesn’t wear out
most is custom built
Delivers information
transforms data and provides a means for acquiring information
provides a gateway to world-wide information networks

5. The Software Process Definition:
The software product is created as part of the Software Engineering Process
Definition:
the Software Process is a description of the process which guides the software engineers as they work

6. The Software Process
The set of activities which produce a software product
The sequence of steps to develop and maintain software
Sets out the technical and management framework for applying methods, tools and people to the software task

7. The Software Process ... Software Engineering is a
Layered Technology (Diagram Pressman p.21):
Quality Focus - bedrock of SE
commitment to quality
Process – foundation of SE
framework of key processes as: a basis for control of projects; and a context for development & methods
Methods – set of basic SE principles
technical ‘how to’ for building software, including methods for analysis, design, programming, testing etc.
Tools – ideal is an integrated SE environment
automated support for the process and the methods

8. The Software Process ...
There is no ‘right’ or ‘wrong’ software process.
But poor processes reduce the quality or usefulness of the product
Software processes are complex and involve a large number of activities

9. The Software Process ... Generic Phases (Pressman)
Definition Phase focuses on ‘what’
- the methods will include these tasks:
system or information engineering
software project planning
requirements analysis
Development Phase focuses on ‘how’
software design
code generation
software testing
Maintenance Phase focuses on the change of the software due to correction, evolution & improvement.

10. The Software Process ...
Has a common process framework containing (Diagram Pressman p.24):
framework activities - for all software projects
work tasks
project milestones
software work products and deliverables
quality assurance points
umbrella activities - occur throughout the process
software quality assurance
software configuration management
software metrics or measurement

11. The Software Process ...
To solve SE problems a team of software engineers develops a strategy that includes the process, methods and tool layers, and the generic phases.
This strategy is called a Software Process Model
The process model is based on the nature of the application, & the methods, tools and deliverables.

12. Traditional Model Software Development Life Cycle (SDLC) (Waterfall or Linear Sequential Model)
SDLC Phases:
1. System Feasibility
Aims to establish the technological, economic, social feasibility of the proposed system.
2. Software Requirements
Requirements are the functions and features of software desired by the customer.
Requirements are validated by obtaining the customer's agreement to the specs.
3. Software Plans
Software planning is concerned with How much, How long? What resources and skills will be needed? When? Estimating, scheduling, budgeting.

13. SDLC Phases ... 4. Product Design & Detailed Design
Concerned with how to meet the requirements.
Design documents are verified - checked against requirements
5. Coding and Module Testing
Programming, implementation
Producing operational models
Testing them

14. SDLC Phases ... 6. Integration Testing 7. Implementation
Testing the whole product
7. Implementation
Put into operation for the first time.
Create data files / databases, user training,
Parallel running, acceptance testing.
8. Operation & Maintenance
As we have seen, covers many different activities!

15. Deficiencies in the Traditional Model
Gross oversimplification
In reality phases are not clear-cut.
Defects in the products of earlier phases are discovered in later phases.
Best approach is an iterative one which feeds the defect information back to the earlier phase.
Documenting is a nightmare - detection of a design fault during coding - do we go back and revise the design documents?
Or are they an historical artifact?

16. SDLC - the reality Overlapping phases
Large, complex systems are usually broken into subsystems and other smaller components
Each subsystem may have its own mini-lifecycle.
In reality there will be a continuous stream of change requests.

17. Software Process Models
1. Linear Sequential or ‘Waterfall’ Model
2. Prototyping Model
3. Rapid Application Development Model
4. Evolutionary Development:
Incremental Model
Spiral Model
Concurrent Development Model
5. Component-Based Development Model
6. Formal Methods Model
7. Fourth Generation Techniques Model
8. Extreme Programming Model

18. Software Process Models ...
Component-Based Development Model
OO technologies provide the framework
Focus is on the reuse of components (Classes)
The Unified Software Development Process is the main component-based development model
The Unified Development Model (UML) is the notation used to define the system components
Fourth Generation Techniques Model
When coupled with UML may become the dominant approach to software development.

19. Software Process Models ...
Process Technology
The process models
have different strengths and weaknesses
are adapted for use by each particular project team
are aided by process technology tools
Process Technology Tools allow:
Organisations to build automated models of the process
Team monitoring and control of the SE tasks
Each team member to plan individual project tasks

20. Software Process Modeling
Modeling Requirements
1. Why? - do we need to model software processes and their components?
2. What? - aspects and objects of the software process do we need to model?
3. How? - are we going to model them?

21. SP Modeling - Why? The over-riding purpose
of software process modeling is
software process
understanding and management.

22. SP Modeling - Why?... Modeling levels Flexibility
- to allow a general view as well as a more detailed view of the process
- to allow for refinement, explosion, elaboration
- to allow managers to see the woods as well as the trees
Flexibility
- to allow for model flexibility and extensibility

23. ‘You cannot control what you cannot measure’
SP Modeling - Why?...
Enaction
- to allow both project managers and developers to use the models, supported in a computer-aided manner.
Metrication (measurement)
‘You cannot control what you cannot measure’
- Tom de Marco

24. SP Modeling - What? Products Activities
Important to model requirements and design documents - the evolving product;
Products can be measured - size, complexity, quality...
Activities
Consume resources and lead to the development of products

25. SP Modeling - What? ... Events Decisions
Important occurrences on the project time-line.
e.g.
Project start;
Approval to produce a detailed proposal;
Requirements acceptance;
Decisions
Branch points in the software process
Undertake prototyping to reduce risk of inadequate requirements.

26. SP Modeling How? Software Process Selection
More advanced topic
In practice most companies select and customise a model, supported by a CASE tool
Software Process Selection
Issues affecting process selection are related to the particular application domain

27. Some Application Domains (refer Appendix)
Data-centred systems
Real-time systems
Systems programs
Life/mission-critical systems
Scientific/engineering systems
Spatial information systems (GIS)
Knowledge-based systems
Networks/data comms including intranet, internet, WAN, LAN, e-commerce
Other including CAD/CAM, office automation

28. OO Modeling Concepts Unified Modeling Language (UML)
Static Model – the Class Diagram or Class Chart
Classes showing specification by class contract
Grouping into clusters/subsystems
Relations: client/supplier and inheritance - fundamental
Dynamic models
Identification of events
Scenarios of communicating objects
State charts for more dynamic parts of the system
Unified Modeling Language (UML)
is the international standard 12

29. Software Process Measurement
or Software Process Metrics
the gathering of quantitative data about the software process
does not measure the product quality
Classes or types of Process Metrics
time taken for the process to be completed
resources required for a particular process
the number of occurrences of a particular event

30. Software Process Maturity Measurement
The model to measure the maturity of an organisation is:
The SEI Process Maturity Model
or The Capability Maturity Model(CMM)
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Managed
Level 5: Optimizing
At each level, Key Process Areas (KPAs) provide goals

31. The SEI Process Maturity Model ...
Level 1: Initial
process is ad hoc and sometimes chaotic
few processes defined
success depends upon individual effort
Key Process Areas (KPAs)
none

32. The SEI Process Maturity Model ...
Level 2: Repeatable
basic project management processes defined
process discipline in place to repeat successes
Key Process Areas
software configuration management
software quality assurance
software subcontract management
software project tracking
software project planning
requirements management

33. The SEI Process Maturity Model ...
Level 3: Defined
process is documented, standardised and integrated into a standard software process
all projects use this standard software process
Key Process Areas
peer reviews
intergroup coordination
software product engineering
integrated software management
training program
software process definition and focus

34. The SEI Process Maturity Model ...
Level 4: Managed
detailed measures of software process and product quality are collected
process and products are quantitatively controlled
Key Process Areas
quality management
qualitative process management

35. The SEI Process Maturity Model ...
Level 5: Optimizing
continuous process improvement is enabled
there is quantitative feedback from the process and from piloting innovative ideas and technologies
Key Process Areas
process change management
technology change management
defect prevention

36. The SEI Process Maturity Model ...
or Capability Maturity Model (CMM)
is the best available description of the goals, methods and practices needed for the industrial practice of software engineering
But how do we do this in the classroom?
this is the role of the PSP
i.e. the Personal Software Process

37. The Personal Software Process or PSP
PSP Objectives:
To introduce students to a process-based approach to developing software
To show students how to measure, estimate, schedule, and track their work
To show students how to improve the quality of their programs
In general PSP improves quality and productivity
The time saved in testing because of better quality reduces time across the project by 20-40%

38. The Personal Software Process or PSP
a self improvement process
designed to
help you be a better software engineer
help you control, manage and improve the way you work
requires research and study of your work
needs personal motivation to pay off

39. The Personal Software Process
PSP helps you to:
manage your work & assess/build your talents/skills
plan better
track your performance precisely
measure the quality of your software products
- as a framework for determining:
why you make errors and how you find them
the quality of your reviews
the types of errors you make

40. The Personal Software Process
PSP has a maturity framework like CMM
- some KPAs are removed eg training program
Structure:
PSP0: establish a measured performance baseline
PSP1: make size, resource and schedule plans
PSP2: learn defect and yield management
PSP3: scale up PSP methods to larger projects

41. The Personal Software Process
Baseline Process - PSP0
includes some basic measurements and a reporting format
the process you currently use to write software but enhanced to provide measurements
PSP0.1 - PSP0 enhanced by adding:
a coding standard
size measurement and size counting standard
process improvement proposal (PIP)

42. The Personal Software Process
The Personal Planning Process (PSP1)
adds planning steps to PSP0
test report
size and resource estimation
PSP1.1
establishes a performance rate for planning
PSP1 enhanced by adding
task planning
schedule planning

43. The Personal Software Process
The Personal Quality Management Process (PSP2)
adds review techniques to PSP1 to help you find defects early
design reviews
code reviews
PSP2.1
establishes design completeness criteria
design templates

44. The Personal Software Process
A Cyclic Personal Process (PSP3)
for large programs e.g. 10,000 LOC
subdivide into PSP2-sized modules
enhance the base module in iterative cycles
in each iteration do a complete PSP2 including design, code, compile, test
effective scale up from base module to large program if each increment is of a high quality

45. The Personal Software Process
The parts of PSP you will be using:
PSP0 for Stage 1 of your assignment
PSP1 & 2 for Stages 2 & 3 of your assignment
The following documents:
Time Log, Defect Log and Project Summary
- use manually (refer Attachments) or
- use electronically in PASEWEB
(Personal Assistant for Software Engineers)
Process scripts and instructions
(refer Attachments)

46. The Personal Software Process
The PSP uses 3 types of measures:
Effort, Size and Defects
Effort measurement
Measured in minutes
Students keep records of time spent on tasks
Interruption time is recorded and subtracted
Size measurement
Size will be measured in number of lines of code and FP
Defect measurement
Students record changes to correct an error
Fix time and defect type is recorded

47. The Personal Software Process
PSP Logic - based on the Principles:
Need measured historical data for effective planning
A defined process can improve working efficiency
Defined personal processes should fit the individual skills of the software engineer
Continuous process improvement is enhanced by rapid and explicit feedback
Competent work is possible when professionals know the basic methods of their field and practice them with discipline.

48. Summary
The CMM sets out the principal practices for managing the processes in large-scale software development
The PSP sets out the principal practices for defining, measuring and analysing an individual’s own processes

49. Appendix – Application Domains
Data-Centred Systems
Many business applications - payroll, inventory control
Often centred on a database, with user interaction objects, and ability to generate customised reports.
Essentially passive - you do things to the data periodically.

50. Application Domains ... Real-time Systems
Air-line reservations, air-traffic control, nuclear power station
Reactive. Things are happening all the time to change the state of the system.
Parallelism, inter-process communication
States and events
Direct real-world interfacing
Concern with messages, signals, control parameters.

51. Application Domains ... Systems Programs
Concerned with the control of computer resources - memory, disk, ports, buses.
Software is Operating systems, device drivers, IOCS, compilers etc.
Shares many of the concerns of real-time systems.
In addition has terms like interrupts, masks, registers etc. which relate specifically to computer resource allocation and control

52. Application Domains ... Life/mission-critical systems
Heart monitor, air-traffic control, rocket launch, nuclear power plant...
Typically real-time, often embedded
Extra-high reliability requirement
e.g. Department of Defense specifies the quality standards, and languages to be used in development of its systems.

53. Application Domains ... Scientific/Engineering
Concerned with scientific and engineering calculations
Evaluation of complex formulae
Sophisticated numerical or statistical methods.
Low on input and output
Spatial Information Systems (GIS)
Mass data storage
Map coordinate digitization, scanning and image processing, relational DB, SQL

54. Application Domains ... Knowledge-based Systems
Knowledge acquisition, building a knowledge base, expert system shell, inference mechanisms.
Networks/Data Communications
Including distributed components and intranet, internet, WAN, LAN
Other
Office automation, EDI, CAD/CAM