Chapter 2_Process Models sunorgamisedASE_finalised.ppt

Chapter 2
• Process Models
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student
use.
These slides are designed to accompany
Software Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman. 1

Process and Product
• software products are the
outcomes of a software project..
• A software process specifies the
abstract set of activities that should
be performed to go from user needs
to final product

The software process
• A structured set of activities required to develop a
software system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract
representation of a process. It presents a description
of a process from some particular perspective.

Other Process Models
• Component based development—the process to apply
when reuse is a development objective
• Formal methods—emphasizes the mathematical
specification of requirements
• AOSD—provides a process and methodological approach
for defining, specifying, designing, and constructing
aspects
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned
with the Unified Modeling Language (UML)

Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule
is created.
• High-level design. External specifications for each component to be
constructed are developed and a component design is created. Prototypes
are built when uncertainty exists. All issues are recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are
applied to uncover errors in the design. Metrics are maintained for all
important tasks and work results.
• Development. The component level design is refined and reviewed. Code
is generated, reviewed, compiled, and tested. Metrics are maintained for all
important tasks and work results.
• Postmortem. Using the measures and metrics collected (this is a
substantial amount of data that should be analyzed statistically), the
effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness.

Team Software Process
(TSP)
• Build self-directed teams that plan and track their work, establish
goals, and own their processes and plans. These can be pure
software teams or integrated product teams (IPT) of three to about
20 engineers.
• Show managers how to coach and motivate their teams and how to
help them sustain peak performance.
• Accelerate software process improvement by making CMM Level 5
behavior normal and expected.
– The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process, is discussed in Chapter 30.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.

Generic software process models
• The waterfall model
– Separate and distinct phases of specification and
development.
• Evolutionary development
– Specification, development and validation are
interleaved.
• Component-based software engineering
– The system is assembled from existing components.
• There are many variants of these models e.g. formal
development where a waterfall-like process is used
but the specification is a formal specification that is
refined through several stages to an implementable
design. These slides are designed to accompany

A Generic Process Model

Process Flow

Process Patterns
• A process pattern
– describes a process-related problem that is
encountered during software engineering work,
– identifies the environment in which the problem has
been encountered, and
– suggests one or more proven solutions to the problem.
• Stated in more general terms, a process pattern
provides you with a template [Amb98]—a
consistent method for describing problem
solutions within the context of the software
process.

Process Pattern Types
• Stage patterns—defines a problem associated
with a framework activity for the process.
• Task patterns—defines a problem associated
with a software engineering action or work task
and relevant to successful software engineering
practice
• Phase patterns—define the sequence of
framework activities that occur with the process,
even when the overall flow of activities is
iterative in nature.

Process Assessment and Improvement
• Standard CMMI Assessment Method for Process Improvement
(SCAMPI) — provides a five step process assessment model that
incorporates five phases: initiating, diagnosing, establishing, acting and
learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—
provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment
[Dun01]
• SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent of the standard is
to assist organizations in developing an objective evaluation of the efficacy
of any defined software process. [ISO08]
• ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]

The requirements engineering
process

Requirements engineering
 Requirements engineering involves three key activities.
1. These are discovering requirements by interacting with
stakeholders (elicitation and analysis);
2.converting these requirements into a standard form (specification);
3. checking that the requirements actually define the system that the
customer wants (validation).
 These are shown as sequential processes in practice, requirements
engineering is an iterative process in which the activities are
interleaved.
 The output of the RE process is a system requirements document.
 The amount of time and effort devoted to each activity in an iteration
depends on the stage of the overall process, the type of system being
developed, and the budget that is available.
 Early in the process, most effort will be spent on understanding high-
level business and non-functional requirements, and the user
requirements for the system.

Requirements engineering
 Later in the process, in the outer rings of the spiral, more effort will be
devoted to eliciting and understanding the non-functional requirements and
more detailed system requirements.
 This spiral model accommodates approaches to development where the
requirements are developed to different levels of detail.
 The number of iterations around the spiral can vary so that the spiral can be
exited after some or all of the user requirements have been elicited.
 Agile development can be used instead of prototyping so that the
requirements and the system implementation are developed together. In
virtually all systems, requirements change.
 The people involved develop a better understanding of what they want the
