Chapter 3 – Improving Software

Economics
 Balanced Attack
 Can improve software economics

 Easy to do so and have poor results

 Key is a ‘balanced’ approach; patient

 Five Key Initiatives – In Order:

 Reducing the size and/or complexity of application

 Improving the development process itself

 Using more-skilled personnel and creation of better teams

 Creating better ‘environments’ with appropriate tools and technology to foster

improvement
 Re-looking at Quality
Reducing the Size

Improving the Software Processes

Improving Team Effectiveness

Improving Automation through Software Economics

Achieving Required Quality

Peer Inspections: A Pragmatic View

Cost Model Parameters Trends

Size
Abstraction and component-based Higher Order Languages (C++, Java, VB,  OO
development technologies (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 Integrated tools (visual modeling, compiler, editors,

Automation technologies and tools debuggers, CMS, ….
Open Systems
Hardware platform performance
Automation of coding, documents, testing, analyses

Quality Hardware platform performance

Performance, reliability, accuracy Demonstration-based assessment
Statistical quality control
 Comments on Overall Approaches
Significant interdependencies are apparent!

Examples:
Some tools (environment) can bring about a reduction in size and process

improvement (process).
UI and GUIs today (tools – environment) GUI Builders, affect process and

quality…
Improved process (use-case driven…) => end user functionality drives

the process thus favorably impacting quality….

A ‘host’ of other interdependencies…
1. Reducing Software Product Size
 The larger the product, the more expensive it is ‘per line.’ Fact.

 Complicated due to
 Component-based development

 Automatic code generation

 “Instruction Explosion”

 GUI builders

 4GLs

 Modeling Languages

 Executable code size often increases!

1. Reducing Software Product Size:
A. Languages

Function Point metrics:

 Language independent!

 External user inputs, outputs, internal logical data groups, external data

interfaces, and external inquiries.

SLOC metrics:
 useful after a candidate solution is formulated and implementation

language is known.

Many comparisons of function points to lines of code.

Comparison 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
 More on Comparisons: Languages
 Use table as a general comparison guide only.

 Languages (in general) are often best suited for ‘classes of problems’ (domain of

usage)
 Web-based apps: Java vs COBOL
 Transaction processing: Java vs COBOL

 Systems programming: Assembler vs C vs Java

 Prototyping UI: VB versus Java (varies…)

 Shows ‘level of expressiveness.’

 Read through comparisons… pros and cons:

 C to C++

 Java
 More on Comparisons: Languages
 Function Points focus more on ‘functionality.’

 The implementing programming language size can be inferred from function point count.

  Not simple to compute function points tho…

 Automatic code generators (CASE; GUI) can reduce size of ‘human generated’ code 

less time; fewer team members…(helps cost; efficiency of automatic code generators?
Function point computation?)
 Commercial DBMSs, GUI Builders, middleware, … reduce the amount of code to be

developed…
 Size may be larger! How are fpoints computed here???

 Others!!
Level of abstraction and functionality –
benefits and ‘expressiveness’

 Reducing size changes ‘level of abstraction’ allowing us to focus on

architecture, …  easier to understand, reuse, maintain. (may import

packages of classes and objects…)

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

 Can talk about classes, subsystems, packages.

 These are serious abstractions!

 But, these higher-level abstractions are often high users of storage, and

communications bandwidth…
 Package Expressiveness
 A package is a general purpose mechanism for organizing elements

into groups (use cases; classes, other model elements…)

 Package is a model element which can contain other model elements

Packages may contain many model

elements: use case models, classes,
objects, subsystems, components,
other packages.

General grouping for organizational

purposes
Package Name
May have tremendous ‘expressiveness’
Think Math class in Java…
 Subsystem - Expressiveness
A combination of a package

groups similar model elements and

a class has behaviors via its methods. (classes provide /

encapsulate behaviors or services)

Subsystems Realize one or more interfaces which define

its behaviors
Realization
Subsystem
<<subsystem>> Generally has classes
Subsystem Name associated that
nterface
provide the holistic
Interface service of the
subsystem…
(a class)
Subsystems and Components
 Components are the physical realization of an abstraction in the design

 physical realization can exist on many levels

 consider the realization of a presentaton layer modeled as a ‘component.’

 Components (in the implementation model) can be used to represent the

subsystems from the design model.

Design Model Implementation Model

<<subsystem>> Component
Component Name Name
Component Component
Interface Interface
 1. Reducing Software Product Size: 
B. OO Methods and Visual Modeling

 Assertions abound re benefits of OO methods on productivity and

quality
Not terribly locked in concrete yet

High costs of OO training using OOSE, modeling languages like UML

and comprehensive, configurable processes like the RUP and many

technologies…
 OO technology reduces size (among other things), but there is no

free lunch.
 B. OO Methods and Visual Modeling
 Size is not everything…

 OO technology approaches – so many other benefits:

 Encourage a common vocabulary

 Glossary; domain model; – artifacts ; object ‘concepts’ and terms

 Support continuous integration

 Easy to talk about subsystems, classes, interfaces…

 Architecture first approach – for stability, planning teams, iteration plans, …

 Architecture provides a clear separation of concerns – for development in parallel; configuration;

integrity of development…
  And then, when you consider the RUP as a process built around OO technology, there are a

host of additional benefits….

 1. Reducing Software Product Size: 
C. Reuse
 Always had ‘reuse’ with stored functions/subpgms

 Many forms of reuse:

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

architectures…
 from all phases of software development

 Common architectures; processes, common environments...

 Very common during monolithic type development.

 Differences in platforms / environments has hurt reuse potential

 Common Microsoft platforms: - counter example

 Linux; MACs, resulting from distributing applications!

 C. Reuse (continued)
 Main reason for Reuse or ‘lack’ thereof: money. (not addressing commercial

components…)
 Costs to build reusable and configure reusable components. Must be able to justify.

 Can reuse be justified across many projects?

 Some commercial organizations focused on selling commercial components.

 Very few success stories for software component reuse

 exceptions: operation systems, middleware, GUI Builders, other obvious ones.

 Most developers do undertake some kind of reuse – just perhaps not as

formalized…
 1. Reducing Software Product Size: 
D. Commercial Components

 Major trend – buy commercial components.

 Saves custom development

 Usually needs tailoring

 Certainly pros and cons.

 Bottom line: may well have global impacts on:

 quality

 cost

 supportability, and the

 architecture.
 Advantages and Disadvantages of Commercial Components versus Custom Software
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

2. Improving Software Processes
Development projects are complex undertakings
Some activities done in parallel; others sequential.

Some activities: overhead; some production .

 Production activities  the project itself – requirements elicitation and

modeling, analysis, design, implementation…

 Overhead activities  planning, progress monitoring, risk assessment, financial

assessments, configuration control, quality assessment, integration, testing, late

rework, management, personnel training, etc….
 Objective: minimize overhead and direct these energies toward

production activities.
2. Improving Software Processes – (cont.)
 It is all about process!

 A high-quality process reduces:

 Required effort and thus schedule

 Project time yet with improved quality.

 Three generic improvement scenarios:

 Improve efficiency of each step in process

 Eliminate some steps in the process

 Undertake the same number of steps, but employ concurrency where

possible
 Improving Software Economics
Improving Software Processes

Attributes Metaprocess Macroprocess Microprocess

Subject Line of business Project Iteration

Objectives Line-of-business profitability Project profitability Resource management

Competitiveness Risk management Risk resolution
Project budget, schedule, quality Milestone budget, schedule,
quality

Audience Acquisition authorities, customers Software project managers Subproject managers

Organizational management Software engineers Software engineers

Metrics Project predictability On budget, on schedule On budget, on schedule

Revenue, market share Major milestone success Major milestone progress
Project scrap and rework Release/iteration scrap and
rework

Concerns Bureaucracy vs. standardization Quality vs. financial performance Content vs. schedule

Time scales 6 to 12 months 1 to many years 1 to 6 months

Three levels of processes and their attributes

 2. Improving Software Processes -
continued
 First approach

 more efficient steps – older approach - is good,

 more ROI on second (fewer steps) and

 third (concurrency in activities)

 We want the highest quality system with fewest iterations in least time.

 Must eliminate rework and late scrap – fixing things up!

 Integration testing is culprit.

 Fixing things up as a result of integration and system tests are killers!!!

 Our Process must reduce the probability of late rework!

 Does the RUP facilitate this? If so, How?

 3. Improving Team Effectiveness
“It has long been understood that differences in personnel

account for the greatest swings in productivity.”

Great teams – all stars – not too good.

Also impossible to manage. Won’t happen.

Best pragmatic approach:

Balance – highly talented people in key positions; less talented in

other positions
Coverage – strong skill people in key positions.
 3. Improving Team Effectiveness
Managing the team is the key.

A well-managed team can make up for other shortcomings.

Boehm’s recommendations:
1.  Principle of top talent: use better and fewer people.
 Proper number of people is critical.

2.  Principle of job matching (skills and motivations)

 Not uncommon in development teams for individuals to have a vision of

promotion from programmer to project manager or to architect or to

designer…
 Skill sets are NOT the same and many projects have gone amuck due to poor

management!
 Great programmers are not necessarily great managers and conversely.
 3. Improving Team Effectiveness
 3.  Principle of Career Progression –
 Organization training will pay great dividends
 Posting for new jobs?
  What are the prime motivators and motivation?

 4.  Principle of team balance – dimensions;

balance of:
 raw skills (intelligence, objectivity, creativity, analytical thinking…)
 psychological makeup (leaders and followers; risk takers and conservatives;
visionaries and nitpickers)
3. Improving Team Effectiveness
 5. Principle of Phase-out

 Get rid of the dead wood!

 Disrupt team balance; horribly de-motivating.
 Get rid of this person!
3. Improving Team Effectiveness –
continued (last)
 Overall team guidance:
 Essential ingredients: a culture of teamwork vice individual

accomplishment.
  Teamwork and balance!!!

 Top talent and phase-out are secondary

 Obsession with career progression will take care of itself in the industry… tertiary

 Strong, ‘aware’ leadership is essential.

 Keeping team together;

 recognizing individual needs and excellent performers;

 nurturing newbees,

 considering diverse opinions,

 facilitating contributions from everyone; make them feel important …

 all are essential for an effective project manager.

 Improving Software Economics
Improving Team Effectiveness (2)

Important Project Manager Skills:

 Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the
right job seems obvious but is surprisingly hard to achieve.
 Customer-interface skill. Avoiding adversarial relationships among stake-holders is a prerequisite
for success.
 Decision-making skill. The jillion books written about management have failed to provide a clear
definition of this attribute. We all know a good leader when we run into one, and decision-making
skill seems obvious despite its intangible definition.
 Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit
eccentric prima donnas, transition average people into top performers, eliminate misfits, and
consolidate diverse opinions into a team direction.
 Selling skill. Successful project managers must sell all stakeholders (including themselves) on
decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face
of resistance, and sell achievements against objectives. In practice, selling requires continuous
negotiation, compromise, and empathy.
 4. Improving Automation Through
Software Environments (1 of 3)
 The environment (tools) can dramatically impact productivity and

effort – and thus schedule and cost.

 Huge number of available tools in marketplace for supporting a

process.
 Careful selection of the right combinations…

 Recognize that these tools are the primary delivery vehicle for process

automation.

  Mature software processes suggest that highly integrated tools and

environment are necessary to facilitate the management of the process.

 4. Improving Automation Through Software
Environments – cont. (2 of 3)

i. Definition of the development and maintenance

environment is a first-class artifact of a successful process.
 Robust, integrated development!
 Hire good people and equip them with modern tools.
  A prime motivator: learning tools and environments of our
profession!
 Yet today’s environments still fall short of what they can be.
 So much more is coming…and coming… and…
4. Improving Automation Through Software
Environments – cont. (3 of 3)
 Be careful of tool vendor claims.

 (Can prove anything with statistics!)

  Remember, the tools must be integrated into the development

environment.
  Authors suggests that in his experience, the combined effect of

all tools is less than 40% (5% for an individual tool) and most
benefits are NOT realized without a corresponding change in the
process that will require their use.
 But this is substantial!!
5. Achieving Required Quality (1 of 5)

Many of the items we have discussed not only favorably

affect the development process but impact overall

quality.
(Remember this statement for questions ahead…)

Author presents a rather comprehensive table – p. 49 – for

our consideration:
This table represents General Quality improvements

realizable with a modern practice:

 Table 3-5. General Quality Improvements with a Modern Process
Quality Driver Conventional Process Modern Iterative Processes

Requirements misunderstanding Discovered late  Resolved early

Development risk Unknown until late  Understood and resolved early

Commercial components Mostly unavailable Still a quality driver, but tradeoffs

must be resolved early in the life
cycle
Change management Late in life cycle; chaotic and  Early in life cycle; straight-
malignant forward and benign

Design errors Discovered late  Resolved early

Automation Mostly error-prone manual Mostly automated, error-free

procedures evolution of artifacts

Resource adequacy Unpredictable Predictable

Schedules Over-constrained Tunable to quality, performance,

and technology

Target performance Paper-based analysis or separate Executing prototypes, early

simulation performance feedback, quantitative
understanding

Software process rigor Document-based  managed, measured, and tool-

supported
 5. Achieving Required Quality –
continued (3 of5 )
 Additional overall quality factors:

 1. Focus on requirements driving the process – namely: address

critical use cases early and traceability late in the life cycle.
 Balance requirements, development and plan evolution

2. Use metrics / indicators to measure progress and quality of the

architecture as it evolves from a high-level prototype to a fully compliant

product
 Remember: the architecture drives much of the process! Discuss. What does it

drive?
 How do you think we measure this progress??
 5. Achieving Required Quality –
continued (4 of 5)
 Additional overall quality factors

3.  Provide integrated life-cycle environments that support

early and continuous configuration control, change management,

rigorous design methods, document automation, and regression
test automation
4.  Use visual modeling and HLL that support architectural

control, abstraction, design reuse…

5. Continually look into performance issues. Require

demonstration-based evaluations.
Think: HOW are these so? Can you answer??
 5. Achieving Required Quality –
continued (last)
 Performance issues:

Be careful with commercial components and custom-built

components
Assessment of performance can degrade as we progress through

our process.
Planned, managed demonstration-based assessments – the way

to go.
 WHY do you think this is so???

 Particularly true to demonstrate EARLY architectural flaws or weaknesses

in commercial components where there is time to make adjustments…

6. Peer Inspections: A Pragmatic View
An old way ‘asserted’ to yield super results. -> Just don’t

provide the return desired in today’s complex systems.

 Good in some cases such as to nurture less-experienced

team members
 Catch the real bad blunders early.

Inspections can be applied at various times during a cycle.

Consider:
6. Peer Inspections: A Pragmatic View –
continued (2 of 7)
  1. INSPECTIONS FOR: Transitioning engineering info

from one artifact set to another, thereby assessing the

consistency, feasibility, understandability, and technology
constraints inherent in the engineering artifacts.
 Example: analysis classes will morph into design classes which will

typically become part of packages or components… In doing so, have

we lost, for example, the desired functionality?
 If the functionality is accommodated by a number of design model

elements, can you ensure that the functionality is NOT lost? Can you
TRACE it?
 Discuss.
 6. Peer Inspections: A Pragmatic View
– (3 of 7)
  2. INSPECTIONS: Major milestone demonstrations

Force artifact assessment against tangible criteria for relevant use

cases…
 3. INSPECTIONS using Environment tools

 4. Life-cycle testing – provides insight into requirements

compliance…
 5. INSPECTIONS: Study Change Management metrics – must

manage Change and how change requests might impact both

quality and progress goals.
 6. Peer Inspections: A Pragmatic View
– (4 of 7)

Overall:
 Ensure that critical components are really looked

at by the primary stakeholders.

Cannot really look at all artifacts.

Inspecting ‘too many artifacts’ will not be cost-effective –

on the contrary!
Many artifacts don’t deserve / merit close scrutiny – and

most inspections tend to be quite superficial.,

 6. Peer Inspections: A Pragmatic View
– (5 of 7)
Love this: Many highly complex applications have demanding

dimensions of complexity which include innumerable

components, concurrent execution, distributed resources, and
more.
Most inspections thus end up looking at style and ‘first-order’

semantic issues rather than real issues of substance.

Discuss technical / managerial reviews
 6. Peer Inspections: A Pragmatic View
– (6 of 7)
 Most major difficulties such as performance, concurrency,

distribution, etc. are discovered through activities such as:

 Analysis, prototyping, and experimentation

 Constructing design models (can see requirements missing; can see

architectural constraints unaccounted…)

 Committing the current state of the design to an executable implementation

 Demonstrating the current implementation strengths and weaknesses in the

context of critical subsets of use cases and scenarios

 Incorporating lessons learned back into the models, use cases, implementations,

and plans.
 6. Peer Inspections: A Pragmatic View -
last
 Remember: the RUP is (among other things) architecture-centric, use-case driven,

iterative development process.

 Iterations are planned to address (decreasing) priorities: risk and core

functionalities as identified in Use Cases and Supplementary Specifications (=SRS)

 This iterative process evolves the architecture through the phases especially and

mainly elaboration.

 Each phase has milestones and focus on inspecting critically-important issues.

 Overall there is very questionable ROI on meetings, inspections, or documents.

 Quality assurance is every stakeholder’s responsibility.