Software Engineering

Dr. Muazzam Maqsood

[email protected]
 Today’s Lecture

❑ Introduction
❑ Course objectives (and why)
❑ Overview of the course
❑ Quick overview of software engineering and why we
study it
 Course Reference Books
Course Book

❑ Software Engineering. A Practitioner's Approach. By Roger

Pressmen

❑ SOFTWARE ENGINEERING. Ninth Edition. Ian Sommerville

9/10/2024 3
 Course Major Topics

9/10/2024 4
 Course Learning Objectives (CLOs)

9/10/2024 5
 Course Contents
◼ Introduction (FAQs about SE)
◼ Software Processes
◼ Requirements
◼ Design
◼ Verification and Validation
◼ Project Management
◼ 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

9/10/2024 6
 Course Policy

◼5 quizzes, we will choose best of 4

◼Group Projects on application area

◼Chocolate Policy
◼>90%
◼Questioning/Answering

9/10/2024 7
 Course Policy

• Quizzes 15%
• Assignments 10%
• Mid Term 25%
• Final 50%

• There will be absolute grading

9/10/2024 8
 Course Policy

• Attendance Policy
– 80%
– <80%, You can’t sit in the exam!
• Grades Policy
– Don’t complain,
(we get nothing by deducting your grades)

9/10/2024 9
Software Engineering Specialities
SE Supply and Demand
Software Engineer’s Compensation
Software Engineer Salaries in US
Software Engineer Salaries by Role
 Rumors and myths

• Software Engineering is not rocket science and not

something to learn only from a textbook
• Software Engineering is the use of common sense and
discipline
• Learn that building large software systems is not a mere
matter of programming
• My goal is to have you more than just intellectually know
it but really feel it and believe it
 How to teach Software Engineering

• There is not a single right way to teach software

engineering
• My approach is to teach what I’ve learned from experience
and not simple textbook solutions
• All engineering, including software engineering, is
concerned with building useful artifacts under constraints
(some people even define engineering to be “design under
constraints”)
• If it weren’t for the constraints, there might be a single
right way to engineer software systems
 What is Software Engineering?

• The practical application of scientific knowledge to the

design and construction of computer programs and the
associated documentation required to develop, operate, and
maintain them [Boehm].

• The systematic approach to the development, operation,

maintenance, and retirement of software [IEEE].

• The establishment and use of sound engineering principles

(methods) in order to obtain economical software that is
reliable and works on real machines [Bauer].
 Why study Software Engineering?

• Building software without discipline is crazy

• Software is critical to society
• Building a large complete software project is hard
• There is a perceived crisis in our ability to build software
• It’s fun!

• $$$$$$$$$$$$$$$$
 Software is critical to society

• Economically important
• Essential for running most enterprises
• Key part of most complex systems
• Essential for designing many engineering products
• In many if not in most cases, the software is embedded in
the system you are using — you don’t see the software
 Software is big
Code sizes due to Jon Jacky (mostly); KLOC = 1000 lines of
code; MLOC = 1,000,000 lines of code

Bar code scanners 10-50KLOC

4-speed transmissions 20KLOC

ATC ground system 130KLOC

Automatic teller machine 600KLOC

Call router 2.1MLOC

B-2 Stealth Bomber 3.5MLOC
Seawolf submarine combat 3.6MLOC

NT 4.0 10MLOC
NT 5.0 60+LMLOC
(NTFS alone) (250K source lines or 100KLOC )
 Software is big, so what?

• Delivered source lines per person

• Common estimates are that a person can deliver
about 1000 source lines per year (including
documentation, scaffolding, etc.)
• Therefore, most complex systems require many
people to build
• This would be true even with an order of
magnitude increase in productivity
• Hence the critical need for coordination
 To some degree this is accurate

• We’ll look at some classic software failures later

on in the quarter
• But it’s not fully accurate
• Given the context, we do pretty well
• We surely can, should and must improve
• Some so-called software “failures” are not
– They are often management errors (the choice not to do
something that would have helped)
 Some “crisis” issues

• Relative cost of hardware/software

• Low productivity
• “Wrong” products
• Poor quality
• Constant maintenance
• Technology transfer is slow
 Why is it hard?

• There is no single reason software engineering is

hard—it’s a “wicked problem”

• Lack of well-understood representations of

software makes customer and engineer
interactions hard [Brooks]

• Still a relatively young field

 The Role of Software Engg. (1)
A bridge from customer needs to programming implementation

