The Software project manager’s handbook: Principles that work at work, second edition

The Software Project Manager's Handbook: Principles that Work at Work

Volumn , Issue , 2004, Pages 1-383

  Phillips, Dwayne ^a  

^a NONE

Author keywords

[No Author keywords available]

Indexed keywords

EID: 85041053766     PISSN: None     EISSN: None     Source Type: Book    
DOI: 10.1109/9780471677772     Document Type: Book

References (270)

1. J. Bach, “The Challenge of Good Enough Software”. American Programmer, October 1995, pp. 2-11.
2. T. Buzan, Use Both Sides of Your Brain, 3rd ed., Penguin Books, New York, 1991.
3. The Capability Maturity Model: Guidelines for Improving the Software Process, Carnegie Mellon University/Software Engineering Institute, Addison-Wesley, Reading, MA, 1995.
4. C. Comaford, “What’sWrong with Software Development?" Software Development, November 1995, pp. 27-28.
5. L. Constantine, “Software by Teamwork: Working Smarter,” Software Development, July 1995, pp. 36-45.
6. D. Gause and G. M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, New York, 1989.
7. R. Glass, “In Search of Self-Belief: The ‘BOP’ Phenomenon,” Computer, January 1995, pp.55-57.
8. R. Glass, “Failure is Looking More Like Success These Days,” IEEE Software, January February 2002, p. 102.
9. “Coach YourTeam to Success,” Software Development, July 1994, pp. 36-43.
10. W. Humphrey, Managing theSoftware Process, Addison-Wesley, Reading, MA, 1989.
11. W. Humphrey, A Discipline for Software Engineering, Addison-Wesley, Reading, MA, 1995.
12. J. Johnson, “Creating Chaos,” American Programmer, July 1995, pp. 3-7.
13. C. Jones, “Our Worst Current Development Practices,” IEEE Software, March 1996a, pp. 102-104.
14. C. Jones, Patterns of Software Systems Failure andSuccess, International Thomson Computer Press, Boston, 1996b.
15. S. Maguire, Debugging theDevelopment Process, Microsoft Press, Redmond, WA, 1994.
16. S. McConnell, Code Complete, Microsoft Press, Redmond, Washington, 1993.
17. D. Parnas, “Why Software JewelsAre Rare, Computer, February 1996, pp. 57-60.
18. R. Racko, “Hedging Your Bets: Part 2,” Software Development, August 1995, pp. 73-76.
19. W. Reid, “You Call That A System? Part 2,” American Programmer, August 1995, pp. 25-33.
20. H. Rubin, “World-Class Information Technology Organizations,” IT Metrics Strategies, January 1996, pp. 1-2.
21. O. Sharp, “How to Build Reliable Code,” Byte, December 1995, pp. 50-51.
22. P. Szmyt, “User Centered Development,” Software Development, November 1994, pp. 49-59.
23. R. Thomsett, “Project Pathology: A Study of Project Failures,” American Programmer, July 1995, pp. 8-16.
24. G. M. Weinberg, Quality Software Management: Vol. 3, Congruent Action, Dorset House; New York, 1994.
25. G. M. Weinberg, The SHAPE Forum, www.geraldmweinberg.com. September 1997.
26. N. Wirth, “APlea for LeanSoftware,” Computer, February 1995, pp. 64-68.
27. B. Blum, Software Engineering, A Holistic View, Oxford University Press, New York, 1992.
28. C. Brusaw, G. Alred, and W. Oliu, The Concise Handbook for Technical Writing, 51. Martin’s Press, NewYork, 1996.
29. T. DeMarcoand T. Lister, Peopleware, Dorset House, NewYork, 1987.
30. R. Fairley, Software Engineering Principles, McGraw-Hill, New York, 1985.
31. D. Freedman and G. Weinberg, Handbook of Wal1lthroughs, Evaluations, and Technical Reviews, Dorset House, NewYork, 1990.
32. IEEE Standard, ANSI/IEEE Std 830-1993, IEEE Recommended Practice for Software Requirements Specifications, IEEE Press, Piscataway, NJ, 1993.
33. IEEE Standard, ANSI/IEEE Std 1042-1987, IEEE Guide to Software Configuration Management, (reaffirmed 1993) IEEE Press, Piscataway, Nf, 1993.
34. IEEE Standards Collection, Software Engineering, IEEE Press, Piscataway, Nf, 1997.
35. Industry Implementation of ISO/IEC 12207: 1995-Standard for Information Technology-Software Life CycleProcesses.
36. Industry Implementation of ISO/IEC 12207: 1995-Standard for Information Technology-Software Life CycleProcesses-Life CycleData.
37. Industry Implementation of International Standard ISO/IEC 12207: 1995; Standard for Information Technology-Software Life Cycle Processes-Implementation Considerations.
38. C. Jones, “Function Point Focus,” IT Metrics Strategies, Cutter Information Corp., p. 8, December 1995.
39. J. Mancuso, Mastering Technical Writing, Addison-Wesley, Reading, MA, 1990.
40. Military Standard, Software Development and Documentation, U.S. Department of Defense, Washington, DC, Dec. 1994, http://www.itsLdisa.mil.
41. S. McConell, Code Complete, Microsoft Press, Redmond, WA, 1993.
42. D. Phillips, “Project Management: Fillingin the Caps,” IEEE Software, July 1996a, pp. 17-18.
43. D. Phillips, “Configuration Management: Understanding the Big Picture,” Software Development, December 1998b, pp. 47-53.
44. D. Phillips, “Go Configurel Understanding the principles and promises of configuration management,” STQE, May-June 2002a, pp. 54.
45. R. Pressman, Software Engineering, A Practitioner’s Approach, 4th ed., McGraw-Hill, New York, 1997.
46. P. Strassman, “Strategic Planning and the Three Little Pigs,” American Programmer, March 1996, pp. 2-8.
47. W. Strunk and E. B. White, The Elements of Style, 2nd edition, Macmillan, New York, 1972.
48. E. Tufte, The Visual Display of Quantitative Information, Graphics Press, Chesire cr, 1983.
49. E. Tufte, Envisioning Information, Graphics Press, Chesire. cr, 1990.
50. E. Tufte, Visual Explanations, Graphics Press, Chesire, cr., 1997.
51. G. Weinberg, Quality Software Management: Vol. 1, Systems Thinking, Dorset House Publishing, NewYork, 1992.
52. G. Weinberg, Quality Software Management: Vol. 2, First Order Measurement, Dorset House Publishing, NewYork, 1993.
53. G. Weinberg, Quality Software Management: Vol. 3, Congruent Action, Dorset House, NewYork, 1994.
54. G. Weinberg, Quality Software Management: Vol. 4, Anticipating Change; Dorset House Publishing, NewYork, 1997.
55. E. Weiss, How to Write A Usable User Manual, lSI Press, Philadelphia, 1985.
56. J. Wood and D. Silver, Joint Application Development, 2nd ed., Wiley, NewYork, 1995.
57. R. Zahniser, “LowTech Groupware for Team Success,” Software Development Conference, Miller-Freeman, San Francisco, 1994.
58. D. Phillips, “People, Process, and Product,” American Programmer, January 1995, pp. 15-20.
59. S. Adams, The Dilbert Principle, HarperCollins, New York, 1996.
60. V. Basili and D. Weiss, “A Methodology for Collecting Valid Software Engineering Data,” IEEE Transactions on Software Engineering, November 1984.
61. K. Beck, Extreme Programming Explained: Embrace Change, Pearson Education, Upper Saddle River, NJ, 1999.
62. F. Brooks, lr., The Mythical Man-Month, Addison-Wesley, Reading, MA, 1975.
63. P. Crosby, Quality is Free, Mentor Books, New York, 1980.
64. T. DeMarco and T. Lister, Peoplewate, Dorset House, New York, 1987.
65. Q. Fleming and J. Koppelman, Earned Value Project Management, 2nd ed., Project Management Institute, 2000.
66. T. Gilb and D. Graham, Software Inspection, Addison-Wesley, Reading, MA, 1993.
67. R. Grady, Practical Software Metrics for Project Managenlent and Process Improvement, Prentice-Hall, Englewood Cliffs, NJ, 1992.
68. W. Humphrey, Managing the Softtuare Process, Addison-Wesley, Reading, MA, 1989.
69. W. Humphrey, A Discipline for Software Engineering, Addison-Wesley, Reading, MA, 1995.
70. C. Jones, Patterns of Software Systems Failure and Success, International Thomson Computer Press, Boston, 1996.
71. N. Kerth, Project Retrospectives, A Handbook forTeam Reviews, Dorset House Publishing, New York, 2001.
72. S. Maguire, Debugging the Development Process, Microsoft Press, Redmond, WA, 1994.
73. M. Mah, “Managing Outsourcing Expectations,” Cutter IT Journal, October 1999, pp. 6-16.
74. J. Marciniak and D. Reifer, Softtvare Acquisition Management, Wiley, New York, 1990.
75. J. McCarthy, Dynamics of Software Development, Microsoft Press, Redmond, WA, 1995.
76. S. McConnell, Rapid Development, Microsoft Press, Redmond, WA, 1996.
77. S. McConnell, “Tool Support for Project Tracking,” IEEE Software, September October 1997, pp. 119-120.
78. D. Phillips, “How People Drive the Outsourcing Process Sometimes Off the Road,” Cutter ITJournal, July 1998, pp. 37-42.
79. D. Phillips, “Backto Basics: Metrics that Work for Software Projects,” Cutter ITJournal, April 1999, pp.36-42.
80. L. H. Putnam and W. Myers, Measures for Excellence-Reliable Software on Time, within Budget, Yourdon Press, Englewood Cliffs, NJ, 1992.
81. D. Smith, xxxx Software Program Manager’s Network, The Program Manager’s Guide toSoftware Acquisition Best Practices, Arlington, VA: US Department of Defense Software Acquisition Best Practices Initiative, The Software Program Managers Network, 1996.
82. B. Tackett and B. Van Doren, “Process Control for Error-Free Software: ASoftware Success Story,” IEEE Software, May June 1999, pp. 24-29.
83. R. Thomsett, “Outsourcing: The GreatDebate,” Cutter ITJournal, July 1998, pp. 11-21.
84. G. Weinberg, Becoming a Technical Leader, Dorset House, New York, 1986.
85. G. Weinberg, Quality Software Management: Vol. 1, Systems Thinking, Dorset House, New York, 1992.
86. G. Weinberg, Quality Software Management: Vol. 2, First-Order Measurement, Dorset House, New York, 1993.
87. G. Weinberg, “What’s So Great about Technical Reviews?" STQE, March April 2003, pp. 16-19.
88. S.Ambler, “Using Use-Cases,” Software Development, July 1995, pp. 53-61.
89. B. Blum, Software Engineering, A Holistic View, Oxford University Press, London, 1992.
90. B. Boehm, “The Art of Expectations Management,” Computer, January 2000, pp. 122-124.
91. T. Buzan, Use Both Sides oj Your Brain, 3rd. ed.,’ Penguin Books, New York, 1991.
92. W. Carnes, Effective Meetings for Busy People, IEEE Press, NewYork, 1987.
93. P. Coad, “Working Out Dynamics with Scenarios,” Software Development, October 1995, pp. 38-50.
94. L. Constantine, “Software by Teamwork: Working Smarter,” Software Development, July 1995, pp. 36-45.
95. A. Cooper, “Goal-Directed Software Design,” Dr. Dobb’s I., September 1996, pp. 16-22.
96. A. Davis, “Requirements Engineering,” in Encyclopedia of Software Engineering, J. Marciniak, ed., Wiley, NewYork, 1994, pp. 1043-1054.
97. A. Davis, “The Art of Requirements Triage,” Computer, March 2003, pp. 42-49.
98. E. Derby, “The ROn Method of Managing Meeting Effectiveness, www.stickyminds.com
99. Esther DerbyAssociates, Inc., www.estherderby.corn, xxxx.
100. D. Gause and G. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, NewYork, 1989.
101. T. Gilb, Principles of Software Eng. Management, Addison Wesley, Reading, MA, 1988.
102. T. Cilb, “Level 6: Why We Can’t Get There from Here,” IEEE Software, January 1996, pp.97-98.
103. R. Glass, Facts andFallacies of Software Engineering, Pearson Education, Boston, 2003.
104. E. Cottesdiener, Requirements by Collaboration: Workshops for Defining Needs, Reading, MA, Addison-Wesley, 2002.
105. IEEE, ANSI/IEEE Std 830-1998, in IEEE Recommended Practice forSoftware Requirements Specifications, IEEEPress, NewYork, 1993.
106. M. Jackson, “Critical Reading for Software Developers,” IEEE Software, November 1995, pp. 103-104.
107. S. Kaner, Facilitator’s Guide to Participatory Decision-Making, New Society Publishers, Gabriola Island, BritishColumbia, 1996.
108. N. Karten, Managing Expectations, Dorset House Publishing, New York, New York, 1994.
109. N. Karren, Communication Gaps andHow to Close Them, Dorset House Publishing, New York, NewYork, 2002.
110. S. Maguire, Debugging theDevelopment Process, MicrosoftPress, Redmond, WA, 1994.
111. J. Marciniak (Ed.), Encyclopedia of Software Engineering, Wiley, NewYork, 1994.
112. S. Robertson and J. Robertson, Mastering the Requirements Process, Addison-Wesley, London, 1999.
113. G. Rush, MGRush Systems, Inc., www.mgrush.com, xxxx.
114. P. Schenck, Identifying and Confirming User Requirements, LearningTree International, Reston, VA, 1994.
115. J. Sharp, “ValidatingSoftware Requirements,” Crosstalk, November 1999, pp. 25-30.
116. S. Smith, www.stevenmsmith.com.xxxx.
117. G. Weinberg, Quality Software Management: Vol. 1: Systems Thinking, Dorset House Publishing, NewYork, 1992.
118. G. Weinberg, Quality Software Management: Vol. 2: First- Order Measurement, Dorset House, NewYork, 1993.
119. K. Wiegers, “Customer Rights and Responsibilities,” Software Development, December 1999, pp. 34-37.
120. N. Wilkinson, Using CRC Cards, ACM Press, NewYork, 1995.
121. J.Wood and D. Silver, Joint Application Development, 2nd edition, John Wiley&Sons, NewYork, 1995.
122. R. Zahniser, “Design By Walking Around,” Communications of the ACM, October 1993a, pp.114-123.
123. R. Zahniser, “SSf: System Storyboarding Techniques,” American Programmer, September 1993b, pp.9-14.
124. R. ZuItner, “Blitz QFD: Better, Faster, Cheaper Forms of QFD” American Programmer, October 1994, pp. 24-30.
125. S. Bayer and J. Highsmith, “RADical Software Development,” American Programmer, June, 1994, pp. 35-42.
126. K. Beck, Extreme Programming Explain: Embrace Change, Addison- Wesley, Reading, MA, 2000.
127. B. Boehm, " ASpiral Model for Software Development and Enhancement,” Computer, May 1988, pp. 61-72.
128. B. Boehm, “Anchoring the Software Process,” IEEE Software, July 1996, pp. 73-82.
129. N. Brown, “Industrial-Strength Management Strategies,” IEEE Software, July 1996, pp. 94-103.
130. N. Brown, “High-Leverage Best Practices: What Hot Companies are Doing to Stay Ahead,” Crosstalk, September 1999, pp. 4-9.
131. R. Charette, “Risk Management,” in Encyclopedia of Software Engineering, J. Marciniak, ed., Wiley, New York, 1994, pp. 1091-1106.
132. CMMI, Capability Maturity Model Integration (CMMI SM), Version 1. 1, CMMI SM for Systems Engineering and Software Engineering, (CMMI-SE/SW, VI.1), Staged Representation, CMU/SEI-2002-TR-002, ESC-TR-2002-002, December 2001a.
133. CMMI, Capability Maturity Modellnregration (CMMI SM), Version 1. 1, CMMI 8M for Systems Engineering and Software Engineering, (CMMI-SE/SW, VI. 1), Continuous Representation, CMU/SEI-2002-TR-001, ESC-TR-2002-001, December 2001b.
134. CMU/SEI, The Capability Maturity Model, Guidelines for Improving the Software Process, Carnegie Mellon University-Software Engineering Institute, Addison-Wesley, Reading, MA, 1995; http://www.sei.cmu.edu.
135. A. Cockburn, “Selecting a Project’s Methodology,” IEEE Software, July August 2000, pp.64-71.
136. B. Curtis, “Building Accelerated Organizations,” IEEE Software, July August 2000, pp. 72-74.
137. M. Cusumano, D. Yoffie, “Software Development on Internet Time, " Computer, October 1999, pp.60-69.
138. E. Derby and J. Rothman, “Manager, Heal Thyself: Improving Software Processes Means Changing Management Processes,” Cutter IT Journal, October 2001, pp. 24-34.
139. DOD-STD-2167A, Military Standard, Defense System Software Development, U.S. Department of Defense, 29 Feb. 1988, Commander, Space and Naval Warfare Systems Command, ATfN: SPAWAR-3212, Washington, D.C., 20363-5100.
140. D. Emery, “Resistance As a Resource,” Cutter IT Journal, October 2001, pp. 35-43.
141. R. Fairley, " Making Accurate Estimates,” IEEE Software, November December 2002, pp.61-63.
142. R. Glass, " Search of Self-Belief: The ‘BOP’ Phenomenon,” Computer, January 1995, pp.55-57.
143. R. Glass, Facts andFallacies of Software Engineering, Pearson Education, Boston, 2003.
144. R. Grady, Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Englewood Cliffs, NJ, 1992.
145. J. Hale, A. Parrish, and B. Dixon, “Enhancing the COCOMO Estimation Models,” IEEE Software, November December 2000, pp. 45-49.
146. D. Henry, “Software Estimation: Perfect Practices Makes Perfect,” Crosstalk, June 2002, pp.28-30.
147. W. Humphrey, Managing theSoftware Process, Addison-Wesley, Reading, MA, 1989.
148. W. Humphrey, A Discipline forSoftware Eng., Addison-Wesley, Reading, MA, 1995.
149. W. Humphrey, Introduction totheTeam Software Process, Addison-Wesley, Reading, MA, 2000.
150. IEEE, IEEE Standard, ANSI/IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans, IEEE Press, New York, 1998.
151. IEEE/EIA, Industry Implementation of ISO/IEC 12207: 1995-Standard for Information Technology-Software Life Cycle Processes.
152. IEEE/EIA, Industry Implementation of ISO/IEC 12207: 1995-Standard for Information Technology-Software Life Cycle Processes-Life Cycle Data.
153. JEEE/EIA, Industry Implementation of International Standard ISO/IEC 12207: 1995; Standard for Information Technology-Software Life Cycle Processes-Implementation Considerations.
154. ISO/IEC, Software Life Cycle Processes, 1 August 1995; available through the American National Standards Institute, New York, www.ansLorg.
155. C. Jones, Patterns of Software Systems Failure andSuccess, International Thomson Computer Press, Boston, 1996.
156. C. Jones, “Software Project Management in the 21st Century,” American Programmer, February 1998, pp. 24-30.
157. W. Keuffel, “People Based Processes: ARADical Concept,” Software Development, 1995, pp.27-30.
158. L. Leach, Critical Chain Project Management, Anech House, Norwood, MA, 2000.
159. “Manlfesto for Agile Software Development,” www.agilemanifesto.org. February 2001.
160. J. McCarthy, Dynamics of Software Development, Microsoft Press, Redmond, WA, 1995.
161. S. McConnell, “Sitting on the Suitcase,” IEEE Software, May June 2000, pp. 5-7.
162. MIL-SID-498, Military Standard, Software Development and Documentation, U.S. Department of Defense, 5 Dec. 1994; http://www.itsi.disa.mil.
163. P. Neuhardt, “Medicine for the Estimation Flu,” American Programmer, June 1996, pp. 36-41.
164. R. Park, " A Manager’s Checklist for Validating Software Cost and Schedule Estimates, " American Programmer, June 1996a, pp. 30-35.
165. R. Park, “Assessing an Organization’s Estimating Capabilities,” American Programmer, July 1999b, pp. 42-49.
166. D. Parnas, “Why Software Jewelsare Rare,” Computer, February 1996, pp. 57-60.
167. M. Paulk, “ExtremeProgramming from a CMMPerspective,” IEEE Software, November December 2001, pp. 19-26.
168. D. Phillips, “Cards-on-the-Wall Sessions,” Software Development, July 2001, pp. 53-56.
169. D. Phillips, “Project Planning: It’s in the Cards,” STQE, January-February 2002, pp. 26-31.
170. M. Poppendieck and T. Poppendieck, Lean Software Development: An Agile Toolkit, Addison-Wesley, Reading, MA, 2003.
171. L. Putnam and W. Myers, Measures for Excellence: Reliable Software On Time, Within Budget,” Yourdon Press, Englewood Cliffs, NJ, 1992.
172. L. Putnam and W. Myers, Controlling Software Devetopmeni, Executive Briefing, IEEE CS Press, LosAlamitos, CA, 1996.
173. L. Putnam and W. Myers, Industrial Strength Sofuoare: Effective Management Using Measurement, IEEE CSPress, LosAlamitos, CA, 1997.
174. R. Rossand B. Boehm, Theory W Software Project Management Principles and Examples” EEE Transactions onSoftware Engineering, July 1989.
175. W. Royce, “Software Management Renaissance,” IEEE Software, July August 2000, pp. 116-121.
176. K. Schwaber, “Againsta Sea of Troubles: Serum Software Development,” Cutter ITJournal, November 2000, pp. 34-39.
177. K. Schwaber and M. Beedle, Agile Software Development with SCRUM, Pearson Education, Upper Saddle River, NJ, 2001.
178. SEI-93-TR-024, M. Paulk et al., Capability Maturity Model forSoftware, Version 1.1, Software Engineering Institute, Pittsburgh, PA, 1993a.
179. SEI-93-TR-025, M. Paulk et al., Key Practices of the Capability Maturity Model, Version 1.1, Software Engineering Institute, Pittsburgh, PA, 1993b.
180. R. Sherman, “Shipping the Right Products at the Right Time,” American Programmer, February 1995, pp. 15-21.
181. B. Sigal, Software Project Management Tools andTechniques, LearningTree International, Reston, VA, 1993.
182. R. Thayer and R. Fairley, “Project Management,” in Encyclopedia of Software Engineering, J. Marciniak (ed.), Wiley, NewYork, 1994, pp. 900-923.
183. R. Thomsett, “Project Pathology: A Study of Project Failures,” American Programmer, July 1995, pp. 8-16.
184. G. Weinberg, Quality Software Management: Vol. 2 First Order Measurement, Dorset House Publishing, New York, 1993.
185. E. Yourdon, Decline and Fall of the American Programmer, Yourdon Press, Englewood Cliffs, NJ, 1992.
186. E. Yourdon, Rise and Resurrection of the Anlerican Programmer, Prentice-Hall, Englewood Cliffs, NI, 1996.
187. R. Zultner, “Project Estimation with Critical Chain: Third-Generation Risk Management”, Cutter ITJournal, July 1999, pp. 4-12.
188. B. Boehm, Software Risk Management, IEEE CSPress, Los Alamitos, CA, 1989.
189. B.Boehm, “Software Risk Management: Principles and Practices,” IEEE Software, January 1991, pp. 32-41.
190. R. Charette, “Risk Management,” in Encyclopedia of Software Engineering, J. Marciniak, ed., Wiley, NewYork, 1994, pp. 1091-1106.
191. E. Derby, “Risky Beginnings,” Software Testing and Quality Engineering, November December 2000, pp. 50-54.
192. D. Estes, “Year 2000 Testing: A Radical Perspective” Cutter IT Journal, February 1999, pp. 13-21.
193. A. Gemmer, “Risk Management: Moving Beyond Process,” Computer, May 1997, pp. 33-43.
194. [Hall 2003] P. Hall, “Knowing the Odds,” STQE, MarchApril 2003, pp. 35-40.
195. IEEE, IEEE Standard, ANSI/IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans, IEEE Press, NewYork, 1998.
196. T. Lister, “Risk Management is Project Management for Adults,” IEEE Software, May June 1997, pp. 20-22.
197. J. Marciniak(ed.), Encyclopedia Software Engineering, Wiley, NewYork, 1994.
198. L. Putnam and W. Myers, Measures for Excellence: Reliable Software On Time, Within Budget,” Yourdon Press, Englewood Cliffs, NI, 1992.
199. L. Putnam and W. Myers, Controlling Software Development, Executive Briefing, IEEE CSPress, LosAlamitos, CA, 1996.
200. L. Putnam and W. Myers, Industrial Strength Software: Effective Management Using Measurement, IEEE CSPress, Los Alamitos, CA, 1997.
201. L. Russel, “I Wish I’d Knownthat from the Start: Scenario Planning for ProjectManagement,” Cutter IT Journal, May 1999, pp. 13-17.
202. G. Weinberg, “lust SayNo! Improving the Requirements Process,” American Programmer, October 1995, pp. 19-23.
203. R. Zahniser, “TimeBoxing,” Software Development, March 1995, pp. 34-38.
204. L.Alford, “Supporting Commercial Software,” Crosstalk, September 2000, pp. 13-16.
205. S. Ambler, “Debunking Modeling Myths, Software Development, August 2001, pp. 51-53.
206. S.Ambler, “Tools and Evidence,” Software Development, May 2002, pp. 65-66.
207. F. Brooks, Ir., The Mythical Man-Month, Addison-Wesley, Reading, MA, 1975.
208. L. Brownsword, P. Oberndorf and C. Sledge, “An Activity Framework for COTS-Based Systems, " Crosstalk, September 2000, pp. 8-12.
209. Structured Analysis and System Specification, Yourdon Press, Englewood Cliffs, NJ, 1979.
210. R. E. Fairley, Software Engineering Principles, McGraw-Hill, NewYork, 1985.
211. R. G. Fichman and C. F. Kemerer, “ObjectTechnologyand Reuse: Lessons from Early Adopters,” Computer, October 1997, pp. 47-59.
212. M. Fowler, “Design Dead?" Software Development, April 2001, pp. 42-46.
213. E. Gamma et al., Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.
214. T. Gilb, Principles of Software Engineering Management, Addison Wesley, Reading, MA, 1988.
215. J. Herbselb and R. Crinter, " Architectures, Coordination, and Distance: Conway’s Law and Beyond,” IEEE Software, September October 1999, pp. 63-70.
216. D. A. Higgins, Data Structured Software Maintenance, The Warnier-Orr Approach, Dorset House Publishing, New York, 1986.
217. J. Highsmith, " Adaptive Management: Patterns for the E-Business Era, Cutter IT Journal, September 1999, pp. 24-30.
218. IEEE, ANSI/IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions, IEEE Press, New York, 1998.
219. A. Jarvis, V. Crandall, and C. Snow, “Who is to Blame for the Y2Kand Similar Bugs,” Crosstalk, September 1999, pp. 23-27.
220. A. Kolawa, " Automating the Development Process,” Software Development, July 2000, pp.46-48.
221. S. McConnell, Code Complete, Microsoft Press, Redmond, WA, 1993.
222. S. McConnell, “Missing in Action: Information Hiding,” IEEE Software, March 1996, pp.127-128.
223. D. Parnas, “WhySoftware Jewels are Rare,” Computer, February 1996, pp. 57-60.
224. D. Phillips, “Information Hiding in C via Modular Programming,” The C/C++ Users Journal, January 1998, pp. 57-60.
225. W. Tracz, “Architectural Issues, Other Lessons Learned in Component-Based Software Development,” Crosstalk, January 2000, pp. 4-7.
226. J. Voas, “EOTS Software: The Economical Choice?" IEEE Software, March April 1998, pp. 16-19.
227. E. Yourdon, Modem Structured Analysis, Yourdon Press, Englewood Cliffs, NJ, 1989.
228. R. Zahniser, “Design ByWalking Around,” Communications of theACM, October 1993, pp. 114-123.
229. K. Beck, Extreme Programming Explained: Embrace Change, Pearson Education, Upper Saddle River, NJ, 1999.
230. K. Beck, “Testing in XP,” Cutter ITJournal August 2002, pp. 24-26.
231. J. Bedunah, “Introducing Test-Driven Development,” STQE, January February 2002, pp.16-17.
232. B. Beizer, Black-Box Testing: Techniques for Functional Testing of Software andSystems, Wiley, New York, 1995.
233. P. Conklin, “Enrollment Management: Managing the Alpha AXP Program,” IEEE Software, July 1996, pp. 53-64
234. M. Dedolph, “Why Testers Should Participate in Early Reviews,” STQE, March April 2001, pp. 79-80.
235. T. Gilb and D. Graham, Software Inspection, Addison-Wesley, Reading, MA, 1993.
236. R. Glass, “A Satisficing Approach to Software Testing in a Many-Flawed World,” Cutter IT Journal, July 2002, pp. 13-17.
237. R. Goldsmith, “Plan Your Testing, " Software Development, April 1999, pp. 35-39.
238. B. Hetzel, The Complete Guide to Software Testing, QED Information Sciences, Wellesley, MA, 1988.
239. W. Humphrey, A Discipline for Software Engineering, Addison-Wesley, Reading, Mass., 1995.
240. IEEE, ANSI/IEEE Std 829-1998, IEEE Standard for Software Test Documentation, IEEE Press, Piscataway, NI, 1998.
241. C. Kaner, Testing Computer Software, Van Nostrand Reinhold, NewYork, 1993.
242. J. McCarthy, Dynamics a/Software Development, MicrosoftPress, Redmond, WA, 1995.
243. S. McConnell, Rapid Development, MicrosoftPress, Redmond, WA, 1996.
244. J. McGregor, M. Major, “Selecting Test Cases Basedon User Priorities,” Software Development, March 2000, pp. 26-31.
245. G. Myers, The Artof Software Testing, Wiley, NewYork, 1979.
246. D. Phillips, “A People-Satisfying IDEA,” Cutter IT Journal, July 2002, pp. 26-30.
247. J. Poore and C. Trammel, “Bringing Respect to Testing Through Statistical Science,” American Programmer, August 1997, pp. 15-22.
248. J. Rothman, “No More Whining,” Software Testing andQuality Engineering, September October 2000, pp. 79-80.
249. S. Sherer, “Consider the Consequences: Risk-Based Testing Strategies,” Cutter IT Journal. pp. 12-16, August, 2002.
250. J. Voas, “Will the Real Operational Profile Please Stand Up?" IEEE Software, March April 2000a, pp. 87-89.
251. J. Voas, “Developing a Usage-Based Software Certification Process, Computer, August 2000b, pp. 32-27.
252. G. Weinberg, “lust Say No Improving the Requirements Process,” American Programmer, Oct. 1995,-pp. 19-23.
253. G. Weinberg, “PlayingQuality Chicken,” STQE, January February 2002, pp. 55-56.
254. J. Whittaker, “What is SoftwareTesting and Why is it so Hard?" IEEE Software, January February 2000, pp. 70-79.
255. B. Blum, Software Engineering, A Holistic View, Oxford University Press, Oxford, 1992.
256. E. Fairley, Software Engineering Principles, McGraw-Hili, NewYork, 1985.
257. R. Glass, “Maintenance: Less is not More,” IEEE Software, JulyAugust 1998, pp. 67-68.
258. A. Hunt, “Software Archaeology,” IEEE Software, MarchApril 2002, pp. 20-22.
259. IEEE, IEEE Std 1219-1998, IEEE Standard for Software Maintenance, IEEE CS Press, Los Alamitos, CA, 1998.
260. M. Lerner, “Software Maintenance Crisis Resolution: The New IEEE Standard,” Software Development, Aug. 1993, pp. 65-72.
261. S. McConnell, “Annualized Software Delivery,” IEEE Software, January February 2000, pp.103-104.
262. V. Rajlich and K. Bennet, " A Staged Model for the Software Life Cycle, " Computer, July 2000, pp. 66-71.
263. V. Rajlich, “Incremental Redocumentation Using the Web,” IEEE Software, September October 2000, pp. 102-106.
264. R. Thomsett, “The Year 2000 bug: A Forgotten Lesson,” IEEE Software, July August 1998, pp. 91-95.
265. G. Weinberg, Quality Software Management: Vol. 1, Systems Thinking, Dorset House, NewYork, 1992.
266. B. Boehm, " ASpiralModel for Software Development and Enhancement,” Computer, May 1988, pp, 61-71.
267. R. Miller, The Online Rules ofSuccessful Companies: The Fool-Proof Guide to Building Profits, PearsonEducation, Upper Saddle River, NJ, 2002.
268. R. Panko, “What We Know About Spreadsheet Errors,” Journal of End User Computing, Spring 1998, pp. 15-21.
269. G. Weinberg, A Privatediscussion In June 2003, www.geraldmweinberg.com.
270. E.Weiss, How to Write AUsable User Manual, lSI Press, Philadelphia, 1985.