Software Engineering (CC-281

/CC-2101)
Fall’24
Lecture # 03-04

Instructor
Rida Ayesha

1
Lecture # 03-04 Agenda

● CHAPTER 02: Software Engineering (Roger S. Pressman Book)

● What is Software Engineering?
● Software Engineering Layers
● The Software Process
● The Process Framework
● Umbrella Activities
● Process Adaptation
● Software Engineering Practice
● Essence of Practice
● General Principles
● Software Development Myths

2
Chapter 2

• Software Engineering

Slide Set to accompany

Software Engineering: A Practitioner’s Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger 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 3
2014). Slides copyright 2014 by Roger Pressman.
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:
• [Software engineering 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 4
2014). Slides copyright 2014 by Roger Pressman.
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 5
2014). Slides copyright 2014 by Roger Pressman.
A Layered Technology - Quality
• Software engineering is a layered technology.

• Referring to the Figure, any engineering approach (including software

engineering) must rest on an organizational commitment to quality.

• Total quality management, Six Sigma,

and similar philosophies foster a
continuous process improvement culture,
and it is this culture that ultimately leads
to the development of increasingly more
effective approaches to software
engineering.

• The bedrock that supports software

engineering is a quality focus.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 6
2014). Slides copyright 2014 by Roger Pressman.
A Layered Technology - Process
• The foundation for software engineering is the
process layer.

• The software engineering process is the glue that

holds the technology layers together and enables
rational and timely development of computer
software.

• Process defines a framework that must be

established for effective delivery of software
engineering technology.

• The software process forms the basis for management control of

software projects and establishes the context in which technical
methods are applied, work products (models, documents, data, reports,
forms, etc.) are produced, milestones are established, quality is ensured,
and change is properly managed.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 7
2014). Slides copyright 2014 by Roger Pressman.
A Layered Technology - Methods
• Software engineering methods provide the
technical how-to’s for building software.

• Methods encompass a broad array of tasks

that include communication, requirements
analysis, design modeling, program
construction, testing, and support.

• Software engineering methods rely on a set

of basic principles that govern each area of
the technology and include modeling
activities and other descriptive techniques.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 8
2014). Slides copyright 2014 by Roger Pressman.
A Layered Technology - Tools
• Software engineering tools provide
automated or semi-automated support for
the process and the methods.

• Environment for design, code & testing

• When tools are integrated so that

information created by one tool can be
used by another, a system for the support
of software development, called computer-
aided software engineering, is established.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 9
2014). Slides copyright 2014 by Roger Pressman.
The Software Process

• Process: A process is a collection of activities, actions, and tasks that are

performed when some work product is to be created.

• Work Product: Programs, documents and data that are produced as a

consequence of activities

• Activity: 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, or degree of
rigor with which software engineering is to be applied.

• Action: An action (e.g., architectural design) encompasses a set of tasks that

produce a major work product (e.g., an architectural model).

• Task: 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 10
2014). Slides copyright 2014 by Roger Pressman.
The Software Process (cont.)
Example of Activity, Action and Task:

• Activity: Stakeholder Communication

This activity involves engaging with stakeholders to gather requirements and
feedback throughout the project lifecycle.

• Action: Requirements Gathering

This action includes specific tasks to collect and document stakeholder needs and
expectations, ensuring that the development aligns with what users want.

• Task: Conducting Interviews

This task involves scheduling and conducting one-on-one interviews with
stakeholders to understand their requirements in detail, producing meeting notes
as a tangible outcome.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 11
2014). Slides copyright 2014 by Roger Pressman.
The Software Process (cont.)
Example of Activity, Action and Task:

• Activity: Quality Assurance

This activity aims to ensure that the product meets specified quality standards
and fulfills user requirements.

• Action: Test Planning

This action involves outlining the testing strategy, including defining test
objectives, scope, resources, and schedules.

• Task: Creating Test Cases

This task consists of writing detailed test cases that specify the conditions under
which a feature will be tested, resulting in a document that guides the testing
process.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 12
2014). Slides copyright 2014 by Roger Pressman.
The Software Process (cont.)

• In the context of software engineering, a process is not a rigid

prescription for how to build computer software.

• Rather, it is an adaptable approach that enables the people doing

