Overview - Software Lifecycles, Processes, Methods and Tools

1
Overview - Software Lifecycles, Processes,
Methods and Tools

• Software lifecycle basics
• Software lifecycles
• build-and-fix
• waterfall
• rapid prototype
• incremental
• spiral
• Process improvement
• CMM ISO9000
• Methods and Tools

2
Software Lifecycle

• A series of steps through which a software
  product progresses
• Lifetimes vary from days to months to years
• Consists of
• people!
• overall process
• intermediate products
• stages of the process

3
Software Production Personnel

• Client
• individual or organization that wants a product
  to be developed
• Developer(s)
• (members of) an organization producing the
  product
• User(s)
• person who authorizes the client to contract the
  developer
• person(s) who will utilize software in operation
• internal software development vs external
  contract
• and all the shades of gray!

4
What is a process?

• Device for producing a product (getting the job
  done)
• Level of indirection
• Process description describes wide class of
  instances
• Humans create process descriptions to solve
  classes of problems
• Thus
• software processes are devices for creating and
  evolving software products
• work for you?

5
Intermediate Software Products

• Objectives
• Demarcate end of phases
• Enable effective reviews
• Specify requirements for next phase
• Form
• Rigorous
• Machine processible (highly desirable)
• Content
• Specifications, Tests, Documentation

6
Phases of a Software Lifecycle

• Standard Phases
• Requirements Analysis Specification
• Design
• Implementation and Integration
• Operation and Maintenance
• Change in Requirements
• Testing throughout
• Phases promote manageability and provide
  organization

7
Requirements Analysis and Specification

• Problem Definition gt Requirements Specification
• determine exactly what client (and user) wants
  and process constraints
• develop a contract with client
• what task the product is to do
• Difficulties
• client asks for wrong product or developer knows
  better (want vs need)
• client is computer/software illiterate or
  developer domain illiterate
• specifications may be ambiguous, inconsistent,
  incomplete
• Validation
• extensive specification reviews check that
  requirements satisfy client wants
• look for ambiguity, consistency, incompleteness
• check for feasibility, testability
• develop system/acceptance test plan

8
Design

• Requirements Specification gt Design
• develop architectural design (system structure)
  decompose software into modules with module
  interfaces
• develop detailed design (module specifications)
  select algorithms and data structures
• maintain record of design decisions and
  traceability
• how the product is to do its task
• Difficulties
• miscommunication between module designers
• design may be inconsistent, incomplete,
  ambiguous
• Verification
• extensive design reviews (inspections with
  checklists) to determine that design conforms to
  requirements
• check module interactions
• develop integration test plan

9
Implementation and Integration

• Design gt Implementation
• implement modules and verify they meet their
  specifications
• combine modules according to architectural design
• how the product does its task
• Difficulties
• module interaction errors
• order of integration has a critical influence on
  product quality and productivity
• Verification and Testing
• extensive code reviews (inspections with
  checklists) to determine that implementation
  conforms to requirements and design
• develop and test on unit/module test plan focus
  on individual module functionality
• test on integration test plan focus on module
  interfaces
• test on system test plan focus on requirements
  and determine whether product as a whole
  functions correctly

10
Operation and Maintenance

• Operation gt Change
• maintain software after (and during) user
  operation
• integral part of process
• determine whether product as a whole still
  functions correctly
• Difficulties
• design not extensible
• lack of up-to-date documentation
• personnel turnover
• Verification and Testing
• extensive review to determine that change is
  made correctly and all documentation updated
• test to determine that change is correctly
  implemented
• test to determine that no inadvertent changes
  were made to compromise system functionality
  (check that no affected software has regressed)

11
Build-and-Fix
Build First Version
Modify until Client is satisfied
Operations Mode
Retirement
12
Waterfall
Req. Change
Operations
Retirement
13
Rapid Prototyping
Req. Change
Operations
Retirement
14
Incremental
For each build Perform detailed design,
implement. Test. Deliver.
Operations
Retirement
15
The Spiral Model Boehm,1988
16
(Extremely) Simplified Spiral Model
Risk Assessment
Req. Change
Risk Assessment
Risk Assessment
Add a Risk Analysis step to each phase!
Operations
Retirement
17
Capability Maturity Model (CMM) Watts
Humphrey,1989

