Architecture-Centric Software Project Management: A Practical Guide
||Author: Daniel J. Paulish|
List Price: $34.99
Our Price: Click to see the latest and low price
Publisher: Addison-Wesley Pub Co (27 December, 2001)
Sales Rank: 70,674
Average Customer Rating: 4.5 out of 5
Customer ReviewsRating: 4 out of 5
Describes an ideal manager for software development
Constructing the appropriate team and environment for the creation of a software project is difficult because writing code is difficult. Many still object to the term "software engineering" because they feel, with a great deal of justification, that it is not yet stable enough to be a field of engineering. To them, a field of engineering has a set of formulas that define the rules for the use of raw materials. Engineers then construct their edifices by placing the proper numbers in the formulas and then building the structure using the results. Despite decades of effort to make it otherwise, software creation is still more art than engineering.
Paulish understands this and uses rules of thumb rather than formulas to describe the software construction process. It all starts with the software development plan (SDP), a description of the organizational structure of the process and the roles and responsibilities of all the members of the team. Short and primarily in outline form, it sets out the general format of how the goals are to be achieved. Experienced managers understand that this starts as a straw man, to be slowly solidified as all inputs are accepted and incorporated.
The hardest part of all software projects is the management of expectations, and it is the place where a manager can make the most difference. One of the quickest ways to poison a well functioning team is to allow unreasonable or inaccurate expectations to be inserted into the plan, either explicitly or by rumor. Paulish devotes chapter four to this, although it is too short. There is much more to this area than he lists in chapter four. Fortunately, this idea recurs in many other sections, so it does receive adequate coverage.
In the modern world, the management of a distributed workforce is fairly typical, and as anyone who has done it will tell you, in many cases the time differential is one of the smaller problems. Language difficulties also occur, but the real difficulties are the social and cultural differences. When you consider how difficult it is to communicate when you share the same cultural background, language, office space and are in proximity for eight hours a day, you realize how difficult it is to make yourself understood when you are separated by half a planet. Chapter 6 is devoted to this issue, but once again, not enough ink and paper are used to cover this critical area. The best piece of advice in the entire book is to undergo some form of focused multicultural training before embarking on an outsourcing project.
While there is a chapter devoted to metrics used to chart progress, it is largely devoid of formulas and expressions. Many of the metrics used are politely referred to as "controversial", which is often a euphemism for "widely disbelieved." Paulish firmly believes in leaving aside the firm tracking mechanisms and relying on hands-on efforts such as following the daily bug tracks and even working as an informal tester. This will give a manager a feel for the software that no other technique ever could.
One of the last chapters is also one of the best, where the simple question "What is a good job?" is asked and answered. This is critical, for software is one area where you can win the battle but lose the war. Many software projects deliver a functioning product and a team of dysfunctional members. The best managers reach the release date with a team that is tired and proud rather than just tired. Paulish rightly considers the staff turnover metric to be one of the key indicators of whether the project can be deemed a success.
Paulish describes a quality, maybe even an ideal manager, which is someone who absorbs a lot of the normal shocks of software development rather than amplifying them before passing them on. His ideas will work to make software development projects work over the long term and if you are in that group, then some of your attention should be focused on what he is saying.
Rating: 5 out of 5
Lynchpin of SEI's architecture and product-line material
The ideal audience of this book includes anyone who works within, or who follows, SEI's (Software Engineering Institute's) extensive body of work on architecture and/or product line engineering, or who needs to develop a project management framework for software development. While the approach in this book is more suited for product-oriented development, it can also be used for major internal projects.
As the title implies, the focus on the project management framework is the architecture, and the key elements of the approach are planning, organizing, implementing and measuring. The latter element lends itself to continuous refinement and fits nicely into CMM level 4 and 5 organization, which is not surprising since the CMM is embedded in practically every guide produced by SEI.
What makes this book special, though, is the clearly defined approach that is systematically presented using case studies and frequent diagrams to orient you as you go through the book. More importantly, the author communicates a vision and shows how to put it into practice.
I like the approach because it lends itself to realistic project planning and estimation. By taking an architecture-centric approach it's easy to develop a complete work breakdown structure early in the planning phase, which provides a foundation for detailed estimating. I also like the way the approach separates, then integrates, team organization, requirements and strategy, risk management and release planning.
This is not another project management methodology, but instead, shows how to use architecture as the focal point of the project and use whatever specific PM methodology suits your organization to effectively define project deliverables and the final product. It's complete, realistic and will work in practice.
Rating: 4 out of 5
PM & Global Development
Certainly the importance of mastering project management, in particular for products that contain signficant amounts of software, is crucial for business success, both at Siemens and elsewhere. This book is based on extensive practical experience and is a broad and well-written book on this topic. The special focus on software architecture as a major success factor for projects provides a useful perspective -- not only for project managers but also software architects as well as others in the software development team. This book also provides a unique "global development" perspective on the topic of project management.
· Beyond Software Architecture: Creating and Sustaining Winning Solutions
· Software Architecture in Practice, Second Edition
· Model Driven Architecture: Applying MDA to Enterprise Computing
· Documenting Software Architectures: Views and Beyond
· Evaluating Software Architectures: Methods and Case Studies