it4520-kinte cnpm - slide 3

7/31/2019 IT4520-Kinte CNPM - Slide 3

1/81


2/81

2

Value-Based Software Engineering (VBSE)

Software Models and Processes


3/81


4/81

Pareto: 80% Value from 20% Components

Source: Experience Report (Bullock. 2000)


5/81

VB Testing: More Net Value

ROI = (benefitcost) / cost

Pareto: Much higher ROI 1.74

Poor Investment


6/81

Motivation for Value-Based SE

z 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

z Value neutral SE methods are increasinglyrisky Software decisions increasingly drive system value

Corporate adaptability to change achieved via softwaredecisions

System value-domain problems are the chief sources ofsoftware project failures


7/81

The Separation of Concerns Legacy

z The notion of user cannot be preciselydefined, and therefore has no place in CS or

SE.- Edsger Dijkstra, ICSE 4, 1979

z Analysis and allocation of the systemrequirements is not the responsibility of the SEgroup but is a prerequisite for their work

- Mark Paulk at al., SEI Software CMM* v.1.1, 1993

*Capability Maturity Model


8/81

Resulting Project Social Structure

SOFTWARE

MGMT.

AERO. ELEC. G & C

MFG.

COMM PAYLOA

D

I wonder whenthey'll give us our

requirements?


9/81

Value-Based Software Engineering

z Goal of VBSE

To develop models and measures of value which are of use formanagers, 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 valueperspectives

z

Root of VBSE Early 80s Software Engineering Economics, pioneered by BarryBoehm

z Extension of ISO SE definition with the elements from

Economics, Cognitive Science, Finance, management Science,Behavioral Sciences, and Decision Science, etc

Source Value-based Software Engineering, Stefan Biffle et. Al., Springer-Verlag,2006


10/81

Value-Based Software Engineering

z Unavoidable involvement with Software & information system product and process

technology Their interaction with human values

z Uses risk considerations

To balance software discipline and flexibility To answer key How much is enough? questionsz Helps illuminate information technology policy

decisions By identifying the quantitative and qualitative sources

of cost and value associated with candidate decisions


11/81

Sources of Failed Projects

Other , 21.0

Incomplete

Requirements,

13.1

Lack of User

Involvement, 12.4

Absence of Need,

7.5

Lack of Planning,

7.5

Changing

Requirements, 8.7Lack of Executive

Support, 9.3

Unrealistic

Expectations, 9.9

Lack of

Resources , 10.6

Source: Standish CHAOS Report [1995]


12/81

Example: Risk Exposure

20% of fires cause 80% of property loss:

e.g.: Fire Dispatching

100

80

60

40

20

% ofProperty

Loss

% of Fires20 40 60 80 100


13/81

VBSE approaches can be appliedto avoid current project failures


14/81

Value : Key Definitions

z 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 importancez Software Validation (also from Latin

valere )

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

right


15/81

Conclusions So Far

z Value considerations Critical factor for successful software projects

z Success is a function of key stake-holdervalues

z Values are vary by stakeholder role

Value for developer, value for customer, value foruser???z Non-monetary values are important

Fairness, customer satisfaction, trust,z VBSE: integration of ethics into software

engineering practice


16/81

Understanding Source of Value


17/81

Maslows Human Need Hierarchy - I

Source: A. Maslow, Motivation and Personality, 1954


18/81

Maslows Human Need Hierarchy - II

z Satisfied needs are not motivators

z Unsatisfied lower-level needs dominatehigh-level needs

z Management Implication

Create environment and subculture whichsatisfies lower-level needs Stability, share values, community, and match to

special needs

Tailor project objectives, structure toparticipants selfactualization priorities


19/81

Different Ways of Self-Actualization

z Becoming a Better Manager

z Becoming a Better Technologist

z Helping Other Developers

z Helping Users

z Making People Happyz Making People Unhappy

z

Doing New Thingsz Increasing Professional Stature


20/81

Projecting Yourself Into Others Win Situations

Counterexample: The Golden Rule

Computer sciences world (compilers, OS, etc.)

Users are programmers

Applications worldUsers are pilots, doctors, tellers

Do unto others

.. As you would have othersdo unto you

z Build computer systems toserve users and operators

