1. University of Southern California Center for Systems and Software Engineering Introduction to: System and Software Construction, Transition and Support Planning CS577a Fall 2009 Barry Boehm ©USC-CSSE1

2. University of Southern California Center for Systems and Software Engineering Outline Overview –Software Maintenance and System Support –CS 577b Challenges Transition Plan System and Software Support Plan (SSSP) Construction Planning ©USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering Applicable ICM Documents CONSTRUCTION, TRANSITION, & SUPPORT (CTS) Set –ITERATION PLAN Iteration Assessment Report Release Description –QUALITY MANAGEMENT PLAN (QMP) –TEST PLAN Test Description and Results –TRANSITION PLAN Software User’s Manual –SYSTEM AND SOFTWARE SUPPORT PLAN (SSSP) ©USC-CSSE3

4. University of Southern California Center for Systems and Software Engineering Life Cycle Definitions ©USC-CSSE4 ValuationFoundations ConstructionTransition Support..... VCRFCRDCR SW IOC TRR Sys IOC RRR Release N+1 System Definition, Prototypes Operational Code Operational Documentation, Data, Procedures, Training Software DevelopmentSoftware Maintenance Software Evolution Activities Milestones PhasesDevelopment

5. University of Southern California Center for Systems and Software Engineering ©USC-CSSE5 Transition and Support Planning Objective: to make winners of the operational stakeholders –Users –Support stakeholders Software maintainers, system administrators, database administrators, operators, user supporters IOC (Initial Operational Capability) Milestone –Like having your first child –Operational system health preservation Corrective and adaptive maintenance Quality of service Dependability: safety, security, availability,... –Changes need to consider Continuous operation No surprises or major inconveniences Preservation of existing services

6. University of Southern California Center for Systems and Software Engineering Software Maintenance Phenomenology The Iron Law of Software Maintenance Software Maintenance production function The software maintenance manager’s whiteboard Lehman-Belady “Laws” of evolution dynamics Effects of COTS on software maintenance ©USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering The Iron Law of Software Maintenance Useful software systems will spend twice as much on software maintenance as they did for development –For CS 577 clients: Development = (24 weeks)(16 hr/week)(6 persons) = 2304 person-hr Maintenance = (2)(2304 PH)($50/PH) = $230,400 ©USC-CSSE7

8. University of Southern California Center for Systems and Software Engineering ©USC-CSSE8 EMERGENCY PROGRAM FIXES ROUTINE DEBUGGING ACCOM CHANGES TO INPUT DATA, FILES ENHANCEMENTS FOR USERS IMPROVE DOCUMENTATION ACCOM CHANGES TO HARDWARE, OS IMPROVE CODE EFFICIENCY OTHER LIENTZ-SWANSON DPMA SURVEY, 1978 487 INSTALLATIONS Distribution of Software Maintenance Effort

9. University of Southern California Center for Systems and Software Engineering 9 CUMULATIVE BENEFIT TO ORGANIZATION The Software Maintenance Production Function EMERGENCY PROGRAM FIXES 020406080100 ACCOMMODATE HARDWARE, OS CHANGES ACCOMMADATE INPUT DATA, FILE CHANGES MANDATORY ENHANCEMENTS INVESTMENT SEGMENT HIGH PAYOFF SEGMENT DIMINISHING RETURNS SECONDARY PERFORMANCE IMPROVEMENTS SECONDARY USER ENHANCEMENTS IMPROVE CODE EFFICENCY IMPROVE DOCUMENTATION TERTIARY USER ENHANCEMENTS PRIMARY USER ENHANCEMENTS ROUTINE DEBUGGING PERCENT OF AVAILABLE SOFTWARE MAINTENANCE BUDGET ©USC-CSSE

10. University of Southern California Center for Systems and Software Engineering ©USC-CSSE10 The Software Maintenance Manager’s Whiteboard Operations Web Mail Study 2002 OSHA Safety Report P & L Center Reorganization Changes Springfield Data Link Finance Contract Status Reports Discounted Cash Flow Analysis Property Report Changes P & L Center Reorganization Changes Personnel 2002 AAP/EEO Reports Skills Inventory College Recruiting Reports Applicant Tracking Study Manufacturing LIFO Inventory Support Time & Motion Data Reduction On-Line Production Control Study Quality Cost Reporting

11. University of Southern California Center for Systems and Software Engineering ©USC-CSSE11 Lehman-Belady “Laws” of Evolution Dynamics 1. Continuing change 2. Increasing complexity 3. Cyclic self-regulation 4. Invariant work rate 5. Conservation of familiarity

