chapter 2 process models software engineering: a practitioner’s approach, 7/e by roger s. pressman
TRANSCRIPT
Chapter 2
Process Models
Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman
2
Software Engineering
• The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software;
• that is, the application of engineering to software.
The IEEE definitionThe IEEE definition
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
A Layered Technology
3
a “quality” focus
process model
methods
tools
“We think that software developers are missing a vital truth: most organizations don’t know what they do. They think they know, but they don’t know.”
Tom DeMarco
Are All developers good?
4
A Layered Technology (cont.)
• Quality – Any engineering approach must rest on organizational
commitment to quality and to assure a continuous process improvement culture.
• Process– Defines as a collection of work activities, actions, and tasks that
are performed when some work product is to be created.– Defines who is doing what, when, and how to reach a certain goal.– Forms the basis for management control of software projects.
• Methods – technical “how to” for building software– Broad array of tasks: communication, requirements analysis,
design modeling, program construction, testing, and support• Tools
– Automated support for process and methods5
A Layered Technology (cont.)
6
A Process Framework
Process frameworkFramework activities work tasks
work products milestones & deliverables checkpoints
Umbrella Activities
Process framework
Umbrella Activities
Framework activity 1
Framework activity n
Software Process
7
Five Activities of a Generic Process framework
1. Communication2. Planning3. Modeling
– Analysis of requirements– Design
4. Construction– Code generation– Testing
5. Deployment – Delivery– Feedback
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Five Activities of a Generic Process framework (cont.)
• Communication: communicate with customer to understand
objectives and gather requirements
• Planning:
• Modeling:
• Construction:
• Deployment:
8
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Five Activities of a Generic Process framework (cont.)
• Communication:
• Planning: creates a “map” that defines the work by describing
tasks, risks and resources, work products and work schedule.
• Modeling:
• Construction:
• Deployment:
9
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Five Activities of a Generic Process framework (cont.)
• Communication:
• Planning:
• Modeling: Create a “sketch”, what it looks like architecturally, how
the essential parts fit together and other characteristics.
• Construction:
• Deployment:
10
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Five Activities of a Generic Process framework (cont.)
• Communication:
• Planning:
• Modeling:
• Construction: code generation and the testing.
• Deployment:
11
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Five Activities of a Generic Process framework (cont.)
• Communication:
• Planning:
• Modeling:
• Construction:
• Deployment: Delivered to the customer who evaluates the
products & provides feedback based on the evaluation.
12
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
13
• These five framework activities can be used to all software development, regardless of the application domain, size of the project, complexity of the efforts etc.– though the details will be different in each case.
• For many software projects, these framework activities are applied iteratively as a project progresses. Each iteration produces a software increment that provides a subset of overall software features and functionality.
Five Activities of a Generic Process framework (cont.)
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Complete the five process framework activities and
help team manage and control progress, quality, change, and risk. – Software project tracking and control:– Risk management:– Software quality assurance:– Technical reviews:– Measurement:– Software configuration management: – Reusability management: – Work product preparation and production:
14
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control: assess progress against the plan and take
actions to maintain the schedule. • Risk management: • Software quality assurance:• Technical reviews:
• Measurement:
• Software configuration management:
• Reusability management:
• Work product preparation and production:
15
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control:• Risk management: assesses risks that may affect the outcome and quality. • Software quality assurance:• Technical reviews:
• Measurement:
• Software configuration management:
• Reusability management:
• Work product preparation and production:
16
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control: • Risk management:• Software quality assurance: defines and conduct activities to ensure quality. • Technical reviews:
• Measurement:
• Software configuration management:
• Reusability management:
• Work product preparation and production:
17
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control:• Risk management:• Software quality assurance:• Technical reviews: assesses work products to uncover and remove errors before
going to the next activity.
• Measurement:
• Software configuration management:
• Reusability management:
• Work product preparation and production:
18
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control:• Risk management:• Software quality assurance:• Technical reviews:
• Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met.
• Software configuration management:
• Reusability management:
• Work product preparation and production:
19
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control:• Risk management:• Software quality assurance:• Technical reviews:
• Measurement:
• Software configuration management: manage the effects of change throughout the software process.
• Reusability management:
• Work product preparation and production:
20
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control:• Risk management:• Software quality assurance:• Technical reviews:
• Measurement:
• Software configuration management:
• Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components.
• Work product preparation and production:
21
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities• Software project tracking & control:• Risk management:• Software quality assurance:• Technical reviews:
• Measurement:
• Software configuration management:
• Reusability management:
• Work product preparation and production: create work products such as models, documents, logs, forms and lists.
22
23These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Process Flow
24
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, – suggests one or more proven solutions to the problem.
25
Process Pattern Types
1. Stage patterns2. Task patterns3. Phase patterns
26
Process Pattern Types
1. Stage patterns—defines a problem associated with a framework activity for the process.
2. Task patterns3. Phase patterns
27
Process Pattern Types
1. Stage patterns2. Task patterns—defines a problem
associated with a software engineering action or work task and relevant to successful software engineering practice
3. Phase patterns
28
Process Pattern Types
1. Stage patterns2. Task patterns3. Phase patterns—define the
sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.
Prescriptive Process Models
• Traditional process models• Specialized process models• Unified process
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Traditional Process Models• Defines a distinct set of activities, actions, tasks,
milestones, and work products that are required to engineer high-quality software
• The activities can be – linear, – incremental, – evolutionary
31
Waterfall Model(Diagram)
CommunicationProject initiation
Requirements gathering
PlanningEstimatingScheduling
Tracking ModelingAnalysisDesign Construction
CodeTest Deployment
DeliverySupport
Feedback
32
Waterfall Model(Description)
• Oldest software lifecycle model & best understood by upper management
• Used when requirements are well understood and risk is low
• Work flow is in a linear fashion (i.e., sequential)
• Used often with well-defined adaptations or enhancements to current software
33
Waterfall Model(Problems)
• Doesn't support iteration, so changes can cause confusion
• Difficult for customers to state all requirements explicitly and up front
• Requires customer patience because a working version of the program doesn't occur until the final phase
34
Incremental Model(Diagram)
Communication PlanningModeling
ConstructionDeployment
Communication PlanningModeling
ConstructionDeployment
Communication PlanningModeling
ConstructionDeployment
Increment #1
Increment #2
Increment #3
35
Incremental Model(Description)
• Used when requirements are well understood• Multiple independent deliveries are identified• Work flow is in a linear (i.e., sequential) fashion within an increment
and is staggered between increments• Iterative in nature; focuses on an operational product with each
increment• Provides a needed set of functionality sooner while delivering optional
components later• Useful also when staffing is too short for a full-scale development
36
Prototyping Model(Diagram)
Communication
Quick Planning
ModelingQuick Design
ConstructionOf Prototype
Deployment,Delivery,
and Feedback
Start
37
Prototyping Model(Description)
• Follows an evolutionary and iterative approach• Used when requirements are not well understood• Serves as a mechanism for identifying software requirements• Focuses on those aspects of the software that are visible to the
customer/user• Feedback is used to refine the prototype
38
Prototyping Model(Potential Problems)
• The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software running quickly – (e.g., language choice, user interface, operating system choice, inefficient
algorithms)
39
Spiral Model(Diagram)
Start
Start
Communication
Planning
Modeling
ConstructionDeployment
40
Spiral Model(Description)
• Follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development
41
General Weaknesses of Evolutionary Process Models
1) Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product
2) Evolutionary software processes do not establish the maximum speed of the evolution
• If too fast, the process will fall into chaos• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and extensibility, and second on high quality
• We should prioritize the speed of the development over zero defects• Extending the development in order to reach higher quality could
result in late delivery
Specialized Process Models
43
Component-based Development Model• Consists of the following process steps
– Available component-based products are researched and evaluated for the application domain in question
– Component integration issues are considered– A software architecture is designed to accommodate the
components– Components are integrated into the architecture– Comprehensive testing is conducted to ensure proper
functionality
• Relies on a robust component library
• Capitalizes on software reuse, which leads to documented savings in project cost and time
44
Formal Methods Model(Description)
• Encompasses a set of activities that leads to formal mathematical specification of computer software
• Enables a software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily through mathematical analysis
• Offers the promise of defect-free software• Used often when building safety-critical systems
45
Formal Methods Model(Challenges)
• Development of formal methods is currently quite time-consuming and expensive
• Because few software developers have the necessary background to apply formal methods, extensive training is required
• It is difficult to use the models as a communication mechanism for technically unsophisticated customers
The Unified Process
47
Background• They eventually worked together on a unified method, called the Unified
Modelling Language (UML)– UML is a robust notation for the modelling and development of object-
oriented systems– UML became an industry standard in 1997– However, UML does not provide the process framework, only the necessary
technology for object-oriented development
• Unified process developed which is a framework for object-oriented software engineering using UML– Draws on the best features and characteristics of conventional software
process models– Emphasizes the important role of software architecture– Consists of a process flow that is iterative and incremental, thereby
providing an evolutionary feel
48
Background (continued)
• Consists of 5 phases: 1. inception, 2. elaboration, 3. construction, 4. transition, 5. production
49
Phases of the Unified Process
communication
planning
modeling
construction
deployment
Inception Elaboration
Construction
TransitionProduction
50
(1) - Inception Phase• Encompasses both customer communication and planning
activities of the generic process
• Business requirements for the software are identified
• A rough architecture for the system is proposed
• A plan is created for an incremental, iterative development
• Fundamental business requirements are described through preliminary use cases– A use case describes a sequence of actions that are performed by a user
51
(2) - Elaboration Phase• Encompasses both the planning and modelling activities of the generic
process• Refines and expands the preliminary use cases• Expands the architectural representation to include five views
– Use-case model– Analysis model– Design model– Implementation model– Deployment model
• Often results in an executable architectural baseline that represents a first cut executable system
• The baseline demonstrates the viability of the architecture but does not provide all features and functions required to use the system
52
(3) - Construction Phase• Encompasses the construction activity of the generic process
• Uses the architectural model from the elaboration phase as input
• Develops or acquires the software components that make each use-case operational
• Analysis and design models from the previous phase are completed to reflect the final version of the increment
• Use cases are used to derive a set of acceptance tests that are executed prior to the next phase
53
(4) - Transition Phase• Encompasses the last part of the construction activity and the first
part of the deployment activity of the generic process
• Software is given to end users for beta testing and user feedback reports on defects and necessary changes
• The software teams create necessary support documentation (user manuals, trouble-shooting guides, installation procedures)
• At the conclusion of this phase, the software increment becomes a usable software release
54
(5) - Production Phase
• Encompasses the last part of the deployment activity of the generic process
• On-going use of the software is monitored
• Support for the operating environment (infrastructure) is provided
• Defect reports and requests for changes are submitted and evaluated
55
Unified Process Work Products• Work products are produced in each of the first four phases of the
unified process
• In this course, we will concentrate on the analysis model and the design model work products
• Analysis model includes– Scenario-based model, class-based model, and behavioural
model
• Design model includes– Component-level design, interface design, architectural design,
and data/class design
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
56
Agile Process Models
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Agile Process Models
– The prescriptive process models stress detailed definition, identification, and
application of process activates and tasks. Intent is to improve system quality, make
projects more manageable, make delivery dates and costs more predictable, and guide
teams of software engineers as they perform the work required to build a system.
– Unfortunately, there have been times when these objectives were not achieved. If
prescriptive models are applied strictly and without adaptation, they can increase the
level of organization.
– Agile process models emphasize project “agility (alertness)” and follow a set of
principles that lead to a more informal approach to software process. It emphasizes
maneuverability and adaptability. It is particularly useful when Web applications are
engineered.
57
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
The Essence of Practice• How does the practice of software engineering fit in the process
activities mentioned above? Namely, – communication,
– planning,
– modeling,
– construction
– deployment.
• the essence of problem solving is outlined in 4 points: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).58
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
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 classified? 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?
59
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
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 sub-problems be defined? If so, are solutions readily apparent for the sub-problems?
• Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?
60
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Carry Out the Plan• Does the solutions 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?
61
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
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?
62
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Software Myths Examples• Myth 1: Once we write the program and get it to work, our job is done.• Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to
80% of all efforts are spent after software is delivered to the customer for the first time.
• Myth 2: Until I get the program running, I have no way of assessing its quality.• Reality: technical review are a quality filter that can be used to find certain classes of
software defects from the inception of a project.
• Myth 3: software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.
• Reality: it is not about creating documents. It is about creating a quality product. Better quality leads to a reduced rework. Reduced work results in faster delivery times.
• Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods foster poor management and technical practices, even when reality dictates a better approach.
63
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
64
EndThank you