Software Development as a Business Process: the Role of
Download
Report
Transcript Software Development as a Business Process: the Role of
RISK ASSESSMENT
Risk Assessment
Definition: “Risk…merely identifies the
undesirable events that might take
place during the project” [Jalote, 1998]
Three Types:
Cost risk
Performance Risk
Schedule Risk
Risk Assessment
Major Risks Encountered in SD
Vague Requirements
Costs and Schedule Estimation
Hidden Costs
Communication Breakdowns
Poor Architecture
Personnel Shortfalls
Software Development- A320
Blunder
Risk Assessment
Risk Reduction
Prototyping
Simulation
Benchmarking
References, Off-the-Shelf Components
Questionnaires
Analytic Modeling
Design Techniques
Standardizing Specification Techniques
UML Modeling Language
SCR/A7-E Specification Technique
Design Techniques
Top Down Functional Decomposition
Information Hiding
Object Oriented Design
Modern Software
Development
Move to OO Designs
Formal Modeling Languages
Emphasis on Documentation
Role of Discrete Mathematics
Formal languages for testing systems
Spiral Model Case Study
Purpose: Experimental validation of this
approach
The case study involved extending
USC’s Integrated Library System to
access multimedia archives, including
films, maps, and videos.
What were they trying to
build/show?
The Integrated Library System is a Unixbased, text-oriented, client-server system
designed to manage the acquisition,
cataloging, public access, and circulation of
library material.
The study’s specific goal was to evaluate the
feasibility of using the spiral model to build
applications written by USC graduate student
teams.
Cycles of the Spiral Model
Cycle 0. Determine the feasibility of an appropriate
family of multimedia applications.
Cycle 1. Develop life-cycle objectives (LCO milestone),
prototypes, plans, and specifications for individual
applications and verify the existence of at
least one feasible architecture for each application.
Cycle 2. Establish a specific, detailed life-cycle
architecture (LCA milestone), verify its feasibility,
and determine that there are no major risks in
satisfying the plans and specifications.
Cycle 3. Achieve a workable initial operational
capability (IOC milestone) for each project
Results
From the 16 projects in the first semester, the
clients selected five applications for
development according to the library’s
commitment to sustain them after the second
semester (IOC). Four are now transitioning to
library operations, and the fifth has good
prospects for transition after refinement this
summer.
The librarians were delighted with the final
presentations.
Lessons Learned
The most important
outcome of product definition is not
a rigorous specification, but a team of
stakeholders with enough trust and
shared vision to adapt effectively
to unexpected changes.
Don’t finish negotiations before prototyping. If you
do, the agreements destabilize once the clients see
the prototypes.
For projects of this size, using a single cycle each for
the LCO and LCA milestones was about right.
Software Development as a
Business Process
State of the Market Today:
The Frenzy, The Freeze, And After
Frenzy Of Technology
Spending
State Of The
Market Today
Freeze In Technology
Decisions
Dot-com Boom
Infrastructure Boom
Click-And-Mortar Race
Dot-com Bust
Infrastructure Crash
Click-And-Mortar Survival
Real E-Business
Build Resilient IT
Strategic New Initiatives
Strong Economy
Internet Euphoria
Time-to-market Demands
Quick Buying Decisions
Weak ROI Models
Weak Economy
Shrinking Revenues
Focus on IT Cost Control
Business Outlook Unclear
Projects Frozen / On Hold
US: Slow Recovery
EU: Flat Market
Challenging Stock Market
Selective Projects
Decision Cycles Improving
Focus on ROI Justification
Growing Demand For Outsourcing
The 1980 Letter to The CEO of Ericsson*
The component-based development approach used
for AKE/AXE will evolve into a world standard
Go further in three steps
1983: a standard method including a modeling language
and a process, supported by a first generation tool-set
1985: the modeling language becomes a formal
executable language
1990: expert system on top of software process and
development tool; “end-user programming”
* Björn Svedberg
Component-Based
Architectures
Originated 1967-70 at Ericsson
for real-time, distributed systems:
blocks a k o components,
design
code
executables
run-time objects
interfaces based on signals,
functions crossed blocks -- or realized as collaborations among blocks
Components have become the standard.
No new development paradigm to replace components in sight!
Modeling Languages
1967-70: The AKE/AXE modeling language:
1974-82: the first object modeling standard SDL adopts those techniques
block diagrams
collaboration diagrams
sequence diagrams
state transition diagrams (state overviews, activity diagrams, concurrent states)
nicknamed ‘The Ericsson Language’
In parallel Entity-Relationship modeling emerged
1987: Objectory modeling language combined SDL and ER technologies,
added Use Cases and Multi-Modeling.
1996: The Unified Modeling Language
based on Objectory, Booch and OMT from 1991
plus many other modeling ideas
The standard modeling language
UML 2.0 a major new release, followed by more...
Development Process
1967-70 The AKE/AXE method
1987-95 The Objectory Process
functional spec’s
software architecture description
functional descr’s, block descriptions, separate from interface (signal)
descriptions
functional tests and system test
engineered process to facilitate specializations and instantiations (projects)
use cases drive the business track, the system track and the user track
1996-2000: The Rational Unified Process
iterative development
architecture-centric
tool support for process engineering and process instantiations
de-facto standard for e-development
Future of Software
We have the standard modeling language
We have a standard development process
What next?
A Software Component Marketplace
Quality from the Beginning
Give Soul to Software Process
A Complete UML Based Software Platform
A Software Component
Marketplace
A component industry including
Component factories provide ‘components’
System Integrators reuse these ‘components’
‘Components’ are component systems used to
build families of application systems
We need a standard for playing on this
marketplace
How to design for reuse
How to design with reuse
Reuseable Assets
Reuse of all models, that is of everything
architecture -- most important but just a
fraction of what is reusable
use cases, analysis, design, implementation
and test
user interface models, business models, etc.
Reuse of technology
process with tools
projects
guidelines
The Reuse Initiative: eDevelopment Accelerator
Technology or domain specific
reusable assets with associated
guidelines on usage.
Reuse Standards
Open UML-based standard
expressing how to document
and produce reusable assets.
Reusable
Frameworks
Automation
Tool support for creating,
managing, and reusing
software assets.
Layered System Architecture
Examples of
reusable object
Application-specific
layer
Application-general
Application
System
Component
System
Application
System
Component
System
Application
System
Component
System
Car Sales
Management
Customer profile
Order management
layer
Middleware layer
Component
System
Component
System
System-software
layer
Component
System
Component
System
Shopping cart
Credit card
authorization
Object persistency
mechanism
Quality from the Beginning
We have lost two generations of developers who think they just need
to debug at the end, when they instead shouldn’t introduce any defects
along the way.
An attitude problem
Process change
“bugs are nice, defects are bad”
“some developers make the dirt, others (customers) clean up”
verify and test along the way -- activity-based verification
there is no test model, test artifacts are part of all models
New tools
generate test cases from requirements, analysis, design...
Activity-Based Verification
Whatever you do, you are not done until you
have verified that you did what you wanted to
do.
Introduce verification on activities
Each activity-artifact pair needs a Verification Case
Each Verification Case has a corresponding
Verification Step
Test Cases are specializations of Verification Cases,
related to the executable system
Software Process Comes Alive
Development steps
The process at your fingertips
The process gets soul
the third step 20 years ago
a software engineering breakthrough
technology
The Process at Your Fingertips
Rational Unified
Process
(RUP)Is specialized
to
My Unified
Process
Is enacted as
My Project
And to
My tasks
Process gets soul: people
may be humans
Traditional
processes hold
static rules and
regulations, but
lacks “soul” and
adaptive
capabilities. They
appeal to
structured
reasoning, but not
to the creative
(lateral) spirit.
Static
Structured
Re-Invent
Generic
Long-Term
Learn
Dynamic
Creative
Reuse
Streamlined and Personalized
Short-Term
Do
Agents
Software Components, but…
Autonomous
Pro-Active
Encapsulate Knowledge as Rules
Adaptive
Agent
(in software)
Each Developer has its Own
Personal Agent
Personal Agent
(for Joe)
Joe
(Developer)
Individuals play roles in software development
www.jaczone.com
Every Role in RUP is Matched to One
Agent
Agent System
Role Agent
(for System Analyst)
www.jaczone.com
System Analyst
Personal Agents and Role Agents
Agent System
Role Agent
(for System Analyst)
Personal Agent
(for Joe)
Joe
(Developer)
Role Agent
(for Business-Process Analyst)
Since a developer can play many roles his/her personal agent
may collaborate with several role agents
Specialist Agents
Rule agents
Reuse agents suggest candidate patterns, frameworks, etc
Workflow agents suggest micro-activities based on state
Conversation agents for conversational modeling
Model completion agents
Round-trip modeling agents between all kinds of models
Evaluation agents
Broker agents
www.jaczone.com
A Complete UML Based
Platform
An executable UML
Semantics of changes -- functional and structural -- defined
by UML
a programming language (or a set of PL’s)
Java, C++ become superfluous
combines graphical and program-like syntax
language defined configuration and version management
Removing seams (or gaps) between UML and
operating systems and database mgmt systems
computer architectures
"Function Distribution in Computer System Architectures”,
Harold “Bud” Lawson, 1976
Every Layer of Components
described in UML
Systemware components
Middleware components
operating systems
database management systems
Customer relationship management
Content management
Change management
Application general components
Subscriber management
Digit analysis node
Route data
Trend: Focus moves upwards
Req.ts
Analysis
Design
Impl.
Test
More “generation”=work elimination
Now
Tomorrow
Use cases generate test cases and input to analysis
Analysis will generate implementation; design will
become superfluous
Summary
We have UML, RUP and tools
Eventually we will get a Component Industry
We will do things right from the beginning
Process will get soul -- developers are people and
people are humans
We will get rid of seams and gaps between levels
Tomorrow, Life will be Much
Better!
Readings by Ivar Jacobson
Unified Software Development Process
Object-Oriented Software Development--A Use Case
Driven Approach (Addison Wesley)
Jacobson, Booch, Rumbaugh, Addison Wesley Longman (1999)
Ivar Jacobson, Addison Wesley Longman (1992)
The Object Advantage: Business Process Reengineering
with Objects (Addison Wesley)
Ivar Jacobson, Addison Wesley Longman (1994)
Software Reuse: Architecture, Process and Organization
for Business Success (Addison Wesley)
Ivar Jacobson, Addison Wesley Longman (1997)
The Road to the Unified Software Development Process
Ivar Jacobson, Stefan Bylund, Cambridge University Press, 2000
Special readings
Software Reuse: Architecture, Process and
Organization
for Business Success (Addison Wesley)
Ivar Jacobson, Addison Wesley Longman (1997)
Function Distribution in Computer System
Architectures,
Harold “Bud” Lawson (1976)