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 (customer)
• individuals or organizations that want the
  solution
• to a problem they have
• Developer(s)
• (members of) an organization producing the
  solution
• to THAT problem
• User(s)
• person who authorizes client to contract with
  developer
• person(s) who will utilize the software solution
• Internal software development vs external
  contract
• and all the shades of gray!

4
What is a process?

• Device for producing a product (get 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
• what is this about?

5
Intermediate Software Products

• Objectives
• Mark the end of phases
• Enable effective reviews
• Specify requirements for next phase
• Note the abstract requirements/design cycle
• 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 is the client (and user)
  problem
• in their environment - with their environmental
  constraints
• develop a contract with client
• exactly what the software/computer solution will
  do
• Difficulties
• client asks for wrong product or developer knows
  better (want vs need)
• client is computer/software illiterate or
  developer domain illiterate
• specifications will be ambiguous, inconsistent,
  incomplete (adequacy?)
• 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
• cant design one of those (feedback to
  requirements?)
• miscommunication between module designers
• design may be inconsistent, incomplete,
  ambiguous
• question when can the programmer make this
  decision for the client? with all that entails
• 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
• cant build one of those (feedback to design or
  requirements?)
• 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, author of PSP

• CMM is not a software lifecycle model ...
• Strategy for improving the software development
  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"
• Software Tools should be ...
• powerful, effective, convenient, natural,
  reliable, robust
• Most 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 not robust
• 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. (But 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
• precise, yet abstract (how do we do this?!?)

25
What about Reality?

• Is a rational process of software development
  possible? (desirable?)
• Parnas No! We should fake it, though (1986)
• 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?
• preconceived notions (favorite ideas, like
  language wars)
• reuse and other economic factors
• Rank order these (most often, most expensive
  during development, most costly in later use?)

26
What does the sincere developer do?

• Parnas says 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 of workers, ideas and software
• if we agree on an ideal process, we can measure
  progress along that dimension
• external reviews made possible and useful
• because others will understand the standards

27
Why have a Requirements Document?

• Record desired behavior of system build the
  solution the the right problem
• that user or customer can review for adequacy
• we dont want a random variation on the correct
  solution
• Avoid making customer decisions by programming!
• what can happen here? consider systems
  engineering
• Avoid duplication and inconsistency
• many would argue, the requirements doc can answer
  questions
• a masters thesis prototype AS requirements

28
Why? (continued)

• A complete requirements doc is necessary to make
  good estimates (not sufficient though!)
• Valuable insurance against staff turnover
• Test plan development

29
More

• Can be used, long after system in use, to define
  constraints for future changes
• senior project never too late to do
  requirements

30
Synchronization

• Read Wiegers
• Read Yourdon
• Read Jackson
• Develop questions you might ask customer
• dynamically develop questions during customer
  presentations to review later and refine
• if you get a good answer, record it as well as
  you can

31
(continued)

• each team member should keep notes
• team meeting afterwards to gather notes to make a
  preliminary report of
• questions asked
• answered obtained
• overview of domain
• overview of problem as described
• other comments of note