.. Assuming users andoperators like to write

programs, and knowcomputer science


21/81

VBSE: Seven Key Elements

z Benefit Realization Analysis

z Stakeholder Proposition Elicitation and

Reconciliationz Business Case Analysis

z Continuous Risk and OpportunityManagement

z Concurrent System and SoftwareEngineering

z Value-Based Monitoring and Control

z Change as Opportunity


22/81

Benefit Realization Analysis

z Field of Dreams syndrome a farmerstory

In Software technology, Build Software andBenefit will come syndrome

Cause of many software project failuresz DMR-BRA

Determine and coordinate the other initiativesbesides software and IT system development


23/81

DMR-BRA: Results Chain

INITIATIVE OUTCOMEOUTCOME

Implement a new order

entry system

ASSUMPTION

Contribution Contribution

Order to delivery time is

an important buying criterion

Reduce time to processorder

Reduced order processing cycle

(intermediate outcome)

Increased sales

Reduce time to deliver product

*DMR Consulting Groups Benefits Realization Approach


24/81

Stakeholder Value Proposition Elicitation & Reconciliation

- Reconcile Everyones Value Position


25/81

Effective Approach for Reconciliation

z Expectations management Aware of resolvable conflicts to relax less-critical levels of

desire

Lessons-learned retrospectives, well calibrated cost models,simplifier-complicator lists

z Visualization and tradeoff analysis Prototype, estimation models

z Prioritization

Rank-ordering of stakeholders or categorization of the relativepriorities of their desired capabilities Pair-wise comparison, scale-of-10 ratings of relative

importance and difficulty

z Groupware

Collaboration-oriented support tool for brainstorming,discussion, and win-win negotiation of conflict situationsz Business case analysis

Prioritization and reconciliation based on Best ROI


26/81

Business Case Analysis

Time

Return on

Investment

-1

1

2

3

Option B-

Rapid Option B

Option A


27/81

Effective Approach for Reconciliation

z Expectations management Aware of resolvable conflicts to relax less-critical levels of

desire

Lessons-learned retrospectives, well calibrated cost models,simplifier-complicator lists

z Visualization and tradeoff analysis Prototype, estimation models

z Prioritization

Rank-ordering of stakeholders or categorization of the relativepriorities of their desired capabilities Pair-wise comparison, scale-of-10 ratings of relative

importance and difficulty

z Groupware

Collaboration-oriented support tool for brainstorming,discussion, and win-win negotiation of conflict situationsz Business case analysis

Prioritization and reconciliation based on Best ROI


28/81

Business Case Analysis

Time

Return on

Investment

-1

1

2

3

Option B-

Rapid Option B

Option A


29/81

Software Processes


30/81

What is S/W Process & Model?

z Software Process A Structured set of activities and associated results to

develop a software system

Specification, Design, Validation, Evolutionz Software Process Model

An abstract representation of a process A description of a process from some particular

perspectivez Proliferation of Process Models

Provides flexibility for organizations to deal with thewide variety of software project situations, cultures,and environments

Weakens the defenses against some commonsources of project failure


31/81

Generic S/W Process Models

z Waterfall Model

Process phases are distinct and separatez Evolutionary Development

Process phases are interleavedz

Formal Systems Development A mathematical system model is formallytransformed to an implementation

z Component-Based Development The system is assembled from existing

components


32/81

Waterfall Model

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


33/81

Waterfall Model: Advantages

z Clear progress state

Good for project Management

Engineers know their tasks

z Development is (relatively) slow anddeliberate

Results in solid, well-constructed systems

All sub-goals within each phase must be met Testing is inherent to every phase


34/81

Waterfall Model : Drawbacks

z Difficult (Expensive) to accommodatechange after process is underway

One phase has to be complete before movingto the next phase

z Inflexible partitioning of the project into

distinct stages Difficult to respond to changing customer

requirements

Few business systems have stablerequirements


35/81

Applicability of Waterfall Model

z Therefore, Waterfall model is onlyappropriate when the requirements are

well-understood and changes will befairly limited during the design process

z Mostly used for large software systemprojects where a system is developed at

several sites


36/81

Evolutionary Development - I


37/81

Evolutionary Development - II

