IT4520- KINH T CNG NGH PHN MM (SOFTWARE ECONOMICS) Nm hc 2010-2011

Ging vin: PGS. TS.Hunh Quyt Thng BM Cng ngh phn mm Vin CNTT-TT, HBK HN

Value-Based Software Engineering (VBSE) Software Models and Processes

Example: Software Testing

Assume Youre the manager of a $2M S/W project, Vendor (ATG) Proposition

Cut your test costs in half (test cost: $1M) Provide it to you the use of the tool for 30% of
your test costs (or $300K) Save 50% of your original cost (or $500K), youre ahead of 20% (or $200K)

Any Concerns with vendor proposition??

Pareto: 80% Value from 20% Components

Source: Experience Report (Bullock. 2000)

VB Testing: More Net Value

ROI = (benefit cost) / cost

Pareto: Much higher ROI 1.74

Poor Investment

Motivation for Value-Based SE

Current SE methods are basically value-neutral

Every requirement, use case, object, test case, and defect is equally important Object oriented development is a logic exercise Earned Value Systems dont track business value Separation of concerns: SEs job is to turn requirements into verified code Ethical concerns separated from daily practices

Value neutral SE methods are increasingly risky

Software decisions increasingly drive system value Corporate adaptability to change achieved via software decisions System value-domain problems are the chief sources of software project failures

The Separation of Concerns Legacy

The notion of user cannot be precisely defined, and therefore has no place in CS or SE.
- Edsger Dijkstra, ICSE 4, 1979

Analysis and allocation of the system requirements is not the responsibility of the SE group but is a prerequisite for their work
- Mark Paulk at al., SEI Software CMM* v.1.1, 1993 *Capability Maturity Model

Resulting Project Social Structure

I wonder when they'll give us our requirements?

SOFTWARE

AERO. MGMT. COMM

ELEC.

G&C MFG.

PAYLOA D

Value-Based Software Engineering

Goal of VBSE
To develop models and measures of value which are of use for managers, developers, and users as they make trade-off decisions b/w quality & cost, functionality and schedule, etc. Such decisions must be economically feasible and comprehensible to the stakeholders with differing value perspectives Early 80s Software Engineering Economics, pioneered by Barry Boehm Economics, Cognitive Science, Finance, management Science, Behavioral Sciences, and Decision Science, etc
Source Value-based Software Engineering, Stefan Biffle et. Al., Springer-Verlag, 2006

Root of VBSE

Extension of ISO SE definition with the elements from

Value-Based Software Engineering

Unavoidable involvement with

Software & information system product and process technology Their interaction with human values To balance software discipline and flexibility To answer key How much is enough? questions

Uses risk considerations

Helps illuminate information technology policy decisions

By identifying the quantitative and qualitative sources of cost and value associated with candidate decisions

Sources of Failed Projects

Perc entage o f So urc e fo r Failed Pro jec ts
Other , 21.0 Incomplete Requirements, 13.1

Absence of Need, 7.5

Lack of User Involvement, 12.4

Lack of Planning, 7.5 Changing Requirements, 8.7

Lack of Resources , 10.6 Lack of Executive Support, 9.3 Unrealistic Expectations, 9.9

Source: Standish CHAOS Report [1995]

Example: Risk Exposure

20% of fires cause 80% of property loss: e.g.: Fire Dispatching

100 80
% of Property Loss

60 40 20 20 40 60 80 100

% of Fires

VBSE approaches can be applied to avoid current project failures

Value : Key Definitions

Value (from Latin valere to be worth)

the quality of being useful or desirable

yahoo dictionary A fair return or equivalent in goods, services, or money Relative worth, utility, or importance

Software Validation (also from Latin valere )

Validation: Are we building the right product Verification: Are we building the product
right

Conclusions So Far

Value considerations

Critical factor for successful software projects

Success is a function of key stake-holder values Values are vary by stakeholder role

Value for developer, value for customer, value for user??? Fairness, customer satisfaction, trust,

Non-monetary values are important VBSE: integration of ethics into software engineering practice

