Fall 2006 – John Pfister 1 CSE 8315 Software Acquisition Practices, Legal and Economic Issues Class Notes Fall 2006 NOTE: These class notes are subject

Fall 2006 – John Pfister 1

CSE 8315Software Acquisition Practices, Legal and Economic Issues

Class NotesFall 2006

NOTE: These class notes are subject to change during any lecture

John Pfister, Adjunct Professor

OFFICE: (972) 344-2094 E-MAIL: [email protected] Site: http://engr.smu.edu/cse/8315/ FAX: (972) 596-1484 (Home)FAX: (214) 768-3085 (SMU CS Dept)

Last Updated: July 24, 2006

mailto:[email protected]



http://engr.smu.edu/cse/8315/










Texts

Software Acquisition Management: Managing the Acquisition of Custom Software Systems by John Marcinak and Don Reifer

Alpha-Graphics3032 MockingbirdDallas, TX 75205(214) 363-1101

[email protected]





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


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 acquisition6. Evaluating proposals

Course Outline1. 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 Outline6. 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

Management8. Best Practices

• Capability Maturity Model Integration (CMMI)• Acquisition Capability Maturity Model• Project Management Body of Knowledge• The Program Manager’s Guide to Software Acquisition

Best Practices 9. 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).


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 Reference

1.

2.


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:

Substance

Degree to which topic is covered in depth 80%

Format Degree to which the format prescribed in Appendix B is followed

10%

Writing Grammatical correctness 10%


Grades and Due Dates

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.


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


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


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


Buyer / Seller Model

OrganizationalManagement

Division

Director ofPrograms

Systems Engineering Manufacturing

Project X Hardware Software

CorporateFinance,

Planning, etc.

Seller

StaffFinance, PlanningHuman Resouces

OtherPrograms

Buyer

StaffPersonnelFinance

Program X

SubsystemManagementTest Etc.

StaffPlansData, etc.

Contracting,Technical Svcs

Organizational Environment


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

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:

Performance

Cost Schedule

Ideally, the Buyer should specify performance, and the Seller should bid cost and schedule


Chapter 2 The Software Acquisition

Environment

• The System Life Cycle

• The Software Life Cycle

• Management Processes

• The Role of Standards


Systems Life Cycle

• Concept Exploration Phase

• Demonstration and Validation Phase (Program Development Risk Reduction)

• Full Scale Development

• Production and Development


Systems Life Cycle

ConceptExploration

Demonstrationand Validation

Full-ScaleDevelopment

ProductionDeployment

o RequirementDefinition

o Planningo Trade-offs

o Advanced

EngineeringPrototypes

o RiskIdentification

o SystemDevelopment(Hardware andSoftware)

o Multiple CopiesProduced

o Trainingo Operationso Maintenance

and Support

o Prototypes


Software Life Cycle

• Software Requirements Analysis

• Software Design

• Code and Unit Testing

• Subsystem Test and Integration

• Test and Integration


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.


Management Processes

• Documentation

• Management and Engineering Reviews

• Configuration Management

• Quality Assurance

• Assessment


Documentation & Reviews

SystemReqmts

SoftwareReqmtsAnalysis Preliminary

Design Detailed

Design Code and

Unit Test Subsystem

Test & Int

Integration

Design

o SRS

o SDPo Software

DesignSpecifications

o Software TestPlan

o SourceCode

o Test o Detailed

Test ProcDescrip. o User Doc

o Prod Speco Test Rpts

Reviews:SRR PDR CDR TRR

FunctionalBaseline

AllocatedBaseline

ProductBaseline

Test &


Configuration Management

• Configuration Identification

• Configuration Control

• Configuration Audit

• Configuration Status Accounting



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


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


Assessment (Metrics)

Management indicators that provide feedback on:* Process* Product* Project* Productivity

Standards facilitate communication between the buyer and the seller


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.


Chapter 3 – Acquisition Management

The Seller

• Determines:* How the software

will be developed* What resources

are required

• Directs strategy at getting the buyer to share risk while making a profit

The Buyer • Determines:

* What the system requires

* When it will be needed

* How it will be accepted

• Directs strategy at getting system at lowest cost and on-time


Procurement Life-Cycle

• Concept exploration

• Source acquisition

• Performance management


Acquisition Management (Continued)

• Acquisition Management Strategy

• Buyer Activities

• Seller Activities

