1. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 1 Focus Identify corpor- ate practices - assess capability - specify standards - e.g. CMM level Development phases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

2. next chapter: Plan development process Plan configuration management - how to manage documents & code - document: SCMP Plan quality assurance - how to ensure quality - document: SQAP Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 1 Focus Identify corpor- ate practices - assess capability - specify standards - e.g. CMM level Development phases Plan verification & validation - verify the product satisfies requirements - validate each phase by showing it succeeded document: SVVP Plan project Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Stand-alone –residing on a single computer –not connected to other software or hardware –e.g., word processor Embedded –part of unique application involving hardware –e.g., automobile controller Realtime –functions must execute within small time limit typically microseconds –e.g., radar software Network –consist of parts interacting across a network –e.g., Web-based video game Some Application Types Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Typical Project Roadmap 1. Understand nature & scope of proposed product 2. Select the development process, and create a plan -- section 4 and chapter 2 4. Design and build the product -- chapters 5, 6, and 7 6. Deliver and maintain the product -- chapter 10 3. Gather requirements -- chapters 3 and 4 5. Test the product -- chapters 8 and 9 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5. 3. Expectations for process, project, product and people

6. Five Key Expectations (Humphrey) Influenced by people Used for process development Part of the project Aspect of the product 3. Keep all work visible 5. Measure quality 4. A. Design only against requirements B. Program only against designs C. Test only against requirements and designs 1. Predetermine quantitative quality goals 2. Accumulate data for subsequent use

7. The Waterfall Model Requirements analysis Design Implementation Integration Produces … specification (text)... diagrams & text... code & comments... entire code Test... test report, including defect descriptions Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. More Detailed Waterfall Version Design Implementation & unit testing Integration System testing Concept analysis Analysis Maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. complete targeted requirements Step n: Analyze requirements Step n+3: Test Step n+2: Implement Step n+1: Design Product:class models + Product: requirements specifications Product: code +Product: test results + Spiral Development Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. Iteration No. Incremental Development Analyze requirements Test whole Implement Design Test units Integrate 123867868 Update SRS 3 Update SDD 2 Update source code Update Test documentation Update SPMP 1 1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. The Unified Software Development Process: Classification of Iterations Inception iterations: preliminary interaction with stakeholders –primarily customer –users –financial backers etc. Elaboration iterations : finalization of what’s wanted and needed; set architecture baseline Construction iterations : results in initial operational capability Transition iterations : completes product release Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. Requirements Analysis USDP vs. Standard Terminology 2 of 2 Design Implementation Test Requirements analysis Implementation USDP Terminology Classical Terminology Integration Design Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

13. Elaboration Unified Process Matrix InceptionConstructionTransition Requirements Analysis Jacobson et al: USDP Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. Design Implemen- tation Test.. Amount of effort expended on the requirements phase during the first Construction iteration

14. The Six USDP Models (Views of the Application) Use-case model Analysis model Design model Deployment model Implementation model Test model Graphics reproduced with permission from Corel.

15. Identify the Process You Will Use 1. Decide which of waterfall, spiral, and incremental processes is appropriate. Usually a spiral for a semester project. Combining parts is OK e.g. start with spiral, end with incremental 2. Decide how many iterations. Usually two for a semester project (there are many artifacts to coordinate at the end of each iteration). Three provides lots of practice -- but this is a challenge; make the first increment as minor as possible Three promotes the collection and use of metric data -- use metric data collected from each iteration on next. 3. Rough out a weekly schedule. Coordinate with course assignments. (The next chapter discusses scheduling.) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

16. 5. Documentation

