Software Engineering Introduction
Pepper
(with credit to both Dr. Chays and
Ian Sommerville book slides)
My Contact Info

My office hours:
 Office:
POST 103 1rst Floor (or in lab Post
102)
 Office Hours:
Monday
8:20 - 8:50; 11:00 – 12:00 ;
1:00 – 2:15
Wednesday 8:20 - 8:50; 11:00 - 12:00
Friday
8:20 - 8:50; 11:00 – 12:15
 Email: pepper@adelphi.edu
My phone: 516-297-5241
 My Web: www.adelphi.edu/~pe16132
 Moodle: ecampus.adelphi.edu

Major Course Objectives

Identify kinds of users, scenarios, and usecases in business systems




for systems presented in class
for one system you design
for one system with you as the designated user
Experiment with using both iterative
(ex:Agile) and plan based (ex: Waterfall)
methodologies to design a new small system.
The design documentation - UML diagrams
 Requirements analysis, select test cases, design
and implement, test, and document.
 Use design patterns (briefly)
 Change management – GIT

Why take this course







Design code without explicit direction
 Code multiple classes that work together without
the professor giving the design
 Some design patterns
Work with users as you will in many businesses
See how your coding skills may be used in business
Get a feel for some different levels of career
opportunities
Acquire language to discuss the software process for
successful design and for interviews
Learn diagrams that help you communicate software
design with users and programmers
Learn how to test programs well and at many levels
Assignments
 Homework Exercises
-
NOT ACCEPTED LATE
 Due before class starts

Project - penalty for lateness
 Everyone
is assigned to a development team of 3
people
 Each team will serve as a design/coding group plus
also a user group for another team.
 Each team chooses one system to work with
throughout the course.
 Partial team submissions accepted
 Writiing quality counts
Business 1
Business 2
User team
D&E&F
A&B&C
Tech team
A&B&C
D&E&F
Textbook







Sommerville, Ian. Software Engineering,
New York: Addison-Wesley, 2011 edition 8
or 9 or 10 ISBN of edition 10:
9780133943030
UML Distilled by Martin Fowler
Practical Software Development Techniques. By
Crookshanks, Edward
Design Patterns, by Erich Gamma et al
Object-Oriented Software Engineering, by Bernd
Bruegge et al
Project-Based Software Engineering: An ObjectOriented Approach, Evelyn Stiller et al
The Mythical Man-Month, by Frederick Brooks,
Textbook Case studies

A personal insulin pump
 An
embedded system in an insulin pump used by
diabetics to maintain blood glucose control.

A mental health case patient management
system
A
system used to maintain records of people
receiving care for mental health problems.

A wilderness weather station
A
data collection system that collects data about
weather conditions in remote areas.
Chapter 1 Introduction
7
Why do we need this course?

Why engineer software?
 Can’t
we just hack at it, until we get something
that works?
Many people/companies do this anyway…

Answer: can’t hack it if we care about
quality
 If
a system is not put together in a wellorganized manner, the chance for bugs is greater

Another Answer: You can’t just hack
together a 106 LOC system
 Complex
systems are impossible to build in an adhoc manner

Some more Answers: Budget and Contract
Introduction: software quality
Software is often buggy
 In critical applications, bugs can lead to
drastic consequences

 Therac-25
malfunctions killed or severely injured
several people in 1985-87
 Ariane 5 launcher crash on 4/6/1996
 Airbus problems
 Banking software failures
 Healthcare Exchange
http://www.cio.com/article/2380827/developer/developer-6-software-development-lessons-fromhealthcare-gov-s-failed-launch.html
The main reason for bugs is enormous
complexity of software
 Need techniques to cope with this complexity

Quality Issues

Software is now an integral part of every
facet of our societal infrastructure
 Air
traffic control
 Telecommunication
 Financial infrastructure
Poor quality software menaces the
maintenance of that infrastructure
 Software is the "Grand Enabler" holding the
key to scientific and engineering challenges

 Human
genome project
 Space exploration
 Weather prediction
Why isn’t software quality up to snuff?
deliver prototypes
 "leave it to the marketplace"
 unsophisticated consumers

 don't
know what they want
 tolerate high failure rates
"the computer is down"
"user error"
 misled by "coverups" in banking, finance,
communications
 lack of understanding of risks
Year 2000 (Y2K)
Web security
What is software?
Code
 Various design documents
 User manuals
 Development plans, timelines, and budgets
 Maintenance documents
 The way of producing software (process)

