Reviewer Soft Eng

Introduction to Software Engineering

Software Engineering is a collaborative activity. You are encouraged to work
together, but ...

Some tasks may require individual work.

Always give credit to your sources and collaborators.

Good professional practice: To make use of the expertise of others and to build
on previous work, with proper attribution.
Unethical and academic plagiarism: To use the efforts of others without
attribution.

Projects

Target must be a production system (not research)

Client should be one or two designated people -- client should be prepared to

meet with you regularly and attend the presentations
Team

Teams need many strengths -- organizational, technical, writing, etc.

Consider appointing a leader to coordinate the effort

Client (a.k.a. Customer)

The client provides resources and expects some product in return.
Client satisfaction is the primary measurement of success in a software
project.
Categories of client and software product:
Generic (e.g., Microsoft Excel)
Packages (e.g., Mathematica)
Customized versions of generic packages (e.g., Cornell's payroll system)
Bespoke (customized) (e.g., IRS internal system)

 Demonstration, prototype, research, ...

Most software development is by teams

Effectiveness of team determines success

Most large software projects are built on older ones

It is rare to start a new suite of programs from scratch

Building on the work of others is a fundamental skill of software development

Risk (as Seen by a Manager)

Problems
Over budget
Late delivery
Does not work as expected
Never used
Does the wrong thing
Needs change
Users dislike to use it
Visibility (as Seen by a Manager)
Problem
Must rely on others for reports of
progress or difficulties
Software Developers
Have difficulty evaluating progress
Optimistic
Consider reporting a waste time

Process in Large Software Projects

Software as a product
Clients and their needs
Quality
Requirements and specification
Usability
Evolution
Project management
Personnel management
Economic, legal, and social factors

Techniques for large and very large systems

Software design
Software architecture
Object-oriented design
Dependable systems
Reliability
Verification
Legacy systems

Good Software
General characteristics

Usability
Maintainability
Dependability
Efficiency

Good software products require good programming,

but ...

Programming quality is the means to the end, not the end itself.
Professional Responsibility
Organizations put trust in software developers:

Competence: Software that does not work effectively can destroy an

organization.
Confidentiality: Software developers and systems administrators may have
access to highly confidential information (e.g., trade secrets, personal data).
Legal environment: Software exists in a complex legal environment (e.g.,
intellectual property, obscenity).
Acceptable use and misuse: Computer abuse can paralyze an organization
(e.g., the Internet worm).

Software Process
Fundamental Assumption:
Good processes lead to good software
Good processes reduce risk
Good processes enhance visibility

Basic Process Steps in all Software Development

Feasibility and planning
A feasibility study precedes the decision to begin a project.

What is the scope of the proposed project?

Is the project technically feasible?

What are the projected benefits?

What are the costs, timetable?

A feasibility study leads to a decision: go or no-go.

Requirements
The requirements analysis and definition establish the system's services,
constraints and goals by consultation with users. They are then defined in a
manner that is understandable by both users and development staff.
This phase can be divided into:

1. Requirements analysis
2. Requirements definition
3. Requirements specification
Design
System design: Partition the requirements to hardware or software systems.
Establishes an overall system architecture
Software design: Represent the software system functions in a form that can be
transformed into one or more executable programs

Unified Modeling Language (UML)

Implementation

Programming

The software design is realized as a set of programs or program units. (Written

specifically, acquired from elsewhere, or modified.)

Testing

Individual components are tested against specifications.

The individual program units are integrated and tested against the design as a
complete system.
Acceptance and release

Acceptance

The complete system is tested against the requirements by the client.

Delivery and release

The complete system is delivered to the client and released into production.
Operation and maintenance

Operation: The system is put into practical use.

Maintenance: Errors and problems are identified and fixed.
Evolution: The system evolves over time as requirements change, to add
new functions or adapt the technical environment.
Phase out: The system is withdrawn from service.

Combining the Process Steps

Sequence of Processes
Every software project will include these basic processes, in some
shape or form, but:

They may be formal or informal

They may be carried out in various sequences

The Waterfall Model

Discussion of the Waterfall Model

Advantages:

Process visibility

Separation of tasks

Quality control

Cost control

Disadvantages:
Each stage in the process reveals new understanding of the previous stages, that
requires the earlier stages to be revised.
Modified Waterfall Model

Iterative

Refinement

Concept: Initial implementation for user comment, followed by refinement until

system is complete.
Vaporware: user interface mock-up
Throw-away software components
Dummy modules
Rapid prototyping
Successive refinement

Phased Development
Concept
A simple system with basic functionality is brought quickly into production (Phase
1).
Subsequent phases are based on experience gained from users of each previous
phase.
Advantages

Pay-back on investment begins soon.

Requirement are more clearly understood in developing

subsequent phases
Observations about Software Processes
Completed projects should have the basic process steps
but ... the development process is always partly evolutionary.
Risk is lowered by:
Prototyping key components
Dividing into phases
Following a visible software process
Making use of reusable components
Conclusion
It is not possible to complete each step and throw it over the wall.

Feasibility Studies
A feasibility study is a study made before committing to a project.
A feasibility study leads to a decision:
go ahead
do not go ahead
think again
In production projects, the feasibility study often leads to a budget request.

In research, a feasibility study is often in the form of a proposal.

Why are Feasibility Studies Difficult?

Benefits are usually very hard to quantify.

Approach is usually ill-defined. Estimates of resources needed
and timetable are very rough.
(e.g., eCornell)
Organizational changes may be needed.
(e.g., Copyright deposit system.)

The Decision Maker's Viewpoint

A senior member of an organization must decide whether to begin a major software
project. What information is needed?

Client: Who is this project for?

Scope: What are the boundaries of the project?
Benefits: What are the benefits? Can they be quantified?
Technical: Is there at least one technical way to carry out the
project?
Resources: What are the estimates of staff, time, equipment, etc?
Alternatives: What are the options if the project is not begun?

Where are risks? Can they be minimized?

Technical

There must be an outline plan with a rough timetable and staff allocation.
The plan must have a very large margin for contingencies. (Projects typically
require twice the staff and/or time envisaged in the feasibility plan.)

External

Every system interacts with others. Are the others committed to the
necessary efforts?
Where are the external pressures and obstacles?

Prototype and Phased Development

A prototype is not released to users, except experimentally

In phased development, each phase is released into full production

Feasibility Study: Scope

Scope expresses the boundaries of the system:
It
It
It
It

will include <list of included functions>

will exclude <list of excluded functions>
depends on <list of dependencies>
replaces <list of functions to be replaced>

Confusion over scope is a common reason for clients to be

dissatisfied with a system.
"Is that all you planned to do?" "But I assumed that you were going
to do xyz." "I can't use the system without abc."
Feasibility Study: Benefits
Why is this project proposed? Can you quantify the benefits?
Examples

Create a marketable product

Improve the efficiency of an organization (e.g., save staff)
Control a system that is too complex to control manually
New or improved service (e.g., faster response to customers)
Safety or security

Feasibility Study: Technical

A feasibility study needs to demonstrate that the proposed system is technically
feasible. This requires:

a rough outline of the requirements

a possible system design (e.g., database, distributed, etc.)
estimates of numbers of users, data, transactions, etc.
possible choices of software to be acquired or developed

These very rough numbers are fed into the provisional plan that is used to estimate
the staffing, timetable, equipment needs, etc.
Feasibility Study: Planning and Resources
The feasibility study should include an outline plan:

Estimate the staffing and equipment needs, and the preliminary timetable
Identify major decision points
Identify interactions with and dependences on external systems
Provide a preliminary list of deliverables and delivery dates

Feasibility Study: Alternatives and Risks

A feasibility study should identify alternatives and risks.
Alternatives

Continue with current system, enhance it, or create new one?

Develop in-house, or contract out? (How will a contract be managed?)

Risks

What can go wrong?

How will problems be identified (visibility)?
Are there fall-back options?

Techniques for Feasibility Studies

Give client appreciation of system:

demonstration
mock-up
walk through

Outline budget:

n people for m months at $x per month

equipment, buildings, etc.

Phases/milestones:

deliverables at approximate date

Feasibility Report
A written document

For a general audience: client, financial management,

technical management, etc.
Short enough that everybody reads it.

Long enough that no important topics are skipped.

Details are often included in supporting documents.

It should be a well written, well presented document.

Legal Aspects of Software Engineering

Intellectual Property Law: Copyright
Copyright is Federal law, which applies to literary works.
Originally applied to textual materials, but gradually extended to cover text, music,
photographs, designs, software, ...
Copyright applies to the expression of ideas (e.g., the words used), not to the ideas
themselves, nor to physical items.
Software
Copyright applies to the program instructions, but not to the concepts behind
the instructions, nor to the files on disk or on paper where the programs instructions
are stored.
Ownership of Copyright (USA)
At creation

Copyright is automatically owned by the creator.

Except works for hire, where the employer owns the copyright.

Transfer of copyright

In the USA, copyright is property that can be sold or licensed.

The agreement to sell is written as a contract.

"A verbal contract isn't worth the paper it's written

on." (Attributed to Yogi Berra.)
International differences
Moral rights
In some countries, e.g., Canada, France, the creator of a work retains moral rights,
which cannot be sold, for instance the right of attribution.

Registration
In the USA, copyright is established automatically when something is created. In
many countries, it is necessary for the creator to register it to claim copyright.
In the USA, copyright gives the owner exclusive right to:

reproduce
distribute
perform
display
license others to reproduce, distribute, perform, or display

Special exceptions
First sale. The owner of an object, e.g., a book, can sell the object without
permission of the copyright owner.
Fair use. Limited use is permitted without permission of the copyright owner,
e.g., in a review or short quotation.
Copyright: Derivative Software
When software is derived from other software:

Copyright in new code only is owned by new developer

Conditions that apply to old code apply to derived work

If you write S, which includes code derived from A, B, C and D, you cannot distribute
or licenses S unless you have right, from the copyright owner, to distribute each of
A, B, C and D.
Contracts and Licences
Contracts allow intellectual property to be sold

Economic agreement in exchange for some consideration

(e.g., money)

Written document with signatures:

Permanent or temporary, whole or part
Exclusive or non-exclusive
Termination, problems and difficulties
Terms and conditions as agreed

Enforceable by courts

For simple agreements, an exchange of letters is a convenient form of

contract.
Intellectual Property: Patents
Patents apply to inventions

Should be: non-obvious, novel, useful

Requires a complex process of patent application

17 years from award (20 years from application)

Copyright applies to the expression of ideas, patents to the ideas themselves.

Problems with software patents
Poor quality of patent examiners can lead to broad patents for routine
computing concepts

Usually difficult to know where ideas originate

International differences

Trade Secrets and Non-Disclosure Agreements

Trade Secret
"... information, including a formula, pattern, compilation, program, device, method,
technique, or process that derives independent economic value from not being
generally known and not being readily ascertainable and is subject to reasonable
efforts to maintain secrecy."
Example: Microsoft source code
Non-Disclosure Agreement
Legal agreement not to disclose trade secrets
Trade Secrets

A trade secret does not expire - as long as it is kept secret.

Competitors may not use secrets obtained through extraordinary means.

If you learn trade secrets when working for one employer, you must not
disclose them to another employer.

Trademark

Specific name or phrase

Unique within a line of business, in a specific country (e.g., only one

electronics firm called Apple in the USA, but could be a shipping line called
Apple in the USA or a different electronics firm called Apple in another
country.)

Generic terms cannot be trademarked (e.g., Windows is currently under

dispute)

Trademarks can be lost if they are not defended

Lost trademarks: aspirin, kleenex

Held trademarks: Coke, Pepsi

Privacy
Invasions of privacy:

intrusion
appropriation of name or likeness
unreasonable publicity
false light

Public or Private Information?

A lot of public information is considered private

An increasing amount of public information available on the Internet

Reverse phone lookups

Campaign Contributions
Housing prices
Drivers license information and photographs

Privacy in Email

Legally, email is like a postal letter

Expectation of privacy in transit

Mail loses its special protected status once it leaves the letter carrier's
grasp

For email,

Expectation of privacy while signal travels over Internet

Email loses its protected status at the mail server whether you have
read it or not

Privacy in the Workplace

Test for employers/employees - Do you have a reasonable expectation of

privacy?

Work-related material on business machines is definitely not private.

Some organizations, e.g., most universities, treat private email on business

machines as private, but this is not the law.

Business Email

Electronic Communications Privacy Act (1986) says all business

communication belongs to that business.
Deleting email can be ruled intentionally destroying company records.
An archive is worthless if it cannot be indexed effectively (in effect, saving
everything can be equivalent to saving nothing).

Free Speech
In the USA, the First Amendment protects many aspects of free speech, including
news reporting, religious expression, etc., but there are major exceptions (e.g., state
secrets, defamation, obscenity, racial hatred). In the USA, some aspects (e.g.,
obscenity) are governed by state laws with big differences among states. Laws in
other countries may be very different (e.g., blasphemy, criticism of the
government).
Special Situations
Internet Service Providers

Transmit and store intellectual property that they do not own

A special (complex) legal framework protects them
If you run such a service, you need a knowledgeable lawyer

Ecommerce

Ecommerce operates across jurisdictional boundaries

Data is subject to various laws of privacy, security, taxation, etc.

If you run such a service, you need a knowledgeable lawyer.

Business Law: Personnel

Every state has strict and complex laws about recruitment, hiring, termination
(firing), on-job conditions, and terms and conditions of employment. If you
supervise other people, you need to know the basics of these laws.
Many employers run short courses for their supervisors or have a booklet with the
key issues.
If in doubt, consult an expert.
Business Law: Your Next Job ...

Your employment contract may restrict your next job (not working for
competitors, etc.)

Trade-secret information (non-disclosure agreement)

Contamination (knowledge of trade secrets may prevent you working on

similar projects for others)

Ask before you accept the job!

Read the employment contract before you sign it!
Practical Advice
Be aware of the law, but do not pretend to be a lawyer.
Use a professional for:

Contracts and licenses (unless very simple exchange of letters)

Troubles (complaints, injunctions, subpoenas, etc.)

Personnel issues (particularly firing)

When in doubt, ask for help!

Requirements
The requirements analysis and definition establish the system's services,
constraints and goals by consultation with users. They are then defined in a
manner that is understandable by both users and development staff.
This phase can be divided into:

Requirements analysis

Requirements definition

Requirements specification

Requirements define the function of the system FROM THE CLIENT'S

VIEWPOINT.
Goals During the Requirements Phase

Understand the requirements in detail (analysis).

Describe the requirements in a manner that is clear to the client. Ensure

that the client understands the description of the requirements and their
implications.

Describe the requirements in a manner that is clear to the people who will
design and implement the system.
The Requirements Documentation is the defining document
that describes the goals of the system that is being built.
It may form a legal contract between client and software developers.
The Requirements Process

Requirements Analysis
High-level abstract description of requirements:

Specifies external system behavior

Comprehensible by customer, management and users

Should reflect accurately WHAT THE CUSTOMER WANTS:

Services that the system will provide

Constraints under which it will operate

Often described in a separate document for consultation with the client.

"Our understanding of your requirements is that ..."
Requirements Documentation
The form of documentation varies, but is likely to contain
the following:
General

Purpose and scope of system

Objectives and criteria for success
List of terminology, organizations involved, etc.

Description of current system(s)

Requirements of proposed system

Overview
Functional Requirements
Usability requirements
Non-functional requirements

System models

Scenarios
Use cases
Models used during analysis

Detailed specifications

Business rules, specifications, etc. (e.g., reference to an

accounting standard)
Data flow, sources of data, data validation etc., etc.,

Realism and Verifiability

Requirements must be realistic, i.e., it must be possible to meet them.
Not: The system must be capable of x, if no known computer system can do x at a
reasonable cost.

Requirements must be verifiable, i.e., it must be possible to test whether a

requirement has been met.
Wrong: The system must be easy to use.
Right: After one day's training an operator should be able to input 50 orders per
hour.
Evolution of Requirements

If the requirements definition is wrong, the system will be

wrong.

With complex systems, understanding of requirements

always continues to improve.

Therefore...

The requirements definition must evolve.

Its documentation must be kept current (but clearly

identify versions).

New and Old Systems

A new system is when there is no existing system.
A replacement system (or subsystem) is when a system is built to replace an
existing system.
A legacy system is an existing system that is not being replaced, but must
interface to the new system.
In requirements analysis it is important to distinguish:

features of the current system

proposed new features

Clients often confuse the current system with the underlying requirement.

Functional Requirements
Requirements about the functions that the system must perform that will be
identified by analyzing the use made of the system

Functionality

Data

User interfaces

Understanding and specifying the functional requirements is the theme of the next
three lectures.
Non-Functional Requirements
Requirements that are not directly related to the functions that the
system must perform

Usability, documentation and training

Reliability and quality assurance

Performance

Supportability

Implementation and technical constraints

Interfaces and compatibility

Operation and physical environment

Packaging and security

Legal and business

Resources

Unspoken Requirements
Examples:

Resistance to change

Departmental friction

Management strengths and weaknesses

Requirements Analysis: Interviews with Clients

CLIENT INTERVIEWS ARE THE HEART OF REQUIREMENTS ANALYSIS AND

DEFINITION. Allow plenty of time.
Clients may have only a vague concept of requirements.
Prepare before you meet with them
Keep full notes
If you do not understand, delve further
Repeat what you hear
Small group meetings are often most effective
Requirements Analysis
1. Identify the stakeholders:
Who is affected by this system?

Client
Senior management
Production staff
Computing staff
Customers etc., etc., etc.,

2. Understand the requirements in depth:

Domain understanding

Examples: Philips light bulbs

Understanding of the real requirements of all stakeholders

3. Organize the requirements:

Classification into coherent clusters

(e.g., legal requirements)

Recognize and resolve conflicts

(e.g., functionality v. cost v. timeliness)
Example: Dartmouth general ledger system

Viewpoint Analysis
Example: University Admissions System

Applicants

University administration
Admissions office
Financial aid office
Special offices (e.g., athletics, development)

Computing staff
Operations
Software development and maintenance

Academic departments

Models
A model is a simplification of reality.
We build models so that we can better understand the system we are
developing.
We build models of complex system because we cannot comprehend such a
system in its entirety.
Models can be informal or formal. The more complex the
project the more valuable a formal model becomes.
Principles of Modeling
The choice of what models to create has a profound influence on how a problem
is attacked and how a solution is shaped.
Every model can be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient. Every nontrivial system is best approached
through a small set of nearly independent models.

The Unified Modeling Language

UML is a standard language for modeling software systems

 Serves as a bridge between the requirements specification and the

implementation.
Provides a means to specify and document the design of a software system.
Is process and programming language independent.
Is particularly suited to object-oriented program development.
Rational Rose
Rational Rose is a system for creating and managing UML diagrams.
It is available for Computer Science Department computers.
There will be a short introduction to Rational Rose in class on Thursday.