What do you think?
Rate this book
Software Methodologies: A Quantitative Guide
This comprehensive reference uses a formal and standard evaluation technique to show the strengths and weakness of more than 60 software development methodologies such as agile, DevOps, RUP, Waterfall, TSP, XP and many more. Each methodology is applied to an application of 1000 function points using the Java language. Each methodology produces a characteristic set of results for development schedules, productivity, costs, and quality. The intent of the book is to show readers the optimum kinds of methodologies for the projects they are concerned with and to warn them about counter indications and possible harm from unsuitable methodologies.
578 pages, Hardcover
Published July 14, 2017
2 people are currently reading
7 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
December 5, 2018
I am left with mixed feeling overall.
I like this book. I'm going to keep it on my software engineering shelf simply because there isn't anything else like this. Yet I wish the book presented a more rigorous, detailed analysis that was open to review.
What I Liked
If the goal is to figure out which aspects of which methodology to study when comparing two methodologies then this book can be a good starting point.
Take the clues provided by the author's analysis as a starting point and then go off on your own study of the methodologies thus shortlisted. The book is a time-saver in this regard and so perhaps fulfills the purpose for which it is written.
Often a particular weakness in a methodology is sufficient to rule it out as a candidate suitable for use in a given context. This book makes it very easy to figure out which particular weakness of a given methodology we need to look at in a given context to make a good argument against the methodology. Refer to this book, figure out the Achilles heel of the methodology, see if it is important in our context, then go study that aspect of the methodology in more detail and make a reasoned argument. While you're at it, the book might also give clues to (some of) the alternatives available instead.
Lastly, the book lists many methodologies that I wouldn't have considered development methodologies to begin with (and I am still not sure whether I do). One such example is 'Legacy Repair Development' which sounds more like the nature of the work rather than a way of working. The good part though is that the author is stating what he is seeing. If most of the development work is legacy software renovation then it needs to be measured and categorized, regardless of whether academia has caught up or not.
What I Disliked
As the author clarifies, there are quite a few popular and successful development methodologies for which reliable data is not available. So the coverage is necessarily incomplete. The practitioner is likely to encounter methodologies that aren't adequately represented in this book.
There are no references to the underlying data being used for the analysis nor a sufficient coverage of how the analysis scale and dimensions are suitable. Minimal to no references to relevant literature and case studies on claims made by the author.
The methodologies themselves are only referred by title and not described in detail. At times the paragraphs accompanying the analysis are anecdotes, opinions, and speculations about the future. These are interesting. But perhaps not what one would want to see in a quantitative analysis. With the corresponding data being unavailable one can only hope that similar levels of speculations did not go into the quantitative analysis.
I like this book. I'm going to keep it on my software engineering shelf simply because there isn't anything else like this. Yet I wish the book presented a more rigorous, detailed analysis that was open to review.
What I Liked
If the goal is to figure out which aspects of which methodology to study when comparing two methodologies then this book can be a good starting point.
Take the clues provided by the author's analysis as a starting point and then go off on your own study of the methodologies thus shortlisted. The book is a time-saver in this regard and so perhaps fulfills the purpose for which it is written.
Often a particular weakness in a methodology is sufficient to rule it out as a candidate suitable for use in a given context. This book makes it very easy to figure out which particular weakness of a given methodology we need to look at in a given context to make a good argument against the methodology. Refer to this book, figure out the Achilles heel of the methodology, see if it is important in our context, then go study that aspect of the methodology in more detail and make a reasoned argument. While you're at it, the book might also give clues to (some of) the alternatives available instead.
Lastly, the book lists many methodologies that I wouldn't have considered development methodologies to begin with (and I am still not sure whether I do). One such example is 'Legacy Repair Development' which sounds more like the nature of the work rather than a way of working. The good part though is that the author is stating what he is seeing. If most of the development work is legacy software renovation then it needs to be measured and categorized, regardless of whether academia has caught up or not.
What I Disliked
As the author clarifies, there are quite a few popular and successful development methodologies for which reliable data is not available. So the coverage is necessarily incomplete. The practitioner is likely to encounter methodologies that aren't adequately represented in this book.
There are no references to the underlying data being used for the analysis nor a sufficient coverage of how the analysis scale and dimensions are suitable. Minimal to no references to relevant literature and case studies on claims made by the author.
The methodologies themselves are only referred by title and not described in detail. At times the paragraphs accompanying the analysis are anecdotes, opinions, and speculations about the future. These are interesting. But perhaps not what one would want to see in a quantitative analysis. With the corresponding data being unavailable one can only hope that similar levels of speculations did not go into the quantitative analysis.
Displaying 1 of 1 review