1. CS3320-Chap21 Office Hours TR 1:00-2:15 PM W 2:30-3:30 PM By appointment

2. CS3320-Chap22 THE SOFTWARE PROCESS CS3320--Chapter 2

3. CS3320-Chap23 SOFTWARE PROCESS Software Process –Life-Cycle model –Tools –Individuals

4. CS3320-Chap24 LIFE-CYCLE PHASES –Requirements –Specifications –Design –Implementation –Integration –Maintenance –Retirement

5. CS3320-Chap25 TERMINOLOGY System Analysis –Requirements + Specifications phases Deign –Architectural design + detailed design Operations mode –Maintenance testing/verification –occur at end of each phase

6. CS3320-Chap26 TERMINOLOGY CONT. Verification –at end of each phase Validation –Before delivering product to client Client, Developer, User Internal Software Development/Contract Software

7. CS3320-Chap27 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. CS3320-Chap28 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. CS3320-Chap29 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. CS3320-Chap210 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. CS3320-Chap211 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. CS3320-Chap212 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. CS3320-Chap213 DESIGN PHASE Specification -- WHAT Design -- HOW Architectural design –decompose product into modules Detailed design –design each module -- data structures and algorithms

14. CS3320-Chap214 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. CS3320-Chap215 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. CS3320-Chap216 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. CS3320-Chap217 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. CS3320-Chap218 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. CS3320-Chap219 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. CS3320-Chap220 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. CS3320-Chap221 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. CS3320-Chap222 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. CS3320-Chap223 COMPLEXITY Software is more complex than any other constructs If a variable X is stored as a 16-bit number => X can have 2 16 possible states the Statement read(X) also has 2 16 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. CS3320-Chap224 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. CS3320-Chap225 CONFORMITY SW needs to interface with an existing system ==> need to conform to existing demands ==> inherent difficulty caused by the need to have SW interface/conform to human to hardware and other systems

26. CS3320-Chap226 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. CS3320-Chap227 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. CS3320-Chap228 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. CS3320-Chap229 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