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 Unix-based, 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 individualapplications and verify the existence of atleast one feasible architecture for each application.

Cycle 2. Establish a specific, detailed life-cyclearchitecture (LCA milestone), verify its feasibility,and determine that there are no major risks insatisfying the plans and specifications.

Cycle 3. Achieve a workable initial operationalcapability (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 nota rigorous specification, but a team ofstakeholders with enough trust andshared vision to adapt effectivelyto 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

Freeze In Technology Decisions

State Of The Market Today

Frenzy Of Technology Spending

Dot-com BoomInfrastructure Boom

Click-And-Mortar Race

Dot-com BustInfrastructure Crash

Click-And-Mortar Survival

Real E-BusinessBuild Resilient IT

Strategic New Initiatives

Strong EconomyInternet Euphoria

Time-to-market DemandsQuick Buying Decisions

Weak ROI Models

Weak EconomyShrinking Revenues

Focus on IT Cost ControlBusiness Outlook UnclearProjects Frozen / On Hold

US: Slow RecoveryEU: Flat Market

Challenging Stock MarketSelective Projects

Decision Cycles ImprovingFocus 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* 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: block diagrams collaboration diagrams sequence diagrams state transition diagrams (state overviews, activity diagrams, concurrent

states) 1974-82: the first object modeling standard SDL adopts those

techniques 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 functional spec’s software architecture description functional descr’s, block descriptions, separate from interface (signal)

descriptions functional tests and system test

1987-95 The Objectory Process 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 MarketplaceA component industry including

Component factories provide ‘components’ System Integrators reuse these ‘components’ ‘Components’ are component systems used

to build families of application systemsWe need a standard for playing on this marketplace

How to design for reuse How to design with reuse

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

Reuseable AssetsReuseable Assets

The Reuse Initiative: e-Development Accelerator

ReusableFrameworksReusableFrameworksReuse StandardsReuse Standards

AutomationAutomation

Open UML-based standard Open UML-based standard expressing how to document expressing how to document and produce reusable assets.and produce reusable assets.

Open UML-based standard Open UML-based standard expressing how to document expressing how to document and produce reusable assets.and produce reusable assets.

Technology or domain specific Technology or domain specific reusable assets with associated reusable assets with associated guidelines on usage.guidelines on usage.

Technology or domain specific Technology or domain specific reusable assets with associated reusable assets with associated guidelines on usage.guidelines on usage.

Tool support for creating, Tool support for creating, managing, and reusing managing, and reusing software assets.software assets.

Tool support for creating, Tool support for creating, managing, and reusing managing, and reusing software assets.software assets.

ComponentSystem

ComponentSystem

ComponentSystem

ApplicationSystem

ApplicationSystem

ApplicationSystem

ComponentSystem

ComponentSystem

Layered System Architecture

Car Sales ManagementCar Sales

Management

Customer profileOrder managementCustomer profile

Order management

Shopping cartCredit card

authorization

Shopping cartCredit card

authorization

Object persistency mechanism

Object persistency mechanism

Examples of Examples of reusable objectreusable object

Application-general layer

Middleware layer

Application-specificlayer

System-softwarelayer

ComponentSystem

ComponentSystem

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

“bugs are nice, defects are bad” “some developers make the dirt, others (customers) clean up”

Process change 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)

My Unified Process

My Project

My tasks

Is specialized to

Is enacted as

And to

Process gets soul: people may be humans

Static Dynamic

StructuredRe-Invent

GenericLong-Term

Learn

CreativeReuseStreamlined and PersonalizedShort-TermDo

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.

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.

Software Components, but… Autonomous Pro-Active Encapsulate Knowledge as Rules Adaptive

Agents

Agent(in software)

Each Developer has its Own Personal Agent

Personal Agent(for Joe)

Joe(Developer)

Individuals play roles in software development

Individuals play roles in software development www.jaczone.com

Every Role in RUP is Matched to One Agent

System Analyst

Role Agent(for System Analyst)

Agent System

www.jaczone.com

Personal Agents and Role Agents

Personal Agent(for Joe)

Joe(Developer)

Role Agent(for System Analyst)

Role Agent(for Business-Process Analyst)

Agent System

Since a developer can play many roles his/her personal agent may collaborate with several role agentsSince 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 agentswww.jaczone.com

A Complete UML Based Platform

An executable UML a programming language (or a set of PL’s) Java, C++ become superfluous combines graphical and program-like syntax

Semantics of changes -- functional and structural -- defined by UML language defined configuration and version management

Removing seams (or gaps) between UML and operating systems and database mgmt systems computer architectures

An executable UML a programming language (or a set of PL’s) Java, C++ become superfluous combines graphical and program-like syntax

Semantics of changes -- functional and structural -- defined by UML 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"Function Distribution in Computer System Architectures”, Harold “Bud” Lawson, 1976

Every Layer of Components described in UML Systemware components

operating systems database management systems

Middleware components Customer relationship management Content management Change management

Application general components Subscriber management Digit analysis node Route data

Trend: Focus moves upwards

Use cases generate test cases and input to analysis

Analysis will generate implementation; design will become superfluous

Req.ts Impl. TestAnalysis Design

More “generation”=work elimination

NowNow

TomorrowTomorrow

Tomorrow, Life will be Much Better!

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

SummarySummary

Readings by Ivar Jacobson

Unified Software Development ProcessJacobson, Booch, Rumbaugh, Addison Wesley Longman (1999)

Object-Oriented Software Development--A Use Case Driven Approach (Addison Wesley)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)