Unit 1

Software & Software Engineering

Software & Software Engineering: The Nature of Software,
The Unique Nature of WebApps, Software Engineering,
Software Process, Software Engineering Practice, Software
Myths.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 1
1.The Nature of software
Software takes on a dual role.
It is a product, and at the same time, the vehicle for
delivering a product.
As a product, it delivers computer hardware or more
broadly, by a network of computers that are accessible
by local hardware. Whether it resides within a mobile
phone or operates inside a mainframe computer,
software is an information transformer—producing,
managing, acquiring, modifying, displaying, or
transmitting information
As the vehicle used to deliver the product, software acts
as the basis for the control of the computer (operating
systems), the communication of information (networks),
and the creation and control of other programs
(software tools and environments).
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 2
1.1 Defining Software
Software is: (1) instructions (computer
programs) that when executed provide
desired features, function, and
performance; (2) data structures that
enable the programs to adequately
manipulate information and (3)
documentation that describes the
operation and use of the programs.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 3
Software characteristics
Software has characteristics that are
considerably different than those of
hardware
1. Software is developed or engineered; it is
not manufactured in the classical sense.
2. Software doesn’t “wear out.”
3. Although the industry is moving toward
component-based construction, most
software continues to be custom built.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 4
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 5
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 6
1.2 Software Application domains
Seven broad categories
system software
application software
engineering/scientific software
embedded software
product-line software
WebApps (Web applications)
AI software
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 7
Software—New Categories
Open world computing—pervasive, distributed
computing
Ubiquitous computing—wireless networks
Net sourcing—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

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 8
1.3 Legacy Software
Dayani-Fard and his colleagues [Day99] describe legacy software in
the following way:
Legacy software systems . . . were developed decades ago and have
been continually modified to meet changes in business
requirements and computing platforms. costly to maintain and risky
to evolve.
legacy systems often evolve for one or more of the following
reasons:
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.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 9
2.Unique nature of webapps
What characteristic differentiates WebApps from other
software?
Network intensiveness. A WebApp resides on a network
and must serve the needs of a diverse community of clients.
Concurrency. A large number of users may access the
WebApp at one time.
Unpredictable load. The number of users of the WebApp
may vary by orders of magnitude from day to day.
Performance. If a WebApp user must wait too long (for
access, for server-side processing, for client-side formatting
and display), he or she may decide to go elsewhere.
Availability. Although expectation of 100 percent
availability is unreasonable, users of popular WebApps often
demand access on a “24/7/365” basis.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 10
2.Unique nature of webapps (contd)
Data driven. The primary function of many WebApps is to use
hypermedia to present text, graphics, audio, and video content to the
end-user.
Content sensitive. The quality and aesthetic nature of content remains
an important determinant of the quality of a WebApp.
Continuous evolution. Unlike conventional application software that
evolves over a series of planned, chronologically-spaced releases, Web
applications evolve continuously.
Immediacy. Although immediacy—the compelling need to get software
to market quickly—is a characteristic of many application domains,
WebApps often exhibit a time to market that can be a matter of a few
days or weeks.
Security. Because WebApps are available via network access, it is
difficult, if not impossible, to limit the population of end-users who may
access the application.
Aesthetics. An undeniable part of the appeal of a WebApp is its look and
feel.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 11
3.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.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 12
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).

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 13
Software engineering is a layered
technology.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 14
4.The software process
A process is a collection of activities, actions, and tasks that
are performed when some work product is to be created.
A Process Framework

Process framework
Framework activities
work tasks
work products
milestones &
deliverables
QA checkpoints
Umbrella Activities
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 15
Five generic process framework activities
Communication
Planning
Modeling
Analysis of requirements
Design
Construction
Code generation
Testing
Deployment
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 16
Umbrella Activities
Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Work product preparation and
production
Reusability management
Measurement
Risk management
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 17
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

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 18
5.Software engineering practice
5.1The 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).

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 19
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?

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 20
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?

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 21
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?
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 22
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?
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 23
5.2 Hooker’s General Principles
1: The Reason It All Exists
2: KISS (Keep It Simple, Stupid!)
3: Maintain the Vision
4: What You Produce, Others Will
Consume
5: Be Open to the Future
6: Plan Ahead for Reuse
7: Think!
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 24
6.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
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 25
Software Myths
Definition: Beliefs about software
and the process used to build it.
Myths have number of attributes
that have made them insidious (i.e.
dangerous).
Misleading Attitudes - caused
serious problem for managers and
technical people.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 26
Management myths
Managers in most disciplines, are often under pressure to
maintain budgets, keep schedules on time, and improve
quality.
Myth1: We already have a book that's full of standards
and procedures for building software, it does provide my
people with everything they need to know.
Reality :
Are software practitioners aware of existence standards?
Does it reflect modern software engineering practice?
Is it complete? Is it streamlined to improve time to
delivery while still maintaining a focus on quality?
In many cases, the answer to all of these questions is "no."

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 27
 Myth: My people have state-of-the-art software
