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
Wear vs. Deterioration
Hardware wears out over time

8
Wear vs. Deterioration

9
Software Applications
 system software
 application software
 engineering/scientific
software
 embedded software
 product-line software
 WebApps (Web
applications)
 AI software

10
Software—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

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

12
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering

13
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

14
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

15
Umbrella Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management

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

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

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

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

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

21
Hooker’s General Principles
 1: The Reason It All Exists
 2: Keep It Simple
 3: Maintain the Vision
 4: What You Produce, Others Will Consume
 5: Be Open to the Future
 6: Plan Ahead for Reuse
 7: Think!

22
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

23
Software Myths

 If we get behind schedule, we can add more

programmers and catch up.
 A general statement about objectives is
sufficient to begin building programs.
 Change in project requirements can be easily
accommodated because software is flexible.

24
Software Myths
 Once we write a working program, we’re
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 too much documentation and will
slow us down.
25
 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 …”
(a.k.a. “The Mongolian Horde concept”)
 “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 …”

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

27
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 …”
28