Many in the extreme and agile communities have long held the RationalUnified Process as being an antithesis approach to program development -citing it as being too process oriented, too rigid and structured, and overlyconcerned with documentation. This book is Rational's reaction to thatinaccurate perception. Using a project case study that is carried throughout thebook, the authors illustrate how agile techniques can be used effectively in aRUP environment. While not taking the extreme or agile communities to taskfor their expressed disdain for process, this book shows that process caneffectively accommodate design and development approaches which are notusually associated with the RUP. Software Engineering for Small Projectssuccessfully extends the appeal of the Rational Unified Process.
Book Description
Editorial Reviews
From the Back Cover
“A lot of RUP users are looking for examples of practical usage, and this book provides excellent insight on how RUP can be applied in practice to a small project. It walks you through the different phases, from project initiation to completion. The authors have done a good job highlighting both the problems that they ran into, as well as the success they had.”
—Per KrollManager, RUP, Rational Software
IBM Corporation
“I loved this book because it is easy to read and full of good stuff that should help software people. It describes how a small team effectively used RUP (Rational Unified Process), a process that is usually thought of as being useful only by large, high-ceremony teams. The authors’ straightforward, low-B.S. approach conveys some serious truths and advice. This book belongs on every bookshelf.”
—Dan Rawsthorne, Ph.D."I highly recommend this book for anyone who's ever tried to implement RUP on a small project. Pollice and company have demystified and effectively scaled the process while ensuring that its essence hasn't been compromised. A must-have for any RUPster's library!"
—Chris Soskin, Process Engineering Consultant, Toyota Motor Sales
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 Development for Small Teams describes an entire software development project, from the initial customer contact through delivery of the software. Through a case study, it describes how one small, distributed team designed and applied a successful process. But this is not a perfect case study. The story includes what worked and what didn't, and describes how the team might change its process for the next project. The authors encourage you to assess their results and to use the lessons learned on your next project.
Key topics covered include:- Achieving a balance between people, process, and tools; recognizing that software development is primarily a human endeavor
- Using RUP as an appropriate foundation for a small project; combining RUP and agile principles to create a workable process
- Configuring a process that supports the project members, helping them work more effectively
- Adjusting the process over the course of the project
- Selecting tools to support a small, distributed team
- 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.
About the Author
Gary Pollice has worked in software development for almost thirty-five years. He was Rational Software's RUP Curmudgeon when this book was started and has since moved on to academia, where he is a professor of practice in the Computer Science Department at Worcester Polytechnic Institute.
Liz Augustine has worked in the software industry for more than twenty years, first as a software developer and now as a technical writer. Throughout her career, she has worked on projects to help software developers work more effectively.
Chris Lowe has developed software for Digital Equipment Corporation, Funk Software, Rational Software, and IBM. In his spare time, Chris is a member of Toastmasters International, plays the keyboards and sings at his church, volunteers for the Boston Museum of Science, and dabbles in woodworking.
Jas Madhur has worked in the high-tech sector in Vancouver, Canada, since 1985. He was part of the original Rational Unified Process (RUP) team, and has gone on to work as a consultant, establishing an e-learning company. He lectures on software engineering processes at the University of British Columbia, and is a member of the International Council of Systems Engineering (INCOSE).
0321199502AB10162003
Product Details
Would you like to update product info or give feedback on images?
|
More About the Author
Discover books, learn about writers, read author blogs, and more.
Customer Reviews
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
8 of 8 people found the following review helpful:
4.0 out of 5 stars
Good Buy,
By
This review is from: Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series) (Paperback)
This is what I call a "nightstand book". It's very readable and won't overload your gray brain cells while still stimulating you to analyze your conceptions of the real world you're faced with at work. It's a story about a voluntary software project implemented by the authors on their free time and provides a nice overview of how RUP can be applied to a small project, mixed in with certain ingredients from agile processes such as XP.The focus of the book is to document what decisions and obstacles the four-member team encountered during the 6 months they spent on the project. The story is very entertaining and I read the book (almost) cover to cover in just 4 days. I found the tips and guidelines splattered around the book to be mostly common sense, but I did make some notes regarding what to do at work a.s.a.p. That's always a sign that the book you're reading was worth reading. One thing that annoyed me though was the constant praise of the Rational product line knowing that all four authors worked for Rational Software during the project. Also, there were a couple of chapters dedicated for showing little islands of the implementation (code snippets etc.) of which value I frankly didn't see. In summary, I'd classify this book as a good buy. Not great, but good. No big revelations, but a nice bunch of thought-provokers here and there.
7 of 7 people found the following review helpful:
4.0 out of 5 stars
Good advice, but only if you are selective,
By Charles Ashbacher (Marion, Iowa United States) - See all my reviews (TOP 500 REVIEWER) (VINE VOICE) (HALL OF FAME REVIEWER)
This review is from: Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series) (Paperback)
This book is a case study of a completed software development project done by a small, distributed team. What is unique about it is that the members of the team were all employed in full-time positions at different places doing other things. In that respect, their experiences are not those of the usual development team, but are more comparable to an open source project. However, since open source projects are largely driven by the passion and dedication of the project members, there are some significant differences. Combining all of this, there are some major questions as to whether their experiences can be transferred over to the development of software by a small team all employed by the same company. The answer to each question is very situation specific.
In the area of effective communication, there is no question that their experiences can serve as a model for all projects. Since any of the team members could have had their employment changed at any time without considering the consequences to the project, all planning had to incorporate the reality of staff change. This is one of the weaknesses of many projects, in that there is no allowance for team members being fired, being transferred to another position, resigning or the task being outsourced. Therefore, the situation for this project, which can be considered an extreme case, is a model for how the communication between the members, including future additions, should be managed. The strategy used in the selection of tools is also one that can serve as a model for all projects. Once again, the unusual nature of the team composition means that it can be considered an extreme case. There are aspects of this project that I do not believe can be transferred to other projects. The people were all volunteers for the development team. In the real world, the selection of the team members is largely by being assigned by management, and is not always based on the quality of the skill set. In many cases it is based on nothing more than current availability. The situation described here immediately introduces a level of team cooperation that cannot be otherwise assumed. The team members all knew each other and were aware of the quality of each other's work. From this, it is clear that the selection of the team members would be skewed towards people who would more naturally work together and had the needed skills. While there was naturally some pressure to succeed, it was not the kind faced by developers working on an industry project. The kind of pressure you face there is the threat of job loss or the company folding if the project is not delivered on time and fully functional. The last aspect is one that deals with the purpose of the project. If it was begun with the idea that their experiences would be recorded and used as the basis of this book, then there would be a natural tendency to complete the project and make it sound good. As someone who has written several books, I understand how the pressure to complete the book can be a powerful driving force. I have no direct evidence that their reporting is skewed in any way. In fact, it appears that the authors are extremely forthright in describing what went wrong during the creation. My raising the point is based on a fundamental understanding of human nature and how we tend to discover what we are looking for. If you are in the position where you are building a distributed team using people who all have full time jobs doing other things, then this book is perfect for you. For everyone else, you can learn things from their experiences, but it will be necessary for you to be very selective in your education.
Share your thoughts with other customers: Create your own review
|
|
Suggested Tags from Similar Products(What's this?)Be the first one to add a relevant tag (keyword that's strongly related to this product).
|
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
