CSE 8315
Software Acquisition Practices, Legal and Economic Issues
Class Notes
Fall 2006
John Pfister, Adjunct Professor
OFFICE: (972) 344-2094
E-MAIL: j-pfister@prodigy.net
Web Site: http://engr.smu.edu/cse/8315/
FAX: (972) 596-1484 (Home)
FAX: (214) 768-3085 (SMU CS Dept)
NOTE: These class notes are subject to
change during any lecture
 Fall 2006 – John Pfister
Last Updated: July 24,
1 2006
Texts
Software Acquisition Management: Managing
the Acquisition of Custom Software Systems by
John Marcinak and Don Reifer
Alpha-Graphics
3032 Mockingbird
Dallas, TX 75205
(214) 363-1101
US054@alphagraphics.com
 Fall 2006 – John Pfister
2
References
• Copyright Your Software by Stephen Fishman
• Legal Battles That Shaped the Computer Industry
by Lawrence Graham
• Managing the Software Process by Watts
Humphrey
• Software Development – A Legal Guide by Stephen
Fishman
• Software Engineering Economics by Barry Boehm
• The Software Developer's and Marketer's Legal
Companion by Gene Landy
• Managing Software Acquisition by B. Craig Meyers
and Patricia Oberndorf
 Fall 2006 – John Pfister
3
Course Objectives
Understand software acquisition process and
issues from both the buyer's and seller's
perspective.
1. Awareness of legal issues associated with intellectual
property, data rights, and contracts
2. Specifying software requirements
3. Preparing a software proposal
4. Managing software subcontractors
5. Understanding the use of capability maturity models
in an acquisition
6. Evaluating proposals
 Fall 2006 – John Pfister
4
Course Outline
1. Course Overview
• Assignments and Grading
• Text - Chapter 1, Introduction
• Text - Chapter 2, The Software Acquisition Environment
2. Acquisition Management Overview
• Text - Chapter 3, Acquisition Management
• Text - Chapter 4, Software SOW Issues
• Text - Chapter 5, Contracts and Contract Law
3. Protection of Intellectual Property
• Software Copyright Law
• Software-Related Patents
• Software Trade Secrets and Confidentiality Agreements
• Software Product Liability
4. Software Management
• Text - Chapter 6, Software Management--The Buyer's Model
• Text - Chapter 7, Software Management--The Seller's Model
• Text - Chapter 8, Software Management--The Team Approach
5. Economic Issues
• Text - Chapter 9, Cost Issues and Answers
Course Outline
6. Quality Assurance
•
Text - Chapter 10, Quality Management
•
ISO 9000-Series Standards
7. Acquisition Management Topics
•
Text - Chapter 11, Special Topics in Acquisition Management
•
Text - Chapter 12, Future Directions in Acquisition Management
8. Best Practices
•
Capability Maturity Model Integration (CMMI)
•
Acquisition Capability Maturity Model
•
•
9.
Project Management Body of Knowledge
The Program Manager’s Guide to Software Acquisition Best
Practices
Case Study
•
Request for Proposal (RFP)
•
Statement of Work (SOW)
Assignment 1
Begin Research. The student will select a OR b, below, for a
research project that will be delivered in Assignment 3:
a) Analyze a Request for Proposal (RFP). Perform an analysis of an
actual software acquisition project. Deliverables:
1) A synopsis of the RFP.
2) Either a copy of the RFP and its Statement of Work (SOW) or
the URL pointing to where the RFP and SOW can be found on the
Internet.
b) Research a Software Legal Issue. Examples of topics are:
Software licensing, software patents, software copyrights, software
data rights, software product liability, etc. Deliverables:
1) A paragraph that describes the legal issue to be addressed in the
research paper. The topic must be sufficiently narrow that it can
be addressed in detail. This is not to be a high level survey of a
topic.
2) An annotated bibliography with at least 5 sources for the
selected topic (see Appendix A of Syllabus for format).
 Fall 2006 – John Pfister
7
Assignment 2
Task: Prepare Questions. Using the case study RFP (on the class web
site), develop questions that you would want to get resolved during a
pre-proposal Q&A meeting with the customer. Assume that all
bidders must submit questions in writing and that there will be no
opportunity for follow-up questions
Deliverable: Ten (10) questions with references to relevant paragraphs.
For each question, summarize the issue that the question addresses
(e.g., why that question is relevant and how the answer could change
your approach to the proposal). There must be at least four
independent questions on the RFP and SOW. Provide the questions
in the following format:
Question
Issue
1.
2.
 Fall 2006 – John Pfister
8
Reference
Assignment 3
Task: Write paper selected in Assignment 1.
Deliverable: One type written document in the
format described in Appendix B of the Syllabus.
Return of Papers: Papers are not returned to the
student.
Grading: The paper turned in for assignment 3 will
be graded as follows:
Substanc Degree to which topic is covered in depth
e
80%
Format
Degree to which the format prescribed in
Appendix B is followed
10%
Writing
Grammatical correctness
10%
 Fall 2006 – John Pfister
9
Grades and Due Dates




Per Cent
In-Class
Distant
Assignment 1
3%
16 Oct
23 Oct
Assignment 2
6%
20 Nov
27 Nov
Assignment 3
25%
27 Nov
4 Dec
Mid-Term
33%
16 Oct
23 Oct
Final Exam
33%
4 Dec
11 Dec
A = 90 – 100 %
B = 80 – 89 %
C = 70 – 79 %
All due dates are as of midnight CST on date shown.
Late assignments are penalized at the rate of 10% per week (or any part of a week).
Due date for Distant students will be adjusted if tapes are consistently
delivered more than one week after in-class date. Negotiate a due date with
instructor BEFORE an assignment is due.
Graduating students may have to complete Final Exam earlier.
 Fall 2006 – John Pfister
10
Chapter 1 – Introduction
• Acquisition Management is the process of managing the
acquisition of custom software often involves:
* Complex, diverse requirements
* Large software development team
* Users who may be involved in specifying requirements and in
accepting the system, but not in the development process
* Software that is not commercial off-the-shelf, but may include
some
* Developer is not the acquirer
* Legal issues involving contracts, copyrights, trade secrets,
patents, warranties, and product liability
 Fall 2006 – John Pfister
11
Introduction (Continued)
• Software acquisition process includes the
following activities:
*
*
*
*
*
*
*
*
Planning
Budgeting
Specifying requirements
Soliciting bids/responses
Evaluating bids/responses
Contracting/negotiating
Monitoring development progress
Evaluating/accepting system
 Fall 2006 – John Pfister
12
Software Development Environment
• Software Development Process Models; e.g.,
•
•
Waterfall, Incremental Development, Spiral
Software Engineering Environment
Overlapping Management Responsibilities
* Software Acquisition Management - process of
assembling the requirements, planning the project,
acquiring the resources, and monitoring and
controlling the implementation
* Software Project Management - process of
managing the technical process.
* Software Engineering Management - process of
building the software product
 Fall 2006 – John Pfister
13
Buyer / Seller Model
Organizational Environment
Buyer
Seller
Corporate
Finance,
Organizational
Management
Director of
Programs
Planning, etc.
Div is ion
Staff
Personnel
Finance
Staff
Finance, Planning
Human Resouces
Other
Programs
Systems
Engineering
Manufacturing
Contracting,
Technical Svcs
Program X
Project X
Staff
Plans
Data, etc.
Test
Subsystem
Management
 Fall 2006 – John Pfister
Etc.
14
Hardware
Software
Buyer/Seller Activities Before the Acquisition
The Buyer plans for the
acquisition by:
• Detailing the requirements
• Allocating the resources
• Arranging for the selection
of a seller
• Contracting with the
selected seller
• Building an in-house team
• Addressing the support
requirements
 Fall 2006 – John Pfister
15
The Seller prepares for the
acquisition by:
• Deciding whether the
resources and capability to
bid on the contract are
available
• Deciding whether to bid
• Developing a team to
respond to the proposal
• Estimating the resources
required to accomplish the
work
Software Acquisition Management Problems
The challenge on most projects is to align:
Cost
Schedule
Performance
Ideally, the Buyer should specify performance, and the
Seller should bid cost and schedule
 Fall 2006 – John Pfister
16
Chapter 2
The Software Acquisition Environment
•
•
•
•
The System Life Cycle
The Software Life Cycle
Management Processes
The Role of Standards
 Fall 2006 – John Pfister
17
Systems Life Cycle
• Concept Exploration Phase
• Demonstration and Validation Phase
•
•
(Program Development Risk Reduction)
Full Scale Development
Production and Development
 Fall 2006 – John Pfister
18
Systems Life Cycle
Concept
E x p l o r a ti o n
o R e q u ire m e n t
D e fi n i ti o n
o P la n n in g
o T r a d e -o f f s
o P r o to ty p e s
D e m o n s tr a ti o n
a n d V a l i d a ti o n
o Ad v a n ce d
P r o to ty p e s
E n g in e e rin g
o R is k
Id e n ti fi c a ti o n
F u l l -S c a l e
D e v e lo p m e n t
o S y s te m
D e v e lo p m e n t
(H a r d w a r e a n d
S o ftw a r e )
D e p lo y m e n t
P r o d u c ti o n
o M u l ti p l e C o p i e s
P ro d u ce d
o T ra in in g
o O p e r a ti o n s
o M a i n te n a n c e
a n d S u p p o rt
 Fall 2006 – John Pfister
19
Software Life Cycle
•
•
•
•
•
Software Requirements Analysis
Software Design
Code and Unit Testing
Subsystem Test and Integration
Test and Integration
 Fall 2006 – John Pfister
20
Software Life Cycle Examples
• Waterfall - each stage of development is
•
•
executed with the system being delivered
at the end.
Incremental Development - each stage of
development is executed with a major
component of the system being delivered
at the end.
Spiral - each stage of development is
executed in relatively short cycles with a
subset (or even a prototype) of the total
system being developed each time.
 Fall 2006 – John Pfister
21
Management Processes
•
•
•
•
•
Documentation
Management and Engineering Reviews
Configuration Management
Quality Assurance
Assessment
 Fall 2006 – John Pfister
22
Documentation & Reviews
System
Reqmts
Design
Software
Reqmts
Analysis
Preliminary
Design
o SRS
Detailed
Design
Code and
o SDP
o Software
Design
Specifications
o Software Test
Plan
Functional
Baseline
Reviews:
Unit Test
o Source
Code
o Test
Descrip.
Subsystem
Test & Int
o Detailed
Test Proc
o User Doc
Test &
Integration
o Prod Spec
o Test Rpts
Allocated
Baseline
SRR
 Fall 2006 – John Pfister
Product
Baseline
PDR
CDR
23
TRR
Configuration Management
•
•
•
•
Configuration
Configuration
Configuration
Configuration
 Fall 2006 – John Pfister
Identification
Control
Audit
Status Accounting
24
Configuration Management
Baselines:
• Functional – System Requirements
• Allocated – Software Requirements
• Product – Fully designed, developed, and tested
product
Control Structure:
• Configuration Control Board (CCB) – Controls changes
•
to formal baselines
Software Fault or Discrepancy Review Board (DRB) –
controls software changes that do NOT affect
formal baselines
 Fall 2006 – John Pfister
25
Quality Assurance
Assure quality of:
• Deliverable software and its documentation
• The processes used to produce deliverable
software
• Non-deliverable software
[DOD, 1988]
Quality means conformance to requirements
 Fall 2006 – John Pfister
26
Assessment (Metrics)
Management indicators that provide feedback
on:
*
*
*
*
Process
Product
Project
Productivity
Standards facilitate communication between the buyer and the seller
 Fall 2006 – John Pfister
