Chapter1-ConventionalSoftwareManagement

8/12/2019 Chapter1-ConventionalSoftwareManagement

http://slidepdf.com/reader/full/chapter1-conventionalsoftwaremanagement 1/28

Chapter 1

Conventional Software

Management



Introduction

Three analyses of the state of the softwareengineering industry as of mid 1990s yielded:

Software Development is still highly unpredictable

• Only about 10% of software projects are delivered successfullyon time, within initial budget, and meets user requirements

• The management discipline is more of a discriminator insuccess or failure than are technology advances

• The level of software scrap and rework is indicative of animmature process.

Behold the magnitude of the software problem andcurrent norms!

But is the „theory‟ bad? “Practice bad?” Both?

Let‟s consider….



I. The Waterfall Model

Recognize that there are numerous variations of

the „waterfall model.‟

Tailored to many diverse environmentsThe „theory‟ behind the waterfall model – good

Oftentimes ignored in the „practice‟

The „practice‟ – some good; some poor



Waterfall – Theory

Historical Perspective and Update

Circa 1970: lessons learned and observationsPoint 1: There are two essential steps common to the development ofcomputer programs: analysis and coding - More later on this one.

Point 2: In order to manage and control all of the intellectual freedomassociated with software development, one must introduce several other„overhead‟ steps, including system requirements definition, softwarerequirements definition, program design, and testing. These stepssupplement the analysis and coding steps.” (See Fig 1-1, text, p. 7,which model basic programming steps and large-scale approach)

Point 3: The basic framework … is risky and invites failure. Thetesting phases that occurs at the end of the development cycle is the firstevent for which timing, storage, input/output transfers, etc. areexperienced as distinguished from analyzed. The resulting designchanges are likely to be so disruptive that the software requirementsupon which the design is based are likely violated. Either therequirements must be modified or a substantial design change is

warranted. Discuss.



Waterfall – TheorySuggested Changes „Then‟ and „Now‟

1. “Program design” comes first.Occurs between SRS generation and analysis.

Program designer looks at storage, timing, data.Very high level…First glimpse. First concepts…

During analysis: program designer must then imposestorage, timing, and operational constraints todetermine consequences.

Begin design process with program designers, notanalysts and programmers

Design, define, and allocate data processing modeseven if wrong. (allocate functions, database design,interfacing, processing modes, i/o processing, operating

procedures…. Even if wrong!!)

Build an overview document – to gain a basicunderstanding of system for all stakeholders.




Point 1: Update: We use the term „architecture

first‟ development rather than program design.

Elaborate: distribution, layered architectures, components

Nowadays, the basic architecture MUST come first.Recall the RUP: use-case driven, architecture-

centric, iterative development process……

Architecture comes first; then it is designed and

developed in parallel with planning and

requirements definition.

Recall RUP Workflow diagrams….




Point 2: Document the Design

Development efforts required huge amounts of

documentation – manuals for everything

• User manuals; operation manuals, program maintenancemanuals, staff user manuals, test manuals…

• Most of us would like to „ignore‟ documentation.

Each designer MUST communicate with variousstakeholders: interface designers, managers,

customers, testers, developers, …..




Point 2: Update: Document the Design Now, we concentrate primarily on „artifacts‟ – those models produced as a result of developing anarchitecture, performing analysis, capturingrequirements, and deriving a design solution

• Include Use Cases, static models (class diagrams, statediagrams, activity diagrams), dynamic models (sequenceand collaboration diagrams), domain models, glossaries,

supplementary specifications (constraints, operationalenvironmental constraints, distribution, ….)

• Modern tools / notations, and methods produce self-documenting artifacts from development activities.

• Visual modeling provides considerable documentation




Point 3: Do it twice.History argues that the delivered version is really version #2.Microcosm of software development.

Version 1, major problems and alternatives are addressed –

the „big cookies‟ such as communications, interfacing, datamodeling, platforms, operational constraints, otherconstraints. Plan to throw first version away sometimes…

Version 2, is a refinement of version 1 where the majorrequirements are implemented.

Version 1 often austere; Version 2 addressed shortcomings!

Point 3: Update.

This approach is a precursor to architecture-firstdevelopment (see RUP). Initial engineering is done. Forms

the basis for iterative development and addressing risk !




Point 4: Then: Plan, Control, and MonitorTesting.

Largest consumer of project resources (manpower,computing time, …) is the test phase.

• Phase of greatest risk – in terms of cost and schedule. (EST 1…) • Occurs last, when alternatives are least available, and expenses are at

a maximum.

• Typically that phase that is shortchanged the most

