Dr Ralph R Young Director Systems and Software

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 l l 1 pp

Briefing Agenda n n PRC Requirements Working Group (RWG) n Formation n Goals, Strategies, and Early Activities n Evolving Role of the RWG n PRC Requirements (RE) Process n Deployment/Implementation/Institutionalization n FY 98 RWG Mission & Goals n 2 Background: Software at PRC n Key Elements of the PRC SPI Program The Value of an Organizational Working Group n Lessons Learned l l pp

Background: Software at PRC n Customers and Primary Markets: n Criminal Justice, Defense, Document Management, Education, Electronic Commerce, Command Control, Health, Intelligence, Legacy Systems, Transportation, and Weather n n 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 n 3 l l pp

SPI Mission and Vision Mission: To reduce the life-cycle costs of PRC software development, while increasing software quality and programmer productivity Defect Prevention (action on the process) Processes are: • Desktop accessible • Supported with tools • Bid with proposal Reusable Corp/Sector Processes (PRC PAL) Input Process Output Management Guidance – “Software Processes shall be: Defined. . . Documented. . . Trained. . . Implemented. . . Measured. . . Refined. ” 4 l l pp

Challenge! Diversity of Software Engineering Activities vs. Need for Repeatable, Defined Processes Customers & Markets Products & Services Related Core Competencies HW, OS, Compilers, DBMS, Etc Diverse & Dynamic SW Engineering Methods & Tools Project Size SW Life Cycle Stages Repeatable and Defined Organizational SW Processes Management 5 Engineering Organizational l l pp

Key Elements of the PRC SPI Program n n n Industry Standard Models Institutionalized TQM Method Organizational EPG Infrastructure Continuous Investment in SPI since 1993 SEI Level 3 Maturity Rating Strong Management Commitment 6 l l pp

The Capability Optimized Level 5 Maturity Model Continuously Process Change-Management Improving Technology Change Management (CMM) Process Defect Prevention Managed - Level 4 Provides a Predictable Software Quality Management Quantitative Process Management Standard Process Defined - Level 3 Standard Consistent Practice Disciplined Process Initial - Level 1 7 Peer Reviews Intergroup Coordination Software Product Engineering Integrated Software Management Training Program Organizational Process Definition Organizational Process Focus Repeatable - Level 2 Software Configuration Management Software Quality Assurance Software Subcontract Management Software Project Tracking and Oversight Software Project Planning Requirements Management l l pp

Quality Improvement Provides a Method QI Teams follow the 7 -step problem solving process called the QI Story Priority Management QI 8 These principles support the necessary cultural change Quality Teams Customer Satisfaction P-D-C-A QIDW incorporates Process Management Statistical Process Control Quality In Daily Work Management By Fact Plan-Do-Check-Act Respect for People l l pp

Organization and Infrastructure for SPI PRC QMB Technology EPG Working Group Leaders Full-Time Staff Support Metrics, RWG, others PRC EPG At-Large Membership QITs Project Representation Phoenix I, III, N Core Competency Representation SW, PM 9 Sector EPGs Systems Services IIS Site/Dept/Project EPGs l l pp

PRC’s SPI Investment n Approximately $1 million per year since 1993 n Full-time SEPG support for process definition, etc. Phoenix teams, Metrics Lead team, working groups (e. g. , RWG) n SEPG Infrastructure (Systems) n Development, acquisition, and support of SPI tools (including the Web-based Process Asset Library [PAL]) n SPI training development, seminars and symposia, handbooks, and assessments n $470 per software engineer vs. industry median at $1375 (per SEI) n 10 l l pp

Requirements Working Group (RWG) Formation n A Requirements Management (RM) Process was defined in 1994 n n PRC desired to have its process reflect a full life cycle approach and be compliant with the Systems Engineering CMM (SE-CMM) n n n 11 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 n n Compliant with the CMM for Software (SW-CMM) Lead Team Authority: PRC EPG Team Leader: a PRC Process Engineer and member of the SELT First meeting: March, 1997 l l pp

RWG Goals and Strategy n n Initial Objective: Update the RM Process Strategy: n n n 12 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 l l pp

RWG Goals and Strategy (continued) n Goal: Satisfy SE-CMM requirements for: n n n 13 PA 06 Understand Customer Needs and Expectations PA 02 Derive and Allocate Requirements Project focus Provide an updated process by end of FY 97 (7/31/97) to support SELT FY 97 objectives RWG members available to assist other projects l l pp

RWG: Initial Activities n n 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 n n Team Leader provided: n n 14 Individual participation varied depending upon project priorities Familiarization with the existing RM Process Familiarization with SE-CMM PA 06 and PA 02 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 l l pp

Maintaining Momentum n n 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: n n n 15 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 formal recognition of RWG members The RWG effort helped evolve our KPA/PA “Process Owner Responsibilities” l l pp

Evolving Role of the RWG n n n n 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: ” n n 16 Provided PRC artifacts to the SEI for links on its Web site Joint meetings to help the SEI develop a prototype l l pp

Evolving Role of the RWG (continued) n n n n n 17 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 l l Process” (currently 8 project links are active) pp

The PRC Requirements Process n Defined in a process flow chart and a Process Description (a completed or filled-in DID) for: n Macro: REOOO PRC Requirements (RE) Process n n Micros: n n RE 100 Assess new/changed requirements and control changes RE 200 Understand customer needs and expectations (PA 06) RE 300 Derive and allocate requirements (PA 01) With lots of attention to: n n 18 Full life cycle requirements activities 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, l inputs, outputs, exit criteria, responsibilities, tasks l pp

Key (Essential) Products for Definition of a PRC Process n n n n 19 Organizational policy Process (flow chart) Process description (narrative per DID) Recommended methods Suggested tools Tailoring guidance Training l l pp

Consideration of Tools n 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 n Facilitate relationships with vendors so that brown bags, demos, and evaluation copies are provided as needed n 20 l l pp

Deployment/Implementation/Institutionalization n Work with Proposal Managers, Project Managers, and engineers to encourage use of the process (deployment) n n n 21 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 l l pp

Gaining Buy-in n How many times we have learned: n Involve early those we need to make it happen! Identify management advocates and supporters and enlist their help n Utilize RWG members to help educate and inform n 22 l l pp

Results n n Artifacts are available on the Web Process has been used on 8 projects to date n Achieving repeatable processes n n n 23 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 l l pp

FY 98 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. ). 24 l l pp

FY 98 RWG: Mission and 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. 25 l l pp

The Value of an Organizational Working Group n n n n 26 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) l l pp

Lessons Learned-Organizational Involvement of Project Personnel and Management is critical n Establish an organization-wide approach and infrastructure for process, QI, and customer satisfaction n Build a Knowledge-Sharing Environment n Maintain and Demonstrate Management Commitment n Continuous Improvement n n Both an act and an attitude n 27 An environment of trust and openness l l pp

Lessons Learned-RWG Specific n n n n n 28 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 l l pp

References Sommerville, Ian and Sawyer, Pete, Requirements Engineering: A Good Practice Guide. Wiley & Sons, 1997. IEEE Software, March/April 1998, focus on requirements engineering. Mc. Carthy, 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 & 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), Mc. Graw-Hill, 1997. See also the R. S. Pressman & Associates, Inc. Web site http: //www. rspa. com/ Mc. Connell, 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. l 29 l pp

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/Kai. Gilb/. Rechtin, Eberhardt and Maiev, Mark W. , The Art of Systems Architecting. CRC Press, 1997. Grady, Jeffrey O. , System Requirements Analysis. Mc. Graw 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. 30 l l pp