Title:
Project management with the IBM Rational Unified Process : lessons from the trenches
Personal Author:
Publication Information:
Upper Saddle River, NJ : IBM Press, 2007
ISBN:
9780321336392
Available:*
Library | Item Barcode | Call Number | Material Type | Item Category 1 | Status |
---|---|---|---|---|---|
Searching... | 30000010125611 | HD69.P75 G524 2007 | Open Access Book | Book | Searching... |
Searching... | 30000010125610 | HD69.P75 G524 2007 | Open Access Book | Book | Searching... |
On Order
Summary
Summary
#65533; Master win-win techniques for managing outsourced and offshore projects, from procurement and risk mitigation to maintenance
#65533; Use RUP to implement best-practice project management throughout the software development lifecycle #65533; Overcome key management challenges, from changing requirements to managing user expectations The Hands-On, Start-to-Finish Guide to Managing Software Projects with the IBM#65533; Rational Unified Process#65533; This is the definitive guide to managing software development projects with the IBM Rational Unified Process (RUP#65533;). Drawing on his extensive experience managing projects with the RUP, R. Dennis Gibbs covers the entire development lifecycle, from planning and requirements to post-mortems and system maintenance. Gibbs offers especially valuable insights into using the RUP to manage outsourced projects and any project relying on distributed development teams--outsourced, insourced, or both. This "from the trenches" guidebook is invaluable for anyone interested in best practices for managing software development: project managers, team leaders, procurement and contracting specialists, quality assurance and software process professionals, consultants, and developers. If you're already using the RUP, Gibbs will help you more effectively use it. Whatever your role or the RUP experience, you'll learn ways to #65533; Simplify and streamline the management of any large-scale or outsourced project #65533; Overcome the challenges of using the RUP in software project management #65533; Optimize software procurement and supplier relationships, from Request for Proposals (RFPs) and contracts to delivery #65533; Staff high-performance project teams and project management offices #65533; Establish productive, consistent development environments #65533; Run effective project kickoffs #65533; Systematically identify and mitigate project risks #65533; Manage the technical and business challenges of changing requirements #65533; Organize iterations and testing in incremental development processes #65533; Transition new systems into service: from managing expectations to migrating data #65533; Plan system maintenance and implement effective change control #65533; Learn all you can from project post-mortems--and put those lessons into practiceAuthor Notes
R. Dennis Gibbs has been immersed in a variety of roles since beginning his career in the software industry in the early 1980s, including roles in programming, software technical support, quality assurance, systems engineering, software engineering, project and program management, and consulting and mentoring. His customers have been a mix of commercial and government clients, particularly centered on the civilian federal government and Department of Defense sectors. He currently is a software architect with Electronic Data Systems (EDS) in Herndon, Virginia.
Table of Contents
Acknowledgments | p. xvii |
About the Author | p. xix |
Introduction | p. 1 |
Chapter 1 Introduction to Outsourcing | p. 7 |
Outsourcing Defined | p. 8 |
Four Common Scenarios Encountered in Outsourced Projects | p. 9 |
Scenario 1 Colocated Contractors | p. 10 |
Scenario 2 Offshore Projects | p. 13 |
Scenario 3 Distant Contractors, Same Country | p. 17 |
Scenario 4 Multiple Contractors | p. 17 |
Where Does the Rational Unified Process Fit in All of This? | p. 19 |
Summary | p. 19 |
What's Next? | p. 20 |
Chapter 2 Overview of the Rational Unified Process | p. 21 |
The Traditional Software Development Process | p. 21 |
Advantages of the Waterfall Process | p. 22 |
Disadvantages of the Waterfall Process | p. 23 |
Introducing the Rational Unified Process | p. 26 |
History | p. 27 |
The Six Best Practices | p. 28 |
RUP Lifecycle Phases | p. 36 |
Is the RUP Agile? | p. 40 |
Summary | p. 41 |
What's Next? | p. 41 |
Chapter 3 Getting Started: Request for Proposals (RFPs), Proposals, and Contracts | p. 43 |
How Is Procurement Accomplished for Outsourced Systems? | p. 44 |
The Ten Steps in the Procurement Process | p. 44 |
Advantages of the Procurement Process | p. 47 |
What's Wrong with This Procurement Process? | p. 47 |
How Can Procurement of Software Systems Be Improved? | p. 49 |
A Proposed Progressive Acquisition Model for Small Projects | p. 49 |
A Progressive Acquisition Model for Medium to Large Projects | p. 52 |
Issues with Managing Fixed-Price Projects | p. 55 |
Monitoring Project Performance | p. 56 |
Releases | p. 56 |
Earned Value | p. 56 |
Project Estimation | p. 60 |
Selecting a Contractor Proficient in the RUP | p. 61 |
Lessons Learned for Outsourcing Organizations | p. 62 |
Lessons Learned for Contractors | p. 62 |
Summary | p. 63 |
What's Next? | p. 63 |
Chapter 4 Best Practices for Staffing the Outsourcing Organization's Project Management Office (PMO) | p. 65 |
Key Roles Defined | p. 65 |
The Project Manager | p. 66 |
The Lead User Representative | p. 69 |
The PMO Project Architect | p. 70 |
The Internal Project Champion | p. 73 |
The Contracting Officer | p. 73 |
The IT Manager | p. 74 |
Other Role Issues | p. 75 |
Developing a Data Model | p. 75 |
Developing Common Code | p. 76 |
Summary | p. 76 |
What's Next? | p. 77 |
Chapter 5 Best Practices for Staffing the Contractor's Software Project Team | p. 79 |
Governing Principles for Staffing the Team | p. 80 |
Roles on the Contractor's Software Development Team | p. 81 |
The Project Manager Role | p. 82 |
The Developer Role | p. 85 |
The Architect Role | p. 86 |
The Technical Lead Role | p. 87 |
The Toolsmith Role | p. 87 |
The Requirements Analyst Role | p. 88 |
The Tester Role | p. 89 |
The Configuration Management/QA Role | p. 89 |
Best Practices for Managing Teams | p. 90 |
Summary | p. 91 |
What's Next? | p. 92 |
Chapter 6 Establishing the Software Development Environment | p. 93 |
Build, Buy, or Borrow | p. 93 |
Shareware Tools | p. 93 |
Commercially Available Tools | p. 94 |
Custom "In-House" Tools | p. 95 |
Requirements Management | p. 96 |
Important Features to Look for in a Requirements Management Tool | p. 97 |
Change Request Management | p. 100 |
Features Needed in Change Request Management Tools | p. 100 |
Configuration Management Tools | p. 103 |
Features Needed in Configuration Management Tools | p. 103 |
Considerations for Servers for the Software Development Environment | p. 108 |
Requirements for Servers | p. 108 |
Other Considerations | p. 109 |
Considerations for Client PCs | p. 109 |
Best Practices for Deploying New Tools | p. 109 |
Summary | p. 110 |
What's Next? | p. 111 |
Chapter 7 Inception: Kicking Off the Project | p. 113 |
Purpose and Goals of the Inception Phase | p. 113 |
Artifacts Produced in the Inception Phase | p. 114 |
The Project Business Case | p. 114 |
The Project Vision Statement | p. 114 |
The Project Risk List and Risk Management Plan | p. 115 |
The Project Software Development Environment | p. 115 |
The Project Software Development Plan (SDP) | p. 115 |
The Iteration Plan | p. 116 |
The Development Process | p. 116 |
The Project Glossary | p. 116 |
The Use Case Model | p. 117 |
Optional Artifacts | p. 117 |
Soft Skills | p. 117 |
Setting the Project Vision | p. 117 |
Maintaining Communication on the Project | p. 120 |
Establishing a Project Web Site | p. 121 |
Advantages of Project Web Sites | p. 121 |
Suggestions for Content of Project Web Sites | p. 122 |
Other Best Practices for Project Web Sites | p. 123 |
What Can Go Wrong During the Inception Phase | p. 123 |
Establishing a Sense of Ownership of the Project Plan | p. 124 |
Summary | p. 125 |
What's Next? | p. 125 |
Chapter 8 Identifying and Managing Risks | p. 127 |
Technical Risks | p. 128 |
Managing Technical Risks | p. 128 |
Political Risks | p. 130 |
An Example of Discovering a Political Risk | p. 130 |
Identifying Political Risks | p. 131 |
Funding Risks | p. 131 |
Funding on Government Projects | p. 132 |
Sources of Funding Often Are Not Straightforward | p. 132 |
Business Risks | p. 132 |
Risks Resulting from Dependencies on External Sources | p. 133 |
An Example of Managing Dependency on a Vendor | p. 133 |
Risks from Other Contractors | p. 135 |
Creating a Risk Tracking System | p. 135 |
Characteristics of a Risk Tracking System | p. 135 |
Summary | p. 138 |
What's Next? | p. 138 |
Chapter 9 Navigating the Requirements Management Process | p. 139 |
Identifying Stakeholders | p. 140 |
Enabling Success in Requirements Management | p. 140 |
Attribute 1 The Contractor Has Easy Access to the Proper Set of Stakeholders in the Outsourcing Organization | p. 141 |
Attribute 2 Establishing a Strong Working Relationship with Stakeholders | p. 142 |
Attribute 3 Collecting and Disseminating Information Obtained from Stakeholders | p. 143 |
Considerations for Offshore and Other Long-Distance Projects | p. 146 |
Looking for Communication Opportunities | p. 146 |
Understanding Cultural Differences for Offshore Projects | p. 147 |
Modeling the Business Process | p. 147 |
Definition of Business Modeling | p. 148 |
Use Cases: A Best Practice for Capturing Business Processes and Functional Requirements | p. 149 |
Transitioning to System Use Cases | p. 150 |
When the Requirements Process Goes Wrong | p. 153 |
They Tell You That the Requirements Analysis Is Already Finished | p. 153 |
Lack of Agreement on the Business Process in the Outsourcing Organization | p. 156 |
Avoiding Unbounded Growth in Requirements, or Requirements "Churn" | p. 156 |
Multiple Contractors and "Forgotten" Stakeholders | p. 158 |
Summary | p. 158 |
What's Next? | p. 159 |
Chapter 10 Construction Iterations: Staying on Target | p. 161 |
How Can You Tell if the Project Is Ready for Construction? | p. 161 |
Assessing Project Readiness for Construction: Checklists | p. 162 |
Iteration Planning, Execution, and Assessment | p. 163 |
How Long Should Iterations Be? | p. 163 |
Determining the Content of Iterations | p. 164 |
Construction Phase Iteration Planning | p. 164 |
Assessing the Results of an Iteration | p. 166 |
Demonstrating the Results of an Iteration | p. 167 |
Regrouping After the Demonstration | p. 169 |
Contractual Issues Revisited | p. 169 |
Common Mistakes Implementing Iterative Development in the Construction Phase | p. 170 |
Mistake 1 Plunging into Construction Before the Project Is Ready | p. 170 |
Mistake 2 Iterations of an Inappropriate Length | p. 170 |
Mistake 3 Iterations with No Stated Purpose | p. 170 |
Mistake 4 Getting Derailed by Change Requests | p. 171 |
Mistake 5 Trying to Plan All Iterations in Detail Up Front | p. 171 |
Anecdotal Observations from Development Teams Using Iterative Techniques Versus Waterfall Techniques | p. 171 |
Summary | p. 173 |
What's Next? | p. 173 |
Chapter 11 Testing | p. 175 |
How Traditional Waterfall Lifecycle Models Inhibit Testing | p. 175 |
Testing with Iterative Lifecycle Models | p. 177 |
Advantages of Testing with Iterative Development | p. 178 |
Prerequisites for Testing with Iterative Lifecycle Models | p. 179 |
The Different Types of Testing | p. 182 |
Functional Testing | p. 183 |
Unit Testing | p. 184 |
Reliability Testing | p. 185 |
Performance/Stress Testing | p. 186 |
Other Types of Testing | p. 188 |
Other Best Practices for Testing | p. 188 |
Involve Testing Expertise During Requirements Elicitation | p. 188 |
Keep Testing Staff in the Loop | p. 189 |
Replicate the Production Environment | p. 189 |
Testing Is Part of the Delivered Product | p. 190 |
Final Thoughts and Philosophies on Staffing for the Testing Discipline | p. 190 |
What if a Separate Team, Perhaps Offshore, Performs the Testing? | p. 191 |
Testing Efforts Gone Awry | p. 192 |
Summary | p. 194 |
What's Next? | p. 195 |
Chapter 12 Transitioning a System into Service | p. 197 |
Staffing Considerations in the Transition Phase | p. 197 |
Project Tasks in the Transition Phase | p. 199 |
Deploying the IOC | p. 199 |
Online Help | p. 200 |
Installation Scripts | p. 201 |
Change Requests | p. 201 |
Data Migration | p. 202 |
Training | p. 207 |
Acceptance Testing | p. 208 |
Setting End-User Expectations for Production | p. 209 |
Identifying User Groups to Aid in Production Rollout | p. 210 |
Summary | p. 211 |
What's Next? | p. 212 |
Chapter 13 System Operations and Maintenance Issues | p. 213 |
Procuring Maintenance Services | p. 213 |
Operations Support | p. 213 |
Maintenance Support | p. 219 |
Summary | p. 221 |
What's Next? | p. 221 |
Chapter 14 Using Consultants Effectively | p. 223 |
Staff Augmentation | p. 223 |
Expert Consultants | p. 225 |
Expert Consultants from Vendors | p. 226 |
Expert Process Consultants from Consulting Firms | p. 228 |
Consultant Pricing | p. 233 |
Summary | p. 233 |
What's Next? | p. 234 |
Chapter 15 The Project Postmortem | p. 235 |
Defining the Project Postmortem | p. 235 |
Sources of Information for Lessons Learned | p. 236 |
Why Bother with a Project Postmortem? | p. 237 |
Instilling Lessons Learned into the Organization's Memory | p. 239 |
Project Management Forums | p. 239 |
Examples of Trends from the Configuration Management Discipline | p. 240 |
Defect Trends on Iterative Projects | p. 242 |
Trends in the Requirements Management Discipline | p. 243 |
Collecting the Project Data | p. 245 |
(Mis)Using Metrics Data | p. 245 |
Summary | p. 245 |
Appendix A Common Mistakes Utilizing RUP | p. 247 |
Mistake 1 Iterations of Inappropriate Length | p. 247 |
Mistake 2 Iterations with No Clear Goal | p. 248 |
Mistake 3 Choosing the Wrong Project for Your First Experience with the RUP | p. 249 |
Mistake 4 Failing to Integrate Change Requests into Iterations | p. 250 |
Mistake 5 Failing to Tailor the RUP Appropriately | p. 250 |
Mistake 6 Failing to Test Properly During the Iteration | p. 251 |
Mistake 7 Assuming You Can Implement the RUP Perfectly the First Time | p. 251 |
Appendix B Implementing a Two-Stage Procurement Process | p. 253 |
Cultural Changes Needed | p. 253 |
Contract Types | p. 254 |
Who Bids on the Second Phase? | p. 255 |
What Artifacts Should Be Produced and Made Available During the First Phase? | p. 256 |
Glossary | p. 256 |
Vision Statement | p. 256 |
Software Architecture Document | p. 256 |
Set of Business and System Use Cases | p. 256 |
UML Models | p. 256 |
Set of Supplementary Requirements | p. 256 |
Executables Produced by Iterations | p. 257 |
List of Risks and Risk History | p. 257 |
Other Information | p. 257 |
Summary | p. 257 |
Glossary | p. 259 |
Bibliography | p. 267 |
Index | p. 271 |