To do:

• 1. Employ a non-vested team of test specialists – not responsible fororiginal design.

• 2. Employ visual inspections to spot obvious errors (code reviews,other technical reviews and interfaces)

• 3. Test every logic path

• 4. Employ final checkout on target computer…..




Point 4: Now: Plan, Control, and MonitorTesting.

Items 1 and 4 are still valid.

• 1) Use a test team not involved in the development of the system –

at least for testing other than „unit testing…‟ • 4) Employ final checkout on target computer….

Item 2 (software inspections) – good years ago, but moderndevelopment environments obviate this need. Many codeanalyzers, optimizing compilers, static and dynamic

analyzers are available to automatically assist… • May still yield good results – but not for significant problems!

Stylistic!

Item 3 (testing every path) is impossible. Very difficultwith distributed systems, reusable components (necessary?),and other factors…. (aspects)

f ll h




Point 5 – Old: Involve the CustomerOld advice: involve customer in requirementsdefinition, preliminary software review,

preliminary program design (critical design

review briefings…)

Now: Involving the customer and all stakeholdersis critical to overall project success.Demonstrate increments; solicit feedback;

embrace change; cyclic and iterative andevolving software. Address risk early…..





But: Less than 20% success rate

The Software Development Plan:

Old Version

Define precise requirements

Define precise plan to deliver system

Constrained by specified time and budget

Execute and track to plan

StakeholderSatisfaction Space

Initial Project Situation

Reused or legacy assets

Detailed plans, scope

Planned Path



1.1.2 In Practice

Characteristics of Conventional Process – as it has been applied (in general)

Projects not delivered on-time, not within initial budget, and rarely met user requirements

Projects frequently had:1. Protracted integration and late design breakage

2. Late risk resolution

3. Requirements-driven functional decomposition

4. Adversarial stakeholder relationships

5. Focus on documents and review meetings

Let‟s look at these five major problems…





Expenditures per activity for a

Conventional Software Project

Activity CostManagement 5%

Requirements 5%

Design 10%

Code and unit test 30%

Integration and Test 40%

Deployment 5%

Environment 5%

Total 100%

Lots of time spent on „perfecting the software design‟ prior tocommitment to code.

Typically had: requirements in English, design in flowcharts, detaileddesign in pdl, and implementations in Fortran, Cobol, or C

Waterfall model late integration and performance showstoppers.

Could only perform testing „at the end‟ (other than unit testing)

Testing „should have‟ required 40% of life-cycle resources: often didn‟t!!



2. Late Risk Resolution

Problem here: focused on early paper artifacts.Real issues – still unknown and hard to grasp.

Difficult to resolve risk during requirements when manykey items still not fully understood.

Even in design, when requirements better understood, stilldifficult to get objective assessment.• Risks were at a very high level

During coding, some risks resolved, BUT during

Integration, many risks were quite clear and changes to

many artifacts and retrenchment often had to occurWhile much „retrenchment „did‟ occur, it often caused missed

dates, delayed requirement compliance, or, at aminimum, sacrificed quality (extensibility,maintainability, loss of original design integrity, andmore).

Quick fixes, often without documentation occurred a lot!



3. Requirements-Driven Functional Decomposition

Traditionally, software development processes have been requirements-driven.

Developers: assumed requirement specs: complete, clear, necessary, feasible, andremaining constant! This is RARELY the case!!!!

All too often, too much time spent on equally treating „all‟ requirements ratherthan on critical ones.

Much time spent on documentation on topics (traceability, testability, etc.) thatwas later made obsolete as „DRIVING REQUIREMENTS AND SUBSEQUENT

DESIGN UNDERSTANDING EVOLVE.‟ We do not KNOW all we‟d like toknow „up front.‟

Too much time addressing all of the scripted requirements• normally listed in tables, decision-logic tables, flowcharts, andplain, old text.

• Much brainpower wasted on the „lesser‟ requirements.

Also, assumption that all requirements could be captured as „functions‟ andresulting decomposition of these functions.

Functions, sub-functions, etc. became the basis for contracts and workapportionment, while ignoring major architectural-driven approaches andrequirements that are „threaded‟ throughout functions and that transcendindividual functions…... (security; authentication; persistency; performance…)

Fallacy: all requirements can be completely specified „up front‟ and (anddecomposed) via functions.



4. Adversarial Stakeholder Relationships (1 of 2)

Who are stakeholders? Discuss….Quite a diverse group! Adversarial relationships OFTEN true!

Misunderstanding of documentation usually written inEnglish and with business jargon.