development tools, after all, we buy them the
newest computers.
Reality :It takes much more than the latest model
mainframe, workstation, or PC to do high-quality
software development. (E.g.=1.Parent-student-
facility 2.5 star facility in education-best engg.)
Computer-aided software engineering (CASE) tools
are more important than hardware for achieving
good quality and productivity, yet the majority of
software developers still do not use them
effectively.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 28
 Myth: If we get behind schedule, we can add more
programmers and catch up (sometimes called the
Mongolian horde concept).
Reality: Software development is not a mechanistic
process like manufacturing.
In the words: "adding people to a late software project
makes it later." At first, this statement may seem
counterintuitive.
However, as new people are added, people who were
working must spend time educating the newcomers,
thereby reducing the amount of time spent on
productive development effort.
People can be added but only in a planned and well-
coordinated manner.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 29
 Myth: If I decide to outsource the
software project to a third party, I can
just relax and let that firm build it.
Reality: If an organization does not
understand how to manage and
control software projects internally, it
will invariably struggle when it
outsources software projects.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 30
Customer Myths
Myth: A general statement of objectives is
sufficient to begin writing programs— we can fill in
the details later. (E.g. only def. is der clg mgmt sys.)
Reality: A poor up-front definition is the major
cause of failed software efforts.
A formal and detailed description of the
information domain, function, behavior,
performance, interfaces, design constraints, and
validation criteria is essential.
Characteristics can be determined only after
thorough communication between customer and
developer.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 31
 Myth: Project requirements continually change, but
change can be easily accommodated because
software is flexible. (E.g. Wipro-IPCA exp.)
Reality: It is true that software requirements
change, but the impact of change varies with the
time at which it is introduced.
If serious attention is given to up-front definition,
early requests for change can be accommodated
easily with relatively little impact on cost.
When changes are requested during software
design, during implementation (code and test) the
cost impact grows rapidly.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 32
Practitioner's myths
Myth: Once we write the program and
get it to work, our job is done.
Reality: Expert said "the sooner you
begin 'writing code', the longer it'll
take you to get done."
Industry data indicate that between 60
and 80 percent of all effort expended
on software will be expended after it is
delivered to the customer for the first
time.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 33
 Myth: Until I get the program "running" I have no
way of assessing its quality.

Reality:One of the most effective software quality

assurance mechanisms can be applied from the
inception of a project—the formal technical review.

Software reviews are a "quality filter" that have

been found to be more effective than testing for
finding certain classes of software defects.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 34
 Myth: The only deliverable work
product for a successful project is the
working program.
Reality: A working program is only one
part of a software configuration that
includes many elements.
Documentation provides a foundation
for successful engineering and, more
important, guidance for software
support.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 35
 Myth: Software engineering will make
