SOFTWARE FAILURE
Ariane 5, Flight 501
Disintegration after 39 sec
$500M loss
Reason
Reused code from Ariane 4 with lower
maximum velocity
Overflow in the conversion from 64-bit floating
point number to a 16-bit signed integer
SOFTWARE MAINTENANCE! https://www.youtube.com/watch?v=gp_D8r-2hwk
http://www.cs.vu.nl/~hans/ariane5report.html 2
RELATIVE DISTRIBUTION OF SOFTWARE/HARDWARE
COSTS
100
Hardware
Development
Percent of total cost
60
Software
20
Maintenance
1955 1970 1985
Year
3
POINT TO PONDER
Why does software maintenance cost so much?
4
DEFINITION (IEEE)
Software Engineering is the application of a systematic,
disciplined, quantifiable approach to the
development, operation, and maintenance of software;
that is, the application of engineering to software
5
CENTRAL THEMES
SE is concerned with BIG you’re doing it together
programs software must effectively
complexity is an issue support users
software evolves involves different disciplines
development must be efficient SE is a balancing act
6
BUILDING SOFTWARE ~ BUILDING BRIDGES?
yes, and no
software is logical, rather than
physical
progress is hard to see (speed
progress)
software is not continuous
Tacoma Narrows bridge
https://www.youtube.com/watch?v=j-zczJXSxnw
7
BUILDING SOFTWARE - SIMPLE LIFE CYCLE MODEL
Design Testing
Problem Model Working System
Req. Specification System
Requirements
Engineering
Implementation Maintenance
8
SIMPLE LIFE CYCLE MODEL
Is this a good model
of how we go about?
Distinguishes global and local design phases
of how we should go about?
Phases may and usually will overlap
No strict linear progression ➔ Backtracking necessary
9
SIMPLE LIFE CYCLE MODEL
Earlier phases Later phases
Is this a good model
of how we go about?
Distinguishes global and local design phases
of how we should go about?
Phases may and usually will overlap
No strict linear progression ➔ Backtracking necessary
10
REQS ENGINEERING
yields a description of the problem to be solved
which functions
possible extensions
required documentation
performance requirements
Lead to imposed constraints
includes a feasibility study
➔ Software Requirements Specification (SRS) document
11
DESIGN
earliest design decisions captured in software architecture
Has major impact on the quality of the final system
decomposition into parts/components; what are the functions of, and
interfaces between, those components?
emphasis on what rather than how
Template for other systems (reusable components)
➔ Functional Specification Document (FSD)
12
IMPLEMENTATION
focus on individual components
not a bag of tricks
Take advantage of high-level programming notations e.g.
pseudocode, OOP
present-day languages have a module and/or class concept
➔ a working, flexible, robust, … software system
13
TESTING
Testing during and even before implementation
start testing activities in phase 1, on day 1
does the software do what it is supposed to do?
are we building the right system? (validation)
are we building the system right? (verification)
➔ a TESTED working, flexible, robust, … software system
14
MAINTENANCE
correcting errors found after the software has been delivered
adapting the software to changing requirements, changing
environments, ...
➔ a MAINTAINED working, flexible, robust, … software system
15
DOCUMENTATION
Includes
Project Plan / Business Requirements
Quality Assurance Plan
Software Requirements Specification
Functional Specification
Architecture Description
Design Documentation
User Interface Requirements
Test plan
Often seen as a balancing item
Important element: user manuals (task oriented)
16
GLOBAL DISTRIBUTION OF EFFORT
40-20-40 rule
requirement
engineering
20% Only 20% spent on coding
testing Put more energy on
45%
design requirements rather than
15%
removing errors while testing
➔ The longer you postpone
implementation
20% coding, the earlier you are
finished
17
GLOBAL DISTRIBUTION OF EFFORT
beware: maintenance alone consumes 50-75% of total effort
testing
implementation
design
requirement engineering
maintenance
70%
18
KINDS OF MAINTENANCE ACTIVITIES
Corrective
correcting errors
Adaptive
adapting to changes in the environment
(both hardware and software)
Perfective
adapting to changing user requirements
Preventive
Increasing future maintainability (adding
comments, updating documentation)
19
DISTRIBUTION OF MAINTENANCE ACTIVITIES
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
20
POINT TO PONDER
You are a tester, and the product you are testing does not yet meet
the testing requirements agreed upon in writing. Your manager
wants to ship the product now, continue testing so that the next
release will meet the testing requirements. What do you do?
Discuss the issue with your manager?
Talk to the manager’s boss?
Talk to the customer?
21
HAMMURABI’S CODE
64: If a builder build a house for a man and do not make its
construction firm, and the house which he has built collapse and
cause the death of the owner of the house, that builder shall be put
to death.
73: If it cause the death of a son of the owner of the house, they shall
put to death a son of that builder.
22
SOFTWARE ENGINEERING ETHICS - PRINCIPLES
IEEE Computer Society and ACM jointly
developed a code of ethics for software
engineers
Principles and clauses
statements of aspirations
Obligations of professionals
Professional behavior within software
engineering
https://ethics.acm.org/code-of-
ethics/software-engineering-code/
23
SOFTWARE ENGINEERING ETHICS - PRINCIPLES
▪ Act consistently with the public interest
▪ Act in a manner that is in the best interest of the client and employer
▪ Ensure products meet the highest professional standards possible
▪ Maintain integrity in professional judgment
▪ Managers shall promote an ethical approach
▪ Advance the integrity and reputation of the profession
▪ Be fair to and supportive of colleagues
▪ Participate in lifelong learning and promote an ethical approach for
yourself
24
IN THE PREVIOUS CASE
Approve software only if you have a As a manager, do not ask a software
well-founded belief that it is safe, engineer to do anything inconsistent
meets specifications, passes with this code of ethics (clause 5.11).
appropriate tests, and does not
Be accurate in stating the
diminish quality of life or privacy or
characteristics of software on which
harm the environment (clause
you work, avoiding not only false
1.031).
claims but also claims that might be
Ensure adequate testing, supposed to be speculative,
debugging, and review of software vacuous, deceptive, misleading, or
and related documents on which doubtful (clause 6.07).
you work (clause 3.10).
25
26
BREAK
SOFTWARE DEVELOPMENT ASPECTS
Technical aspects of software development
Design
Specification
Implementation
Testing
Organizational and managerial aspects are as important as
technical aspects
27
SOFTWARE DEVELOPMENT ASPECTS
Software project not started in
complete isolation
Meta-project planning process
• Tune project to other projects within
organization
28
EXAMPLE: INFORMATION PLAN OF A UNIVERSITY
REGISTRATION OF STUDENT DATA
Relations to other systems: personal data, courses, course results,
alumni, …
Use both by central administration, at faculty level, and possibly by
students themselves
Requires training courses to administrative personnel
Authorization/security procedures
Auditing procedures
External links, e.g. to scholarship funding agencies, ministry of
education
29
A BROADER VIEW ON SOFTWARE DEVELOPMENT
Meta-project planning information planning Overall guidelines set by organization
boundary • Use of certain standards
• Data interchange formats
conditions • Security policies
• Webpage layout
documentation people
software
program
input output
program
Interact with existing software
Software development project is Extend existing software
a misnomer Use existing subroutine libraries
procedures
➔ Develop full systems
30
A BROADER VIEW ON
SOFTWARE DEVELOPMENT
The project system encompasses a
number of components
Collectively provide us with desired
functionality
➔Planning the project
▪ Identify project characteristics
▪ Impact on development process
▪ Document: project plan/Business
Requirement (BRD)
31
DOCUMENTATION
Includes
Project Plan / Business Requirements
Quality Assurance Plan
Software Requirements Specification
Functional Specification
Architecture Description
Design Documentation
User Interface Requirements
Test plan
Often seen as a balancing item
Important element: user manuals (task oriented)
32
CONTENTS OF PROJECT PLAN
Standards,
Process Organization Management
Introduction Guidelines,
Model of Project Activities
Procedures
Methods and Quality Work
Risks Staffing
Techniques Assurance Packages
Budget and
Resources Changes Delivery
Schedule
This is part of Senior I course
33
INTRODUCTION
Background and history
Scope
Aims
Project deliverables
Names of persons responsible
Summary of the project
34
PROCESS MODEL
Decide upon the process model to be followed
Activities undertaken
Milestones identified
More on this next lecture
35
PROJECT ORGANIZATION
Relationship of project to other entities
User organization
Parent organization
Others
Users
Information
Services
Resources
Identify roles and responsibilities of the project team
36
TEAM ORGANIZATIONS
Hierarchical team Matrix organization Chief programmer team Agile team Open source
•people are divided into •Chief programmer •Skilled wit advanced development
•following a tree
structure. specialist groups. •Project assistant tools •Team divided into layers
•People at bottom level •Each group has a •Project secretary •Short communication with more people in
possess most detailed manager •specialists channels outer layers
knowledge about the •Less discipline enforced
system.
•People at higher levels
have broader view
37
SOME GENERAL RULES
Use fewer, and better, people
Fit tasks to people
Help people to get the most out of themselves
Look for a well-balanced team
If someone doesn’t fit the team: remove him/her
38
STANDARDS, GUIDELINES
AND PROCEDURES
Strong working discipline
Clear agreements about documentation
Described in separate documents
Configuration Control Plan
Quality Assurance Plan
39
MANAGEMENT ACTIVITIES
Goals and activities set for the project
For instance
Submit regular reports on project progress status
Follow certain priorities
Requirements
Schedule
Cost
40
RISKS
Risk management is project management for adults
In software development, we tend to ignore risks:
We’ll solve the problem on time
Requirements will be stable
No one will leave the project
…
41
TOP TEN RISK FACTORS
Personnel shortfall
Unrealistic schedule/budget
Wrong functionality
Wrong user interface
Gold-plating
Requirement's volatility
Bad external components
Bad external tasks
Real-time shortfalls
Capability shortfalls
42
RISK MANAGEMENT STRATEGY
Identify risk
Handle risks
factors
Develop Assess risk
strategies to exposure
mitigate risks (probability *
• Avoid, transfer, or effect)
accept
43
STAFFING
At different phases require different number of personnel with
different skills
Identify personnel
Start
Duration
Amount
Expertise
44
METHODS AND TECHNIQUES
Methods and techniques used during
requirements engineering
Implementation
Testing
Test environment
Test equipment
More about testing later in the course
45
QUALITY ASSURANCE
Quality of the product versus quality of the
process
Check whether (product or process)
conforms to certain norms
Improve quality by improving the product or
process
incorporates all software development
processes starting from defining
requirements to coding until release
46
SQA PLAN DOCUMENT
The SQA plan document consists of the below sections:
1. Purpose section
2. Reference section
3. Software configuration management section
4. Problem reporting and corrective action section
5. Tools, technologies and methodologies section
6. Code control section
7. Records: Collection, maintenance and retention section
8. Testing methodology
48
WORK PACKAGES
Break large products into activities
Work breakdown structure
Decomposition of the project
49
RESOURCES
Hardware
CPU cycles
Tools needed to support project
Personnel needed for various process
phases
50
BUDGET AND SCHEDULE
Total budget depending on work breakdown structure
PERT chart for scheduling activities
More on this later in the course
51
CHANGES
Deal with inevitable changes in an orderly way
Clear procedures on how they will be handled
In the context of configuration control plan
52
DELIVERY
Procedure to be followed in handing over the system to the
customer
53
PROJECT PLAN
Provides a clear picture of the project to both the customers and
the project team
Careful planning early on leads to fewer surprises
Gives orderly procedures for dealing with future events
54
PROJECT CONTROL
Exert control along the following dimensions during project execution
Time
Informa
Money
tion
Project
Control
Organi
Quality
zation
55
MANAGING TIME
Measuring progress is hard (“we spent half the money,
so we must be halfway”)
Development models serve to manage time
More people less time?
Brooks’ law: adding people to a late project makes it later
56
MANAGING INFORMATION
Documentation
Technical documentation
Current state of projects
Changes agree upon
…
Agile projects: less attention to explicit documentation, more on
implied knowledge held by people
57
MANAGING PEOPLE
Managing expectations
Building a team
Coordination of work
58
MANAGING QUALITY
Quality has to be designed in
Quality is not an afterthought
Quality requirements often conflict with each other
Requires frequent interaction with stakeholders
59
MANAGING COST
Which factors influence cost?
What influences productivity?
Relation between cost and schedule
60
READING REFERENCE
61
SOFTWARE
LIFECYCLE
REVISITED
62