17. Undocumented Code int a( int i, char c ) { if( c== “m” ) if( i< 1000 ) return 0; else if( i< 10000 ) return 500; else return 1200; else return 1300; } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. Somewhat Documented Code Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. int tax( int anEarning, char aStatus ) { if( aStatus == ‘m’ ) if( anEarning < 1000 ) return 0; // no tax for married, < $1000 else if( anEarning < 10000 ) return 500; // married, $1000-$10000 else return 1200; // married, >=$10000 // If not “married”, apply single tax rate of $1300 regardless else return 1300; }

19. Documented Code /** * This method implements requirement 4.3: * “State tax effective 9/1/98 -12/31/99” * @author Eric J. Braude * @version 2.3.4 (8/6/98) * @param anEarning: earnings 9/1/98 thru 12/31/99 * @param aStatus: ‘m’ signifies “married” (anything * else designates unmarried) */ int tax( int anEarning, char aStatus ) { Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20. Project Documentation SCMP software configuration management plan SPMP software project management plan Project status Configuration SQAP software quality assurance plan Quality assurance SVVP software validation & verification plan Verification & validation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

21. Project Documentation SRS software requirements specifications STD software test documention SCMP software configuration management plan SDD software design document SPMP software project management plan Source Code Project status Configuration Testing Requirements Design Code User’s manual Operation SQAP software quality assurance plan Quality assurance SVVP software validation & verification plan Verification & validation Customer- oriented Developer- oriented Architecture Detailed design Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. 1. Document the way documents & code are accessed –otherwise, chaos results –“Software Configuration Management Plan*” -- section tbd 2. Specify who will do what, and when they will do it –“Software Project Management Plan*” -- chapter 2 3. Document what is to be implemented –for yourself, your customer, and your team –“Software Requirements Specification*” -- chapters 3 and 4 4. Document the design of the application –i.e., prior to programming –“Software Design Document*” -- chapters 5 and 6 5. Write and document code –the “code base” -- chapter 7 6. Document the tests you perform –so that they can be re-run, extended etc. –“Software Test Documentation*” -- chapters 8 and 9 Identify Your Documentation Needs * the IEEE standard, which can be used to organize this documentation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

23. 6. Quality

24. QA Involvement 3. Plan4. Design and build 5. Deliver & main- tain the product 1. Specify how to manage project documents 2. Identify process QA 1. QA Develops and/or reviews configuration management plans, standards... 3. QA develops and/or reviews provision for QA activities 2. QA reviews process for conformance to organizational policy 5. QA reviews, inspects & tests 4. QA reviews, inspects & tests Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

25. Principle of Inspection AUTHORS CAN USUALLY REPAIR DEFECTS THAT THEY RECOGNIZE Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

26. OVERVIEW CAUSAL ANALYSIS 4. REWORK 5. FOLLOW-UP Inspection Process & Example Times Non-nominal process 6. IMPROVE PROCESS 2. PREPARATION 3. INSPECTION Nominal process 1. PLANNING Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. Time/Costs per 100 LoC* -- one company’s estimates Planning1 hr  (1 person) [ Overview 1 hr  (3-5) ] Preparation1 hr  (2-4 people) Inspection meeting1 hr  (3-5 people) Rework1 hr  (1 person) [ Analysis 1 hr  (3-5) ] Total: approx. 7 - 21 person-hours * lines of non-commented code Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Hours Per Defect: One estimate … at inspection … at integration timetime Hours to.... detect 0.7 to 2 0.2 to 10.. repair 0.3 to 1.2 9+ Total 1.0 to 3.2 9.2 to 19+ If defect found... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. Prepare For & Conduct Inspections 1. Build inspections into the project schedule –plan to inspect all phases, starting with requirements –allow for preparation (time consuming!) & meeting time 2. Prepare for collection of inspection data –include # defects per work unit (e.g., KLOC), time spent –develop forms: include description, severity and type –decide who, where, how to store and use the metric data default: appoint a single person to be responsible failure to decide usually results in discarding the data 3. Assign roles to participants –Three adequate (author; moderator/recorder; reader) –Two far better than none (author; inspector) 4. Ensure every participant prepares –bring defects pre-entered on forms to inspection meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

30. IEEE 730-1989 Software Quality Assurance Plans Table of Contents 1. Purpose 2. Referenced documents 3. Management 3.1Organization 3.2 Tasks 3.3 Responsibilities 4. Documentation 4.1Purpose 4.2 Minimum documen- tation requirements 4.3 Other 5. Standards, practices, conventions and metrics 5.1Purpose 5.2Content

31. IEEE 730-1989 Software Quality Assurance Plans Table of Contents 1. Purpose 2. Referenced documents 3. Management 3.1Organization 3.2 Tasks 3.3 Responsibilities 4. Documentation 4.1Purpose 4.2 Minimum documen- tation requirements 4.3 Other 5. Standards, practices, conventions and metrics 5.1Purpose 5.2Content 6. Reviews and audits 6.1 Purpose 6.2 Minimum requirements 6.2.1 Software requirements review 6.2.2 Preliminary design review 6.2.3 Critical design review 6.2.4 SVVP review 6.2.5 Functional audit 6.2.6 Physical audit 6.2.7 In-process audits 6.2.8 Managerial review 6.2.9 SCMP review 6.2.10 Post mortem review 6.3 Other 7. - 15. -- see next chapter

32. Verification: are we building the thing right? Validation: are we building the right thing? Meaning of “V&V” (Boehm) Graphics reproduced with permission from Corel.

33. IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992) 1. Purpose 2. Referenced documents 3. Definitions 4. V&V overview 4.1Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies 5. Lifecycle V&V 5.1Management of V&V 5.2 Concept phase V&V 5.3 Requirements phase V&V 5.4 Design phase V&V 5.5 Implementation phase V&V

34. IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992) 1. Purpose 2. Referenced documents 3. Definitions 4. V&V overview 4.1Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies 5. Lifecycle V&V 5.1Management of V&V 5.2 Concept phase V&V 5.3 Requirements phase V&V 5.4 Design phase V&V 5.5 Implementation phase V&V 5.3 Test phase V&V 5.4 Installation & checkout phase V&V 5.5 Operation & maintenance phase V&V 6. Software V&V reporting 6.1 Required reports 6.2 Optional reports 7. V&V administrative procedures 7.1Anomaly reporting & resolution 7.2 Task iteration policy 7.3 Deviation policy 7.4 Standards, practices & conventions