software to do; the organization buying the system changes; and
modifications are made to the system’s hardware, software, and
organizational environment.
 Changes have to be managed to understand the impact on other
requirements and the cost and system implications of making the change

Requirements Engineering

Stages in RE
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

Inception
• Ask a set of questions that establish …
– basic understanding of the problem
– the people who want a solution
– the nature of the solution that is desired
– the effectiveness of preliminary
communication and collaboration between the
customer and the developer

Elicitation
• Elicit requirements from all stakeholders
– address problems of scope
– address problems of understanding
• customers are not sure about what is needed, skip
“obvious” issues, have difficulty communicating
with the software engineer, have poor grasp of
problem domain
– address problems of volatility (changing
requirements)

Elaboration and negotiation
• Elaboration: create an analysis model that identifies data, function, features,
constraints and behavioral requirements
• Negotiation: agree on a deliverable system that is realistic for developers
and customers
– rank requirements by priority (conflicts arise here …)
– identify and analyze risks assoc. with each
requirement
– “guestimate” efforts needed to implement each
requirement
– eliminate, combine and / or modify requirements to
make project realistic

Specification
• can be in any one (or more) of the
following:
– A written document
– A set of models
– A formal mathematical model
– A collection of user scenarios (use-cases)
– A prototype

Validation
• a review mechanism that looks for:
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large
products or systems are engineered)
– conflicting or unrealistic (unachievable)
requirements
– tests for requirements

Management
Involves managing change:
– Feature traceability: how requirements relate to
observable system/product features
– Source traceability: identifies source of each
requirement
– Dependency traceability: how requirements are
related to each other
– Subsystem traceability: categorizes requirements
by the sub system (s) they govern
– Interface traceability: how requirements relate to
both external and internal system interfaces

Building the Analysis Model
Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an
“actor” and the system
– Class-based elements
• Implied by scenarios
– Behavioral elements
• State diagram
– Flow-oriented elements
• Data flow diagram

Use Case Diagrams

Use Case Model Survey
• The Use Case Model Survey is to illustrate, in graphical
form, the universe of Use Cases that the system is
contracted to deliver.
• Each Use Case in the system appears in the Survey
with a short description of its main function.
– Participants:
• Domain Expert
• Architect
• Analyst/Designer (Use Case author)
• Testing Engineer

Use Cases
 What is a Use Case
-A scenario-based technique in the UML
• -A formal way of representing how a business
system interacts with its environment
 -Illustrates the activities that are performed by the
users of the system
 -A sequence of actions a system performs that yields a
valuable result for a particular actor.
 -Use case diagrams describe what a system does from the standpoint
of an external observer. The emphasis is on what a system does rather
than how.
 -Use case diagrams are closely connected to scenarios. A
scenario is an example of what happens when someone
interacts with the system.

Use Case Diagram - Use Case
• A major process performed by the system
that benefits an actor(s) in some way
• Models a dialogue between an actor and
the system
• Represents the functionality provided by
the system

Use Case Diagram components
 An Actor is outside or
external to the system.
 It can be a:
 Human
 Peripheral device (hardware)
 External system or
subsystem
 Time or time-based event
 Represented by stick figure
 Labelled using a descriptive
noun or phrase
l Use Case
l Labelled using a
descriptive verb-
noun phrase
l Represented by
an oval
Make
Appointment

Use Case - Relationships
• Relationships
– Represent communication between actor
and use case
– Depicted by line or double-headed arrow
line
– Also called association relationship
Make
Appointment
l Boundary
• A boundary rectangle is placed
around the perimeter of the
system to show how the actors
communicate with the system.
Make
Appointment

Use-Case Diagram
A use case diagram is a collection of actors, use cases, and their
communications.

Use Case Diagram
• Other Types of Relationships for Use
Cases
– Generalization
– Include
– Extend

Components of Use Case Diagram
• Generalization Relationship
– Represented by a line and a hollow arrow
• From child to parent
Child use case Parent use case

Example of Relationships

Use Case Diagram
• Include Relationship
– Represents the inclusion of the functionality of
one use case within another
– Arrow is drawn from the base use case to the
used use case
– Write << include >> above arrowhead line