Understanding Source of Value

Maslows Human Need Hierarchy - I

Self-Actualization Esteem and Autonomy Belongingness and Love Safety and Security Physiological (Food and Drink)

Source: A. Maslow, Motivation and Personality, 1954

Maslows Human Need Hierarchy - II

Satisfied needs are not motivators Unsatisfied lower-level needs dominate high-level needs Management Implication

Create environment and subculture which

satisfies lower-level needs

Stability, share values, community, and match to

special needs

Tailor project objectives, structure to

participants selfactualization priorities

Different Ways of Self-Actualization

Becoming a Better Manager Becoming a Better Technologist Helping Other Developers Helping Users Making People Happy Making People Unhappy Doing New Things Increasing Professional Stature

Projecting Yourself Into Others Win Situations

Counterexample: The Golden Rule

Do unto others

Build computer systems to serve users and operators .. Assuming users and operators like to write programs, and know computer science

.. As you would have others

do unto you

Computer sciences world (compilers, OS, etc.)

Users are programmers

Applications world
Users are pilots, doctors, tellers

VBSE: Seven Key Elements

Benefit Realization Analysis Stakeholder Proposition Elicitation and Reconciliation Business Case Analysis Continuous Risk and Opportunity Management Concurrent System and Software Engineering Value-Based Monitoring and Control Change as Opportunity

Benefit Realization Analysis

Field of Dreams syndrome a farmer story

In Software technology, Build Software and

Benefit will come syndrome Cause of many software project failures

DMR-BRA

Determine and coordinate the other initiatives

besides software and IT system development

DMR-BRA: Results Chain

Order to delivery time is an important buying criterion
ASSUMPTION

INITIATIVE
Contribution

OUTCOME
Contribution

OUTCOME

Implement a new order entry system

Reduced order processing cycle (intermediate outcome)

Increased sales Reduce time to process order Reduce time to deliver product
*DMR Consulting Groups Benefits Realization Approach

Stakeholder Value Proposition Elicitation & Reconciliation Model-Clash Spider Web: Master Net

- Reconcile Everyones Value Position

Effective Approach for Reconciliation

Expectations management

Aware of resolvable conflicts to relax less-critical levels of desire Lessons-learned retrospectives, well calibrated cost models, simplifier-complicator lists Prototype, estimation models Rank-ordering of stakeholders or categorization of the relative priorities of their desired capabilities Pair-wise comparison, scale-of-10 ratings of relative importance and difficulty Collaboration-oriented support tool for brainstorming, discussion, and win-win negotiation of conflict situations Prioritization and reconciliation based on Best ROI

Visualization and tradeoff analysis Prioritization

Groupware Business case analysis

Business Case Analysis

ROI= (Benefits-Costs)/Costs
Option BRapid

Present Value

Option B

Return on Investment

2 Option A 1

Time
-1

Effective Approach for Reconciliation

Expectations management

Aware of resolvable conflicts to relax less-critical levels of desire Lessons-learned retrospectives, well calibrated cost models, simplifier-complicator lists Prototype, estimation models Rank-ordering of stakeholders or categorization of the relative priorities of their desired capabilities Pair-wise comparison, scale-of-10 ratings of relative importance and difficulty Collaboration-oriented support tool for brainstorming, discussion, and win-win negotiation of conflict situations Prioritization and reconciliation based on Best ROI

Visualization and tradeoff analysis Prioritization

Groupware Business case analysis

Business Case Analysis

ROI= (Benefits-Costs)/Costs
Option BRapid

Present Value

Option B

Return on Investment

2 Option A 1

Time
-1

Software Processes

What is S/W Process & Model?

Software Process

A Structured set of activities and associated results to develop a software system

Specification, Design, Validation, Evolution

Software Process Model

An abstract representation of a process
perspective

A description of a process from some particular

Proliferation of Process Models

Provides flexibility for organizations to deal with the wide variety of software project situations, cultures, and environments Weakens the defenses against some common sources of project failure

Generic S/W Process Models

Waterfall Model

Process phases are distinct and separate

