1. 23 1
Chapter 3 – ImprovingChapter 3 – Improving
Software EconomicsSoftware Economics
Part 1 of 2Part 1 of 2

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 theReducing the size and/or complexitysize and/or complexity of applicationof application
• Improving the developmentImproving the development processprocess itselfitself
• UsingUsing more-skilled personnelmore-skilled personnel and creation of betterand 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 Qualityat Quality

3. 2323 33
This lectureThis lecture
 We will concentrate onWe will concentrate on
• Reducing the Size (most slides), and aReducing the Size (most slides), and a
little onlittle on
• Looking at the Process.Looking at the Process.

4. 2323 44
Cost Model Parameters Trends
Size
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 development
Teamwork
Win-win cultures
Environment
Automation technologies and tools
Integrated tools (visual modeling, compiler, editors,
debuggers, CMS, ….
Open Systems
Hardware platform performance
Automation of coding, documents, testing, analyses
Quality
Performance, reliability, accuracy Hardware platform performance
Demonstration-based assessment
Statistical quality control

5. 2323 55
Comments on Overall ApproachesComments on Overall Approaches
 Significant interdependencies are apparent!Significant interdependencies are apparent!
 Examples:Examples:
• SomeSome toolstools ((environmentenvironment) can bring about a) can bring about a
reduction inreduction in sizesize andand processprocess improvementimprovement
(process).(process).
• UI and GUIs today (tools –UI and GUIs today (tools – environmentenvironment) GUI) GUI
Builders, affectBuilders, affect processprocess andand qualityquality……
• ImprovedImproved processprocess (use-case driven…) => end user(use-case driven…) => end user
functionality drives the process thus favorablyfunctionality drives the process thus favorably
impactingimpacting qualityquality….….
• A ‘host’ of other interdependencies…A ‘host’ of other interdependencies…

6. 2323 66
1. Reducing Software Product Size1. Reducing Software Product Size
 The larger the product, the moreThe 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!

7. 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 logicalExternal user inputs, outputs, internal logical
data groups, external data interfaces, anddata groups, external data interfaces, and
external inquiries.external inquiries.
 SLOC metrics:SLOC metrics:
 usefuluseful afterafter a candidate solution is formulateda candidate solution is formulated
and implementation language is known.and implementation language is known.
 Many comparisons of function pointsMany comparisons of function points
to lines of code.to lines of code.

8. 2323 88
Comparison TableComparison Table
LANGUAGE SLOC PER UFP
Assembler Language 320
C 128
Fortran 77 105
Cobol 85 91
Ada 83 71
C++ 56
Ada 95 55
Java 55
Visual Basic 35

9. 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 suitedLanguages (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++
• JavaJava

10. 2323 1010
More on Comparisons: LanguagesMore on Comparisons: Languages
 Function Points focus more on ‘Function Points focus more on ‘functionalityfunctionality.’.’
 The implementingThe implementing programming language sizeprogramming language size
can becan 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 reduceAutomatic code generators (CASE; GUI) can reduce
sizesize of ‘human generated’ codeof ‘human generated’ code  less time; fewerless time; fewer
team members…(helps cost; efficiency of automaticteam 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!!

11. 2323 1111
Level of abstraction and functionalityLevel 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 toeasier to
understand, reuse, maintain. (may importunderstand, 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 highBut, these higher-level abstractions are often high
users of storage, and communications bandwidth…users of storage, and communications bandwidth…

12. 2323 1212
 A package is aA package is a general purpose mechanismgeneral purpose mechanism forfor
organizing elements into groups (use cases;organizing elements into groups (use cases;
classes, other model elements…)classes, other model elements…)
 Package is aPackage is a model elementmodel element which can containwhich can contain
otherother model elementsmodel 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…

13. 2323 1313
Subsystem - ExpressivenessSubsystem - Expressiveness
 AA combinationcombination of a packageof a package
• groups similar model elementsgroups similar model elements andand
• aa classclass has behaviors via its methods.has behaviors via its methods.
(classes provide / encapsulate behaviors(classes provide / encapsulate behaviors
or services)or services)
 SubsystemsSubsystems RealizeRealize one or moreone or more
interfaces whichinterfaces which definedefine its behaviorsits behaviors
<<subsystem>>
Subsystem Name
Interface
(a class)
nterface
Realization
Subsystem
Generally has classes
associated that
provide the holistic
service of the
subsystem…

14. 2323 1414
Component
Name
Design Model Implementation Model
<<subsystem>>
Component Name
Component
Interface
Component
Interface
Subsystems and ComponentsSubsystems and Components
 ComponentsComponents are theare the physical realizationphysical realization ofof
anan abstractionabstraction in the designin the design
• physical realization can exist on many levelsphysical realization can exist on many levels
• consider the realization of a presentaton layerconsider the realization of a presentaton layer
modeled as a ‘component.’modeled as a ‘component.’
 Components (in the implementationComponents (in the implementation
model) can be used tomodel) can be used to represent therepresent the
subsystemssubsystems from the design model.from the design model.

15. 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 OOAssertions 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 andmodeling languages like UML and
comprehensive,comprehensive, configurable processesconfigurable processes likelike
the RUP andthe RUP and many technologiesmany technologies……
 OO technology reduces size (amongOO technology reduces size (among
other things), but there is no free lunch.other things), but there is no free lunch.

16. 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 aEncourage a commoncommon vocabularyvocabulary
 Glossary; domain model; – artifacts ; object ‘concepts’ andGlossary; 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 aArchitecture provides a clear separation of concernsclear separation of concerns – for– for
development in paralleldevelopment in parallel; configuration;; configuration; integrity ofintegrity of
development…development…
  And then, when you consider theAnd then, when you consider the RUP as a process builtRUP as a process built
around OO technologyaround OO technology, there are a, there are a hosthost of additionalof additional
benefits….benefits….

17. 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 ofOld stuff: data descriptions; documents, and a host of
similar, old artifacts, designs, architectures…similar, old artifacts, designs, architectures…
 fromfrom allall phasesphases of software developmentof 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 hasDifferences in platforms / environments has
hurt reuse potentialhurt reuse potential
 Common Microsoft platforms: - counter exampleCommon Microsoft platforms: - counter example
 Linux; MACs, resulting fromLinux; MACs, resulting from distributing applicationsdistributing applications!!

18. 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 toCosts 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 sellingSome commercial organizations focused on selling
commercial components.commercial components.
 Very few success storiesVery few success stories for software componentfor software component
reusereuse
• exceptions: operation systems, middleware, GUIexceptions: operation systems, middleware, GUI
Builders, other obvious ones.Builders, other obvious ones.
 Most developersMost developers dodo undertake some kind of reuseundertake some kind of reuse
– just perhaps not as formalized…– just perhaps not as formalized…

19. 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 tailoringUsually needs tailoring
 Certainly pros and cons.Certainly pros and cons.
 Bottom line: may well haveBottom line: may well have global impacts on:global impacts on:
• qualityquality
• costcost
• supportability, and thesupportability, and the
• architecturearchitecture..

20. 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

21. 2323 2121
2. Improving Software2. 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 – requirementsthe 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, configurationrisk assessment, financial assessments, configuration
control, quality assessment, integration, testing, latecontrol, quality assessment, integration, testing, late
rework, management, personnel training, etc….rework, management, personnel training, etc….
 Objective: minimize overhead and directObjective: minimize overhead and direct
these energies toward production activities.these energies toward production activities.

22. 2323 2222
2. Improving Software Processes – (cont.)2. Improving Software Processes – (cont.)
• It is all aboutIt is all about process!process!
• A high-qualityA high-quality processprocess reduces:reduces:
 Required effortRequired effort and thusand thus scheduleschedule
 Project time yet withProject time yet with improved qualityimproved quality..
 ThreeThree genericgeneric improvement scenarios:improvement scenarios:
• ImproveImprove efficiencyefficiency of eachof each stepstep in processin process
• Eliminate some stepsEliminate some steps in the processin the process
• Undertake the same number of steps, butUndertake the same number of steps, but
employ concurrency where possibleemploy concurrency where possible

23. 2323 2323
2. Improving Software Processes -2. Improving Software Processes -
continuedcontinued
 First approachFirst approach
• more efficient steps – older approach - is good,more efficient steps – older approach - is good,
• more ROI on second (fewer steps) andmore ROI on second (fewer steps) and
• third (concurrency in activities)third (concurrency in activities)
 We want the highest quality system with fewestWe want the highest quality system with fewest
iterations in least time.iterations in least time.
• Must eliminateMust 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 testsFixing things up as a result of integration and system tests
are killers!!!are killers!!!
 OurOur ProcessProcess must reduce the probability of latemust reduce the probability of late
rework!rework!
• Does the RUP facilitate this? If so, How?Does the RUP facilitate this? If so, How?