• Request for Proposal

• Proposal

• Contract Negotiations


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


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.


Strategy Selection Factors

Factor Sole-Source Competitive Two-Phase

Risk low low-medium high

Complexity

low medium high

Uniqueness

yes no no

Cost

moderate high high

Schedule

tight flexible flexible

Size

small large large

Req. Volatility

stable volatile volatile


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

• 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)


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


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


Source selection organization 1. Source selection authority2. Source selection advisors3. Source selection evaluators

Competitive Source Process

Source selection process1. Complete selection package2. Prepare source list3. Issue solicitation4. Score and rank responses5. Issue questions6. Rescore based on responses7. Negotiate8. Award contract


Writing a Winning Proposal

• Complete Solicitation Package

• Prepare Source List

• Issue RFP

• Score and Rank Responses

• Issue Questions

• Rescore Based on Responses

• Negotiate

• Award


Negotiations and Appeasements

1. Technical terms and conditions2. Financial terms and conditions3. Contract terms and conditions


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


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


Offshore Software Development

• Benefits

• Characteristics of offshore projects

• Characteristics of offshore companies

• CMM profile of offshore companies

Reference: WWW. SWDEVELOPER.COM


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


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


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


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


USA and Offshore Organization Maturity Profiles

2002 by Carnegie Mellon University

29.3%

42.7%

21.7%

4.5%

1.8%

17.6%

35.4%

27.3%

8.3%

11.5%

0.0%

5.0%

10.0%

15.0%

20.0%

25.0%

30.0%

35.0%

40.0%

45.0%

Initial Repeatable Defined Managed Optimizing

% o

f O

rga

niz

ati

on

s

USA Offshore

Based on 714 U. S. organizations and 444 offshore organizations – March 2002


Number of Assessments and Maturity Levels Reported

Country

Number of Assessments

Reported

Maturity Level 1

Reported

Maturity Level 2

Reported

Maturity Level 3

Reported

Maturity Level 4

Reported

Maturity Level 5

ReportedArgentina Less than 10Australia 27 Yes Yes Yes No NoAustria Less than 10Barbados Less than 10Belgium Less than 10Brazil 15 Yes Yes Yes No NoCanada 47 Yes Yes Yes No YesChile Less than 10China 18 No Yes Yes No YesColombia Less than 10Denmark Less than 10Egypt Less than 10Finland Less than 10France 103 Yes Yes Yes Yes NoGermany 21 Yes Yes Yes No NoGreece Less than 10Hong Kong Less than 10Hungary Less than 10India 153 Yes Yes Yes Yes YesIreland Less than 10Israel 27 Yes Yes Yes No NoItaly 21 Yes Yes Yes No No



Number of Assessments and Maturity Levels Reported

Country

Number of Assessments

Reported

Maturity Level 1

Reported

Maturity Level 2

Reported

Maturity Level 3

Reported

Maturity Level 4

Reported

Maturity Level 5

ReportedJapan 46 Yes Yes Yes No YesKorea, Republic of Less than 10Malaysia Less than 10Mexico Less than 10Netherlands 12 Yes Yes Yes No NoNew Zealand Less than 10Phillipines Less than 10Poland Less than 10Portugal Less than 10Puerto Rico Less than 10Russia Less than 10Saudi Arabia Less than 10Singapore 15 Yes Yes Yes No YesSouth Africa Less than 10Spain Less than 10Sweden Less than 10Switzerland Less than 10Taiwan Less than 10Thailand Less than 10Turkey Less than 10United Kingdom 103 Yes Yes Yes No NoUnited States 1496 Yes Yes Yes Yes YesVenezuela Less than 10



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


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

*Safety*Security*Metrics*Documentation*Acceptance*Test and Evaluation


Request for Proposal (RFP) Outline

Part I - The ScheduleSection A Solicitation/contract formSection B Supplies or services and

price/costSection C Description/specs/work statementSection D Packaging and markingSection E Inspection and acceptanceSection F Deliveries or performanceSection G Contract administration dataSection H Special contract requirements

Part II - Contract ClausesSection I Contract clauses


RFP Outline (Continued)

Part III - List of documents, exhibits and other attachments

Section J List of attachments

Part IV - Representations and

instructionsSection K Representations, certifications

and other statements of offerors

Section L Instructions, conditions, and notices to offerors

Section M Evaluation factors for award


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


System/Software Engineering Issues

