The Software Process

1
CHAPTER 2
THE SOFTWARE PROCESS
2
Overview

• Client, Developer, and User
• Requirements Phase
• Specification Phase
• Design Phase
• Implementation Phase
• Integration Phase
• Maintenance Phase
• Retirement
• Problems with Software Production Essence and
  Accidents

3
The Software Process

• The software process is the way we produce
  software. It incorporates the
• life-cycle model
• CASE tools
• The individuals building the software

4
Terminology

• Systems analysis
• Requirements specifications phases
• Operations mode
• Maintenance
• Design
• Architectural design, detailed design
• Client, developer, user
• Internal software development
• Contract software development (outsourcing)

5
Testing Phase?

• There is NO testing phase separately
• Testing is an activity performed throughout
  software production
• Verification
• Performed at the end of each phase
• Validation
• Performed before delivering the product to the
  client

6
Documentation Phase?

• There is NO documentation phase separately
• Every phase must be fully documented before
  starting the next phase
• Postponed documentation may never be completed
• The responsible individual may leave
• The product is constantly changingwe need the
  documentation to do this
• The design (for example) will be modified during
  development, but the original designers may not
  be available to document it

7
Requirements Phase

• Assumption
• The software being considered is economically
  justifiable
• Concept exploration
• Determine what the client needs, not what the
  client wants
• Determine what constraints exist
• Deadline
• Reliability
• Object code size (e.g., for small embedded
  systems)
• Cost
• Functionality of the product is successively
  refined and analyzed for technical feasibility
  and financial justification

8
Requirements Phase Testing

• Frequently, the clients do not know exactly what
  they need
• Rapid prototyping is often used to solve this
  problem
• Rapid prototype - a software that is quickly put
  together that incorporates much of the
  functionality of the target product
• Does not show the aspects generally invisible to
  the client
• More on this in Chapter 10

9
Software Quality Assurance (SQA)

• The role of SQA group
• Ensures that the delivered project is what the
  client ordered and that the product has been
  developed correctly
• SQA group is involved from the beginning of
  software development
• Moving Target Problem
• The client changes the requirements during
  development
• Keeps changing his/her mind!

10
Requirements Phase Documentation

• Rapid prototype with the records of discussion,
  OR
• Requirements document
• Must be thoroughly checked by the client, users
  and the development team
• Finally, SQA checks it

11
Specification Phase

• Specifications document (specifications)
• Explicitly describes the functionality of the
  product
• Specifies the inputs and the outputs
• Legal contract document
• Must not have phrases like suitable, enough,
  optimal, or 98 complete

12
Specification Phase (contd)

• Specifications must not be
• Ambiguous
• Incomplete
• Contradictory
• Once the specifications have been signed off
• The Software Product Management Plan (SPMP) is
  drawn up
• This is the earliest possible time for the SPMP
• Shows the tasks, which members of the development
  team are involved in each task, and deadlines for
  completing each task

13
Specification Phase (contd)

• SPMP
• Includes the deliverables (what the client is
  going to get) and the milestones (when the client
  gets them)
• Describes the software process, life-cycle model,
  structure of development team, project
  responsibilities, managerial objectives and
  priorities, techniques and CASE tools used,
  detailed schedules, budgets, resource allocations
• The most important in SPMP are time and cost
  estimates

14
Specification Phase Testing

• Traceability of specification document
• Must be able to trace every statement in the
  spec. document to a statement made by the client
  during the requirements phase
• Review
• To determine if the specs are correct
• Spec team and client participate with SQA member
  being the chair
• Check the SPMP by SQA group

15
Specification Phase Documentation

• Specification document (specifications)
• SPMP

16
Design Phase

• Specificationwhat
• Designhow
• Retain design decisions
• When a dead-end is reached
• For the maintenance team
• Ideally, the design should be open-ended
• Architectural design
• Decompose the product into modules
• Detailed design
• Design each module data structures, algorithms

17
Design Phase Testing

• Traceability
• Every part of the design can be linked to a
  statement in the specification document
• Review
• By the design team and the SQA group (no client)

18
Design Phase Documentation

• Design
• Architectural design
• Detailed design

19
Implementation Phase

• Implement the detailed design in code

20
Implementation Phase Testing

• Code Review
• The programmer explains the code to the review
  team, which includes a SQA member
• Test cases
• Informal testing (desk checking)
• Formal testing (SQA)

21
Implementation Phase Documentation

• Source code
• Must have suitable comments
• Test cases (with expected output)

22
Integration Phase

• Combine the modules and check the product as a
  whole
• Modules can be integrated
• All at once or one at a time
• Top to bottom in the module interconnection
  diagram or bottom to top

23
Integration Phase Testing

• Product testing
• By the integration team and SQA
• Acceptance testing
• By the client
• The software is delivered to the client, who
  tests it on the actual hardware using actual data

24
Integration Phase Documentation

• Commented source code
• Test cases for the product as a whole

25
COTS Software

• Commercial off-the-shelf (COTS)
• Shrink-wrapped software
• Nowadays, COTS software is often downloaded over
  the Internet
• Click-wrapped software
• Alpha testing alpha version to selected
  possible clients
• Beta testing beta version (corrected alpha
  version) testing -gt final version

26
Maintenance Phase

• Maintenance
• Any change once the client has accepted the
  software
• The most money is devoted to this phase
• The problem of lack of documentation

27
Maintenance Phase Testing

• Must make sure that the new changes have been
  implemented correctly
• Regression testing
• Testing the modified product against previous
  test cases

28
Maintenance Phase Documentation

• Record of all changes made, with reasons
• Regression test cases

29
Retirement

• 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 changedit may be cheaper to
  rewrite the software from scratch than to modify
  it
• True retirement is a rare event

30
Process-Specific Difficulties

• Does the product meet the users real needs?
• Is the specification document free of
  ambiguities, contradictions, and omissions?

31
Inherent Problems of Software Production

• Hardware has inherent limits
• So does software
• No Silver Bullet Fred Brooks, 1986
• Complexity
• Conformity
• Changeability
• Invisibility
• Aristotelian categories
• Essence difficulties inherent in the nature of
  s/w
• Accidents difficulties encountered in development

32
Complexity

• Software is far more complex than hardware
• Traditional abstraction will not work
• We cannot understand the whole, so we cannot
  understand any part
• Management is difficult
• Maintenance is a nightmare (documentation, too)

33
Conformity

• Type 1 Existing gold refinery
• Type 2 New gold refinery

34
Changeability

• Software is easier to change than hardware
• Pressure to change
• Reality
• Useful software
• Easier to change
• Software has a long lifetime (15 yrs)
  compared to hardware (4 yrs)

35
Invisibility

• Software is invisible and unvisualizable
• Complete views are incomprehensible
• Partial views are misleading
• However, all views can be helpful

36
Is There a Silver Bullet?

• What about
• High-level languages
• Time sharing
• CASE tools
• These are useful but do not solve the intrinsic
  problems
• We have experienced
• 6 annual productivity increase
• But, no silver bullet (order-of-magnitude
  increase) is possible
• Read Chapter 2 (except sections on CMM)