27
•
Standards
IEEE – Maps standard processes to:
*
*
*
*
*
Project Management
Predevelopment
Development
Post-development
Integral
• Military – Structured processes that follow
•
•
•
the waterfall model
NASA – Software Management and Assurance
Program (SMAP)
ISO – International Standards Organization
Others – Automobile industry for example.
 Fall 2006 – John Pfister
28
Chapter 3 – Acquisition Management
The Buyer
• Determines:
The Seller
• Determines:
* What the system
requires
* When it will be
needed
* How it will be
accepted
* How the software
will be developed
* What resources are
required
• Directs strategy at
getting system at
lowest cost and ontime
 Fall 2006 – John Pfister
29
• Directs strategy at
getting the buyer
to share risk while
making a profit
Procurement Life-Cycle
• Concept exploration
• Source acquisition
• Performance management
 Fall 2006 – John Pfister
30
Acquisition Management (Continued)
•
•
•
•
•
•
Acquisition Management Strategy
Buyer Activities
Seller Activities
Request for Proposal
Proposal
Contract Negotiations
 Fall 2006 – John Pfister
31
Acquisition Management Strategies
• Competitive Acquisition
* Contractors compete thru a bidding process
* Contract awarded on basis of proposal evaluation
* Requirements are generally understood
• Multi-Phase Acquisition
* Contractors compete thru a bidding process for the first
phase of the acquisition
* Multiple contracts may be awarded for first phase
* Subsequent phases awarded on basis of proposal and
performance in first phase
* Often used when requirements are not well understood
• Sole-Source Acquisition
* Contract awarded without competition
* Requirements should be very well understood
 Fall 2006 – John Pfister
32
Strategy Selection Factors
Risk
Those technical factors with the potential to
adversely impact cost, schedule, or performance.
Complexity
A relative gauge of the difficulty of the software
product development
Uniqueness
The degree to which competition can be used during
source selection.
Cost
A measure of the dollar resource available to do the
job.
Schedule
A measure of the amount of time available to get the
job done.
Size
A measure of the amount of effort required to get
the job done; e.g., lines of code.
Requirements
Volatility
A measure of the definition and stability of the
requirements for the system.
 Fall 2006 – John Pfister
33
Strategy Selection Factors
Factor
Sole-Source
Competitive
Two-Phase
Risk
low
low-medium
high
Complexity
low
medium
high
Uniqueness
yes
no
no
moderate
high
high
Schedule
tight
flexible
flexible
Size
small
large
large
Req. Volatility
stable
volatile
volatile
Cost
 Fall 2006 – John Pfister
34
Buyer Activities
• Writes Project Management Plan
* Work Breakdown Structure
* Schedule
* Cost Estimate
• Writes Request for Proposal (RFP)
*
*
*
*
*
*
*
Operational Concept Document
System Specification
Statement of Work
Terms and conditions
Deliverables
Evaluation criteria
Proposal preparation instructions
 Fall 2006 – John Pfister
35
•
•
•
•
•
Prepares bidders list
Distributes RFP
Evaluates proposals
Selects contractor
Negotiates contract
Seller Activities
• Tracks potential procurements
• Responds to requests for information and
•
•
•
•
•
•
•
comments on draft RFPs
Identifies internal risk reduction activities
Performs market analysis
Justifies bid and proposal funding
Identifies necessary resources
Develops proposal
Negotiates technical and cost terms and conditions
Submits a best and final offer (BAFO)
 Fall 2006 – John Pfister
36
Request for Proposal
• Initiates source selection phase
• Scopes the technical requirements
• Provides a statement of the work to be
•
performed
Details the administrative terms and
conditions
 Fall 2006 – John Pfister
37
Legal and Administration Actions
•
•
•
•
•
•
•
•
•
Equal opportunity requirements and reporting
Compliance with labor law legislation
Patent claims and rights to computer software
Invoicing and payment terms and conditions
Use of toxic chemicals in the workplace
Termination for convenience and/or default
Rights to inspect accounting records and
claims
Conflict of interest
Use and replacement of key personnel
 Fall 2006 – John Pfister
38
Competitive Source Process
Source selection process
1.
2.
3.
4.
5.
6.
7.
8.
Complete selection package
Prepare source list
Issue solicitation
Score and rank responses
Issue questions
Rescore based on responses
Negotiate
Award contract
Source selection organization
1. Source selection authority
2. Source selection advisors
3. Source selection evaluators
 Fall 2006 – John Pfister
39
Writing a Winning Proposal
•
•
•
•
•
•
•
•
Complete Solicitation Package
Prepare Source List
Issue RFP
Score and Rank Responses
Issue Questions
Rescore Based on Responses
Negotiate
Award
 Fall 2006 – John Pfister
40
Negotiations and Appeasements
1. Technical terms and conditions
2. Financial terms and conditions
3. Contract terms and conditions
 Fall 2006 – John Pfister
41
Potential Problems
Administrative
workload
Administrative burden of contract detracts
from monitoring the technical issues.
Creeping
functionality
Customer keeps trying to add scope to the
project after it has started.
Fragmentation
Buyer/seller team members split time on other
projects
Gold plating
Developers impose costly elegant solutions
rather than simple ones
“I’ paid to engineer” Buyer dictates the solution rather than the
requirements
Missing indicators
Poor selection of metrics to measure progress
Who’s in charge
Too many bosses
 Fall 2006 – John Pfister
42
Contract Management and Close-out
• Finalize overhead rates and make final
•
•
•
payment
Dispose of excess property
Release any claims and determine status of
excess funds
Document seller's performance
 Fall 2006 – John Pfister
43
Offshore Software Development
•
•
•
•
Benefits
Characteristics of offshore projects
Characteristics of offshore companies
CMM profile of offshore companies
Reference: WWW. SWDEVELOPER.COM
 Fall 2006 – John Pfister
44
Offshore Software Development Benefits
• Lower cost
* Offshore companies can develop custom software at an
affordable price
* Professional labor offshore can be as much as 50% less
* Savings in recruiting and training new staff
* Savings in hardware and software investment needed to
support the development stages
• Availability of Technical Talent
* Large pool of professional talent
* Avoid immigration problems
* Because of the lower cost, possible for time-critical projects
to hire larger staff
• Free up staff to work on higher priority tasks
• Most offshore companies will sign non-disclosure
agreements
 Fall 2006 – John Pfister
45
Characteristics of an Offshore Project
• Labor intensive project
• Series of short-term projects are better
•
•
•
candidates than a single long-term project
Requirements should be well defined
Deliverables can be independently tested and
verified
If software must be integrated into a system not
developed by the offshore company:
* Interfaces must be well defined
* Responsibilities for integration and testing must be
defined
 Fall 2006 – John Pfister
46
Characteristics of an Offshore Company
• Highly skilled professional staff
• Cost per professional staff/hour is significantly
•
•
•
•
lower than locally available professionals
Technical staff is conversant in English
Good, high-speed data transmissions and easy
access to Internet and e-mail
Availability of advanced technology and
technical training and support
Experience with advanced technology
 Fall 2006 – John Pfister
47
Characteristics of an Offshore Company
• Good infrastructure facilities; e.g.,
•
•
•
workstations, servers, LANs, etc.
Good configuration management and quality
assurance practices
Stable political environment with strong legal
and legislative framework
Incentives given by the government for these
ventures
 Fall 2006 – John Pfister
48
USA and Offshore Organization Maturity Profiles
45.0%
42.7%
40.0%
% of Organizations
35.4%
35.0%
30.0%
29.3%
27.3%
25.0%
20.0%
21.7%
17.6%
15.0%
11.5%
10.0%
8.3%
4.5%
5.0%
1.8%
0.0%
Initial
Repeatable
Defined
USA
Managed
Optimizing
Offshore
Based on 714 U. S. organizations and 444 offshore organizations – March 2002
 2002 by Carnegie Mellon University
 Fall 2006 – John Pfister
49
Number of Assessments and Maturity Levels Reported
Country
Argentina
Australia
Austria
Barbados
Belgium
Brazil
Canada
Chile
China
Colombia
Denmark
Egypt
Finland
France
Germany
Greece
Hong Kong
Hungary
India
Ireland
Israel
Italy
 Fall 2006 – John Pfister
Number of
Maturity Maturity Maturity Maturity
Assessments Level 1 Level 2 Level 3 Level 4
Reported
Reported Reported Reported Reported
Less than 10
27
Yes
Yes
Yes
No
Less than 10
Less than 10
Less than 10
15
Yes
Yes
Yes
No
47
Yes
Yes
Yes
No
Less than 10
18
No
Yes
Yes
No
Less than 10
Less than 10
Less than 10
Less than 10
103
Yes
Yes
Yes
Yes
21
Yes
Yes
Yes
No
Less than 10
Less than 10
Less than 10
153
Yes
Yes
Yes
Yes
Less than 10
27
Yes
Yes
Yes
No
21
Yes
Yes
Yes
No
 2002 by Carnegie
50
Maturity
Level 5
Reported
No
No
Yes
Yes
No
No
Yes
No
No
Mellon University
Number of Assessments and Maturity Levels Reported
Country
Japan
Korea, Republic of
Malaysia
Mexico
Netherlands
New Zealand
Phillipines
Poland
Portugal
Puerto Rico
Russia
Saudi Arabia
Singapore
South Africa
Spain
Sweden
Switzerland
Taiwan
Thailand
Turkey
United Kingdom
United States
Venezuela
 Fall 2006 – John Pfister
Number of
Maturity Maturity Maturity Maturity Maturity
Assessments Level 1 Level 2 Level 3 Level 4 Level 5
Reported
Reported Reported Reported Reported Reported
46
Yes
Yes
Yes
No
Yes
Less than 10
Less than 10
Less than 10
12
Yes
Yes
Yes
No
No
Less than 10
Less than 10
Less than 10
Less than 10
Less than 10
Less than 10
Less than 10
15
Yes
Yes
Yes
No
Yes
Less than 10
Less than 10
Less than 10
Less than 10
Less than 10
Less than 10
Less than 10
103
Yes
Yes
Yes
No
No
1496
Yes
Yes
Yes
Yes
Yes
Less than 10
51
 2002 by Carnegie Mellon University
Federal Government Using Offshore Contractors
Now that companies are taking a harder look at offshore outsourcing, does it
make sense for the federal government to weigh the cost benefits with the
security concerns (and potential political blow-back)? Outsourcing IT work
overseas doesn’t bother Bush administration IT czar Mark Forman. “We
don’t care if its built overseas or in the U.S., as long as it’s built to the same
high standards,” says Forman, chief enforcer of the fed’s IT policy as
associate director for IT and E-government a the Office of Management and
Budget. But Forman doesn’t see much need to outsource overseas.
Rep Tom Davis, R-Va., who chairs the House Subcommittee on IT and
Procurement Policy, says that using overseas programmers to write
nonsensitive, nonstrategic government software could be a way to save
taxpayers’ money. “I don’t have a problem if work for the government – if it’s
done cheaper, same quality, talking about best values – is going offshore.”
Davis says most overseas work would likely be part of outsourcing contracts
awarded to American firms. “I see my job as trying to be an honest broker
here to get the best value for the country.”
“IT Confidential: The Politics of Offshore Outsourcing,” by John Soat, Information
Week, December 16, 2002
 Fall 2006 – John Pfister