us create voluminous and unnecessary
documentation and will invariably slow
us down.
Reality: Software engineering is not
about creating documents. It is about
creating quality
Better quality leads to reduced rework.
And reduced rework results in faster
delivery times.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 36
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.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 37
Process Models
A Generic Process Model, Process Assessment and
Improvement, Prescriptive Process Models, Specialized
Process Models, The Unified Process, Personal and Team
Process Models, Process Terminology, Product and Process.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 38
 A Generic Process Model

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 39
Process Flow

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 40
Identifying a Task Set
A task set defines the actual work to
be done to accomplish the objectives
of a software engineering action.
A list of the task to be accomplished
A list of the work products to be
produced
A list of the quality assurance filters to be
applied

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 41
Process Patterns
A process pattern
describes a process-related problem that is
encountered during software engineering work,
identifies the environment in which the problem
has been encountered, and
suggests one or more proven solutions to the
problem.
Stated in more general terms, a process
pattern provides you with a template
[Amb98]—a consistent method for describing
problem solutions within the context of the
software process.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 42
Process Pattern Types
Stage patterns—defines a problem
associated with a framework activity for
the process.
Task patterns—defines a problem
associated with a software engineering
action or work task and relevant to
successful software engineering practice
Phase patterns—define the sequence of
framework activities that occur with the
process, even when the overall flow of
activities is iterative in nature.
Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 43
Process Assessment and Improvement
Standard CMMI Assessment Method for Process
Improvement (SCAMPI) — provides a five step
process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting
and learning.
CMM-Based Appraisal for Internal Process
Improvement (CBA IPI)—provides a diagnostic
technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the
basis for the assessment [Dun01]

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 44
Process Assessment and Improvement
SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent
of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software
process. [ISO08]
ISO 9001:2000 for Software—a generic standard that
applies to any organization that wants to improve the
overall quality of the products, systems, or services that it
provides. Therefore, the standard is directly applicable to
software organizations and companies. [Ant06]

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 45
Prescriptive Models
Prescriptive process models advocate an
orderly approach to software engineering
That leads to a few questions …
If prescriptive process models strive for
structure and order, are they inappropriate for
a software world that thrives on change?
Yet, if we reject traditional process models
(and the order they imply) and replace them
with something less structured, do we make it
impossible to achieve coordination and
coherence in software work?

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 46
The Waterfall Model

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 47
The V-Model

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 48
The Incremental Model

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 49
Evolutionary Models: The Spiral

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 50
Evolutionary Models: Concurrent

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 51
Specialized Process Models
Component based development—the process to
apply when reuse is a development objective
Formal methods—emphasizes the mathematical
specification of requirements
AOSD—provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects
Unified Process—a “use-case driven, architecture-
centric, iterative and incremental” software process
closely aligned with the Unified Modeling
Language (UML)

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 52
The Unified Process (UP)

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 53
UP Phases
UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 54
UP Work Products
Inception phase

Elaboration phase
Vision document
Init ial use-case model
Init ial project glossary Construction phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Transition phase
Design model
Project plan, Analysis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Delivered soft ware increment
Int egrat ed soft ware
Business model, Descript ion. increment Bet a t est report s
if necessary. Execut able archit ect ural General user feedback
Test plan and procedure
One or more prot ot ypes prot ot ype.
I nc e pt i o Test cases
n Preliminary design model Support document at ion
Revised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 55
Personal Software Process (PSP)
Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of
defects projected for the work) is made. All metrics are recorded on
worksheets or templates. Finally, development tasks are identified and
a project schedule is created.
High-level design. External specifications for each component to be
constructed are developed and a component design is created.
Prototypes are built when uncertainty exists. All issues are recorded and
tracked.
High-level design review. Formal verification methods (Chapter 21) are
applied to uncover errors in the design. Metrics are maintained for all
important tasks and work results.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 56
Personal Software Process (PSP)
Development. The component level design is refined and
reviewed. Code is generated, reviewed, compiled, and
tested. Metrics are maintained for all important tasks and
work results.
Postmortem. Using the measures and metrics collected
(this is a substantial amount of data that should be analyzed
statistically), the effectiveness of the process is determined.
Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 57
Team Software Process (TSP)
Build self-directed teams that plan and track their work, establish
goals, and own their processes and plans. These can be pure
software teams or integrated product teams (IPT) of three to
about 20 engineers.
Show managers how to coach and motivate their teams and how
to help them sustain peak performance.
Accelerate software process improvement by making CMM Level
5 behavior normal and expected.
The Capability Maturity Model (CMM), a measure of the
effectiveness of a software process, is discussed in Chapter 30.
Provide improvement guidance to high-maturity organizations.
Facilitate university teaching of industrial-grade team skills.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 58
Process technology
process technology tools have been developed to help
software organizations analyze their current
process,organize work tasks, control and monitor
progress, and manage technical quality.
Process technology tools allow a software organization
to build an automated model of the process
framework, task sets, and umbrella activities
The process technology tool can also be used to
coordinate the use of other software engineering
tools that are appropriate for a particular work task.

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 59
Product and Process
The Product is what we're actually building. What's
our solution to the problem at hand? Half of
engineering is making sure you're building the right
product and have the ability to actually build it.
For software engineers, that means coming up
with a software solution and being able to code it
up properly.
The Process, which means how we're actually
building our product. Products don't just result
from a single all-night coding session

Content extracted from Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman. 60