• Requirements management

• Selection/definition of software subsystem/components

• Tools and environment

• Methods and methodologies


Engineering Methods

SystemReqmts


Design Detailed

Design Code and

Unit Test Subsystem

Test & Int

Integration

Design

RequirementsModeling

Functionaldecomposition

Data flow

Structured analysis/designProgram design language

Path analysis

Random testingFunctional testingReal-time testing

System I&T

ENGINEERING METHODS

Code and peer reviewsStructured analysisCode auditsData flow testing

Test &


Management Methods

SystemReqmts


Design DetailedDesign Code and

Unit Test Subsystem

Test & Int

Design

System I&T

MANAGEMENT METHODS

Riskanalysis

Requirementsreview

Designreviews

Test reviewsTesting

Documentation reviewSpecifications, manuals, training materials, etc.

Project review andTechnical interchange meetings

Baseline control - Configuration Control BoardFunctional Baseline

Allocated Baseline

IntegrationTest &


Management Issues

• Software Documentation

• Engineering Data Management



• Assessment


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



• 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



• 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?


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



• 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



• 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?


Configuration Management (CM)

• CM Plan

• Organization

• Tools

• Personnel



• 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.



• 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?


Quality Assurance

IEEE: "To provide adequate confidence that the item or product conforms to established technical requirements"

• Organization

• Procedures

• Personnel


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.


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 used on prior projects?


Assessment (Metrics)

• Oversight Management

• Test and Evaluation

• Reviews and Audits

• Management Indicators

• Schedule

• Clean Room Activity


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?


Test and Evaluation

SystemReqmts


Design Detailed

Design Code and

Unit Test Subsystem

Test & Int

Integration

Design

System I&T

Qualificationrequirementsstated

Test conceptin softwaredevelopmentplan

Test requirementsincorporated intodesign specifications

Informaltesting

Softwaretest plan

Detailedtest procedures

Formaltesting

Testreviews

Testing

Testresults

Dynamic testing

Static analysis testing

Test &


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


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.


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?


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.


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?


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.



• 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?


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.


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?


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?


Seller Organization Types

• Matrix (Functional) Organization

• Project Management Organization

• Hybrid


Matrix (Functional) Organization

ENGINEERING

Sys Eng

Elec Eng

Mech Eng

S/W Eng

PROGRAM A PROGRAM B

NEW SYSTEMS

Sys Eng

Elec Eng

Mech Eng

S/W Eng

Sys Eng

Elec Eng

Mech Eng

S/W Eng


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.


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 senior-level managers within the seller organization?


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


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


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.


Fixed-Price Contracts

• Firm fixed-price

• Fixed-price with economic price adjustment

• Fixed-price incentive

• Fixed-price redetermination


Firm-Fixed Price

• Fixed price upon delivery of specified goods or services

• Requirements must be well understood

• All risk assumed by the seller


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


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-to-exceed-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


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



FFP FPEPA FPI FPRApplicability

•Firm design & requirements

•Adequate competition exists

•Reasonable price & cost comparisons exist

Market & labor conditions are unstable for extended time period

•Possibility of cost 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

•Established price

•Ceiling on upward adjustment

•Downward adjustment reasonable

•Target cost

•Target profit

•Price ceiling

•Profit adjustment formula

•OK accounting system

•Ceiling price or initial price fixed

•Agreement to renegotiate & redetermine price




FFP FPEPA FPI FPRCost Risk

All of the cost risk assumed by seller

Reduced cost risk in the adjustment areas

Variable fee employed to control cost

Reduced cost risk in the renegotiated 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

Increased administrative burden

•Minimum management burden

•Minimum administrative burden

Even more administrative and management burden


Cost-Reimbursable Contracts

• Cost and cost sharing (CS)

• Cost plus incentive fee (CPIF)

• Cost plus award fee (CPAF)

• Cost plus fixed fee (CPFF)


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


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


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


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



CS CPIF CPAF CPFFApplicability

•Uncertainties in performance and estimates

•Research and development jointly sponsored

•Research and development done with a nonprofit organization



•Cost/schedule improvement possible

•Variable fee can provide incentives



•Measurements of improvements subjective

•Variable fee can provide incentives


•Research and development where the job cannot be defined and the level of effort is not known initially

Essential Elements•Predetermined cost for both buyer/seller

•No fee•OK accounting system

