Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

Software Management 45.2 Software Distribution 785

Manager 2007 also comes with over 60 management

packs, which extend management capabilities to the

operating systems, applications, and other technology

components that make up the datacenter. With these

management packs, IT departments have access to best-

practice knowledge about speciﬁc Microsoft products

and can more easily discover, monitor, trouble shoot, re-

port on, and resolve problems for a speciﬁc technology

component. Consequently, they can keep their data-

center running smoothly and efﬁciently. System Center

Operation Manager alsohas ahigh-availabilityarchitec-

ture that can leverage the latest network load-balancing

and clustering capabilities to help ensure the datacenter

is managed day and night.

To help guarantee that the infrastructure has the

right conﬁgurations across all required server com-

ponents, IT administrators can use System Center

Conﬁguration Manager 2007. The desired conﬁgura-

tion management feature in Conﬁguration Manager

2007 allows IT administrators to automatically assess

how computers comply with predeﬁned conﬁgurations;

for example, an IT department can monitor the health

of a conﬁguration implemented for Microsoft Ex-

change Server or Windows Server and are alerted when

a server’s conﬁguration drifts from the standard conﬁg-

uration.

Conﬁguration Manager also ships with conﬁg-

uration packs, which provide predeﬁned, optimized

conﬁgurations for a range of servers. In addition, one of

the most time-consuming aspects of ongoing manage-

ment of the datacenter can be automated and managed

by using Conﬁguration Manager. Updating servers with

patches, drivers, etc. within enforced maintenance win-

dows remains a key challenge for IT departments.

The desired conﬁguration management feature can

automate this process, ensuring that servers are main-

tained, available, and compliant with organizational

standards.

Improve Disaster Recovery Capabilities. The IT depart-

ment cannot prevent organizational disasters, but can

take the appropriate steps to ensure that data is pro-

tected by developing and implementing a well-planned

backup and recovery strategy for network outages. Data

Protection Manager 2007 delivers the best possible re-

covery experience because it features continuous data

protection with traditional backup, disk-based recovery,

tape-based storage, database synchronizations, and log

shipping. Consequently, with just a few mouse clicks

the IT administrator can restore a SQL Server database

directly back to the original server, restore data to a re-

covery database on the original server, or copy database

ﬁles to an alternate server or disk.

Software Management Lifecycle

As the IT department updates and maintains datacenter

server infrastructure and transitions to a dynamic IT in-

frastructure, Microsoft System Center can play a major

role at each step. Because System Center is an inte-

grated solution for the datacenter, IT departments can

derive the most value in the shortest time. Every capa-

bility is built on a common framework and design, so

IT departments can smoothly transition from one phase

of the lifecycle to the next. Some examples of these

transitions include:

•

The ability to conﬁgure, deploy, and monitor server

images, automatically, and then patch or update

these images as required

•

The ability to monitor datacenter applications and

servers (such as Microsoft SQL Server 2008), be

alerted to failures, and then recover from backup

data

•

The ability to report server performance, identify

problem servers, backup servers, and convert to

a virtual form to allow uninterrupted service while

switching to new hardware.

System Center delivers the capabilities the IT de-

partment needs for the complete distributed software

management lifecycle, and even offers speciﬁc licens-

ing to support the evolution of the datacenter with the

Server Management Suite Enterprise.

45.2.3 On-Demand Software

Microsoft’s chairman Bill Gates recently provided

a glimpse into the software giant’s strategy for the fu-

ture. In a widely circulated memo, Gates indicated that

Microsoft will shift its focus from packaged software

to the software as a service (SaaS), or on-demand,

model. Instead of buying software outright and in-

stalling it on desktops or servers, businesses would rent

applications on a per-user, per-month basis. Other en-

terprise software vendors have long been testing similar

SaaS offerings as well. For small businesses, the on-

demand model promises to reduce costs and complexity

while at the same time increase the level of software

functionality available to them. There are no packaged

applications or hardware to buy upfront, and no dedi-

cated personnel needed to install and maintain software.

What’s more SaaS will unleash a wave of service ap-

plications and that will dramatically change the nature

Part E 45.2

786 Part E Automation Management

and cost of solutions deliverable to enterprises or small

businesses.

In this case as with the web a decade ago the revo-

lution started without Microsoft, since other companies

have been selling on-demand software for years. How-

ever, a push by the world’s most powerful software

maker will certainly accelerate the trend, and it is note-

worthy that the immediate target of the new Microsoft

Ofﬁce Live on-demand platform is small business. Pre-

release or beta versions of e-Mail, project management,

collaboration, website design, and analytics programs

will be available in early 2006. Microsoft aims to of-

fer some services to small businesses for free; the basic

version of Microsoft Ofﬁce Live, will be supported by

advertisers and will allow small businesses to establish

a domain name, complete with a hosted web site with