52
Chapter 4 – Statement of Work (SOW)
• Purpose: Conveys management
•
requirements for tasks to be performed.
Subject areas addressed include:
*Reliability
*Quality Assurance
*Maintainability
*Configuration Management
*Logistics
*Training
*Supportability
 Fall 2006 – John Pfister
53
*Safety
*Security
*Metrics
*Documentation
*Acceptance
*Test and Evaluation
Request for Proposal (RFP) Outline
Part I - The Schedule
Section
Section
Section
Section
Section
Section
Section
Section
A
B
C
D
E
F
G
H
Solicitation/contract form
Supplies or services and price/cost
Description/specs/work statement
Packaging and marking
Inspection and acceptance
Deliveries or performance
Contract administration data
Special contract requirements
Part II - Contract Clauses
Section I
 Fall 2006 – John Pfister
Contract clauses
54
RFP Outline (Continued)
Part III - List of documents, exhibits and
other attachments
Section J List of attachments
Part IV - Representations and instructions
Section K
other
Representations, certifications and
statements of offerors
Section L Instructions, conditions, and notices
to offerors
Section M Evaluation factors for award
 Fall 2006 – John Pfister
55
Planning
• Identify Organizational functions and
•
•
•
•
•
•
personnel to participate in SOW preparations
Initial organizational meeting
Review of pertinent materials by SOW team
SOW team meeting set work assignments
Review of draft SOW
Review of SOW by blue team
Review and coordination of SOW prior to
release
 Fall 2006 – John Pfister
56
System/Software Engineering Issues
• Requirements management
• Selection/definition of software
•
•
subsystem/components
Tools and environment
Methods and methodologies
 Fall 2006 – John Pfister
57
Engineering Methods
System
Reqmts
Design
Code and peer reviews
Structured analysis
Code audits
Data flow testing
Software
Reqmts
Analysis
Preliminary
Design
Detailed
Design
Code and
Unit Test
Subsystem
Requirements
Modeling
Test & Int
Test &
Integration
Functional
decomposition
Data flow
Path analysis
System I&T
Structured analysis/design
Program design language
Random testing
Functional testing
Real-time testing
ENGINEERING METHODS
 Fall 2006 – John Pfister
58
Management Methods
Baseline control - Configuration Control Board
Functional Baseline
Allocated Baseline
System
Reqmts
Design
Software
Reqmts
Analysis
Preliminary
Design
Detailed
Design
Risk
analysis
Code and
Unit Test
Subsystem
Test & Int
Requirements
review
Design
reviews
Test reviews
Testing
Documentation review
Specifications, manuals, training materials, etc.
Project review and
Technical interchange meetings
MANAGEMENT METHODS
 Fall 2006 – John Pfister
59
Test &
Integration
System I&T
Management Issues
•
•
•
•
•
Software Documentation
Engineering Data Management
Configuration Management
Quality Assurance
Assessment
 Fall 2006 – John Pfister
60
Software Documentation
• Formal description of the products of the
•
•
engineering process
Costs may range from 20-40% of overall
development
Should be tailored to needs of development
effort
 Fall 2006 – John Pfister
61
Software Documentation
• Requirements - the buyer should:
* Require seller to describe methods to be used to
generate, record, store, and control documentation
* Require seller to describe management of
documentation in the SDP
* Specify the types and formats of documents
required
* Specify the detail expected
* Specify how tailoring will be handled
* Specify use of a standards and conventions
document
* Specify documentation, review, and approval process
 Fall 2006 – John Pfister
62
Software Documentation
• Evaluation Criteria:
* Does the seller have an overall plan for
documentation preparation?
* Does the seller have a standards and conventions
document that includes procedures for preparing
documentation?
* Does the seller understand the use of
documentation to support development?
* Are seller tailoring and scaling recommendations
consistent with the requirements of the
development?
* Does the seller demonstrate experience with
documentation preparation?
 Fall 2006 – John Pfister
63
Engineering Data Management
• All individual bits of information that hold
•
•
together the engineering process
Must be properly recorded
Includes the information in engineering
notebooks and software development
folders
 Fall 2006 – John Pfister
64
Engineering Data Management
• Requirements - The buyer should require
the seller to describe:
* The methods that will be used to record, store,
and control engineering data
* The management of engineering data in the SDP
* How data generated will be used to support the
processes of development from analysis
through document preparation
 Fall 2006 – John Pfister
65
Engineering Data Management
• Evaluation Criteria:
* Does the seller understand the importance of
engineering data to the development process?
* Does the seller have a plan to mange
engineering data?
* Does the seller understand the use of software
development folders to house engineering data
throughout the project?
* Does the seller provide for the integration of
engineering data with the documentation
products of the development effort?
 Fall 2006 – John Pfister
66
Configuration Management (CM)
•
•
•
•
CM Plan
Organization
Tools
Personnel
 Fall 2006 – John Pfister
67
Configuration Management
• Requirements - the buyer should require
the seller to:
* Have a CM plan or develop one for the project.
If the CM plan will not be delivered with the
proposal, require the seller to address CM
capabilities in the proposal.
* Assign experienced personnel to perform CM on
the project.
* Use a modern library management system.
* Have CM procedures that will support control of
the products of development throughout the
life cycle and not only the formal baselines
invoked by the buyer.
 Fall 2006 – John Pfister
68
Configuration Management
• Evaluation Criteria:
* Does the seller have an in-place function for CM?
Does it have the capability to ensure sound CM
practice?
* Does the seller have a company-wide CM plan and CM
procedures? Are they used across the board?
* Does the seller have experienced CM personnel?
* Does the seller intend to use an automated tool for
CM? Do CM personnel have experience with the
tool?
* Do the seller's internal procedures for CM include
provisions for generating status accounting reports
for managing changes?
 Fall 2006 – John Pfister
69
Quality Assurance
IEEE: "To provide adequate confidence that
the item or product conforms to
established technical requirements"
• Organization
• Procedures
• Personnel
 Fall 2006 – John Pfister
70
Quality Assurance
• Requirement - The buyer should require
the seller to:
* Have an independent organization perform QA
for the development project.
* Have existing procedures for the conduct of
QA.
* Prepare a software quality assurance plan for
the project.
 Fall 2006 – John Pfister
71
Quality Assurance
• Evaluation Criteria:
* Does the seller management actively support the
QA function?
* Does the QA function report independent of the
project management team and is it integrated into
the oversight management process?
* Does the QA manager assigned to the project
enjoy independent reporting within the seller
organization?
* Does the seller have internal procedures that
address the conduct of reviews, audits, and
inspections?
* Does the seller have qualified personnel?
* Does the seller have an existing QA plan? Has it
been
72
 Fall 2006 – John
Pfister used on prior projects?
Assessment (Metrics)
•
•
•
•
•
•
Oversight Management
Test and Evaluation
Reviews and Audits
Management Indicators
Schedule
Clean Room Activity
 Fall 2006 – John Pfister
73
Oversight Management
• Requirements - the seller should describe
how:
1. The organization provides oversight
management of the development project.
2. It provides the buyer visibility into and control
over the project.
• Evaluation Criteria:
1. Does the project manager have the
responsibility and commensurate authority to
report on the development project?
2. Does the organization display an interest in the
project? Will high-level managers be
interested and involved?
 Fall 2006 – John Pfister
74
Test and Evaluation
System
Reqmts
Static analysis testing
Design
Software
Reqmts
Analysis
Preliminary
Design
Dynamic testing
Detailed
Design
Qualification
requirements
stated
Code and
Unit Test
Informal
testing
Test
reviews
Testing
Detailed
test procedures
75
Test &
Integration
System I&T
Formal
testing
Software
test plan
 Fall 2006 – John Pfister
Test & Int
Test requirements
incorporated into
design specifications
Test concept
in software
development
plan
Subsystem
Test
results
Test and Evaluation
• Requirements - the buyer should require the
seller to:
* Describe the testing process that will be
employed in the project.
* Relate the testing process to the overall
development process by:
•
•
•
•
Addressing test requirements and design specifications,
Addressing testing processes and methods in the SDP,
Preparing adequate software test documentation, and
Explaining the relationship between the testing process
and the other processes of the development (such as
QA).
 Fall 2006 – John Pfister
76
Test and Evaluation
• Requirements - the buyer should require
the seller to:
* Describe the internal testing function and how
it will be employed in development testing.
* Explain the relationship of the testing function
to testing conducted by the development team.
* Explain the function for formal testing and its
independence from the development team.
* Specify the testing environment that will be
employed.
* Identify testing personnel and experience
levels.
 Fall 2006 – John Pfister
77
Test and Evaluation
• Evaluation Criteria:
* Does the seller have an identifiable test
function? Does the test environment contain
the necessary tools and procedures? Do test
personnel have experience with these tools and
procedures?
* Does the location of the testing function in the
seller organization ensure independence of
testing?
* Does the seller demonstrate an understanding
of the importance of test documentation and
the integration of test requirements into the
project requirements and design specifications?
 Fall 2006 – John Pfister
78
Reviews and Audits
• Requirements - the seller must:
* Perform internal reviews of the products and
processes of the development project. These
should include formal and informal reviews and
inspections of the products and audits of
functional processes such as QA and CM.
* Describe procedures for conducting reviews in
the SDP.
 Fall 2006 – John Pfister
79
Reviews and Audits
• Evaluation Criteria:
* Does the seller have an existing methodology
for software development? Does that
methodology include detailed procedures for
conducting both formal and informal reviews,
audits, and inspections?
* Do seller personnel have experience in the
conduct of reviews, audits, and inspections?
 Fall 2006 – John Pfister
80
Management Indicators
• Requirements - the buyer should require
the seller to:
* Select a set of appropriate management
indicators for use on the project, or
alternatively, impose a selected set of
indicators on the seller.
* Evaluate the selected set and recommend
changes.
 Fall 2006 – John Pfister
81
Management Indicators
• Evaluation Criteria:
* Does the seller understand the indicators
selected and have experience in their
application?
* Is the selected set appropriate for the effort?
* Does the seller display the expertise required
to use the management indicators?
* Has the seller demonstrated the ability to
collect data to support the indicators and to
effectively apply the results to the
management assessment process?
 Fall 2006 – John Pfister
82
Schedules
• Requirements - the buyer should require
the seller to:
* Provide a detailed schedule using a suitable
scheduling technique such as milestone or Gantt
charts to provide timely visibility into
development progress.
* Show how this schedule is integrated into the
scheduling methods used on the project.
 Fall 2006 – John Pfister
83
Schedules
• Evaluation Criteria:
* Does the seller understand the need for
presenting detailed schedule information and is
that information tied to detailed project tasks?
* Does seller oversight management employ these
types of schedules as a normal part of
management responsibility?
* Are schedule needs and types described in the
SDP?
 Fall 2006 – John Pfister
84
Clean Room Activity
• Requirements - the buyer should require
the seller to:
* Provide a central location to track events in a
project
• Evaluation Criteria:
* Does the seller employ a clean room for the
management of projects?
* Has the clean room been used on previous
projects?
* Is the clean room used by all project personnel
in an effective and honest manner?
 Fall 2006 – John Pfister
85
Seller Organization Types
• Matrix (Functional) Organization
• Project Management Organization
• Hybrid
 Fall 2006 – John Pfister
86
Matrix (Functional) Organization
NEW SYSTEMS
ENGINEERING
PROGRAM A
PROGRAM B
Sys Eng
Sys Eng
Sys Eng
Elec Eng
Elec Eng
Elec Eng
Mech Eng
Mech Eng
Mech Eng
S/W Eng
S/W Eng
S/W Eng
 Fall 2006 – John Pfister