the work (the software team) to pick and choose the appropriate
set of work actions and tasks.

• The intent is always to deliver software in a timely manner and

with sufficient quality to satisfy those who have sponsored its
creation and those who will use it.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 13
2014). Slides copyright 2014 by Roger Pressman.
Class Activity 01

• Provide an example for Activity, Action & Task for any work
product.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 14
2014). Slides copyright 2014 by Roger Pressman.
A Process Framework
• A process framework establishes the foundation for a complete software
engineering process by identifying a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity.

• In addition, the process framework encompasses a set of umbrella activities that

are applicable across the entire software process.

• A generic process framework for software engineering encompasses five activities:

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

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 15
2014). Slides copyright 2014 by Roger Pressman.
Framework Activities
• These five generic framework activities can be used during the
development of small, simple programs, the creation of Web
applications, and for the engineering of large, complex
computer-based systems.
• The details of the software process will be quite different in
each case, but the framework activities remain the same.
1. Communication
2. Planning
3. Modeling
o Analysis of requirements
o Design
4. Construction
o Code generation
o Testing
5. Deployment
These slides are designed to accompany Software
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 16
2014). Slides copyright 2014 by Roger Pressman.
Framework Activities (cont.)
1. Communication:
• Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders).

• The intent is to understand stakeholders’ objectives for the project and to

gather requirements that help define software features and functions.

2. Planning:
• Any complicated journey can be simplified if a map exists. A software
project is a complicated journey, and the planning activity creates a “map”
that helps guide the team as it makes the journey.

• The map—called a software project plan—defines the software engineering

work by describing the technical tasks to be conducted, the risks that are
likely, the resources that will be required, the work products to be produced,
and a work schedule.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 17
2014). Slides copyright 2014 by Roger Pressman.
Framework Activities (cont.)
3. Modeling:
• Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day.

• You create a “sketch” of the thing so that you’ll understand the big picture—
what it will look like architecturally, how the constituent parts fit together,
and many other characteristics.

• If required, you refine the sketch into greater and greater detail in an effort
to better understand the problem and how you’re going to solve it.

• A software engineer does the same thing by creating models to better

understand software requirements and the design that will achieve those
requirements.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 18
2014). Slides copyright 2014 by Roger Pressman.
Framework Activities (cont.)
4. Construction:
• What you design must be built. This activity combines code generation
(either manual or automated) and the testing that is required to uncover
errors in the code.

5. Deployment:
• The software (as a complete entity or as a partially completed increment) is
delivered to the customer who evaluates the delivered product and provides
feedback based on the evaluation.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 19
2014). Slides copyright 2014 by Roger Pressman.
Umbrella Activities
• 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 20
2014). Slides copyright 2014 by Roger Pressman.
Umbrella Activities (cont.)
• Software project tracking and control—allows the software team to assess
progress against the project plan and take any necessary action to maintain the
schedule.

• Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.

• Software quality assurance—defines and conducts the activities required to

ensure software quality.

• Technical reviews—assess software engineering work products in an effort to

uncover and remove errors before they are propagated to the next activity.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 21
2014). Slides copyright 2014 by Roger Pressman.
Umbrella Activities (cont.)
• Measurement—defines and collects process, project, and product measures that
assist the team in delivering software that meets stakeholders’ needs; can be used in
conjunction with all other framework and umbrella activities.

• Software configuration management—manages the effects of change

throughout the software process.

• Reusability management—defines criteria for work product reuse (including

software components) and establishes mechanisms to achieve reusable components.

• Work product preparation and production—encompass the activities required

to create work products such as models, documents, logs, forms, and lists.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 22
2014). Slides copyright 2014 by Roger Pressman.
Adapting a Process Model

• 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 autonomy 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 23
2014). Slides copyright 2014 by Roger Pressman.
Software Engineering Practice

• Consists of a collection of concepts, principles, methods, and tools

that a software engineer calls upon on a daily basis

• Equips managers to manage software projects and software

engineers to build computer programs

• Provides necessary technical and management how to’s in getting

the job done

• Transforms a haphazard unfocused approach into something that

