Office%20Hours

1
Office Hours

• TR 100-215 PM
• W 230-330 PM
• By appointment

2
THE SOFTWARE PROCESS

• CS3320--Chapter 2

3
SOFTWARE PROCESS

• Software Process
• Life-Cycle model
• Tools
• Individuals

4
LIFE-CYCLE PHASES

• Requirements
• Specifications
• Design
• Implementation
• Integration
• Maintenance
• Retirement

5
TERMINOLOGY

• System Analysis
• Requirements Specifications phases
• Deign
• Architectural design detailed design
• Operations mode
• Maintenance
• testing/verification
• occur at end of each phase

6
TERMINOLOGY CONT.

• Verification
• at end of each phase
• Validation
• Before delivering product to client
• Client, Developer, User
• Internal Software Development/Contract Software

7
REQUIREMENTS PHASE

• To determine what the product is to do
• Concept exploration
• determine what the client needs
• Determine the constraints
• budget
• time
• size
• etc.

8
REQUIREMENTS PHASE cont.

• Determine the functionality of the product
• This phase is often done improperly
• client does not know what they need
• Moving target problem
• Rapid Prototype

9
Requirements Testing

• Software Quality Assurance Group (SQA)
• to ensure that the product delivered is what the
  client ordered
• verify with client that the rapid prototype is
  completely satisfactory

10
SPECIFICATIONS PHASE

• Explicitly describes what the product
• is supposed to do.
• Specification is a legal document
• Must not include phrases like optimal, 98
  complete, etc.
• Specification must not be
• ambiguous
• incomplete
• contradictory

11
SPECIFICATIONS PHASE

• Once specification have been signed off
• Software Product Management Plan (SPMP)
• SPMP includes
• deliverables, milestones, budget
• Describes the software process in fullest detail
  life-cycle model, organization structure,
  project responsibilities, resource allocations,
  CASE tools
• See chap8 for standard IEEE format

12
SPECIFICATION PHASE TESTING

• SQA check specs for ambiguities,
  contradictions, incompleteness.
• Feasibility obtain 2 or more independent
  estimates.
• Traceability
• requirements properly numbered, cross-referenced,
  and indexed
• Rapid Prototype
• Testing by means of Review

13
DESIGN PHASE

• Specification -- WHAT
• Design -- HOW
• Architectural design
• decompose product into modules
• Detailed design
• design each module -- data structures and
  algorithms

14
DESIGN PHASE cont.

• documenting the process in case
• dead end is reached
• maintenance is needed
• Ideally design is open-ended
• future enhancements can be done by adding new
  modules or replacing modules without affecting
  the design
• Output detailed description of architectural
  design and detailed design

15
DESIGN PHASE TESTING

• Traceability every part of the design can be
  traced to a statement in the specs
• Review process design team SQA group
• Type of faults
• logic
• interface
• lack of exception handling
• non-conformance to the specification

16
IMPLEMENTATION PHASE

• Implement detailed design in code
• Output source code, adequately commented
• Implementation testing
• module tested as they are implemented by
  programmers (desk checking)
• formal testing by SQA
• Documentation
• comments
• test cases with results

17
INTEGRATION PHASE

• Combine the modules and check product as a whole
• all at once
• one at a time
• top to bottom
• bottom to top
• parallel integration and implementation

18
Integration Phase Testing

• Product testing by SQA
• correctness meets specs
• robustness behavior under erroneous input
• complete and consistent documentation
• Acceptance testing
• tested by the client on the actual hardware using
  real data
• Shrink-wrapped software (COTS)
• Alpha test--Beta test

19
MAINTENANCE PHASE

• Work done After Acceptance Testing
• an integral part of software design and coding
  should take future maintenance in mind
• problems
• lack of documentation
• personnel turnover
• the most challenging phase

20
Maintenance Phase Testing

• Two aspects
• the required changes have been correctly
  implemented
• no unwanted changes were made
• regression testing test product against previous
  test cases
• Previous test cases and their results must be
  documented

21
Retirement

• When
• Further maintenance is not cost-effective
• drastic changes are needed
• interdependencies (because of too many changes)
• HW/OS replacement
• True retirement is RARE

22
INHERENT PROBLEMS OF SOFTWARE

• Hardware has inherent limits
• speed speed of light
• size width of an atom
• SW limits essence vs. accidents
• Does software has an inherent limits?
• Complexity
• conformity
• changeability
• invisibility Brooks, 1986

23
COMPLEXITY

• Software is more complex than any other
  constructs
• If a variable X is stored as a 16-bit number
• gt X can have 216 possible states
• the Statement read(X) also has 216 states
• If X is used to control the flow of execution in
  a module (e.g. Conditional, loop, recursion, etc)
  the complexity of the module increases greatly

24
COMPLEXITY cont.

• The complexity of a module increases with the
  number if arguments it has, the number global
  variables, etc.
• Complexity also increases with increased
  inter-depend modules
• Some aspect of complexity can be reduced
• e.g. using OO paradigm
• Some aspects are inherent to SW

25
CONFORMITY

• SW needs to interface with an existing system
• gt need to conform to existing demands
• gt inherent difficulty caused by the need to
  have SW interface/conform to human to hardware
  and other systems

26
CHANGEABILITY

• SW is easier to change than HW
• Frequent demands for major changes
• Reasons
• SW is a model of reality
• Extend the functionality
• easier to change than HW
• successful SW longer lifetime ( 15 y ) than HW
  (4 y)
• Changeability is an inherent property of SW

27
Invisibility

• Difficult to visualize the SW
• multiple charts are used
• data flow diagrams
• control flow diagrams
• dependency graphs
• time sequences
• diagrams cannot embody every aspect of the product

28
No Silver Bullet

• Three major breakthroughs
• HLL
• time sharing
• software development environments
• Did not eliminate the inherent difficulties
• 6 productivity increase per year in SW industry
  during the last 20 years.

29
SOFTWARE PROCESS IMPROVEMENT INITIATIVES

• Capability Maturity Model (CMM) strategy for
  improving SW process
• put forward by SEI
• ISO 9000 set of standards for quality control
• Software process Improvement Capability
  dEtermination (SPICE) extends CMM and ISO 9000.
  Referred to as ISO 15504