Use Case Diagram
• Extend relationship
– Represents the extension of the use case to
include optional functionality
– Arrow is drawn from the extension use case
to the base use case
– Write << extend >> above arrowhead line

Example of Relationships

Benefits of Use Cases
 Use cases are described using the language of the customer (language
of the domain which is defined in the glossary)
 Use cases provide a contractual delivery process
 Use cases provide an easily-understood communication mechanism
 When requirements are traced, they make it difficult for requirements to
fall through the cracks
 Use cases provide a concise summary of what the system should do at
an abstract level.
Difficulties with Use Cases
 Use Cases make stating non-functional requirements difficult (where do
you say that X must execute at Y/sec?)

Structure Diagrams
Provide a way for representing the data and
static relationships that are in an information
system eg.(classdiagram)
– Class Diagram
– Describe the structure of the system in terms
of classes and objects
– Primary purpose during analysis workflow: to
create a vocabulary that is used by both the
analyst and users

What is a Class?
• A general template that we use to create
specific instances or objects in the
application domain
• Represents a kind of person, place, or
thing about which the system will need to
capture and store information
• Abstractions that specify the attributes and
behaviors of a set of objects

What is an Object?
• Entities that encapsulate state and
behavior
• Each object has an identity
– It can be referred individually
– It is distinguishable from other objects

Attributes in a Class
 Properties of the class about which we want
to capture information
 Only add attributes that are primitive or
atomic types
 Derived attribute
 attributes that are calculated or derived from
other attributes
 denoted by placing slash (/) before name

Operations in a Class
• Represents the actions or functions
that a class can perform
• Describes the actions to which the
instances of the class will be capable
of responding
• Can be classified as a constructor,
query, or update operation

UML Representation of Class
.
Class Name
Attributes of Class
Operations/methods of
Class

Example of a Class Diagram
Video Rental System
methods
class name
Video
+rentMovie()
Customer
-CID: int
-name: String
+authenticateCustomer ()
relationship
rents
1..*
1..*
multiplicity
visibility
attributes
-cassetteID : int
-cassetteVolumeNo: int

Visibility
of Attributes and Operations
Relates to the level of information hiding to be enforced

Relationships among Classes
• Represents a connection between
multiple classes or with in
• 3 basic categories:
–association relationships
–generalization relationships
–aggregation relationships

Association Relationship
• A bidirectional semantic connection
between classes
• Type:
–name of relationship
–role that classes play in the relationship

Association Relationship
• Name of relationship type shown by:
–drawing line between classes
–labeling with the name of the relationship
–indicating with a small solid triangle
beside the name of the relationship in
the direction of the association
Provides
Patient Medical History

Generalization Relationship
Person
Employee Customer
Manager Engineer
Enables the analyst to create classes
that inherit attributes and operations
of other classes
Represented by a-kind-of
relationship

Employee
hireDate
receivePay
performWork
Manager
department
bonus
hireEmployee
promoteEmployee
Engineer
certifications
Analyze design

Person
Employee Contractor
Manager Engineer
Preferred
Contractor
Secondary
Contractor

Aggregation Relationship
• Specialized form of association in which a
whole is related to its part(s)
• Represented by a-part-of relationship
• Denoted by placing a diamond nearest the
class representing the aggregation
provides
1 0..1
Denotes the minimum number.. maximum number of instances
Exactly one 1
Zero or more 0..* or 0..m
One or more 1..* or 1..m
Zero or one 0..1
Specified range 2..4
Multiple, disjoint ranges 1..3, 5

Multiplicity
• Documents how many instances of a
class can be associated with one
instance of another class
provides
1 0..1

Class Diagram (expectation)
• Ensure that the classes are both necessary
and sufficient to solve the underlying
problem
–no missing attributes or methods in each
class
–no extra or unused attributes or methods
in each class
–no missing or extra classes

State Diagram(behavioural elements based)
Reading
Commands
System status = “ready”
Display msg = “enter cmd”
Display status = steady
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State name
State variables
State activities

UML state diagrams
 State diagram: Depicts data and behavior of a single
object throughout its lifetime.
 set of states (including an initial start state)
 transitions between states
 entire diagram is drawn from that object's perspective
 similar to finite state machines (DFA, NFA, PDA, etc.)