is more organized, more effective, and more likely to achieve
success

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 24
2014). Slides copyright 2014 by Roger Pressman.
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).

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 25
2014). Slides copyright 2014 by Roger 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 26
2014). Slides copyright 2014 by Roger 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 27
2014). Slides copyright 2014 by Roger 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 28
2014). Slides copyright 2014 by Roger Pressman.
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 29
2014). Slides copyright 2014 by Roger Pressman.
Hooker’s General Principles

• 1: The Reason It All Exists

to provide value to its users
• 2: KISS (Keep It Simple, Stupid!)
All designs should be as simple as possible
• 3: Maintain the Vision
A clear vision is essential to the success of a software project
• 4: What You Produce, Others Will Consume
Always specify, design, and implement knowing someone else will
have to understand what you are doing

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 30
2014). Slides copyright 2014 by Roger Pressman.
Hooker’s General Principles

• 5: Be Open to the Future

Never design yourself into a corner
• 6: Plan Ahead for Reuse
Planning ahead for reuse reduces he cost and increases the value of
both the reusable components and the system into which they are
incorporated.
• 7: Think!
Placing clear, complete thought before action almost always
produces better results.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 31
2014). Slides copyright 2014 by Roger Pressman.
 Communication Practices
(Requirements Elicitation)

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
These slides are designed to accompany Software 32
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill
2014). Slides copyright 2014 by Roger Pressman.
Communication Principles
1) Listen to the speaker and concentrate on what is being said

2) Prepare before you meet by researching and understanding the problem

3) Someone should facility the meeting and have an agenda

4) Face-to-face communication is best, but also have a document or presentation to focus

the discussion

5) Take notes and document decisions

6) Strive for collaboration and consensus

7) Stay focused on a topic; modularize your discussion

8) If something is unclear, draw a picture

9) Move on to the next topic a) after you agree to something, b) if you cannot agree to
something, or c) if a feature or function is unclear and cannot be clarified at the
moment

10) Negotiation is not a contest or a game; it works best when both parties win
These slides are designed to accompany Software 33
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill
2014). Slides copyright 2014 by Roger Pressman.
 Planning Practices
(Defining a Road Map)

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
These slides are designed to accompany Software 34
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill
2014). Slides copyright 2014 by Roger Pressman.
Planning Principles
1) Understand the scope of the project

2) Involve the customer in the planning activity

3) Recognize that planning is iterative; things will change

4) Estimate based only on what you know

5) Consider risk as you define the plan

6) Be realistic on how much can be done each day by each person and how well

7) Adjust granularity as you define the plan

8) Define how you intend to ensure quality

9) Describe how you intend to accommodate change

10) Track the plan frequently and make adjustments as required

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 35
2014). Slides copyright 2014 by Roger Pressman.
Barry Boehm’s W5HH Principle

• Why is the system being developed?

• What will be done?
• When will it be accomplished?
• Who is responsible for each function?
• Where are they organizationally located?
• How will the job be done technically and managerially?
• How much of each resource is needed?

The answers to these questions lead to a definition of key

project characteristics and the resultant project plan

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 36
2014). Slides copyright 2014 by Roger Pressman.
 Modeling Practices
(Analysis and Design)

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
These slides are designed to accompany Software 37
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill
2014). Slides copyright 2014 by Roger Pressman.
Analysis Modeling Principles

1) The information domain of a problem (the data that flows in and out
of a system) must be represented and understood

2) The functions that the software performs must be defined

3) The behavior of the software (as a consequence of external events)

must be represented

4) The models that depict information, function, and behavior must be

partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion

5) The analysis task should move from essential information toward

implementation detail

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 38
2014). Slides copyright 2014 by Roger Pressman.
 Design Modeling Principles
1) The design should be traceable to the analysis model
2) Always consider the software architecture of the system to be built
3) Design of data is as important as design of processing functions
4) Interfaces (both internal and external) must be designed with care
5) User interface design should be tuned to the needs of the end-user and should stress
ease of use
6) Component-level design should be functionally independent (high cohesion)
7) Components should be loosely coupled to one another and to the external environment
8) Design representations (models) should be easily understandable
9) The design should be developed iteratively; with each iteration, the designer should
strive for greater simplicity

External quality factors: those properties that can be readily observed