87
Seller Organization
• Requirements - the buyer should require
the seller to:
* Describe the project organization and its
relationship to all supporting functional
activities; e.g., CM.
* Explain the degree of authority and
responsibility of the project manager.
* Explain internal reporting on the project.
* Explain how supporting functions (QA, CM) will
support the project.
 Fall 2006 – John Pfister
88
Seller Organization
• Evaluation Criteria:
* Does the project manager have direct control
over personnel needed to implement the
project?
* Does the project manager have reporting
responsibility to a high enough level to ensure
control of the project?
* Is this reporting level commensurate with the
importance of the project?
* Does the reporting level suggest that the
project will receive adequate review by seniorlevel managers within the seller organization?
 Fall 2006 – John Pfister
89
Chapter 5 - Contracts and Contract Law
• Contract: A set of promises, the breach of which is
•
•
provided a remedy by law.
Agreement: Encompasses promises the law will
enforce as well as those the law will not enforce.
Essential elements of a contract:
*
*
*
*
*
At least 2 parties, each with legal capacity to act
By offer and acceptance, the parties agree to terms
Consideration of value exchanged
Provisions for redress
Enforceable by law
 Fall 2006 – John Pfister
90
Contracting Terms
• Contracting Authority
* Contracting officer - authorized to enter into, administer, and
make changes to or modify the contract
* Contracting officer's representative - authorized representative
of the contracting officer to provide technical direction,
approval, and/or surveillance of the technical requirements of a
contract
• Contract Changes
* Contract order - unilateral action in accordance with a contract
provision
* Contract modification - an alteration in the specification, delivery
point, rate of delivery, contract period, price, quantity or other
contract provision
 Fall 2006 – John Pfister
91
Basic Principles
• Contract terms and conditions - qualifies the
promises to perform.
• Divisibility - parties to a contract may divide their
respective performances into installments or
separate units.
• Substantial performance - if the seller only partially,
but the performance is substantial, the buyer can
seek remedies only for partial damages, not the full
contract price.
• Discharge of contracts - the obligations incurred by
buyer and seller when they entered into agreement no
longer exist to bind performance.
 Fall 2006 – John Pfister
92
Fixed-Price Contracts
• Firm fixed-price
• Fixed-price with economic price
•
•
adjustment
Fixed-price incentive
Fixed-price redetermination
 Fall 2006 – John Pfister
93
Firm-Fixed Price
• Fixed price upon delivery of specified
•
•
goods or services
Requirements must be well understood
All risk assumed by the seller
 Fall 2006 – John Pfister
94
Fixed Price with Economic Price Adjustment
• Same as the firm fixed-price contract, but
•
•
•
with an additional clause
Adjustment in the price may be adjusted
up or down depending upon some specified
economic factor
For example: If heavy travel required over
multiple years, cost of airfare may be
factored in to the price
Most risk assumed by the seller, but some
shared risk
 Fall 2006 – John Pfister
95
Fixed-Price Incentive
• Same as the firm fixed-price contract, but with an
•
•
additional clause
A factor is specified to motivate the seller to
reduce overall cost, deliver early, or improve
overall performance
For example: Instead of a fixed-price, a not-toexceed-cost plus fee is agreed to
* Any savings or are split between the Seller and Buyer
according to an agreed upon ratio; i.e., the Seller’s fee
can be increased by some percentage of the cost savings
* Cost overruns are not allowed
 Fall 2006 – John Pfister
96
Fixed-Price Redetermination
• Provides a means for shifting some
•
•
indeterminable risks from the seller to the
buyer after the initial price is negotiated
Factors to be used in adjusting the price
must be negotiated up front
For example: This could be used when the
requirements are not firm; firm price to
develop the requirements with a tentative
price for the project; renegotiate final
price as the uncertainty is cleared up
 Fall 2006 – John Pfister
97
Fixed-Price Contracts
FFP
FPEPA
FPI
FPR
Applicability
• Firm design &
•
•
• Possibility of cost
Market & labor
requirements
conditions are
unstable for
Adequate
competition exists extended time
period
Reasonable price
& cost
comparisons exist
reduction
• Performance
improvements
possible
• Firm target price
& profit can be
negotiated
• Realistic price
cannot be
estimated at start
• Realistic price for
later time periods
cannot be
estimated
Essential Elements
• Buyer/Seller must
agree to fixed
price at inception
• Fair and
reasonable price
can be estimated
at inception
 Fall 2006 – John Pfister
• Established price
• Ceiling on upward
•
adjustment
Downward
adjustment
reasonable
• Target cost
• Target profit
• Price ceiling
• Profit adjustment
formula
• OK accounting
system
98
• Ceiling price or
initial price fixed
• Agreement to
renegotiate &
redetermine price
• OK accounting
system
Fixed-Price Contracts
FFP
FPEPA
FPI
FPR
Variable fee
employed to control
cost
Reduced cost risk in
the renegotiated
areas
Cost Risk
All of the cost risk
assumed by seller
Reduced cost risk in
the adjustment
areas
Approvals
Contracting officer
If adjustments
more than 10%,
higher-level
approval may be
needed
Contracting officer
Contracting officer
Strengths/Weaknesses
• Minimum
management
burden
• Minimum
administrative
burden
 Fall 2006 – John Pfister
• Minimum
Increased
administrative
burden
management
burden
• Minimum
administrative
burden
99
Even more
administrative and
management burden
Cost-Reimbursable Contracts
•
•
•
•
Cost
Cost
Cost
Cost
and cost sharing (CS)
plus incentive fee (CPIF)
plus award fee (CPAF)
plus fixed fee (CPFF)
 Fall 2006 – John Pfister
100
Cost and Cost-Sharing
• Seller receives no fee
• If a cost contract, seller is reimbursed for
•
all allowable costs
If a cost-sharing contract, seller and buyer
split the allowable costs in some redefined
ratio
 Fall 2006 – John Pfister
101
Cost Plus Incentive Fee
• Incentive fee is structured to motivate the
•
•
seller to control costs
Negotiations set a target cost, a ceiling
price, and an adjustment formula
Minimum and maximum fees are
established and related to performance
goals
 Fall 2006 – John Pfister
102
Cost Plus Award Fee
• Buyer establishes a number of
•
•
•
•
performance criteria that are difficult to
measure quantitatively
Incentives are structured based on
subjective evaluation of these factors
There is a base fee and the incentives
Maximum profit is typically structured
higher than in CPIF contracts
Award fees typically follow a periodic
evaluation
 Fall 2006 – John Pfister
103
Cost Plus Fixed Fee
•
•
•
•
•
Seller reimbursed for all allowable costs
Profit is the fixed fee on top of the costs
Normally used on R&D projects
A cost ceiling may be specified
Risk is assumed by the buyer
 Fall 2006 – John Pfister
104
Cost-Reimbursable Contracts
CS
• Uncertainties in
•
•
performance and
estimates
Research and
development
jointly sponsored
Research and
development done
with a nonprofit
organization
CPIF
Applicability
• Uncertainties in
 Fall 2006 – John Pfister
• Uncertainties in
performance and
estimates
• Performance
improvements
possible
• Cost/schedule
improvement
possible
• Variable fee can
provide incentives
• Predetermined cost •
for both
•
buyer/seller
•
• No fee
•
• OK accounting
•
system
CPAF
performance and
estimates
• Performance
improvements
possible
• Measurements of
improvements
subjective
• Variable fee can
provide incentives
Essential Elements
Target cost
Target fee
Min/maximum fee
Fee adjust formula
OK accounting
system
105
• Estimated cost
• Base fee
• Maximum fee
• Award fee criteria
• OK accounting
system
CPFF
• Uncertainties in
performance and
estimates
• Research and
development where
the job cannot be
defined and the
level of effort is
not known initially
• Estimated cost
• Fixed fee
• OK accounting
system
Cost-Reimbursable Contracts
CS
CPIF
CPAF
CPFF
Variable fee
employed to control
cost and
performance
Seller responsibility
for managing cost
Cost Risk
Self-motivated to
control cost and
performance
Variable fee
employed to control
cost and
performance
Approvals
Head of contracting
Contacting officer
Contracting officer
Contracting officer
Strengths/Weaknesses
Hard to get parties
to agree
 Fall 2006 – John Pfister
• Management
• Most difficult to
burden high
• Administrative
burden high
administer
• Difficult to derive
award fee and to
manage
106
• No incentives
provided to control
cost
• Administrative
burden high
Other Contractual Devices
•
•
•
•
Time and materials contract (T-M)
Letter contract (LC)
Indefinite-delivery contract (IDC)
Basic ordering agreement (BOA)
 Fall 2006 – John Pfister
107
Time and Materials
• Buyer pays seller a fixed rate per hour plus
•
•
all allowable costs; e.g., material, travel,
etc.
Suitable when cost of work cannot be
estimated
Typically used for engineering services,
repair, maintenance, and overhaul work
 Fall 2006 – John Pfister
108
Letter Contract
• Preliminary contractual instrument
• Permits the seller to begin work while
•
details of the contract are worked out
Used only when a definitive contract
cannot be negotiated in time to satisfy the
buyer’s requirement
 Fall 2006 – John Pfister
109
Indefinite-Delivery Contract
• Used when the exact delivery date is
•
•
unknown
Provides for delivery of a known quantity
within a contract period
Price is known
 Fall 2006 – John Pfister
110
Basic Ordering Agreement
• A BOA is not a contract
• Provisional agreement whereby buyer and
•
•
seller agree on the services or supplies to
be ordered in the future and prices to be
paid or how the prices will be determined
Terms and conditions for the future
contract are known
Used to minimize paperwork when a buyer
anticipates a large number of orders with
the same seller
 Fall 2006 – John Pfister
111
Other Contractual Devices
T-M
• Initially not
•
possible to
estimate the
extent or duration
of the job
Applicable to
design or eng.
services and
maintenance and
repair
• Direct labor rate
fixed
• Burden and fee
negotiated
• Ceiling price
established
• OK accounting
system
 Fall 2006 – John Pfister
LC
IDC
BOA
• Schedule for
• Multiple jobs
Applicability
• Requirements are
such that
commitment is
needed for work to
start immediately
• Cost/schedule
estimates can be
derived in the
future
delivery may be
unknown
• Quantity may be
unknown
• Requirements may
need to be defined
during start-up
Essential Elements
• Maximum liability
•
•
spelled out
As many contract
provisions defined
as possible
OK accounting
system
112
• Provisions for
specifying time,
amount, and req
identified
• Min and max order
quantities
• OK accounting
system
contemplated,
which can be
combined for ease
of overall
administration
under a single
agreement
• Economies of scale
exist
• Estimated cost
• Estimated fee
• OK accounting
system
Cost-Reimbursable Contracts
T-M
LC
IDC
BOA
Cost Risk
Task orders used as
minicontracts to
control cost
Cost could grow
during negotiations
Variable fee
employed to control
cost and
performance
None – not a
contract
Approvals
Contracting officer
Head of contracting
Contracting officer
Head of contracting
Strengths/Weaknesses
• Constant
surveillance
needed
• Management
burden high
 Fall 2006 – John Pfister
Need to get under
contract as soon as
possible
113
• Easy to administer • Do not have to
if fixed-price
• Management
burden high
compete jobs
• Still have to make
contract
Contract Selection Considerations
• The degree of competition present
• The availability of comparative data for
•
•
•
•
use in evaluating the contractor's offer
The volatility and difficulty of the
requirements
The urgency of the requirements
The degree of risk involved in meeting the
requirements
The difficulty in measuring performance
during the contract
 Fall 2006 – John Pfister
