1. University of Southern California Center for Systems and Software Engineering Operational Concept Description (OCD) and Life Cycle Plan (LCP) Barry Boehm CS577a Fall 2014 1

2. University of Southern California Center for Systems and Software Engineering 1/13/2014 ICSM Activity Levels for Complex Systems 2© USC-CSSE

3. University of Southern California Center for Systems and Software Engineering 1/13/2014 Anchor Point Feasibility Evidence Descriptions Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will –Satisfy the requirements: capability, interfaces, level of service, and evolution –Support the operational concept –Be buildable within the budgets and schedules in the plan –Generate a viable return on investment –Generate satisfactory outcomes for all of the success-critical stakeholders All major risks resolved or covered by risk management plans Serves as basis for stakeholders’ commitment to proceed Synchronizes and stabilizes concurrent activities Can be used to strengthen current schedule- or event-based reviews 3© USC-CSSE

4. University of Southern California Center for Systems and Software Engineering 4 Similarity of OCD and LCP Just Answer the Simple Questions : - Why? - What? - When? - Who? - Where? - How? - How Much? - Whereas? Objectives to be achieved Milestones (dates) & Products (to be delivered) Responsibilities (individual And location/organization) Approach Resources, Quality Assumptions OCD does this for the system. LCP for the project

5. University of Southern California Center for Systems and Software Engineering https://wiki.umiacs.umd.edu/adapt/images/1/11/Concept-of-operations-2.pdf 5

6. University of Southern California Center for Systems and Software Engineering Business Model Generation 6 More info at EP09 – Business Model Generation

7. University of Southern California Center for Systems and Software Engineering 7

8. University of Southern California Center for Systems and Software Engineering Example: Apple iPod/iTunes Business Model Canvas 8

9. University of Southern California Center for Systems and Software Engineering Success-critical stakeholders Success- Critical Stakeholders (SCS) –Project SCS Client, developers, sponsors –Operational SCS: System’s users, operators, supporters, administrators, maintainers (client’s clients) –System-specific SCS supplier, actor, volunteer, vendor, researcher –Key stakeholders should have CRACK characteristics CRACK: Collaborative, Representative, Authorized, Committed, and Knowledgeable ©USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering Value Propositions Are we solving anything? What do we offering ? What value do we deliver to the customer? Which customer needs are we satisfying? –Newness –Performance, cost reduction, risk reduction –Customization, usability –Getting the job done –Price 10

11. University of Southern California Center for Systems and Software Engineering Operational Concept Definition (OCD) ©USC-CSSE11 Purpose of the OCD 1.To describe the success critical (key) stakeholders’ shared vision of the project being undertaken. 2.Key stakeholders typically include the system’s users the client the customer, if different from the client the maintainer** and the developers. More info, check the ICSM EPG http://greenbay.usc.edu/IICMSw/index.htm

12. University of Southern California Center for Systems and Software Engineering OCD Content and Completion Criteria VC Package FC Package OCD Content Shared Vision Success- Critical Stakeholders System Capabilities Descriptions Expected Benefits Benefit Chain, System Boundary and Environment System Transformation Information on the Current System System Objective, Constraints & Priorities Capability Goals, LOS goals, Organization goals Constraints, relation to current system Proposed New Operational Concept Element Relationship diagram, Business Workflow Organization and Operational Transformation ©USC-CSSE12

13. University of Southern California Center for Systems and Software Engineering Shared Vision ©USC-CSSE13

14. University of Southern California Center for Systems and Software Engineering System Capabilities Descriptions Contain the following information –The type of system to be built –The target customer(s) for the system –The need or opportunity that will be satisfied by the system –A compelling reason for the customer to buy/use the system –The closest competitor of the system –The system's primary differentiation from, or benefit over, the closest competitor or alternative approach, if there are competitors or alternatives ah the time “ Sierra Mountainbikes, Inc’s Sales Department needs a faster, more integrated order entry system to increase sales. The proposed Web Order System will give us an e-commerce order entry system similar to Amazon.com’s that will fit the special needs of ordering mountain bicycles and their aftermarket components. Unlike the template- based system that our main competitor bought, ours would be faster, more user friendly, and better integrated with our order fulfillment system.” ©USC-CSSE14