30MB of storage, among other services.

45.2.4 Electronic Software Delivery

Distributing software over the Internet is becoming an

increasingly popular means to distribute software to

users. Electronic software delivery (ESD) refers to such

distribution and particularly the practice of enabling

users to download software from the Internet. In fact,

ESD is the future of software distribution, sales, invoic-

ing, payment, maintenance, and customer service and

support. It is already an efﬁcient and preferred way for

vendors and buyers to distribute/acquire a wide range

of software including music, videos, productivity soft-

ware, and increasingly texts and books. Compared with

physical distribution involving compact disks (CDs),

digital videodisks or digital versatile disks (DVDs), and

paper formats, ESD offers dramatic improvements in

cost, delivery time, and convenience.

The trend toward ESD is irreversible. Nearly all

software vendors offer electronic delivery options, and

many new companies choose online downloads as their

only vehicle forsoftware delivery. An increasingly large

proportion of consumer software and enterprise soft-

ware are being delivered electronically.

Major Challenges

of Electronic Software Delivery System

ESD however has a long way to go as regards qual-

ity, reliability, and security of delivery. The following

constitute the major challenges that ESD faces [45.8]:

a) Ensuring robust download performance to promote

user satisfaction, avoid costly physical fulﬁllment,

and prevent lost sales

b) Providing high-performance infrastructure that

meets highly unpredictable demands in a cost-

effective manner

c) Measuring and understanding download results and

completion rates to gain insight into customer base

and ESD efﬁcacy

d) Identifying speciﬁc geographic regions where

end-users are downloading from and control-

ling/restricting access accordingly.

45.3 Asset Management

45.3.1 Software Asset Management

and Optimization

Typically the investment in software amounts to 20% of

an organization’s IT budget. The portfolio of software

development and maintenance tools and its enterprise

applications may be licensed from third-party vendors,

developed in-house, or in some cases be open-source

system software such as Linux, or open-source applica-

tions such as Apache or EMACS. In any case the IT

organization must take full systems responsibility in-

cluding currency, interoperability, and local support for

all of the software in its portfolio, managing these as

the organization would any other asset. In the case of

in-house developed application packages the organiza-

tion has conventional ownership of the asset; in the case

of third-party systems or application software the or-

ganization has a lease-like licence for the use of the

software and perhaps a maintenance service subscrip-

tion; for open-source software the situation is less clear

but can be sufﬁciently unambiguous that any risk of use

is vastly outweighed by the technological and economic

beneﬁts of use.

Depending on the size of the organization and its

IT commitment, the human and ﬁnancial resources re-

quired to manage software as an asset may vary widely.

At an IBM conference for IT directors in Atlanta re-

cently one of the authors sat next to a senior technical

person from Bell-South. As the presenter went around

the room of 30 IT directors asking for their titles and af-

ﬁliation, he got to my seat mate who declared he was

a Unix system administrator. The others looked at him

in disgust, wondering how a low-level grunt like him

got into this august gathering of senior managers. The

Part E 45.3

Software Management 45.3 Asset Management 787

fellow went on to ﬁnish his sentence saying that he

managed 6700 Unix servers for Bell-South. Their ex-

pressions quickly turned from disgust to admiration as

he probably had the biggest and most critical IT respon-

sibility in the group. The complexity that the software

asset manager must deal with comes in two ﬂavors:

ﬁrst the inherent complexity of the software function-

ality itself, but second the number of desktop or laptop

workstations that must be dealt with. Two decades ago

most chief information ofﬁcers (CIOs) avidly avoided

taking responsibility for small computers outside their

immediate purview, but since then the proliferation of

client–server computing organization has long insisted

that they take responsibility for them without the man-

date of ownership. This introduces the complexity of

numbers or volume, similarity to the complexity of

a 1000 piece jigsaw puzzle, which is more than twice as

difﬁcult to assemble as a 500 piece puzzle. Few IT ad-

ministrators are responsible for 6700 servers, but many

are responsible for the effective operation of 10000 or

more client workstations remotely attached to the main-

frame(s) or servers for which they do have ownership.

As client–server technology as grown along with the

third-party software vendor industry, so has the need for

automation in software asset management. A glance at

the Internet will reveal dozens of packages designed to

aid the software asset manager in his or her task. We

will not attempt to catalog this dynamic market here

but rather only mention the availability and capability

of such support software packages and describe what

you might expect from one.

45.3.2 The Applications Inventory

or Asset Portfolio

The director of development in the IT organization

usually takes responsibility for what is called the appli-

cations portfolio of all the software systems, application

packages, and tools licensed, owned, or used to fulﬁll

the organization’s functions. In larger organizations the

responsibility may be divided between a director of sys-

tems for system software and a director of applications

for applications software. An organization supporting

thousands of client platforms may have a third person