z Basic Idea

Build prototype version of system, seek usecomments, and keep refining until done

z Other side of formality spectrum from

Waterfall Model


38/81

Two Flavors of Evolutionary Development.

z Exploratory development: Objective is to work with customers and to

evolve a final system from an initial outlinespecification

Should start with well-understood requirementand add new features as proposed by the

customer

z Throw-prototyping Objective is to understand the system

requirements Should start with poorly understood

requirements to clarify what is really needed


39/81

Evolutionary Development: Advantages

z Faster system development than withwaterfall model

z Useful when requirements are less-wellunderstood

z

Customer inputs throughoutdevelopment yields system closer totheir needs

z Steady visible signs of progress


40/81

Evolutionary Development: Drawbacks

z Lack of process visibility

Not known how long it will take to create anacceptable product

Not known how many iteration will benecessary

z Systems are often poorly structured Continuous reflection of customer needs

z Special skills (e.g. in languages for rapidprototyping) may be required.


41/81

Applicability of Evolutionary Development

z For small or medium-size interactivesystems

z For parts of large systems (e.g. the userinterface)

z

For short-lifetime systems


42/81

Formal Systems Development - I

z Based on the transformation of a mathematicalspecification through different representations

to an executable programz Transformations are correctness-preserving

so it is straightforward to show that the

program conforms to its specificationz Embodied in the Cleanroom approach to

software development

z

Each transformation should be sufficientlyclose to avoid excessive verification efforts andreduce the possibility of transformation errors


43/81

Formal Systems Development - II

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

R2Formal

specificationR3

Executableprogram

P2 P3 P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1


44/81

Formal Systems Development: Advantages

z Transformations are small, makingverification tractable

z Resulting implementations are proven to

meet specifications, so testing (ofcomponents) unnecessary

Although, overall system characteristics (e.g.

performance, reliability) still need verification


45/81

Formal Systems Development: Drawbacks

z Need for specialised skills and training

z Difficult to formally specify some aspectsof the system, e.g. user interfaces

z Development time high (usually not worththe time/cost)


46/81

Applicability of Formal Systems Development

z Critical systems

Systems that require strict safety, reliability,and security requirements

z Critical components within large systems


47/81

Component-based Development - I

z Based on systematic reuse where systems areintegrated from existing components or COTS

(Commercial-off-the-shelf) systemsz Process stages

Component analysis

Requirements modification System design with reuse Development and integration

z This approach is becoming more important butstill limited experience with it


48/81

Component-based Development - II

Requirementsspecification Componentanalysis

Development

and integration

System design

with reuse

Requirementsmodification

Systemvalidation


49/81

Process iteration

z System requirements ALWAYS evolve inthe course of a project so process

iteration where earlier stages arereworked is always part of the processfor large systems.

z Iteration can be applied to any of thegeneric process models.

z

Two (related) approaches Incremental Model; Spiral Model


50/81

Incremental Model

z Rather than deliver the system as a singledelivery, the development and delivery is brokendown into increments with each incrementdelivering part of the required functionality.

z User requirements are prioritised and thehighest priority requirements are included in

early increments.

z Once the development of an increment isstarted, the requirements are frozen though

requirements for later increments can continueto evolve.


51/81

Incremental development

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

Implement and test

first build

Implement, integrate and testsuccessive build until product

is complete

Maintenance


52/81

Incremental Model: Advantages

z Customer value can be delivered witheach increment so system functionality is

available earlier.z Early increments act as a prototype to

help elicit requirements for laterincrements.

z Lower risk of overall project failure.

z The highest priority system services tendto receive the most testing.


53/81

Component-based Development - I

z Based on systematic reuse where systems areintegrated from existing components or COTS

(Commercial-off-the-shelf) systemsz Process stages

Component analysis

Requirements modification

System design with reuse Development and integration

z This approach is becoming more important but

still limited experience with it


54/81

Component-based Development - II

Requirementsspecification

Componentanalysis

Development

and integration

System design

with reuse

Requirements

modification

Systemvalidation

P it ti


55/81

Process iteration

z System requirements ALWAYS evolve inthe course of a project so process

iteration where earlier stages arereworked is always part of the processfor large systems.