12. University of Southern California Center for Systems and Software Engineering ©USC-CSSE12 Effects of NDI on Software Maintenance You have no control over NDI evolution Maintenance headaches scale exponentially with # NDI You need a pro-active NDI-based-system evolution strategy –Go for dominant open standards –Factor evolution requirements into NDI selection –Evaluate NDI vendors’ evolution track records –Use flexible architectures CORBA, COM, software bus, layering, event/message- based Encapsulation : use NDI wrappers –Technology watch investments –Synchronized NDI upgrade/release strategy

13. University of Southern California Center for Systems and Software Engineering ©USC-CSSE13 CS 577b Challenges No developers available for software/system support Short time period to develop and transition system –And for clients to prepare for transition system

14. University of Southern California Center for Systems and Software Engineering Outline Overview –Software Maintenance and System Support –CS 577b Challenges Transition Plan System and Software Support Plan (SSSP) Construction Planning ©USC-CSSE14

15. University of Southern California Center for Systems and Software Engineering Transition Plan Overview Purpose: ensure successful transition into operations –For 577, transition is from developers (you) to clients and their software maintainers Timing: –DCR: sections 1 & 2 at top level –Transition Readiness Review: final plan Completion Criteria: stakeholder concurrence; feasibility of execution; assurance of successful transition Intended Audience: transition stakeholders: user, customer, developer, maintainer, operator, supplier Typical dependencies: LCP 2 deliverables; LCP 3 life cycle support responsibilities ©USC-CSSE15

16. University of Southern California Center for Systems and Software Engineering 1. Transition Strategy 1.1 Transition objectives –Extent: full operation/limited pilot operation –Sites: one/many; homogeneous/heterogeneous –Developer continuity: none/full/intermediate –Degree of operational test and evaluation –Product transitioned: COTS/new system/legacy upgrade 1.2 Transition process strategy –Cutover: instant/incremental/parallel operation –Phasing of multiple increments to multiple sites –Role of alpha testing, beta testing, formal operational testing ©USC-CSSE16

17. University of Southern California Center for Systems and Software Engineering 2. Preparing for Transition 2.1 Hardware preparation: purchases, installation 2.2Software preparation: licenses, rehosting, data 2.3Site preparation: facilities, equipment, communications 3. Stakeholder Roles and Responsibilities –This section should be coordinated with stakeholder organizations, especially user and maintainer –Section should be coordinated with: LCP - Responsibilities ©USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering Outline Overview –Software Maintenance and System Support –CS 577b Challenges Transition Plan System and Software Support Plan (SSSP) Construction Planning ©USC-CSSE18

19. University of Southern California Center for Systems and Software Engineering System and Software Support Plan Purpose: to guide support stakeholders in successfully (operating and) maintaining the system Timing: –Rebaselined-DCR: top-level draft –Transition Readiness Review: complete draft –Completion of Transition Phase: final plan. Intended Audience: Support stakeholders, plus developers (target for Transition Plan), users (operational information) Responsibilities: joint between support stakeholders (normally the leaders) and developers (leaders in 577b) Completion Criterion: stakeholder concurrence, feasibility of execution, resource realism ©USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering Support Plan Contents 1. Support Objectives and Assumptions (why, whereas) 2.Support Strategy (what) 3.Support Environment (when) 3. Support Responsibilities (who, where) ©USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering Examples: Support Objectives and Assumptions Key driving objectives for support activities -Ensure system safety; top customer satisfaction; competitive speed -Replace inefficient old systems quickly -Provide more promising support career paths Assumptions required for workability of support plan –Continuity of funding, staffing, executive support –Controllable/negotiable interfaces with other systems –Stability of next-release requirements and schedules ©USC-CSSE21

22. University of Southern California Center for Systems and Software Engineering Support Strategy Estimated support lifetime –Under 1 year; over 5 years; until XYZ phased out Release strategy –Continuous small fixes; annual release; COTS refresh cycle –Early next-release content (evolution rqts.) –Release transition strategy (testing; multisite sequencing) Release requirements determination –Primary drivers (budget, schedule, staffing, marketplace) –Process (stakeholder win-win, bidding, sub-allocations) Release process –Normally inception/elaboration/construction/transition ©USC-CSSE22

23. University of Southern California Center for Systems and Software Engineering Outline Overview –Software Maintenance and System Support –CS 577b Challenges Transition Plan System and Software Support Plan (SSSP) Construction Planning ©USC-CSSE23

24. University of Southern California Center for Systems and Software Engineering Initial Operational Capability (IOC) Deliverables Construction Phase ©USC-CSSE24

