Course Name

Introduction to Software
Engineering
Course Code: SE-106T

1
◼ Instructor:
Ali Yousuf Khan
Assistant Professor
Software Engineering Department
Ph.D. Research Scholar
MS (I.T.), BS ( Computer Engr. )
Microsoft Certified, CISCO Certified
Office: BS-02 ( Cubical # 10 )

◼ Email:
[email protected]

◼ Consultation:
Preferably via email
2
◼ Textbooks:
◼ Software Engineering (A Practitioner’s Approach) By Roger S.
Pressman, McGraw Hill ( 7th Edition )
◼ Software Engineering (A Practitioner’s Approach) By Roger S.
Pressman & Maxim B. R., McGraw Hill ( 8th Edition )

◼ Reference Books:
◼ Software Engineering by Sommerville I., Pearson ( 9th Edition )
◼ Software Engineering by Sommerville I., Pearson ( 10th Edition )

3
 Marks Distribution

Quizzes 10 Marks
Assignments 10 Marks
Midterm Examination 30 Marks
Final Examination 50 Marks
Total 100 Marks

4
What you need to know...

◼ The presentation slides provide simply

the talk's outline.

◼ These summaries are not a substitute

for attending class and taking notes.

◼ However, these summaries are not a

replacement for the textbook.

5
Chapter 1
◼ Software & Software Engineering

6
What is Software?
Software is:
✓ instructions (computer programs) that when
executed provide desired features, function, and
performance;
✓ data structures that enable the programs to
adequately manipulate information and
✓ documentation that describes the operation
and use of the programs.

7
Types of Application & System
Software

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

9
 Hardware Failure Curve /
Bathtub Curve

A product is said to follow the bathtub curve

if in the early life of a product, the failure rate
decreases as defective products are identified
and discarded, and early sources of potential
failure such as manufacturing defects or
damage during transit are detected.

10
Wear vs. Deterioration
Hardware wears out over time

11
 Software Failure Curve /
Idealized Curve

A failure that occurs when the user perceives that

the software has ceased to deliver the expected
result with respect to the specification input values.
The user may need to identify the severity of the
levels of failures such as catastrophic, critical, major
or minor, depending on their impact on the systems.

12
Wear vs. Deterioration

13
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).

14
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?

15
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 subproblems be defined? If so, are solutions readily
apparent for the subproblems?
◼ Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?

16
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?

17
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?

18
Software Myths

19
 Management Myths

◼ “We already have a book of standards and

procedures for building software. It does provide my
people with everything they need to know …”
◼ “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 …”

20
 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 …”

21
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 …”

◼ “Software engineering is baloney. It makes us

create tons of paperwork, only to slow us
down …”
22