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)