Software Engineering
Course Code: CS3CO26
Session : Aug-Dec, 2024
By
Dr. Ratnesh Litoriya
Professor & Head
Software Engineering
An Orientation Lecture
Objectives of the Subject
Appreciate Software Engineering:
Build complex software systems in the context of frequent change
Understand how to
produce a high quality software system within time
while dealing with complexity and change
Acquire technical knowledge (main emphasis)
Acquire managerial knowledge
Understand the Software Lifecycle
Process vs Product
Learn about different software lifecycles
Greenfield Engineering – from scratch,
What this course is about ?
• Learn how to build a large software system in a team
– Learn how to collect requirements
– Learn how to write specification
– Learn how to design
• Reliability is central to software engineering: This constitutes
significant part of the course
– Version Control
– Testing
– Debugging
– Dynamic Analysis
What this course is not about ?
• Do not expect to learn a new language
• Do not expect to learn programming tricks
– But you’ll learn techniques for “programming in the
large”
• Do not expect to learn management skills from the lectures
– Some things you learn by doing, not through lectures!
Why Software Engineering?
Standish Report (The “Chaos” Report)
Scientist vs Engineer
Computer Scientist
Proves theorems about algorithms, designs languages, defines
knowledge representation schemes
Has infinite time…
Engineer
Develops a solution for an application-specific problem for a client
Uses computers & languages, tools, techniques and methods
Software Engineer
Works in multiple application domains
Has only 3 months...
…while changes occurs in requirements and available technology
Software Engineering: A Problem
Solving Activity
Analysis: Understand the nature of the problem and break the
problem into pieces
Synthesis: Put the pieces together into a large structure
For problem solving we use
Techniques (methods):
Formal procedures for producing results using some well-defined
notation
Methodologies:
Collection of techniques applied across software development and
unified by a philosophical approach
Tools:
Instrument or automated systems to accomplish a technique
Software Engineering Myths :
(Management)
“We have books with rules. Isn’t that everything my
people need?”
Which book do you think is perfect for you?
“If we fall behind, we add more programmers”
“Adding people to a late software project, makes it
later” – Fred Brooks (The Mythical Man Month)
“We can outsource it”
If you do not know how to manage and control it
internally, you will struggle to do this with outsiders
Software Engineering Myths :
(Customer)
“We can refine the requirements later”
A recipe for disaster.
“The good thing about software is that we can change it
later easily”
As time passes, cost of changes grows rapidly
Software Engineering Myths :
(Professional/Practitioner)
“Let’s write the code, so we’ll be done faster”
“The sooner you begin writing code, the longer it’ll
take to finish”
60-80% of effort is expended after first delivery
“Until I finish it, I cannot assess its quality”
Software and design reviews are more effective than
testing (find 5 times more bugs)
“There is no time for software engineering”
But is there time to redo the software?
Software Crisis
Buggy software is a huge problem
But you likely already know that
Defects in software are commonplace
Much more common than in other engineering disciplines
So many Examples are available .
This is not inevitable---we can do better!
Software Crisis
(The Evolving Nature of Software Development )
Software Bugs : Space Disaster
Maiden flight of the
Ariane 5 rocket on
the 4th of June 1996
• The reason for the explosion was
a software error (Attempt to
cram a 64-floating point number
to a 16-bit integer failed)
• Financial loss: $500,000,000
(including indirect costs:
$2,000,000,000)
Software Bugs/Error : More
Examples
Radio Therapy Machine
software error
6 people overdosed
Year 2010 Bug
30 million debit and credit cards have been
rendered unreadable by the software bug
software in modern cars
>100K LOC
2006: error in pump control
software
128000 vehicles recalled
Cost of Software
Financial Impact of Software
Bugs/Errors
Recent research at Cambridge University (2013, link)
showed that the global cost of software bugs is
around 312 billion of dollars annually
Goal: to increase software reliability
How to identify software bugs?
• How do we know behavior is a bug?
• Because we have some separate specification
of what the program must do
– Separate from the code
• Thus, knowing whether the code works
requires us first to define what “works” means
– A specification
Teams and Specifications
• Do we really need to write specifications?
• A typical software team will in general do the
following:
– Discuss what to do
– Divide up the work
– Implement incompatible components
– Be surprised when it doesn’t all just work together
Cartoon
20
Cartoon
21
Cartoon
22
Cartoon
23
Cartoon
24
Cartoon
25
Cartoon
26
Cartoon
27
Cartoon
28
Cartoon
Prof. Majumdar CS 130 Lecture 1 29
Specification
• A specification allows us to:
– Check whether software works
– Build software in teams at all
• Actually checking that software works is hard
– Code reviews
– Static analysis tools
– Testing and more testing
– We will examine this problem closely
Evaluation scheme:
• MST (1 and 2) 20
• Quiz/Assignment 10
• Attendance 05
• Behaviour/Conduct 05
• End Sem Exam 60
Total 100
Books/Literature recommended
Software Engineering: A Practitioner's Approach (Mc-Graw-
Hill) By Roger S. Pressman
Software Engineering (Addison-Wesley) by Ian Sommerville
Introduction to Software Engineering (CRC Press) by Ronald J.
Leach
Software Engineering (Pearson Education) by Shari Lawrence
Pfleeger
Code Complete: A Practical Handbook of Software
Construction by Steve McConnell
