Software Engineering for Small Projects: A RUP-Centric Approach
Do you want to improve the process on your next project? Perhaps you'd like to combine the best practices from the Rational Unified Process (RUP) and from agile methodologies (such as Extreme Programming). If so, buy this book! "Software Engineering for Small Projects" takes you from the initial customer contact through the delivery of the software product, explaining through case study how one small, distributed team applied a successful process. But this is not a perfect case study. This story gives you the good, the bad, and the ugly of the project. It shows you what worked and what didn't, and describes how the team might change its process for the next project. The authors encourage you to look critically at what they did, and develop ideas to use on your next project.
Key topics covered include
- Achieving a balance between people, process, and tools; recognizing that software development is first and foremost a human endeavor
- Configuring a process that supports the people
- Adjusting the process as the project proceeds
- Selecting tools that support a small, distributed team
- Using RUP as an appropriate base for a small project
- Resolving technical details and people issues
- Dealing effectively with your customer
Whether you're a project lead, a programmer, or another member of the development team, this book will show you how to tap the strengths of specific processes to dramatically increase the productivity of your team.
Review By: Howard S. Epstein
09/16/2004"Software Engineering for Small Projects: A RUP-Centric Approach," was written by a small project team and is about a tool its members developed to support the Personal Software Process (PSP). During development, they follow the primary tenets of the Rational Unified Process, or RUP. This slim publication covers quite a bit of ground, and the reader will learn a lot about different topics in software development.
The book is written in a conversational tone and guides the reader through the four phases of RUP – from the beginning of the project (known in RUP as the inception phase) through the architecture design (elaboration phase), construction, and delivery (transition phase). The real focus is on the overall experience of developing a PSP tool that tracks and reports a developer's activities. The authors focus on the interactions between team members –what went well and what did not go so well during the project. The authors also provide tips that can aid other project efforts.
The book starts with a guide that explains how to apply the authors' process to other small projects. They advise the reader not to stick religiously to the principles any process provides. Instead, be smart, use common sense, and use the components of a process that apply to your project. For example, do not create any artifact (project deliverable) just because the process indicates it should be created.
Pollice et al. also detail the history of the project. The authors advise non-technical readers that skipping the technical solutions in the book is acceptable. Conversely, they feel providing design details and code constructs used to overcome challenges faced by team members is important to the reader's development.
The book ends with a post-mortem of the project from each author's perspective of what went well and what could have gone better if the project had to be redone. The book closes with three appendices: one provides an overview of RUP, one describes Watt Humphrey's PSP, and one outlines the basic "rules" of Extreme Programming.
The book's style is more interesting and engaging than the usual run-of-the-mill book on programming or process. At 250 pages, the book packs in advice on managing smaller projects effectively, using RUP for minor efforts, and how people issues can drag down a project even when the team consists of four or five people.
I recommend this book for its lessons, but I wish the authors would have gone deeper into the various problems they faced and how/why the team arrived at the solutions it did (or how they would have done things differently given a second chance). Too many pages are dedicated to the innards of the technology and how the code is written. A non-technical reader will most likely get lost in these chapters. On the other hand, a technical reader will find these discussions too elementary and will probably consult other programming guides for more information. Therefore, these chapters add little value to the book.
I recommend this book for small-project managers facing the following hurdles: a team learning to use a new process or deal with a new technology, a team that co-located during the course of the project, and a team with competing priorities that could hinder a project's success.