31/03/2020

Lecture 1
 Software & Software Engineering

SK Alamgir Hossain
Associate Professor
CSE Discipline, Khulna University

What is Software?
(1) instructions (computer programs) that when executed provide
desired features, function, and performance;

(2) data structures that enable the programs to adequately

manipulate information and

(3) documentation that describes the operation and use of the

programs.

1
 31/03/2020

Software Characteristics
 Software is developed or engineered, it is not manufactured in the
classical sense.

 Although some similarities exist between software development and hardware

manufacture, the two activities are fundamentally different.
 In both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems that are
nonexistent (or easily corrected) for software.
 Both activities are dependent on people, but the relationship between people
applied and work accomplished is entirely different.
 Both activities require the construction of a "product" but the approaches are
different.
 Software costs are concentrated in engineering.
 This means that software projects cannot be managed as if they were
manufacturing projects.

Software Characteristics (Cont…)

 Software doesn't "wear out.“
 Figure 1.1 shows failure rate as a function of time for hardware. The relationship, often
called the "bathtub curve," indicates that hardware exhibits relatively high failure rates
early in its life (these failures are often attributable to design or manufacturing defects);
defects are corrected and the failure rate drops to a steady-state level.
 As time passes, however, the failure rate rises again as hardware components suffer from
the cumulative affects of dust, vibration, abuse, temperature extremes, and many other
environmental maladies. Stated simply, the hardware begins to wear out.
 Software is not susceptible to the environmental maladies that cause hardware to wear out.
In theory, therefore, the failure rate curve for software should take the form of the "idealized
curve" shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the
life of a program. However, these are corrected (ideally, without introducing other errors)
and the curve flattens as shown. The idealized curve is a gross over-simplification of actual
failure models for software. However, the implication is clear, software doesn’t wear out. But
it does deteriorate!

Figure 1.1: Hardware Failure Curve Figure 1.2: Software Idealized and Actual
4
Failure Curves

2
 31/03/2020

Software Applications
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software
 Web applications
 AI software

Software Engineering
 Software engineering is the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and works efficiently on real machines.

3
 31/03/2020

A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering

A Process Framework
 The software process is represented
schematically in Figure.
 Referring to the figure, each framework
activity is populated by a set of software
engineering actions.
 Each software engineering action is
defined by a task set that identifies the
work tasks that are to be completed,
the work products that will be produced,
the quality assurance points that will be
required, and the milestones that will be
used to indicate progress.

4
 31/03/2020

Framework Activities
 Communication
 Planning
 Modeling
 Construction
 Deployment

Umbrella Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management

10

5
 31/03/2020

Software Myths
 Affect managers, customers (and other non-technical
stakeholders) and practitioners
 Are believable because they often have elements of truth,

but …
 Invariably lead to bad decisions,

therefore …
 Insist on reality as you navigate your way through software
engineering

11

Management Myths
 “We already have a book of standards and procedures for building
software.

 “If my project is behind the schedule, I always can add more

programmers to it and catch up

 “If I decide to outsource the software project to a third party, I can

just relax: Let them build it, and I will just pocket my profits …”

12

6
 31/03/2020

Customer Myths
 “A general statement of objectives is sufficient to begin writing programs -
we can fill in the details later …”

 “Project requirements continually change but this change can easily be

accommodated because software is flexible …”

 “A general statement of objectives is sufficient to begin writing programs -

we can fill in the details later …”

13

Practitioner’s Myths
 “Let’s start coding ASAP, because once we write the program and
get it to work, our job is done …”

 “Until I get the program running, I have no way of assessing its

quality …”

 “The only deliverable work product for a successful project is the

working program …”

14

7
 31/03/2020

Any Question ?

15