Operational Concept Description CS 577a, Fall 2015 ©USC-CSSE

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-CSSE

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.”** * 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 ©USC-CSSE

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 * 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 ©USC-CSSE

https://wiki. umiacs. umd https://wiki.umiacs.umd.edu/adapt/images/1/11/Concept-of-operations-2.pdf

Business Model Generation More info at EP09 – Business Model Generation

Business Model Canvas More info at EP09 – Business Model Generation

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-CSSE

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

Example: Apple iPod/iTunes Business Model

Operational Concept Definition (OCD) Purpose of the OCD To describe the success critical (key) stakeholders’ shared vision of the project being undertaken. 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 ©USC-CSSE

OCD Content and Completion Criteria VC Package FC 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-CSSE

Shared Vision ©USC-CSSE

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-CSSE

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-CSSE

Benefit Chain Diagram Stakeholder(s): Initiative: Contribution: 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-CSSE

Benefit Chain Diagram ©USC-CSSE

Benefit Chain Diagram A good example ©USC-CSSE

Benefit Chain Diagram A good example ©USC-CSSE

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

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-CSSE

System Boundary and Environment ©USC-CSSE

System Boundary and Environment A good example ©USC-CSSE

System Boundary and Environment A good example ©USC-CSSE

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-CSSE

System Objectives, Constraints, and Priorities 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. LOS Goals Desired Level Acceptance Level Notes Response time per entry (second) 0.1 0.5 Current system: 1 ©USC-CSSE

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-CSSE

Element Relationship Diagram Summarizes the major relationships among the primary elements and external entities involved in the proposed new system. ©USC-CSSE

Element Relationship Diagram ©USC-CSSE

©USC-CSSE

Element Relationship Diagram ©USC-CSSE

©USC-CSSE

Business Workflow Diagram Represent the “work” flow from non-technical perspectives Use activity diagram Can be very simple ©USC-CSSE

Business Workflow Diagram ©USC-CSSE

©USC-CSSE