114
Contract Selection Considerations
• The extent and nature of subcontracting
•
•
contemplated
The size of the contract
The seller's experience
 Fall 2006 – John Pfister
115
Contract Clauses
• Labor clauses
• Socioeconomic clauses
• Patent right, copyright, and trade secret
•
•
clauses
Rights in technical data and computer
software clauses
Other clauses
*
*
*
*
*
Conflict of interest
Key personnel replacement
Use of facilities and/or equipment
Cost accounting standards
Warranty
 Fall 2006 – John Pfister
116
Other Related Contracting Topics
• Federal Acquisition Regulations (FARs)
• Contract Administration and Termination
* Performance Measurement
* Contract Modifications
* Contract Termination/Close-out
 Fall 2006 – John Pfister
117
Performance Measurement
• Seller is primarily responsible for the timely and
satisfactory performance of the contract requirements
• Buyer must relate technical performance to schedule
and cost status
• Key buyer activities are:
* Maintaining visibility into, communications with, and control over
the seller’s work
* Handling disagreements with the seller in a professional
manner, calling in specialists, when warranted, to mediate
problems
* Analyzing cost, schedule, and technical performance
quantitatively and determining if variances are within
acceptable bounds
* Monitoring costs, both direct and indirect,and taking action
when they seem to be getting out of hand
* Learning about the seller’s systems and procedures and using
them to supply necessary management information
 Fall 2006 – John Pfister
118
Contract Modifications
• Contract changes should be expected
• Contract changes should be processed and
•
implemented in a timely manner
Change proposals can be made by either the
buyer or the seller
* Sometimes a change control board is established
to handle them
* Changes that are within the scope of the original
contract don’t require a new contract
• Some contracts permit the buyer to make
certain types of changes unilaterally
 Fall 2006 – John Pfister
119
Contract Termination
• Termination for convenience
* May occur at any time during the contract even when the
seller is performing satisfactorily
* Buyer obliged to compensate seller for work completed
to date as well as the costs of termination
* Seller is entitled to reasonable profit
• Termination for default
* Occurs when the seller fails to perform satisfactorily
* Buyer obliged to put the seller on notice of default
* If a fixed price contract, seller may be liable for cost of
purchasing replacement goods and services
* If a cost-reimbursement contract, seller may be entitled
to all allowable costs incurred up to termination and not
liable for the repurchase costs
 Fall 2006 – John Pfister
120
Contract Closeout
Independent of how the contract was terminated:
• Overhead rates may need to be finalized
• Incentive and award fees may need to be
computed
• Excess property needs to be disposed of
• Patent disclosures need to be made
• Claims need to be released
• Equipment needs to be returned
• Excess funds need to be de-obligated
• Seller performance needs to be documented
 Fall 2006 – John Pfister
121
Other Legal Issues
• Copyrights
• Software Patents
• Trade Secrets and Confidentiality
•
•
Agreements
Employee Non-Competition Agreements
Software Liability Issues
 Fall 2006 – John Pfister
122
Software Copyright Law
• U. S. Constitution, Article I, Section 8: “The
•
Congress shall have Power … To promote the
Progress of Science and useful Arts, by
securing for limited times to Authors … the
exclusive Right to their Writings.”
Copyright Act provides the legal right to
control:
*
*
*
*
*
Reproduction
Distribution
Creation of adaptations
Public display
Public performance
 Fall 2006 – John Pfister
123
Software Copyright Law (Continued)
• The purpose of copyright law is to
•
encourage creation and expression by
granting a legal monopoly for a new "work";
e.g., a book, song, or computer program.
References:
* Software Development – A Legal Guide,
Stephen Fishman, 1998.
* Copyright Your Software, Stephen Fishman,
1998
 Fall 2006 – John Pfister
124
Software Copyright Law (Continued)
• 1980 Amendment extended coverage to
computer programs.
* "Computer program" - a set of statements or
instructions to be used directly or indirectly in a
computer in order to bring about a certain result.”
(17 U.S.C. 101)
* Grants exclusive rights to the particular
expression that constitutes the work.
* Does not extend to "any idea, procedure, system,
method of operation, concept, principle, or
discovery" underlying the program.
 Fall 2006 – John Pfister
125
Software Copyright Law (Continued)
• Requirement of originality
* Level of originality "very slight" or "minimal"
* Independent creation
• Copyright not only protects all forms of
computer code, but may extend to:
* Program design documents
* Supporting materials such as users’ manuals,
documentation, etc.
* The way a program itself is structured,
sequenced, and organized
* A program’s user interface; i.e., the look and
feel
 Fall 2006 – John Pfister
126
Software Copyright Law (Continued)
• Major limitation on copyrights:
* Only protects the particular form that a
program, book, manual, record, screen, script,
etc. takes.
* It does NOT protect the ideas or concepts
contained within it.
 Fall 2006 – John Pfister
127
Software Copyright Law (Continued)
• For works published after 1 January
•
1978 and before 1 March 1989, the
author was permitted up to 5 years to
register the copyright and a reasonable
effort had to be made to add a valid notice
to all copies
For works published on or after March 1,
1989, a copyright notice is NOT required
* Software is "published" when it is first put into
general distribution or public sale
* Private showings to friends, investors, or
publishers is not publication
 Fall 2006 – John Pfister
128
Software Copyright Law (Continued)
• Must you register your software copyright?
* Registration NOT required, but recommended
* Copyright is secured automatically when program
is recorded in some solid form (e.g., printout,
diskette, or ROM chip) for the first time
* All works published before 1978 had to contain a
valid copyright notice
• Failure to provide the notice resulted in automatic loss
of copyright protection
• Exception was where the copyright was omitted on a
very few copies
 Fall 2006 – John Pfister
129
Software Copyright Law (Continued)
• A copyright notice must contain three parts:
* The word “Copyright,” the abbreviation “Copr.,” or a

* The year the work was first published
* The name of the copyright owner
• Why register?
* Registration with the U. S. Copyright Office is
required to bring a lawsuit to enforce your copyright
* Registration protects your copyright by making it
public record
* Timely registration makes it easier to win money in
court
 Fall 2006 – John Pfister
130
Software Copyright Law (Continued)
• When to register
* Must register within prescribed time periods
to receive benefit of statutory damages and
attorney fees in infringement suits
* Prescribed time for published works is:
• Within 3 months of the date of the first publication
or
• Before the date the copyright infringement began
* Prescribed time for unpublished works is:
• Before the infringement occurred
 Fall 2006 – John Pfister
131
Software Copyright Law (Continued)
• How long is your software protected by a
copyright?
* AFTER 1977:
• Software developed as "work for hire" is protected for 75
years from date of publication or 100 years from creation,
whichever is shorter
• Software developed by an individual is for life of author
plus 50 years
• Software developed jointly by several authors is, for life of
the last surviving author plus 50 years
* BEFORE 1978, BUT AFTER 1964:
• 75 years from date of publication
* BEFORE 1964:
• Initially, a 28-year term
• Additional 47-year term IF a renewal application filed
during the 28th year 132
 Fall 2006 – John Pfister
Software Copyright Law (Continued)
• Most computer programs or code can be
•
described using general descriptive terms
like, “entire text of computer program with
accompanying documentation.”
Other acceptable terms include:
Computer software
Text of program
Routine
Program instructions
Entire program
Wrote program
Subroutine
Entire program code
Entire work
Program listing
Software
Computer program code
Entire text
Program text and screen displays
Text of computer game
Program text
Module
Reference: Software Development, A Legal Guide, Stephen Fishman, Jan 1998.
 Fall 2006 – John Pfister
133
Software Copyright Law (Continued)
Some unacceptable terms are:
Algorithm
Analysis
Cassette
Chip
Computer game
Disk
Encrypting
Eprom
Firmware
Format
Formatting
Functions
Language
Lay-out
Logic
Menu screen
Mnemonics
Printout
Programmer
Prom
Rom
Software methodology
Structure
Sequence
Organization
System
System design
Text of algorithm
Reference: Software Development, A Legal Guide, Stephen Fishman, Jan 1998.
 Fall 2006 – John Pfister
134
Software Copyright Law (Continued)
• Ownership rights may be transferred by
way of either licenses or assignments:
* Licensing means that one person or company is
granting someone else permission or license to
use the software under specified conditions.
• Exclusive Licenses
• Nonexclusive Licenses
* Assignment means a transfer of all the rights a
person owns in a piece of property.
 Fall 2006 – John Pfister
135
Software Copyright Law (Continued)
• Examples of contractual arrangements to
exploit your copyrights:
* Software Assignments - Copyright owner
transfers all ownership rights to a new owner.
* Software Development Agreements Developer agrees to create software to
specifications and then to transfer or license
the copyright to another party.
* Software Publishing Agreements - Developer
grants to a publisher a license to duplicate and
market the copyrighted software. The
publisher makes royalty payments to the
developer.
 Fall 2006 – John Pfister
136
Software Copyright Law (Continued)
• Examples of contractual arrangements to
exploit your copyrights:
* Software Distribution Arrangements - Owner
of copyrighted software makes an arrangement
with a distributor to sell the software. The
distributor gets the right to grant licenses to
users.
* End-User Agreements - End-user is granted a
license to use, but not to sell the software
product.
 Fall 2006 – John Pfister
137
Software Copyright Law (Continued)
• Some important principles:
* Principal of First Sale - Once you sell a copy of
a copyrighted work, you cannot forbid or
control the resale of the copy.
* Sale of a copy does not transfer copyright
ownership.
* The author, or the author’s heirs, may
terminate a copyright transfer made after
1977, after 35 years without paying anything.
 Fall 2006 – John Pfister
138
Software Copyright Law (Continued)
• Rights of ownership of software copies:
*
*
*
*
*
*
Unlimited use rights
Right to copy the program into computer RAM
Right to make archival copies
Right to sell or give away the program
Adaptation right
Reverse engineering
 Fall 2006 – John Pfister
139
Software Copyright Law (Continued)
• Things owners of software copies can’t do:
* No copies other than back-up and RAM copy
* Copy can only be used on a single computer at a
time
* No running the software on computer networks
* No software rentals or lending
* No derivative works
 Fall 2006 – John Pfister
140
Software Copyright Law (Continued)
• Scope of Protection Under Copyright Law
* Software is fundamentally different than other
copyrighted items; e.g., object code, source code,
structure, not all visible to user
* Object and source code are clearly protected by
the law -- even parts of the code are protected
* Criminal prosecution is possible, but unlikely
* Copy protection locks in code seldom used any more
-- "salting" program with non-functional code is used
* External characteristics of program (screens,
keystrokes, etc.) are also protected by copyrights sometimes called the "non-literal elements" - Lotus
Versus Quattro
 Fall 2006 – John Pfister
141
Software Copyright Law (Continued)
• Copyright Act forbids extending copyright
protection to any "idea" or "concept."
* Test is one of "substantial similarity"
* Author had access
* Can't consider elements copied from public
domain
• "Derivative work" - based on another work
• "Thin" copyright protection for databases
 Fall 2006 – John Pfister
142
Software Copyright Law (Continued)
• Limits on Software Copyright Protection
* No protection for functional elements inherent
in the idea of the application
* No protection for commonly used software
elements
* No protection for use of interfaces and file
formats needed for compatibility
* Duplicating without copying - "Clean Rooms"
* No protection for some intellectual property
• Inventions [Patent Law]
• Product Names [Trademark Law]
• Secret technology and techniques [State Trade
Secret Laws]
 Fall 2006 – John Pfister
