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