•Target cost•Target fee•Min/maximum fee•Fee adjust

formula•OK accounting

system

•Estimated cost•Base fee•Maximum fee•Award fee criteria•OK accounting system

•Estimated cost•Fixed fee•OK accounting system



CS CPIF CPAF CPFFCost Risk

Self-motivated to control cost and performance

Variable fee employed to control cost and performance


Seller responsibility for managing cost

Approvals

Head of contracting

Contacting officer Contracting officer Contracting officer


Hard to get parties to agree

•Management burden high

•Administrative burden high

•Most difficult to administer

•Difficult to derive award fee and to manage

•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)


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


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


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


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


Other Contractual Devices

T-M LC IDC BOAApplicability

• Initially not possible to estimate the extent or duration of the job

•Applicable to design or eng. services and maintenance and repair

•Requirements are such that commitment is needed for work to start immediately

•Cost/schedule estimates can be derived in the future

•Schedule for delivery may be unknown

•Quantity may be unknown

•Requirements may need to be defined during start-up

•Multiple jobs contemplated, which can be combined for ease of overall administration under a single agreement

•Economies of scale exist

Essential Elements•Direct labor rate fixed

•Burden and fee negotiated

•Ceiling price established


•Maximum liability spelled out

•As many contract provisions defined as possible


•Provisions for specifying time, amount, and req identified

•Min and max order quantities


•Estimated cost•Estimated fee•OK accounting system



T-M LC IDC BOACost Risk

Task orders used as minicontracts to control cost

Cost could grow during negotiations


None – not a contract

Approvals

Contracting officer Head of contracting

Contracting officer Head of contracting


•Constant surveillance needed


Need to get under contract as soon as possible

•Easy to administer if fixed-price


•Do not have to 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


Contract Selection Considerations

• The extent and nature of subcontracting contemplated

• The size of the contract

• The seller's experience


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


Other Related Contracting Topics

• Federal Acquisition Regulations (FARs)

• Contract Administration and Termination* Performance Measurement* Contract Modifications* Contract Termination/Close-out


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


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


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


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


Other Legal Issues

• Copyrights

• Software Patents

• Trade Secrets and Confidentiality Agreements

• Employee Non-Competition Agreements

• Software Liability Issues


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


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



• 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.



• 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



• 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.



• 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



• 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



• 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



• 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



• 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



• 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 softwareText of programRoutineProgram instructionsEntire programWrote programSubroutineEntire program codeEntire work

Program listingSoftwareComputer program codeEntire textProgram text and screen displaysText of computer gameProgram textModule

Reference: Software Development, A Legal Guide, Stephen Fishman, Jan 1998.



Some unacceptable terms are:

Algorithm Formatting RomAnalysis Functions Software methodologyCassette Language StructureChip Lay-out SequenceComputer game Logic OrganizationDisk Menu screen SystemEncrypting Mnemonics System designEprom Printout Text of algorithmFirmware ProgrammerFormat Prom




• 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.



• 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.



• 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.



• 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.



• 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



• 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



• 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



• 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



• 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]



• The Gray Areas* Uncertain protection for the internal

structure of a program* Unresolved question of reverse engineering* Doctrine of "fair use"* Creating "near clones"



• 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



• 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.



• 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.




• 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?




• 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)



• 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)



• 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



• 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


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"


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



• 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



• 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"



• 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 - $15-20K per month for about two years



• 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



• 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.



• 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.



• 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.


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.


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


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


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


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


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 safety-critical situations

Reference: CMU/SEI-93-TR-013, Software Product Liability, August 1993.


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


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


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


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


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


Software Product Liability

Personal injury?

Caused by a product?

Was there a contract?

Court uphold contract?

Prove negligence?

Failure to perform?

Recover under warranty

Recover under strict liability

Recover under negligence

No recourse

Yes

Yes No

YesNo

Yes

YesNo

No

Property damage?

Reference: CMU/SEI-93-TR-013, Software Product Liability, August 1993.


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


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.


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


Project Planning

• Project Organizational Structure• Key Personnel Responsibilities• Standards and Methodologies• Documentation• Development Tools• Budget• Schedules• Staffing• Assessment, Customer Approval and

Certification


Important Considerations

• Establishing Requirements

• Estimating Resources

• Risk Management Strategies


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


Requirements Outline Example

1. Introduction1.1 Purpose1.2 Scope1.3 Definitions, Acronyms and Abbreviations1.4 References1.5 Overview

