10 diagnosing problems ii

7/31/2019 10 Diagnosing Problems II

1/13

Applied Software Project Management

Andrew Stellman & Jennifer Greene


http://www.stellman-greene.com 1

Why Software Projects Fail

(Part II)

How to diagnose and fix a

troubled software project


2/13





Iteration Abuse

Iteration can be a useful tool, but it is oftenabused

The team uses iteration as a guessinggame

Programmers deliver build after build; users andstakeholders make small changes to each build

Programmers like it because they can dive in

Users and stakeholders like it because they dont

have to read documents or think about their needs


3/13


4/13





Fixing Requirements

ProblemsWhen software requirements are notgathered and specified before the software is

developed, it causes scope creep and theteam resorts to iteration abuse.

The team can adopt software requirementsengineering practices to write down most of the

changes before the work beginsA change control process gives them a handle on

the few changes that remain


5/13





Haunted by Ghosts of Old

ProblemsProgrammers find that old bugssuddenly reappear without warning

As the code base grows, it becomesharder to keep control of the source code

They may use a shared folder to store

source code, but occasionally old copies offiles are copied over newer ones


6/13





Broken Builds

The programmers deliver a build which doesnot workand the testers cant even begin to

test itThe programmers get frustrated because they feel

that they put a lot of effort into testing the build

Isnt it the job of the QA team to figure out the

build is broken and tell them what to fix?The testers spend hours or days setting up a test

environment, only to redo it for the next build


7/13





Spaghetti Code

Maintaining old code is the leastdesirable programming job in many

organizationsOld, highly modified code turns into a

twisted mess of execution paths and

patchesSpaghetti code is often used as an excuse

to do an unnecessary rewrite


8/13





Fixing Programming Problems

When the team adopts goodprogramming habits, they can avoid

ghosts of old problems, broken buildsand spaghetti code.Get control of the source code with version

control software like Subversion

Use unit tests and test-driven developmentto increase the quality of the build

Use refactoring to keep the code readable


9/13





Requirements Havent Been

ImplementedThe team delivers software missingbehavior or even entire features

Software is complex, and even with goodreview practices, its difficult for

programmers to fully implement everything

Missing requirements are difficult to spotbecause even the programmer missedthem when looking over his own work


10/13





Obvious Bugs Slipped

ThroughInexperienced testers are expected to justbang on the software

Technical support staff, junior programmers,end users, outside temps and sales peopleare drafted as testers

Even when experienced testers are used,

they are not given time to planDecisions about release readiness are madebased on the schedule, rather than the quality


11/13





But It Worked For Us!

When a product is not tested in allenvironments in which it will be used,

the tests will be thrown offDefects are missed when testers cantadequately replicate the environment inwhich the software will be used

Test data may not resemble actualproduction data


12/13





Fixing Testing Problems

When code is delivered with too fewrequirements implemented and too manybugs included, the team needs better testingpractices.Software testers must be involved in every stage

of development

Test planning must be given adequate time on the

scheduleSufficient budget must be provided for a testing

environment.


13/13




http://www stellman-greene com 13

Common Problems Can Be

Avoided!Almost everyone has experienced atleast a few of these problems.

We know what causes them, and wehave tools, techniques and practicesthat can fix them.

All it takes is good project managementand sound software engineering andany project team can do it!

10 diagnosing problems ii

Documents