15. University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram Illustrate the results of chain of benefits starting from developing to deploying the system Focusing on –What kind of initiatives will create the benefits? –Who has to perform those initiatives so that the benefits can be realized? –What is/are the ultimate benefits/outcomes of the system? ©USC-CSSE15

16. University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram Stakeholder(s): –What are the success critical stakeholders who create and receive benefits from the developing system? E.g. Development team, Volunteer, Manager Initiative: –What are the actions that stakeholder(s) performs that could contribute benefit to the system. Initiative should be represented in Verb-form. E.g. Develop automatic report generation module, fill out online application, analyze volunteer performance, provide training Contribution: –What are the results of the initiative that will add to the benefits to the system? E.g. automated report generation process, paperless application, insightful volunteer performance analysis Outcome: –Benefits that is contributed by the system such as improved volunteer management performance, faster application processing Assumption: –What are the conditions that have to be true in order to make this benefit chain to be true. ©USC-CSSE16

17. University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram ©USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering ©USC-CSSE Benefit Chain Diagram A good example 18

19. University of Southern California Center for Systems and Software Engineering ©USC-CSSE Benefit Chain Diagram A not so good example Common mistakes -Does not show the chain of benefits -Unclear initiative, outcome -Missing contribution -Incomplete benefit representation 19 Assumption: 1. No limits on no. of users 2. Stable support from CollectiveX for Network and Database functionality Implement the Web-based system depending on current system Developer s, IV and V Providing Tutorials to the Client and Users. Business firms, students and teachers Use the system functionalities System to be beneficiary to the client Client Enhance the capabilities of existing system WEB- Based application

20. University of Southern California Center for Systems and Software Engineering System Boundary and Environment Your project is responsible for what’s inside Illustrate the snapshot of the system at the deployment time (not development time) –the system List of services, modules –Stakeholders Their roles at the deployment/operation time E.g. Users, maintainers, students Common mistake – 577 developers (you will not be there at the deployment time) –Its environment Internet, scanner, external system –Infrastructure (platform, language, package) ©USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering System Boundary and Environment ©USC-CSSE21

22. University of Southern California Center for Systems and Software Engineering ©USC-CSSE22 System Boundary and Environment A good example

23. University of Southern California Center for Systems and Software Engineering System Transformation Information on Current System –Infrastructure –Artifacts –Current Business Workflow If this is a new (from manual to automatic) system, study how the transactions are done manually ©USC-CSSE23

24. University of Southern California Center for Systems and Software Engineering System Objectives, Constraints, and Priorities System objectives –Capability Goals OC-1 Central Order Processing: Orders may be (i) entered and processed directly via the Sierra Mountainbikes (SMB) central website and Enterprise Resource Planning (ERP) system, or, in the case of telephone or fax orders (ii) entered by SMB service personnel. Orders are validated interactively, using validation criteria editable by administrators. –Level of Service Goals –Organization Goals OG-1: Increase sales and profits via more efficient order processing. ©USC-CSSE24 LOS GoalsDesired LevelAcceptance LevelNotes Response time per entry (second)0.10.5Current system: 1

25. University of Southern California Center for Systems and Software Engineering System Constraints Examples: –CO-1: Windows as an Operating System: The new system must be able to run on Windows platform. –CO-2: Zero Monetary Budget: The selected NDI/NCS should be free or no monetary cost. –CO-3: Java as a Development Language: Java must be used as a development language. ©USC-CSSE25

26. University of Southern California Center for Systems and Software Engineering Element Relationship Diagram Summarizes the major relationships among the primary elements and external entities involved in the proposed new system. ©USC-CSSE26

27. University of Southern California Center for Systems and Software Engineering Element Relationship Diagram ©USC-CSSE27

28. University of Southern California Center for Systems and Software Engineering Element Relationship Diagram ©USC-CSSE28

29. University of Southern California Center for Systems and Software Engineering Business Workflow Diagram Represent the “work” flow from non- technical perspectives Use activity diagram Can be very simple ©USC-CSSE29

30. University of Southern California Center for Systems and Software Engineering Business Workflow Diagram ©USC-CSSE30

31. University of Southern California Center for Systems and Software Engineering 31 Similarity of OCD and LCP Just Answer the Simple Questions : - Why? - What? - When? - Who? - Where? - How? - How Much? - Whereas? Objectives to be achieved Milestones (dates) & Products (to be delivered) Responsibilities (individual And location/organization) Approach Resources, Quality Assumptions OCD does this for the system. LCP for the project

