University of Southern California Center for Systems and Software Engineering Incremental Commitment Spiral Model for CSCI577 (c) 2007-2013 USC-CSSE 1 University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC-CSSE IICSM-Sw Project Artifacts 2 University of Southern California Center for Systems and Software Engineering Success Critical Criteria for each milestone Foundations Commitment 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 Development Commitment Review • 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 (c) 2007-2013 USC-CSSE Transition Readiness Review • 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 University of Southern California Center for Systems and Software Engineering ICSM-Sw & P3S Invariants and Variants Invariants Variants 1. Defining and sustaining a stakeholder winwin relationship through the system's lifecycle. 1. Use of particular success, process, product, or property models. 2. Using the ICSM-Sw & P3S Model Integration Framework. 3. Degree of detail of process, product, property, or success modeling. 3. Using the ICSM-Sw & P3S Process Integration Framework. 4. Number of risk-driven cycles or builds between anchor points. 4. Using the ECR, VCR, FCR, DCR, IOC and OCR Anchor Point milestones. 5. Mapping of activities onto Exploration, Valuation, Foundations, Construction, Transition phases. 5. Ensuring that the contents of ICSM-Sw & P3S artifacts and activities are risk-driven. 6. Mapping of staff levels onto activities. 2. Choice of process or product representation. (c) 2007-2013 USC-CSSE 4 University of Southern California Center for Systems and Software Engineering RUP & ICSM Anchor Points Enable Concurrent Engineering (c) 2007-2013 USC-CSSE 5 University of Southern California Center for Systems and Software Engineering Operational Concept Description CS 577a, Fall 2013 ©USC-CSSE 6 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-CSSE 7 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.”** * 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 8 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 * 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 9 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 University of Southern California Center for Systems and Software Engineering Business Model Generation More info at EP09 – Business Model Generation 11 University of Southern California Center for Systems and Software Engineering Business Model Canvas More info at EP09 – Business Model Generation 12 University of Southern California Center for Systems and Software Engineering 13 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-CSSE 14 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 University of Southern California Center for Systems and Software Engineering Example: Apple iPod/iTunes Business Model 16 University of Southern California Center for Systems and Software Engineering 17 University of Southern California Center for Systems and Software Engineering Operational Concept Definition (OCD) 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 ©USC-CSSE 18 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-CSSE 19 University of Southern California Center for Systems and Software Engineering Shared Vision ©USC-CSSE 20 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-CSSE 21 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-CSSE 22 University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram • Stakeholder(s): – • Initiative: – • 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: – • 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 success critical stakeholders who create and receive benefits from the developing system? E.g. Development team, Volunteer, Manager 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 23 University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram ©USC-CSSE 24 University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram • A good example ©USC-CSSE 25 University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram • A good example Assumptions: High availability of the system during users' work time. High-speed Internet connections. Users are trained to utilize this system. Developers, IIV&V Develop the system "Project Paper Less" Providing training for users and maintainer Faster file management and process Less paper Faster case consumption management and Improved file management and auditing process Computer-aided form filling process and instant submission Faster file retrive Faster case management and improved verification Comment instantly available to others Fill out forms and submit them Faster information processing and better integrity Increased productivity Faster file retrive ,more convenient case control and evaluation Comment on submitted files View files on cases Spervisor Program Director Internal Auditor Specialty worker Access files on case Case managers Case managers Program Director Finance Biller Legend: Contribution ©USC-CSSE Initiative Outcome Stakeholder 26 University of Southern California Center for Systems and Software Engineering Benefit Chain Diagram Assumption: 1. No limits on no. of users 2. Stable support from CollectiveX for Network and Database functionality Business firms, students and teachers Developers , IV and V A not so good example Common mistakes 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 WEBBased application - Does not show the chain of benefits Unclear initiative, outcome Missing contribution Incomplete benefit representation System to be beneficiary to the client Client ©USC-CSSE 27 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-CSSE 28 University of Southern California Center for Systems and Software Engineering System Boundary and Environment ©USC-CSSE 29 University of Southern California Center for Systems and Software Engineering System Boundary and Environment • A good example ©USC-CSSE 30 University of Southern California Center for Systems and Software Engineering System Boundary and Environment • A good example ©USC-CSSE 31 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-CSSE 32 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 LOS Goals Desired Level Acceptance Level Notes Response time per entry (second) 0.1 0.5 Current system: 1 – Organization Goals • OG-1: Increase sales and profits via more efficient order processing. ©USC-CSSE 33 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-CSSE 34 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-CSSE 35 University of Southern California Center for Systems and Software Engineering Element Relationship Diagram ©USC-CSSE 36 University Southern ProjectofPaper Less California Center for Systems and Software Engineering Automatic Form Population Case Management System Activate Permission assignment records Specialty Worker Submit files Submit and review files, create case activities, assign persons to activities. Review files and comment on them Case Manager Authentication Case records Group-based Permission System Case records and file records Groups records and permission assignment records Finance biller Program director Supervisor Internal Auditor User Account Name Password Grant/Revoke permissions System notification System Adminitrator Check/Review System log record/ System modification record Add/Remove accounts Database Account records Account Management System Maintain database function and performance maintainer ©USC-CSSE 37 University of Southern California Center for Systems and Software Engineering Element Relationship Diagram ©USC-CSSE 38 University of Southern California Center for Systems and Software Engineering ©USC-CSSE 39 University of Southern California Center for Systems and Software Engineering Business Workflow Diagram • Represent the “work” flow from nontechnical perspectives • Use activity diagram • Can be very simple ©USC-CSSE 40 University of Southern California Center for Systems and Software Engineering Business Workflow Diagram ©USC-CSSE 41 University of Southern California Center for Systems and Software Engineering ©USC-CSSE 42