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