32. University of Southern California Center for Systems and Software Engineering 10 Reasons That Projects Fail 1.Scope Creep 2.Overallocated Resources 3.Poor Communications 4.Bad Stakeholder Management 5.Unreliable Estimates 6.No Risk Management 7.Unsupported Project Culture 8.The Accidental Project Manager 9.Lack of Team Planning Sessions 10.Monitoring and Controlling 32 http://project-management.com/top-10-reasons-why-projects-fail/

33. University of Southern California Center for Systems and Software Engineering Completion Percentage of Project Artifacts in Exploration – Valuation - Foundations Phases Exploration Valuation Foundations OCD20%80%95% SSRD5%80%87% SSAD0%30%90% UML0%30%90% LCP5%79%89% FED5%75%90%

34. University of Southern California Center for Systems and Software Engineering LCP 1. Introduction 1.1 Purpose of the LCP document 1.2 Status of the LCP document – Identify and document any differences between the contents of LCP and Win-Win negotiations. – Identify major LCP-related issues 34

35. University of Southern California Center for Systems and Software Engineering LCP 1. Introduction (Contd.) 1.3 Assumptions –Conditions Necessary to Meet Plans, which, if not realized, would require re-negotiation –Examples Requirements Stability Schedule Stability Continuity of Funding Delivery of Customer-Furnished Items, On-Schedule, and in Acceptable Condition Customer Response Time when Approvals are Required Other external dependencies (Hardware availability/performance, COTS availability/performance, satisfactory progress of other teams on other projects on which this one depends) 35

36. University of Southern California Center for Systems and Software Engineering 2. Milestones and Products (What? When?) 2.1 Overall Strategy –Describe the choice of process model to be used Depending upon: –Type of project : NDI-intensive, Custom, Other –Key stakeholders’ requirements –Schedule As Independent Variable (SAIV), which is required in a university course 36

37. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC CSSE37 Instructional Incremental Commitment Spiral Model – Software Engineering

38. University of Southern California Center for Systems and Software Engineering Example Project Schedule 38

39. University of Southern California Center for Systems and Software Engineering 39 Example Detailed Schedule

40. University of Southern California Center for Systems and Software Engineering 40 2.2.1 Exploration Phase During this phase, explore current system and identify initial scope of the system. 2.2.2 Valuation Phase During this phase, initial understanding of the desired system must be accomplished. This is achieved by defining the scope of the project so all stakeholders are in concurrence. Feasibility analysis and prioritization of the tasks must also be done here. 2.2.3 Foundations Phase During this phase, prototyping must demonstrate the architecture’s feasibility and stability. Risks and plans to minimize risk must also be assessed and developed in this phase. Additionally an appropriate development schedule should be created. Furthermore, cost estimates must also be conceived here. Moreover, an operational impact analysis must be completed to observe how useful the proposed would be to the customer and user. 2.2.4 Rebaselined Foundations Phase 2.2.5 Development Phase Example 2.3 Phase Deliverables and Completion Criteria ArtifactDue dateFormatMedium Client Interaction Report9/17/2006.doc,.pdfSoft copy Valuation Commitment Package  Operational Concept Description (OCD) Early Section  Life Cycle Plan (LCP) Early Section  Feasibility Evidence Description (FED) Early Section 09/18/2006.doc,.pdfSoft copy Evaluation of Valuation Commitment Package09/27/2006.xlsSoft copy Project EffortEvery MondayTextER system Project PlanEvery Wednesday.mpp,.pdfSoft copy Progress ReportEvery Wednesday.xlsSoft copy Risk AnalysisEvery WednesdayTextDART system For Milestones and suggested deliverables, check lecture 3

41. University of Southern California Center for Systems and Software Engineering 41 2.2 Project Deliverables -Provide a list of artifacts to be delivered. -The precise artifacts to be delivered depend upon your project’s type. -The contents of the list depend on the type of project -with certain COTS projects having different artifact delivery requirements than custom development projects, so an indication of the project type would be appropriate here. -For each artifact, provide its due date, format (word, pdf, etc) and delivery medium (hard copy, soft copy, etc). -

