CSE3001 SOFTWARE ENGINEERING

L T P J C
2 0 2 4 4

Dr. S M SATAPATHY
Associate Professor,
School of Computer Science and Engineering,
VIT Vellore, TN, India – 632 014.
SYLLABUS

2
 SYLLABUS :: MODULE-WISE OVERVIEW

1. OVERVIEW

2. SOFTWARE PROJECT MANAGEMENT

3. MODELLING - REQUIREMENTS

4. SOFTWARE DESIGN

5. VALIDATION AND VERIFICATION

6. SOFTWARE EVOLUTION

7. QUALITY ASSURNACE

8. RECENT TRENDS

3
 Module – 1

OVERVIEW OF SOFTWARE ENGINEERING

1. Nature of Software

2. Software Engineering

3. Software Process and Project

4. Process Models

4
INTRODUCTION

5
 Software
 Software is: (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.

 Software is developed or engineered, it is not manufactured in the

classical sense.
 Software doesn't “wear out”.

 Although the industry is moving toward component-based

construction, most software continues to be custom-built.
6
Wear vs. Deterioration

7
 Software Applications

 system software

 application software

 engineering/scientific software

 embedded software

 product-line software

 WebApps (Web applications)

 AI software

8
 Software Applications – New Categories
 Open world computing - pervasive, distributed computing
 Ubiquitous computing - wireless networks
 Netsourcing - the Web as a computing engine
 Open source – “free” source code open to the computing
community (a blessing, but also a potential curse!)

 Also …
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies

9
 Legacy Software

 Why must it change?

 software must be adapted to meet the needs of new computing

environments or technology.

 software must be enhanced to implement new business

requirements.

 software must be extended to make it interoperable with other

more modern systems or databases.

 software must be re-architected to make it viable within a

network environment.
10
What do you mean by Software Engineering?

11
 Software Engineering

 The seminal definition:

[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.

 The IEEE definition:

Software Engineering: (1) The application of a systematic,

disciplined, quantifiable approach to the development, operation,

and maintenance of software; that is, the application of engineering

to software. (2) The study of approaches as in (1).

12
 Programmer vs. Software Engineer

A programmer is a puh-tey-toh. A software developer is a puh-tah-toh.

A software engineer is a potato (in some states, a certified potato).

Got it?

13
Software Engineering

14
Software Engineering

15
 Software Engineering

STANDISH CHAOS REPORT 2015

 Traditional Definition: The project was resolved within a reasonable

estimated time, stayed within budget, and contained a good number

of the estimated features and functions.

16
 Software Engineering

STANDISH CHAOS REPORT 2015

 Modern Definition: The project was resolved within a reasonable

estimated time, stayed within budget, and delivered customer and

user satisfaction regardless of the original scope.

17
A Layered Technology

tools

methods

process model

a “quality” focus

Soft w are Engineering

18
 Process Framework

 Process framework

 Framework activities

 work tasks

 work products

 milestones & deliverables

 QA checkpoints

 Umbrella Activities

19
 Framework Activities

 Communication

 Planning

 Modeling

 Analysis of requirements

 Design

 Construction

 Code generation

 Testing

 Deployment
20
 Umbrella Activities

 Software project management

 Formal technical reviews (Decision Maker, Review Leader, Recorder, Technical

Staff, Management Staff, Customer / User Representative).

 Software quality assurance

 Software configuration management

 Work product preparation and production

 Reusability management

 Measurement

 Risk management
21
 The Essence of Practice

Polya suggests:

1. Understand the problem (communication and analysis).

2. Plan a solution (modeling and software design).

3. Carry out the plan (code generation).

4. Examine the result for accuracy (testing and quality assurance).

22
 Understand the Problem

 Who has a stake in the solution to the problem? That is, who are

the stakeholders?

 What are the unknowns? What data, functions, and features are

required to properly solve the problem?

 Can the problem be compartmentalized? Is it possible to

represent smaller problems that may be easier to understand?

 Can the problem be represented graphically? Can an analysis

model be created?

23
 Plan the Solution

 Have you seen similar problems before? Are there patterns that

are recognizable in a potential solution? Is there existing software

that implements the data, functions, and features that are required?

 Has a similar problem been solved? If so, are elements of the

solution reusable?

 Can sub-problems be defined? If so, are solutions readily

apparent for the sub-problems?

 Can you represent a solution in a manner that leads to effective

implementation? Can a design model be created?

24
 Carry out the Plan

 Does the solution conform to the plan? Is source code traceable

to the design model?

 Is each component part of the solution provably correct? Has

the design and code been reviewed, or better, have correctness

proofs been applied to algorithm?

25
 Examine the Result

 Is it possible to test each component part of the solution? Has a

reasonable testing strategy been implemented?

 Does the solution produce results that conform to the data,

functions, and features that are required? Has the software been

validated against all stakeholder requirements?

26
 Hooker’s General Principles

1: The Reason It All Exists

2: KISS (Keep It Simple, Stupid!)

3: Maintain the Vision

4: What You Produce, Others Will Consume

5: Be Open to the Future

6: Plan Ahead for Reuse

7: Think!

27
 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

28
 Software Myths (Management Perspectives)

 We already have a book that’s full of standards and procedures for

building software. Won’t that provide my people with everything they

need to know.

 If we get behind schedule, we can add more programmers and catch

up sometimes called the “Mongolian Horde” concept.

 Brooks [Bro95]: “Adding people to a late software project makes

it later.”

 If I decide to outsource the software project to a third party, I can just

relax and let that form build it.

29
 Software Myths (Customer Perspectives)

 A general statement of objectives is sufficient to begin writing

programs- We can fill in the details later.

 Software requirements continually change, but change can be easily

accommodated because software is flexible.

30
 Software Myths (Practitioner Perspectives)

 Once we write the program and get it to work, our job is done.

 “The sooner you begin ‘writing code’, the longer it’ll take you to

get 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.

 Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.

31
 Software Crisis
It was in late 1960’s

 Many software projects failed.

 Many software projects late, over budget, providing unreliable
software that is expensive to maintain.
 Many software projects produced software which did not satisfy the
requirements of the customer.
 Complexities of software projects increased as hardware capability
increased.
 Larger software system is more difficult and expensive to maintain.
 Demand of new software increased faster than ability to generate
new software.
32
 Software Crisis
 Software is unmaintainable due to:
 poor design, poor documentation (most software can be
understood only by its author, and then only within a few months
of writing it)
 Software is inefficient (new versions of complex software require
machine upgrades)
 Software is unreliable due to:
 poor design , inadequate testing (market pressures, beta
releases), impossible testing.
 Software is too complex.
 Complexity does not scale linearly: a 1000 line program is more
than 10 times as complex as a 100 line program
33
 Software Bug Examples
 The Explosion of Ariane 5 – 1996 – Faulty Data Conversion
 Therac-25 – 1985-1987
 USS Yorktown Incident – 1997 – Divide by Zero
 Sony CD Malicious Copy Protection – 2005 - rootkit
 Patriot Missile Bug – 1991 – resetting system clock
 Millennium Bug – 2000 – Y2K problem
 Year 2038 – 19th Jan 2038

34
 Cost of Software Production

• Roughly 60% of costs are development costs, 40% are testing

costs. For custom software, evolution costs often exceed

development costs.

• Costs vary depending on the type of system being developed and

the requirements of system attributes such as performance and

system reliability.

• Distribution of costs depends on the development model that is

used.

35
 Attributes of Good Software
 The software should deliver the required functionality and
performance to the user and should be maintainable, dependable
and acceptable.
 Maintainability
 Software must evolve to meet changing needs;
 Dependability
 Software must be trustworthy;
 Efficiency
 Software should not make wasteful use of system resources;
 Acceptability
 Software must accepted by the users for which it was designed.
This means it must be understandable, usable and compatible
with other systems. 36
 Key Challenges of Software Engineering

 Heterogeneity, delivery and trust.

 Heterogeneity

 Developing techniques for building software that can cope with

heterogeneous platforms and execution environments;

 Delivery

 Developing techniques that lead to faster delivery of software;

 Trust

 Developing techniques that demonstrate that software can be

trusted by its users.

37
 System Engineering
 Systems engineering is an interdisciplinary field of engineering that
focuses on how to design and manage complex engineering projects
over their life cycles.

 It is the sub discipline of engineering which deals with the overall

management of engineering projects during their life cycle (focusing
more on physical aspects).

 It deals with logistics, team coordination, automatic machinery

control, work processes and similar tools. Most of the times, System
Engineering overlaps with the concepts of industrial engineering,
control engineering, organizational and project management and
even software engineering. 38
 System Engineering vs. Software Engineering

 The difference between System Engineering and Software

Engineering is not very clear.

 However, it can be said that the System Engineers focus more on

users and domains, while Software Engineering focus more on n

implementing quality software.

 System Engineer may deal with a substantial amount of hardware

engineering, but typically software engineers will focus solely on

software components.
39
 Practice Questions
1. Why can’t we find all errors before we give the software to our
customers?

2. Why do we continue to have difficulty in measuring progress as

software is being developed and maintained?

3. Provide at least two number of examples (both positive and

negative) that indicate the impact of software on our society?

4. Many modern applications change frequently before they are

presented to the end user and then after the first versions have
been used. Suggest few ways to build software to stop deterioration
due to change. 40
 Practice Questions
5. Describe process framework in your own words. When we say that
framework activities are applicable to all projects, does this mean
that the same work tasks are applied for all projects regardless of
size and complexity? Explain.

6. Add two more additional myths considering present day software

industries and also state the reality that accompanies the myth.

41
Thank You for Your Attention !

42