23 1

Chapter 3 – Improving Chapter 3 – Improving Software EconomicsSoftware Economics

Part 1 of 2Part 1 of 2

2323 22

Balanced AttackBalanced Attack

Can improve software economicsCan improve software economics Easy to do so and have poor resultsEasy to do so and have poor results Key is a ‘balanced’ approach; patientKey is a ‘balanced’ approach; patient Five Key Initiatives – In Order:Five Key Initiatives – In Order:

• Reducing the Reducing the size and/or complexitysize and/or complexity of application of application• Improving the developmentImproving the development process process itselfitself• Using Using more-skilled personnelmore-skilled personnel and creation of better and creation of better

teamsteams• Creating better ‘Creating better ‘environmentsenvironments’ with appropriate ’ with appropriate

tools and technology to foster improvementtools and technology to foster improvement• Re-lookingRe-looking at Quality at Quality

2323 33

This lectureThis lecture

We will concentrate onWe will concentrate on• Reducing the Size (most slides), and a Reducing the Size (most slides), and a

little on little on • Looking at the Process.Looking at the Process.

2323 44

Cost Model Parameters TrendsSize Abstraction and component-based development technologies

Higher Order Languages (C++, Java, VB, OO (analysis, design, programming) Reuse Commercial Components

Process Methods and techniques

Iterative Development Process Maturity Models Architecture-first development Acquisition reform

Personnel People factors

Training and personnel skill developmentTeamworkWin-win cultures

Environment Automation technologies and tools

Integrated tools (visual modeling, compiler, editors, debuggers, CMS, ….Open SystemsHardware platform performanceAutomation of coding, documents, testing, analyses

Quality Performance, reliability, accuracy

Hardware platform performanceDemonstration-based assessmentStatistical quality control

2323 55

Comments on Overall ApproachesComments on Overall Approaches

Significant interdependencies are apparent!Significant interdependencies are apparent! Examples: Examples:

• Some Some toolstools ( (environmentenvironment) can bring about a ) can bring about a reduction in reduction in sizesize and and processprocess improvement improvement (process). (process).

• UI and GUIs today (tools – UI and GUIs today (tools – environmentenvironment) GUI ) GUI Builders, affect Builders, affect processprocess and and qualityquality……

• Improved Improved processprocess (use-case driven…) => end user (use-case driven…) => end user functionality drives the process thus favorably functionality drives the process thus favorably impacting impacting qualityquality….….

• A ‘host’ of other interdependencies…A ‘host’ of other interdependencies…

2323 66

1. Reducing Software Product Size1. Reducing Software Product Size

The larger the product, the more The larger the product, the more expensive it is ‘per line.’ Fact.expensive it is ‘per line.’ Fact.

Complicated due toComplicated due to• Component-based developmentComponent-based development• Automatic code generationAutomatic code generation• ““Instruction Explosion”Instruction Explosion”• GUI buildersGUI builders• 4GLs4GLs• Modeling LanguagesModeling Languages• Executable code size often increases!Executable code size often increases!

2323 77

1. Reducing Software Product Size: 1. Reducing Software Product Size: A. LanguagesA. Languages

Function Point metrics: Function Point metrics: Language independentLanguage independent!! External user inputs, outputs, internal logical External user inputs, outputs, internal logical

data groups, external data interfaces, and data groups, external data interfaces, and external inquiries.external inquiries.

SLOC metrics: SLOC metrics: useful useful afterafter a candidate solution is formulated a candidate solution is formulated

and implementation language is known.and implementation language is known.

Many comparisons of function points Many comparisons of function points to lines of code.to lines of code.

2323 88

Comparison TableComparison Table

LANGUAGE SLOC PER UFPAssembler Language 320

C 128

Fortran 77 105

Cobol 85 91

Ada 83 71

C++ 56

Ada 95 55

Java 55

Visual Basic 35

2323 99

More on Comparisons: LanguagesMore on Comparisons: Languages

Use table as a general comparison guide only.Use table as a general comparison guide only. Languages (in general) are often best suited Languages (in general) are often best suited

for ‘classes of problems’ (domain of usage)for ‘classes of problems’ (domain of usage)• Web-based apps: Java vs COBOLWeb-based apps: Java vs COBOL• Transaction processing: Java vs COBOLTransaction processing: Java vs COBOL• Systems programming: Assembler vs C vs JavaSystems programming: Assembler vs C vs Java• Prototyping UI: VB versus Java (varies…)Prototyping UI: VB versus Java (varies…)

Shows ‘Shows ‘level of expressivenesslevel of expressiveness.’.’ Read through comparisons… pros and cons:Read through comparisons… pros and cons:

• C to C++C to C++• Java Java

2323 1010

More on Comparisons: LanguagesMore on Comparisons: Languages Function Points focus more on ‘Function Points focus more on ‘functionalityfunctionality.’.’ The implementing The implementing programming language sizeprogramming language size

can be can be inferredinferred from function point count. from function point count. Not simple to compute function points tho…Not simple to compute function points tho…

• Automatic code generators (CASE; GUI) can reduce Automatic code generators (CASE; GUI) can reduce sizesize of ‘human generated’ code of ‘human generated’ code less time; fewer less time; fewer team members…(helps cost; efficiency of automatic team members…(helps cost; efficiency of automatic code generators? Function point computation?)code generators? Function point computation?)

• Commercial DBMSs, GUI Builders, middleware, … Commercial DBMSs, GUI Builders, middleware, … reduce the amount of code to be developed…reduce the amount of code to be developed…

Size may be larger! How are fpoints computed here???Size may be larger! How are fpoints computed here???

• Others!!Others!!

2323 1111

Level of abstraction and functionality Level of abstraction and functionality – benefits and ‘expressiveness’– benefits and ‘expressiveness’

Reducing size changes ‘level of abstraction’ Reducing size changes ‘level of abstraction’ allowing us to focus on architectureallowing us to focus on architecture, … , … easier to easier to understand, reuse, maintain. (may import understand, reuse, maintain. (may import packages of classes and objects…)packages of classes and objects…)

• We can talk about layers, dependencies, interfaces, We can talk about layers, dependencies, interfaces, services!services!

• Can talk about classes, subsystems, packages.Can talk about classes, subsystems, packages.• These are serious abstractions!These are serious abstractions!

But, these higher-level abstractions are often high But, these higher-level abstractions are often high users of storage, and communications bandwidth…users of storage, and communications bandwidth…

2323 1212

A package is a A package is a general purpose mechanismgeneral purpose mechanism for for organizing elements into groups (use cases; organizing elements into groups (use cases; classes, other model elements…)classes, other model elements…)

Package is a Package is a model elementmodel element which can contain which can contain otherother model elements model elements

Package ExpressivenessPackage Expressiveness

Package Name

Packages may contain many model elements: use case models, classes, objects, subsystems, components, other packages.

General grouping for organizational purposes

May have tremendous ‘expressiveness’Think Math class in Java…

2323 1313

Subsystem - ExpressivenessSubsystem - Expressiveness A A combinationcombination of a package of a package

• groups similar model elements groups similar model elements andand • a a classclass has behaviors via its methods. has behaviors via its methods.

(classes provide / encapsulate behaviors (classes provide / encapsulate behaviors or services)or services)

Subsystems Subsystems RealizeRealize one or more one or more interfaces which interfaces which definedefine its behaviors its behaviors

<<subsystem>>Subsystem Name

Interface

(a class)

Interface

RealizationSubsystem

Generally has classes associated that provide the holistic service of the subsystem…

2323 1414

ComponentName

Design Model Implementation Model

<<subsystem>>Component Name

Component Interface

Component Interface

Subsystems and ComponentsSubsystems and Components ComponentsComponents are the are the physical realizationphysical realization of of

an an abstractionabstraction in the design in the design• physical realization can exist on many levelsphysical realization can exist on many levels• consider the realization of a presentaton layer consider the realization of a presentaton layer

modeled as a ‘component.’modeled as a ‘component.’ Components (in the implementation Components (in the implementation

model) can be used to model) can be used to represent the represent the subsystems subsystems from the design model. from the design model.

2323 1515

1. Reducing Software Product Size: 1. Reducing Software Product Size: B. B. OO Methods and Visual ModelingOO Methods and Visual Modeling

Assertions abound re benefits of OO Assertions abound re benefits of OO methods on productivity and qualitymethods on productivity and quality• Not terribly locked in concrete yetNot terribly locked in concrete yet• High costs of OO training using OOSE, High costs of OO training using OOSE,

modeling languages like UML and modeling languages like UML and comprehensive, comprehensive, configurable processesconfigurable processes like like the RUP and the RUP and many technologiesmany technologies……

OO technology reduces size (among OO technology reduces size (among other things), but there is no free lunch. other things), but there is no free lunch.

2323 1616

B. OO Methods and Visual ModelingB. OO Methods and Visual Modeling

Size is not everything…Size is not everything… OO technology approaches – OO technology approaches – so many other benefitsso many other benefits::

• Encourage a Encourage a commoncommon vocabularyvocabulary Glossary; domain model; – artifacts ; object ‘concepts’ and Glossary; domain model; – artifacts ; object ‘concepts’ and

termsterms• Support continuous integrationSupport continuous integration

Easy to talk about subsystems, classes, interfaces…Easy to talk about subsystems, classes, interfaces… Architecture first approach – for stability, planning teams, Architecture first approach – for stability, planning teams,

iteration plans, …iteration plans, …• Architecture provides a Architecture provides a clear separation of concernsclear separation of concerns – for – for

development in paralleldevelopment in parallel; configuration; ; configuration; integrity of integrity of development…development…

And then, when you consider the And then, when you consider the RUP as a process built RUP as a process built around OO technologyaround OO technology, there are a , there are a hosthost of additional of additional benefits….benefits….

2323 1717

1. Reducing Software Product Size: 1. Reducing Software Product Size: C.C. ReuseReuse

Always had ‘reuse’ with stored functions/subpgmsAlways had ‘reuse’ with stored functions/subpgms Many forms of reuseMany forms of reuse::

Old stuff: data descriptions; documents, and a host of Old stuff: data descriptions; documents, and a host of similar, old artifacts, designs, architectures… similar, old artifacts, designs, architectures…

from from allall phasesphases of software development of software development Common architectures; processes, common environments...Common architectures; processes, common environments... Very common during monolithic type developmentVery common during monolithic type development. .

Differences in platforms / environments has Differences in platforms / environments has hurt reuse potentialhurt reuse potential

Common Microsoft platforms: - counter exampleCommon Microsoft platforms: - counter example Linux; MACs, resulting from Linux; MACs, resulting from distributing applicationsdistributing applications!!

2323 1818

C. Reuse (continued)C. Reuse (continued)

Main reason for Reuse or ‘lack’ thereof: Main reason for Reuse or ‘lack’ thereof: moneymoney. . (not addressing commercial components…)(not addressing commercial components…)

Costs to Costs to buildbuild reusable and configure reusable components. reusable and configure reusable components. Must be able to justify. Must be able to justify.

Can reuse be justified across many projects? Can reuse be justified across many projects? Some commercial organizations focused on selling Some commercial organizations focused on selling

commercial components.commercial components.

Very few success storiesVery few success stories for software component for software component reuse reuse • exceptions: operation systems, middleware, GUI exceptions: operation systems, middleware, GUI

Builders, other obvious ones. Builders, other obvious ones. Most developers Most developers dodo undertake some kind of reuse undertake some kind of reuse

– just perhaps not as formalized…– just perhaps not as formalized…

2323 1919

1. Reducing Software Product Size: 1. Reducing Software Product Size: D. Commercial ComponentsD. Commercial Components

Major trend – Major trend – buy commercial componentsbuy commercial components.. Saves custom developmentSaves custom development Usually needs tailoring Usually needs tailoring Certainly pros and cons.Certainly pros and cons.

Bottom line: may well have Bottom line: may well have global impacts on:global impacts on:• qualityquality• cost cost • supportability, and the supportability, and the

• architecturearchitecture..

2323 2020

APPROACH ADVANTAGES DISADVANTAGES

Commercial Components Predictable license costs Frequent upgrades

Broadly used, mature technology Up-front license fees

Available now Recurring maintenance fees

Dedicated support organizations Dependency on vendor

Hardware/software independence Run-time efficiency sacrifices

Rich in functionality Functionality constraints

Integration not always trivial

No control over upgrades or maintenance

Unnecessary features that consume extra resources

Often inadequate reliability and stability

Multiple vendor incompatibilities

Custom Development Complete change freedom Expensive, unpredictable development

Smaller, often simpler implementations Unpredictable availability date

Often better performance Underdefined maintenance model

Control of development and enhancement Often immature and fragile

Single-platform dependency

Drain on expert resources

Advantages and Disadvantages of Commercial Components versus Custom Software

2323 2121

2. Improving Software 2. Improving Software ProcessesProcesses

Development projects are complex undertakingsDevelopment projects are complex undertakings• Some activities done in parallel; others sequential.Some activities done in parallel; others sequential.• Some activities: overhead; some productionSome activities: overhead; some production..

Production activitiesProduction activities the project itself – requirements the project itself – requirements elicitation and modeling, analysis, design, elicitation and modeling, analysis, design, implementation…implementation…

Overhead activitiesOverhead activities planning, progress monitoring, planning, progress monitoring, risk assessment, financial assessments, configuration risk assessment, financial assessments, configuration control, quality assessment, integration, testing, late control, quality assessment, integration, testing, late rework, management, personnel training, etc….rework, management, personnel training, etc….

Objective: minimize overhead and direct Objective: minimize overhead and direct these energies toward production activities.these energies toward production activities.

2323 2222

2. Improving Software Processes – (cont.)2. Improving Software Processes – (cont.)• It is all about It is all about process!process!• A high-quality A high-quality processprocess reduces: reduces:

Required effortRequired effort and thus and thus scheduleschedule Project time yet with Project time yet with improved qualityimproved quality..

Three Three genericgeneric improvement scenarios: improvement scenarios:• Improve Improve efficiencyefficiency of each of each stepstep in process in process

• Eliminate some stepsEliminate some steps in the process in the process

• Undertake the same number of steps, but Undertake the same number of steps, but employ concurrency where possibleemploy concurrency where possible

2323 2323

2. Improving Software Processes - 2. Improving Software Processes - continuedcontinued

First approach First approach • more efficient steps – older approach - is good, more efficient steps – older approach - is good, • more ROI on second (fewer steps) and more ROI on second (fewer steps) and • third (concurrency in activities)third (concurrency in activities)

We want the highest quality system with fewest We want the highest quality system with fewest iterations in least time.iterations in least time.• Must eliminate Must eliminate rework and late scraprework and late scrap – fixing things up! – fixing things up! • Integration testing is culprit.Integration testing is culprit.• Fixing things up as a result of integration and system tests Fixing things up as a result of integration and system tests

are killers!!!are killers!!!

Our Our ProcessProcess must reduce the probability of late must reduce the probability of late rework! rework! • Does the RUP facilitate this? If so, How?Does the RUP facilitate this? If so, How?