z Iteration can be applied to any of thegeneric process models.

z

Two (related) approaches Incremental Model; Spiral Model

I t l M d l


56/81

Incremental Model

z Rather than deliver the system as a singledelivery, the development and delivery is brokendown into increments (Builds) with eachincrement delivering part of the requiredfunctionality.

z User requirements are prioritized and the

highest priority requirements are included inearly increments.

z Once the development of an increment is

started, the requirements are frozen thoughrequirements for later increments can continueto evolve.



57/81


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

Implement and test

first build

Implement, integrate and testsuccessive build until product

is complete

Maintenance

I t l M d l Ad t


58/81

Incremental Model: Advantages

z Customer value can be delivered witheach increment so system functionality is

available earlier.z Early increments act as a prototype to

help elicit requirements for later

increments.

z Lower risk of overall project failure.

z The highest priority system services tendto receive the most testing.

Spiral Model I


59/81

Spiral Model - I

z Represented as a spiral rather than as a sequenceof activities with backtracking. Combines the iterative nature of prototyping with the

controlled and systematic aspects of the waterfall model

z Provides the potential for rapid development ofincremental versions of software

z Each loop in the spiral represents a phase in theprocess.

z No fixed phases such as specification or design -loops in the spiral are chosen depending on whatis required.

z

Risks are explicitly assessed and resolvedthroughout the process.

[Boehm 1988]: A Spiral Model of Software Development and Enhancement

Spiral Model II


60/81

Spiral Model - II

Spiral Model Sectors I


61/81

Spiral Model Sectors - I

z 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.)

z

Evaluate Alternatives, Identify, resolve risks Evaluate alternatives relative to the objectives andconstraints

Identify areas of uncertainty that significant sources ofproject risk

Formulate a cost effective strategy for resolving sources ofrisk Prototyping, simulation, benchmarking, reference checking,

administering user questionnaires, analytic modeling, orcombinations of these and other resolution techniques

Spiral Model Sectors - II


62/81

Spiral Model Sectors - II

z Develop, Verify next-level product A development model for the system is

chosen which can be any of the genericmodels. Evolutionary model, waterfall model, incremental

development, combinations, etc.

z Plan Next Phases The project is reviewed and the next phase of

the spiral is planned

The review covers all products developed duringthe previous cycle, plans for the next cycle,resource required

Ensure that all concerned parties are mutuallycommitted to the approach for the next phase

Common Misinterpretations of Spiral


63/81

Common Misinterpretations of Spiral

z Hack some prototypes

z Fit spiral into waterfall

z Incremental waterfalls

z Suppress risk analysis

z No concurrency, feedback

z One-size-fits-all model

Six Spiral Model Essentials


64/81

Six Spiral Model Essentials

. Concurrent determination of artifacts in eachcycle

2. Each cycle addresses objectives, constraints,alternatives, risks, artifact elaboration,stakeholders commitment

3. Risk-driven activity level of effort4. Risk-driven artifact degree of detail

5. Managing stakeholder commitments via

anchor-point milestones6. Emphasis on system and life-cycle issues

- vs. software and development issues

Spiral Model : Advantages


65/81

Spiral Model : Advantages

z The spiral model is a realistic approach to thedevelopment of large-scale software products becausethe software evolves as the process progresses. Inaddition, the developer and the client better understandand react to risks at each evolutionary level.

z The model uses prototyping as a risk reductionmechanism and allows for the development of prototypesat any stage of the evolutionary development.

z It maintains a systematic stepwise approach, like theclassic life cycle model, but incorporates it into aniterative framework that more reflect the real world.

z If employed correctly, this model should reduce risks

before they become problematic, as consideration oftechnical risks are considered at all stages.

Win-Win Spiral Model - I


66/81

p

z An adaptation of the spiral model which emphasisis explicitly placed on the involvement of the clientin a negotiation process at the genesis of the

product development.z Defines a set of negotiation activities at the

beginning of each pass around the spiral. Ratherthat 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 allconcerned (including the software project team).

[Boehm 1996]: Anchoring the Software Process

Win-Win Spiral Model - II


67/81

p

Win-Win Spiral Milestones (Anchor points)


68/81

p ( p )