responsible for the managementof clienthardware asset

leasing, software asset licensing, and end-user support.

As in any other IT function these managers must walk

a tightrope to avoid too slow incorporation and sup-

port of new technology and too rapid incorporation of

new technology. In the former case their end-users lose

competitive advantage because they do not have access

to current software features and functions, and in the

latter they lose competitive advantage due to unreliabil-

ity of early release software, and perhaps even end-user

training problems.

The software asset portfolio should include all envi-

ronmental, legal, functional, and resource requirements

information about any program system, application,

or tool, whether licensed from the hardware vendor,

a third-party software vendor, open source or locally

developed. During the preparation for addressing year

2000 (Y2K) computer compliance one of the most of-

ten asked questions about a perfectly working but not

Y2K compliant COBOL75 program to the IT manager

was: Do you have current source code? If the answer

was “yes” the second question was: Do you still have

an archived copy of your COBOL75 compiler? All too

often the answer to the second question was that it had

long ago been discarded because it was no longer sup-

ported bythe vendor. It was very easy (and relativelyin-

expensive) to help those IT managers who saved every-

thing and knew exactly where it all was. As the prophet

Isaiah once said, “my people go into exile (or captivity)

for lack of knowledge” (Isaiah 5:13). The requirements

for a software portfolio are relatively simple:

•

Know what software you are using and its source

and environmental requirements

•

Know which of your users needs it, how often, and

what their applications are

•

If still supported by a vendor, know who to contact

at the vendor for emergency support

•

If not supported, maintain a current copy of the

source code and a compiler that will compile it

•

Know the legal or licensing constraints of the soft-

ware and any sublicensed components that may be

used within it

•

Maintain a current source code ﬁle if possible; if

not, insure that one is escrowed for you by the ven-

dor

•

Archive software that is no longer used; it is

amazing how often someone very high up in the

organization will need it one more time.

45.3.3 Software Asset Management Tools

The issues that software asset management (SAM) tools

offer to handle for an organization concern IT man-

agers, ﬁnancial managers, and corporate legal staff. For

IT managers the issues of concern are:

Part E 45.3

788 Part E Automation Management

•

Manage site licences for software by user and work-

station

•

Get more out of underutilized assets by moving un-

used software to new users rather than purchasing

more licences

•

Manage unlicensed and open-source software any-

where in the system

•

Summarize entitlement information

•

Reconcile installations to entitlements

•

Provide user services high-level access to vendor

support as required

•

Monitor lifecycles and proposed upgrades of all li-

censed software

•

Ensure uniform corporate-wide installation of up-

grades and support.

For ﬁnancial managers:

•

Know whether all the software in ﬁrm is licensed

and legal

•

Avoid compliance ﬁnes and fees

•

Ensure that site licences are sufﬁcient but also at

lowest cost

•

Maximize underused software assets by redistribut-

ing existing licences to new users

•

Minimize overall cost of licensed software.

For corporate legal staff in support of IT and ﬁnancial

management:

•

Ensure absolute compliance with site licence provi-

sions

•

Inform all staff and department heads about therisks

of using unlicensed software

•

Inhibit maverick departments and personnel from

downloading or sharing unlicensed software

•

Limit corporate liability by ensuring that unau-

thorized or illegal (e.g., off-shore gaming, porno-

graphic, child pornography, etc.) software is never

installed on corporate desktops or laptops.

While managing these issues calls for little more

than the application of common sense, doing so in

a large corporation, university, or government orga-

nization with several hundred servers and 15 000 or

more workstations and laptops is best done in a rig-

orous and disciplined way. One of the most pervasive

problems is easiest solved; when CIO at a research uni-

versity one of the authors had difﬁculty discouraging

some faculty, research staff, and department personnel

from downloading and sharing nonlicensed, non-open-

source software that they felt entitled to use without

licence. A short conversation with the general counsel

solved the problem with a single joint memo inform-

ing such users and department that, in the event they

were sued for such noncompliance, they would have

to pay the legal fees for their defense and any ﬁnes

out of personal or departmental budgets, since the uni-

versity would not be doing so. As for the latter, more

sensitive and even higher risk issue, making sure ev-

eryone in the organization knows the consequences

of noncompliance with corporate standards is usually

sufﬁcient.

A somewhat larger issue is that software licensing

agreements are not all the same. Site licences for col-

leges and universities are often more lenient, and may

for example allow a faculty person to use two copies of

the software, one on a desktop and the other on a laptop,

providing that only one of them is being used at a time.

Provisions such as this may require invoking a bit of the

honor systembut are usually manageable without undue

risk.

45.3.4 Managing Corporate Laptops

and Their Software

Laptops have a special set of problems due to their mo-

bility and susceptibility to shock-related damage. Many

organizations support both personal computer (PC)and