Desirable qualities of software systems

Reliability
 Performs
the required functions correctly
 The rate of failures is low

Maintainability
 Understandability
 Changeability
 Simplicity

Reusability
 The
solution to a problem should be as general as
possible
User friendliness
 Efficiency

Some interesting numbers - Quality Metrics

About 25% of s/w projects fail
 Failure
rate increases as the size of the project
increases

Costs about $100/LOC
 Ranges

Typical programmer produces about 30 LOCs
a day
 Ranges

between $10-$600
between 10-100 LOCs
25 faults/KLOC
 Ranges
between 3-100 faults/KLOC
Software Failures - more interesting numbers
Gartner found that 28% of IT projects with
budget exceeding $1 million fail.
 The Standish Group, when considering
projects of $10 million or more, said that

 52%
were challenged, meaning they faced budget,
schedule or user expectation issues,
 41% were failures
 6.4% were successful.

http://www.cio.com/article/2381459/regulati
on/healthcare-gov-may-be-a--black-swan.html
Software costs

Development costs
 generally
measured in hundreds to thousands of
dollars per delivered LOC
many artifacts associated with a line of code
 testing and analysis is usually 50% of this cost

Maintenance costs
 2-3
times as much as development
Software Costs
Development costs
reqts and design
code
15%
35%
testing
50%
Full lifecycle costs
code
reqts/design
testing
maintenance
Models
Software code is too complex to reason
about it directly
 Need a higher level representation, called
design

 Captures
only the most important relevant
characteristics of the problem
 Needs to capture the behavior of the problem
accurately

Software code must conform to its design
Software Engineering




Name coined at the NATO Science Committee
Conference, October 1968
Engineering-- established, scientifically sound
practices that well trained practitioners follow
Software Engineering-- the application of scientific
knowledge to the the development and maintenance
of software systems
Software-- ALL associated artifacts to assist with
the development, operation, validation, and
maintenance of programs/software systems

e.g., code, documentation, designs, requirements, user
manuals, installation manuals, test cases, test results, bug
reports, revision history, make files,...
Industry’s short term focus

"bottom line orientation"
 emphasis
on time to market
not life cycle
 return on investment

startups cannot invest in R&D until product
established in marketplace
 without
the R&D, takes too long for next or
improved product
 market strategy driven by investors who want
impressive short term gains
The nature of software
Software is a complex, intricately
interconnected data aggregate
 Software Development is the process of
creating such a complex product, while
continuously assuring that it remains
consistent
 Software Engineering is the systematic
design and management of the software
development.

What is novel about software, compared to
other fields of engineering?
 product is unprecedentedly complex
 application horizons expand too fast--with
human demands/imagination
 construction is human-intensive
 solutions require unusual rigor
 extremely malleable--can modify the product
all too easily
Barriers to engineering software
Industry’s short term focus
 Shortage of skilled personnel
 Inadequate investment in R&D
 Poor technology transfer models
 Insufficient standards

Industry’s short term focus

software houses
 intensely
competitive
 often don't use own technology
 keep development cost down, fix later

unsophisticated industries
 lack
of technical expertise
 lack of administrative experience

overselling the technology
Software Causing Disaster
http://www.wired.com/software/coolapps/new
s/2005/11/69355?currentPage=all
 Ariane 5 - rocket

 Module
from prior version of code not needed, but
not removed
 Backup system fails for same reason as main
system
 Failure sends directional commands, not seen as
failure code but taken as direction
 Velocity exceeded maximum for 16 bit unsigned
integer when converted from original 64 bit size
What do we need?
Scientific basis
 Organized discipline
 R&D strategy
 Trained professionals
 Technology transfer strategies
 Quality control

High-level Goals of Software
Engineering
 improve productivity
 reduce
resources
e.g., time, cost, personnel
improve predictability
 improve maintainability
 improve quality

How to increase Software Quality

Treat software as a PRODUCT produced in a
systematic way by a PROCESS designed and
implemented to achieve explicit quality
objectives
 Build
quality in
 Define software product formally
 Define software process formally
 Reason about the product and process formally
 Incorporate validation as integral steps in the
process
 Reuse when appropriate
 Consider incremental releases
Certification and Licensing?