2. Overall Description3. Specific Requirements

3.1 Functionality3.1.1 <Functional Requirement One>

3.2 Usability3.2.1 <Usability Requirement One>

3.3 Reliability3.3.1 <Reliability Requirement One>

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.


Requirements Outline Example

3.4 Performance3.4.1 <Performance Requirement One>

3.5 Supportability3.5.1 <Supportability Requirement One>

3.6 Design Constraints3.6.1 <Design Constraint One>

3.7 Online User Documentation and Help System Requirements

3.8 Purchased Components3.9 Interfaces

3.9.1 User Interfaces3.9.2 Hardware Interfaces3.9.3 Software Interfaces3.9.4 Communications Interfaces

3.10 Licensing Requirements3.11 Legal, Copyright and Other Notices3.12 Applicable Standards

4. Supporting Information


Requirements Characteristics

• The DoD says that they should be:* Complete* Traceable* Testable* Consistent* Feasible* Uniquely Identified* Design Free

• Another author says:* Correct* Compete* Consistent* Unambiguous* Verifiable* Understandable* Traceable* 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


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


1995 DoD Software Study


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


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


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


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


Risk Management Strategies

• Basic Risk Management Process:* Assessment* Analysis* Evaluation* Management

• Risk Management Plan Should:* Identify risk* Attempt to quantify impact* Identify mitigation plans


Program Management Office - Roles and Responsibilities

• Project Management• Engineering• Test• Training• Quality Assurance• Contract Administration• Program Control• Data Management• Interface Management• Logistics Support


Performance Management & Assessment

• Reviews

• Schedules

• Problem Reporting

• Test

• Independent Testing

• Management Indicators

• Documentation


Reviews

• Generally two kinds of reviews:* Formal -- should be structured around

well-defined 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 walk-throughs


Schedules

• Generally two kinds of schedules:* Gantt charts - top-level milestone chart* PERT/CPM - detailed precedent-related

event chart


Problem Management

• Management procedures should provide for:* Review of the problem* Reporting* Status* Management* Correction


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



• Memory utilization

• Problem reports

• Software size

• Personnel stability

• Development progress

• Incremental release

• Test progress



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.


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


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


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


IV&V Contract

Use IV&V Contractors if: System Characteristic

DevelopmentCharacteristics

High RiskLow Cost

Med RiskMed Cost

Low RiskHigh 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


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


Chapter 7 - Software ManagementThe 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


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


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


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


Project Plan Objectives

1.Communicate work and expectations2.Establish baseline for control over work-

in-process by establishing intermediate goals and milestones

3.Focus efforts toward accomplishment of project-related objectives

4.Integrate budget and schedule5.Exercise control


Software Project Plan Outline (IEEE)

Title PageRevision SheetTable of ContentsList of FiguresList of Tables1.Introduction

1.1 Project Overview1.2 Project Deliverables1.3 Evolution of the Plan1.4 Reference Materials1.5 Definitions and Acronyms



2.Project Organization2.1 Process Model2.2 Organizational Structure2.3 Organizational Boundaries and Interfaces2.4 Project Responsibilities

3.Managerial Process3.1 Management Objectives and Priorities3.2 Assumptions, Dependencies, and

Constraints3.3 Risk Management3.4 Monitoring and Controlling Mechanisms3.5 Staging Plan



4.Technical Process4.1 Methods, Tools, and Techniques4.2 Software Documentation4.3 Project Support Functions

5.Work Packages, Schedule, and Budget5.1 Work Packages5.2 Dependencies5.3 Resource Requirements5.4 Budget and Resource Allocation5.5 Schedule



Additional ComponentsIndexAppendices


Software Development Plan (DoD)

Title PageTable of Contents1.Scope

1.1 Identification1.2 System Overview1.3 Document Overview1.4 Relationship to Other Plans

2.Referenced Documents



3.Software Development Management3.1 Project Organization and Resources

3.1.1 Contractor Facilities3.1.2 Government Furnished Equipment,

Software, and Services3.1.3 Organizational Structure3.1.4 Personnel

3.2 Schedule and Milestones3.2.1 Activities3.2.2 Activity Network3.2.3 Source Identification



3.3 Risk Management3.4 Security3.5 Interface with Associate Contractors3.6 Interface with Software IV&V Agent(s)3.7 Subcontractor Management3.8 Formal Reviews3.9 Software Development Library3.10 Corrective Action Process3.11 Problem/Change Report