Mac laptops and thus may have to license the same soft-

ware in more than one way. As laptop hard drives are

more subject to shock damage and consequent loss of

both system and application software as well as data,

an inventory of the software licensed to each laptop

may be critical. The mobility of laptops introduces haz-

ards beyond shock in terms of theft or just loss of the

whole machine. Corporate data may be seriously com-

promised in these situations so security and backup is

especially important for laptops. If an organization has

thousands of laptop users it may require a full-time per-

son to maintain currency and security of both laptop

hardware and software. Now that many organizations

issue only laptops and not a desktop computer as well,

a special focus on laptop computing assets beyond just

SAM generally is worthy of consideration.

45.3.5 Licence Compliance Issues

and Beneﬁts

As every personal computer user well knows, if you do

not agree to the license agreement, the software will not

install and open for you. Thus, the ﬁrst beneﬁt from li-

censing compliance is access. At the beginning the user

was forced to actually read the licence before the in-

Part E 45.3

Software Management 45.4 Cost Estimation 789

staller would accept their agreement, but users never

read these things (licences and contracts are written by

lawyers and therefore only read by lawyers). When the

vendorsrealized thateveryone (except lawyers) wasjust

scrolling to the end and clicking on the accept radio but-

ton, they began to allow the user to just hit the button

and install. The licence is a form of contract and thus

protects both the vendor and the user. Software is no

longer bought and sold; rather the use of it or access to

it is guaranteed by the vendor to purchaser of a licence.

This means that,if it does not work asdelivered,you can

insist on certain ﬁxes and upgrades, although you may

have to pay an additional sum for the upgrades. After

spending a great deal of creative effort building a system

of application, it is somecomfort to know that it will not

be arbitrarily dropped or made unavailable to you. In

such a case the end-user may need to ﬁnally read the li-

cence agreement to determine his or her rights and what

remedies may be available. If you build a complex ap-

plication without beneﬁt of licence and something goes

wrong then you have no recourse. In a large organiza-

tion this is very important and careful management of

site licences may be an important business continuity

consideration if a real disaster happens.

45.3.6 Emerging Trends

and Future Challenges

The trend in personal computing and information shar-

ing is deﬁnitely towards mobility. As WiFi wireless

networks proliferate beyond today’s local-area net-

works (LANs) and small digital assistants, including

enhanced cell phones, become more popular, one may

expect to see the corporations computing, software, and

information assets spread ever more widely. As in any

other management situation it is necessary to know

where everything is, how it is being used, and to mini-

mize risk.

45.4 Cost Estimation

45.4.1 Estimating Project Scope

One of the major problems in computer systems devel-

opment is estimating the time and cost of a development

project. It has often been said that the next major devel-

opment in hardware technology forecast to be available

in 10years arrives in about half that time, but the time

forecast to build a new software system takes twice as

long and costs at least twice as much as the initial fore-

cast. The ﬁeld of software development is strewn with

disasters and abandoned projects because the scope of

the project was not understood from the beginning or

was expanded beyond the time and resources available

during development. A few tragic examples are given

in the book Design for Trustworthy Software [45.3,

p. 536].

One of the earliest and best contributions to

the solution of this problem was Prof. Barry

Boehm’s magisterial work entitled Software Engineer-

ing Economics [45.9]. The constructive cost model

(COCOMO) which he developed for estimating the cost

and development time for large mainframe software

projects has been updated for the current client–server

era and will be discussed below. While there are

other similar development models and methodologies,

COCOMO has long since become the gold standard

for such methods and is available in several commer-

cial versions. Here we willbrieﬂy review the COCOMO

suite and a recent product, SEER-SEM, which is based

on it. These are typical of the software estimation pack-

ages available to the software developer today.

45.4.2 Cost Estimating for Large Projects

Large software development projects have an unfortu-

nate history of time and cost overruns and the largest

and more complex of them have often been abandoned

after several years and many millions of dollars in-

vested. It is also true that some large software projects

do ﬁnish, on time, within budget, and satisfy their

users. Capers Jones, the dean of software estimation,

did a study of both 59 manual and 50 automated esti-

mates for large projects (e.g., in the 5000 function-point

range) [45.10]. The manual estimates were created by

managers using conventional methodologies and the

automated ones by commercially available estimating

tools. The manual estimates yielded lower costs and

shorter times than actually experienced and only 4 of

the 50 were within 10% of actual. Only one of the

automated estimates was optimistic, most were much

too conservative, but 22 were within 10% of actual

experience. Curiously, both were fairly accurate es-

timating the actual coding involved, but the manual

estimates weremuch toooptimistic forthe nonprogram-

Part E 45.4

790 Part E Automation Management

Table 45.1 Relative software development activities and effort by genre (after [45.10,p.3])

Activity WWW % MIS % Outsource % Commercial % System % Military %