Currently, software engineering is not one of the 36
engineering professions recognized and licensed in
the United States.
48 states prohibit using the term "engineer" without
a license
Texas has forced universities to stop MSSE
 Tennessee prohibits the use of "software engineering" in
business literature and advertising
 New Jersey considered, but did not pass, a regulation that
would have required licensing of all SW professionals



IEEE/CS & ACM established Commission on
Software Engineering in 1993
2009 Software Engineering Consortium

NCEES/IEEE Principles and Practices Exam of Software in
2013 – Not required
Software Process Models
•
•
•
Software Process Activities
General Model Types
Specific Models
The software process

Activities Needed
 Specification
– defining what the system should
do;
 Design and implementation (development) – defining
the organization of the system and implementing
the system;
 Validation – checking that it does what the
customer wants;
 Evolution – changing the system in response to
changing customer needs.

A software process model is an abstract
representation of a process.
Chapter 2 Software
31
Plan-driven and agile processes
Plan-driven processes are processes where all
of the process activities are planned in
advance and progress is measured against
this plan. (ex: waterfall)
 In incremental processes, planning is
incremental and it is easier to change the
process to reflect changing customer
requirements. (ex: Agile, Extreme
Programming)
 In practice, most practical processes include
elements of both plan-driven and agile
 There are no right or wrong software
processes.
Chapter 2 Software
32

No One Best Method

Heterogeneity
 distributed
systems across networks - different
types of computer and mobile devices.

Business and social change
 Business
and society changes
 Emerging economies
 New technologies

System types
 Embedded
– like insulin pump system
 Information / transactional – like medical records
 Data collection – like Wilderness Weather system

Developer skill levels
Chapter 1 Introduction
33
#1 Waterfall Method – Plan based with Gates
Requirements
reqts. analysis
System Design
validation
Coding (Implementation)
Unit test
Integration
System Test
Maintenance
revalidation
Waterfall Model - Requirements
 Requirements-- a complete,consistent
specification of what is needed
 Feasibility
study
Is it technically and financially feasible to
build the system?
 Requirements elicitation and analysis
What do the system stakeholders require or
expect from the system?
 Requirements specification
Defining the requirements in detail

Requirements analysis
Checking the validity, completeness and
correctness of the requirements
Risk Assessment
The requirements engineering process
Chapter 2 Software
36
Waterfall Model - Design

design specifications--a description of how
the requirements are to be realized
 high-level
architectural design
 low-level detailed design

design validation
 traceability
between requirements and design
decisions
 internal consistency
A general model of the design process
Chapter 2 Software
38
Waterfall Model - Implement
code--realization of the design in executable
instructions
 code validation – Unit Test

 assure
coding and documentation standards have
been maintained
 internal consistency
e.g., syntactic analysis, semantic analysis,
type
checking, interface consistency
 consistency between design/requirements and code
Waterfall Model Integrate and System Test
Integrate modules
 System testing--reveal problems,
demonstrate behavior, assess reliability,
evaluate
non-functional requirements
(e.g., performance, ease of use)

 integration
testing
 system testing
 acceptance testing
 regression testing
 testing validation
adequacy of the testcases
Stages of testing
Chapter 2 Software
41
Testing phases in a plan-driven software
process
Chapter 2 Software
42
Waterfall Model - Maintenance

maintenance--the process of modifying existing software
while leaving its primary functionality intact
corrective maintenance-- fix problems
(20%)
 adaptive maintenance-- add new functionality/enhance existing
features
(30%)
 perfective maintenance-- improve product (50%)
e.g., performance, maintainability



Regression Test
maintenance involves all the previous phases of the
lifecycle
System evolution
Chapter 2 Software
44
Is the waterfall model an appropriate
process model?


Recognizes distinct activities
Cheaper design before construction, but .. .
too long a wait before hands on result
 Business requirements can change before system goes live


Clear structure facilities multi-group dev, but .. .
Lower level surprises
 Programmer design changes


Actual processes are more complex
numerous iterations among phases
 not purely top down
 decomposition into subsystems


many variations of the waterfall model

Prototyping, re-engineering, risk reduction
#2 Incremental development
Chapter 2 Software
•
•
•
•
Prototypes
Phases
Agile Cycles
Test Releases
46
Incremental development benefits
The cost of accommodating changing
customer requirements is reduced. (less
analysis and doc)
 It is easier to get customer feedback on the
development work that has been done.
 More rapid delivery and deployment of useful
