1. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC-CSSE Incremental Commitment Spiral Model for CSCI577 1

2. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC-CSSE IICSM-Sw Project Artifacts 2

3. University of Southern California Center for Systems and Software Engineering Success Critical Criteria for each milestone (c) 2007-2013 USC-CSSE Foundations Commitment Review Development Commitment Review Transition Readiness Review For at least one architecture, a system built to architecture will: Support the Operational Concept Satisfy the Requirements Be faithful to the prototype(s) Be buildable within the budgets and schedules in the Plan Show viable business case Most major risks identified and resolved or covered by risk management plan Key stakeholders committed to support Foundations Phase For the selected architecture, a system built to the arch. will: Support the Ops Concept Satisfy the Requirements Be faithful to the Prototype(s) Be buildable within the budgets and schedules in the Plan All major risks resolved or covered by risk management plan Key stakeholders committed to support full life cycle Show value Product works as expected (or with addressable exceptions) Product will help users do job Show quality development As-Built Documentation V&V results Show sustainability Support requirements/plans Transition plan & status: training, installation, usage test Show confidence that product is/will be ready to be used 3

4. University of Southern California Center for Systems and Software Engineering ICSM-Sw & P 3 S Invariants and Variants (c) 2007-2013 USC-CSSE 1. Use of particular success, process, product, or property models. 2. Choice of process or product representation. 3. Degree of detail of process, product, property, or success modeling. 4. Number of risk-driven cycles or builds between anchor points. 5. Mapping of activities onto Exploration, Valuation, Foundations, Construction, Transition phases. 6. Mapping of staff levels onto activities. 1. Defining and sustaining a stakeholder win- win relationship through the system's life- cycle. 2. Using the ICSM-Sw & P3S Model Integration Framework. 3. Using the ICSM-Sw & P3S Process Integration Framework. 4. Using the ECR, VCR, FCR, DCR, IOC and OCR Anchor Point milestones. 5. Ensuring that the contents of ICSM-Sw & P3S artifacts and activities are risk-driven. VariantsInvariants 4

5. University of Southern California Center for Systems and Software Engineering RUP & ICSM Anchor Points Enable Concurrent Engineering (c) 2007-2013 USC-CSSE5

6. University of Southern California Center for Systems and Software Engineering Operational Concept Description CS 577a, Fall 2013 ©USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering ICSM Practices Main ICSM Practices in CSCI577 –Operational Concept Development –System and Software Requirements Development –Prototyping –System and Software Architecture Development –Life Cycle Planning –Feasibility Evidence Development –Testing –Quality Management ©USC-CSSE7

8. University of Southern California Center for Systems and Software Engineering Operational Concept Definition (OCD) A concept of operations –( CONOPS, CONOPs, or ConOps, or OpsCons) “a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system”* “a user-oriented document that describes systems characteristics for a proposed system from a user's perspective.”** ©USC-CSSE8 * http://standards.ieee.org/findstds/standard/1362-1998.html ** http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/concept_ops.html

9. University of Southern California Center for Systems and Software Engineering Operational Concept Definition (OCD) Is used to communicate quantitative and qualitative system characteristics to all stakeholders. describes the proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used ©USC-CSSE9 * http://en.wikipedia.org/wiki/Concept_of_operations ** http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/concept_ops.html

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

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

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

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

14. University of Southern California Center for Systems and Software Engineering Success-critical stakeholders Success- Critical Stakeholders (SCS) –Common SCS: system’s user, client, customer maintainer, developer. –Project-specific SCS supplier, actor, volunteer, vendor, researcher –Key stakeholders should have CRACK characteristics CRACK: Collaborative, Representative, Authorized, Committed, and Knowledgeable ©USC-CSSE14

15. 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 15

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

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

18. University of Southern California Center for Systems and Software Engineering Operational Concept Definition (OCD) ©USC-CSSE18 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

19. 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-CSSE19

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

21. 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-CSSE21

22. 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-CSSE22

23. 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-CSSE23

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

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

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

27. 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 27 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 Developers, 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

28. University of Southern California Center for Systems and Software Engineering System Boundary and Environment 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-CSSE28

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

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

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

32. 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-CSSE32

33. 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-CSSE33 LOS GoalsDesired LevelAcceptance LevelNotes Response time per entry (second)0.10.5Current system: 1

34. 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-CSSE34

35. 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-CSSE35

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

37. University of Southern California Center for Systems and Software Engineering ©USC-CSSE37

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

39. University of Southern California Center for Systems and Software Engineering ©USC-CSSE39

40. 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-CSSE40

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

42. University of Southern California Center for Systems and Software Engineering ©USC-CSSE42