Applied software project management
""If you're looking for solid, easy-to-follow advice on estimation, requirements gathering, managing change, and more, you can stop now: this is the book for you.""--Scott Berkun, Author of The Art of Project Management What makes software projects succeed? It takes more t...
| Autor principal: | |
|---|---|
| Otros Autores: | |
| Formato: | Libro electrónico |
| Idioma: | Inglés |
| Publicado: |
Sebastopol, California :
O'Reilly
2005.
|
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009627149506719 |
Tabla de Contenidos:
- Applied Software Project Management; Praise for Applied Software Project Management; Preface; Who Should Read This Book; Comments and Questions; Safari Enabled; Acknowledgments; 1. Introduction; 1.2. Trust Your Team; 1.3. Review Everything, Test Everything; 1.4. All Software Engineers Are Created Equal; 1.5. Doing the Project Right Is Most Efficient; 1.6. Part I: Tools and Techniques; 1.7. Part II: Using Project Management Effectively; I. Tools and Techniques; 2.1.2. Talk to the Main Stakeholder; 2.1.3. Write the Vision and Scope Document; 2.2. Create the Project Plan; 2.2.2. Resource List
- 2.2.3. Estimates and Project Schedule2.2.4. Risk Plan; 2.2.4.2. Estimate the impact of each risk; 2.2.4.3. Make a mitigation plan; 2.2.5. Project Plan Inspection Checklist; 2.3. Diagnosing Project Planning Problems; 2.3.2. The Mid-Course Correction; 2.3.3. The Detached Engineering Team; 3. Estimation; 3.1.2. Distrust Can Undermine Estimates; 3.2. Wideband Delphi Estimation; 3.2.1.2. Kickoff meeting; 3.2.1.3. Individual preparation; 3.2.1.4. Estimation session; 3.2.1.5. Assemble tasks; 3.2.1.6. Review results; 3.3. Other Estimation Techniques; 3.3.2. COCOMO II; 3.3.3. The Planning Game
- 3.4. Diagnosing Estimation Problems3.4.2. Self-Fulfilling Prophecy; 4. Project Schedules; 4.1.2. Identify Dependencies; 4.1.3. Create the Schedule; 4.1.4. Reconcile the Schedule with the Organization&s Needs; 4.1.5. Add Review Meetings to the Schedule; 4.1.6. Optimize the Schedule; 4.1.7. Don&t Abuse Buffers; 4.1.8. Track the Performance of the Project; 4.2. Managing Multiple Projects; 4.2.2. Prioritize Projects Realistically; 4.3. Use the Schedule to Manage Commitments; 4.4. Diagnosing Scheduling Problems; 4.4.2. Misunderstood Predecessors; 5. Reviews; 5.1.2. Select a Moderator
- 5.1.3. Inspect the Work Product5.1.4. Manage the Author&s Expectations; 5.1.5. Help Others in the Organization Accept Inspections; 5.1.5.2. ""I don&t like people criticizing my work.""; 5.1.5.3. ""I built it, and only I can say when it&s done.""; 5.2. Deskchecks; 5.3. Walkthroughs; 5.4. Code Reviews; 5.4.2. Hold the Review Session; 5.4.3. Code Review Checklist; 5.5. Pair Programming; 5.6. Use Inspections to Manage Commitments; 5.7. Diagnosing Review Problems; 5.7.2. Big, Useless Meetings; 5.7.3. The Indispensable ""Hero""; 6. Software Requirements; 6.1.2. Observe Users at Work
- 6.1.3. Use a Discussion Summary6.2. Use Cases; 6.2.2. Preconditions and Postconditions; 6.2.3. Basic Course of Events; 6.2.4. Alternative Paths; 6.2.5. Develop Use Cases Iteratively; 6.3. Software Requirements Specification; 6.3.1.2. Nonfunctional requirements; 6.3.2. Develop the SRS Iteratively; 6.3.3. Requirements Differ from Design; 6.3.4. SRS Inspection Checklist; 6.4. Change Control; 6.4.2. Change Control Process; 6.4.3. Evaluate Changes in the CCB Meeting; 6.4.4. Analyze the Impact of Each Change; 6.5. Introduce Software Requirements Carefully; 6.5.2. Speak the Managers& Language
- 6.6. Diagnosing Software Requirements Problems