143
Software Copyright Law (Continued)
• The Gray Areas
* Uncertain protection for the internal structure
of a program
* Unresolved question of reverse engineering
* Doctrine of "fair use"
* Creating "near clones"
 Fall 2006 – John Pfister
144
Software Copyright Law (Continued)
• Examples of fair use include:
* Library’s Special Rights
• Archiving lost, stolen, damaged or deteriorating works
• Making copies for library patrons
• Making copies for other libraries’ patrons
(interlibrary loan)
* Performances and Displays in Face-to-Face
Teaching and Broadcasts
• Educational institutions
• Governmental agencies
 Fall 2006 – John Pfister
145
Software Copyright Law (Continued)
• Other examples of fair use include:
* Quotations or excerpts in a review or criticism
for purposes of illustration or comment.
* Quotation of a short passage in a scholarly or
technical work for illustration or clarification
of the author’s observation.
* Use in a parody of some of the content of the
work parodied.
* Summary of an address or article, with brief
quotations, in a news report.
 Fall 2006 – John Pfister
146
Software Copyright Law (Continued)
• Other examples of fair use include:
* Reproduction by a library of a portion of a work
to replace part of a damaged copy.
* Reproduction by a teacher or student of a small
part of a work to illustrate a lesson.
* Reproduction of a work in legislative or judicial
proceedings or reports.
* Incidental and fortuitous reproduction, in a
newsreel or broadcast, or a work located at the
scene of an event being recorded.
Reference: Software Development, A Legal Guide, Stephen Fishman, Jan 1998.
 Fall 2006 – John Pfister
147
Software Copyright Law (Continued)
• Fair Use Tests
*
*
*
*
What is the character of the use?
What is the nature of the work to be used?
How much of the work will you use?
What effect would this use have on the market
for the original or for permission if the use were
widespread?
Reference: Software Development, A Legal Guide, Stephen Fishman, Jan 1998.
 Fall 2006 – John Pfister
148
Software Copyright Law (Continued)
• Congress specifically authorized two fair
uses that relate to computer programs:
* “An essential step in the utilization of the
computer program in conjunction with a machine
and that it is used in not other manner.”
* The copy of adaptation is for archival purposes
only (a single back-up copy) and is made and kept
only by the person who owns the legally purchased
copy. (17 U.S.C. 117)
 Fall 2006 – John Pfister
149
Software Copyright Law (Continued)
• The Federal appeals court held that
disassembly of object code (reverse
engineering) is fair use if:
* It is the only means available to obtain access to
the unprotected elements of a computer program
(ideas, functional principles, etc.) and,
* The copier has a legitimate reason for seeking
such access.
Sega Enterprises, Ltd. V. Accolade, Inc., 977 F.2d 1510 (9th Cir.
1992)
 Fall 2006 – John Pfister
150
Software Copyright Law (Continued)
• Criminal liability for infringement (a Federal
crime):
* Willful infringement not for financial gain:
• If retail value greater than $1000 and less than $2500 – up
to one year of imprisonment and up to $100,000 fine
• If ten or more copies with retail value equal to or greater
than $2500 – up to three years of imprisonment and up to
$250,000 fine
* Willful infringement for financial gain:
• If less than ten copies with retail value less than $2500 –
up to one year of imprisonment and up to $100,000 fine
• If ten or more copies and over $2500 – up to five years
imprisonment and up to $250,000 fine
• Jail time can be increased to 10 years for second offense
 Fall 2006 – John Pfister
151
Software Copyright Law (Continued)
• Collecting damages from infringement law suits:
* Actual damages – lost profits and/or other losses
sustained as a result of the copyright infringement
* Statutory damages – requires no proof of any actual
loss
• If infringer did not act willfully or innocently, between
$500 and $20,000 for all infringements by a single
infringer for a single work
• If infringer acted willfully, the penalty can be up to
$100,000
• If infringer acted innocently, the judge has discretion to
award as little as $200 – can’t claim this if work had a valid
copyright notice
• Statute of limitations is generally 3 years
 Fall 2006 – John Pfister
152
Software Patents
• Generally, at least a 14-year exclusive right
•
•
granted by the federal government to
exploit an invention
Patents can cover "any process, machine,
manufacture or composition of matter"
Patent law treats software as a "process" or
a "machine"
 Fall 2006 – John Pfister
153
Software Patents (Continued)
• United States Patent and Trademark
Office (PTO) grants a patent after
determining that the "process" or "device"
is:
* Useful
* Novel
* Not obvious to a skilled practitioner
• Supreme Court ruling opened up software•
related patents in 1981
IBM has the most software-related
patents - adding about 200 new software
patents each year
 Fall 2006 – John Pfister
154
Software Patents (Continued)
• Patents give the holder the right to
•
exclude others from making, using, or
selling devices that contain the invention.
Right of exclusion potentially serves three
purposes:
* Royalty income
* Exclusion of competition
* As a bargaining chip
 Fall 2006 – John Pfister
155
Software Patents (Continued)
• Software-related patents are a concern in
the intellectual property field because:
* The breath of patented software technology
* Independent creation is not a defense
* The difficulty of patent infringement
determinations
* Applications for patents are kept secret
* The expense of resisting claims
* The difficulty of determining "prior art"
 Fall 2006 – John Pfister
156
Software Patents (Continued)
• Large successful companies and companies
•
•
on leading edge of technology are most
likely to be targets of patent infringement
claims
Small, start-up companies and companies
with more mundane technologies are less
likely to be targets of patent infringement
suits
Patent litigation is very expensive - $1520K per month for about two years
 Fall 2006 – John Pfister
157
Software Patents (Continued)
• When the court finds patent infringement, it
can:
* Award damages (triple for intentional infringement)
* Issue court order to prevent further infringement
* Award attorney fees if intentional infringement
• The following factors should be considered in
deciding whether or not to seek a patent:
*
*
*
*
*
Originality
Marketability
Advancement over prior solutions
Will the technology stand the test of time
Are you willing to disclose the technology
 Fall 2006 – John Pfister
158
Software Patents (Continued)
• Types of Patents:
* Utility Patents are patents that have some
type of usefulness.
* Design Patents protect a device’s ornamental
characteristics.
* Plant Patents protect certain types of plants.
 Fall 2006 – John Pfister
159
Software Patents (Continued)
• Examples of Utility Patents:
* A process or method of getting something useful
done; e.g., genetic engineering procedure, a
manufacturing technique, or computer software.
* A machine (usually something with moving parts or
circuitry); e.g., cigarette lighter, sewage treatment
system, laser or photocopier.
* An article of manufacture; e.g., an eraser, tire,
transistor, or hand tool)
* A composition of matter; e.g., a chemical
composition, drug, soap, or genetically altered life
form.
* An improvement of an invention that fits within one
of the first four categories.
 Fall 2006 – John Pfister
160
Software Patents (Continued)
• Patent Duration and Expiration
* Utility Patents – 20 years after the date of
regular patent application.
* Design Patents:
• 14 years if filed on or after June 8, 1995
• If filed before June 8, 1995:
– 20 years from date of filing, or
– 17 years from date of issuance, whichever is longer
* A patent may expire if its owner fails to pay
required maintenance fees.
* Once a patent has expired for any reason, the
invention described by the patent falls into the
public domain.
 Fall 2006 – John Pfister
161
Software Trade Secrets
• Trade Secret - Information used in a
business that is held in confidence and
gives the business an advantage over its
competitors.
* Protected by state laws
* Generally two kinds of trade secrets:
• Technology - Legal protection for the secret in all its
various forms.
• Customer and other confidential commercial
information - sometimes considered like "confidential
information," but protection is the same in either
case.
 Fall 2006 – John Pfister
162
Software Trade Secrets (Continued)
• Trade secret protection not automatic -•
•
•
•
must be protected by reasonable security
measures
Trade secrets last as long as the
information remains secret and valuable
If trade secret disclosure is limited, the
trade secret may not be lost
If trade secret is published, trade secret
could be lost
Criminal prosecution is possible for theft
of scientific and technical data
 Fall 2006 – John Pfister
163
Software Trade Secrets (Continued)
• Examples of Reasonable Security Measures:
*
*
*
*
One person in charge of confidential measures
Controls on access to confidential data
Entry control and badges
Confidentiality legends on documents, code, and other
data
* Confidentiality agreements for employees
* Posted policy on confidentiality
* New employee orientation
* Exit interviews
* Restrictions on code and other data kept out of the
office
* Measures for confidential disclosure to other
companies
164
 Fall 2006 – John
Pfister
Employee Noncompetition Agreements
• Two categories of employees who may need to
be restricted:
* Employees who have access to trade secrets or
confidential information usually technical employees
* Sales employees who have gained customer loyalty
• Requirements of reasonable scope and duration
* Duration of non-competition agreements
* Geographic scope for employees holding trade
secret information
* Geographic scope for sales employees
• Governed by state laws
 Fall 2006 – John Pfister
165
Employment Agreements
• New employees should be asked to review
•
•
and sign employment agreement at time job
offer is made
Current employees must be given
something of value in return
Employee agreements for technical people
are more specific and complex than for
non-technical people
 Fall 2006 – John Pfister
166
Software Product Liability
• Increasing uses of software opens new areas of
risk:
*
*
*
*
*
*
*
Telecommunications
Bank and brokerage transactions
International currency transactions
"Program trading"
Air traffic control
Monitoring nuclear reactors
Designing buildings, bridges, etc.
• Exposure is greatest when software is used to
control sophisticated operations in safetycritical situations
Reference: CMU/SEI-93-TR-013, Software Product Liability, August 1993.
 Fall 2006 – John Pfister
167
Software Liability Strategies
• Investing in improved product quality - It is
•
•
•
•
•
far safer and less expensive to avoid the
problem than to attempt to limit damages
after the fact
Replacing defective software without delay
Using User documentation to limit liability
Using contract provisions to reduce liability
Liability insurance
Incorporate the business
 Fall 2006 – John Pfister
168
Types of Recovery
• Strict liability - that part of tort law that
•
•
covers damage caused by or threatened by
unreasonably dangerous products
Negligence - conduct that falls below the
standard established by law to protect persons
against unreasonable risk or harm
Warranty - contractually assure customers
that the products they buy will perform as
stated
 Fall 2006 – John Pfister
169
Strict Liability
• Courts have held that software can be a
•
•
•
product subject to the doctrine of strict
liability
Injured party does not have to prove
negligence
Injured party only has to prove that the
product was defective and that it caused
the loss
Contractual disclaimers, limitations of
remedies, and limited warranties are no
protection
 Fall 2006 – John Pfister
170
Negligence
• Area of greatest risk for organizations
•
•
•
•
•
with software-intensive products
Proof obligations for negligence can be
difficult
No need for actual or imminent physical
damage
Courts permit 3rd party suits
Large awards for physical damages;
enormous awards for economic losses
Contracts between corporations and
individuals may be judged to be
unconscionable; i.e., unequal parties
 Fall 2006 – John Pfister
171
Warranties
• Explicit limited warranties
• Implied warranties - Uniform Commercial
Code (UCC)
* Fitness for a specific purpose; i.e., software will
do what your customer said was wanted
* Merchantability; software must be of the
general kind described and reasonable fit for
the general purpose for which it was sold
 Fall 2006 – John Pfister
172
Software Product Liability
Personal
injury?
Property
damage?
Caused by a
product?
Was there a
contract?
Yes
No
Yes No
Prove
negligence?
Court uphold
contract?
Yes
Yes No
Failure to
perform?
No
Recover under
strict liability
Recover under
negligence
Yes
Recover under
warranty
No recourse
Reference: CMU/SEI-93-TR-013, Software Product Liability, August 1993.
 Fall 2006 – John Pfister