• CMM is not a software lifecycle model ...
• but a strategy for improving the software process
  regardless of the process model followed
• Basic premise the use of new software methods
  alone will not improve productivity and quality,
  because software management is, in part, the
  cause of problems
• CMM assists organizations in providing the
  infrastructure required for achieving a
  disciplined and mature process
• Includes
• technical aspects of software production
• managerial aspects of software production

18
Capability Maturity Model (continued)

• Five maturity levels
• 1. initial ad hoc process
• 2. repeatable process basic project management
• 3. defined process process modeling and
  definition
• 4. managed process process measurement
• 5. optimizing process process control and
  dynamic improvement
• to move from one stage to the next, the SEI
  provides a series of questionnaires and conducts
  process assessments that highlight current
  shortcomings

19
ISO 9000

• Further attempt to improve software quality based
  on International Standards Organization (ISO)
• ISO 9000 series of five related standards
• within ISO 9000 standard series ISO 9000-3
  focuses on software and software development
• Basic features
• stress on documenting the process in both words
  and pictures
• requires management commitment to quality
• requires intensive training of workers
• emphasizes measurement
• Adopted by over 60 countries (USA, Japan,
  European Union, ...)
• To be ISO 9000 compliant, a companys process
  must be certified

20
Software Methods and Tools

• Methods provide a means or procedure for
  accomplishing a task
• Tools are devices for performing some task
• analytical tools
• software tools
• Methodology guides the proper use of methods and
  tools
• Process helps to enact a methodology
• Environments are a synergistic collection of
  tools with process support

21
Analytical Tools

• Problem solving techniques that help in software
  development
• cost-benefit analysis
• compare expected benefits against estimated costs
• stepwise refinement
• divide and conquer
• abstraction
• focus on some important property and ignore (for
  the time being) irrelevant details
• Analytical tools underlie many software
  development methods

22
Software Tools

• Software tools are an automated implement for
  performing a task
• Tools facilitate work because they are
• fast, immune to boredom and "cheating"
• Actual Software Tools are ...
• powerful, effective, convenient, natural,
  reliable, robust
• Most software development tools are not
• exceptions compilers, editors, loaders
• these have been polished, refined, and debugged
  through long-term use and hence made reliable and
  robust
• these have been made natural and effective
  through extended exposure and maintenance

23
Tool Obstacles

• Tool use obstacles
• developers tend to be like hammer and screwdriver
  carpenters
• tools are not powerful and/or effective
• tools are unreliable and/or unrobust
• comes with time and money
• tools are inconvenient and/or unnatural
• comes from successful use
• Tool building obstacles
• Short history of large-scale software development
• Limited success in
• developing software well
• exploiting tools successfully
• Few software techniques have had time and use
  required to achieve tool status
• No tools at all in some key areas (e.g.,
  real-time analysis)

24
Requirements Focus

• Requirements determine the What of a software
  products functionality. (See Jackson!)
• Requirements analysis and specification
  transforms
• informal product definition
• into
• formal requirements specification
• A step in between is transforming the product
  definition into a natural language statement of
  the systems functionality

25
What about Reality?

• Is a rational process of software development
  possible? (desirable?)
• Parnas No! We should fake it, though
• people dont know what they want
• dont know everything at outset, backtracking
  inevitable
• human beings not good at big, complex problems
• changes occur in the environment (out of our
  control)
• human errors only avoidable if we avoid the use
  of humans
• can we?
• preconceive, pet design ideas
• reuse and other economic factors
• Rank order these along different dimensions

26
What does the sincere developer do?

• Fake the rational process -
• designers need guidance - helps us proceed
• better than ad hoc - we can at least aim high
• organizational advantages to standard procedure
• reviews, transfer workers, ideas and software
• if we agree on an ideal process, we can measure
  progress along that dimension
• external reviews made possible and useful

27
Why have a Requirements Document?

• Record desired behavior of system
• that user or customer can review
• Avoid making customer decisions by programming!
• Avoid duplication and inconsistency
• many would argue, the requirements doc can answer
  questions
• A complete requirements doc is necessary to make
  good estimates (not sufficient though!)
• Valuable insurance against staff turnover
• Test plan development

28
More

• Can be used, long after system in use, to define
  constraints for future changes