Lplp lplp 1 Dr. Ralph R. Young Director, Systems and Software Process Engineering Litton PRC...
30
l p l p 1 Dr. Ralph R. Young Director, Systems and Software Process Engineering Litton PRC [email protected]Third International Conference on Practical Software Quality Techniques (PSQT ‘98) October, 1998
Lplp lplp 1 Dr. Ralph R. Young Director, Systems and Software Process Engineering Litton PRC [email protected] Third International Conference on Practical
lplp lplp 1 Dr. Ralph R. Young Director, Systems and Software
Process Engineering Litton PRC [email protected] 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.