Page 1 of 2
You are in charge of getting a new system developed and implemented.
You have met with all interested parties and outlined what the system
needs to do. A developer is hired and is given the plan. You feel
confident that all is well and your system will be a success
?will it?
Not so fast. Six months later the project is already late and over budget.
The developer who replaced the original one is working 12 hours a day
but the software never seems to get any closer to completion.
Part of the problem is the users say the software does not do what they
want and they keep asking for "must have" changes; also there is a ton
of bugs being found during tests. What went wrong?
Whatever it is your not alone.
The 2006 (Standish Group, 2008) indicates software projects generally
do not meet one or more of the cost (budget), time (schedule), or scope
requirements and only 35% of projects were successfully completed ? while
19% of projects were failures, and the remaining 46% were considered
challenged. An outcome labeled as successful must meet all three of the
triple constraint parameters. A challenged outcome is one that that was
completed and operational but did not meet one or more of the triple constraint
parameters and a failed outcome is a project that was started,
but was canceled at some time during the development cycle.
An analysis of approximately 250 software projects between 1995 and 2004
showed an interesting pattern. When comparing projects that were successful
vs. those that ran late, were over budget, or were canceled without completion,
the primary reasons were related to poor project management practices rather
than any other factors (Capers Jones, 2004).
In contrast, things look very different in the engineering and
construction industry. According to the Engineering News-Record,
94 percent of the project customers they queried were satisfied
with the results of their projects, which suggests that construction
projects have much lower failure rates than software projects.
NOTE: These numbers are from older reports because they were freely available.
Over my Information Systems career, I have always wondered why software
development is so different from say building a bridge. After all,
if the bridges had a failure rate of 19% and 46% were questionable
people would stick to ferries. Could it be that the level of education,
and training of IT professionals is lacking? As a rule do persons in this
field make more mistakes than the rest of the population? Are consumers of
these products more naive than most? If the primary reason for failure is
project management then why? Again, are the people involved somehow less
motivated, educated, or talented than project management teams who build bridges?
As it turns out it is not people, but the product itself. Building software is
different than building bridges or cars or houses. It cannot easily be build
using the traditional methods of project management. The following summaries
point out how software and the process of building software are unique and
different. Hopefully once you are aware of them, your next software project
will be a success.
Software is Intricate
Even a modest program can consist of thousands of lines of code. But the
number of lines only begins to tell how complex a program is. There are
many sets of instructions in a program and these instructions interact with
other instructions to accomplish tasks. There are various inputs and outputs
to and from varying devices and third party systems. Errors must be anticipated
and handled to prevent incorrect results or system failure.
Computer programs are the most intricate, delicately balanced and
finely interwoven of all the products of human industry to date. They
are machines with far more moving parts than any engine: the parts
don't wear out, but they interact and rub up against one another in
ways the programmers themselves cannot predict. [Gleik 1992]
Software is Intangible
Software doesn't have height or width, it has no mass or volume, and you can't
perceive it as you would a bridge. When a bridge is being built you can see the
parts being put together, even before it is complete you can envision it. Software
is more spectral; it is the instructions for a group of behaviors. You might be
able to visualize individual behaviors but things tend to blur as you try to pan
out to large numbers of sequential and alternative behaviors.
The same things that make it hard to visualize software make it hard to
draw blueprints of that software. An architectural drawing of a bridge shows the most
minute details of the structure yet it most certainly is not a bridge. The architectural
drawing corresponds to the structure, but it's not the same as the structure.
Software, conversely, is just instructions for the behaviors that the
programmers and users want to happen. The blueprint and the program are one in the
same. Once the instructions has been completely written, then the software has
been created. Nothing else needs to be done. We have automatic tools that
convert this representation into a binary that the computer can execute.
This is an important realization: any architecture, design, or diagram we create for
software is essentially inadequate. If we represent every detail, then we're merely
duplicating the software in another form, and we're wasting our time and effort.
Requirements are Deficient
Rarely do the people who use the software have experience dealing with the abstraction
and complexity of software. They are the expert in the business processes the software
is being designed for and understand the main behaviors that are required, however they
cannot be expected to take into account all of the alternative flows and error conditions,
and how different sets of requirements relate to each other.As stated previously, accurate
requirements are only realized as the completed software.This means that any specification
of requirements for software is likely to be incomplete in important ways.
As the users start seeing the developed software it becomes clearer to them and they start
adding "essential change requests". They do this because they're just not able to
visualize a system of this complexity until it's at least partially complete.
Users and developers must work together throughout the development, refining the
requirements. Users need to revise the features based on their testing of the system
as it is being built.
Technology Changes Rapidly
Twenty years ago we were struggling with the MS-DOS operating system and
creating simple spreadsheets on our PCs. Today we edit video on our computers
and connect to systems across the world. Computers double in speed about
every two years, and this opens up more and more opportunities for software
developers. Software changes quickly?we all know that?but we may not be
aware of just how quickly it changes, and what impact this has on any new
software we try to build.
In contrast, we've been building bridges for thousands of years, ever since
the time of the ancient Roman and Chinese civilizations. The problem is well
understood, and the technologies change slowly. The first design for a bridge resembling
the modern suspension bridge was in 1595, and that basic technology is still what we use
today.
Continued in next post......
You are in charge of getting a new system developed and implemented.
You have met with all interested parties and outlined what the system
needs to do. A developer is hired and is given the plan. You feel
confident that all is well and your system will be a success
?will it?
Not so fast. Six months later the project is already late and over budget.
The developer who replaced the original one is working 12 hours a day
but the software never seems to get any closer to completion.
Part of the problem is the users say the software does not do what they
want and they keep asking for "must have" changes; also there is a ton
of bugs being found during tests. What went wrong?
Whatever it is your not alone.
The 2006 (Standish Group, 2008) indicates software projects generally
do not meet one or more of the cost (budget), time (schedule), or scope
requirements and only 35% of projects were successfully completed ? while
19% of projects were failures, and the remaining 46% were considered
challenged. An outcome labeled as successful must meet all three of the
triple constraint parameters. A challenged outcome is one that that was
completed and operational but did not meet one or more of the triple constraint
parameters and a failed outcome is a project that was started,
but was canceled at some time during the development cycle.
An analysis of approximately 250 software projects between 1995 and 2004
showed an interesting pattern. When comparing projects that were successful
vs. those that ran late, were over budget, or were canceled without completion,
the primary reasons were related to poor project management practices rather
than any other factors (Capers Jones, 2004).
In contrast, things look very different in the engineering and
construction industry. According to the Engineering News-Record,
94 percent of the project customers they queried were satisfied
with the results of their projects, which suggests that construction
projects have much lower failure rates than software projects.
NOTE: These numbers are from older reports because they were freely available.
Over my Information Systems career, I have always wondered why software
development is so different from say building a bridge. After all,
if the bridges had a failure rate of 19% and 46% were questionable
people would stick to ferries. Could it be that the level of education,
and training of IT professionals is lacking? As a rule do persons in this
field make more mistakes than the rest of the population? Are consumers of
these products more naive than most? If the primary reason for failure is
project management then why? Again, are the people involved somehow less
motivated, educated, or talented than project management teams who build bridges?
As it turns out it is not people, but the product itself. Building software is
different than building bridges or cars or houses. It cannot easily be build
using the traditional methods of project management. The following summaries
point out how software and the process of building software are unique and
different. Hopefully once you are aware of them, your next software project
will be a success.
Software is Intricate
Even a modest program can consist of thousands of lines of code. But the
number of lines only begins to tell how complex a program is. There are
many sets of instructions in a program and these instructions interact with
other instructions to accomplish tasks. There are various inputs and outputs
to and from varying devices and third party systems. Errors must be anticipated
and handled to prevent incorrect results or system failure.
Computer programs are the most intricate, delicately balanced and
finely interwoven of all the products of human industry to date. They
are machines with far more moving parts than any engine: the parts
don't wear out, but they interact and rub up against one another in
ways the programmers themselves cannot predict. [Gleik 1992]
Software is Intangible
Software doesn't have height or width, it has no mass or volume, and you can't
perceive it as you would a bridge. When a bridge is being built you can see the
parts being put together, even before it is complete you can envision it. Software
is more spectral; it is the instructions for a group of behaviors. You might be
able to visualize individual behaviors but things tend to blur as you try to pan
out to large numbers of sequential and alternative behaviors.
The same things that make it hard to visualize software make it hard to
draw blueprints of that software. An architectural drawing of a bridge shows the most
minute details of the structure yet it most certainly is not a bridge. The architectural
drawing corresponds to the structure, but it's not the same as the structure.
Software, conversely, is just instructions for the behaviors that the
programmers and users want to happen. The blueprint and the program are one in the
same. Once the instructions has been completely written, then the software has
been created. Nothing else needs to be done. We have automatic tools that
convert this representation into a binary that the computer can execute.
This is an important realization: any architecture, design, or diagram we create for
software is essentially inadequate. If we represent every detail, then we're merely
duplicating the software in another form, and we're wasting our time and effort.
Requirements are Deficient
Rarely do the people who use the software have experience dealing with the abstraction
and complexity of software. They are the expert in the business processes the software
is being designed for and understand the main behaviors that are required, however they
cannot be expected to take into account all of the alternative flows and error conditions,
and how different sets of requirements relate to each other.As stated previously, accurate
requirements are only realized as the completed software.This means that any specification
of requirements for software is likely to be incomplete in important ways.
As the users start seeing the developed software it becomes clearer to them and they start
adding "essential change requests". They do this because they're just not able to
visualize a system of this complexity until it's at least partially complete.
Users and developers must work together throughout the development, refining the
requirements. Users need to revise the features based on their testing of the system
as it is being built.
Technology Changes Rapidly
Twenty years ago we were struggling with the MS-DOS operating system and
creating simple spreadsheets on our PCs. Today we edit video on our computers
and connect to systems across the world. Computers double in speed about
every two years, and this opens up more and more opportunities for software
developers. Software changes quickly?we all know that?but we may not be
aware of just how quickly it changes, and what impact this has on any new
software we try to build.
In contrast, we've been building bridges for thousands of years, ever since
the time of the ancient Roman and Chinese civilizations. The problem is well
understood, and the technologies change slowly. The first design for a bridge resembling
the modern suspension bridge was in 1595, and that basic technology is still what we use
today.
Continued in next post......
but some of the information is quite misleading IMO 
Comment