Requirements 5 7.5 9 4 4 7

Prototype 10 2 2.5 1 2 2

Architecture 0.5 1 2 1.5 1

Planning 1 1.5 1 2 1

Func design 8 7 6 7 6

Tech design 7 8 5 6 7

Design review 0.5 1.5 2.5 1

Coding 30 20 16 23 20 16

Reuseability 5 2 2 2 2

Package purchase 1 1 1 1

Code inspection 1.5 1.5 1

Veriﬁcation and validation 1

Conﬁg management 3 3 1 1 1.5

Integration 2 2 1.5 2 1.5

Documentation 10 7 9 12 10 10

Unit testing 30 4 3.5 2.5 5 3

Functional testing 6 5 6 5 5

Integration testing 5 5 4 5 5

System testing 7 5 7 5 6

Field testing 6 1.5 3

Acceptance testing 5 3 1 3

Independent testing 1

Quality testing 1 2 2 1

Training 2 3 1 1

Project management 10 12 12 11 12 13

ming partsof the project such as design, documentation,

rework, testing, project management, etc. Jones notes

that, for projects with fewer than 1000 function points

(or about 125000 C source LOC), programming is the

major cost driver, but for projects above 10000 func-

tion points (or about 1250000 C source LOC), testing

and bug removal, plus documentation are much more

costly than the programming or actual implementa-

tion cost. The dynamic of software development cost

estimation is that developers tend to be conservative,

especially those who have survived one or more un-

successful project death marches, but their customers,

i.e., the senior managers who need the application tend

to be optimistic about both cost and time and crowd

the developers toward more optimistic estimates. If the

developer is too cautious and conservative the man-

ager will simple not buy the project. Any estimate,

whether it turns out to be optimistic or conservative in

the end, must be defensible and is best based on ex-

perience with previous projects of the same size and

complexity.

As software development projects get larger and the

specter of later abandonment becomes more threaten-

ing, the need for more accurate estimates has prompted

the development of a whole new software develop-

ment service industry to provide quality tools. Some

of the estimating tools on the market today are

COCOMO II, CoStar, CostModeler, CostXpert, Knowl-

edgePlan, PriceS, SEER, SLIM, and SoftCost [45.10,

p. 2]. Some of the ﬁrst generation of tools are still in

use but are no longer being supported or sold. Jones

reports that the basic kernel of functions supported by

such tools includes:

•

Sizing logic for speciﬁcations, source code, and test

cases

•

Phase-level, activity-level, and task-level estimation

•

Schedule adjustments for holidays, vacations, and

overtime

•

Local salary and burden rate adjustments

•

Adjustments for military, systems, and commercial

standards

Part E 45.4

Software Management 45.4 Cost Estimation 791

•

Metrics support for function points and/or LOC

•

Support for maintenance and enhancement.

More advanced features available in some estimat-

ing systems include quality and reliability estimates,

risk and value analysis, return on investment (ROI),

models to collect historical data, statistical analysis,

and currency conversion for overseas development. Ta-

ble 45.1 summarizes Jones experience with six different

application genres. While he styles the table as merely

illustrative it certainly ﬁts one of the author’s more than

50years developing software in all six of these genres.

The new class of automatic software estimating

tools may not be perfect but they are very good and

may prompt the user to include factors he or she might

otherwise overlook. As always in any complex human

endeavor, there is no substitute for experience.

45.4.3 Requirements-Based

a priori Estimates

Of course it is easier to estimate a large software project

if this is the tenth one you have done just like it, but

that is rarely the case. Developers who managed to do

two or three projects fairly well are often promoted

to chief software architect or director of MIS.What

can be done when you need to create a requirements-

based estimate and the requirements are not completely

known yet? Amazing as it may seem to an engineer, this

case occurs very often in software development, and

can be tolerated because software is not manufactured

like other systems and products designed by engineers.

A software development project is the result of a nego-

tiation and, like any other negotiated decision, can be

renegotiated. Software is simply designed, redesigned,

and redesigned again as it is implemented. The only

software implementation analog to hard goods manu-

facturing is the almost completely error-free process of

copying a computer ﬁle on to one or more CD-ROMs.

The hardware designer would think that the soft-

ware engineer would follow the logical process of

requirements discovery, functional design, technical

design, implementation, testing, documentation, and

delivery; however, the more common case in software

development is thatthe ﬁrst truly known and understood

parameter is the delivery date to the customer. Hence,

the software developer’s commonly employed process,

known as date-driven estimation [45.11]. So at this

point we now when the project is to be completed but

as yet do not know what is to be delivered. In traditional

engineering one makes the estimate after design but in

software engineering one must makethe estimatebefore

design since, for software, design replaces manufactur-

ing. This places a tremendous burden on requirements

discovery [45.12] and on the subsequent speciﬁca-

