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.
 New software can be created by developing
new programs, configuring generic software
systems or reusing existing software.
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,
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. 10
Software—New Categories
 Open world computing
 the rapid growth of wireless networking may soon lead to true
pervasive, distributed computing. The challenge for soft-ware
engineers will be to develop systems and application software that will
allow mobile devices, personal computers, and enterprise systems to
communicate across vast networks.
 Pervasive computing (also called ubiquitous computing) is the growing
trend towards embedding microprocessors in everyday objects so they
can communicate information. The words pervasive and
ubiquitous mean "existing everywhere." Pervasive computing devices
are completely connected and constantly available
 Netsourcing—the Web as a computing engine
 Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)

11
Legacy Software
 Legacy software systems . . . were developed decades ago and have
been continually modified to meet changes in business requirements and
computing platforms. The proliferation of such systems is causing
headaches for large organizations who find them costly to maintain and
risky to evolve.
 legacy applications and data are those that have been inherited from
languages, platforms, and techniques earlier than current technology

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
Characteristics of WebApps - I
 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
Characteristics of WebApps - II
 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 visual 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,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. When an application has been designed to market or sell
products or ideas, aesthetics may have as much to do with success
. 14
as technical design.
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15
 Software engineering is a layered technology.
 Referring to 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 16
 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. 17
 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

18
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. 19
 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. 20
 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. 21
 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

22
 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. 23
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, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 24
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, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 25
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. 26
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. 27
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. 28
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. 29
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!

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