logging in or signing up Value of Org RWG Arkwright26 Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 237 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: June 19, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Slide1: Dr. Ralph R. Young Director, Systems and Software Process Engineering Litton PRC young_ralph@prc.com Third International Conference on Practical Software Quality Techniques (PSQT ‘98) October, 1998 Slide2: Briefing Agenda Background: Software at PRC Key Elements of the PRC SPI Program PRC Requirements Working Group (RWG) Formation Goals, Strategies, and Early Activities Evolving Role of the RWG PRC Requirements (RE) Process Deployment/Implementation/Institutionalization FY98 RWG Mission andamp; Goals The Value of an Organizational Working Group Lessons Learned Slide3: Background: Software at PRC Customers and Primary Markets: Criminal Justice, Defense, Document Management, Education, Electronic Commerce, Command and Control, Health, Intelligence, Legacy Systems, Transportation, and Weather Staff: 2889 computer/engineering, approx. 5500 total Core competencies: Systems Integration, System/Software Engineering, Complex Document Imaging, Computer Aided Dispatch, Enterprise Implementation, SETA Support and Life Cycle Support Slide4: Management Guidance – 'Software Processes shall be: Defined ...Documented ...Trained ...Implemented ...Measured ...Refined.' Mission: To reduce the life-cycle costs of PRC software development, while increasing software quality and programmer productivity SPI Mission and Vision Slide5: Challenge! Diversity of Software Engineering Activities vs. Need for Repeatable, Defined Processes Slide6: Key Elements of the PRC SPI Program Industry Standard Models Institutionalized TQM Method Organizational EPG Infrastructure Continuous Investment in SPI since 1993 SEI Level 3 Maturity Rating Strong Management Commitment Slide7: The Capability Maturity Model (CMM) Provides a Standard Slide8: Quality Improvement Provides a Method QI Teams follow the 7-step problem solving process called the QI Story QIDW incorporates Process Management - Statistical Process Control These principles support the necessary cultural change Plan-Do-Check-Act Management By Fact Customer Satisfaction Respect for People P-D-C-A Priority Management QI Quality Teams Quality In Daily Work Slide9: Organization and Infrastructure for SPI PRC QMB PRC EPG Technology EPG Sector EPGs At-Large Membership QITs Systems Services IIS Phoenix I, II, III, N Working Group Leaders Metrics, RWG, others Core Competency Representation SW, PM Site/Dept/Project EPGs Full-Time Staff Support Project Representation Slide10: PRC’s SPI Investment Approximately $1 million per year since 1993 Full-time SEPG support for process definition, etc. Phoenix teams, Metrics Lead team, working groups (e.g., RWG) SEPG Infrastructure (Systems) Development, acquisition, and support of SPI tools (including the Web-based Process Asset Library [PAL]) SPI training development, seminars and symposia, handbooks, and assessments $470 per software engineer vs. industry median at $1375 (per SEI) Requirements Working Group (RWG) Formation: Requirements Working Group (RWG) Formation A Requirements Management (RM) Process was defined in 1994 Compliant with the CMM for Software (SW-CMM) PRC desired to have its process reflect a full life cycle approach and be compliant with the Systems Engineering CMM (SE-CMM) PRC Systems Engineering Lead Team (SELT) evolving SE Maturity The organizational culture suggested use of a QI Team composed of project requirements engineers to update the RM Process Lead Team Authority: PRC EPG Team Leader: a PRC Process Engineer and member of the SELT First meeting: March, 1997 RWG Goals and Strategy: RWG Goals and Strategy Initial Objective: Update the RM Process Strategy: RWG membership open to anyone who wanted to participate Participation from known project requirements engineers was encouraged Participants provide the guidance; Team Leader does the legwork Meetings held weekly Lunchtime 'Brown Bags' (i.e., an overhead charge number was not provided) Utilize actual project experience to improve the process RWG Goals and Strategy(continued): Goal: Satisfy SE-CMM requirements for: PA06 Understand Customer Needs and Expectations PA02 Derive and Allocate Requirements Project focus Provide an updated process by end of FY97 (7/31/97) to support SELT FY97 objectives RWG members available to assist other projects RWG Goals and Strategy (continued) RWG: Initial Activities: RWG: Initial Activities High level of interest on the part of several project requirements engineers: wanted to lend their experience and expertise to improve PRC’s process Good participation in weekly meetings Individual participation varied depending upon project priorities Team Leader provided: Familiarization with the existing RM Process Familiarization with SE-CMM PA06 and PA02 requirements Copies of articles reflecting industry best practices Agendas, motivation, e-mail reminders of meetings, encouragement, nagging, coordination with PRC EPG, SELT, PM EPG, Sector EPGs Maintaining Momentum: Maintaining Momentum Because of a high level of project responsibilities, some RWG participants experienced conflicts in making time for RWG Meetings. Solution: drive on with whoever can make the meeting -- keep going! Team Leader: Stressed the importance of the RWG effort to PRC’s business objectives Emphasized an awareness of the importance of requirements to project success (based on a review of industry literature) Worked between meetings to develop RWG products Kept PRC EPG infrastructure aware of RWG efforts and products Arranged for formal recognition of RWG members The RWG effort helped evolve our KPA/PA 'Process Owner Responsibilities' Evolving Role of the RWG: Evolving Role of the RWG Recommended an updated (and expanded) PRC Policy concerning requirements Process and other artifacts/assets Maintained the Web pages for the RM KPA Created Web pages for the related SE-CMM PAs Recommended methods for each part of the process Invited vendors to provide demos, resulting in suggested tools Suggested metrics (quality indicators for the products; process indicators for the processes) Collaboration with the SEI’s 'Transistion Packages Initiative:' Provided PRC artifacts to the SEI for links on its Web site Joint meetings to help the SEI develop a prototype Evolving Role of the RWG(continued): Developed training materials for the 'PRC Requirements Course' (10 hours) Provided tailoring guidance Comparison of the old process with the new Draft template for a Project Requirements Policy Identify industry best practices and best of breed methods Acronyms References Proposal support materials Web-based transition package at PRC including all of the above, plus links to project deployments of the 'PRC RE Process' (currently 8 project links are active) Evolving Role of the RWG (continued) The PRC Requirements Process: The PRC Requirements Process Defined in a process flow chart and a Process Description (a completed or filled-in DID) for: Macro: REOOO PRC Requirements (RE) Process Full life cycle requirements activities Micros: RE100 Assess new/changed requirements and control changes RE200 Understand customer needs and expectations (PA06) RE300 Derive and allocate requirements (PA01) With lots of attention to: Who are the customers of this process? What are their 'Customer Valid Requirements?' Mechanisms to facilitate effective implementation Narrative to describe the purpose, intent, entrance criteria, inputs, outputs, exit criteria, responsibilities, tasks Key (Essential) Products for Definition of a PRC Process: Key (Essential) Products for Definition of a PRC Process Organizational policy Process (flow chart) Process description (narrative per DID) Recommended methods Suggested tools Tailoring guidance Training Consideration of Tools: Consideration of Tools Our experience is that development of a process is facilitated by implementation of an effective automated tool. Provide formal vendor training so that the tool can be used effectively Facilitate relationships with vendors so that brown bags, demos, and evaluation copies are provided as needed Deployment/Implementation/Institutionalization: Deployment/Implementation/Institutionalization Work with Proposal Managers, Project Managers, and engineers to encourage use of the process (deployment) Consider a Web-based corporate process asset library with links to project instantiations (and peer pressure!) Proposals are a great place to start! Brief the Process Improvement (PI) infrastructure concerning the availability of artifacts Members of the RWG can lend their experiences to assist and advise concerning implementation Capture success stories (where the process and the tool have helped a project) and publicize Advocates and sponsors are very helpful in achieving institutionalization Gaining Buy-in: Gaining Buy-in How many times we have learned: Involve early those we need to make it happen! Identify management advocates and supporters and enlist their help Utilize RWG members to help educate and inform Results: Results Artifacts are available on the Web Process has been used on 8 projects to date Achieving repeatable processes Saves time and money Gets the job done in an improved manner Allows continuous improvement (feedback from projects to further strengthen and improve the process) Engineers familiar when they move to new projects Increase in use of automated requirements tools (4 projects) RWG desires to further facilitate PRC business objectives FY98 RWG: Mission and Objectives: FY98 RWG: Mission and Objectives Mission: To lead efforts to institutionalize the PRC Requirements Process. Objectives: 1. Encourage deployment and implementation of the PRC RE Process, and achieve active participation and use of the process by PRC Projects. 2. Maintain involvement and feedback from projects using the RE Process. 3. Determine a way to measure the benefits of using the process. 4. Provide an explanatory document describing the benefits of using the process. 5. Update the process based on inputs, suggestions, and project tailoring (continuous improvement). 6. Provide the capability for proposals to utilize/propose the process (provide sample write-ups, presentation slides, etc.). FY98 RWG: Mission and Objectives: Objectives (continued): 7. Prepare a 'Work Plan' to facilitate project use of the Requirements Process artifacts, in particular, to help projects just starting with how to proceed (what to do first, then next…etc.) and how to utilize the artifacts which are provided in the RE Process Transition Package. 8. Sponsor Brown Bags on methods, tools, and technologies. Consider sponsoring training as needed. 9. Provide instructional sessions concerning methods that are recommended to support the process. 10. Review, study, and make available for PRC exceptional materials from the requirements literature. 11. Participate in learning sessions with industry experts. FY98 RWG: Mission and Objectives The Value of an Organizational Working Group: The Value of an Organizational Working Group Allows the organization to benefit from the experience of its projects and the expertise of key staff members Seeds the organization with persons who share a common body of knowledge and who have come into consensus on key topics Members provide a resource to the remainder of the organization Facilitates use of the developed knowledge and artifacts for use in winning new business (proposals, lead marketing briefings, etc.) Encourages a common way of doing things; supports repeatability and reuse Encourages and facilitates selection of appropriate methods and tools as well as their deployment and implementation Encourages us to measure the effectiveness of the process and the benefits of institutionalization Allows participation in industry leading-edge efforts (transition packages) Slide27: Lessons Learned-Organizational Involvement of Project Personnel and Management is critical Establish an organization-wide approach and infrastructure for process, QI, and customer satisfaction Build a Knowledge-Sharing Environment Maintain and Demonstrate Management Commitment Continuous Improvement Both an act and an attitude An environment of trust and openness Slide28: Lessons Learned-RWG Specific Need for committed, ongoing staff support Maintain momentum Provide acknowledgement and recognition Be proactive in deployment Be available to help/advise/sympathize Benefit from industry experience (read and synthesize) Be persistent Share information learned at conferences Keep the PI infrastructure informed and updated Provide training--on the process and for tools References: References Sommerville, Ian and Sawyer, Pete, Requirements Engineering: A Good Practice Guide. Wiley andamp; Sons, 1997. IEEE Software, March/April 1998, focus on requirements engineering. McCarthy, Jim, Dynamics of Software Development. Microsoft Press, 1995. Kar, Pradip and Bailey, Michelle, 'Characteristics of Good Requirements. INCOSE. Stevens, Richard and Putlock, Gary, 'Improving Requirements Management.' INCOSE INSIGHT, Summer, 1997. Quality Systems andamp; Software Web site http://www.qssinc.com/ has various articles on the subject of requirements. Pressman, Roger S., Software Engineering: A Practitioners Approach (Fourth Edition), McGraw-Hill, 1997. See also the R.S. Pressman andamp; Associates, Inc. Web site http://www.rspa.com/ McConnell, Steve, Software Project Survival Guide. Microsoft Press, 1998. See also his Web site http://www.construx.com/ and another book, Rapid Development: T Wild Software Schedulers. Microsoft Press, 1996. References (continued): References (continued) Gilb, Tom (authoring on Evolutionary Development (EVO), Requirements-Driven Management, and Inspections), Principles of Software Engineering Management. Addison Wesley, 1988. See also http://ourworld.compuserve.com/homepages/KaiGilb/. Rechtin, Eberhardt and Maiev, Mark W., The Art of Systems Architecting. CRC Press, 1997. Grady, Jeffrey O., System Requirements Analysis. McGraw Hill, Inc., 1993. Litton PRC, Phoenix Software Process Improvement Reference Guide (Fourth Edition), April, 1996. Hooks, Ivy, 'Guide for Managing and Writing Requirements.' 1994. Software Engineering Institute (SEI) Capability Maturity Model for Software (SW-CMM), Version 1.1. Carnegie Mellon University, February, 1993. Litton PRC Requirements Process, 1997. Systems Engineering Capability Maturity Model (SE-CMM), Version 1.1. Enterprise Process Improvement Collaboration (EPIC), November, 1995. You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
Value of Org RWG Arkwright26 Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 237 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: June 19, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Slide1: Dr. Ralph R. Young Director, Systems and Software Process Engineering Litton PRC young_ralph@prc.com Third International Conference on Practical Software Quality Techniques (PSQT ‘98) October, 1998 Slide2: Briefing Agenda Background: Software at PRC Key Elements of the PRC SPI Program PRC Requirements Working Group (RWG) Formation Goals, Strategies, and Early Activities Evolving Role of the RWG PRC Requirements (RE) Process Deployment/Implementation/Institutionalization FY98 RWG Mission andamp; Goals The Value of an Organizational Working Group Lessons Learned Slide3: Background: Software at PRC Customers and Primary Markets: Criminal Justice, Defense, Document Management, Education, Electronic Commerce, Command and Control, Health, Intelligence, Legacy Systems, Transportation, and Weather Staff: 2889 computer/engineering, approx. 5500 total Core competencies: Systems Integration, System/Software Engineering, Complex Document Imaging, Computer Aided Dispatch, Enterprise Implementation, SETA Support and Life Cycle Support Slide4: Management Guidance – 'Software Processes shall be: Defined ...Documented ...Trained ...Implemented ...Measured ...Refined.' Mission: To reduce the life-cycle costs of PRC software development, while increasing software quality and programmer productivity SPI Mission and Vision Slide5: Challenge! Diversity of Software Engineering Activities vs. Need for Repeatable, Defined Processes Slide6: Key Elements of the PRC SPI Program Industry Standard Models Institutionalized TQM Method Organizational EPG Infrastructure Continuous Investment in SPI since 1993 SEI Level 3 Maturity Rating Strong Management Commitment Slide7: The Capability Maturity Model (CMM) Provides a Standard Slide8: Quality Improvement Provides a Method QI Teams follow the 7-step problem solving process called the QI Story QIDW incorporates Process Management - Statistical Process Control These principles support the necessary cultural change Plan-Do-Check-Act Management By Fact Customer Satisfaction Respect for People P-D-C-A Priority Management QI Quality Teams Quality In Daily Work Slide9: Organization and Infrastructure for SPI PRC QMB PRC EPG Technology EPG Sector EPGs At-Large Membership QITs Systems Services IIS Phoenix I, II, III, N Working Group Leaders Metrics, RWG, others Core Competency Representation SW, PM Site/Dept/Project EPGs Full-Time Staff Support Project Representation Slide10: PRC’s SPI Investment Approximately $1 million per year since 1993 Full-time SEPG support for process definition, etc. Phoenix teams, Metrics Lead team, working groups (e.g., RWG) SEPG Infrastructure (Systems) Development, acquisition, and support of SPI tools (including the Web-based Process Asset Library [PAL]) SPI training development, seminars and symposia, handbooks, and assessments $470 per software engineer vs. industry median at $1375 (per SEI) Requirements Working Group (RWG) Formation: Requirements Working Group (RWG) Formation A Requirements Management (RM) Process was defined in 1994 Compliant with the CMM for Software (SW-CMM) PRC desired to have its process reflect a full life cycle approach and be compliant with the Systems Engineering CMM (SE-CMM) PRC Systems Engineering Lead Team (SELT) evolving SE Maturity The organizational culture suggested use of a QI Team composed of project requirements engineers to update the RM Process Lead Team Authority: PRC EPG Team Leader: a PRC Process Engineer and member of the SELT First meeting: March, 1997 RWG Goals and Strategy: RWG Goals and Strategy Initial Objective: Update the RM Process Strategy: RWG membership open to anyone who wanted to participate Participation from known project requirements engineers was encouraged Participants provide the guidance; Team Leader does the legwork Meetings held weekly Lunchtime 'Brown Bags' (i.e., an overhead charge number was not provided) Utilize actual project experience to improve the process RWG Goals and Strategy(continued): Goal: Satisfy SE-CMM requirements for: PA06 Understand Customer Needs and Expectations PA02 Derive and Allocate Requirements Project focus Provide an updated process by end of FY97 (7/31/97) to support SELT FY97 objectives RWG members available to assist other projects RWG Goals and Strategy (continued) RWG: Initial Activities: RWG: Initial Activities High level of interest on the part of several project requirements engineers: wanted to lend their experience and expertise to improve PRC’s process Good participation in weekly meetings Individual participation varied depending upon project priorities Team Leader provided: Familiarization with the existing RM Process Familiarization with SE-CMM PA06 and PA02 requirements Copies of articles reflecting industry best practices Agendas, motivation, e-mail reminders of meetings, encouragement, nagging, coordination with PRC EPG, SELT, PM EPG, Sector EPGs Maintaining Momentum: Maintaining Momentum Because of a high level of project responsibilities, some RWG participants experienced conflicts in making time for RWG Meetings. Solution: drive on with whoever can make the meeting -- keep going! Team Leader: Stressed the importance of the RWG effort to PRC’s business objectives Emphasized an awareness of the importance of requirements to project success (based on a review of industry literature) Worked between meetings to develop RWG products Kept PRC EPG infrastructure aware of RWG efforts and products Arranged for formal recognition of RWG members The RWG effort helped evolve our KPA/PA 'Process Owner Responsibilities' Evolving Role of the RWG: Evolving Role of the RWG Recommended an updated (and expanded) PRC Policy concerning requirements Process and other artifacts/assets Maintained the Web pages for the RM KPA Created Web pages for the related SE-CMM PAs Recommended methods for each part of the process Invited vendors to provide demos, resulting in suggested tools Suggested metrics (quality indicators for the products; process indicators for the processes) Collaboration with the SEI’s 'Transistion Packages Initiative:' Provided PRC artifacts to the SEI for links on its Web site Joint meetings to help the SEI develop a prototype Evolving Role of the RWG(continued): Developed training materials for the 'PRC Requirements Course' (10 hours) Provided tailoring guidance Comparison of the old process with the new Draft template for a Project Requirements Policy Identify industry best practices and best of breed methods Acronyms References Proposal support materials Web-based transition package at PRC including all of the above, plus links to project deployments of the 'PRC RE Process' (currently 8 project links are active) Evolving Role of the RWG (continued) The PRC Requirements Process: The PRC Requirements Process Defined in a process flow chart and a Process Description (a completed or filled-in DID) for: Macro: REOOO PRC Requirements (RE) Process Full life cycle requirements activities Micros: RE100 Assess new/changed requirements and control changes RE200 Understand customer needs and expectations (PA06) RE300 Derive and allocate requirements (PA01) With lots of attention to: Who are the customers of this process? What are their 'Customer Valid Requirements?' Mechanisms to facilitate effective implementation Narrative to describe the purpose, intent, entrance criteria, inputs, outputs, exit criteria, responsibilities, tasks Key (Essential) Products for Definition of a PRC Process: Key (Essential) Products for Definition of a PRC Process Organizational policy Process (flow chart) Process description (narrative per DID) Recommended methods Suggested tools Tailoring guidance Training Consideration of Tools: Consideration of Tools Our experience is that development of a process is facilitated by implementation of an effective automated tool. Provide formal vendor training so that the tool can be used effectively Facilitate relationships with vendors so that brown bags, demos, and evaluation copies are provided as needed Deployment/Implementation/Institutionalization: Deployment/Implementation/Institutionalization Work with Proposal Managers, Project Managers, and engineers to encourage use of the process (deployment) Consider a Web-based corporate process asset library with links to project instantiations (and peer pressure!) Proposals are a great place to start! Brief the Process Improvement (PI) infrastructure concerning the availability of artifacts Members of the RWG can lend their experiences to assist and advise concerning implementation Capture success stories (where the process and the tool have helped a project) and publicize Advocates and sponsors are very helpful in achieving institutionalization Gaining Buy-in: Gaining Buy-in How many times we have learned: Involve early those we need to make it happen! Identify management advocates and supporters and enlist their help Utilize RWG members to help educate and inform Results: Results Artifacts are available on the Web Process has been used on 8 projects to date Achieving repeatable processes Saves time and money Gets the job done in an improved manner Allows continuous improvement (feedback from projects to further strengthen and improve the process) Engineers familiar when they move to new projects Increase in use of automated requirements tools (4 projects) RWG desires to further facilitate PRC business objectives FY98 RWG: Mission and Objectives: FY98 RWG: Mission and Objectives Mission: To lead efforts to institutionalize the PRC Requirements Process. Objectives: 1. Encourage deployment and implementation of the PRC RE Process, and achieve active participation and use of the process by PRC Projects. 2. Maintain involvement and feedback from projects using the RE Process. 3. Determine a way to measure the benefits of using the process. 4. Provide an explanatory document describing the benefits of using the process. 5. Update the process based on inputs, suggestions, and project tailoring (continuous improvement). 6. Provide the capability for proposals to utilize/propose the process (provide sample write-ups, presentation slides, etc.). FY98 RWG: Mission and Objectives: Objectives (continued): 7. Prepare a 'Work Plan' to facilitate project use of the Requirements Process artifacts, in particular, to help projects just starting with how to proceed (what to do first, then next…etc.) and how to utilize the artifacts which are provided in the RE Process Transition Package. 8. Sponsor Brown Bags on methods, tools, and technologies. Consider sponsoring training as needed. 9. Provide instructional sessions concerning methods that are recommended to support the process. 10. Review, study, and make available for PRC exceptional materials from the requirements literature. 11. Participate in learning sessions with industry experts. FY98 RWG: Mission and Objectives The Value of an Organizational Working Group: The Value of an Organizational Working Group Allows the organization to benefit from the experience of its projects and the expertise of key staff members Seeds the organization with persons who share a common body of knowledge and who have come into consensus on key topics Members provide a resource to the remainder of the organization Facilitates use of the developed knowledge and artifacts for use in winning new business (proposals, lead marketing briefings, etc.) Encourages a common way of doing things; supports repeatability and reuse Encourages and facilitates selection of appropriate methods and tools as well as their deployment and implementation Encourages us to measure the effectiveness of the process and the benefits of institutionalization Allows participation in industry leading-edge efforts (transition packages) Slide27: Lessons Learned-Organizational Involvement of Project Personnel and Management is critical Establish an organization-wide approach and infrastructure for process, QI, and customer satisfaction Build a Knowledge-Sharing Environment Maintain and Demonstrate Management Commitment Continuous Improvement Both an act and an attitude An environment of trust and openness Slide28: Lessons Learned-RWG Specific Need for committed, ongoing staff support Maintain momentum Provide acknowledgement and recognition Be proactive in deployment Be available to help/advise/sympathize Benefit from industry experience (read and synthesize) Be persistent Share information learned at conferences Keep the PI infrastructure informed and updated Provide training--on the process and for tools References: References Sommerville, Ian and Sawyer, Pete, Requirements Engineering: A Good Practice Guide. Wiley andamp; Sons, 1997. IEEE Software, March/April 1998, focus on requirements engineering. McCarthy, Jim, Dynamics of Software Development. Microsoft Press, 1995. Kar, Pradip and Bailey, Michelle, 'Characteristics of Good Requirements. INCOSE. Stevens, Richard and Putlock, Gary, 'Improving Requirements Management.' INCOSE INSIGHT, Summer, 1997. Quality Systems andamp; Software Web site http://www.qssinc.com/ has various articles on the subject of requirements. Pressman, Roger S., Software Engineering: A Practitioners Approach (Fourth Edition), McGraw-Hill, 1997. See also the R.S. Pressman andamp; Associates, Inc. Web site http://www.rspa.com/ McConnell, Steve, Software Project Survival Guide. Microsoft Press, 1998. See also his Web site http://www.construx.com/ and another book, Rapid Development: T Wild Software Schedulers. Microsoft Press, 1996. References (continued): References (continued) Gilb, Tom (authoring on Evolutionary Development (EVO), Requirements-Driven Management, and Inspections), Principles of Software Engineering Management. Addison Wesley, 1988. See also http://ourworld.compuserve.com/homepages/KaiGilb/. Rechtin, Eberhardt and Maiev, Mark W., The Art of Systems Architecting. CRC Press, 1997. Grady, Jeffrey O., System Requirements Analysis. McGraw Hill, Inc., 1993. Litton PRC, Phoenix Software Process Improvement Reference Guide (Fourth Edition), April, 1996. Hooks, Ivy, 'Guide for Managing and Writing Requirements.' 1994. Software Engineering Institute (SEI) Capability Maturity Model for Software (SW-CMM), Version 1.1. Carnegie Mellon University, February, 1993. Litton PRC Requirements Process, 1997. Systems Engineering Capability Maturity Model (SE-CMM), Version 1.1. Enterprise Process Improvement Collaboration (EPIC), November, 1995.