4.Software Engineering4.1 Organization and Resources - Software

Engineering4.1.1 Organizational Structure - Software

Engineering4.1.2 Personnel - Software Engineering4.1.3 Software Engineering Environment

4.1.3.1 Software Items4.1.3.2 Hardware and Firmware Items4.1.3.3 Proprietary Nature of Government Rights4.1.3.4 Installation, Control, and Maintenance

4.2 Software Standards and Procedures4.2.1 Software Development Techniques and

Methodologies4.2.2 Software Development Files4.2.3 Design Standards4.2.4 Coding Standards

4.3 Non-Developmental Software



5.Formal Qualification Testing5.1 Organization and Resources - Formal

Qualification Testing5.1.1 Organizational Structure - Formal

Qualification Testing5.1.2 Personnel - Formal Qualification

Testing

5.2 Test Approach/Philosophy5.3 Test Planning Assumptions and

Constraints



6.Software Product Evaluations6.1 Organization and Resources - Software

Product Evaluations6.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 Procedures

6.2.2 Tools

6.3 Subcontractor Products6.4 Software Product Evaluation Records6.5 Activity-Dependent Product Evaluations



7.Software Configuration Management7.1 Organization and Structure - Configuration

Management7.1.1 Organizational Structure - Configuration

Management7.1.2 Personnel - Configuration Management

7.2 Configuration Identification7.2.1 Developmental Configuration Identification7.2.2 Identification Methods

7.3 Configuration Control7.3.1 Flow of Configuration Control7.3.2 Reporting Documentation7.3.3 Review Procedures7.3.4 Storage, Handling, and Delivery of Project

Media7.3.5 Additional Control



7.4 Configuration Accounting7.5 Configuration Audits7.6 Preparation for Specification

Authentication7.7 Configuration Management Milestones

8.Other Software Development Functions9.Notes10. Appendixes


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.2 Requirements & Design

1.1 Management1.3 Construction &

Implementation1.4 Deployment &

Support

1.1.1 Planning

1.1.2 Reviews

1.1.3 Travel

1.2.1 Requirements

1.2.2 Design

1.3.1 Construction

1.3.2 Implementation

1.4.1 Deployment

1.4.2 Training

1.4.3 Verification

1.4.4 Support


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


Providing Leadership and Direction

• Foster Teamwork

• Building Synergistic Teams

• Coaching and Motivating* Interesting work* Growth* Recognition* Achievement* Responsibility* Advancement* Interpersonal relations


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


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


Reviews and Audits (Continued)

• Project Reviews* Management Reviews* Upper management reviews* Steering committee reviews* Peer management reviews

• Peer Reviews* Walk-throughs* Inspections* Round-robin reviews* Walkbacks


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


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


Risk Management and Control

• Top-Ten List* Identify top ten risks each month* Analyze* Prioritize* Minimize

• Risk Advisory Council* Use on large, complicated jobs* Meet monthly* Chaired by software manager* Invite customer* Identify and prioritize top ten risks


Common Software Risks

People1. Personnel shortfalls2. Fragmentation

Resources3. Unrealistic schedule (not enough time)4. Inadequate budget (not enough money)

Requirements5. Developing the wrong functions6. Poorly defined requirements7. Gold plating8. Continuing change (feature creep)9. Too little user involvement


Common Software Risks

Receivables10. Other projects don't deliver as

promised11. Legacy does not live up to

expectations

Technology12. Technology shortfalls


Chapter 8 - Software ManagementThe 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


Key Player Roles & Responsibilities

• Planning

• Engineering

• Documentation



• Software Tools

• Testing


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


Engineering

• Staffing difficulties are not uncommon

• Engineers tend to add functionality -- make more complex

• Requirements management essential


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


Documentation (Continued)

• Documentation most important aspect of software development because it is primary indicator of progress

• Informal documentation must also be managed



• 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


Quality Assurance

• Frequently misunderstood function

• QA resources often underscoped

• Often de-emphasized or eliminated on small contracts

• Necessary part of engineering process


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


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 selling-off the product


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


Communication and Trust

• Informal Networking

• Electronic Communications

• Project and Telephone Lists

• Minutes and Reports

• Newsletters


Reward and Punishment

• Organizational Awards* Cost* Award Fee

• Personal Awards