z Common System/Software stakeholder commitment points Defined in concert with Government, industry affiliates Coordinated with the Rational Unified Process

z

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 productrequirements)

z Life cycle Architecture (LCA):

what is the structure of the system? Establishes the objectives that must be met as the softwarearchitecture is defined.

z Initial Operational Concepts (IOC) : The first released version

Represents a set of objectives associated with the preparation of thesoftware for installation/distribution, site preparations prior toinstallations, and assistance required by all parties that will use orsupport the software.

Win-Win Spiral Anchor Points


69/81

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

Milestone Element Life Cycle Objectives (LCO) Life Cycle Architecture (LCA)

Definition ofOperational

Concept

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)

Elaboration of system objectives andscope of increment

Elaboration of operational concept by increment

Top-level functions, interfaces, quality attribute levels,including:

- Growth vectors and priorities- Prototypes

Stakeholders concurrence on essentials

Elaboration of functions, interfaces, quality attributes,and prototypes by increment

- Identification of TBDs( (to-be-determined items) Stakeholders concurrence on their priority concerns

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

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

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

management plan

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, feasiblearchitectures

Definition of SystemRequirements

Definition of System

and SoftwareArchitecture

Definition of Life-

Cycle Plan

Feasibility

Rationale

System Prototype(s) Exercise key usage scenarios

Resolve critical risks

Exercise range of usage scenarios

Resolve major outstanding risks

Win-Win Spiral Model: Advantages


70/81

z Faster software production facilitatedthrough collaborative involvement of the

relevant stake holders.

z Cheaper software via rework andmaintenance reductions

MBASE Model


71/81

a set of guidelines that describe software

engineering techniques for the creation andintegration of development models for asoftware project

z Integrated Model of

Product (development) models such as objectoriented analysis and design models and traditionalrequirements models

Process models such as lifecycle and risk models

Property models such as cost and schedule Success models such as business-case analysis andstakeholder win-win.

( odel ased rchitecting and oftware ngineering)

MBASE Framework


72/81

MBASE Invariants and Variants


73/81

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

2. Choice of process or productrepresentation.

3. Degree of detail of process,

product, property, or success modeling.

4. Number of spiral cycles or buildsbetween anchor points.

5. Mapping of activities onto Inception-Elaboration-Construction-Transitionphases.

6. Mapping of staff levels onto

activities.

1. Defining and sustaining astakeholder win-win relationship throughthe system's life-cycle.

2. Using the MBASE Model IntegrationFramework.

3. Using the MBASE Process

Integration Framework.

4. Using the LCO, LCA, and IOCAnchor Point milestones.

5. Ensuring that the content of MBASE

artifacts and activities is risk-driven.

VariantsInvariants

RUP Model - I


74/81

z A modern process model derived fromthe work on the UML and associatedprocess.

z Normally described from 3 perspectives

A dynamic perspective that shows phasesover time A static perspective that shows process

activities A proactive perspective that suggests goodpractice

( ational nified rocess)

RUP Model - II


75/81

RUP Phases


76/81

z Inception

Establish the business case for the system.z Elaboration

Develop an understanding of the problemdomain and the system architecture.

z Construction System design, programming and testing.

z

Transition Deploy the system in its operatingenvironment.

Best practices of RUP


77/81

z Develop software iteratively

z Manage requirements

z Use component based architecture

z Visually model software

z

Verify software qualityz Control changes to software

Limitations of RUP


78/81

z High Adopting RUP is often thought tobe expensive.

z Does not cover any non-softwareaspects of development

e.g., system engineering. product-lineengineering, safety engineering

z Considered too practical, as thepracticality has been based on current

status of the Rational tool suite

Process Model Decision


79/81

MBASE vs. RUP


80/81

LCO LCA IOC

Standard Processes


81/81

z 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 InformationTechnology - Software Life Cycle Processes - ReuseProcesses

12207.0-1996IEEE/EIA Standard: IndustryImplementation of International Standard ISO/IEC12207:1995 Standard for Information Technology--Software Life Cycle Processes.

15288-2004IEEE Std 15288-2004 (Adoption ofISO/IEC 15288:2002, IDT), Systems Engineering---

System Life Cycle Processes

it4520-kinte cnpm - slide 3

Documents