42. University of Southern California Center for Systems and Software Engineering 3. Responsibilities (Who? Where?) 3.1 Project – specific stakeholder’s responsibilities –Provide an overall summary of stakeholders’ responsibilities during the development of the project. –Include the responsibilities of each stakeholders – or group of stakeholders -- for each phase 42

43. University of Southern California Center for Systems and Software Engineering 577 Project Roles Roles – Exploration, Valuation, Foundations phases –Project Manager –Operational Concept Engineer –Requirements Engineer –Prototyper –Software Architect –Life Cycle Plan –Feasibility Analyst –Quality Focal Point Roles – Development phase –Implementer –Tester –Trainer 43

44. University of Southern California Center for Systems and Software Engineering 3.2 Responsibilities By Phase For each member of the development team, identify his/her role and his/her primary and secondary responsibility during the various phases of the development. Identify the stakeholder representative(s) who is/are authorized to approve any change(s) in project scope, budget or schedule along with the organization that each one represents. Check the ICSM EPG for guided responsibilities 44

45. University of Southern California Center for Systems and Software Engineering 3.3 Skills Identify skills required for each role. If you are looking for a team member(s) to join your team in CSCI577b, please identify expected roles, responsibilities, and skills of your new team member(s) 45

46. University of Southern California Center for Systems and Software Engineering 4. Approach 4.1 Monitoring and Control –4.1.1 Closed loop feedback control –4.1.2 Reviews –Check EC-10 for QM strategies 4.2 Methods, Tools, and Facilities 46

47. University of Southern California Center for Systems and Software Engineering 5. Resources COCOMO Analysis –Provide COCOMOII effort and schedule estimates. –Explain how values were chosen for the various parameters. –Analyze the COCOMOII estimation result 47 Note : you may use COINCOMO tool Check COINCOMO Tutorial for more information http://greenbay.usc.edu/csci577/fall2013/tools

48. University of Southern California Center for Systems and Software Engineering Example of COCOMO II calculation 48 No.Module NameBrief DescriptionSLOCREV L 1Plant Service Recording Provide plant service recording system for worker 100010% 2Plant Service Management Provide plant service management system for manager 370010% 3AuthenticationUser authentication and authorization mechanism 3005% 4UtilityProvide essential utilities supporting the system 1005% 5Barcode GeneratingGenerate barcode using NDI, Barbecue java library 35610%

49. University of Southern California Center for Systems and Software Engineering Example of COCOMO II Scale Drivers 49 Scale DriverValueRationale PRECHIGHThe development team is familiar with this type of online application. Although, concurrent development associates with extensive new hardware and operational procedures. FLEXHIGHThe system needs to considerably conform to pre-established requirement from the client and external interface specifications, e.g. GPRS services and Internet protocols. RESLHIGHAll critical risk items, schedule, budget and internal milestones are identified. However, there is some uncertainty in hardware compatibility. TEAMHIGHEach stakeholder has considerable consistency of objectives and cultures, and considerable ability and willingness to accommodate others’ objectives. In addition, the stakeholders have basic experience in operating as a team. PMATNOMINALThe development team follows ICSM-EPG, which the processes are defined and repeatable but the result may not be consistent, CMM Level 2.