Paper transmission of requirements – only method used…. No real modeling, universally-agreed-to languages withcommon notations; (no GUIs, network components alreadyavailable; Most systems were „custom.‟)

Subjective reviews / opinions. Generally without value!

…more

Management Reviews; Technical Reviews!

4 Ad i l S k h ld R l i hi



4. Adversarial Stakeholder Relationships

Common Occurrences:

Common events with contractual software:1. Contractor prepared a draft contract-deliverable document thatconstituted an intermediate artifact and delivered it to the customer forapproval. (usually done after interviews, questionnaires, meetings…)

2. Customer was expected to provide comments(typically within 15-30 days.)

3. Contractor incorporated these comments and submitted(typically 15-30 days) a final version for approval.

Evaluation:Overhead of paper was huge and „intolerable.‟ Volumes of paper! (oftenunder-read)

Strained contractor/customer relationshipsMutual distrust – basis for much litigation

Often, once approved, rendered obsolete later….(living document?)



5. Focus on Documents and Review Meetings

A very documentation-intensive approach.Insufficient attention on producing credible „increments‟ of thedesired products.

Big bang approach – all FDs delivered at once;

All Design Specs „ok‟d‟ at once and „briefed‟…

Milestones „commemorated‟ via review meetings – technical,managerial, ….. Everyone nodding and smiling often… Incredible energies expended on producing paper documentation toshow progress versus efforts to address real risk issues andintegration issues.

Stakeholders often did not go through design…

Very VERY low value in meetings and high costs

• Travel, accommodations…..

Many issues could have been averted early during development – during early life-cycle phases rather than encountered huge problemslate….but…

Continuing



Continuing….

Typical Software product design R eviews….

1. Big briefing to a diverse audienceResults: only a small percentage of the audience understands thesoftware

Briefings and documents expose few of the important assets and risksof complex software.

2. A design that appears to be compliantThere is no tangible evidence of compliance

Compliance with ambiguous requirements is of little value.

3. Coverage of requirements (typically hundreds….)

Few (tens) are in reality the real design drivers, but many presented

Dealing with all requirements dilutes the focus on critical drivers.

4. A design considered „innocent until proven guilty‟

The design is always guilty

Design flaws are exposed later in the life cycle.

1 2 C ti l S ft



1.2 Conventional Software

Management Performance

Very few changes from Barry Boehm‟s “industrial software metrics” from 1987.

Most still generally describe some of the

fundamental economic relationships that arederived from years of practice:

What follows is Barry‟s top ten (and your

author‟s (and my) comments.



Basic Software Economics…

1. Finding and fixing a software problem after delivery costs 100times more than fining and fixing the problem in early design phases.Flat true.

2. You can compress software development schedules 25% ofnominal, but no more.

Addition of people requires more management overhead and training

of people.Still a good heuristic. Some compression is sometimes possible! Becareful! Oftentimes it is a killer to add people….(Discuss later)

3. For every dollar you spend on development, you will spend twodollars on maintenance. We HOPE this is true!

Hope so. Long life cycles mean revenue…Still, hard to tell

Product‟s success in market place is driver.Successful products will have much higher ratios of “maintenance todevelopment”…..

One of a kind development will most likely NOT spend this kind ofmoney on maintenance .

• Examples: implementation / conversion subsystems…..

• Conversion software….



Basic Software Economics (cont)

4. Software development and maintenance costs are primarily afunction of the number of source lines of code.

Generally true. Component-based development may dilutethis as might reuse - but not in common use in the past.

5. Variations among people account for the biggest differences

in software productivity.Always try to hire good people. But we cannot always to that. Balanceis critical. Don‟t want all team members trying to self -actualize and

become heroes. Build the „team concept.‟ While there is no “I” in„team”, there is an implicit “we.”

6. Overall ratio of software to hardware costs is still growing.In 1955 it was 15:85; In 1985, it was 85:15. Now? I don‟tknow.

While true, impacting these figures is the ever-increasing demand forfunctionality and attendant complexity. They appear w/o bound.



Basic Software Economics (cont)

7. Only about 15% of software development effort isdevoted to programming. (Sorry! But this is the way it is!)

Approximately true. This figure has been used for years – and is shattering to a lot of programmers – especially „new‟ones. And, this 15% is only for the development! It does not

include, hopefully, some 65% - 70% of the overall total lifecycle expenses based on maintenance!!

8. Software systems and products typically cost three times asmuch per SLOC as individual software programs. Software-system products, that is system of systems, cost nine times asmuch.

A real fact: the more software you build, the moreexpensive it is per source line. Why do you think?Discuss!

