software engineering new1 1062217755 2
TRANSCRIPT
-
7/29/2019 Software Engineering New1 1062217755 2
1/165
Software Engineering
Lecture 1
Introduction to Software Engineering
Code of Conduct
Software Engineering is a collaborative activity. You areencouraged 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 otherswithout attribution.
Projects
Project teams, about 3 to 5 peoples.
Select your own project, any branch of software engineering
Real project for real client who intends to use the software inproduction.
Feasibility study and plan
Presentations:
requirements
design
final
-
7/29/2019 Software Engineering New1 1062217755 2
2/165
Project Selection
Some suggested projects
Recitation section to suggest projects
Contact potential clients:
Gain idea of their expectations
Estimate scope and complexity of the project
Discuss business decisions
Assemble project team
Advertise on the web site
Previous Experience
Biggest program that you have written?
Biggest program that you have worked on?
Biggest project team that you have been part of?
Longest project that you have worked on?
Most people who have used your work?
Longest that your project has been in production?
Course Themes
1. Leadership of 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
-
7/29/2019 Software Engineering New1 1062217755 2
3/165
Course Themes
2. Large and very large systems
Software design
Software architecture
Object-oriented design
Dependable systems
Reliability
Verification
Legacy systems
Characteristics of Software Products
General characteristics
Usability
Maintainability
Dependability
Efficiency
Good software products require good programming,
but ...
Programming quality is the means to the end, not theend itself.
Software as a Product
Software is expensive!!
Every software project has a trade-off between:
Functionality
Resources (cost)
Timeliness
Example:
Accounting Management System
-
7/29/2019 Software Engineering New1 1062217755 2
4/165
Client (a.k.a Customer)
The client provides resources and expects some productin return.
Client satisfaction is the primary measurement ofsuccess.
Question: Who is the client for Microsoft Excel?
Variety of Software Products
Examples?
-Operation System
-Database Management System
-Embedded System
-Games
-Application Software
-
Categories of Product
Categories of client and software product:
Generic (e.g., Microsoft Excel)
Bespoke (customized) (e.g., IRS internalsystem)
Many systems are customized versions of generic
packages (e.g., Cornell's payroll system)
-
7/29/2019 Software Engineering New1 1062217755 2
5/165
Variety of Software Products
Software products are very varied
--> Client requirements are very different
--> There is no standard process for software engineering
--> There is no best language, operating system, platform,database system, development environment, etc.
A skilled software developer knows about a wide variety of
approaches, methods, tools. The craft of software engineering
is to select appropriate methods for each project and apply them
effectively.
Professional Responsibility
Organizations put trust in software developers:
Competence: Software that does not work effectively candestroy an organization.
Confidentiali ty: Software developers and systemsadministrators 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 anorganization (e.g., the Internet worm).
Software Engineering
Lecture 2
The Software Process
-
7/29/2019 Software Engineering New1 1062217755 2
6/165
Books
Frederick P. Brooks, Jr. The Mythical Man Month.Addison-Wesley, 1972.
Ian Sommerville, Software Engineering, 6th edition.Addison-Wesley, 2000.
Grady Booch, James Rumbach, Ivar Jacobson, TheUnified Modeling Language. Addison-Wesley 1999.
Software Process
Fundamental Assumption:
Good processes lead to good software
Good processes reduce risk
Risk Management
What can go wrong in a software project?
How can the risk be reduced?
-
7/29/2019 Software Engineering New1 1062217755 2
7/165
The Software Process (Simplified)
Requirements
Operation andMaintenanceImplementation
Design
Feasibility and
Planning
The Waterfall Model
Requirements
Definition
System and
Software design
Programmingand Unit Testing
Integration and
System Testing
Operation and
Maintenance
Requirements Analysis and Definition
The system's services, constraints and goals are established by
consultation with system users. They are then defined in a
manner that is understandable by both users and development
staff.
This phase can be divided into:
Feasibility study (often carried out separately)
Requirements analysis
Requirements definition
Requirements specification
-
7/29/2019 Software Engineering New1 1062217755 2
8/165
System and Software Design
System design: Partition the requirements to hardware orsoftware 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)
Programming and Unit Testing
The software design is realized as a set of programs orprogram units. (Written specifically, acquired from
elsewhere, or modified.)
Individual components are tested against specifications.
Integration and System Testing
The individual program units are:
integrated and tested as a complete system
tested against the requirements as specified
delivered to the client
-
7/29/2019 Software Engineering New1 1062217755 2
9/165
Operation and Maintenance
Operation: The system is put into practical use.
Maintenance: Errors and problems are identified andfixed.
Evolution: The system evolves over time asrequirements change, to add new functions or adapt the
technical environment.
Phase out: The system is withdrawn from service.
Discussion of the Waterfall Model
Advantages:
Process visibility
Dependence on individuals
Quality control
Cost control
Disadvantages:
Each stage in the process reveals newunderstanding of the previous stages, that
requires the earlier stages to be revised.
Feedback in the Waterfall Model
RequirementsDefinition
System andSoftware design
Programming
and Unit Testing
Integration and
System Testing
Operation andMaintenance
-
7/29/2019 Software Engineering New1 1062217755 2
10/165
Iterative Refinement
(Evolutionary Development)
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
Iterative Refinement
Requirements
DesignImplementation
(prototype)
Evaluation
Iterative Refinement
Outline
Description
Concurrent
Activities
Requirements
Design
Implementation
Initial
Version
Intermediate
Versions
Final
Version
-
7/29/2019 Software Engineering New1 1062217755 2
11/165
Iterative Refinement & Software
Process
Outline
Description
Concurrent
Activities
Requirements
Design
Implementation Final
Version
Iterative Refinement
When is iterative refinement appropriate?
Iterative Refinement + Waterfall Model:
Graphics for Basic
Outline Description: Add vector graphics to
Dartmouth Basic.
Phase 1: Extend current language with a preprocessor
and run-time support package. (1976/77)
Phase 2: Write new compiler and run-time system
incorporating graphics elements. (1978/80)
-
7/29/2019 Software Engineering New1 1062217755 2
12/165
Iterative Refinement + Waterfall Model:
Graphics for Basic
Design Issues:
Pictorial subprograms: coordinate systems, window/viewport
User specification of perspective
Design Strategy: (Iterative Refinement)
Write a series of prototypes with various proposed semantics
Evaluate with a set of programming tasks
Iterative Refinement + Waterfall Model:
Graphics for Basic
Phase 1: Implementation (Waterfall)
When the final specification was agreed, the entirepreprocessor and run-time support were recoded.
The system was almost entirely bug-free.
Phase 2: New compiler (Waterfall)
Phase 1 was used as the requirements definition for thefinal version.
Observations about Software Processes
Completed projects should look like the Waterfall Model
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
-
7/29/2019 Software Engineering New1 1062217755 2
13/165
Software Engineering
Lecture 3
(a) Feasibility Study
(b) Requirements Definition
Feasibility Study
Before beginning a project, a short, low-cost study to identify
Client
Scope
Potential benefits
Resources needed:
staff, time, equipment, etc.
Potential obstacles
Where are the risks? How can they be minimized?
Feasibility Study
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.
-
7/29/2019 Software Engineering New1 1062217755 2
14/165
CS 501: Client
In CS 501, you have two clients:
The client for the project
The professor for the course
Can you satisfy them both?
Scope
What are the boundaries of the project?
CS 501 Examples:
Static web pages with open access on the Web [Web Profiler]
Used by the general public [Digital Collections]
Varying data formats [Legal Information]
Thousands of sensors [Data mining]
Support for Windows, Mac, Unix [SALSA]
Potential Benefits
Why are you doing thi s project?
Examples
Create a marketable product
Improve the efficiency of an organization
Control a system that is too complex to control manually
New or improved service
Safety or security
Get a good grade on CS 501
-
7/29/2019 Software Engineering New1 1062217755 2
15/165
Resources
Examples: CS 501
Staff: 5 to 7 students, with some help. How many hours per week?
What skills do people have?
Time: Must be completed by end of semester, including
operational system, documentation, presentation
Equipment and software: What special needs are there?
Client: Will the client be sufficiently available and helpful?
Obstacles
CS 501 projects
Start-up time. Creating a team, scheduling meetings, acquiring
software, learning new systems, ...
Business considerations. Licenses, trade-secrets, ...
Too ambitious. Nothing to show at the end of the semester.
Changing circumstances. Client leaves the university, ...
What else?
How to Minimize Risk?
CS 501 Proj ects
Several target levels of functionality:
required, desirable, optional
Visible software process: intermediate deliverables
Good communication within team and with
Teaching Assistant
Good processes lead to good software
Good processes reduce risk
-
7/29/2019 Software Engineering New1 1062217755 2
16/165
Feasibility Report
A wri tten 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
Requirements Definition and Analysis
Requirements
Definition
System and
Software design
Programmingand Unit Testing
Integration and
System Testing
Operation and
Maintenance
Example: Library of Congress
(A Partial Failure)
Outline DescriptionThe Library of Congress requires a repository system
to store and make accessible very large amounts of
highly varied material over long periods of time.
-
7/29/2019 Software Engineering New1 1062217755 2
17/165
Chronology
1993-94 CNRI carries out research on architectures for
digital libraries
1995-97 CNRI implements prototype repository for
Library of Congress
1998 CNRI and Library of Congress carry out requirements
definition
Repository
Identification System Search System
Users
The Repository
Storage and Representation of Complex
Objects
Data
Several representations:
thumbnail image
reference image
archival image
Metadata
Each representation may
have its own metadata
-
7/29/2019 Software Engineering New1 1062217755 2
18/165
Repository: Research Achievements
1. CORBA implementation of repository access protocol.
2. Integration of persistent naming through handle system.
3. Use of structural metadata to describe complex objects,
elementary typology.
4. Access management framework and implementation.
5. Applet-based middleware for user interfaces.
6. Information visualization program to view the structure of
large collections.
Good Discoveries During Prototype
Structuring complex information in digital libraries
Data driven digital library interfaces
Comparison of object-oriented, relational, and file
based storage systems
Naming and identification of library objects
Boundaries of required repository system
Bad Discoveries During Prototype
Resistance to change within Library of Congress
Technical weakness of Library of Congress
Gaps in CNRI architecture
-
7/29/2019 Software Engineering New1 1062217755 2
19/165
Mistakes
Confusion of objectives (research and implementation)
Failure to involve all stakeholders
Over-ambitious (no proper feasibility study)
The Requirements Process
FeasibilityStudy
Requirements
Analysis
Requirements
DefinitionRequirements
SpecificationFeasibility
Report System
Models Definition of
Requirements
Specification of
RequirementsRequirements
Document
Requirements Definition
High-l evel abstract descri ption of requirements:
Specifies external system behavior
Comprehensible by customer, management and users
Should r eflect accurately what th e customer wants:
Services that the system will provide
Constraints under which it will operate
-
7/29/2019 Software Engineering New1 1062217755 2
20/165
Library of Congress Requirements Study
Team (all experienced): Librarian, Software Engineer (CNRI),Computing Project Leader (Library of Congress), + 2 others
Advisors: Mailing list of about 20 knowledgeable stakeholders.
Timetable: Preliminary report (2 months). Final report (1 month).
Functional Requirements
Example: Library of Congress repository
Support for complex digital objects
Access management
Identification
Information hiding
Open protocols and formats
Integration with other systems (scope)
Current Storage Structure
(in Unix files, by aggregate)
Index Generation
(including pre-processing)
American Memory User Interface
(retrieval, navigation, & display)
Object Administration System
Repository
NDLP Workflow
Tracking Support
Handle-server
NDLP collections
already released
NDLP collections
in conversion
Coolidge collection
(for repository test)
Future
NDLP collections
NOW FUTURE
ILS OPAC InterfaceOther User Interfaces
(e.g. RLG, OCLC, DLF partners)
Other applications
and materials
ILS
Handle assignment
& registration Handle resolution
Supporting infrastructure
DRAFTOVERVIEW OF ITS SUPPORT
FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY
AM user interface plus
access managementfor objects/collections
-
7/29/2019 Software Engineering New1 1062217755 2
21/165
Non-functional Requirements
Environment:
Estimates of sizes, numbers of users, etc.
Reliability and performance measures and targets
Preferred:
Example: Library of Congress repository
Hardware and software systems (e.g., IBM/Unix) Database systems (e.g., Oracle)
Programming languages (e.g., C and C++)
Evolution of Requirements
If the requirements definition is wrong, the system will be
a failure.
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).
Software Engineering
Lecture 4
Management I: Project Management
-
7/29/2019 Software Engineering New1 1062217755 2
22/165
The Aim of Project Management
To complete a project: On time
On budget
With required functionality
To the satisfaction of the client
Without exhausting the team
The Project Manager
Create and maintain the schedule
Should track progress against schedule
Keep some slack in the schedule
Be continually making adjustments:
Start activities before previous activity complete
Sub-contract activities
Renegotiate deliverables
Keep senior management informed
Project Planning Methods
The Critical Path Method, Gantt charts, Activity bar charts, etc.are roughly equivalent.
These methods are best when:
Model is updated regularly (e.g., monthly)
The structure of the project is well understood
The time estimates are reliable
Activities do not share resources
[Critical Path Method is excellent for large construction
projects.]
-
7/29/2019 Software Engineering New1 1062217755 2
23/165
Example: An Open University Course
Deliverables:
16 Written texts (bound in pairs)
8 Television programs
8 Radio programs
4 Computer programs
1 Home experimental kit (scientific calculator)
4 Assignments and sample solutions
Flexibility
Schedule: Dates for broadcasting TV and radio programs arefixed. Printing and mailings can be accelerated if overtime is
used.
Functionality: The course team can decide what goes into the
components of the course.
Resources: The size of the course team can be increased
slightly.
Scheduling: Critical Path Method
An activity
A dummy activity
An event
A milestone
-
7/29/2019 Software Engineering New1 1062217755 2
24/165
Critical Path Method
Edit
Unit 3
Print
Unit 3
Revise
Unit 3Mail
Unit 3
other
activities
START END
Critical Path Method
Edit
Unit 3Typeset
Unit 3
Revise
Unit 3MailUnits 3/4
other
activities
Edit
Unit 4
Print
Units 3/4
Revise
Unit 4
other
activities
Typeset
Unit 4
START
Critical Path Method
START
Edit
Unit 3
ScriptTV 2
Make
TV 2
Edit
Unit 4
Prototype Computer 1
Program
Computer 1
Document
Computer 1
Mail
Delivery
-
7/29/2019 Software Engineering New1 1062217755 2
25/165
Time Estimates for Activities (Weeks)
64
2
2
3
3
1
3
3
82
1 1
4
12
12
1
4
Earliest Start Dates
64
2
2
3
3
1
3
3
8
2
1 1
4
12
12
1
4
0
1
12
12
4
15 17
17
17
19
22
26
23 25
Latest Start Dates
64
2
2
3
3
1
3
3
82
1 1
4
12
12
1
0
11
12
14
13
15 17
17
17
20
23
26
24 25
4
-
7/29/2019 Software Engineering New1 1062217755 2
26/165
Critical Path
0/0
1/11
12/12
12/14
4/13
15/15 17/17
17/17
17/17
19/20
22/23
26/26
23/24 25/25
Slack
0/0
1/11
17/17
23/24
10
5
0
12/12
12/14
4/13
15/15 17/17
17/17 19/20
22/23
26/26
25/25
10
0 0
00 0
0
22
99
1
1
3
1 1
Key Personnel
In computing, not all people are equal:
The best are at least 5 times more productive
Some tasks are too difficult for everybody
Adding more people adds communications complexity
Some activities need a single mind
Sometimes, the elapsed time for an activity can not be
shortened.
What happens to the project if a key person is sick or quits?
-
7/29/2019 Software Engineering New1 1062217755 2
27/165
Key Personnel: Schedule for Editor
Earliest Start Date Activity
Weeks 15-16 Edit Unit 3Weeks 17-18 Edit Unit 4
Weeks 19-20 Edit Unit 5
Weeks 21-22 Edit Unit 6
Week 15 Review draft of Unit 7
Week 17 Review draft of Unit 8
Week 19 Check proofs of Unit 3
Week 21 Check proofs of Unit 4
Weeks 18-19 Vacation
Week 22 Out sick
Start-up Time
On a big project, the start-up time is typically three to six
months:
Personnel have to complete previous projects (fatigue) or
recruited.
Hardware and software has to be acquired and installed.
Staff have to learn new domain areas and software (slow
while learning)
Clients may not be ready.
Experience with Critical Path Method
Administrative computing department at Dartmouth used the
Critical Path Method for implementation phase of major projects.
Experience: Elapsed time to complete projects was consistently
25% to 40% longer than predicted by model.
Analysis:
Some tasks not anticipated (incomplete understanding)
Some tasks had to be redone (change of requirements,
technical changes)
Key personnel on many activities (schedule conflicts)
System ZZZ (non-billable hours)
-
7/29/2019 Software Engineering New1 1062217755 2
28/165
Software Engineering
Lecture 5
(a) Documentation
(b) Requirements Analysis
Documentation
Reasons for documentation:
visibility (e.g., project plan, interim report)
user support (e.g., user manual)
team communication (e.g., interface specifications)
maintenance and evolution (e.g., requirements)
Characteristics of documentation:
accurate and kept current
appropriate for audience
maintained online (usually)
simple but professional in style and appearance
Documentation is expensive --> Quality not volume
Form of Documentation
External
Printed
Web site
Internal
Program documentation
Program context (e.g., copyright notices)
-
7/29/2019 Software Engineering New1 1062217755 2
29/165
Requirements Definition and Analysis
Requirements
Definition
System and
Software design
Programmingand Unit Testing
Integration and
System Testing
Operation and
Maintenance
The Requirements Process
FeasibilityStudy
Requirements
Analysis
Requirements
DefinitionRequirements
SpecificationFeasibility
Report System
Models Definition of
Requirements
Specification of
RequirementsRequirements
Document
Requirements Analysis
1. Understand the requirements in depth:
Domain understanding
Examples: science research, application
Stakeholders
Example: companies, ministries, Danang City
-
7/29/2019 Software Engineering New1 1062217755 2
30/165
Viewpoint Analysis
Example: Uni versity Admi ssions System
Applicants
University administration
Admissions office
Financial aid office
Special offices (e.g., athletics, development)
Computing staff
Operations
Software development and maintenance
Academic departments
Interviews with Clients
Cli ents may have onl y a vague concept of requi rements.
Prepare before you meet with them
Keep full notes
If you don't understand, delve further
Small group meetings are often most effective
Cli ents often confuse the current system with the
underlyi ng requirement.
Requirements Analysis
2. Organ ize the requi rements:
Classification into coherent clusters
(e.g., legal requirements)
Recognize and resolve conflicts
(e.g., functionality v. cost v. timeliness)
Example: Dartmouth general ledger system
-
7/29/2019 Software Engineering New1 1062217755 2
31/165
Requirements Analysis
3. Model the requir ements: Informal
Prose
Systematic
Procedural models
Data-centric models
Object models
Formal models
Procedural Models: Flowchart
Operation
Decision
Manual operation
Report
Flowchart: University Admissions
Form
received New?
Databaserecord
T
Notify
student
F Update
databaseComplete?
Notifystudent
T
FEvaluate
-
7/29/2019 Software Engineering New1 1062217755 2
32/165
Procedural Models: Pseudo-code
Example: Check project project plan
check_plan (report)
ifreport (date_time) > due_date_timethen error (too_late)
ifreport (client) = none then error (no_client)ifreport (team) < min_team or > max_team
then error (bad_team)iferror() = none
then comments = read_report (report)
return (comments (text), comments (grade))else return error()
Data-Flow Models
External entities
Processing steps
Data stores or sources
Data flows
Example: University Admissions
Applicant
Application
form Receive
application
Completed
applicationEvaluate
Rejection
Offer
-
7/29/2019 Software Engineering New1 1062217755 2
33/165
Example: University Admissions
Assemble Application Stage
Applicant
Applicationform
Receive
Completed
application
Supporting
information
Pending
database
Acknowledgment
Initiate
evaluation
Applicant
database
Evaluation
request
AND
AND
Acknowledgment
Example: University Admissions
Process Completed Application Stage
Rejection
Evaluation
Applicant
database
Evaluation
request AcceptanceFinancial
aid
Offer
Special
request
Requirements Analysis v. System Design
Dilemma.
Requirements analysis should make minimal assumptions
about the system design.
But the requirements definition must be consistent with
computing technology and the resources available.
In practice, analysis and design are interwoven. However, do
not to al low the analysis tools to prejudge the system design .
-
7/29/2019 Software Engineering New1 1062217755 2
34/165
Software Engineering
Lecture 6
(a) Requirements Analysis (continued)
(b) Requirements Specification
The Requirements Process
FeasibilityStudy
Requirements
Analysis
Requirements
DefinitionRequirements
SpecificationFeasibility
Report System
Models Definition of
Requirements
Specification of
RequirementsRequirements
Document
Requirements Analysis
Methods for data modeli ng and design
Data flow diagrams
Entity-relation diagrams
Data dictionaries
Object models
Many of these methods blur the distinction between
analysis and design.
-
7/29/2019 Software Engineering New1 1062217755 2
35/165
Entity-Relation Model
A Design Methodology for Relational Databases A database of entities and relations
Tools for displaying and manipulating entity-
relation diagrams
Tools for manipulating the database (e.g., as
input to database design)
Warning: There is much confusion about
definitions and notation
Entity-Relation Diagram
An entity
A relation between
entities
An entity or relation
attribute
An inheritance
relation
Example: CS 501 Project
Student
CS501
Student
Major
Project
5 to 7
1
Member of
Person
Client
1
Tech contact
0:n0:n
0:n
-
7/29/2019 Software Engineering New1 1062217755 2
36/165
MARC Format for Monographs
(Books)
001 89-16879 r93
245 Campus strategies for libraries and electronic information260 {Bedford, Mass.} : Digital Press, c1990.
650 Academic libraries--United States--Automation.
650 Libraries and electronic publishing--United States.
700 Arms, Caroline R. (Caroline Ruth)
Entity-Relation Diagram for MARC
Book
Short title
Catalog
record
Describes
Control numb
Subject
headingIs about
CreatorEditor of
Author of
1:n
1
0:n
0:n
0:n
0:n
0:n
0:n
Data Dictionaries
A data dicti onary is a li st of names used by the system
Brief definition (e.g., what is "date")
What is it (e.g., number, relation)
Where is it used (e.g., source, used by, etc.)
May be combined with a glossary
As the system is implemented, the data dicti onary in the
requirements is input to the system data dictionary, which is a
formal part of the system specif ication.
-
7/29/2019 Software Engineering New1 1062217755 2
37/165
A Note on Object Models
This course teaches object models as a tool for design.
Some people recommend object models for requirements
analysis, but it is difficult to use them without constraining
the system design.
Non-Functional Requirements
Product requirements
performance, reliability, portability, etc...
Organizational requirements
delivery, training, standards, etc...
External requirements
legal, interoperability, etc...
Examples of Non-Functional
Requirements
Privacy (Mercury digital l ibrary)
Functional requirement:
Usage data for management of system
Non-functional requirement:
Usage data must not identify individuals
Mi nimi zing records (NeXT)
Functional requirement:
Retain all required records
Non-functional requirement:
Discard all other records
-
7/29/2019 Software Engineering New1 1062217755 2
38/165
Unspoken Requirements
Example:Resistance to change at XXX
Requirements Specification
What is the purpose of the Requirements Specification?
Requirements Specification: Purpose
1. I t descri bes the requir ements to the stakeholders
Expressed in the terms that the stakeholders understand
Comprehensible from many viewpoints
Reviewed by stakeholders so that they understandimplications
Must be clear about assumptions (things left out)
-
7/29/2019 Software Engineering New1 1062217755 2
39/165
Requirements Specification: Purpose
2. It describes the requir ements to the impl ementers As precise and specific as possible
Expressed in terms that they understand
Comprehensible to new team members
Requirements Specification: Purpose
3. I t records the requirements for the futu re
An essential part of system evolution
4. I f may be a contractual document
See you in court!
Requirements Specification: Approaches
Natural language
Structured natural language
Design description language
Requirements specification language
Graphical notation
Formal specification
See Sommerville, Chapter 7.
-
7/29/2019 Software Engineering New1 1062217755 2
40/165
Software Engineering
Lecture 7
Management II
Business and Legal Aspects of
Software Engineering
Legal Environment
Software is developed in a complex legal and
economic framework. Changes in l aws fol low
changes in technical wor ld.
Jurisdictions:
Vietnamese laws
International treaties
Federal and state statues
Precedents Supreme Court
Cost of establishing precedent
Legal Topics
International
Intellectual property (copyright, patent, contract)
Tort (e.g., liability of Internet service provider)
Privacy
Free speech and its limitations (government secrets,
obscenity, blasphemy, hate)
Legal Information Institute: http://www.law.cornell.edu/
-
7/29/2019 Software Engineering New1 1062217755 2
41/165
Copyright
A copyright gives the owner the exclusive right to: reproduce
distribute
perform
display
license
Gradually extended to cover text, music,photographs, designs, software, ...
Copyright
Copyright at creation
Works for hire
Contracts and licenses
First sale
Fair use
Infringement (contamination)
I nternational differences Moral rights
Copyright registration
Software Patents
Should be: non-obvious, novel, useful
17 years from award (20 years from application)
Poor quality of examining can lead to broad patents for
routine computing concepts
International differences
Copyright applies to the expression of ideas, patents to the
ideas themselves.
-
7/29/2019 Software Engineering New1 1062217755 2
42/165
Contracts and Licences
Contracts allow intellectual property to be sold or li censed
Promise in exchange for adequate consideration
Written document with signature
Permanent or temporary, whole or part
Exclusive or non-exclusive
Termination, problems and difficulties
Terms and conditions as agreed
Enforceable by courts
Derivative Works
When software is derived from other software:
New code is owned by new developer
Conditions that apply to old code apply to derived work
If you write S, which is derived from A, B, C and D, you cannot distribute or licenses S unless you have right to distribute
each of A, B, C and D.
To create a software product, you must have documentedrights to use every component.
Privacy
Invasions of privacy:
intrusion
appropriation of name or likeness
unreasonable publicity
false light
Be very careful about collecting personal
data without the knowledge of the individual
-
7/29/2019 Software Engineering New1 1062217755 2
43/165
Software Business Questions
You are employed for company X writing software.
When you leave, who owns your work? What use can youmake of the work?
You work free-lance for company X. When you finish,
who owns your work? What use can you make of the work?
Read the contract!
Your Next Job ...
Employment contract may restrict your next job (not
working for competitors, etc.)
Trade-secret information (non-disclosure agreement)
Ask when you are interviewed!
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 reasonableefforts to maintain secrecy."
Uniform Trade Secrets Act
Non-Di sclosure A greement
Legal agreement not to disclose trade secrets.
-
7/29/2019 Software Engineering New1 1062217755 2
44/165
Some Business Models
Software developed in-house
Package licensed to customer, binary only (Microsoft
model)
Package licensed to customer, source code for customer's
modifications
Bespoke software for customer (may be owned by
supplier or customer)
Software bundled with hardware product (PalmPilot)
Free-Lance Software Development
You and a few friends create a company to develop software.
How much should you charge per hour?
You plan to work 40 hours a week for 50 weeks of the year and
want to earn $50,000.
Hourly rate = $50,000 / (40 x 50) = $25
But ...
Free-Lance Software Development
Salary $50,000Taxes and benefits $15,000
Rent, equipment, etc. $10,000
Fees, services, etc. $15,000
Travel and misc. $10,000
TOTAL EXPENSE $100,000
Hours worked 2,000less administration 400
less marketing 350
BILLABLE HOURS 1,250
Hourly rate = $100,000 /1,250 = $80
-
7/29/2019 Software Engineering New1 1062217755 2
45/165
Fixed and Variable Cost: Packaged Software
Example:
The initial development cost of a software product
is $10 million.
The cost of packaging and distribution of each
copy is $5.
Technical support costs average $15 per copy.
The package sells for $200 per copy.
Fixed cost = $10 million
Variable cost = $20
Fixed and Variable Costs: Profit or Loss
$15M
$10M
$5M
Unit
sales2,500 5,000 7,500
Community Development
Shareware
Open source (e.g., Linux, Apache, Perl, etc.)
-> Shared development
-> Market penetration
Example: TCP/IP for Vax/VMS
Software may be open source, but packaging and
services can be profitable businesses
-
7/29/2019 Software Engineering New1 1062217755 2
46/165
Open Source
Free redistribution
Source code
Derived works
Integrity of the author's source code
No discrimination against persons or groups
Open Source
No discrimination against fields of endeavor
Distribution of license
License must not be specific to a product
License must not contaminate other software
http://www.opensource.org/osd.html
Practical Advice
Be aware of the law, but do not pr etend to be a lawyer.
Use a professional for :
Contracts and licenses
Troubles (complaints, injunctions, subpoenas, etc.)
Personnel issues
When in doubt, ask help!
-
7/29/2019 Software Engineering New1 1062217755 2
47/165
Source Code Management
Or
Configuration Management: How I
learned to Stop Worrying and Hate My
Co-workers Less
Source Code Management
Also known as Configuration Management
Source Code Managers are tools that:
Archive your development files
Serve as a single point of entry/exit when adding or
updating development files
Why You Want A Source Control
System
Supports concurrent development
Manage diverging source code bases
Records file/release versions
Easy access to all previous revisions
Can record why a revision was made
Optimal disk space usage
Youll end up doing something equivalent anyway so it
may as well be automated
-
7/29/2019 Software Engineering New1 1062217755 2
48/165
Source Code Management Tools Are
Not
A substitute for project management
A replacement for developer communication
How They Work
Central database of source code, documentation, build
tools
Each file stored only once - all other versions are diffs of
that one copy
To Make a Change
Check out the latest version of a file
Make the changes
Update the database
What should be in the database
Source Code
Documentation
Build Tools
Often need old versions of the tools to build old versions
of the software
Ensures software is rebuilt exactly as the customer
received it
Test Suites
Anything else you might want later
-
7/29/2019 Software Engineering New1 1062217755 2
49/165
Version Control
Companies ship several products from the same source
base (i.e. Win NT and Windows 2000 versions of MSOffice)
When tracking down bugs you want to examine the code
as it was when the product shipped
Code Sharing
Multiple people can work on the same source base without
colliding
(1) Locks individual files so only one person at a time can
modify it *OR*
(2) Allows multiple people to modify a source file and the
system will automatically merge the changes (usually)
Locking
Only one person can work on a file at once
Works fairly well if developers work on different areas ofthe project and dont conflict often
Problem 1: People forget to unlock files when they are
done
Problem 2: People work around locking by editing aprivate copy and checking in when the file is finally
unlocked - easy to goof and lose changes
-
7/29/2019 Software Engineering New1 1062217755 2
50/165
Merging
Several people can work on a file at once
Before committing changes, each user merges their copywith the latest copy in the database
This is normally done automatically by the system and
usually works, but you should not blindly accept the result
of the merge
Labeling
Label all the files in the source base that make up a product
at each milestone
Just before and just after a major change (e.g.. changing
several interfaces)
When a new version ships
Version Trees
Each file in the database has a version tree
Can branch off the version tree to allow separate
development paths
Typically a main path (trunk) for the next major version
and branches off of shipped versions for maintenance
-
7/29/2019 Software Engineering New1 1062217755 2
51/165
Branching
When a new version ships, typically create a branch in the
version tree for maintenanceDouble update: fix a defect in the latest version and then
merge the changes (often by hand) into the maintenance
version
Also create personal versions so you can make a change
against a stable source base and then merge in the latest
version later
Examples
RCS
Solaris: man rcsintro
CVS
Solaris: man cvs
www.cyclic.com/cvs/info.html
Visual SourceSafe
msdn.microsoft.com/SSAFE
ClearCase
www.rational.com
RCS
File management only
Transaction model
check out and lock
edit
check in and unlock
Little support for binaries
-
7/29/2019 Software Engineering New1 1062217755 2
52/165
CVS
Built on top of RCS
Therefore little support for binaries
Database can be remote
No locking: merge before commit
Fast
Integrates with emacs
SourceSafe
Microsofts entry into the field
Project-based
Checkout-edit-checkin model
Built-in web site creation tools
Integrates with MSDEV
Clearcase
Clearcase is configuration management on steroids
You create a view of the database with a config spec,
which describes how to select files from the database.
When you set a view, Clearcase creates a virtual filesystem
containing only those versions of the files selected by the
config spec
-
7/29/2019 Software Engineering New1 1062217755 2
53/165
Clearcase Features
Distributed System
Several groups at different locations can work on the samedatabase
Can install triggers
Example: e-mail the author of a file when some one makes
a change to it
Uses merging model like CVS, but can also lock files
More Clearcase Features
Integrates with MSDEV
Build Management
Knows to rebuild out-of-date files even if your makefile
doesnt
Slow and a bit buggy
Helpful Rules for Version Control Bliss
Archived Files Should Always Compile
Code Review Files Before Check-in
Compile and run latest archived files *as a set* before
Check-in
No Cheating (even simple bug fixes need to undergo this
process)
-
7/29/2019 Software Engineering New1 1062217755 2
54/165
Software Engineering
Lecture 10
Formal Specification
Formal Specification
Why?
Precise standard to define and validate software
Why not?
May be time consuming
Methods not suitable for all applications
Formal Specification
Ben Potter, Jane Sinclair, David Till,
An Introduction to Formal Specification and Z
(Prentice Hall) 1991
Jonathan Jacky
The Way of Z
(Cambridge University Press) 1997
-
7/29/2019 Software Engineering New1 1062217755 2
55/165
Mathematical Specification
Example of specifi cation
B1,B2, ...Bkis a sequence ofm x m matrices
1, 2, ... kis a sequence ofm x m elementarymatrices
B1-1 = 1
B2-1 = 21
Bk-1 = k ... 21
The numerical accuracy must be such that, for all k,
BkBk-1 - I <
Specification of Programming Languages
::= |
::= {}
::= . {} |
. {} E |
E
::= |
::= + | -
Pascal number syntax
Formal Specification Using Diagrams
digit
unsigned in teger
digit. E
+
-
unsigned integerunsigned integer
unsigned number
-
7/29/2019 Software Engineering New1 1062217755 2
56/165
Two Rules
Formal specification does not guarantee correctness
Formal specification does not prescribe the implementation
Informal: The function intrt(a) returns the largest integer
whose square is less than or equal to a.
Formal (Z):
intrt:N N
a : N
intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)
Example: Z Specification Language
Example: Algorithm
1 + 3 + 5 + ... (2n - 1) = n2
-
7/29/2019 Software Engineering New1 1062217755 2
57/165
Example: Program
int intrt (int a)
/* Calculate integer square root */{
int i, term, sum;
term = 1; sum = 1;
for (i = 0; sum
-
7/29/2019 Software Engineering New1 1062217755 2
58/165
State Transition Diagram
Patients Fields Setup ReadyBeam
on
Enter Enter Start
Stop
Select field
Select patient
(interlock)
(ok)
State Transition Table
Select
Patient
Select
FieldEnter ok Start Stop interlock
Patients
Fields
Setup
Ready
Beam
on
Fields
Fields
Fields
Patients
Patients
Patients
Setup
Setup
Setup
Ready
Beamon
Ready
Z Specification
STATE::=patients |fields |setup | ready | beam_on
EVENT::=select_patient|select_field| enter|start|stop
| ok| interlock
FSM == (STATEXEVENT) STATE
no_change, transitions, control:FSM
Continued on next slide
-
7/29/2019 Software Engineering New1 1062217755 2
59/165
Z Specification (continued)
control= no_change transitions
no_change = {s : STATE; e :EVENT (s, e) s }
transitions = { (patients, enter) fields,
(fields, select_patient) patients, (fields, enter) setup,
(setup,select_patient) patients, (setup,select_field) fields,
(setup, ok) ready,
(ready,select_patient) patients, (ready,select_field) fields,
(ready,start) beam_on, (ready, interlock) setup,
(beam_on,stop) ready, (beam_on, interlock) setup }
Schemas
Schema:
The basic unit of formal specification.
Describes admissible states and operations of a
system.
LibSys: An Example of Z
Library system:
Stock of books
Registered users.
Each copy of a book has a unique identifier.
Some books on loan; other books on shelves available
for loan.
Maximum number of books that any user may have on
loan.
-
7/29/2019 Software Engineering New1 1062217755 2
60/165
LibSys: Operations
Issue a copy of a book to a reader.
Reader return a book.
Add a copy to the stock.
Remove a copy from the stock.
Inquire which books are on loan to a reader.
Inquire which readers has a particular copy of a book.
Register a new reader.
Cancel a reader's registration.
LibSys
Level of Detail:
Assume given sets:
Copy,Book,Reader
Global constant:
maxloans
Schemas Describing Operations
Naming conventi ons for objects:
Before: plain variables, e.g., r
After: with appended dash, e.g., r'
Input: with appended ?, e.g., r?
Output: with appended !, e.g., r!
-
7/29/2019 Software Engineering New1 1062217755 2
61/165
Operation: Issue a Book
Inputs: copy c?, reader r?
Copy must be shelved initially: c? shelved
Reader must be registered: r? readers
Reader must have less than maximum number of books on loan:
#(issued {r?}) < maxloans
Copy must be recorded as issued to the reader:
issued' = issued {c? r?}
The stock and the set of registered readers are unchanged:
stock'=stock; readers'= readers
Domain and Range
dom mX Y
x
ran m
y
m : X Y
dom m = { x X : y Y x y}
ran m = { yY : x X x y}
Operation: Issue a Book
stock,stock': Copy Book
issued, issued': Copy Reader
shelved,shelved': F Copy
readers, readers': FReader
c?: Copy; r? :Reader
[See next slide]
Issue
-
7/29/2019 Software Engineering New1 1062217755 2
62/165
Operation: Issue a Book (continued)
[See previous slide]
Issue
shelved dom issued= domstock
shelved' dom issued'= domstock'
shelved dom issued= ;shelved' dom issued'=
ran issued readers; ran issued' readers'r: readers #(issued {r}) maxloans
r: readers' #(issued' {r}) maxloans
c? shelved; r? readers; #(issued {r?}) < maxloans
issued' = issued {c? r?}stock'=stock; readers'= readers
there may not be an intuitive model
Navigation around large space
Conventions are growing over the years
=> scroll bars, buttons, help systems, sliders
=> good for users, good for designers
Menus
Easy for users to learn and use
Certain categories of error are avoided
Enables context-sensitive help
Major diffi culty is structure of lar ge menus
Scrolling menus (e.g., states of USA)
Hierarchical
Associated control panels
Menus plus command line
Users prefer br oad and shall ow to deep menu systems
-
7/29/2019 Software Engineering New1 1062217755 2
123/165
1
Information Presentation
Information tobe displayed
Presentation
software
Display
Information Presentation
Text
precise, unambiguous
fast to compute and transmit
Graphics
simple to comprehend
uses of color
shows variations
Help System Design
Help system design is dif fi cult!
Must prototype with mixed users
Categories of help:
=> Overview and general information
=> Specific or context information
=> Tutorials (general)
=> Cook books and wizards
=> Emergency ("I am in trouble ...")
Must have many routes to same information
Never blame the user!
-
7/29/2019 Software Engineering New1 1062217755 2
124/165
1
System Considerations of User
Interfaces
Personal computer cycles are there to be used
Any network transfer involves delay
Shared systems have unpredictable performance
Data validation often requires access to shared data
Mobile code poses security risks
Usability and Cost
Performance may be expensive in hardware or special
software development
User interface development may be a major part of a
software development project
Costs are multiplied if a user interface has to be used on
different computers or migrate to different versions of
systems
Web browsers provide a general purpose user interface that
others maintain
Extensibility in Web Browsers
Data types:helper applications, plug-ins
Protocols
HTTP, WAIS, Gopher, FTP, etc.
proxies
Executable code
CGI scripts at server
JavaScript at client
Java applets
Style sheets
-
7/29/2019 Software Engineering New1 1062217755 2
125/165
1
Web User Interface: Basic
Web serversWeb browser
Static pages from server
All interaction requires communication with server
Web User Interface: CGI Script
User interface
tables
CGI
Scripts
Web serversWeb browser
Scripts can configure pages Scripts can validate information
All interaction requires communication with server
Web User Interface: JavaScript
User interface
tables
CGI
Scripts
Web serversWeb browser
JavaScripts can validate information as typed
Some interactions are local
Server interaction constrained by web protocols
Java
Script
html
-
7/29/2019 Software Engineering New1 1062217755 2
126/165
1
Web User Interface: Applet
Any
server
Web serversWeb browser
Any executable code can run on client
Client can connect to any server
Applets
Device-Aware User Interfaces
Examples of devices:
desk-top computer, fast network connection
laptop computer, intermittent connectivity
PalmPilot, intermittent use of cradle
Smart telephone
Digital camera, camcorder
Device-aware user interfaces are aware of:
=> Performance of device
=> Connectivity
The Importance of Design
Good support f or users i s more than a cosmetic fl ouri sh
Elegant design, appropriate functionality, & responsive system:
=> a measurable difference to their effectiveness
A system that is hard to use:
=> users may fail to find important results,
or mis-interpret what they do find
=> user may give up in disgust
A computer system is only as good as the in terf ace it provi des to
its users
-
7/29/2019 Software Engineering New1 1062217755 2
127/165
1
Software Engineering
Lecture 19
Performance of Computer Systems
Moore's Law
Original version:
The density of transistors in an integrated circuit will double
every year. (Gordon Moore, Intel, 1965)
Current version:
Cost/performance of silicon chips doubles every 18 months.
Moore's Law and System Design
Design system: 2000
Production use: 2003
Withdrawn from production: 2013
Processor speeds: 1 1.9 28
Memory sizes: 1 1.9 28
Disk capacity: 1 2.2 51
System cost: 1 0.4 0.01
-
7/29/2019 Software Engineering New1 1062217755 2
128/165
1
Moore's Law: Rules of Thumb
Planning assumptions:
Every year:cost/performance of silicon chips improves 25%
cost/performance of magnetic media improves 30%
10 years = 100:1
20 years = 10,000:1
Parkinson's Law
Original: Work expands to fill the time available. (C.
Northcote Parkinson)
Planning assumptions:
(a) Demand will expand to use all the hardware available.
(b) Low prices will create new demands.
(c) Your software will be used on equipment that you have not
envisioned.
False Assumptions
Unix file system will never exceed 2 Gbytes (2 32bytes).
AppleTalk networks will never have more than 256 hosts (28bits).
GPS software will not last 1024 weeks.
Nobody at Dartmouth will ever earn more than $10,000 per month.
etc., etc., .....
-
7/29/2019 Software Engineering New1 1062217755 2
129/165
1
Moore's Law and the Long Term
1965 When?
Whatlevel?
2000?
Within your
working life?
Predicting System Performance
Mathematical models
Simulation
Direct measurement
Al l requir e detail ed understanding of the
in teracti on between softwar e and systems.
Queues
arrive wait in line service depart
Single server queue
-
7/29/2019 Software Engineering New1 1062217755 2
130/165
1
Queues
arrive wait in line
service
depart
Multi -server queue
Mathematical Models
Queueing theory
Good estimates of congestion can be made for single-
server queues with:
arrivals that are independent, random events
(Poisson process)
service times that follow families of distributions
(e.g., negative exponential, gamma)
Many of the results can be extended to multi-server
queues.
Utilization: Rule of Thumb
utilization =mean service time
mean inter-arrival time
When the utilization of any system component
exceeds 30%, be prepared for congestion.
-
7/29/2019 Software Engineering New1 1062217755 2
131/165
1
Behavior of Queues: Utilization
mean
delay
utilization10
Simulation
Model the system as set of states and events
advance simulated time
determine which events occurred
update state and event list
repeat
Discrete time simulation: Time is advanced in fixed steps
(e.g., 1 millisecond)
Next event simulation: Time is advanced to next eventEvents can be simulated by random variables (e.g., arrival
of next customer, completion of disk latency)
Timescale
Operations per second
CPU instruction: 400,000,000
Disk latency: 60
read: 25,000,000 bytes
Network LAN: 10,000,000 bytes
dial-up modem: 6,000 bytes
-
7/29/2019 Software Engineering New1 1062217755 2
132/165
1
Measurements on Operational Systems
Benchmarks: Run system on standard problemsets, sample inputs, or a simulated load on the system.
Instrumentation: Clock specific events.
Serial and Parallel Processing
Single thread v. multi-thread
e.g., Unixfork
Granularity of locks on data
e.g., record locking
Network congestion
e.g., back-off algorithms
Example: Performance of Disk Array
Each transaction must:
wait for specific disk platter
wait for I/O channel
signal to move heads on disk platter
wait for I/O channel
pause for disk rotation
read data
Close agreement between: results from queueing theory,
simulation, and direct measurement (within 15%).
-
7/29/2019 Software Engineering New1 1062217755 2
133/165
1
The Software Process
Requirements
Definition
System and
Software design
Programmingand Unit Testing
Integration and
System Testing
Operation and
Maintenance
Lecture 20
Coding Standards
Tools for Debugging 1
Software Engineering
Coding Standards
Or
How to Pound all of your odd-shaped
programmers into a one size fits all hole
-
7/29/2019 Software Engineering New1 1062217755 2
134/165
1
I think there may be a bug in Joes Code - Please Fix
func GreenEggsNHam(Not SamIAm, Green EggsNHam)
foreach Green TryThem in SamIAm
do EatThem(TryThem) = false
NotInACarNotOnABus(EggsNHam)
func NotInACarNotOnABus(Green EggsNHam)
EatThem(EggsNHam) = true
NotOnAPlane(EggsNHam)
foreach NotLikeThem SamIAm of EggsNHam do
if not EatThem(SamIAm) then
NotInACarNotOnABus(SamIAm)
IDoNotLikeThem(EggsNHam)
Joes Code Following a Sane Coding Standard . . .
func DepthFirstSearch(graph G, vertex v)
foreach vertex w in G
do Encountered(w) = false
RecursiveDFS(v)
func RecursiveDFS(vertex v)
Encountered(v) = true
PreVisit(v)
foreach neighbor w of v do
if not Encountered(w) then
RecursiveDFS(w)
PostVisit(v)
What are Coding Standards
Coding standards are guidelines for code style and documentation.
The dream is that any developer familiar with the guidelines can work
on any code that followed them.
Standards range from a simple series of stat ements to involved
documents.
-
7/29/2019 Software Engineering New1 1062217755 2
135/165
1
Areas Typically Covered
Program Design
Naming Conventions
Formatting Conventions
Documentation
Possibly Even Licensing
Why Have Coding Standards
Greater consistency between developers
Easier to develop and maintain
Saves time and money
Prime Directive
Document every time you violate a standard.
No standard is perfect for every application, but failure to
comply with your standards requires a comment
-
7/29/2019 Software Engineering New1 1062217755 2
136/165
1
Amblers Law of Standards
Industry Standards > organizational standards > project s tandards > no standards
The more commonly accepted a standard the easier it is for team members tocommunicate
Invent standards when necessary, but dont waste time creating something that you
wont be able to use later.
All languages have recommended coding standards available. It is well worth your
effort to find and use industry standards
Push for organizational standards whenever possible
Good Coding Style
Names
Use full English descriptors
Use mixed case to make names readable
Use abbreviations sparingly and consistently
Avoid long names
Avoid leading/trailing underscores
Documentation
Document the purpose of every variable
Document why something is done not just what
Accessors
use getVar() and setVar() functions on all class variable unless class is
being used solely as a data structure (OOP)
Member Functions Documentation
What and why member function does what it does
Parameters / return value
How function modifies object
Preconditions /Postconditions
Concurrency issues
Restrictions
Internal Documentation
Control Structures
Why as well as what the code does
Difficult or complex code
Processing order
-
7/29/2019 Software Engineering New1 1062217755 2
137/165
1
Three Rules
Coding standards neednt be onerous - find a standard that
works for your team.Standardize early - the effort to bring your old work into
the standard will be too great otherwise.
Encourage a culture where standards are followed.
Examples of Coding Standards
http://www.ambysoft.com/javaCodingStandards.html
http://www.swtech.com/java/codestd/
http://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.html
http://www.scriptics.com/doc/styleGuide.pdf
Software Engineering
Lecture 21
Dependable Systems I
Reliability
http://www.ambysoft.com/javaCodingStandards.htmlhttp://www.swtech.com/java/codestd/http://www.swtech.com/java/codestd/http://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://www.scriptics.com/doc/styleGuide.pdfhttp://www.scriptics.com/doc/styleGuide.pdfhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://www.swtech.com/java/codestd/http://www.swtech.com/java/codestd/http://www.swtech.com/java/codestd/http://www.ambysoft.com/javaCodingStandards.html -
7/29/2019 Software Engineering New1 1062217755 2
138/165
1
Software Reliability
Failure: Software does not deliver the service expected by
the user (e.g., mistake in requirements)
Fault: Programming or design error whereby the delivered
system does not conform to specification
Reliability: Probability of a failure occurring in operationaluse.
Perceived reliability: Depends upon:
user behavior
set of inputs
pain of failure
Reliability Metrics
Probability of failure on demand
Rate of failure occurrence (failure intensity)
Mean time between failures
Availability (up time)
Mean time to repair
Distribution of failures
Hypothetical example: Cars are safer thanairplane in accidents (failures) per hour, but lesssafe in failures per mile.
Reliability Metrics for Distributed Systems
Traditi onal metri cs are hard to apply in mul ti -component
systems:
In a big network, at a given moment something will be givingtrouble, but very few users will see it.
A system that has excellent average reliability may give
terrible service to certain users.
There are so many components that system administratorsrely on automatic reporting systems to identify problem areas.
-
7/29/2019 Software Engineering New1 1062217755 2
139/165
1
User Perception of Reliability
1. A personal computer that crashes frequently v. a machinethat is out of service for two days.
2. A database system that crashes frequently but comes back
quickly with no loss of data v. a system that fails once in three
years but data has to be restored from backup.
3. A system that does not fail but has unpredictable periods
when it runs very slowly.
Cost of Improved Reliability
$
Up time
99% 100%
Will you spend your money on new functionality
or improved reliability?
Specification of System Reliability
Example: ATM card reader
Failure class Example Metric
Permanent System fails to operate 1 per 1,000 days
non-corrupting with any card -- reboot
Transient System can not read 1 in 1,000 transactions
non-corrupting an undamaged card
Corrupting A pattern of Never
transactions corrupts
database
-
7/29/2019 Software Engineering New1 1062217755 2
140/165
1
Principles for Dependable Systems
The human mind can encompass only limited complexity:
=> Comprehensibility
=> Simplicity
=> Partitioning of complexity
Principles for Dependable Systems
High-quality has to be built-in
=> Each stage of development must be done well
=> Testing and correction does not lead to quality
=> Changes should be incorporated into the structure
Quality Management Processes
Assumption:
Good processes lead to good software
The importance of routine:
Standard terminology (requirements, specification,
design, etc.)
Software standards (naming conventions, etc.)
Internal and external documentation
Reporting procedures
-
7/29/2019 Software Engineering New1 1062217755 2
141/165
1
Quality Management Processes
Change management:Source code management and version control
Tracking of change requests and bug reports
Procedures for changing requirements specifications,
designs and other documentation
Release control
Design and Code Reviews
Colleagues review each other's work:
can be applied to any stage of software development
can be formal or informal
The developer provides colleagues with:
documentation (e.g., specification or design), or code listing
talks through the work while answering questions
Most effective when developer and reviewers prepare well
Benefits of Design and Code Reviews
Benefits: Extra eyes spot mistakes, suggest improvements
Colleagues share expertise; helps with training
An occasion to tidy loose ends
Incompatibilities between modules can be identified
Helps scheduling and management control
Fundamental requirements:
Senior team members must show leadership
Must be helpful, not threatening
-
7/29/2019 Software Engineering New1 1062217755 2
142/165
1
Process (Plan) Reviews
Objectives:
To review progress against plan (formal or informal)
To adjust plan (schedule, team assignments,
functionality, etc.)
Impact on quality:
Good quality systems usually result from plans that are
demanding but realistic
Good people like to be stretched and to work hard, but
must not be pressed beyond their capabilit ies.
Statistical Testing
Determine the operational profile of the software
Select or generate a profile of test data
Apply test data to system, record failure patterns
Compute statistical values of metrics under test conditions
Statistical Testing
Advantages:
Can test with very large numbers of transactions
Can test with extreme cases (high loads, restarts, disruptions)
Can repeat after system modifications
Disadvantages:
Uncertainty in operational profile (unlikely inputs)
Expensive
Can never prove high reliability
-
7/29/2019 Software Engineering New1 1062217755 2
143/165
1
Error Avoidance
Risky programming constructs
Pointers
Dynamic memory allocation
Floating-point numbers
Parallelism
Recursion
Interrupts
All are valuable in certain circumstances, but
should be used with discretion
Defensive Programming
Mu rphy's Law:If anything can go wrong, it will.
Defensive Programming:
Redundant code is incorporated to check system state aftermodifications
Implicit assumptions are tested explicitly
Defensive Programming Examples
Use boolean variable not integer
Test i
-
7/29/2019 Software Engineering New1 1062217755 2
144/165
1
Some Notable Bugs
Built-in function in Fortran compiler (e0 = 0)
Japanese microcode for Honeywell DPS virtual memory
The microfilm plotter with the missing byte (1:1023)
The Sun 3 page fault that IBM paid to fix
Left handed rotation in the graphics package
Good people work around problems.
The best people track them down and f ix them!
Software Engineering
Lecture 22
Dependable Systems II
Validation and Verification
Defensive Programming
Mu rphy's Law:If anything can go wrong, it will.
Defensive Programming:
Redundant code is incorporated to check system state after
modifications
Implicit assumptions are tested explicitly
-
7/29/2019 Software Engineering New1 1062217755 2
145/165
1
Defensive Programming Examples
Use boolean variable not integer
Test i
-
7/29/2019 Software Engineering New1 1062217755 2
146/165
1
Fault Tolerance
Backwar d Recovery:
Record system state at specific events (checkpoints). After
failure, recreate state at last checkpoint.
Combine checkpoints with system log that allows
transactions from last checkpoint to be repeated automatically.
Fault Tolerance
General Approach:
Failure detection
Damage assessment
Fault recovery
Fault repair
N-version programming -- Execute independentimpl ementation in parall el, compare result s, accept the
most probable.
Validation and Verification
Validation: Are we building the right product?
Verification: Are we building the product right?
In practice, it is sometimes difficult to distinguish between
the two.
That's not a bug. That's a feature!
-
7/29/2019 Software Engineering New1 1062217755 2
147/165
1
Cleanroom Software Development
Software development process that aims to develop zero-defect
software.
Formal specification
Incremental development with customer input
Constrained programming options
Static verification
Statistical testing
I t is always better to prevent defects than to remove them later.
Example: The four color problem.
Static and Dynamic Verification
Static veri fi cation:Techniques of verification that do not
include execution of the software.
May be manual or use computer tools.
Dynamic verification
Testing the software with trial data.
Debugging to remove errors.
Static Validation & Verification
Carried out throughout the software development process.
Validation &
verification
Requirements
specification Design Program
-
7/29/2019 Software Engineering New1 1062217755 2
148/165
1
Static Verification: Program Inspections
Program reviews whose objective is to detect faults
Code may be read or reviewed line by line.
150 to 250 lines of code in 2 hour meeting.
Use checklist of common errors.
Requires team commitment, e.g., trained leaders
So effective that it can replace unit testing
Inspection Checklist: Common Errors
Data faults: Initialization, constants, array bounds, character strings
Control faults: Conditions, loop termination, compound statements,
case statements
Input/output faults: All inputs used; all outputs assigned a value
Interface faults: Parameter numbers, types, and order; structures and
shared memory
Storage management faults: Modification of links, allocation and de-allocation of memory
Exceptions: Possible errors, error handlers
Static Analysis Tools
Program analyzers scan the source of a program forpossible
faults and anomalies (e.g., Lint for C programs).
Control flow: loops with multiple exit or entry points
Data use: Undeclared or uninitialized variables, unused
variables, multiple assignments, array bounds
Interface faults: Parameter mismatches, non-use of
functions results, uncalled procedures
Storage management: Unassigned pointers, pointer
arithmetic
-
7/29/2019 Software Engineering New1 1062217755 2
149/165
1
Static Analysis Tools (continued)
Cross-reference table: Shows every use of a variable,
procedure, object, etc.
Information flow analysis: Identifies input variables on which
an output depends.
Path analysis: Identifies all possible paths through the
program.
Test Design
Testing can never prove that a system is corr ect. I t can only
show that (a) a system is correct in a special case, or (b) that i t
has a fault .
The objective of testing is to find faults.
Testing is never comprehensive.
Testing is expensive.
Testing and Debugging
Testing is most eff ective if di vided into stages:
Unit testing at various levels of granularity
tests by the developer
emphasis is on accuracy of actual code
System and sub-system testing
uses trial data
emphasis is on integration and interfaces
Acceptance testing
uses real data in realistic situations
emphasis is on meeting requirements
-
7/29/2019 Software Engineering New1 1062217755 2
150/165
1
Acceptance Testing
Alpha Testing: Clients operate the system in a realisticbut non-production environment
Beta Testing: Clients operate the system in a carefullymonitored production environment
Parallel Testing: Clients operate new system alongsideold production system with same data and compare
results
The Testing Process
System and Acceptance Testing is a major par t of a software
project
It requires time on the schedule
It may require substantial investment in datasets,
equipment, and test software.
Good testing requires good people!
Management and client reports are important parts oftesting.
What is the definition of "done"?
Testing Strategies
Bottom-up testing. Each unit is tested with its own test
environment.
Top-down testing. Large components are tested with
dummy stubs.
user interfaces
work-flowclient and management demonstrations
Stress testing. Tests the system at and beyond its limits.
real-time systems
transaction processing
-
7/29/2019 Software Engineering New1 1062217755 2
151/165
1
Test Cases
Test cases are specific tests that are chosen because they are
likely to find faults.
Test cases are chosen to balance expense against chance of
finding serious faults.
Cases chosen by the development team are effective intesting known vulnerable areas.
Cases chosen by experienced outsiders and clients will be
effective in finding gaps left by the developers.
Cases chosen by inexperienced users will find other
faults.
Test Case Selection: Coverage of Inputs
Objective is to test all c lasses of input
Classes of data -- major categories of transaction and
data inputs.
Cornell example: (undergraduate, graduate, transfer, ...)
by (college, school, program, ...) by (standing) by (...)
Ranges of data -- typical values, extremes
Invalid data, reversals, and special cases.
Test Case Selection: Program
Objective is to test all functions of each computer program
Paths through the computer programs
Program flow graph
Check that every path is executed at least once
Dynamic program analyzers
Count number of times each path is executed
Highlight or color source code
Can not be used with time critical software
-
7/29/2019 Software Engineering New1 1062217755 2
152/165
1
Program Flow Graph
if-then-elseloop-while
Fixing Bugs
Isolate the bug
Intermittent --> repeatable
Complex example --> simple example
Understand the bug
Root cause
Dependencies
Structural interactions
Fix the bugDesign changes
Documentation changesCode changes
Moving the Bugs Around
Fi xin g bugs is an err or-prone process!
When you fix a bug, fix its environment
Bug fixes need static and dynamic testing
Repeat all tests that have the slightest relevance(regression testing)
Bugs have a habit of r eturning!
When a bug is fixed, add the failure case to the test suite
for the future.
-
7/29/2019 Software Engineering New1 1062217755 2
153/165
1
Regression Testing
Applied to modified software to provide confidence thatmodifications behave as intended and do not adversely
affect the behavior of unmodified code.
Basic technique is to repeat entire testing process after
every change, however small.
Real Time Software Development
Testing and debugging need special tool s and
environments
Debuggers, etc., can not be used to test real timeperformance
Simulation of environment may be needed to testinterfaces -- e.g., adjustable clock speed
General purpose tools may not be available
Software Engineering for Real Time
The special characteristics of real time computing require
extra attention to good software engineering principles:
Requirements analysis and specification
Development of tools
Modular design
Exhaustive testing
Heroic programming will fail!
-
7/29/2019 Software Engineering New1 1062217755 2
154/165
1
Software Engineering
Management III
Managing People
Administration
Return of laptops and wireless cards
-> Dates for return will be announced on "Notices"
-> All equipment must be returned before the
examination. Bring the receipt to the exam.
-> If an extension granted, (e.g., independent
research) must return and be issued again
I f any repair s needed, please swap for replacement sin cewarrant y runs out on December 15.
Administration
Early examination
December 7, 10:00 to 11:30, Upson 5130
Send email to [email protected] if you plan
to take the early examination, by December 5
Al l laptops and wir eless cards must be retur ned
before the examination
-
7/29/2019 Software Engineering New1 1062217755 2
155/165
1
Managing People
Theoretical: Organizational behavior
Industrial psychology
Group behavior
Cognitive fundamentals
Economic motivation
Maslow's Hierarchy of Needs
Self-realization needs
Esteem needs
Social needs
Safety needs
Physiological needs
Software Engineering Basics
Professional staff are the major cost of software
Professional staff vary greatly in productivity
=> Ability
=> Education and training
=> Motivation
=> Interaction with colleagues and leaders
=> Work environment
People are productive when happy and happy when
productive
-
7/29/2019 Software Engineering New1 1062217755 2
156/165
1
Software is Built by Teams
Best size for a team is 3 to 8 people
Team members may include:
developers (from trainee to expert)
domain experts
graphic or interface designers
software librarians
testers
Teams must have:
administrative leadership (manager)
technical leadership
Group Working
50%
interaction
with
others
20%
non-productive
30%
working alone
Communication
InformalKitchen, smokers' doorway, after work, etc.
Walkabout (tours)
Ad hoc meetings
Staff meetings (non-technical)
Example:Tektronics
Technical meetings
Facilitation
Record of decisions
-
7/29/2019 Software Engineering New1 1062217755 2
157/165
1
Administrative Leader (Manager)
Personnel
Assigning tasksHiring, promoting, etc.
Resources
Budgets
Space, facilities
Equipment
Project management
Relationships with other teams and clients
Project plan and schedule
Hiring Criteria
Productivity is a combination of:
Analytic ability
Verbal ability and communication skills
Education
Application domain knowledge
Adaptability and inquisitiveness
Personality and attitude
Platform experience
Programming language experience
Staff Retention
Technically interesting workup to date hardware and software
opportunities to learn and experiment
Feeling of appreciation
management recognition
money and promotion
Working conditions
space, light, noise, parking
flexibility
Organizational dynamics
-
7/29/2019 Software Engineering New1 1062217755 2
158/165
1
Firmness
Managers must be fi rm when needed:
Assignment of tasks must be equitable and open;
everybody will have to tackle some of the dreary tasks
Carrots are better than sticks, but poor performance must
be addressed.
Nobody is indispensable; nobody should be allowed to
think that they are indispensable
Technical Challenges
Canceling projects
Example: the Andrew window manager
Changes of environment
Example: the World Wide Web
Technical tinkering v. needed re-engineering
Turning a Group Around
To turn a weak group into a strong one is the greatestchallenge of leadership
The art of the possible
Promotion of the best over the old leaders
Using opportunities to reorganize
Resignations and terminations
Respect people who try, yet refuse to accept problem areas
Brutal and abrupt rarely equals persistent and fi rm
-
7/29/2019 Software Engineering New1 1062217755 2
159/165
1
How to be Led
As a jun ior member of a team, what can you do to make it
productive?
Software Engineering
Lecture 26
Risk in Software Engineering
Failures and Risks
Software development projects can fai l in many ways:
Bad software engineering
Late, over budget
Lack of function, f