An Introduction to Software

Engineering
What is software?
 Computer programs and associated
documentation such as requirements, design
models and user manuals.
 Software products may be developed for a
particular customer or may be developed for a
general market.
 Software products may be
 Generic - developed to be sold to a range of different
customers e.g. PC software such as Excel or Word.
 Bespoke (custom) - developed for a single customer
according to their specification.
 What is Software?
 Software is developed or engineered,
it is not manufactured in the
classical sense.
 Software doesn't "wear out."
 Although the industry is moving
toward component-based
construction, most software
continues to be custom-built.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3
What is Software?
Software is: (1) instructions (computer
programs) that when executed provide
desired features, function, and
performance; (2) data structures that
enable the programs to sufficiently
manipulate information and (3)
documentation that describes the
operation and use of the programs.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4
What is software
engineering?
 Software engineering is an engineering
discipline that is concerned with all aspects of
software production.
 Software engineers should adopt a systematic
and organised approach to their work and use
appropriate tools and techniques depending on
the problem to be solved, the development
constraints and the resources available.
What is the difference between
software engineering and computer
science?
 Computer science is concerned with theory
and fundamentals; software engineering is
concerned with the practicalities of developing
and delivering useful software.
What is the difference between
software engineering and system
engineering?
 System engineering is concerned with all
aspects of computer-based systems
development including hardware, software and
process engineering. Software engineering is
part of this process concerned with developing
the software infrastructure, control, applications
and databases in the system.
 System engineers are involved in system
specification, architectural design, integration
and deployment.
What are the costs of software
engineering?
 Roughly 60% of costs are development costs,
40% are testing costs. For custom software,
evolution costs often exceed development
costs.
 Costs vary depending on the type of system
being developed and the requirements of
system attributes such as performance and
system reliability.
 Distribution of costs depends on the
development model that is used.
What are software engineering
methods?
 Structured approaches to software development
which include system models, notations, rules,
design advice and process guidance.
 Model descriptions
 Descriptions of graphical models which should be
produced;
 Rules
 Constraints applied to system models;
 Recommendations
 Advice on good design practice;
 Process guidance
 What activities to follow.
What is CASE (Computer-Aided
Software Engineering)
 Software systems that are intended to provide
automated support for software process
activities.
 CASE systems are often used for method
support.
 Upper-CASE
 Tools to support the early process activities of
requirements and design;
 Lower-CASE
 Tools to support later activities such as
programming, debugging and testing.
 What are the attributes of good
software?
 The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and acceptable.
 Maintainability
 Software must evolve to meet changing needs;
 Dependability
 Software must be trustworthy;
 Efficiency
 Software should not make wasteful use of system resources;
 Acceptability
 Software must accepted by the users for which it was designed. This
means it must be understandable, usable and compatible with other
systems.
Software Applications
 system software
 application software
 engineering/scientific software
 embedded software
 WebApps (Web applications)
 AI software
 product-line software
 set of software-intensive systems that share a
common, managed set of features satisfying the
specific needs of a particular market segment or
mission and that are developed from a common set of
core assets in a prescribed way.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12
 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.
 Software engineering methods provide the technical how-to’s for
building software.
 Methods include communication, requirements analysis, design
modeling, program construction, testing, and support.
 Software engineering tools provide automated or semi automated
support for the process and the methods. 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, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
 The Software Process
 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, or degree of rigor 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

14
A Process Framework
Process framework
Framework activities
Umbrella Activities

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15
 Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 16
 Framework Activities…
 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.
 Planning.
 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.
 Modeling.
A software engineer creating models to better understand software requirements and the design
that will achieve those requirements.
 Construction.
 This activity combines code generation (either manual or
automated) and the testing that is required to uncover errors in the code.
 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, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 17
 Umbrella Activities
 Umbrella activities are applied throughout a software project
and help a software team manage and control progress,
quality, change, and risk. Typical umbrella activities include
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management

18
 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—assesses software engineering work products in an effort
to uncover and remove errors before they are propagated to the next activity.
 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—encompasses 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, 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?

These slides are designed to accompany 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?

These slides are designed to accompany 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?

These slides are designed to accompany 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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23