Author: Caper Jones
If software engineering has to be recognized as a true profession like other conventional engineering fields it has to inculcate the discipline of better measurements, better benchmarks, better quality control, and better security during the process of software development. Thus opines Caper Jones, the author of this book who is a well-respected authority in this field.
He also says that majority of the best-practice claims in software engineering fields are not based on solid measurements using valid metrics. In this book he attempts to remedy the situation by describing the best practices where the available quantitative data proves their effectiveness at least to some extent.
The book consists of nine chapters. I have summarized their key points below, heavily drawing upon author’s own summary in the introductory chapter.
Detailed table of content is available at McGraw Hill website.
Chapter 1- Introduction and Definitions of Software Best Practices: The author proposes a rating on a ( -10 to +10 scale) , based on the measured percentage productivity and quality improvement data collected by him and his team. He then ranks 200 practices ( which includes methodologies and results also) in software engineering which he has observed in 13,000 projects ( all types and sizes)in 600 companies over a period of 20 years on this rating scale. Based on the ratings these practices are classified as Best Practices (rating > 7.5), Very Good Practices, Good Practices, Fair Practices, Neutral Practices, Unsafe Practices, and Worst Practices. However also recognizing the fact that the best practices may vary depending upon the size and type of projects, the author also lists best practices of small projects (1000 Function points), large projects (10,000 function points), IT projects, embedded system projects.
You can read this chapter online at McGraw Hill website.
Chapter 2- Overview of 50 Software Best Practices: This chapter deals with development best practices, maintenance best practices, management best practices, and sociological best practices such as those dealing with layoffs. Other best-practice areas include security control, quality control, risk analysis, governance, and renovation of legacy applications.
Chapter 3- A Preview of Software Development and Maintenance in 2049: This chapter envisions the software engineering scenario in 2049. It looks ahead to specific technical topics such as role of data mining in gathering requirements and the possible availability of substantial libraries of certified reusable material. Also possible are intelligent agents and search-bots that will accumulate and even analyze information on critical topics. In author’s view significant improvements are needed in security, quality, and reusability to keep pace with hardware and network evolution by 2049.
Chapter 4- How Software Personnel Learn New Skills: Seventeen channels - for e.g. paper books, e-books, software journals, e-journals, blogs, wiki sites, commercial education, in-house education, academic education, live conferences, on-line conferences and webinars - available for transmitting and learning new software engineering information are evaluated in terms of their learning effectiveness, cost-effectiveness and long term evolution.
This chapter also suggests curricula for software engineers, software quality assurance personnel, software testers, software project office personnel, and software managers. The author highlights the lack of strong focus on topics like sizing, estimating, planning, metrics, security, quality control, maintenance, renovation, and software engineering economics in the academic curricula.
Chapter 5- Software Team Organization and Specialization: This chapter shows the results of many different kinds of organization structures, including pair programming, small Agile teams, hierarchical organizations, matrix organizations, and geographically dispersed virtual organizations. It also shows the most effective ways of organizing specialists like software quality assurance, testing, technical documentation, and project offices.
Chapter 6- Project Management and Software Engineering: Critical management functions that can cause software engineering failures if not done properly – like sizing, planning, estimating, progress tracking, resource tracking, benchmarks and change management – are dealt in this chapter. Author suggests that any software project of non-trivial size should collect both quality and productivity data that can be used for baselines and benchmarks. He argues strongly that failure to do so is a signal that “software engineering” is not yet a true engineering discipline.
Chapter 7- Requirements, Business Analysis, Architecture, Enterprise Architecture, and Design: This chapter discusses the most widely used methods (including Agile methods, UML) of dealing with requirements and design issues and shows the classes and types of applications for which they are best suited.
Chapter 8- Programming and Code Development: As of 2009, there are about 2500 programming languages and dialects. In this chapter the author discusses the maintenance nightmare created due to such plethora of languages. He suggests having a National Programming Translation Center that would record the syntax of all known languages and assist in converting applications written in dead languages into modern languages.
Information on the kinds of bugs found in source code, and the most effective “personal” methods of defect prevention and defect removal that are carried out by software engineers prior to public activities such as function and regression testing are included in this chapter.
This chapter also discusses methods of measuring programming productivity and quality levels. It challenges the traditional “lines of code” (LOC) metric since it penalizes high-level languages and distorts economic analysis. Besides LOC metric does not take into account the non-coding activities like requirements, design, screen, or documentation which constitute more than 60 percent of total development expenses. The alternative is slow and expensive functional metrics which can handle all such activities. However new high-speed functional metrics are starting to appear.
Chapter 9- Software Quality: The Key to Successful Software Engineering: This chapter attempts to cover all major factors that influence software quality, including both defect prevention methods and defect removal methods. It discusses the strengths and weaknesses of formal inspections, static analysis, and 17 different kinds of testing. In addition, the chapter deals with various troublesome metrics those degrade understanding software quality – for e.g. the popular “cost per defect” metric which actually penalizes quality and achieves the lowest cost for the buggiest applications.
The main theme of the chapter is that quality is the driving force that has more influence on software costs, schedules, and success than any other but poor measurement practices have made it difficult to carry out valid software engineering economic studies.
This chapter also challenges two common definitions of quality. The definition that quality means “conformance to requirements” is challenged on the grounds that many requirements are harmful or “toxic” and should not be implemented. The definition that quality means conformance to a list of words ending in “ility,” such as “portability”, is also challenged on the grounds that these terms can neither be predicted nor measured.
The chapter concludes that an activity that cannot measure its own results is not a true engineering discipline and so it is time for software engineering to study critical topics such as defect potentials and defect removal efficiency levels. Otherwise “software engineering” is a misnomer, and software development is only a craft and not a true profession.
This book is a result of extensive research by Caper Jones and provides lots of data and information. However there are several instances of repetitive information (for e.g. project taxonomy description) in this book, which could have been avoided. Also I felt that Chapter 3 (A Preview of Software Development and Maintenance in 2049) was rather unnecessary. These have increased the bulk (and the price??) of the book .
The book serves more as a pointer to best practices rather than providing in-depth understanding and know-how of implementing them. I was expecting more case studies in the book of this type. Besides I came across very few best practices which I was not earlier aware of.
On the whole a good reference book, especially if you need to do some research or need some facts and figures for arguing the case of a best practice. But I don’t otherwise consider it as a MUST Read book.
Published: 2009
Publisher: Tata McGraw Hill
Paperback: 688 Pages
If software engineering has to be recognized as a true profession like other conventional engineering fields it has to inculcate the discipline of better measurements, better benchmarks, better quality control, and better security during the process of software development. Thus opines Caper Jones, the author of this book who is a well-respected authority in this field.
He also says that majority of the best-practice claims in software engineering fields are not based on solid measurements using valid metrics. In this book he attempts to remedy the situation by describing the best practices where the available quantitative data proves their effectiveness at least to some extent.
The book consists of nine chapters. I have summarized their key points below, heavily drawing upon author’s own summary in the introductory chapter.
Detailed table of content is available at McGraw Hill website.
Chapter 1- Introduction and Definitions of Software Best Practices: The author proposes a rating on a ( -10 to +10 scale) , based on the measured percentage productivity and quality improvement data collected by him and his team. He then ranks 200 practices ( which includes methodologies and results also) in software engineering which he has observed in 13,000 projects ( all types and sizes)in 600 companies over a period of 20 years on this rating scale. Based on the ratings these practices are classified as Best Practices (rating > 7.5), Very Good Practices, Good Practices, Fair Practices, Neutral Practices, Unsafe Practices, and Worst Practices. However also recognizing the fact that the best practices may vary depending upon the size and type of projects, the author also lists best practices of small projects (1000 Function points), large projects (10,000 function points), IT projects, embedded system projects.
You can read this chapter online at McGraw Hill website.
Chapter 2- Overview of 50 Software Best Practices: This chapter deals with development best practices, maintenance best practices, management best practices, and sociological best practices such as those dealing with layoffs. Other best-practice areas include security control, quality control, risk analysis, governance, and renovation of legacy applications.
Chapter 3- A Preview of Software Development and Maintenance in 2049: This chapter envisions the software engineering scenario in 2049. It looks ahead to specific technical topics such as role of data mining in gathering requirements and the possible availability of substantial libraries of certified reusable material. Also possible are intelligent agents and search-bots that will accumulate and even analyze information on critical topics. In author’s view significant improvements are needed in security, quality, and reusability to keep pace with hardware and network evolution by 2049.
Chapter 4- How Software Personnel Learn New Skills: Seventeen channels - for e.g. paper books, e-books, software journals, e-journals, blogs, wiki sites, commercial education, in-house education, academic education, live conferences, on-line conferences and webinars - available for transmitting and learning new software engineering information are evaluated in terms of their learning effectiveness, cost-effectiveness and long term evolution.
This chapter also suggests curricula for software engineers, software quality assurance personnel, software testers, software project office personnel, and software managers. The author highlights the lack of strong focus on topics like sizing, estimating, planning, metrics, security, quality control, maintenance, renovation, and software engineering economics in the academic curricula.
Chapter 5- Software Team Organization and Specialization: This chapter shows the results of many different kinds of organization structures, including pair programming, small Agile teams, hierarchical organizations, matrix organizations, and geographically dispersed virtual organizations. It also shows the most effective ways of organizing specialists like software quality assurance, testing, technical documentation, and project offices.
Chapter 6- Project Management and Software Engineering: Critical management functions that can cause software engineering failures if not done properly – like sizing, planning, estimating, progress tracking, resource tracking, benchmarks and change management – are dealt in this chapter. Author suggests that any software project of non-trivial size should collect both quality and productivity data that can be used for baselines and benchmarks. He argues strongly that failure to do so is a signal that “software engineering” is not yet a true engineering discipline.
Chapter 7- Requirements, Business Analysis, Architecture, Enterprise Architecture, and Design: This chapter discusses the most widely used methods (including Agile methods, UML) of dealing with requirements and design issues and shows the classes and types of applications for which they are best suited.
Chapter 8- Programming and Code Development: As of 2009, there are about 2500 programming languages and dialects. In this chapter the author discusses the maintenance nightmare created due to such plethora of languages. He suggests having a National Programming Translation Center that would record the syntax of all known languages and assist in converting applications written in dead languages into modern languages.
Information on the kinds of bugs found in source code, and the most effective “personal” methods of defect prevention and defect removal that are carried out by software engineers prior to public activities such as function and regression testing are included in this chapter.
This chapter also discusses methods of measuring programming productivity and quality levels. It challenges the traditional “lines of code” (LOC) metric since it penalizes high-level languages and distorts economic analysis. Besides LOC metric does not take into account the non-coding activities like requirements, design, screen, or documentation which constitute more than 60 percent of total development expenses. The alternative is slow and expensive functional metrics which can handle all such activities. However new high-speed functional metrics are starting to appear.
Chapter 9- Software Quality: The Key to Successful Software Engineering: This chapter attempts to cover all major factors that influence software quality, including both defect prevention methods and defect removal methods. It discusses the strengths and weaknesses of formal inspections, static analysis, and 17 different kinds of testing. In addition, the chapter deals with various troublesome metrics those degrade understanding software quality – for e.g. the popular “cost per defect” metric which actually penalizes quality and achieves the lowest cost for the buggiest applications.
The main theme of the chapter is that quality is the driving force that has more influence on software costs, schedules, and success than any other but poor measurement practices have made it difficult to carry out valid software engineering economic studies.
This chapter also challenges two common definitions of quality. The definition that quality means “conformance to requirements” is challenged on the grounds that many requirements are harmful or “toxic” and should not be implemented. The definition that quality means conformance to a list of words ending in “ility,” such as “portability”, is also challenged on the grounds that these terms can neither be predicted nor measured.
The chapter concludes that an activity that cannot measure its own results is not a true engineering discipline and so it is time for software engineering to study critical topics such as defect potentials and defect removal efficiency levels. Otherwise “software engineering” is a misnomer, and software development is only a craft and not a true profession.
This book is a result of extensive research by Caper Jones and provides lots of data and information. However there are several instances of repetitive information (for e.g. project taxonomy description) in this book, which could have been avoided. Also I felt that Chapter 3 (A Preview of Software Development and Maintenance in 2049) was rather unnecessary. These have increased the bulk (and the price??) of the book .
The book serves more as a pointer to best practices rather than providing in-depth understanding and know-how of implementing them. I was expecting more case studies in the book of this type. Besides I came across very few best practices which I was not earlier aware of.
On the whole a good reference book, especially if you need to do some research or need some facts and figures for arguing the case of a best practice. But I don’t otherwise consider it as a MUST Read book.
3 comments:
interesting blog. It would be great if you can provide more details about it. Thanks you
Software Development in India
Mani, Thanks for your comments. Could you please let me know what specific details you are looking for.
Thanks for sharing this post and the efforts you have made in writing this. If you have more info about Software testing companies, please share. Good to see such nice articulated post.
Post a Comment