173
Can You Go to Jail?
• Copying Software for Fun and Profit?
* Copyright Act has criminal penalties
* Revised on December 16, 1997 to include cases
where there was no profit
• Viruses and Hacking?
* Computer Fraud Abuse Act of 1986 has criminal
penalties
* State laws
 Fall 2006 – John Pfister
174
Can You Go to Jail?
• Trade Secret Theft?
* Economic Espionage Act of 1986 provides
criminal penalties of up to $250,000 fine and
ten years in jail
* Trademark Counterfeiting Act of 1984 provides
penalties of $2 million fine and ten years in
prison for individuals, and $5 million fine for
corporations.
 Fall 2006 – John Pfister
175
Chapter 6 - Software Management Buyer’s Model
• Project Planning
• Important Considerations
• Project Management Office Roles and
•
•
•
Responsibilities
Performance Management and Assessment
Techniques
Engineering Support Contractors
IV&V Contractors
 Fall 2006 – John Pfister
176
Project Planning
•
•
•
•
•
•
•
•
•
Project Organizational Structure
Key Personnel Responsibilities
Standards and Methodologies
Documentation
Development Tools
Budget
Schedules
Staffing
Assessment, Customer Approval and
Certification
 Fall 2006 – John Pfister
177
Important Considerations
• Establishing Requirements
• Estimating Resources
• Risk Management Strategies
 Fall 2006 – John Pfister
178
Establishing Requirements
• Outline Example
• Requirements Characteristics
• Requirements Risks
• Requirements Risk Mitigation
The purpose of Requirements Management is to manage the
requirements of the project's products and product
components and to identify inconsistencies between those
requirements and the project's plans and work products.
Reference: CMMI-SW, V1.1
 Fall 2006 – John Pfister
179
Requirements Outline Example
Note: This outline is intended for use with the Rational Unified Process. The Software
Requirements Specification (SRS) captures the complete software requirements for the
system, or a portion of the system. This is a typical SRS outline for a project using only
traditional natural-language style requirements – with no use-case modeling.
1. Introduction
1.1
1.2
1.3
1.4
1.5
Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Overview
2. Overall Description
3. Specific Requirements
3.1 Functionality
3.1.1
<Functional Requirement One>
3.2.1
<Usability Requirement One>
3.3.1
<Reliability Requirement One>
3.2 Usability
3.3 Reliability
 Fall 2006 – John Pfister
180
Requirements Outline Example
3.4 Performance
3.4.1
<Performance Requirement One>
3.5.1
<Supportability Requirement One>
3.6.1
<Design Constraint One>
3.9.1
3.9.2
3.9.3
3.9.4
User Interfaces
Hardware Interfaces
Software Interfaces
Communications Interfaces
3.5 Supportability
3.6 Design Constraints
3.7 Online User Documentation and Help System Requirements
3.8 Purchased Components
3.9 Interfaces
3.10Licensing Requirements
3.11 Legal, Copyright and Other Notices
3.12Applicable Standards
4. Supporting Information
 Fall 2006 – John Pfister
181
Requirements Characteristics
• The DoD says that
• Another author says:
they should be:
* Correct
* Complete
* Compete
* Traceable
* Consistent
* Testable
* Unambiguous
* Consistent
* Verifiable
* Feasible
* Understandable
* Uniquely Identified
* Traceable
* Design Free
* Modifiable
In specifications, using the word “shall” indicates a binding provision;
i.e., one that must be implemented by the specification users. To
state non-binding provisions, use “should” or “may.” Use “will” to
express a declaration of purpose or to express future tense.
Military Standard Specification Practices, MIL-STD-490A, U.S. Department of Defense, 4 June 1985
 Fall 2006 – John Pfister
182
Requirements Risks
• But we gave you exactly what you asked for
• I know that I think I know what your requirements
•
•
•
•
•
•
•
are
Overboard assumptions
The expectations cloud
The never-ending requirements story
I don’t know what I want, but I’ll know it when I
see it
Rapid development requirements risks
Failure to recognize that faulty requirements
represent a risk
Can’t you read my mind?
“Requirements Risks Can Drown Software Projects,” CrossTalk, April 2002
 Fall 2006 – John Pfister
183
1995 DoD Software Study
 Fall 2006 – John Pfister
184
Requirements Risk Mitigation Strategies
• Develop and follow sound processes and
procedures
*
*
*
*
*
*
Requirements elicitation
Requirements analysis
Documentation of requirements
Requirements verification, review, and approval
Configuration control of requirements
Requirements traceability
• Incorporate requirements into all software
life cycles
 Fall 2006 – John Pfister
185
Requirements Risk Mitigation Strategies
• Provide training to those responsible for
•
•
•
•
•
requirements management
Require user involvement
Always document requirements
Validate software requirements
Hold formal requirements reviews
Strictly manage requirements changes
 Fall 2006 – John Pfister
186
Estimating Resources
• Accurate cost estimates very difficult
• Best estimate follows completion of design
• If cost risk too high, use prototyping or
risk-reduction phase to better understand
requirements and design
 Fall 2006 – John Pfister
187
Risk Management Strategies
• Different views of risk:
* To the end user -- risk involves suability and
performance
* To the buyer - risk involves budget and
schedule to meet contractual requirements
* To the seller -- risk involves meeting
contractual requirements while making a profit
* To the maintainer -- risk involves system
maintainability
 Fall 2006 – John Pfister
188
Risk Management Strategies
• Basic Risk Management Process:
*
*
*
*
Assessment
Analysis
Evaluation
Management
• Risk Management Plan Should:
* Identify risk
* Attempt to quantify impact
* Identify mitigation plans
 Fall 2006 – John Pfister
189
Program Management Office Roles and Responsibilities
•
•
•
•
•
•
•
•
•
•
Project Management
Engineering
Test
Training
Quality Assurance
Contract Administration
Program Control
Data Management
Interface Management
Logistics Support
 Fall 2006 – John Pfister
190
Performance Management & Assessment
•
•
•
•
•
•
•
Reviews
Schedules
Problem Reporting
Test
Independent Testing
Management Indicators
Documentation
 Fall 2006 – John Pfister
191
Reviews
• Generally two kinds of reviews:
* Formal -- should be structured around welldefined procedures and objectives and occur at
major project milestones; e.g., PDR, CDR, etc.
* Informal - generally not monitored by buyer
unless SQA is participating; e.g., code walkthroughs
 Fall 2006 – John Pfister
192
Schedules
• Generally two kinds of schedules:
* Gantt charts - top-level milestone chart
* PERT/CPM - detailed precedent-related event
chart
 Fall 2006 – John Pfister
193
Problem Management
• Management procedures should provide
for:
*
*
*
*
*
Review of the problem
Reporting
Status
Management
Correction
 Fall 2006 – John Pfister
194
Test
• To establish a test program, ensure that:
* The qualification requirements are incorporated
into early specifications
* The early planning documents cover the testing
program
* The development contractor has and will employ a
test environment that maintains the necessary tools
to support the testing program
* Long lead actions are identified and the seller has a
plan for implementing these actions
* A viable test organization with responsibility and
authority for conducting the program is in place
* There are appropriate checks on the testing
process
 Fall 2006 – John Pfister
195
Management Indicators
•
•
•
•
•
•
•
Memory utilization
Problem reports
Software size
Personnel stability
Development progress
Incremental release
Test progress
 Fall 2006 – John Pfister
196
Management Indicators
•
•
•
Goal-Question-Metric Paradigm
Define the goals that against which you
want to measure progress/performance
Define questions that have quantifiable
answers relate directly to the goals
Select metrics that provide quantitative
answers to the questions
Basili, V. R., and D. M. Weiss. "A Methodology for Collecting
Valid Software Engineering Data, " IEEE Transactions on
Software Engineering, Vol. SE-10, No. 3, pp. 728-738, Nov.
1984.
 Fall 2006 – John Pfister
197
Engineering Support Contractors
• Types
* Services Contractors
* System Engineering and Technical Assistance
(SETA) Contractors
* Independent Verification and Validation (IV&V)
Contractors
• Considerations
*
*
*
*
Technical Risk
Independent Testing
Management Support
Integration
 Fall 2006 – John Pfister
198
IV&V Contract
• Definition: An in-depth independent
assessment of the software development
process and an independent determination
of whether the developed system performs
all intended mission functions.
* Verification - ensures that the development
process in sound
* Validation - ensures that the products of
development meet operational requirements
 Fall 2006 – John Pfister
199
IV&V Contract
• The SOW should include:
* The buyer's intent to use an IV&V function to
monitor the development effort and assess the
utility of the operational product
* The specific objectives of the IV&V effort,
including, for example, identification of the
specific portions of the system to which IV&V
will be applied
* The authority of the IV&V contractor, for
example, in participation in reviews, access to
documentation, participation in testing, and
conduct of activities
 Fall 2006 – John Pfister
200
IV&V Contract
Use IV&V Contractors if:
System Characteristic
Development
Characteristics
High Risk
Low Cost
Med Risk
Med Cost
Low Risk
High Cost
Manned Systems
Yes
Yes
Maybe
Unmanned Remote
Systems
Yes
Yes
Maybe
Critical to Development
Yes
Maybe
No
Complex System
Maybe
Maybe
N/A
Data-Sensitivity
(privacy)
Yes
Yes
No
Commercial
(e.g., banking)
Maybe
No
No
 Fall 2006 – John Pfister
201
IV&V Contracts
• IV&V Cost Considerations:
* Two objections to use of IV&V contractors:
• Cost too much
• Unnecessary because the development contractor is
highly reputable and maintains an excellent
development environment
* Typical cost ranges from 10 - 30 % of
development cost
* Life cycle cost benefit based on cost avoidance
can make it a good investment
 Fall 2006 – John Pfister
202
Chapter 7 - Software Management
The Seller’s Model
• Project Management Office Roles and
Responsibilities:
*
*
*
*
Single point of contact
Achieve contract requirements
Control budget
Negotiate allocation of resources
• Organizational Approaches:
* Matrix
* Project
* Hybrid
 Fall 2006 – John Pfister
203
Project Manager Tasks
1. Interface Management
* Interface between internal and external organizations
* Coordinate activities
* Tap internal resources
2. Project Management
*
*
*
*
*
Plan and control work
Ensure all contractual requirements are addressed
Scope management controls
Provide leadership and direction
Encourage communications and teamwork
 Fall 2006 – John Pfister
204
Project Manager Tasks (Continued)
3. Resource Management
* Manage people, time, money, equipment, materials, information,
and technology
* Perform make/buy analysis
* Coordinate procurements
* Maintain a management reserve
* Monitors cost-to-complete and schedule-to-complete
4. Change Management
* Uses CCB to manage changes
* Negotiates changes with buyer
5. Risk Management
* Builds options into plans
* Identifies and prioritizes risks
 Fall 2006 – John Pfister
205
Planning and Control
• Before Contract is Let, Proposal Manager
Develops
*
*
*
*
*
*
*
Proposal Win Strategy
Technical Approach
Top-Level Management Plan
Work Breakdown Structure
After Contract Award, Software Manager
Updates Software Development Plan
Negotiates Schedules, Budgets, Deliverables,
and Management Controls
 Fall 2006 – John Pfister
206
Project Plan Objectives
1. Communicate work and expectations
2. Establish baseline for control over work-inprocess by establishing intermediate goals
and milestones
3. Focus efforts toward accomplishment of
project-related objectives
4. Integrate budget and schedule
5. Exercise control
 Fall 2006 – John Pfister
