6516.Chapter3-Part1-ImprovingSoftwareEconomics

8/12/2019 6516.Chapter3-Part1-ImprovingSoftwareEconomics

1/23


2/23

23 2

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 complexityof application

Improving the developmentprocess itself

Using more-skilled personneland creation of better

teams Creating better environments with appropriate

tools and technology to foster improvement

Re-lookingat Quality


3/23

23 3

This lecture

We will concentrate on

Reducing the Size (most slides), and alittle on

Looking at the Process.


4/23

23 4

Cost Model Parameters Trends

Size

Abstraction and component-based

development technologiesHigher 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 SystemsHardware platform performance

Automation of coding, documents, testing, analyses

Quality

Performance, reliability, accuracy Hardware platform performance

Demonstration-based assessment

Statistical quality control


5/23

23 5

Comments on Overall Approaches

Significant interdependencies are apparent!

Examples: Some tools (environment) can bring about a

reduction in sizeand processimprovement(process).

UI and GUIs today (tools environment) GUIBuilders, affect process and quality

Improved process(use-case driven) => end user

functionality drives the process thus favorablyimpacting quality.

A host of other interdependencies


6/23

23 6

1. Reducing Software Product Size

The larger the product, the moreexpensive 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!


7/23

23 7

1. Reducing Software Product Size:

A. Languages

Function Point metrics:Language independent!

External user inputs, outputs, internal logicaldata groups, external data interfaces, andexternal inquiries.

SLOC metrics:useful after a candidate solution is formulated

and implementation language is known.

Many comparisons of function pointsto lines of code.


8/23

23 8

Comparison Table

LANGUAGE SLOC PER UFPAssembler Language 320

C 128

Fortran 77 105

Cobol 85 91

Ada 83 71

C++ 56Ada 95 55

Java 55

Visual Basic 35


9/23

23 9

More on Comparisons: Languages

Use table as a general comparison guide only.

Languages (in general) are often best suitedfor 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


10/23

23 10

More on Comparisons: Languages

Function Points focus more on functionality.

The implementing programming language sizecan be inferredfrom function point count. Not simple to compute function points tho

Automatic code generators (CASE; GUI) can reducesize of human generated code less time; fewerteam members(helps cost; efficiency of automaticcode 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!!


11/23

23 11

Level of abstraction and functionalitybenefits and expressiveness

Reducing size changes level of abstractionallowing us to focus on architecture, easier tounderstand, reuse, maintain. (may importpackages 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 highusers of storage, and communications bandwidth


12/23

23 12

A package is a general purpose mechanismfor organizing elements into groups (usecases; classes, other model elements)

Package is a model element which can contain

other model elements

Package Expressiveness

Package Name

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

General grouping for organizationalpurposes

May have tremendous expressivenessThink Math class in Java


13/23

23 13

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 Realizeone or more

interfaces which define its behaviors

Subsystem Name

Interface

(a class)

terface

Realization SubsystemGenerally has classesassociated thatprovide the holisticservice of the

subsystem


14/23


15/23

23 15


B. OO Methods and Visual Modeling

Assertions abound re benefits of OOmethods on productivity and quality

Not terribly locked in concrete yet

High costs of OO training using OOSE,modeling languages like UML andcomprehensive, configurable processes like

the RUP and many technologies OO technology reduces size (among

other things), but there is no free lunch.


16/23

23 16

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 fordevelopment in parallel; configuration; integrity of

development

And then, when you consider the RUP as a process builtaround OO technology, there are a host of additionalbenefits.


17/23

23 17


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 allphasesof software development

Common architectures; processes, common environments...

Very common during monolithic type development.

Differences in platforms / environments hashurt reuse potential

Common Microsoft platforms: - counter example

Linux; MACs, resulting from distributing applications!


18/23

23 18

C. Reuse (continued)

Main reason for Reuse or lack thereof: money.(not addressing commercial components)

Costs to buildreusable and configure reusable components.Must beable to justify.

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

commercial components.

Very few success stories for software componentreuse

exceptions: operation systems, middleware, GUIBuilders, other obvious ones.

Most developers do undertake some kind of reusejust perhaps not as formalized


19/23

23 19


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.

Ad antages and Disad antages of Commercial Components ers s C stom Soft are


20/23

23 20

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/23

23 21

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 requirementselicitation and modeling, analysis, design,implementation

Overhead activities planning, progress monitoring,risk assessment, financial assessments, configurationcontrol, quality assessment, integration, testing, laterework, management, personnel training, etc.

Objective: minimize overhead and direct

these energies toward production activities.


22/23


23/23

23 23

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 fewestiterations 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 laterework! Does the RUP facilitate this? If so, How?

Documents

6516.Chapter3-Part1-ImprovingSoftwareEconomics