eer ing
Customer gi n
wa r e En
Soft Programmer

First law of software engineering

Software engineer is willing to learn the problem domain
25
(problem cannot be solved without understanding it first)
The Role of Software Engg. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction with the environment
in a specified manner

System-to-be

Environment
Software-to-be
User

Software Engineer’s task:

To understand how the system-to-be needs to interact with
the user or the environment so that customer’s requirement is met
and design the software-to-be

May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer
26
 Example: ATM Machine
Understanding the money-machine problem:

1
7
4
0
2
5 3
8 6
9
Communication link

Bank’s
remote
ATM machine
datacenter
Bank
customer
27
 How ATM Machine Might Work
Domain Model

Transaction
How may I record
help you? Cash

Bookkeeper
Speakerphone Safe
Safe keeper
Phone

Window clerk

Datacenter
liaison

Dispenser

Bank’s
remote
28
datacenter
Customer
 Software Engineering Blueprints
➢ Specifying software problems and solutions is like
cartoon script writing
➢ Unfortunately, most of us are not artists, so we will use
something less exciting:
UML symbols
➢ However …

29
 Law of Software Engineering

• Software should be written for people first

– ( Computers run software, but hardware quickly
becomes outdated )

– Useful + good software lives long

– To nurture software, people must be able to understand

it

30
 Software lifecycle

• A software engineering lifecycle model describes

how one might put structure on the software
engineering activities

• The classic lifecycle model is the waterfall model

(roughly due to Royce in 1956), which is
structured by a set of activities and is inherently
document-driven
Software lifecycle
 Software lifecycle

• Limited feedback increases risk

• “You start at the top and it’s all downhill from
there.” [uncertain origin]
• The cost of fixing errors at later lifecycle phases is
much higher than at earlier stages
– Boehm’s 1976 data still hold — the differences are
often an order of magnitude
– Must increase feedback in the lifecycle to reduce these
costs (and other risks)
 Software Development Methods
➢ Method = work strategy
▪ The Feynman Problem-Solving Algorithm:
(i) Write down the problem (ii) think very hard, and
(iii) write down the answer.
➢ Waterfall
▪ Unidirectional, finish this step before moving to the next
➢ Iterative + Incremental
▪ Develop increment of functionality, repeat in a feedback loop
➢ Agile
▪ Continuous user feedback essential; feedback loops on several levels of
granularity

34
 Waterfall Method
Requirements

Design

Implementation

Testing
Waterfall
method Deployment &
Maintenance

Each activity confined to its “phase”.

Unidirectional, no way back;
35
finish this phase before moving to the next
 How Much Diagramming?
• Use informal, ad-hoc, hand-drawn, scruffy diagrams during
early stages and within the development team
– Hand-drawing forces economizing and leads to low emotional
investment
• Economizing focuses on the essential, most important considerations
– Prioritize substance over the form
• Not being invested facilitates critique and suggested modifications
– Always take snapshot to preserve records for future
• Use standardized, neat, computer-generated diagrams when
consensus reached and designs have “stabilized”
– Standards like UML facilitate communication with broad range of
stakeholders
– But, invest effort to make neat and polished diagrams only when
there is an agreement about the design, so this effort is worth doing
• Invest in the form, only when the substance is worth such an investment
36
Understanding the Problem Domain

• System to be developed

• Actors
– Agents external to the system that interact with it

• Concepts/ Objects
– Agents working inside the system to make it function

• Use Cases
– Scenarios for using the system

37
 ATM: Gallery of Players

1
4 2
7 5 3
8 6
0 9

Bank customer System Bank’s remote

(ATM machine) datacenter

Actors (Easy to identify because they are visible!)

38
 Gallery of Workers + Tools

Window clerk Datacenter Bookkeeper Safe keeper Dispenser

liaison

Speakerphone Telephone Transaction Safe Cash

record

Concepts (Hard to identify because they are invisible/imaginary!)

39
 Use Case: Withdraw Cash
A Enter
B Verify
account C How may
your PIN XYZ I help
you?

1
4 2
7 5 63 1
8 4 2
0 9 7 85 6 3
0 9

Typing in XYZ valid. Withdraw

PIN number Balance: $60
… $100

D E XYZ
Please take
your cash withdrew
$60

1
4 2
7 85 6 3
0 9

Collecting
cash …
Acknowledged
40
 Feasibility & Quality of Designs
• Judging feasibility or quality of a design requires
great deal of domain knowledge
(and commonsense knowledge!)

41
• Any Question