25. University of Southern California Center for Systems and Software Engineering Construction Deliverables –Reference Construction Transition Support (CTS) section of ICM EPG Sets of artifacts are identified for various purposes Construction Planning Set –LCP, plus Specialty Plans (see next slide) –At start of Development Phase (for 577, RDCR) Construction Working Set--end of each construction iteration. Summary of contents: –Code base –COTS packages (integrated, configuration) –Revised Documentation ©USC-CSSE25

26. University of Southern California Center for Systems and Software Engineering Specialty Plans First Iteration Plan –For 577, first iteration is through CCD Quality Management Plan Test Plan Security Plan* Safety Plan* *These optional plans are not covered by the Guidelines ©USC-CSSE26

27. University of Southern California Center for Systems and Software Engineering All Plans and Major Activities Should be Explicitly Planned Allocate effort and people in LCP to –Write plans –Execute plan activities –Prepare for RDCR and TRR reviews, Core Capability Demo Anticipate and account for risks –Allocate extra time for risky items –Explicitly schedule critical contingency plans Be consistent with the class schedule ©USC-CSSE27

28. University of Southern California Center for Systems and Software Engineering Example Project Major Milestones Jan. 12 - Re-form teams Feb. 8- Draft Rebaselined DC Package on Web Feb. 15-16- Rebaselined DCR ARB reviews Mar. 9 –31- Core Capability Demos Apr. 12 - Draft Transition Package on Web Apr. 15-16 - Transition Readiness Reviews May 7- Product Delivery ©USC-CSSE28

29. University of Southern California Center for Systems and Software Engineering ©USC-CSSE29 Example Summary of Client Activities 08/25/08©USC-CSSE29 Jan. 11- Feb. 12: Work with teams: –Rebaseline prototype, prioritize requirements –Plan for CS 577b specifics, including transition strategy, key risk items –Participate in ARB review Feb 15 – May 7: Scheduled Weekly Meetings with Teams to: –Discuss status and plans –Provide access to key transition people for strategy and readiness discussions Mar 8 – 26: Core Capability Drivethrough Apr 15 - Apr 16: Project Transition Readiness ARB Reviews Apr 20: Installation and Transition –Install Product –Execute Transition Plan May 4-5: Operational Commitment Review for Initial Operational Capability May 7: Client Evaluations

30. University of Southern California Center for Systems and Software Engineering Iteration Activities, Milestones and Deliverables ©USC-CSSE30

31. University of Southern California Center for Systems and Software Engineering Construction Working Set (per iteration) Iteration Plan (from start of iteration) Test Reports Release Description Iteration Assessment Report Iteration implementation (under CM) –Source code, compile-time files, executables, test drivers As-built OCD, SSRD, SSAD, FED, LCP ©USC-CSSE31

32. University of Southern California Center for Systems and Software Engineering Iteration Plan 1.1Capabilities to be implemented –Usually specified by listing requirements from SSRD 1.2Capabilities to be tested –“Verification” is via technique appropriate to the requirement Usually testing, but can be peer review, client agreement, … Consult the “measurable” attribute of the requirement 1.3 Capabilities not to be tested –Identify features which will not be tested this iteration and why. 2Plan (for the iteration) –Usual planning information: Tool Support, Schedule, Resources, Responsibilities Iteration plan is input to the next iteration plan. ©USC-CSSE32

33. University of Southern California Center for Systems and Software Engineering Quality Management Plan Describes plans for certain types of effort which increase the likelihood that the system will satisfy stakeholders’ win conditions Writing code so that it’s readable, it contains certain useful information, and it avoids certain errors 2.2Coding Guidelines Using peer reviews to catch defects early 2.3.1 Peer Reviews (coordinate with Peer Review Plan) Seeing that all requirements are verified, in an appropriate way 2.5.1 Requirement Verification Ensuring that software changes are as agreed to by stakeholders and are as planned 2.7Configuration Management Selecting test types and tracking the testing process ©USC-CSSE33

34. University of Southern California Center for Systems and Software Engineering Test Plan Describes plans for managing the testing process Covers specifying testing resources and planning for their use –How many tests will be run –How long will each take –What kind(s) of platform(s) are needed to run tests –Testing schedule –... ©USC-CSSE34

35. University of Southern California Center for Systems and Software Engineering Iteration Assessment Report Each iteration is concluded by an iteration assessment –Overview Capabilities implemented Summary of test results –Adherence to Plan –External Changes Occurred –Suggested Actions ©USC-CSSE35

36. University of Southern California Center for Systems and Software Engineering Release Description The purpose of the Release Description is to describe the release –New Features and Important Changes since the previous release –Upcoming Changes that will be incorporated in future releases –Known Bugs and Limitations ©USC-CSSE36