Evolutionary Development

Process phases are interleaved

Formal Systems Development

A mathematical system model is formally

transformed to an implementation

Component-Based Development

The system is assembled from existing

components

Waterfall Model

Formal Sign-off at the end of each phase - Documentation as product of each phase

Waterfall Model: Advantages

Clear progress state

Good for project Management Engineers know their tasks

Development is (relatively) slow and deliberate

Results in solid, well-constructed systems All sub-goals within each phase must be met Testing is inherent to every phase

Waterfall Model : Drawbacks

Difficult (Expensive) to accommodate change after process is underway

One phase has to be complete before moving

to the next phase

Inflexible partitioning of the project into distinct stages

Difficult to respond to changing customer

requirements Few business systems have stable requirements

Applicability of Waterfall Model

Therefore, Waterfall model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process Mostly used for large software system projects where a system is developed at several sites

Evolutionary Development - I

Evolutionary Development - II

Basic Idea

Build prototype version of system, seek use

comments, and keep refining until done

Other side of formality spectrum from Waterfall Model

Two Flavors of Evolutionary Development.

Exploratory development:

Objective is to work with customers and to

evolve a final system from an initial outline specification Should start with well-understood requirement and add new features as proposed by the customer

Throw-prototyping

Objective is to understand the system

requirements Should start with poorly understood requirements to clarify what is really needed

Evolutionary Development: Advantages

Faster system development than with waterfall model Useful when requirements are less-well understood Customer inputs throughout development yields system closer to their needs Steady visible signs of progress

Evolutionary Development: Drawbacks

Lack of process visibility

Not known how long it will take to create an

acceptable product Not known how many iteration will be necessary

Systems are often poorly structured

Continuous reflection of customer needs

Special skills (e.g. in languages for rapid prototyping) may be required.

Applicability of Evolutionary Development

For small or medium-size interactive systems For parts of large systems (e.g. the user interface) For short-lifetime systems

Formal Systems Development - I

Based on the transformation of a mathematical specification through different representations to an executable program Transformations are correctness-preserving so it is straightforward to show that the program conforms to its specification Embodied in the Cleanroom approach to software development Each transformation should be sufficiently close to avoid excessive verification efforts and reduce the possibility of transformation errors

Formal Systems Development - II

Requirements definition Formal specification Formal transformation Integration and system testing

T1

Formal transformations T2 T3

T4

Formal specification

R1

R2

R3

Executable program

P1

P2

P3

P4

Proofs of transformation correctness

Formal Systems Development: Advantages

Transformations are small, making verification tractable Resulting implementations are proven to meet specifications, so testing (of components) unnecessary

Although, overall system characteristics (e.g.

performance, reliability) still need verification

Formal Systems Development: Drawbacks

Need for specialised skills and training Difficult to formally specify some aspects of the system, e.g. user interfaces Development time high (usually not worth
the time/cost)

Applicability of Formal Systems Development

Critical systems

Systems that require strict safety, reliability,

and security requirements

Critical components within large systems

Component-based Development - I

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Process stages

Component analysis Requirements modification System design with reuse Development and integration

This approach is becoming more important but still limited experience with it

Component-based Development - II

Requirements specification

Component analysis

Requirements modification

System design with reuse

Development and integration

System validation

Process iteration

System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. Iteration can be applied to any of the generic process models. Two (related) approaches

Incremental Model; Spiral Model

Incremental Model
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

Incremental development
Implement and test first build Implement, integrate and test successive build until product is complete

Maintenance

Series of incremental builds until the product is finished Value assignment to each build not yet implemented Cost estimation of developing each build Value-to-Cost ratio is the criterion used for next build selection

Incremental Model: Advantages

Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing.

Component-based Development - I

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Process stages

Component analysis Requirements modification System design with reuse Development and integration

This approach is becoming more important but still limited experience with it

Component-based Development - II

Requirements specification

Component analysis

Requirements modification

System design with reuse

Development and integration

System validation

Process iteration

System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. Iteration can be applied to any of the generic process models. Two (related) approaches

Incremental Model; Spiral Model