software to the customer is possible.
Incremental development problems
 The process is not visible.
 System structure tends to degrade as new
increments are added.

Chapter 2 Software
47
#3 Reuse-oriented software engineering
Chapter 2 Software
48
#4 Boehm’s spiral model
Chapter 2 Software
RISK
Adverse
49
Spiral model sectors

Objective setting
 Specific

objectives for the phase are identified.
Risk assessment and reduction
 Risks
are assessed and activities put in place to
reduce the key risks.

Development and validation
A
development model for the system is chosen
which can be any of the generic models.

Planning
 The
project is reviewed and the next phase of
the spiral is planned.

In practice – affects thought, but not used
Chapter 2 Software
50
#5: The Rational Unified Process
A modern generic process derived from the
work on the UML and associated process.
 Brings together aspects of the 3 generic
process models discussed previously.
 Normally described from 3 perspectives

A
dynamic perspective that shows phases over
time;
 A static perspective that shows process activities;
 A practice perspective that suggests good
practice.
Chapter 2 Software
51
Phases in the Rational Unified Process
High Level
Requirements
Requirements
Design / Architecture
Detail Design, Code, test
Deploy,
Train
Chapter 2 Software
52
RUP iteration

In-phase iteration
 Each
phase is iterative with results developed
incrementally.

Cross-phase iteration
 As
shown by the loop in the RUP model, the whole
set of phases may be enacted incrementally.
Chapter 2 Software
53
Static workflows in the Rational Unified
Process
Workflow
Description
Business modelling
The business processes are modelled using business
use cases.
Requirements
Actors who interact with the system are identified and
use cases are developed to model the system
requirements.
Analysis and design
A design model is created and documented using
architectural models, component models, object
models and sequence models.
Implementation
The components in the system are implemented and
structured
into
implementation
sub-systems.
Automatic code generation from design models helps
accelerate this process.
Chapter 2 Software
54
Static workflows in the Rational Unified
Process
Workflow
Description
Testing
Testing is an iterative process that is carried out in conjunction
with implementation. System testing follows the completion of
the implementation.
Deployment
A product release is created, distributed to users and installed in
their workplace.
Configuration
and This supporting workflow managed changes to the system (see
change management
Chapter 25).
Project management
This supporting workflow manages the system development (see
Chapters 22 and 23).
Environment
This workflow is concerned with making appropriate software
tools available to the software development team.
Chapter 2 Software
55
RUP good practice

Develop software iteratively
 customer

Manage requirements


priorities / deliver in increments
document initial and changed requirements.
Use component-based architectures

make reusable when possible
Visually model software using UML
 Verify software quality
 Control changes to software

 Change
management for requirements
 Configuration management for code
Chapter 2 Software
56
Summary - Software Process Models
Plan based – Waterfall
 Incremental – Agile
 Reuse COTS (commercial off the shelf)
 Boehm’s Spiral - Risk
 Rational Unified Process – UML iterative
phases

Ethics
Software engineering ethics
Software engineering involves wider
responsibilities than simply the application of
technical skills.
 Software engineers must behave in an honest
and ethically responsible way if they are to
be respected as professionals.
 Ethical behaviour is more than simply
upholding the law but involves following a set
of principles that are morally correct.

Issues of professional responsibility

Confidentiality
 Engineers
should normally respect the
confidentiality of their employers or clients
irrespective of whether or not a formal
confidentiality agreement has been signed.

Competence
 Engineers
should not misrepresent their level of
competence. They should not knowingly accept
work which is outwith their competence.
Issues of professional responsibility

Intellectual property rights


Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They
should be careful to ensure that the intellectual property of
employers and clients is protected.
Computer misuse

Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (game playing on an employer’s
machine, say) to extremely serious (dissemination of
viruses).
Ethical principles
ACM / IEEE-CS Code of Ethics
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and
maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the profession.
Chapter 1 Introduction
62
Ethical dilemmas
Disagreement in principle with the policies of
senior management.
 Your employer acts in an unethical way and
releases a safety-critical system without
finishing the testing of the system.
 Participation in the development of military
weapons systems or nuclear systems.

Summary
Course Structure
 Why Software Engineering is important
 Software Process Activities
 Software Process Models

 Plan
based – Waterfall
 Incremental – Agile
 Reuse COTS (commercial off the shelf)
 Boehm’s Spiral - Risk
 Rational Unified Process – UML iterative phases

Code of Ethics