About the Whitepapers
Here are some white papers I've written over the years.
To be honest, all are pretty old. Truth be told, when I do
find time to sit down and write, my inclination is usually
to write on any topic except
technology. It's not that I don't like tech stuff; it's just
a question of maintaining some balance in my life. In any
case, you may find some of these helpful.
The RUP is an excellent methodology right out of the box,
however, to be successful, any methodology must be
customized to the project and the organization.
Rational Unified Process (RUP) is an incremental,
iterative, object-oriented software development methodology,
whose low price and flexibility makes it attractive to many
users. Implementing RUP, however, can be a little tricky.
Read this paper for some tips.
This paper dispells the common misconception that Q/A is
equivalent to a testing program, and will argue that quality
is built in through a robust development methodology, and
not simply ‘tested on’ at the end. In essence, a well
defined, flexible, and dynamic development process
represents the cornerstone of the Q/A function.
Acquisition is becoming an increasingly popular way
to grow your organization, but in a technology-intensive
environment, this can be risky. If you accept the statistic
that some 85% of software projects end in failure, the odds
make it overwhelmingly likely that the slick software shop
you're looking at has been responsible for at least one of
these disasters. This problem is compounded by the fact that
these companies are often quite adept at disguising their
shoddy infrastructure behind a facade of pseudo-process. Nor
is this issue limited to acquisitions. Senior managers,
faced with I.T. departments that continually fail to deliver
critical projects, are often at a loss to sort out
conflicting excuses, alibis, and disclaimers. This paper
describes a step-by-step approach to conducting a technology
assessment, pointing out some common pitfalls and how to
avoid them.
Software development processes have been around for some
time now, and are beginning to gain wider acceptance.
Although this increased focus on how we build (or, more
often than not, fail to build) software products is a
healthy trend, realistic expectations must be emphasized. In
particular, it is essential to recognize that software
development is a complex undertaking, whose elements are
highly synergistic. A defined process is one element of the
mechanism, and will not yield optimum results without a
holistic understanding of the entire system. Moreover,
process is neither a "purchase and deploy" commodity, nor is
it a quick fix for a project on the brink of the abyss. If
you're serious about bringing order to a dithyrambic I.T.
organization, you must be prepared to pay for it, work at
it, and fight for it, but if you stick to your guns, victory
will be yours
In the late 1990s it often seemed as if Information
Technology could do no wrong. Generous investors with deep
pockets were only too willing to shovel venture capital into
anything with a "dot-com" on the end of its name, rarely
peering too deeply into issues of efficiency. Lavish office
spaces, often populated with swollen staffs, were the norm.
"Burn rate" was the term of the day, profits were a
non-issue, and efficiency was a concept so foreign as to
never even be considered. Then came the millennium. Staffs
were cut, workloads increased, and those golden dot-com's
started folding so fast it was hard to keep track.
Beleaguered IT managers everywhere now face the same
problem: how to do more with less. The good news is that
there is definitely an answer.
Over the past decade or so, Microsoft operating systems
have, in many respects, taken over a nitch once occupied
only by IBM, as a safe way to go. The saying used to be
“nobody gets fired for choosing IBM.” To a significant
extent, this same attitude has now come to apply to
Microsoft. As a result, an entire generation of programmers,
IT managers, and executives have entered the workforce never
knowing anything except a Microsoft world. So why consider
introducing a new operating system into the mix? There are
several good reasons.
Object orientation is, overall, a good thing, and it is
advantageous that practitioners have settled on a
standardized modeling system (UML – the Unified Modeling
Language). Nevertheless, although this system provides a
concise mode of communication among software professionals,
it frequently represents a barrier to effective
communication with end users. Just mention that you’re going
to employ a Use-Case driven approach, and eyes glaze over.
Speak of “Actors,” and you may elicit a chuckle. All in all,
however, the reaction that most often prevails involves
images of endless facilitated sessions, with little
stick-figure men drawn on a white board, and little apparent
progress toward the finished system. Once again, I firmly
believe that Use Case Analysis is a useful and mature tool,
but one best reserved for formalization of a requirements
model, and not necessarily for communicating with the user
community.