tion process. It has long been conventional wisdom in

software development that one could write a precise

functional speciﬁcation (i.e., precise to both the im-

plementers and the end users). Efforts to do so have

greatly improved in the current era of object-oriented

programming analysis and design, and have given new

hope for the decades-long search for the holy grail

of software development: speciﬁcation-based program-

ming [45.3, p. 502–506]. New technologies coming on

to the market today such as Lawson Software’s Land-

mark and Wescraft’s Java refactoring system, inter alia

promise a high degree of programming automation for

Java-based software [45.3, p. 501]. Moreover, since the

precise functional speciﬁcation is written by domain

specialist(s) and the Java code produced automatically

by a metacompiler, what you as domain expert or al-

lele for the end-user specify is truly what you get. This

innovation in programming will dramatically change

the way software is designed, implemented, and main-

tained, but it also will put even more burden on the

requirements discovery and speciﬁcation part of the

project, which according to Dekkers are already the

source of 60–99% of the defects delivered into imple-

mentation [45.12]. We have long known that defects are

written into software, just like villains are written into

melodramas, and with similar high drama and anxiety

we see as we approach the end of the project, i.e., the

well-known and very precise date of delivery.

In our opinion the best way to deal with this

commonly occurring situation is the analytic hier-

archy process (AHP) developed by Saaty [45.13],

which naturally prioritizes the user requirements as

they are identiﬁed. Clearly, the most critical and time-

consuming requirements come ﬁrst to the user’s mind

and are the most important to the user’s ultimate satis-

faction with the end result of the software development

project. A description and overview of AHP together

with examples of its application is given in [45.3,

Chap. 8].

45.4.4 Training Developers

to Make Good Estimates

The need to train developers to make precise estimates

is an artifact of the conventional software design pro-

cess, in which requirements and functional designers

write in one language, technical or detail designers in

Part E 45.4

792 Part E Automation Management

another, testers in yet another, and the end-user in even

yet another, but a bit more similar to the ﬁrst language

in the sequence. Understanding software design doc-

uments (including the actual source code) going from

one stage to the next in the process seems to involve an

inherent language translation effort which can be the

source of many defects in the end result; for example,

functional speciﬁcation writers tend to think in terms of

effort units, placing the project in a cost and resource

framework. Developers however, tend to describe size

and complexity in terms of the things they will have to

make to implement the requirements [45.14]. Commer-

cial estimation packages need either concrete measures

such as source LOC or abstract measures such as func-

tion points as input, but are encoded with sufﬁcient

industry experience to translate back and forth between

such measures.

Putnam and his associates, the developers of SLIM,

have developed a process for mapping units of need

into units of work which is able to train estimators

to take best advantage of the new software estimation

tools coming onto the market. As an alternative to the

conventional software development process, one deter-

mines the size of the software components by analyzing

them into common low-level software implementation

units; creating a model-based ﬁrst-cut estimate using

known experiential productivity assumptions, project

size, and critical components; performing what-if mod-

eling until an agreed-upon (i.e., negotiated) estimate

has been developed; and ﬁnally creating a detailed plan

for the project [45.14]. The what-if modeling part of this

alternative employs the estimation tool (SLIM in his

example) in a feedback loop as well as a feedforward

process and provides a powerful learning experience

for the estimator. The intermediate units, for exam-

ple, would include forms, new reports, changed reports,

table changes, job control language (JCL) changes,

and SQL procedures, and for each such unit of work

a qualitative measure of effort, e.g., simple, average or

complex. This is a more analytical and ﬁner-grained ap-

proach than the conventional method of estimating the

number of reports, estimatingthe number of forms, then

the number of transactions per component, and then the

number of database accesses, etc. Highly experienced

COBOL programmers of yesteryear could use the time-

honored conventional approach to estimate a project’s

source LOC to within a few percent using conventional

methods and experience, but object-oriented analysis,

design and programming (OOAPD)-based design begs

for a more analytical and ﬁner-grained modeling as pro-

posed and implemented by Putnam.

45.4.5 Software Tools for Software

Development Estimates

In the late 1970s and early 1980s Barry Boehm devel-

oped the original COCOMO system mentioned above

to support the ﬁrst generation of true software engi-

neers in estimating the cost of mainframe software

development. By 2000 the need for a version this tool

able to handle object-oriented programming (OOP)and

client–serversoftwaredevelopment ledto COCOMO II.

There is also a large suite of collateral but genre

or methodology speciﬁc variations and derivatives of

COCOMO modelsand packages available today[45.15,

p. 2]. The major variations are COCOMO II, COIN-

COMO, and DBA COCOMO, which are fundamentally

the same model but tailored for different develop-

ment situations. Commercial version of COCOMO