Internal quality factors: those properties that lead to a high-quality design from a
technical perspective
These slides are designed to accompany Software
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 39
2014). Slides copyright 2014 by Roger Pressman.
 Construction Practices

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
These slides are designed to accompany Software 40
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill
2014). Slides copyright 2014 by Roger Pressman.
Coding Principles
(Preparation before coding)

1) Understand the problem you are trying to solve

2) Understand basic design principles and concepts

3) Pick a programming language that meets the needs of the

software to be built and the environment in which it will
operate

4) Select a programming environment that provides tools that will

make your work easier

5) Create a set of unit tests that will be applied once the

component you code is completed

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 41
2014). Slides copyright 2014 by Roger Pressman.
Coding Principles
(As you begin coding)
1) Constrain your algorithms by following structured programming practices

2) Select data structures that will meet the needs of the design

3) Understand the software architecture and create interfaces that are consistent
with it

4) Keep conditional logic as simple as possible

5) Create nested loops in a way that makes them easily testable

6) Select meaningful variable names and follow other local coding standards

7) Write code that is self-documenting

8) Create a visual layout (e.g., indentation and blank lines) that aids code
understanding
These slides are designed to accompany Software
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 42
2014). Slides copyright 2014 by Roger Pressman.
Coding Principles
(After completing the first round of code)

1) Conduct a code walkthrough

2) Perform unit tests (black-box and white-box) and correct errors

you have uncovered

3) Refactor the code

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 43
2014). Slides copyright 2014 by Roger Pressman.
Testing Principles

1) All tests should be traceable to the software requirements

2) Tests should be planned long before testing begins

3) The Pareto principle applies to software testing

• 80% of the uncovered errors are in 20% of the code

4) Testing should begin “in the small” and progress toward

testing “in the large”

• Unit testing --> integration testing --> validation testing -->

system testing
5) Exhaustive testing is not possible

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 44
2014). Slides copyright 2014 by Roger Pressman.
Test Objectives

1) Testing is a process of executing a program with the intent of

finding an error

2) A good test case is one that has a high probability of finding an

as-yet undiscovered error

3) A successful test is one that uncovers an as-yet undiscovered

error

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 45
2014). Slides copyright 2014 by Roger Pressman.
 Deployment Practices

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
These slides are designed to accompany Software 46
Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill
2014). Slides copyright 2014 by Roger Pressman.
Deployment Principles
1) Customer expectations for the software must be managed

• Be careful not to promise too much or to mislead the user

2) A complete delivery package should be assembled and tested

3) A support regime must be established before the software is

delivered

4) Appropriate instructional materials must be provided to end

users

5) Buggy software should be fixed first, delivered later

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 47
2014). Slides copyright 2014 by Roger 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 48
2014). Slides copyright 2014 by Roger Pressman.
Software Myths: Management Myths

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 49
2014). Slides copyright 2014 by Roger Pressman.
Software Myths: Management Myths
(cont.)

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 50
2014). Slides copyright 2014 by Roger Pressman.
Software Myths: Customer Myths

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 51
2014). Slides copyright 2014 by Roger Pressman.
Software Myths: Customer Myths
(cont.)

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 52
2014). Slides copyright 2014 by Roger Pressman.
Software Myths: Practitioner’s Myths

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 53
2014). Slides copyright 2014 by Roger Pressman.
Software Myths: Practitioner’s Myths
(cont.)

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 54
2014). Slides copyright 2014 by Roger Pressman.
How It all Starts

• SafeHome:
• Every software project is precipitated by some business need—
• the need to correct a defect in an existing application;
• the need to 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 55
2014). Slides copyright 2014 by Roger Pressman.
Summary
• Software engineering encompasses process, methods, and tools that enable
complex computer-based systems to be built in a timely manner with quality.

• The software process incorporates five framework activities—communication,

planning, modeling, construction, and deployment—that are applicable to all
software projects.

• Software engineering practice is a problem-solving activity that follows a set of

core principles.

• A wide array of software myths continue to lead managers and practitioners

astray, even as our collective knowledge of software and the technologies
required to build it grows.

• As you learn more about software engineering, you’ll begin to understand

why these myths should be debunked whenever they are encountered.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 56
2014). Slides copyright 2014 by Roger Pressman.