50. University of Southern California Center for Systems and Software Engineering Example of COCOMOII Cost factors 50 Cost DriverValueRationale RELYNOMIN AL Although, some modules in this project depend on this module, the effect of the software failure is moderate and losses are easily recoverable. DATALOWThe ratio of bytes in the testing database to SLOC in the program is approximately less than 10 because the database will store only information of plant services, which are employee id, check-in time, check-out time, each plant conditions, and short comments, of 20 locations in each week. DOCUNOMIN AL Because the development process follows ICM-EPG, the document for life-cycle needs is normal. CPLXNOMIN AL It contains simple message passing control, standard math and statistical routines for generating reports, and simple I/O process includes device selection from bar code scanner or user interface, status checking of bar code scanner, and error processing. Additionally, it has simple structural changes and uses simple widget set. RUSELOWIt is not intended to be reused for the future project. TIMENOMIN AL The percentage of available execution time expected to be used by the system and subsystem consuming the execution time resource is less than 50% because this system is used when a worker does plant services which are preformed once a week, and this system is used by a manager to review plant service reports which at most couple times a week. STORNOMIN AL The percentage of available storage expected to be used by the system and subsystem is less than 50% because the most data is general text and the information of plant services such as plant conditions and comments are condensed. PVOLLOWMajor changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year. ACAPVERY HIGH The analysts have the ability to analyze, design, communicate, and cooperate very well. PCAPVERY HIGH Programmers are capable, efficient and thorough. They are able to communicate and cooperate very well. PCONNOMIN AL We have 8 team members in CSCI577a and 5 team members in CSCI 577b that suitable for our project sizing. APEXNOMIN AL The average experience of the team members for this online web-based application is about one year. LTEXNOMIN AL The development team plans to develop this web-based application with JSP, HTML, and Java script, and uses SQL language to query information from the database. The tools for programming are Dreamweaver and Eclipse. Therefore, the language and tool experience is nominal because team members have at least one year experience with these languages and tools. PLEXLOWThe server platform is web server Apache Tomcat with JDK version 1.5, and database is MySQL. Although, all developers have this platform experience, this module need implementation an user interface on PDA and input with bar code scanner which our developers have less experience. TOOLLOWThe software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle. SITEVERY HIGH Six of eight team members are on-campus students; only two team members are off-campus students. Additionally, we use wideband electronic communication and occasional video conference. SCEDNOMIN AL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester. COCOMOII Cost Drivers of Module 1 Plant Service Recording module Cost DriverValueRationale RELYNOMINALAlthough, some modules in this project depend on this module, the effect of the software failure is moderate and losses are easily recoverable. DATALOWThe ratio of bytes in the testing database to SLOC in the program is approximately less than 10 because the database will store only information of plant services, which are employee id, check-in time, check-out time, each plant conditions, and short comments, of 20 locations in each week. DOCUNOMINALBecause the development process follows ICM-EPG, the document for life-cycle needs is normal. CPLXNOMINALIt contains simple message passing control, standard math and statistical routines for generating reports, and simple I/O process includes device selection from bar code scanner or user interface, status checking of bar code scanner, and error processing. Additionally, it has simple structural changes and uses simple widget set. RUSELOWIt is not intended to be reused for the future project. TIMENOMINALThe percentage of available execution time expected to be used by the system and subsystem consuming the execution time resource is less than 50% because this system is used when a worker does plant services which are preformed once a week, and this system is used by a manager to review plant service reports which at most couple times a week. STORNOMINALThe percentage of available storage expected to be used by the system and subsystem is less than 50% because the most data is general text and the information of plant services such as plant conditions and comments are condensed. PVOLLOWMajor changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year. ACAPVERY HIGH The analysts have the ability to analyze, design, communicate, and cooperate very well. PCAPVERY HIGH Programmers are capable, efficient and thorough. They are able to communicate and cooperate very well. PCONNOMINALWe have 8 team members in CSCI577a and 5 team members in CSCI 577b that suitable for our project sizing. APEXNOMINALThe average experience of the team members for this online web- based application is about one year. LTEXVERY LOW The development team plans to develop this web-based application with JSP, HTML, and Java script, and uses SQL language to query information from the database. The tools for programming are Dreamweaver and Eclipse. Although, the language and tool experience is nominal because team members have experience with these languages and tools, this module is developed by using NDI java library for bar code generating that our developers have no experience. PLEXNOMINALThe server platform is web server Apache Tomcat with JDK version 1.5, and database is MySQL. All developers have this platform experience at least one year. TOOLLOWThe software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle. SITEVERY HIGH Six of eight team members are on-campus students; only two team members are off-campus students. Additionally, we use wideband electronic communication and occasional video conference. SCEDNOMINALThe schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester. COCOMOII Cost Drivers of Module 5 Barcode Generating module ………..

51. University of Southern California Center for Systems and Software Engineering COCOMOII Estimation Result Justify your estimation result –Doable with 6 person team ? If not, then ? –More info about COCOMO II on EC07-Cost Estimation 51

52. University of Southern California Center for Systems and Software Engineering 10 Reasons That Projects Fail 1.Scope Creep 2.Overallocated Resources 3.Poor Communications 4.Bad Stakeholder Management 5.Unreliable Estimates 6.No Risk Management 7.Unsupported Project Culture 8.The Accidental Project Manager 9.Lack of Team Planning Sessions 10.Monitoring and Controlling 52 http://project-management.com/top-10-reasons-why-projects-fail/