35. Produce a Quality Product 1. Quantify your quality goals minimum: number of defects per KLOC team: # defective requirements; # classes missing from design; # defects in testing; # defects found in operation. personal: apply # defects to code, compile, unit test separately 2. Build inspections and reviews into the schedule (see scheduling, next chapter) follow the inspection procedure (see figure 1.27 on page ??) 3. Document your quality goals and procedures use a documentation standard to avoid missing issues SQAP (see case study for example); If time allows: SVVP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. 7. Documentation management

37. Example of Hyperlinked Documentation Set (with Dynamic Content shown) SRS software requirements specifications STP software test plan SCMP software configuration management plan SDD software design document SPMP software project management plan Source Code References to all other documents Project status* Configuration* Test results* Direction of hyperlink * Dynamic component Updates* Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

38. Configuration Management Requirements Procedure to identify CI's Locking –to prevent more than one person working on a CI at one time Authorization to check out –optional Check-in procedure –authorization process –involves testing etc. Historical record of prior groupings of consistent CI’s Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

39. IEEE 828-1990 SCMP Table of Contents 3.2 Configuration control 3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis- approving changes 3.2.4 Implementing changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control 4. SCM schedules 5. SCM resources 6. SCM plan maintenance 1. Introduction 2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures 3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configu- ration items 3.1.2 Naming configu- ration items 3.1.3 Acquiring configu- ration items Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

40. Plan Configuration Management 1. Roughly sketch out your SCMP Determine procedures for making changes Omit tool references unless already identified one See the case study for an example 2. Specify what you need from a CM tool For class use, maybe only locking and backup 3. Evaluate affordable tools against your needs and budget Commercial tools are in wide use For class use, try free document storage web sites; try simple method of checking out e.g. renaming 5. Finalize your SCMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

41. 8. Introduction to capability assessment

42. The PSP Evolution (Humphrey) (Adapted from [Hu1] ) PSP0 Current personal process Basic measurements PSP0.1 Coding standards Process improvement proposal Size measurement PSP1 Size estimation Test report PSP1.1 Task planning Schedule planning PSP2 Code reviews Design reviews PSP2.1 Design templates PSP3 Cyclic development Additional capability at the same level Skills added to prior stage 100’s of lines 1000’s of lines

43. TSP Objectives 1 (Humphrey) Build self-directed teams –3-20 engineers –establish own goals –establish own process and plans –track work Show managers how to manage teams –coach –motivate –sustain peak performance Graphics reproduced with permission from Corel.

44. TSP Objectives 2 (Humphrey) Accelerate CMM improvement –make CMM 5 “normal” “Provide improvement guidelines to high-maturity organizations” “Facilitate university teaching of industrial-grade teams”

45. The Capability Maturity Model (CMM) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

46. 1. Initial (Software Engineering Institute) Process: undefined, ad hoc Result: outcome depends on individuals Lacking: any reasonable process

47. 2. Repeatable (Software Engineering Institute) 1. INITIAL Process undefined, ad hoc, depends on individuals Process tracks documents, cost, schedule, functionality (after fact) Result repeatable only on similar projects Lacking: complete process

48. 3. Defined (Software Engineering Institute) 2. REPEATABLE Basic project management to track cost & schedule, repeatable on similar projects Process documented, standardized, tailorable Result consistency Lacking: predictable outcomes

49. 4. Managed (Software Engineering Institute) 3. DEFINED Consistent: Documented, standardized, tailorable Process detailed measurement; control Result process and products with quantified quality predictability Lacking mechanism for process improvement

50. 5 Optimized (Software Engineering Institute) 4. MANAGED Predictable: process & products measured Process Continual process improvement through quantitative feedback; Extensible scope Innovative ideas and technologies Graphics reproduced with permission from Corel.

51. Get permission Relating PSP, TSP & CMM (Humphrey)

52. Get permission Relating PSP, TSP & CMM (Humphrey)

53. 9. Summary

54. Software engineering an extensive challenge Major process models: waterfall; spiral; incremental Capability frameworks: CMM; TSP; PSP Quality is the professional difference –metrics to define –inspection throughout –rigorous testing –include continuous self-improvement process Documentation: SCMP, SVVP, SQAP, SPMP, SRS, SDD, STP, Code, User’s manual Summary Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

55. Case Study: SCMP