Incremental Model
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments (Builds) with each increment delivering part of the required functionality. User requirements are prioritized and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

Incremental development
Implement and test first build Implement, integrate and test successive build until product is complete

Maintenance

Series of incremental builds until the product is finished Value assignment to each build not yet implemented Cost estimation of developing each build Value-to-Cost ratio is the criterion used for next build selection

Incremental Model: Advantages

Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing.

Spiral Model - I

Represented as a spiral rather than as a sequence of activities with backtracking.

Combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model

Provides the potential for rapid development of incremental versions of software Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process.
[Boehm 1988]: A Spiral Model of Software Development and Enhancement

Spiral Model - II

Spiral Model Sectors - I

Determine objectives, alternatives, & constraints

Specific objectives for the phase (performance, functionality, ability to accommodate changes etc.) Alternative means of implementing this portion of the product (design A, design B, reuse, buy, etc.) Constraints imposed on the application of the alternatives (cost, schedule, interface, etc.)

Evaluate Alternatives, Identify, resolve risks

Evaluate alternatives relative to the objectives and constraints Identify areas of uncertainty that significant sources of project risk Formulate a cost effective strategy for resolving sources of risk

Prototyping, simulation, benchmarking, reference checking, administering user questionnaires, analytic modeling, or combinations of these and other resolution techniques

Spiral Model Sectors - II

Develop, Verify next-level product

A development model for the system is

chosen which can be any of the generic models.

Evolutionary model, waterfall model, incremental

development, combinations, etc.

Plan Next Phases

The project is reviewed and the next phase of

the spiral is planned

The review covers all products developed during

the previous cycle, plans for the next cycle, resource required Ensure that all concerned parties are mutually committed to the approach for the next phase

Common Misinterpretations of Spiral

Hack some prototypes Fit spiral into waterfall Incremental waterfalls Suppress risk analysis No concurrency, feedback One-size-fits-all model

Six Spiral Model Essentials

. Concurrent determination of artifacts in each cycle 2. Each cycle addresses objectives, constraints, alternatives, risks, artifact elaboration, stakeholders commitment 3. Risk-driven activity level of effort 4. Risk-driven artifact degree of detail 5. Managing stakeholder commitments via anchor-point milestones 6. Emphasis on system and life-cycle issues - vs. software and development issues

Spiral Model : Advantages

The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level. The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development. It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world. If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.

Win-Win Spiral Model - I

An adaptation of the spiral model which emphasis is explicitly placed on the involvement of the client in a negotiation process at the genesis of the product development. Defines a set of negotiation activities at the beginning of each pass around the spiral. Rather that a single customer communication activity the following activities

Identification of the system stakeholders. Determination of the stakeholders win conditions Negotiations of the stakeholders win conditions to reconcile them into a set of win-win conditions for all concerned (including the software project team).
[Boehm 1996]: Anchoring the Software Process

Win-Win Spiral Model - II

Win-Win Spiral Milestones (Anchor points)

Common System/Software stakeholder commitment points

Defined in concert with Government, industry affiliates Coordinated with the Rational Unified Process

Life Cycle Objectives (LCO):

what should the system accomplish? Defines a set of objectives for each major software activity (e.g. a set of objectives associated with the definition of top level product requirements) what is the structure of the system? Establishes the objectives that must be met as the software architecture is defined. The first released version Represents a set of objectives associated with the preparation of the software for installation/distribution, site preparations prior to installations, and assistance required by all parties that will use or support the software.

Life cycle Architecture (LCA):

Initial Operational Concepts (IOC) :

Win-Win Spiral Anchor Points

Milestone Element Definition of Operational Concept System Prototype(s) Definition of System Requirements Life Cycle Objectives (LCO)
Top-level system objectives and scope - System boundary - Environment parameters and assumptions - Evolution parameters Operational concept - Operations and maintenance scenarios and parameters - Organizational life-cycle responsibilities (stakeholders)

Life Cycle Architecture (LCA)

Elaboration of system objectives and scope of increment Elaboration of operational concept by increment

