SlideShare a Scribd company logo
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.
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 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. 4
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
adequately 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. 5
Wear vs. Deterioration
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,
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
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.
14
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!)
15
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.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 16
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.
. 17
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
as technical design.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 18
A Layered Technology
Software Engineering
a “quality” focus
process model
methods
tools
 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. 19
 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. 20
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
21
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22
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. 23
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment
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. 24
25
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
 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. 26
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27
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. 28
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. 29
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. 30
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. 31
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. 32
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. 33
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!

More Related Content

DOC
Chapter1
PPT
software engineering models
PPTX
Lecture 01 Introduction to Software Engineering
PPT
INTRODUCTION TO SOFTWARE ENGINEERING
PPTX
Software Engineering
PDF
Introduction to software engineering
PDF
SWE-401 - 2. Software Development life cycle (SDLC)
PPT
Introduction to Software Engineering
Chapter1
software engineering models
Lecture 01 Introduction to Software Engineering
INTRODUCTION TO SOFTWARE ENGINEERING
Software Engineering
Introduction to software engineering
SWE-401 - 2. Software Development life cycle (SDLC)
Introduction to Software Engineering

What's hot (20)

PDF
Software systems engineering PRINCIPLES
PPT
Pressman ch-1-software
PPT
Intro
PDF
Software engineering a practitioners approach 8th edition pressman solutions ...
PPT
DOCX
Notes of Software engineering and Project Management
PPTX
Introduction To Software Engineering
PPT
Unit1
PPTX
Software engineering principles in system software design
PPT
Software engineering introduction
PPT
DevOps101 (version 2)
PPTX
DevOps 101 - IBM Impact 2014
PPT
Slides chapter 1
PDF
Devops Strategy Roadmap Lifecycle Ppt Powerpoint Presentation Slides Complete...
PPTX
DevOps evolution architecting the modern software factory - cloud expo east 2017
PPT
Introduction to Software Engineering
PDF
Mainframe DevOps: A Zowe CLI-enabled Roadmap
PPT
Chapter 01
PDF
Pulse 2013: DevOps Review and Roadmap
Software systems engineering PRINCIPLES
Pressman ch-1-software
Intro
Software engineering a practitioners approach 8th edition pressman solutions ...
Notes of Software engineering and Project Management
Introduction To Software Engineering
Unit1
Software engineering principles in system software design
Software engineering introduction
DevOps101 (version 2)
DevOps 101 - IBM Impact 2014
Slides chapter 1
Devops Strategy Roadmap Lifecycle Ppt Powerpoint Presentation Slides Complete...
DevOps evolution architecting the modern software factory - cloud expo east 2017
Introduction to Software Engineering
Mainframe DevOps: A Zowe CLI-enabled Roadmap
Chapter 01
Pulse 2013: DevOps Review and Roadmap
Ad

Similar to software (20)

PPT
Chapter_01_of_slides_of_software_engineering_book.ppt
PDF
Ch01 SE
PPT
Software Engineering
PPT
Chapter 01 software engineering pressman
PPT
PPT-UEU-Rekayasa-Perangkat-Lunak-Pertemuan-1.ppt
PPT
Chapter 01
PPTX
Software Engineering Chapter-1 Basic Concepts
PDF
chapter1 introduction of software engneering.pdf
PPT
Introduction to Software Engineering.ppt
PDF
Software Engineering Lecture for Computer Science.pdf
PDF
Software Engineering Introduction by Dr M Zhu
PPT
Chapter 01
PPT
Rekayasa Perangkat Lunak Pertemuan 1 RPL
PPT
SE CHAPTER 1 SOFTWARE ENGINEERING
PPTX
Week_01-Intro to Software Engineering (1).pptx
PPTX
III-I SOFTWARE ENGINEERING TOPICS UNIT-1.pptx
PPTX
SE&PM-MODULE-1 2.pptx Software engineering
PPTX
Software Engineering and management project development
PPT
Week_01-Intro to Software Engineering-1.ppt
Chapter_01_of_slides_of_software_engineering_book.ppt
Ch01 SE
Software Engineering
Chapter 01 software engineering pressman
PPT-UEU-Rekayasa-Perangkat-Lunak-Pertemuan-1.ppt
Chapter 01
Software Engineering Chapter-1 Basic Concepts
chapter1 introduction of software engneering.pdf
Introduction to Software Engineering.ppt
Software Engineering Lecture for Computer Science.pdf
Software Engineering Introduction by Dr M Zhu
Chapter 01
Rekayasa Perangkat Lunak Pertemuan 1 RPL
SE CHAPTER 1 SOFTWARE ENGINEERING
Week_01-Intro to Software Engineering (1).pptx
III-I SOFTWARE ENGINEERING TOPICS UNIT-1.pptx
SE&PM-MODULE-1 2.pptx Software engineering
Software Engineering and management project development
Week_01-Intro to Software Engineering-1.ppt
Ad

