Scribd
Upload
12 views32 pages

L1 Orientation - Software Engineering Notes

Software engineering notes

Uploaded by

Tasneem khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views32 pages

L1 Orientation - Software Engineering Notes

Software engineering notes

Uploaded by

Tasneem khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

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

You might also like