Slide 1

lplp lplp 1 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

Slide 2

lplp lplp 2 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 & Goals The Value of an Organizational Working Group Lessons Learned

Slide 3

lplp lplp 3 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

Slide 4

lplp lplp 4 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 Input Process Output Defect Prevention (action on the process) Reusable Processes (PRC PAL) Corp/Sector Processes are: Desktop accessible Supported with tools Bid with proposal

Slide 5

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

Slide 6

lplp lplp 6 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

Slide 7

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

Slide 8

lplp lplp 8 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

Slide 9

lplp lplp 9 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

Slide 10

lplp lplp 10 PRCs 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)

Slide 11

lplp lplp 11 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

Slide 12

lplp lplp 12 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

Slide 13

lplp lplp 13 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)

Slide 14

lplp lplp 14 RWG: Initial Activities High level of interest on the part of several project requirements engineers: wanted to lend their experience and expertise to improve PRCs 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

Slide 15

lplp lplp 15 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 PRCs 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

Slide 16

lplp lplp 16 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 SEIs Transistion Packages Initiative: Provided PRC artifacts to the SEI for links on its Web site Joint meetings to help the SEI develop a prototype

Slide 17

lplp lplp 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 Process (currently 8 project links are active) Evolving Role of the RWG (continued)

Slide 18

lplp lplp 18 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: RE100Assess new/changed requirements and control changes RE200Understand customer needs and expectations (PA06) RE300Derive 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

Slide 19

lplp lplp 19 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

Slide 20

lplp lplp 20 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

Slide 21

lplp lplp 21 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

Slide 22

lplp lplp 22 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

Slide 23

lplp lplp 23 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

Slide 24

lplp lplp 24 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.).

Slide 25

lplp lplp 25 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 nextetc.) 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

Slide 26

lplp lplp 26 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)

Slide 27

lplp lplp 27 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

Slide 28

lplp lplp 28 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

Slide 29

lplp lplp 29 References Sommerville, Ian and Sawyer, Pete, Requirements Engineering: A Good Practice Guide. Wiley & 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 & 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 & 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.

Slide 30

lplp lplp 30 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.