CS 450 Chapter 2 The Software Process

1
CS 450 Chapter 2The Software Process

• 2.1-2.8 Real World Software Engineering--Details
  of Phases
• 2.9 There is no Silver Bullet
• 2.10-2.14 Improving the Process

2
The Software Process

• The way a company produces software.
• Varies from one company to another.
• Aim is process improvement -- a better process
  will result in a better product .

3
Three Views of Software

• Client customer who orders software.
• User person(s) who will actually use software.
• Developers producers of software, who attempt to
  meet client specifications and user needs.

4
Planning

• Original project plan -- general time frame for
  completion of each of the phases and product
  delivery.
• Planning continues throughout development -- in
  each phase, detailed scheduling of next phase is
  done.
• personnel assignments
• completion date for each module
• integration schedule

5
Requirements Phase

• Preliminary investigation
• generally what is wanted
• what are the constraints (budget, delivery)
• Successive refinements of requirements
• Rapid prototyping
• Requirements testing
• Software Quality Assurance (SQA) group
• Verify product will meet client/user needs
• Manage change

6
Specification Phase

• Explicitly describes
• functionality -- what the product will do
• constraints (e.g. must run on certain hardware,
  timing constraints ...)
• Project charter or specification document serves
  as contract between developer and client
• Paragraph numbers for cross reference

7
Specification Testing

• Check for and correct
• ambiguities (means different things to different
  people)
• contradictions (different parts of document state
  different requirements)
• incompleteness (not all functionality is
  described)
• Formal review with client

8
Design Phase

• Architectural Design
• broken up into modules
• data structure design
• operations on data determined
• interfaces between modules
• Detailed Design
• design of each module
• Aim for modifiability

9
Design Testing

• SQA Cross reference with requirements to assure
  each one is met.
• Check for
• logic faults
• interface faults
• missing exception handling
• Walk-throughs and reviews with development team

10
Implementation and Integration

• Modules written in self-documenting code and unit
  tested.
• Modules gradually integrated and integration
  tested.
• Product tested before release.
• Acceptance test by client.
• Possible alpha and beta testing (alpha -- at
  developer site beta -- at selected customer
  site(s)).

11
Maintenance

• A high quality product is easily maintainable.
• Maintainability was a factor in design.
• Documentation is complete and up to date.
• Maintenance testing
• Each change is tested
• Product is regression tested (previous tests run
  again in case new errors introduced)

12
Retirement

• Legacy code is common and seldom retired.
  Eventually it may be for reasons such as
• Further maintenance is no longer cost-effective.
• Software is gradually being upgraded to new
  paradigm.
• Product has outgrown its usefulness.

13
No Silver Bullet

• Article by Frederick Brooks
• ... building software will always be hard due
  to difficulties in its intrinsic nature
  (essence)
• however, improved process can solve difficulties
  which surround software production and are not
  part of its nature (accidents)

14
Difficulties in Essence of Software

• complexity due to interaction of components,
  number of possible states grows much faster than
  lines of code.
• conformity must interface with existing
  systems.
• changeability must model changing real world,
  increase functionality, run on new hardware.
• invisibility cannot visualize all aspects at
  once.

15
Breakthroughs that have and will solve accidental
difficulties

• historical high level languages and time
  sharing
• software development environments
• use of off the shelf software and components
• rapid prototyping
• incremental development
• training, encouraging great designers

16
Improving the ProcessCapability Maturity Model
(CMM)

• Internationally recognized rating of quality of
  an organizations software production process
• CMM Levels
• 1 Initial -- no standard process
• 2 Repeatable -- Measurements from past similar
  projects used.
• 3 Defined -- Process fully documented
• 4 Managed -- Goals set for each project
• 5 Optimizing -- Continuous improvement

17
ISO 9000 and SPICE

• International Standards Organization industrial
  quality standards
• Software guidelines are similar, but not
  identical, to CMM
• International trade may require certification as
  ISO 9000 compliant

18
Homework

• Read Chapter 2
• Be prepared to discuss reading and these problems
  pp. 59, 60
• 2.1, 2.6
• 2.10, 2.11
• 2.13