Exercise key usage scenarios Resolve critical risks

Top-level functions, interfaces, quality attribute levels, including: - Growth vectors and priorities - Prototypes Stakeholders concurrence on essentials Top-level definition of at least one feasible architecture - Physical and logical elements and relationships - Choices of COTS and reusable software elements Identification of infeasible architecture options

Exercise range of usage scenarios Resolve major outstanding risks

Elaboration of functions, interfaces, quality attributes, and prototypes by increment - Identification of TBDs( (to-be-determined items) Stakeholders concurrence on their priority concerns

Choice of architecture and elaboration by increment

- Physical and logical components, connectors, configurations, constraints - COTS, reuse choices - Domain-architecture and architectural style choices Architecture evolution parameters Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBDs for later increments

Definition of System and Software Architecture Definition of LifeCycle Plan Feasibility Rationale

Identification of life-cycle stakeholders

- Users, customers, developers, maintainers, interoperators, general public, others Identification of life-cycle process model - Top-level stages, increments Top-level WWWWWHH* by stage

Assurance of consistency among elements above

- via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures

Assurance of consistency among elements above All major risks resolved or covered by risk management plan

*WWWWWHH: Why, What, When, Who, Where, How, How Much

Win-Win Spiral Model: Advantages

Faster software production facilitated through collaborative involvement of the relevant stake holders. Cheaper software via rework and maintenance reductions

MBASE Model
MBASE (Model Based Architecting and Software Engineering)

a set of guidelines that describe software engineering techniques for the creation and integration of development models for a software project Integrated Model of

Product (development) models such as object oriented analysis and design models and traditional requirements models Process models such as lifecycle and risk models Property models such as cost and schedule Success models such as business-case analysis and stakeholder win-win.

MBASE Framework

MBASE Invariants and Variants

Invariants
1. Defining and sustaining a stakeholder win-win relationship through the system's life-cycle. 2. Using the MBASE Model Integration Framework. 3. Using the MBASE Process Integration Framework.

Variants
1. Use of particular success, process, product, or property models.

2. Choice of process or product representation. 3. Degree of detail of process, product, property, or success modeling. 4. Number of spiral cycles or builds between anchor points. 5. Mapping of activities onto InceptionElaboration-Construction-Transition phases. 6. Mapping of staff levels onto activities.

4. Using the LCO, LCA, and IOC Anchor Point milestones. 5. Ensuring that the content of MBASE artifacts and activities is risk-driven.

RUP Model - I
RUP (Rational Unified Process)

A modern process model derived from the work on the UML and associated process. Normally described from 3 perspectives

A dynamic perspective that shows phases

over time A static perspective that shows process activities A proactive perspective that suggests good practice

RUP Model - II

RUP Phases

Inception

Establish the business case for the system.

Elaboration

Develop an understanding of the problem

domain and the system architecture.

Construction

System design, programming and testing.

Transition

Deploy the system in its operating

environment.

Best practices of RUP

Develop software iteratively Manage requirements Use component based architecture Visually model software Verify software quality Control changes to software

Limitations of RUP

High Adopting RUP is often thought to be expensive. Does not cover any non-software aspects of development

e.g., system engineering. product-line

engineering, safety engineering

Considered too practical, as the practicality has been based on current status of the Rational tool suite

Process Model Decision

MBASE vs. RUP

MBASE

LCO

LCA

IOC

RUP

Inception

Elaboration Construction

Transition

Standard Processes

IEEE and ISO Software Engineering Standards

http://standards.ieee.org/catalog/olis/se.html 1074-1997IEEE Standard for Developing Software Life Cycle Processes 1517-1999 (R2004)IEEE Standard for Information Technology - Software Life Cycle Processes - Reuse Processes 12207.0-1996IEEE/EIA Standard: Industry Implementation of International Standard ISO/IEC 12207:1995 Standard for Information Technology-Software Life Cycle Processes. 15288-2004IEEE Std 15288-2004 (Adoption of ISO/IEC 15288:2002, IDT), Systems Engineering--System Life Cycle Processes