Pharos University in Alexandria

Faculty of Computer Science & Artificial Intelligence

Course Title: Software Engineering
Code: CS 106

Week 1 - Chapter 2
Introduction to Software Engineering
Dr. Abdulfatah Farawila
Email : [email protected]
[email protected]
Mobile: 01015382683
Slides are adopted from “Software Engineering: A Practitioner’s Approach,
by R. S. Pressman and Bruce R. Maxim; 9th edition, 2019”
Chapter 2
 Software Engineering
Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 8/e
by R. S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2019 by R. S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 2
 Software Engineering
 Some realities:
 A concerted effort should be made to understand the
problem before a software solution is developed
 Design becomes a pivotal activity
 Software should exhibit high quality
 Software should be maintainable
 The seminal definition of Software Engineering:
 It is the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works
efficiently on real machines.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 3
 Software Engineering
 The IEEE definition:
Software Engineering:
1) The application of a systematic, disciplined,
quantifiable approach to the development, operation,
and maintenance of software; that is, the application
of engineering to software

2) The study of approaches as in (1)

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 4
 A Layered
Technology
Tools: provide automated support for the process and the methods.
Information created by one tool can be used by another

Methods: tasks that include communication, requirements analysis,

design modeling, program construction, testing, and support.

Process model: (models, documents, data, reports, forms, etc.)

Quality: (e.g. TQM, Six Sigma, etc.)

Software Engineering
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides
copyright 2019 by R. Pressman. 5
 A Process
Framework
A process is a collection of activities, actions, and tasks that
are performed when some work product is to be created.
• An activity strives to achieve a broad objective (e.g.,
communication with stakeholders) and is applied regardless
of the application domain, size of the project, complexity of
the effort with which software engineering is to be applied.
•An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an
architectural design model).
•A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides 6
copyright 2019 by R. Pressman.
 The 5 Process Framework
Activities
 Communication (with the customer and other
stakeholders)
 Planning (using maps to simplify the project)
 Modeling
 Analysis of requirements
 Design

 Construction
 Code generation
 Testing

 Deployment: Software is delivered to the

customer who evaluates the product and provides
feedback. 7
 Umbrella Activities: Software engineering process
framework activities are complemented by a number of umbrella activities to help a
software team manage and control progress (page 18)

 Software project tracking and control

 Risk management
 Software quality assurance
 Technical reviews
 Measurement
 Software configuration management
 Reusability management
 Work product preparation and production
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides
copyright 2019 by R. Pressman. 8
Adapting a Process Model: a process adopted
for one project might be different than a process
adopted for another project. Differences are:-
 The overall flow of activities, actions, and tasks and the
interdependencies among them
 The degree to which actions and tasks are defined within each
framework activity
 The degree to which work products are identified and required
 The manner which quality assurance activities are applied
 The manner in which project tracking and control activities are applied
 The overall degree of detail and rigor with which the process is
described
 The degree to which the customer and other stakeholders are involved
with the project
 The level of independence given to the software team
 The degree to which team organization and roles are prescribed
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 9
 The Essence of Practice

George Polya outlined the essence of

problem solving. He 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).

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides 10
copyright 2019 by R. Pressman.
 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?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides 11
copyright 2019 by R. Pressman.
 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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides 12
copyright 2019 by R. Pressman.
 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?

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 13
 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?

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 14
 David Hooker’s 7 General Principles of
Software Engineering practice
1: The Reason It All Exists
A software exists for one reason to provide
value to users
2: KISS (Keep It Simple, Stupid!)
3: Maintain the Vision
4: What You Produce, Others Will Consume
Always specify, design, and implement knowing
someone else will have to understand what you are
doing.
5: Be Open to the Future
Never design yourself into a corner
6: Plan Ahead for Reuse
to save time and effort and reduce the cost 15
 David Hooker’s 7 General Principles of
software engineering practice :
The Reason It All Exists: A software system exists
for one reason: to provide value to its users. All
decisions should be made with this in mind. Before
specifying a system requirement, before noting a
piece of system functionality, before determining the
hardware platforms or development processes, ask
yourself questions such as: Does this add real
VALUE to the system? If the answer is "no", don't
do it. All other principles support this one.
16
 David Hooker’s 7 General Principles of
