Adaptable Process
Model
Software
Engineering Checklists
Hypertext version
Copyright ©
2001
R.S. Pressman & Associates, Inc.
These checklists may be useful as you assess the quality of
software engineering work products and the software
process.
IMPORTANT NOTICE: The complete Adaptable Process Model (APM),
including document templates and checklists, is provided for informational
purposes and for assessment by potential users. The APM is copyrighted material
and may not be downloaded, copied, or extracted for use in actual project work.
The full hypertext (html) version of the APM, including document templates and
checklists, may be acquired for use and customization within your organization.
Contact R.S. Pressman & Associates, Inc. at info@rspa.com for
complete licensing information.
If you have developed additional
questions that would be appropriate for this checklist and would like the share
them with others, please send them to us at infor@rspa.com and we'll consider
you additions for inclusion in our checklists. Thanks.
Risk Assessment
Product Size Risks
Few experienced managers would debate the following
statement: Project risk is directly proportional to product size. The
following risk item issues identify generic risks associated with product
size:
- Estimated size of the product in LOC or FP?
- Degree of confidence in estimated size
estimate?
- Estimated size of product in number of programs,
files, transactions?
- Percentage deviation in size of product from average
for previous products?
- Size of database created or used by the
product?
- Number of users of the product?
- Number of projected changes to the requirements for
the product? Before delivery? after delivery?
- Amount of reused software?
In each case, the information for the product to be
developed must be compared to past experience. If a large percentage deviation
occurs or if numbers are similar, but past results were considerably less than
satisfactory, risk is high.
Business Impact Risks
An engineering manager at a major software company
placed the following framed plaque on his wall: "God grant me brains to be a
good project manager and the common sense to run like hell whenever marketing
sets project deadlines!" The marketing department was driven by business
considerations, and business considerations sometimes come into direct
conflict with technical realities. The following risk item issues identify
generic risks associated with business impact:
- Affect of this product on company revenue?
- Visibility of this product by senior
management?
- Reasonableness of delivery deadline?
- Number of customers who will use this product and
the consistency of their needs relative to the product?
- Number of other products/systems with which this
product must be interoperable?
- Sophistication of end users?
- Amount and quality of product documentation that
must be produced and delivered to the customer?
- Governmental constraints on the construction of the
product?
- Costs associated with late delivery?
- Costs associated with a defective product?
Each response for the product to be developed must be
compared to past experience. If a large percentage deviation occurs or if
numbers are similar, but past results were considerably less than
satisfactory, risk is high.
Customer -Related Risks
All customers are not created equal. Pressman and
Herron [PRE91] discuss this issue when they state:
Customers have different needs. Some know what
they want; others know what they don't want. Some customers are willing to sweat
the details, while others are satisfied with a vague promises. Customers have
different personalities. Some enjoy being customers–the tension, the
negotiation, the psychological rewards of a good product. Others would prefer
not to be customers at all. Some will happily accept almost anything that is
delivered and make the very best of a poor product. Others will complain
bitterly when quality is lacking; some will show their appreciation when quality
is good; a few will complain no matter what. Customers also have varied
associations with their suppliers. Some know the product and producer well;
others may be faceless, communicating with the producer only by written
correspondence and a few hurried telephone calls. Customers are often
contradictory. They want everything yesterday for free. Often, the producer is
caught among the customers' own contradictions.
A ‘bad’ customer can have a profound impact on a
software team’s ability to complete a project on time and within budget. A bad
customer represents a significant threat to the project plan and a substantial
risk for the project manager. The following risk item checklist identifies
generic risks associated with different customers:
- Have you worked with the customer in the
past?
- Does the customer have a solid idea of what is
required? Has the customer spent the time to write it down?
- Will the customer agree to spend time in formal
requirements gathering meetings (Chapter 11) to identify project
scope?
- Is the customer willing to establish rapid
communication links with the developer?
- Is the customer willing to participate in
reviews?
- Is the customer technically sophisticated in the
product area?
- Is the customer willing to let your people do their
job–that is, will the customer resist looking over your shoulder during
technically detailed work?
- Does the customer understand the software
engineering process?
If the answer to any of these questions is "no,"
further investigation should be undertaken to assess risk
potential.
Process Risks
If the software engineering process (Chapter 2) is
ill-defined; if analysis, design and testing are conducted in an ad hoc
fashion; if quality is a concept that everyone agrees is important, but no one
acts to achieve in any tangible way, then you've got a project that is at
risk. The following questions are extracted from a workshop on the assessment
of software engineering practice developed by R.S. Pressman & Associates,
Inc. [PRE95]. The questions themselves have been adapted from the Software
Engineering Institute (SEI) software process assessment
questionnaire.
Process Issues
- Does your senior management support a written policy
statement that emphasizes the importance of a standard process for software
development?
- Has your organization developed a written
description of the software process to be used on this project?
- Are staff members "signed-up" to the software
process as it is documented and willing to use it?
- Is the software process used for other
projects?
- Has your organization developed or acquired a series
of software engineering training courses for managers and technical
staff?
- Are published software engineering standards
provided for every software developer and software manager?
- Have document outlines and examples been developed
for all deliverables defined as part of the software process?
- Are formal technical reviews of the requirements
specification, design and code conducted regularly?
- Are formal technical reviews of test procedures and
test cases conducted regularly?
- Are the results of each formal technical review
documented, including defects found and resources used?
- Is there some mechanism for ensuring that work
conducted on a project conforms with software engineering standards?
- Is configuration management used to maintain
consistency among system/software requirements, design, code, and test
cases?
- Is a mechanism used for controlling changes to
customer requirements that impact the software?
- Is there a documented statement of work, software
requirements specification, and software development plan for each
subcontract?
- Is a procedure followed for tracking and reviewing
the performance of subcontractors?
Technical Issues
- Are facilitated application specification techniques
used to aid in communication between the customer and developer?
- Are specific methods used for software
analysis?
- Do you use a specific method for data and
architectural design?
- Is more than 90 percent of your code written in a
high order language?
- Are specific conventions for code documentation
defined and used?
- Do you use specific methods for test case
design?
- Are software tools used to support planning and
tracking activities?
- Are configuration management software tools used to
control and track change activity throughout the software process?
- Are software tools used to support the software
analysis and design process?
- Are tools used to create software prototypes?
- Are software tools used to support the testing
process?
- Are software tools used to support the production
and management of documentation?
- Are quality metrics collected for all software
projects?
- Are productivity metrics collected for all software
projects?
- If a majority of the above questions are answered
"no," software process is weak and risk is high.
Technology Risk
Pushing the limits of the technology is challenging and
exciting. It's the dream of almost every technical person, because it forces a
practitioner to use his or her skills to the fullest. But it's also very
risky. Murphy's law seems to hold sway in this part of the development
universe, making it extremely difficult to foresee risks, much less plan for
them. The following risk item checklist identifies generic risks associated
with the technology to be built:
- Is the technology to be built new to your
organization?
- Do the customer's requirements demand the creation
of new algorithms, input or output technology?
- Does the software interface with new or unproven
hardware?
- Does the software to be built interface with vendor
supplied software products that are unproven?
- Does the software to be built interface with a
database system whose function and performance have not been proven in this
application area?
- Is a specialized user interface demanded by product
requirements?
- Do requirements for the product demand the creation
of program components that are unlike any previously developed by your
organization?
- Do requirements demand the use of new analysis,
design or testing methods?
- Do requirements demand the use of unconventional
software development methods, such as formal methods, AI-based approaches,
artificial neural networks?
- Do requirements put excessive performance
constraints on the product?
- Is the customer uncertain that the functionality
requested is "do-able?"
- If the answer to any of these questions is "yes,"
further investigation should be undertaken to assess risk potential.
Development Environment Risks
If a carpenter were asked to create a fine piece of
furniture with a bent, dull hand saw, the quality of the end product would be
suspect. Inappropriate or ineffective tools can blunt the efforts of even a
skilled practitioner. The software engineering environment supports the
project team, the process, and the product. But if the environment is flawed,
it can be the source of significant risk. The following risk item checklist
identifies generic risks associated with the development
environment:
- Is a software project management tool
available?
- Is a software process management tools
available?
- Are tools for analysis and design available?
- Do analysis and design tools deliver methods that
are appropriate for the product to be built?
- Are compilers or code generators available and
appropriate for the product to be built?
- Are testing tools available and appropriate for the
product to be built?
- Are software configuration management tools
available?
- Does the environment make use of a database or
repository?
- Are all software tools integrated with one
another?
- Have members of the project team received training
in each of the tools?
- Are local experts available to answer questions
about the tools?
- Is on-line help and documentation for the tools
adequate?
- If a majority of the above questions are answered
"no," the software development environment is weak and risk is high.
Risks Associated with Staff Size and
Experience
Barry Boehm suggests the following questions to assess
risks associated with staff size and experience:
- Are the best people available?
- Do the people have the right combination of
skills?
- Are enough people available?
- Are staff committed for entire duration of the
project?
- Will some project staff be working only part time on
this project?
- Do staff have the right expectations about the job
at hand?
- Have staff received necessary training?
- Will turnover among staff be low enough to allow
continuity?
- If the answer to any of these questions is "no,"
further investigation should be undertaken to assess risk
potential.
Return to Checklist
Table of Contents