207
Software Project Plan Outline (IEEE)
Title Page
Revision Sheet
Table of Contents
List of Figures
List of Tables
1. Introduction
1.1 Project Overview
1.2 Project Deliverables
1.3 Evolution of the Plan
1.4 Reference Materials
1.5 Definitions and Acronyms
 Fall 2006 – John Pfister
208
Software Project Plan Outline (IEEE)
2. Project Organization
2.1 Process Model
2.2Organizational Structure
2.3Organizational Boundaries and Interfaces
2.4Project Responsibilities
3. Managerial Process
3.1 Management Objectives and Priorities
3.2Assumptions, Dependencies, and Constraints
3.3Risk Management
3.4Monitoring and Controlling Mechanisms
3.5Staging Plan
 Fall 2006 – John Pfister
209
Software Project Plan Outline (IEEE)
4. Technical Process
4.1 Methods, Tools, and Techniques
4.2Software Documentation
4.3Project Support Functions
5. Work Packages, Schedule, and Budget
5.1 Work Packages
5.2Dependencies
5.3Resource Requirements
5.4Budget and Resource Allocation
5.5Schedule
 Fall 2006 – John Pfister
210
Software Project Plan Outline (IEEE)
Additional Components
Index
Appendices
 Fall 2006 – John Pfister
211
Software Development Plan (DoD)
Title Page
Table of Contents
1. Scope
1.1 Identification
1.2 System Overview
1.3 Document Overview
1.4 Relationship to Other Plans
2. Referenced Documents
 Fall 2006 – John Pfister
212
Software Development Plan (DoD)
3. Software Development Management
3.1 Project Organization and Resources
3.1.1
Contractor Facilities
3.1.2 Government Furnished Equipment, Software, and
Services
3.1.3 Organizational Structure
3.1.4 Personnel
3.2 Schedule and Milestones
3.2.1
3.2.2
3.2.3
 Fall 2006 – John Pfister
Activities
Activity Network
Source Identification
213
Software Development Plan (DoD)
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
 Fall 2006 – John Pfister
Risk Management
Security
Interface with Associate Contractors
Interface with Software IV&V Agent(s)
Subcontractor Management
Formal Reviews
Software Development Library
Corrective Action Process
Problem/Change Report
214
Software Development Plan (DoD)
4. Software Engineering
4.1 Organization and Resources - Software Engineering
4.1.1
4.1.2
4.1.3
Organizational Structure - Software Engineering
Personnel - Software Engineering
Software Engineering Environment
4.1.3.1
4.1.3.2
4.1.3.3
4.1.3.4
Software Items
Hardware and Firmware Items
Proprietary Nature of Government Rights
Installation, Control, and Maintenance
4.2 Software Standards and Procedures
4.2.1
4.2.2
4.2.3
4.2.4
Software Development Techniques and Methodologies
Software Development Files
Design Standards
Coding Standards
4.3 Non-Developmental Software
 Fall 2006 – John Pfister
215
Software Development Plan (DoD)
5. Formal Qualification Testing
5.1 Organization and Resources - Formal
Qualification Testing
5.1.1
Organizational Structure - Formal Qualification
Testing
5.1.2 Personnel - Formal Qualification Testing
5.2Test Approach/Philosophy
5.3Test Planning Assumptions and Constraints
 Fall 2006 – John Pfister
216
Software Development Plan (DoD)
6. Software Product Evaluations
6.1 Organization and Resources - Software Product
Evaluations
6.1.1
Organizational Structure - Software Product
Evaluations
6.1.2
Personnel - Software Product Evaluations
6.2 Software Product Evaluations Procedures and Tools
6.2.1
6.2.2
Procedures
Tools
6.3 Subcontractor Products
6.4 Software Product Evaluation Records
6.5 Activity-Dependent Product Evaluations
 Fall 2006 – John Pfister
217
Software Development Plan (DoD)
7. Software Configuration Management
7.1 Organization and Structure - Configuration Management
7.1.1
7.1.2
Organizational Structure - Configuration Management
Personnel - Configuration Management
7.2 Configuration Identification
7.2.1
7.2.2
Developmental Configuration Identification
Identification Methods
7.3 Configuration Control
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
 Fall 2006 – John Pfister
Flow of Configuration Control
Reporting Documentation
Review Procedures
Storage, Handling, and Delivery of Project Media
Additional Control
218
Software Development Plan (DoD)
7.4Configuration Accounting
7.5Configuration Audits
7.6Preparation for Specification Authentication
7.7Configuration Management Milestones
8. Other Software Development Functions
9. Notes
10. Appendixes
 Fall 2006 – John Pfister
219
Work Breakdown Structure (WBS)
• Primary planning tool
• Decomposes work hierarchically into
•
component parts
Schedule and resources allocated to each task
1.0 Project Name
1.1 Management
1.2 Requirements &
Design
1.3 Construction &
Implementation
1.4 Deployment &
Support
1.1.1 Planning
1.2.1 Requirements
1.3.1 Construction
1.4.1 Deployment
1.1.2 Reviews
1.2.2 Design
1.3.2 Implementation
1.4.2 Training
1.1.3 Travel
1.4.3 Verification
1.4.4 Support
 Fall 2006 – John Pfister
220
Organization & Staffing Realities
•
•
•
•
•
•
•
Recruiting Key Personnel
Competition with other projects
Good technical skills
Good non-technical skills
Keeping Good People
Buffer outside distractions
Facilitate open communications
 Fall 2006 – John Pfister
221
Providing Leadership and Direction
• Foster Teamwork
• Building Synergistic Teams
• Coaching and Motivating
*
*
*
*
*
*
*
Interesting work
Growth
Recognition
Achievement
Responsibility
Advancement
Interpersonal relations
 Fall 2006 – John Pfister
222
Performance Measurement
• Allow visibility into project
• Use management indicators to pinpoint
•
•
•
problems early
Isolate causes of problems
Provide insight into quality and progress
Reassure customer and upper management
on progress and status
 Fall 2006 – John Pfister
223
Reviews and Audits
• Customer Reviews and Audits
*
*
*
*
*
*
*
Requirements Review
Preliminary Design Review
Critical Design Review
Test Readiness Review
End-Product Acceptance Review
Functional Configuration Audit
Physical Configuration Audit
• Quality Reviews and Audits
* Quality reviews (circles)
* Quality audits (evaluation)
* Quality inspection
 Fall 2006 – John Pfister
224
Reviews and Audits (Continued)
• Project Reviews
*
*
*
*
Management Reviews
Upper management reviews
Steering committee reviews
Peer management reviews
*
*
*
*
Walk-throughs
Inspections
Round-robin reviews
Walkbacks
• Peer Reviews
 Fall 2006 – John Pfister
225
Configuration Management and
Library Controls
•
•
•
•
•
Required for all large projects
Generally already in place
Problem reporting system
May have multiple CM systems
Need to adapt
 Fall 2006 – John Pfister
226
Quality Assurance and Metrics Analysis
• Independent quality assurance organization
•
•
required by some contracts
Tools and techniques tailored to needs of
project
Typical criticisms:
* Upper management paid only lip service to quality
* The quality organizations were staffed with
junior people
* The quality organizations were undertooled and
undercapitalized
* The quality organizations relied on inspections
 Fall 2006 – John Pfister
227
Risk Management and Control
• Top-Ten List
*
*
*
*
Identify top ten risks each month
Analyze
Prioritize
Minimize
*
*
*
*
*
Use on large, complicated jobs
Meet monthly
Chaired by software manager
Invite customer
Identify and prioritize top ten risks
• Risk Advisory Council
 Fall 2006 – John Pfister
228
Common Software Risks
People
1. Personnel shortfalls
2. Fragmentation
Resources
3. Unrealistic schedule (not enough time)
4. Inadequate budget (not enough money)
Requirements
5. Developing the wrong functions
6. Poorly defined requirements
7. Gold plating
8. Continuing change (feature creep)
9. Too little user involvement
 Fall 2006 – John Pfister
229
Common Software Risks
Receivables
10. Other projects don't deliver as promised
11. Legacy does not live up to expectations
Technology
12. Technology shortfalls
 Fall 2006 – John Pfister
230
Chapter 8 - Software Management
The Team Approach
• Communication and mutual trust between buyer and seller
are essential ingredients for the success of large
complex software projects
• Degree of interaction between buyer and seller will be a
function of the contract type used
• Buyer and seller managers have the same objective: meet
all requirements within the allocated resources
• Problems arise because of different motivations:
* Buyer wants to reduce risk (and therefore cost) by imposing
additional requirements - reviews, documentation, controls, etc.
* Seller wants to reduce risk (and costs) by paring down those
requirements -- providing more flexibility
 Fall 2006 – John Pfister
231
Key Player Roles & Responsibilities
•
•
•
•
•
•
•
Planning
Engineering
Documentation
Configuration Management
Quality Assurance
Software Tools
Testing
 Fall 2006 – John Pfister
232
Planning
• Before contract award:
* Buyer must deal with internal "politics" while
"selling" the project -- results in shortchanging
engineering and management decisions
* Seller concerned with contract award -assesses technical capability available staff,
competition, and available B&P funds
• After contract award Seller must assemble
•
staff -- danger that proposal staff may not
be available to execute contract
Buyer can minimize problems by sticking to
tight procurement schedule
 Fall 2006 – John Pfister
233
Engineering
• Staffing difficulties are not uncommon
• Engineers tend to add functionality -- make
•
more complex
Requirements management essential
 Fall 2006 – John Pfister
234
Documentation
• Inadequately addressed by Buyer during
planning
* Not equipped to make decisions
* End users unable to specify need for
documentation
• Seller recognizes the overall requirement,
but:
* Reluctant to recommend because of costs
* Not wise to tell customer he or she is wrong
* May want to de-emphasize documentation to
pull up schedule
 Fall 2006 – John Pfister
235
Documentation (Continued)
• Documentation most important aspect of
•
software development because it is
primary indicator of progress
Informal documentation must also be
managed
 Fall 2006 – John Pfister
236
Configuration Management
• CM essential to software development
•
•
•
process
Buyer may not appreciate importance
Seller may not have an effective CM
process in place
CM resources often cut during proposal to
be more competitive
 Fall 2006 – John Pfister
237
Quality Assurance
• Frequently misunderstood function
• QA resources often underscoped
• Often de-emphasized or eliminated on
•
small contracts
Necessary part of engineering process
 Fall 2006 – John Pfister
238
Software Tools
• Modern tools improve quality and
•
•
productivity
Buyer often not interested unless tools
being delivered with system
Cost of tools usually come out of Seller's
overhead
 Fall 2006 – John Pfister
239
Testing
• Frequently misunderstood and poorly
•
•
•
practiced
Testing begins with requirements
Buyer views testing as demonstration that it
meets requirements
Seller views testing as the means for sellingoff the product
 Fall 2006 – John Pfister
240
Building Synergistic Buyer/Seller Teams
• The Contract - In selecting a contractor,
the Buyer should consider:
* Ability of the seller to perform
* Organization
* Experience
• The Development
*
*
*
*
*
Project leaders
Personality conflicts
Crowd control
Personnel stability
Key personnel stability
 Fall 2006 – John Pfister
241
Communication and Trust
•
•
•
•
•
Informal Networking
Electronic Communications
Project and Telephone Lists
Minutes and Reports
Newsletters
 Fall 2006 – John Pfister
242
Reward and Punishment
• Organizational Awards
* Cost
* Award Fee
• Personal Awards
 Fall 2006 – John Pfister
243