software engineering practice
KISS (Keep It Simple, Stupid!):
This facilitates having a more easily understood, and easily
maintained system.
The more elegant designs are usually the more simple ones.
The payoff is a software that is more maintainable and less
error-prone.

17
 David Hooker’s 7 General Principles of
software engineering practice
Maintain the Vision: A clear vision is essential to the
success of a software project.
As Brooks states: “Conceptual integrity is the most
important consideration in system design. It is better
to have a system omit certain unusual features and
improvements, but to reflect one set of design ideas,
than to have one that contains many good but
independent and uncoordinated ideas. Conceptual
integrity in turn dictates that the design must proceed
from one mind, or from a very small number of
agreeing Conceptual Integrity”
18
 David Hooker’s 7 General Principles of
software engineering practice :
What You Produce, Others Will Consume:
Seldom is a software system constructed and used in a
vacuum. In some way or other, someone else will use,
maintain, document. So, always someone else will have to
understand what you are doing.
Specify with an eye to the users.
Design, keeping the implementers in mind.
Code with concern for those that must debug, maintain and
extend the system. Making their job easier adds value to the
system.
19
 David Hooker’s 7 General Principles of
software engineering practice
Be Open to the Future:
A system with a long lifetime has more value. In today's
computing environments, specifications change on a
moment's notice and hardware platforms are obsolete after
few months, software lifetimes are typically measured in
years.
Systems must be ready to adapt to changes and they must be
designed this way from the start.
Always prepare for creating systems that solve a general
problem, not just the specific one. This could very possibly
lead to the reuse of an entire system. 20
 David Hooker’s 7 General Principles of
software engineering practice :

Plan Ahead for Reuse:

Reuse saves time and effort. Achieving a high level of
reuse is the hardest goal to accomplish in developing a
software system. This is the major benefit of using object-
oriented technologies.
Planning ahead for reuse reduces the cost and increases the
value of both the reusable components and the systems into
which they are incorporated.

21
 David Hooker’s 7 General Principles of
software engineering practice :
Think!:
Placing clear, complete thought before action always
produces better results.
If you do think about something and still do it
wrong, it becomes valuable experience. When clear
thought has gone into a system, value comes out.

22
 Software
Myths

Software myths: wrong beliefs about software and

the process that is used to build it—can be traced to
the earliest days of computing.
Myths have a number of attributes that make them
false.
For instance, they appear to be reasonable
statements of fact (sometimes containing elements
of truth), they have an intuitive feel, and they are
often promulgated by experienced practitioners who
“know the score.”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides 23
copyright 2019 by R. Pressman.
 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
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides copyright 2019 by R.
Pressman. 24
Software Myths: Example
Management Myth

 If we get behind schedule, we can add more

programmers and catch up (sometimes called
theMongolian horde concept ‫مفهوم‬
‫) الحشد المنغولي‬
Software Myths: Example
Customer Myth

 A general statement of objectives is sufficient to

begin writing programs – we can fill in details
later.
 Software requirements continually change, but
change can be easily accommodated because
software is flexible.
Software Myths: Example
Practitioner’s Myth
 Software engineering will make us create
voluminous and unnecessary documentation
and will invariably slow us down.
 How to start a software
project:

 Every software project is taken place by some business need:

• the need to correct a defect in an existing application
• the need to adapt a ‘legacy system’ to a changing
business environment
• the need to extend the functions and features of an
existing application, or
• the need to create a new product, service, or system.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2019). Slides 28
copyright 2019 by R. Pressman.
 Dictionary
seminal ‫رسمي‬
sound engineering principles ‫مبادئ هندسية معروفة‬
framework ‫إطار‬
milestones & deliverables ‫معالم وإنجازات‬
Umbrella ‫مظلة‬
interdependencies ‫الترابط‬
rigor ‫صرامة‬
stakeholders ‫أصحاب المصلحة‬
autonomy ‫الحكم الذاتي‬
essence ‫جوهر‬
stake ‫ركيزة أساسية‬
compartmentalized ‫مجزأة‬
Erroneous myths ‫أساطير خاطئة‬
Insidious ‫غدر‬
Precipitated ‫متسرع‬
Strive to ‫يسعى جاهدًا‬ 29