Recently uploaded (20)

PDF
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
PDF
Adobe Illustrator 28.6 Crack My Vision of Vector Design
PDF
Design an Analysis of Algorithms II-SECS-1021-03
PDF
Understanding Forklifts - TECH EHS Solution
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
PPTX
Odoo POS Development Services by CandidRoot Solutions
PDF
System and Network Administration Chapter 2
PPTX
CHAPTER 2 - PM Management and IT Context
PDF
Digital Strategies for Manufacturing Companies
PDF
medical staffing services at VALiNTRY
PPTX
history of c programming in notes for students .pptx
PDF
Design an Analysis of Algorithms I-SECS-1021-03
PDF
Nekopoi APK 2025 free lastest update
PDF
Softaken Excel to vCard Converter Software.pdf
PPTX
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
PPTX
ISO 45001 Occupational Health and Safety Management System
PDF
top salesforce developer skills in 2025.pdf
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
Adobe Illustrator 28.6 Crack My Vision of Vector Design
Design an Analysis of Algorithms II-SECS-1021-03
Understanding Forklifts - TECH EHS Solution
Which alternative to Crystal Reports is best for small or large businesses.pdf
Odoo POS Development Services by CandidRoot Solutions
System and Network Administration Chapter 2
CHAPTER 2 - PM Management and IT Context
Digital Strategies for Manufacturing Companies
medical staffing services at VALiNTRY
history of c programming in notes for students .pptx
Design an Analysis of Algorithms I-SECS-1021-03
Nekopoi APK 2025 free lastest update
Softaken Excel to vCard Converter Software.pdf
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
2025 Textile ERP Trends: SAP, Odoo & Oracle
ISO 45001 Occupational Health and Safety Management System
top salesforce developer skills in 2025.pdf
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...

software

  • 1. An Introduction to Software Engineering
  • 2. 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.
  • 3. 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 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.
  • 4. 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? 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.
  • 5. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 Wear vs. Deterioration
  • 6. 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.
  • 7. 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.
  • 8. 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.
  • 9. 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.
  • 10. 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.
  • 11. 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.
  • 12. 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,
  • 13. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13 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.
  • 14. 14 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!)
  • 15. 15 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.
  • 16. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 16 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.
  • 17. . 17 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 as technical design.
  • 18. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 18 A Layered Technology Software Engineering a “quality” focus process model methods tools
  • 19.  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. 19
  • 20.  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. 20
  • 21. 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 21
  • 22. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22 A Process Framework Process framework Framework activities Umbrella Activities
  • 23. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23 Framework Activities  Communication  Planning  Modeling  Analysis of requirements  Design  Construction  Code generation  Testing  Deployment
  • 24. 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. 24
  • 25. 25 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
  • 26.  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. 26
  • 27. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27 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
  • 28. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 28 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).
  • 29. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 29 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?
  • 30. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 30 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?
  • 31. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31 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?
  • 32. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 32 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?
  • 33. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33 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!