Transcript No Slide Title

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
l l
1
pp
Briefing Agenda
2

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
l l
pp
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

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





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
QIDW incorporates
Process
Management Statistical Process
Control
QI
8
These
principles
support the
necessary
cultural
change
Quality
Teams
Customer
Satisfaction
P-D-C-A
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, II, III, N
Core
Competency
Representation
SW, PM
9
Sector
EPGs
Systems Services IIS
Site/Dept/Project EPGs
l l
pp
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)

10
l l
pp
Requirements Working Group (RWG) Formation

A Requirements Management (RM) Process was defined in
1994


PRC desired to have its process reflect a full life cycle
approach and be compliant with the Systems Engineering
CMM (SE-CMM)



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


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


Initial Objective: Update the RM Process
Strategy:






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)

Goal: Satisfy SE-CMM requirements for:





13
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
l l
pp
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


Team Leader provided:




14
Individual participation varied depending upon project
priorities
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
l l
pp
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:






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 for formal recognition of RWG members
The RWG effort helped evolve our KPA/PA “Process Owner
Responsibilities”
l l
pp
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:”


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)









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

Defined in a process flow chart and a Process Description (a
completed or filled-in DID) for:

Macro: REOOO PRC Requirements (RE) Process


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:




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







19
Organizational policy
Process (flow chart)
Process description (narrative per DID)
Recommended methods
Suggested tools
Tailoring guidance
Training
l l
pp
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

20
l l
pp
Deployment/Implementation/Institutionalization

Work with Proposal Managers, Project Managers, and
engineers to encourage use of the process (deployment)






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

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

22
l l
pp
Results


Artifacts are available on the Web
Process has been used on 8 projects to date

Achieving repeatable processes






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
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.).
24
l l
pp
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.
25
l l
pp
The Value of an
Organizational Working Group








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
 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



27
Both an act and an attitude
An environment of trust and openness
l l
pp
Lessons Learned-RWG Specific










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.
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.
l
29
l
pp
References
(continued)
Gilb, Tom (authoring on Evolutionary Development (EVO), RequirementsDriven 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.
30
l l
pp