Software Engineering Best Practices
Foreword
Software Engineering is about people—the people who have a need for
and use software, the people who build software, the people who test
software, the people who manage software projects, and the people who
support and maintain software. So why is it that the emphasis of software
engineering still concentrates on the technology?
How old is the business of software development? Let’s settle on
55 years. That means a full generation has moved through the industry.
These people were trained, spent their lives working on software, and
are now retired or close to retirement. In their time, they have seen
innumerable promises of “a better way”—silver bullets by the score.
There have been thousands of new programming languages, all manner
of methodologies, and a plethora of new tools. It sometimes seems as
if the software industry is as strongly driven by fads and fashion as
the garment industry. Many practitioners become apostolic in their
worship of a particular approach, practice, or tool—for a while at
least. But when the metrics are collected and analyzed, the sad truth
is revealed—as an industry we have not made a great deal of progress.
There have been no major breakthroughs that have led to the painless
production of quality software delivered on time and within a predicted
cost. And the skeptics ask, “Is software engineering an oxymoron?”
Our fixation on technology blinds us. We don’t want to, or can’t, see
the need to embrace basic, sound engineering practices. In this book,
Capers Jones contends that if the software industry wants to be recognized
as an engineering discipline, rather than a craft, then it must
employ solid engineering practices to deliver an acceptable result, economically.
Technology is fascinating, but it is not the most important
factor when it comes to doing good work and delivering a good result.
The way people work, the choices they make, and the disciplines they
choose to apply, will have more impact on the success of a software
project than the choice of technology.
There must be times when Capers feels like a prophet alone in a desert.
He has been tirelessly providing the software industry with guidance
and use software, the people who build software, the people who test
software, the people who manage software projects, and the people who
support and maintain software. So why is it that the emphasis of software
engineering still concentrates on the technology?
How old is the business of software development? Let’s settle on
55 years. That means a full generation has moved through the industry.
These people were trained, spent their lives working on software, and
are now retired or close to retirement. In their time, they have seen
innumerable promises of “a better way”—silver bullets by the score.
There have been thousands of new programming languages, all manner
of methodologies, and a plethora of new tools. It sometimes seems as
if the software industry is as strongly driven by fads and fashion as
the garment industry. Many practitioners become apostolic in their
worship of a particular approach, practice, or tool—for a while at
least. But when the metrics are collected and analyzed, the sad truth
is revealed—as an industry we have not made a great deal of progress.
There have been no major breakthroughs that have led to the painless
production of quality software delivered on time and within a predicted
cost. And the skeptics ask, “Is software engineering an oxymoron?”
Our fixation on technology blinds us. We don’t want to, or can’t, see
the need to embrace basic, sound engineering practices. In this book,
Capers Jones contends that if the software industry wants to be recognized
as an engineering discipline, rather than a craft, then it must
employ solid engineering practices to deliver an acceptable result, economically.
Technology is fascinating, but it is not the most important
factor when it comes to doing good work and delivering a good result.
The way people work, the choices they make, and the disciplines they
choose to apply, will have more impact on the success of a software
project than the choice of technology.
There must be times when Capers feels like a prophet alone in a desert.
He has been tirelessly providing the software industry with guidance
Introduction
Between the time this book was started and the time it was completed,
the global recession began. As a result, this book moved in a somewhat
different direction than older books dealing with software engineering.
Due to the recession, the book now includes material on dealing with
layoffs and downsizing; on the changing economic balance between the
United States and other countries; and on the economics of software
during a recessionary period.
Software engineering was not immediately affected by the financial
crisis and the recession when it started in 2008, but as time passed,
venture funds began to run out. Other forms of financing for software
companies became difficult, so by the middle of 2009, software engineering
positions were starting to be affected by layoffs. Specialty positions
such as quality assurance and technical writing have been affected
even more severely, since such positions are often the first to go during
economic downturns.
One unexpected byproduct of the recession is that the availability of
software engineers combined with a reduction in compensation has made
the United States a candidate for becoming an outsource country.
As of 2009, the cost differentials between the United States, India,
and China are being lowered, and the convenience of domestic contracts
versus international contracts may prove to be beneficial for the software
engineering community of the United States.
As the recession continues, the high costs of software are being examined
more seriously than in the past. The recession also highlights the
fact that software has always been insecure. Due to the recession, cybercrime
such as the theft of valuable information, identity theft, and even
embezzlement are increasing rapidly. There are also sharp increases in
“phishing” or attempting to use false messages to gain access to personal
bank accounts.
the global recession began. As a result, this book moved in a somewhat
different direction than older books dealing with software engineering.
Due to the recession, the book now includes material on dealing with
layoffs and downsizing; on the changing economic balance between the
United States and other countries; and on the economics of software
during a recessionary period.
Software engineering was not immediately affected by the financial
crisis and the recession when it started in 2008, but as time passed,
venture funds began to run out. Other forms of financing for software
companies became difficult, so by the middle of 2009, software engineering
positions were starting to be affected by layoffs. Specialty positions
such as quality assurance and technical writing have been affected
even more severely, since such positions are often the first to go during
economic downturns.
One unexpected byproduct of the recession is that the availability of
software engineers combined with a reduction in compensation has made
the United States a candidate for becoming an outsource country.
As of 2009, the cost differentials between the United States, India,
and China are being lowered, and the convenience of domestic contracts
versus international contracts may prove to be beneficial for the software
engineering community of the United States.
As the recession continues, the high costs of software are being examined
more seriously than in the past. The recession also highlights the
fact that software has always been insecure. Due to the recession, cybercrime
such as the theft of valuable information, identity theft, and even
embezzlement are increasing rapidly. There are also sharp increases in
“phishing” or attempting to use false messages to gain access to personal
bank accounts.
From the author’s viewpoint, the recession is highlighting four critical
areas where software engineering needs to improve to become a solid
engineering discipline rather than a craft:
1. Software security needs to be improved organically by raising the
immunity levels of applications and including better security features
in programming languages themselves. Access control and
permissions are weak links in software engineering.
2. Software quality needs to be improved in terms of both defect prevention
methods and defect removal methods. Poor quality has damaged
the economics of software for 50 years, and this situation cannot continue.
Every major application needs to use effective combinations of
inspections, static analysis, and testing. Testing alone is inadequate
to achieve high quality levels.
3. Software measurements need to be improved in order to gain better
understanding of the true economic picture of software development
and software maintenance. This implies moving to activity-based
costs. Better measurement also implies analyzing the flaws of traditional
metrics such as “cost per defect” and “lines of code,” which
violate the rules of standard economics.
4. Due to the recession, new development is slowing down, so the economics
of software maintenance and renovation need to be better
understood. Methods of preserving and renovating legacy applications
are increasingly important, as are methods of mining legacy
applications for “lost” requirements and business rules.
As of 2009, the great majority of companies and the great majority of
software engineers have no effective measurements of either productivity
or quality. This is not a suitable situation for a true engineering discipline.
Lack of measurements combined with hazardous metrics mean
that evaluating the effectiveness of methods such as Agile, Rational
Unified Process (RUP), and the Team Software Process (TSP) is harder
than it should be.
While the lack of measurements and the ability to judge the effectiveness
of software engineering methods and practices was inconvenient
when the economy was growing, it is a serious problem during a recession.
Poor measurements have made phrases such as “best practices”
embarrassing for software, because a majority of the best-practice claims
have not been based on solid measurements using valid metrics.
This book attempts to show a combination of metrics and measurements
that can demonstrate effectiveness and hopefully place software
engineering on a sound economic basis. The “best practices” described
to download this course click here
areas where software engineering needs to improve to become a solid
engineering discipline rather than a craft:
1. Software security needs to be improved organically by raising the
immunity levels of applications and including better security features
in programming languages themselves. Access control and
permissions are weak links in software engineering.
2. Software quality needs to be improved in terms of both defect prevention
methods and defect removal methods. Poor quality has damaged
the economics of software for 50 years, and this situation cannot continue.
Every major application needs to use effective combinations of
inspections, static analysis, and testing. Testing alone is inadequate
to achieve high quality levels.
3. Software measurements need to be improved in order to gain better
understanding of the true economic picture of software development
and software maintenance. This implies moving to activity-based
costs. Better measurement also implies analyzing the flaws of traditional
metrics such as “cost per defect” and “lines of code,” which
violate the rules of standard economics.
4. Due to the recession, new development is slowing down, so the economics
of software maintenance and renovation need to be better
understood. Methods of preserving and renovating legacy applications
are increasingly important, as are methods of mining legacy
applications for “lost” requirements and business rules.
As of 2009, the great majority of companies and the great majority of
software engineers have no effective measurements of either productivity
or quality. This is not a suitable situation for a true engineering discipline.
Lack of measurements combined with hazardous metrics mean
that evaluating the effectiveness of methods such as Agile, Rational
Unified Process (RUP), and the Team Software Process (TSP) is harder
than it should be.
While the lack of measurements and the ability to judge the effectiveness
of software engineering methods and practices was inconvenient
when the economy was growing, it is a serious problem during a recession.
Poor measurements have made phrases such as “best practices”
embarrassing for software, because a majority of the best-practice claims
have not been based on solid measurements using valid metrics.
This book attempts to show a combination of metrics and measurements
that can demonstrate effectiveness and hopefully place software
engineering on a sound economic basis. The “best practices” described
to download this course click here