such as Costar (http://www.softstarsystems.com)and

CostXpert (http://www.CostXpert.com) provide even

further cost estimation capability (see also http://sunset.

usc.edu/).

The basic logic of COCOMO models is based on

the general model or formula

PM = A×





Size



(

EM ,

where PM is person months, A is a calibration factor,

Size isa measure of functional size for a software model

that has an additive effect on the software development

effort, B are scale factors that have an exponential of

nonlinear effect on software development effort, and

EM are effort multipliers that inﬂuence software devel-

opment effort.

Clearly this is an experience-based model or for-

mula, not merely an equation to be evaluated. Each

factor in the equation can be represented by either a sin-

gle or multiple values depending on the purpose of the

factor; for example, Size may be measured in either

source LOC or function points, and EM may be used to

describe development environment factors such as soft-

ware complexity or software reuse. COCOMO II has

1 additive, 5 exponential, and 17 multiplicative factors,

but other models in the suite have a different number

depending on the scope of the effort and software genre

being estimated by that model [45.15]. Boehm’s current

research at the University of Southern California (USC)

is directed toward a uniﬁcation of the COCOMO suite

of models in order to provide a comprehensive estimate

for the development of a software system to help de-

velopers make more precise cost and time estimates for

their projects.

Part E 45.4

Software Management 45.4 Cost Estimation 793

SEER-SEM is a cousin of COCOMO since both

followed the early work of both Jensen method and

Halstead’s software science. As in most other models

the development environment is characterized by pa-

rameters. The architecture of a software cost estimation

model is characterized by the way it answers the follow-

ing questions [45.16]:

•

How large is the project?

•

How productive are the developers?

•

How much effort and time are required to complete

the project?

•

How does the outcome change under resource con-

straints?

•

How much will the project cost?

•

What is the expected quality of the outcome?

•

How much effort will be required to maintain and

upgrade the system in the ﬁeld?

While the model can estimate program size in either

LOC or function points we will display only the source

LOC formula here

=NewSize+ExistingSize

×(0.4×Redesign+0.25×Reimpl

+0.35×Retest) ,

where S

increases in direct proportion to the amount

of new code being added, but by a lesser amount for

the redesign, implementation, and retesting of existing

code [45.16, p. 1]. This pragmatic approach reﬂects the

fact that today’s programmer rarely starts with a blank

piece of paper (or a blank screen, as it were), but rather

is redesigning or upgrading some existing system or

application package to run in a new or enhanced envi-

ronment.

The formula for effort in SEER-SEM is

K = D

0.4

)

1.2

where S

is effective size, and C

is effective tech-

nology, a composite metric capturing factors relating

to development efﬁciency or productivity, based on an

extensive set of experiential people, process, and prod-

uct parameters. D is stafﬁng complexity, whichdepends

on how quickly qualiﬁed staff can be added to the

project [45.16]. Once effort is obtained, the time to im-

plement can be found from

= D

−0.2

)

0.4

The exponent on the criticalratio reﬂectsthe fact that as

the project size increases so does the time to complete,

however at a lesser rate.

45.4.6 Emerging Trends

and Future Challenges

The future of software development may be a very in-

teresting revolutionary one rather than the evolutionary

one we have experienced for the past 50 years. The

emergence of very high-quality open-source software

such as Linux and Apache raises the natural question

as to why management should pay large sums and wait

long timesto developcustom proprietarysoftware when

open-source alternatives are available. Of course the an-

swer to this question is they do not need to: if a time-

and industry-tested alternative is available it should be

added to the portfolio, but managed in a somewhat dif-

ferent way. We should only write software when we

have to, and this principle is leading to a restructuring

of the software industry from a vertical to a horizon-

tal model. In the future most software vendors will

sell their products to other software vendors, similar

to the structure of today’s automobile industry. Henry

Ford began his company with an extremely vertically

integrated business model like those of European man-

ufacturers: he had his own taconite mines in Minnesota

to feed his own steel mills, his own sand mines in New

Mexico for producing glass windows, his own sheep

ranches in Montana to produce the wool for upholstery,

etc. Today, every small engineering and machining ﬁrm

in Windsor, Ontario produces part for Ford. We think

the same development is happening in software, aided

by OOP and the functional componentization and con-

sequent reusability of software. Many ﬁrms will write

software but only a few of them will deliver it to end-

users.

The computer revolution has produced a hardware

performance gain of more than 10

in the 60years

since the ENIAC was announced in 1946; however,

the productivity gain in software development has been

much less impressive. Countess Ada Lovelace invented

the idea of the program loop in 1844 while watch-

ing Jacquard loom operate; Betty Holberton invented

the sort–merge generator at the Harvard Computation

Laboratory 100years later; a decade later Dr. Grace

Hopper left Harvard to build the ﬁrst compilers, Math-

Matic and FlowMatic at Univac, while Mandaly Grems

at Boeing was creating sophisticated scientiﬁc program-

ming interpretive systems for the IBM 701.26. The

progression of programmer-oriented languages such as

COBOL, FORTAN, and ALGOL in the second software

generation ledto afactor of 10–20 in programmingpro-

ductivity. Third- and fourth-generation software added

additional increase by at least an order of magnitude

Part E 45.4

794 Part E Automation Management

each, but three or four orders of magnitude overall is

much smaller than ten orders of magnitude.

The future of software development belongs to pat-

tern languages. Christopher Alexander is a building

architect who discovered the notion of a pattern lan-

guage for designing and constructing buildings and

cities. In general, a pattern language is a set of patterns

or design solutions to some particular design problem

in some particular domain. The key insight here is that

design is a domain-speciﬁc problem that takes deep un-

derstanding of the problem domain and that, once good

design solutions are found to any speciﬁc problem, we

can codify them into reusable patterns. A simple ex-

ample of a pattern language and the nature of domain

speciﬁcity is perhaps how farmers go about building

barns. They do not hire architects but rather get to-

gether and,through a set of rules of thumbbasedonhow

much livestock they have and storage and processing

considerations, build a barn with certain dimensions.

One simple pattern is that, when the barn gets to be too

long for doors only at the ends, they put a double door

in the middle. Only with a powerful design or pattern

language – and in general a domain-speciﬁc design lan-

guage (DSDL) – can we overcome the inherent limita-

tions we have in our ability to comprehend the working

of some complex system, to model it, and then auto-

mate those portions which can be mechanized [45.17].

Lawson Software’s experience with Richard Patton and

Richard Lawson’s Landmark [45.3, p. 501] DSDL has

not only shown more than another order of magnitude

in business enterprise software development, but in the

ﬁrst year of delivering accounting,supply chain,and hu-

man resources (HR) applications only one bug has been

reported. This is the future of software development.

45.5 Further Reading

•

J. Bosch: Design and Use ofSoftware Architectures:

Adopting and Evolving a Product Line Approach

(Addison-Wesley, Reading 2000)

•

A. Cockburn: Agile Software Development (Long-

man, Boston 2002)

•

D. Dikel, D.Kane, S. Ornburn,W. Loftus,J. Wilson:

Applying software product-line architecture, IEEE

Comput. 30(8), 49–55 (1997)

•

D. Dori: Object-Process Methodology (Springer,

Berlin, Heidelberg 2002)

•

A. De Lucia, F. Ferrucci, G. Tortora, M. Tucci:

Emerging Methods, Technologies, and Process

Management in Software Engineering (Wiley, IEEE

Computer Society, New York 2008)

•

R. Fantina: Practical Software Process Improve-

ment (Artech House, Norwood 2005)

•

P. Hall, J. Fernandez-Ramil: Managing the Software

Enterprise: Software Engineering and Information

Systems in Context (Cengage Learning Business,

London 2007)

•

I. Jacobson, G. Booch, J. Rumbaugh: The Uniﬁed

Software Development Process (Addison-Wesley,

Reading 1999)

•

D. Lefﬁngwell: Scaling Software Agility: Best

Practices for Large Enterprises (Addison-Wesley,

Reading 2007)

•

D. Lefﬁngwell, D. Widrig: Managing Software Re-

quirements: A Uniﬁed Approach (Addison-Wesley,

Reading 1999)

•

A. Mathur: Foundations of Software Testing

(Addison-Wesley, Reading 2008)

•

P. Robillard, P. Kruchten, P. d’Astous: Software

Engineering Processes: With UPEDU (Addison-

Wesley, Reading 2002)

•

W. Royce: Software Project Management: A Uniﬁed

Framework (Addison-Wesley, Reading 1998)

References

45.1 S. Barclay, S. Padusenko: Case Tools History,Cur-

riculum Methods Class CURR 309, Computer Science,

Faculty of Education (Queen’s University, Kingston

2008), http://educ.queensu.ca/˜compsci/units/

casetools.html#HIST

45.2 B. Boehm: Foreword. In: Software Management,

ed. by D.J. Reifer (Wiley Interscience, New York

2006) p. ix

45.3 B.K. Jayaswal, P.C. Patton: Design for Trustworthy

Software: Tools Techniques of Developing Robust

Software (Prentice Hall, Upper Saddle River 2006)

p. 58

45.4 D.J. Reifer (Ed.): Software Management (Wiley In-

terscience, New York 2006)

45.5 LANDesk Software Ltd.: http://www.networkd.com/

pdf/LDMS8/Data_Sheets/ds_mgtsuite_en-US.pdf

(South Jordan, 2007)

45.6 Microsoft System Center: Controlling Costs and

Driving Agility in the Datacenter, MS Whitepaper

(Microsoft, Redmond 2007)

Part E 45