State ,Transitions
• State: conceptual description of the data in the object
– represented by object's field values
• Transition: movement from one state to
another
• transitions must be mutually exclusive
(deterministic)
– must be clear what transition to take for an event

State diagram example
ATM
software
states
at
a
bank

Super/substates
• When one state is complex, you can
include substates in it.
– drawn as nested rounded rectangles within
the larger state
– Caution: Don't over-use this feature.
– easy to confuse separate states for sub-states
within one state

Quality Function Deployment
 Quality function deployment (QFD) is a quality management technique that translates the needs of the
customer into technical requirements for software.
 QFD “concentrates on maximizing customer satisfaction from the software engineering process” [Zul92].
 To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then
deploys these values throughout the engineering process.
 QFD identifies three types of requirements [Zul92]:
1.Normal requirements. The objectives and goals that are stated for a product or system during meetings with
the customer. If these requirements are present, the customer is satisfied.
 Examples of normal requirements might be requested types of graphical displays, specific system
functions, and defined levels of performance.
2. Expected requirements. These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them.
 Their absence will be a cause for significant dissatisfaction.
 Examples of expected requirements are: ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation.
3. Exciting requirements.
 These features go beyond the customer’s expectations and prove to be very satisfying when present. For
example, software for a new mobile phone comes with standard features, but is coupled with a set of
unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product

Quality Function Deployment
3. Exciting requirements.
 These features go beyond the customer’s expectations and prove to be very satisfying when
present. For example, software for a new mobile phone comes with standard features, but is
coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) that
delight every user of the product.
 QFD techniques
 Although QFD concepts can be applied across the entire software process [Par96a], specific QFD
techniques are applicable to the requirements elicitation activity.
 QFD uses customer interviews and observation, surveys, and examination of historical data (e.g.,
problem reports) as raw data for the requirements gathering activity.
 These data are then translated into a table of requirements—called the customer voice table—
that is reviewed with the customer and other stakeholders.
 A variety of diagrams, matrices, and evaluation methods are then used to extract expected
requirements and to attempt to derive exciting requirements.

Requirements validation
• Requirements validation is the process of checking that
requirements define the system that the customer really wants.
• It overlaps with elicitation and analysis, as it is concerned with
finding problems with the requirements. Requirements validation is
critically important because errors in a requirements document can
lead to extensive rework costs when these problems are discovered
during development or after the system is in service.
• The cost of fixing a requirements problem by making a system
change is usually much greater than repairing design or coding
errors.
• A change to the requirements usually means that the system design
and implementation must also be changed.

Requirements validation
 During the requirements validation process, different types of checks should be
carried
 1. Validity checks These check that the requirements reflect the real needs of system
users. Because of changing circumstances, the user requirements may have
changed since they were originally elicited.
 2. Consistency checks Requirements in the document should not conflict. That is,
there should not be contradictory constraints or different descriptions of the same
system function.
 3. Completeness checks The requirements document should include requirements
that define all functions and the constraints intended by the system user.
 4. Realism checks By using knowledge of existing technologies, the requirements
should be checked to ensure that they can be implemented within the proposed
budget for the system.
These checks should also take account of the budget and schedule for the system
development.
 5. Verifiability To reduce the potential for dispute between customer and contractor,
system requirements should always be written so that they are verifiable.

Assignment to be handed over in 7 days
1. What is the fundamental difference between the structured analysis
and object-oriented strategies for requirements analysis?
2. In a data flow diagram, does an arrow represent a flow of control
or something else?
3. What is “information flow continuity” and how is it applied as a data
flow diagram is refined?
4. How is a grammatical parse used in the creation of a DFD?
5. What is a control specification?
6. Are a PSPEC and a use case the same thing? If not, explain the
differences.
7. There are two different types of “states” that behavioral models
can represent. What are they?
8. How does a sequence diagram differ from a state diagram. How
are they similar? These slides are designed to accompany

• End of Chapter 2

Chapter 2_Process Models sunorgamisedASE_finalised.ppt

More Related Content

Similar to Chapter 2_Process Models sunorgamisedASE_finalised.ppt (20)

More from Bule Hora University (6)

Recently uploaded (20)

Chapter 2_Process Models sunorgamisedASE_finalised.ppt