Vous êtes sur la page 1sur 337

MATERI KULIAH

Teknik Elektro S1

• MK Rekayasa Perangkat Lunak

http://ocw.usu.ac.id
 
 
DEPATEMEN TEKNIK ELEKTRO 
FAKULTAS TEKNIK 
UNIVERSITAS SUMATERA UTARA 
Jl. Almamater, Kampus USU, Medan 20155 
Phone: 061‐8213246, Fax: 061‐8213250 
 
 
 
COURSE SYLLABUS 
 
 
Course No  :   TEK‐336     
Unit  :  2 credits 
Course Title  :  Rekayasa Perangkat Lunak 
Class Schedule  :  Tuesday, 13.10‐14.50 
Lecturer  :  F. Rizal Batubara (rizal@usu.ac.id) 
 
       
Description 
This course will study a collection of methods which embody an "engineering" approach 
to the development of computer software. We will discuss the nature of software and 
software  projects,  software  development  models,  software  process  maturity,  project 
planning, management, and communication. We will study methods for analysis, design, 
testing,  and  implementation  of  large,  complex  software  systems.  We  will  inquire  into 
the various perspectives on software quality ‐‐ what it means, how to measure it, how 
to improve it. 
 
Course Objectives 
After finishing this course, students should be able to understand:  
• concept of software process  
• activities in software development  
• technical and managerial aspects of software development related to development 
methodologies, maturity level of the software developer organization  
• various life cycle models for software development  
• software quality assurance process  
• competency of software engineer profesional 

  1
Method of Delivery 
This is a student‐centered type of teaching where there will be lots of discussions and 
sharing  experiences  among  us.  Students  are  fully  suggested  to  be  active  and 
participative. 
 
Required Reading 
[1] Pressman,  Roger.  Software  Engineering:  A  Practitioner’s  Approach,  6th  Edition, 
Mc.Graw‐Hill International, USA, 2005.   
[2] Sommerville,  Ian,  Software  Engineering,  7th  Edition,  Pearson  Addison  Wesley, 
England, 2004 
[3] Online: www.sei.cmu.edu 
 
Assignments 
Readings.  Readings  are  an  essential  part  of  your  effort  to  understand  the  materials.  I 
suggest  that  you  read  ahead  and  use  class  time  to  ask  questions  that  weren’t  clear  in 
the readings or to share your thoughts with the class.  
Class  Participation.  Class  participations  consist  of  question  and  answer  (Q/A)  session, 
and class present. Q/A provides immediate feedback on previous materials and will be 
administered  at  the  end  of  each  chapter.  Class  participation  constitutes  10  percent  of 
your grade. 
Quizzes. There will be quizzes delivered in class a. No notification being made in advance 
to  deliver  quiz.  You  have  to  be  ready  anytime  for  a  short  time  quiz  as  a  medium  for 
immediate feedback.   
Case Analysis (Individual Project). The purpose of the case analysis is to summarize your 
thought processes and communicate them in writing. The length of the paper is limited 
to  ten  pages,  1.5‐spaced  with  margins  not  exceeding  one  inch.  Your  paper  should  be 
simple, concise and well‐written. Detailed instructions will be given in class. 
Group Project. There will be one software engineering project, which you will do as part 
of a team. The project will require you to make incremental deliveries through out the 
term, which will be graded. The objective of the project is to give you experience trying 
to apply the principles and techniques covered in the course, as part of team working on 
a real software product. The project will be carried out step‐by‐step. The progress will 
be monitored accordingly. 
Exams.  There  will  be  two  exams.  The  midterm  will  cover  the  first  eight  weeks  of  the 
course materials. The final exam will cover the next eight weeks of the course materials. 
These examinations will be "closed book". That is, no books or reference materials will 
be allowed in the examination room. These are the main check on how much you have 
learned from the course. 

  2
Evaluation 
Your final grade will not rest on one or two exams but will be based on how many points 
you accumulate throughout the semester. My view is that this would better reflect your 
learning  process  and  would  minimize  anxiety  associated  with  exams.  The  weights 
assigned to each component are as follows: 
  Class participation       10% 
  Quizzes     10% 
  Individual project      10% 
  Group Project     20% 
  Midterm exams     20% 
  Final exams       30% 
  Total                                        100% 
 
Class Policies 
Attendance.  Students are expected to attend class regularly. There are 80% minimum 
attendance requirements, and attendance sheets will be passed out and will be factored 
into your class participation grade. In the case of absence, students are responsible to 
stay  current  on  information  regarding  materials  covered  in  class  and  any  changes  in 
schedule.    
Late  Assignments.  For  each  day  an  assignment  is  turned  late,  the  total  grade  will  be 
deducted 5 (five) points. If you have a justified reason for not turning the assignment on 
time (e.g., due to extenuating circumstances), please let me know prior to the due date. 
I want to be flexible, yet fair to other students in the class. All late assignments are to be 
turned in to department. 
Academic  dishonesty  and  Incompletes.  Each  student  should  be  familiar  with  the 
guidelines  set  in  the    “Code  of  Student  Ethics”  for  issues  pertaining  to  academic 
dishonesty. No incompletes (I) will be assigned. There will be no makeup exams unless 
prior notice is given and documentation of emergency is given. 
   
   
 

  3
Topics and Schedule 
 
 

Week  Date  Lecture Topic  Readings 

1  26 Jan  Software Engineering introduction and  Pressman – Ch. 1 


course overview 

2  2 Feb  Software/product development processes  Pressman – Ch.2 

3  9 Feb  Software Process and Life Cycle  Pressman – Ch.3 

4  16 Feb  Teams Roles and Agile Development  Pressman – Ch.4 

5  23 Feb  Overview of Software Practice  Pressman – Ch.5 

6  2 Mar  Requirements Engineering  Pressman – Ch.7 

7  9 Mar  Requirements Analysis  Pressman – Ch.8 

8  16‐28 Mar  Mid Term Exam   

9  30 Mar  System Engineering  Pressman – Ch.6 

10  6 Apr  Architecture Design and Metaphors  Pressman – Ch.10 

11  13 Apr  Software Testing  Pressman – Ch.13 ‐14 

12  20 Apr  Software Project Management  Pressman – Ch.21 

13  27 Apr  Managing Software Quality  Pressman – Ch. 26 

14  4 Mei  Software Change Management  Pressman – Ch.27 

15  11 Mei  SEI CMM for Software Appraisal  www.sei.cmu.edu 

16  25 Mei – 6 Jun  Final Exam   


 
  

  4
Part 1
Introduction to
Software Engineering

copyright © 1996, 2001, 2005


R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used for


short courses, industry seminars, or consulting purposes.
1
Software’s Dual Role
• Software is a product
• Delivers computing potential
• Produces, manages, acquires, modifies, displays, or
transmits information
• Software is a vehicle for delivering a product
• Supports or directly provides system functionality
• Controls other programs (e.g., an operating system)
• Effects communications (e.g., networking software)
• Helps build other software (e.g., software tools)

2
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...

3
What is Software?
• software is engineered
• software doesn’t wear out
• software is complex

4
Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

5
Software Applications
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software
• WebApps (Web applications)
• AI software

6
Software—New Categories
• Ubiquitous computing—wireless networks
• Netsourcing—the Web as a computing engine
• Open source—”free” source code open to the
computing community (a blessing, but also a
potential curse!)
• Also … (see Chapter 32)
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies 7
Legacy Software
• 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.

Why must it change?

8
E-Type Systems
• E-Type Systems:
Software that has been implemented in a real-world
computing context and will therefore evolve over
time

9
Software Evolution
• The Law of Continuing Change (1974): E-type systems must be continually adapted else they become
progressively less satisfactory.
• The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless
work is done to maintain or reduce it.
• The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with
distribution of product and process measures close to normal.
• The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in
an evolving E-type system is invariant over product lifetime.
• The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it,
developers, sales personnel, users, for example, must maintain mastery of its content and behavior to
achieve satisfactory evolution.
• The Law of Continuing Growth (1980): The functional content of E-type systems must be continually
increased to maintain user satisfaction over their lifetime.
• The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they
are rigorously maintained and adapted to operational environment changes.
• The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi-
agent feedback systems and must be treated as such to achieve significant improvement over any
reasonable base.

10
Software Myths
• Affect managers, customers (and other non-
technical stakeholders) and practitioners
• Are believable because they often have elements of
truth,
• but …
• Invariably lead to bad decisions,
• therefore …
• Insist on reality as you navigate your way through
software engineering
11
Management Myths
• “We already have a book of standards and
procedures for building software. It does provide my
people with everything they need to know …”
• “If my project is behind the schedule, I always can
add more programmers to it and catch up …”
(a.k.a. “The Mongolian Horde concept”)
• “If I decide to outsource the software project to a
third party, I can just relax: Let them build it, and I
will just pocket my profits …”

12
Customer Myths
• “A general statement of objectives is sufficient to
begin writing programs - we can fill in the details
later …”

• “Project requirements continually change but this


change can easily be accommodated because
software is flexible …”

13
Practitioner’s Myths
• “Let’s start coding ASAP, because once we write the
program and get it to work, our job is done …”

• “Until I get the program running, I have no way of assessing


its quality …”

• “The only deliverable work product for a successful project


is the working program …”

• “Software engineering is baloney. It makes us create tons


of paperwork, only to slow us down …”
14
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 2
Process: A Generic View
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
A Layered Technology

Software Engineering

tools

methods

process model

a “quality” focus

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
A Process Framework

Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Umbrella Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
The Process Model:
Adaptability
 the framework activities will always be applied on
every project ... BUT
 the tasks (and degree of rigor) for each activity will
vary based on:
 the type of project
 characteristics of the project
 common sense judgment; concurrence of the project
team

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
The CMMI
 The CMMI defines each process area in terms of
“specific goals” and the “specific practices” required to
achieve these goals.
 Specific goals establish the characteristics that must
exist if the activities implied by a process area are to be
effective.
 Specific practices refine a goal into a set of process-
process-
related activities.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Process Patterns
 Process patterns define a set of activities, actions, work
tasks, work products and/or related behaviors
 A template is used to define a pattern
 Typical examples:
 Customer communication (a process activity)
 Analysis (an action)
 Requirements gathering (a process task)
 Reviewing a work product (a process task)
 Design model (a work product)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Process Assessment
 The process should be assessed to ensure that it meets
a set of basic process criteria that have been shown to
be essential for a successful software engineering.
 Many different assessment options are available:
 SCAMPI
 CBA IPI
 SPICE
 ISO 9001:2000

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Assessment and Improvement
Software Process

identifies is examined by identifies capabilities


modifications to and risk of

Software Process
Assessment

Capability
Software Process leads to leads to
Determination
Improvement

motivates

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Personal Software Process
(PSP)
 Recommends five framework activities:
 Planning
 High--level design
High
 High--level design review
High
 Development
 Postmortem
 stresses the need for each software engineer to
identify errors early and as important, to
understand the types of errors

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Team Software Process (TSP)
 Each project is “launched” using a “script” that
defines the tasks to be accomplished
 Teams are self-
self-directed
 Measurement is encouraged
 Measures are analyzed with the intent of
improving the team process

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
The Primary Goal of Any Software
Process: High Quality

Remember:

High quality = project timeliness

Why?

Less rework!

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Software Engineering: A Practitioner’s Approach,
6/e

Chapter 3
Prescriptive Process Models
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Prescriptive Models

 Prescriptive process models advocate an orderly approach to


software engineering

That leads to a few questions …


 If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they
imply) and replace them with something less structured, do we make
it impossible to achieve coordination and coherence in software
work?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
Waterfall Model
Com m unic a t ion
proje c t init ia t ion Planning
re quire m e nt ga t he ring estimating Mode ling
scheduling
analysis Const r uc t ion
tracking
design De ploy m e nt
code
t est de liv e ry
s upport
f e e dba c k

 A.k.a.: Classic Life Cycle


 Useful for problems that are well understood
 Real problems are more complex than that; changes = confusion
 Customer must state all requirements upfront
 Customer must have patience
 Lack of feedback to the customer makes blunders disastrous

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Incremental Model

increment # n
Co m m u n i c a t i o n
Pl a nni ng

M ode l ing
a na ly s is Co n s t ru c t i o n
d es ig n
c od e De p l o y m e n t
t es t d e l iv e ry
fe e dba c k

deliv ery of
nt h increment
increment # 2

Co m m u n i c a t i o n
Pl a nnin g

M ode l ing
an a ly s i s Co n s t ru c t i o n
de s ig n c od e De p l o y m e n t
t es t d e li v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pl a nning
M ode li ng
a n al y s is Co n s t ru c t i o n
d e s i gn code De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k
1st increment

project calendar t ime

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Incremental Model

 Applies elements of the waterfall model in incremental fashion


 First increment is often a core product
 Subsequent elements offer expanded functionality
 Subsequent features (some known, some unknown) are created,
while the core product may undergo evaluation
 If a customer requires deadlines that are impossible to meet,
a sequence of releases may solve the problem
 Permits for staffing of a team to fluctuate

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
RAD Model
Team # n
M o d e lin g
business m odeling
dat a m odeling
process m odeling

C o n s t r u c t io n
com ponent reuse
Team # 2 aut om at ic code
Com m unicat ion generat ion
t est ing
Mo d eling
b u si n e ss m o d e l in g
dat a m odeling
p ro ce ss m o d e l in g

Planning
Co nst r uct io n De ploym e nt
Team # 1 co m p o n e n t re u se
int egrat ion
a u t o m a t i c co d e
g e n e ra t i o n
deliv ery
Mode ling t e st i n g feedback
business modeling
dat a modeling
process modeling

Const r uct ion


component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
RAD Model
 Emphasizes short development cycle
 If requirements are well understood and project scope is
constrained, it may allow rapid creation of S/W systems
 For large projects may require vast human resources (for
many RAD teams)
 Developers and customers must be able to cope with fast
action
 For systems that are not highly modularized the RAD
approach may not work
 If systems require mutual tuning of various components, the
RAD approach may not work
 RAD may not be appropriate with technical risks high (new
technology)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Evolutionary Models: Prototyping

Q u ick p lan
Quick
Com m unicat ion plan
communication

Mo d e lin g
Modeling
Qu ick d e sig n
Quick design

Deployment
Deployment
De live r y
delivery & Const r uct ion
& Fe e dback Construction
feedback of
ofot
pr prototype
ot ype

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Evolutionary Models: Prototyping

 Useful when the customer has a legitimate need but is


clueless about the details
 First prototype may be barely useful: too slow, too big, too
unfriendly, etc.
DANGERS:
 The customer may “LOVE” the prototype which is held
together with “chewing gum”. When informed that it is a
prototype which has to be re-re-built, he may want “few fixes”
only
 The developer may be tempted to deliver the raw prototype as
a final product, sacrificing quality for a quick buck

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Evolutionary Models: The Spiral

 Combines iterative prototyping with systematic aspects of the


waterfall model
 Can be used throughout the S/W life cycle:
from conceptualization to maintenance
 Anchor point milestones are used for each evolutionary pass
 Anchor point milestones:
 Work products
 Required conditions to be attained
 Realistic to the development of large-
large-scale systems
 Iteratively reduces risk
 Allows repeated use of the prototyping approach
 PROBLEM: Customers may not like it, fearing lack of control

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Evolutionary Models: Concurrent
none

Modeling ac t iv it y

rep resent s t he st at e
Under o f a so f t ware eng ineering
act ivit y o r t ask
dev elopm ent

A w ait ing
changes

Under review

Under
revis ion

Baselined

Done

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Evolutionary Models: Concurrent
 The former image depicted only the modeling activity
 Indeed, concurrent engineering is a set of framework activities
such as Communication, Modeling, etc.
 Each of these activities is in one of its states…

 A state is some externally observable mode of behaviour

PROBLEMS::
PROBLEMS
 Prototyping (and other evolutionary processes) pose problems
to project planning (too much uncertainty)
 Evolutionary speed may not be optimal: too slow affects
productivity, too fast leads to chaos
 Sometimes software processes should focus on flexibility and
extensibility, rather than on quality - delivery delays may make
us miss the market niche and window of opportunity
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Still Other Process Models
 Component based development— development—the process to apply
when reuse is a development objective
 Formal methods— methods—emphasizes the mathematical
specification of requirements
 AOSD
AOSD— —provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects like security, fault tolerance,
adherence to business rules, systemic: DB mirroring,
memory management, concurrency
 Unified Process— Process—a “use- “use-case driven, architecture- architecture-
centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language
(UML)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
The Unified Process (UP)
Elabo r at ion
elaboration

Incept ion
inception

inception

const r uct io n
Release
t r ansit ion
soft ware increment

pr o duct ion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
UP Phases
UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Incept ion phase
UP Work Products
Elaborat ion phase
Vision document
Init ial use-case model
Init ial project glossary Const ruct ion phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Transit ion phase
Design model
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Deliv ered soft ware increment
Int egrat ed soft ware
Business model, Descript ion. increment Bet a t est report s
if necessary . Execut able archit ect ural General user feedback
Test plan and procedure
One or more prot ot y pes prot ot y pe.
I nc e pt i o
Test cases
n Preliminary design model Support document at ion
Rev ised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
Software Engineering: A Practitioner’s Approach,
6/e

Chapter 4
Agile Development
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
•Individuals and interactions over processes and
tools
•Working software over comprehensive
documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.”

Kent Beck et al.


These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
What is “Agility”?
 Effective (rapid and adaptive) response to change
 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the work
performed

Yielding …

 Rapid, incremental delivery of software

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
An Agile Process
 Is driven by customer descriptions of what is
required (scenarios)
 Recognizes that plans are short-
short-lived
 Develops software iteratively with a heavy
emphasis on construction activities
 Delivers frequent, multiple ‘software increments’
 Adapts as changes occur

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Agile Team
Characteristics
 Competence
 Common focus
 Collaboration
 Decisiveness
 Fuzzy problem-
problem-solving ability
 Mutual trust and respect
 Self--organization
Self

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Extreme Programming (XP)
 The most widely used agile process, originally
proposed by Kent Beck
 XP Planning
 Begins with the creation of “user
“user stories”
stories”
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project
“project velocity”(I.e.
velocity”(I.e. No. of
“stories
stories”” implemented during 1st release) is used to help
define subsequent delivery dates for other increments

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Extreme Programming (XP)
 XP Design
 Follows the KIS principle
 Encourage the use of CRC (Class-
(Class-Responsibility Collaborator) cards (see
Chapter 8)
 For difficult design problems, suggests the creation of “spike
“spike solutions”
solutions”—a design
prototype (tool for lowering risks)
 Encourages “refactoring
“refactoring””—an iterative refinement of the internal program design
 XP Coding
 Recommends the construction of a unit test for a store before coding commences
 Encourages “pair
“pair programming”
programming”
 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and executed to assess customer
visible functionality

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Extreme Programming (XP)
spike solut ions
simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

ref act oring

pair
programming

Release
sof t ware increment
unit t est
project velocit y comput ed cont inuous int egrat ion

accept
These courseware materials are to be used in conjunction ance
with t estEngineering:
Software ing A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Adaptive Software Development
 Originally proposed by Jim Highsmith
 Useful to changing project and business
conditions
 ASD — distinguishing features
 Mission-driven planning
Mission-
 Component--based focus
Component
 Uses “time
“time--boxing
boxing”” (See Chapter 24)
 Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning
“learning”” throughout the process
(focus groups; technical reviews; postmortems)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Adaptive Software Development
adapt ive cycle planning Requirement s gat hering
uses mission st at ement JAD
project const raint s mini-specs
basic requirement s
t ime-boxed release plan

Release
sof t ware increment
adjust ment s f or subsequent cycles
component s implement ed/ t est ed
f ocus groups for f eedback
f ormal t echnical reviews
post mort
These courseware materials are to be used in conjunction with Software Engineering: ems Approach, 6/e and are provided
A Practitioner’s
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Dynamic Systems Development Method

 Promoted by the DSDM Consortium (www.dsdm.org


(www.dsdm.org))
 DSDM—
DSDM —distinguishing features
 Similar in most respects to XP and/or ASD
 Nine guiding principles:
 Active user involvement is imperative.
 DSDM teams must be empowered to make decisions.
 The focus is on frequent delivery of products.
 Fitness for business purpose is the essential criterion for acceptance of deliverables.
 Iterative and incremental development is necessary to converge on an accurate
business solution.
 All changes during development are reversible.
 Requirements (functional+information; application architecture; maintainability) are
baselined at a high level.
 Testing is integrated throughout the life-
life-cycle.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Scrum
 Originally proposed by Schwaber and Beedle
 “Assumes up-
up-front that chaos exists”
 Scrum — distinguishing features:
 Small work teams (min. overhead; max. communication)
 Development work is partitioned into “packets
“packets””
 Testing and documentation are on- on-going as the product is
constructed
 Work occurs in “sprints
“sprints”” and is derived from a “backlog
“backlog”” of
existing requirements (frequent S/W increments)
 Meetings are very short and sometimes conducted without chairs
 “demos
demos”” are delivered to the customer with the time-
time-box allocated
 Constant testing and documentation

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Crystal
 Proposed by Cockburn and Highsmith

 Crystal — distinguishing features:


 Actually a family of process models that allow
“maneuverability
maneuverability”” (resource-
(resource-limited coop. game of invention
and communication) based on problem characteristics
 Face--to-
Face to-face communication is emphasized
 Suggests the use of “reflection
“reflection workshops”
workshops” to review the
work habits of the team

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Feature Driven Development
 Originally proposed by Peter Coad et al.
 FDD — distinguishing features:
 Emphasis is on defining “features”
 a feature “is a client-
client-valued function that can be implemented in two
weeks or less.”
 Uses a feature template
 <action> the <result> <by | for | of | to> a(n) <object>, viz:
 Add the product to a shopping cart
 Display the technical specs of a product
 A features list is created and “plan
“plan by feature”
feature” is conducted
 Design and construction merge in FDD

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Agile Modeling
 Originally proposed by Scott Ambler
 Suggests a set of agile modeling principles:
 Model with a purpose
 Use multiple models for different aspects of the system
 Travel light (keep only long-
long-term models)
 Content is more important than representation
 Know the models and the tools you use to create them
 Adapt locally (to the needs of the agile team)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 6
System Engineering
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
System … Wazzat?
 A set or arrangement of things related to
form a unity or organic whole
 A set of facts, rules, principles, etc…
classified and arranged to show a logical
plan linking the various parts
 A method or plan of classification or
arrangement
 An established method of doing
something; method; procedure

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
Computer--Based System
Computer

 A set or arrangement of elements


organized in order to accomplish some
predefined goal by processing
information

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
System Engineering
 Elements of a computer-
computer-based system
 Software
 Hardware
 People
 Database
 Documentation
 Procedures

 Systems
 A hierarchy of macro-
macro-elements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
The Hierarchy
Business or
Product Domain
World view

Domain of interest

Domain view

System element

Element view

Detailed view

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
System Modeling
 Define the processes that serve the needs of the view under
consideration.
 Represent the behavior of the processes and the assumptions
on which the behavior is based.
 Explicitly define both exogenous and endogenous input to the
model.
 Exogenous inputs link one constituent of a given view with other
constituents at the same level of other levels; endogenous input
links individual components of a constituent at a particular view.
 Represent all linkages (including output) that will enable the
engineer to better understand the view.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
System Modeling
 Restraining factors:
 ASSUMPTIONS reduce the number of possible
permutations or variations
 SIMPLIFICATIONS enable to create a model in a timely
fashion
 LIMITATIONS help to bound the system
 CONSTRAINTS guide the manners in which a model is
created and approaches taken when implementing the
model
 PREFERENCES indicate preferred architecture for all data,
functions and technology. May clash with other restraining
factors

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
System Simulation

 Used to verify and validate models before implementing


them

 Helps eliminating surprises during implementation

 Allows system engineers to “test drive” the specifications


of a system

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
System Engineering

 Two variants exist:

 Business Process Engineering


 Product Engineering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Business Process Engineering
 Uses an integrated set of procedures,
methods, and tools to identify how
information systems can best meet the
strategic goals of an enterprise
 Focuses first on the enterprise and then on
the business area
 Creates enterprise models, data models and
process models
 Creates a framework for better information
management distribution, and control

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
System Architectures
 Three different architectures must be analyzed and designed
within the context of business objectives and goals:

 Data architecture provides a framework for the information


needs of a business or business function

 Application architecture encompasses those elements of a


system that transform objects within the data architecture for
some business purpose

 Technology infrastructure provides the foundation for the


data and application architectures

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
The BPE Hierarchy
 Information strategy planning (ISP)
 strategic goals defined
 success factors/business rules identified
 enterprise model created

 Business area analysis (BAA)


 processes/services modeled
 interrelationships of processes and data

 Application Engineering
 a.k.a ... software engineering
 modeling applications/procedures that
address (BAA) and constraints of ISP

 Construction and delivery


 using CASE and 4GTs, testing
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Information Strategy Planning
 Management issues
 Define strategic business goals/objectives
 Isolate critical success factors
 Conduct analysis of technology impact
 Perform analysis of strategic systems

 Technical issues
 Create a top-
top-level data model
 Cluster by business/organizational area
 Refine model and clustering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Defining Objectives and Goals
 Objective—general statement of direction
Objective—
 Goal—
Goal—defines measurable objective: “reduce
manufactured cost of our product”
 Subgoals
Subgoals::
 decrease reject rate by 20% in first 6 months
 gain 10% price concessions from suppliers
 re
re--engineer 30% of components for ease of manufacture
during first year
 Objectives tend to be strategic while goals tend
to be tactical

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Business Area Analysis
 Define “naturally cohesive groupings of business
functions and data” (Martin)
 Perform many of the same activities as ISP, but
narrow scope to individual business area
 Identify existing (old) information systems /
determine compatibility with new ISP model
 Define systems that are problematic
 Defining systems that are incompatible with new
information model
 Begin to establish re-
re-engineering priorities

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
The BAA Process
admin.
manufacturing

sales QC distribution
acct eng’ring

Process
Decomposition Matrices
Process Diagram e.g.,
Flow Data entity/process
Models Model matrix

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Product Engineering
The complete
System analysis
product
(World view)

capabilities

hardware software
Component
engineering
(Domain view)

Processing requirement

function behavior
Analysis & Design
data
Modeling
(Element view)

program
component Software
Engineering

Construction
&
Integration
(Detailed view)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
Product Architecture Template
(after Hatley-
Hatley-Pirbhai)

user interface processing

input process and control output


processing functions processing

maintenance and self-test

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
Architecture Flow Diagram
operator
interface operator requests CLSS queries, reports, displays
operator
interface
subsystem
bar code acquisition request
shunt control status
sorting reports

CLSS processing & control report timing/location data


requests

part shunt shunt


bar code bar code number control controller
reader decoding subsystem
subsystem subsystem

raw bar bin


code data shunt commands
location
bar code
data base
access
subsystem report CLSS reports
line
sensor data speed key formating
acquisition subsystem
subsystem sort records
mainframe
communications
BCR status driver
diagnostics shunt status
pulse tach input sensor status
subsystem formated
communications status reporting data
data acquisition bar code
interface reader status diagnostic interface output interface

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
System Modeling with UML
 Deployment diagrams
 Each 3-
3-D box depicts a hardware element that is part of
the physical architecture of the system
 Activity diagrams
 Represent procedural aspects of a system element
 Class diagrams
 Represent system level elements in terms of the data that
describe the element and the operations that manipulate
the data
These and other UML models will be discussed later

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Deployment Diagram
CLSS processor

Sort ing subsyst em Operat or display

Sensor dat a
shunt cont roller
acquisit ion subsyst em

Conveyor Bar code reader Shunt act uat or


Pulse t ach

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
Activity Diagram
st a rt c o n v e y o r l in e

re a d b a r c o d e g e t c o n v e y o r sp e e d

valid bar code invalid bar code

d e t e r m i n e b i n l o c a t io n se t f o r re je c t b i n

se n d sh u n t
c o n t ro l d a t a

g e t sh u n t st a t u s re a d b a r c o d e g e t c o n v e y o r st a t u s

p ro d u c e re p o rt e n t ry

conveyor st opped conveyor in m ot ion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
Class Diagram
class name

Box
at t ribut es
barcode not e use of capit al
forwardSpeed let t er f or mult i-word
conveyorLocat ion at t ribut e names
height
widt h
dept h
weight
cont ent s
operat ions
( parent heses at end
readBarcode( ) of name indicat e t he
updat eSpeed ( ) list of at t ribut es t hat t he
readSpeed( ) operat ion requires)
updat eLocat ion( )
readLocat ion( )
get Dimensions( )
get Weight( )
checkCont ent s( )

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 7
Requirements Engineering
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Requirements Engineering
 Stages:
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Management

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
Requirements Engineering
 Inception—
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, and
 the effectiveness of preliminary communication and collaboration between
the customer and the developer

 Elicitation—
Elicitation—elicit requirements from all stakeholders
 address problems of scope
 address problems of understanding
 customers 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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Requirements Engineering
 Elaboration—create an analysis model that identifies data,
Elaboration—
function, features, constraints and behavioral requirements

 Negotiation—agree on a deliverable system that is realistic for


Negotiation—
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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Requirements Engineering
 Specification—
Specification—can be any one (or more) of the following:
 A written document
 A set of models
 A formal mathematical model
 A collection of user scenarios (use-
(use-cases)
 A prototype

 Validation—
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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Requirements Engineering
 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


subsystem(s) they govern

 Interface traceability: how requirements relate to both


external and internal system interfaces

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Inception
 Identify stakeholders
 “whom else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration

 The first questions:


 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Inception

 The subsequent questions:


 What constitutes a “good” output from the system?
 What problem(s) does this solution address?
 What is the intended business environment for this
solution?
 What performance issues or constraints should
affecting my approach to the solution

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Inception

 The final questions:


 Are your answers official?
 Are my questions relevant?
 Am I asking too many questions?
 Can anyone else provide additional info?
 Should I be asking anything else?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Eliciting Requirements
 Meetings are conducted and attended by both software
engineers and customers
 Rules for preparation and participation are established
 An agenda is suggested
 A "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
 A "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual
forum) is used
 The goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Conduc t FA ST
m eet ings

Make lis t s of
f unc t ions , c lass es

Mak e list s of
c ons t raint s , et c .

f orm al priorit izat ion?


El i c i t re q u i re m e n t s
yes no

Use QFD t o inf orm ally def ine ac t ors


priorit ize priorit ize
requirem ent s requirem ent s

draw use-c as e
writ e s c enario
diagram

Creat e Use-c as es
c om plet e t em plat e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Quality Function Deployment

 A technique of translating customer needs into technical


system requirements:
 Normal requirements: reflect stated customer goals
and objectives
 Expected requirements: implicit to the product or
system; their absence will cause significant customer
dissatisfaction
 Exciting requirements: featured going beyond
customer expectations, causing customer euphoria (;-(;-)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Quality Function Deployment
 Function deployment determines the “value” (as
perceived by the customer) of each function required of
the system

 Information deployment identifies data objects and


events

 Task deployment examines the behavior of the system

 Value analysis determines the relative priority of


requirements
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Elicitation Work Products
 A statement of need and feasibility.
 A bounded statement of scope for the system or product.
 A list of customers, users, and other stakeholders who
participated in requirements elicitation
 A description of the system’s technical environment.
 A list of requirements (preferably organized by function)
and the domain constraints that apply to each.
 A set of usage scenarios that provide insight into the use
of the system or product under different operating
conditions.
 Any prototypes developed to better define requirements
requirements.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Use--Cases
Use
 A collection of user scenarios that describe the thread of usage of a system

 Each scenario is described from the point-


point-of-
of-view of an “actor”
“actor”—
—a person or
device that interacts with the software in some way

 Each scenario answers the following questions:


 Who is the primary actor, the secondary actor (s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Use--Case Diagram
Use
Arms/ disarms
syst em

Accesses syst em sensors


via Int ernet

homeow ner

Responds t o
alarm event

Encount ers an
error condit ion

syst em Reconf igures sensors


administ rat or and relat ed
syst em f eat ures

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Building the Analysis Model
 Intent: to provide a description of the required
informational, functional and behavioral domains
of the computer-
computer-based system

 The model changes dynamically as the system


engineers learn more about the system

 Is a series of time-
time-ordered snapshots of
requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
Building the Analysis Model
 Elements of the analysis model
 Scenario--based elements
Scenario
 Functional—processing narratives for software functions
Functional—
 Use--case—
Use case—descriptions of the interaction between an
“actor” and the system
 Class--based elements
Class
 Implied by scenarios
 Behavioral elements
 State diagram
 Flow--oriented elements
Flow
 Data flow diagram

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure()

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
State Diagram
Reading
Init ializat ion
commands not jammed

t urn copier subsyst ems


syst em st at us=“not ready” syst em st at us=“Ready” paper f ull
“on“ ready
display msg = “please wait ” display msg = “ent er cmd”
display st at us = blinking display st at us = st eady

ent ry/ swit ch machine on ent ry/ subsyst ems ready


do: run diagnost ics do: poll user input panel
do: init iat e all subsyst ems do: read user input
do: int erpret user input

t urn copier “of f ”

st art copies

Making copies load paper


copies complet e
syst em st at us=“Copying”
syst em st at us=“load paper”
display msg= “copy count =”
display msg= “load paper”
display message=#copies paper t ray empt y display st at us= blinking
display st at us= st eady

ent ry/ st art copies paper jammed ent ry/ paper empt y
do: manage copying do: lower paper t ray
do: monit or paper t ray do: monit or f ill swit ch
do: monit or paper f low problem diagnosis do: r aise paper t ray

syst em st at us=“Jammed”
display msg = “paper jam”
display message=locat ion
display st at us= blinking not jammed

ent ry/ paper jammed


do: det ermine locat ion
do: provide correct ivemsg.
do: int errupt making copies

Figure 7.6 Preliminary UML st at e diagram for a phot ocopier


These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Analysis Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address the
problem.
Forces and context: A description of external issues (forces) that can affect how the
pattern is used and also the external issues that will be resolved when the pattern is
applied.
Solution: A description of how the pattern is applied to solve the problem with an
emphasis on structural and behavioral issues.
Consequences:: Addresses what happens when the pattern is applied and what trade-
Consequences trade-
offs exist during its application.
Design:: Discusses how the analysis pattern can be achieved through the use of
Design
known design patterns.
Known uses:
uses: Examples of uses within actual systems.
Related patterns:
patterns: On e or more analysis patterns that are related to the named pattern
because (1) it is commonly used with the named pattern; (2) it is structurally similar to
the named pattern; (3) it is a variation of the named pattern.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
Negotiating Requirements

 Identify the key stakeholders


 These are the people who will be involved in the negotiation

 Determine each of the stakeholders “win conditions”


 Win conditions are not always obvious

 Negotiate
 Work toward a set of requirements that lead to “win-
“win-win”

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
Validating Requirements
Checking for Consistency, Omissions, Ambiguity

 Is each requirement consistent with the overall objective for the


system/product?
 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-
add-on
feature that may not be essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
 Do any requirements conflict with other requirements?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Validating Requirements
 Is each requirement achievable in the technical environment that will house
the system or product?

 Is each requirement testable, once implemented?

 Does the requirements model properly reflect the information, function and
behavior of the system to be built.

 Has the requirements model been “partitioned” in a way that exposes


progressively more detailed information about the system.

 Have requirements patterns been used to simplify the requirements model.


Have all patterns been properly validated? Are all patterns consistent with
customer requirements?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 8
Analysis Modeling
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Requirements Analysis
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet
 Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier
requirement engineering tasks
 build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class
behavior, and the flow of data as it is transformed.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
A Bridge
system
description

analysis
model

design
model

ANALYSIS MODEL: a representation of requirements in


terms of text and diagrams depicting requirements for data,
function and system behaviour in a way easy to understand
and review for correctness, completeness and consistency
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Rules of Thumb
 The model should focus on requirements that are visible within the
problem or business domain. The level of abstraction should be
relatively high (focus on the “WHAT”, not “HOW”).
 Each element of the analysis model should add to an overall
understanding of software requirements and provide insight into the
information domain, function and behavior of the system.
 Delay consideration of infrastructure and other non-
non-functional
models until design.
 Minimize coupling throughout the system.
 Be certain that the analysis model provides value to all
stakeholders.
 Keep the model as simple as it can be.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Domain Analysis
Software domain analysis is the identification,
analysis, and specification of common requirements
from a specific application domain, typically for reuse on
multiple projects within that application domain . . .
[Object
Object--oriented domain analysis is] the identification,
analysis, and specification of common, reusable
capabilities within a specific application domain, in
terms of common objects, classes, subassemblies, and
frameworks . . .
Donald Firesmith

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Domain Analysis
 Define the domain to be investigated.

 Collect a representative sample of applications


in the domain.

 Analyze each application in the sample.

 Develop an analysis model for the objects.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Analysis Modeling Approaches
 STRUCTURED ANALYSIS considers data and
processes transforming the data as separate entities.
Data objects are modeled defining their attributes and
relationships. Processes depict transformation of data
objects as they flow through the system.

 OBJECT-ORIENTED ANALYSIS focuses on the


OBJECT-
definition of classes and the way they collaborate with
one another to satisfy customer requirements. (UML and
Unified Process are predominantly object-
object-oriented)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Data Modeling
 Examines data objects independently of
processing

 Focuses attention on the data domain

 Creates a model at the customer’s level of


abstraction

 Indicates how data objects relate to one


another
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
What is a Data Object?
Object —something that is described by a set
of attributes (data items) and that will be
manipulated within the software (system)
each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #)
each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are
themselves data items

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Typical Objects
external entities (printer, user, sensor)
things (e.g, reports, displays, signals)
occurrences or events (e.g., interrupt, alarm)
roles (e.g., manager, engineer, salesperson)
organizational units (e.g., division, team)
places (e.g., manufacturing floor)
structures (e.g., employee record)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
What is a Relationship?
relationship —indicates “connectedness”;
a "fact" that must be "remembered"
by the system and cannot or is not computed
or derived mechanically

 several instances of a relationship can exist


 objects can be related in many different ways

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
E-R Diagrams
One common form:
(0, m)
object1 relationship object 2
(1, 1)

attribute
Another common form:

object1 relationship
object 2
(0, m) (1, 1)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Building an ERD

 Level 1—
1—model all data objects (entities) and their
“connections” to one another
 Level 2—
2—model all entities and relationships
 Level 3—
3—model all entities, relationships, and the
attributes that provide further depth

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
The ERD: An Example
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard generates (1,n) work
task table order
(1,1) (1,1) (1,1)
selected work (1,w) consists
from (1,w) tasks of

(1,i)
materials lists

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Object--Oriented Concepts
Object
 Must be understood to apply class -
based elements of the analysis model

 Key concepts:
 Classes and objects
 Attributes and operations
 Encapsulation and instantiation
 Inheritance

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Classes
• object-oriented thinking begins with the
object-
definition of a class, often defined as:
– template
– generalized description
– “blueprint” ... describing a collection of
similar items
• a metaclass (also called a superclass
superclass))
establishes a hierarchy of classes
• once a class of items is defined, a
specific instance of the class can be
identified

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
Building a Class
class name

attributes:

operations

attributes:
operations:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
What is a Class?
occurrences roles
things organizational units
places
external entities
structures

class name

attributes:

operations:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
manipulate the data method method
#2
#1
data

method
method #3
#6

method method
#5 #4

Achieves “information hiding”

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Class Hierarchy
PieceOfFurniture (superclass)

Table Chair Desk ”Chable"

subclasses of the

instances of Chair
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
Methods
(a.k.a. Operations, Services)
An executable procedure that is
encapsulated in a class and is designed
to operate on one or more data attributes
that are defined as part of the class.
A method is invoked
via message passing.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
Scenario--Based Modeling
Scenario
“[Use-cases] are simply an aid to defining what exists
“[Use-
outside the system (actors) and what should be
performed by the system (use-
(use-cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Use--Case
Use

 a scenario that describes a “thread of usage”


for a system

 actors represent roles people or devices play


as the system functions

 users can play a number of different roles in a


given scenario

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
Developing a Use-
Use-Case
 What are the main tasks or functions that are performed
by the actor?

 What system information will the the actor acquire,


produce or change?

 Will the actor have to inform the system about changes


in the external environment?

 What information does the actor desire from the system?

 Does the actor wish to be informed about unexpected


changes?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
Use--Case Diagram
Use
Saf eHome

Access camera
surveillance via t he cameras
Int ernet

Conf igure Saf eHome


syst em paramet ers

homeowner

Set alarm

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
Activity Diagram
Supplements the use-
use-case ent er password
and user ID
by providing a diagrammatic
representation of procedural
flow valid passwor ds/ ID invalid passwor ds/ ID

select major f unct ion prompt f or reent ry


ot her f unct ions
m ay also be
select ed
input t r ies r em ain
selec t surv eillance
no input
t r ies r em ain

t hum bnail views select a specif ic cam er a

selec t specif ic
select c amera icon
camera - t humbnails

v iew c amera out put


in labelled window

prompt f or
anot her v iew

exit t his f unct ion


see anot her cam er a

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
Swimlane Diagrams
Allow the modeler to represent the flow of activities described by the use-
use-case and at the
same time indicate which actor (if there are multiple actors involved in a specific use-
use-case)
or analysis class has responsibility for the action described by an activity rectangle
home owne r c a m e ra i n t e rf a c e

ent er password
and user ID

valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
select m ajor f unct ion

o t h er f u n ct io n s prom pt f or reent ry
m ay also b e
select ed

in p u t t r ies
select surveillance r em ain

n o in p u t
t r ies r em ain

t h u m b n ail views select a sp ecif ic cam er a

select specif ic
select cam era ic on
cam era - t hum bnails

generat e video
out put

view cam era out put prom pt f or


in labelled window anot her view

exit t h is
f u n ct io n

see
an o t h er
cam er a

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28
Flow--Oriented Modeling
Flow
Represents how data objects are transformed at they
move through the system
A data flow diagram (DFD) is the diagrammatic form that
is used
Considered by many to be an ‘old school’ approach, flow-
flow-
oriented modeling continues to provide a view of the
system that is unique—
unique—it should be used to supplement
other analysis model elements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
The Flow Model
Every computer-
computer-based system is an
information transform ....

computer
input based output
system

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30
Flow Modeling Notation

external entity

process

data flow

data store

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31
External Entity

A producer or consumer of data

Examples: a person, a device, a sensor


Another example: computer-
computer-based
system
Data must always originate somewhere
and must always be sent to something

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
Process
A data transformer (changes input
to output)

Examples: compute taxes, determine area,


format report, display graph
Data must always be processed in some
way to achieve system function

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33
Data Flow

Data flows through a system, beginning


as input and be transformed into output.

base
compute
area
triangle
height area

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34
Data Stores
Data is often stored for later use.

sensor #
sensor #, type,
look-up
look- location, age
sensor
report required data
type,
location, age
sensor number

sensor data

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35
Data Flow Diagramming:
Guidelines
 All icons must be labeled with meaningful
names
 The DFD evolves through a number of
levels of detail
 Always begin with a context level diagram
(also called level 0)
 Always show external entities at level 0
 Always label data flow arrows
 Do not represent procedural logic

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36
Constructing a DFD — I

 Review the data model to isolate data objects


and use a grammatical parse to determine
“operations”

 Determine external entities (producers and


consumers of data)

 Create a level 0 DFD

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37
Level 0 DFD Example

processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38
Constructing a DFD — II

 Write a narrative describing the transform

 Parse to determine next level transforms

 “Balance” the flow to maintain data flow continuity

 Develop a level 1 DFD

 Use a 1:5 (approx.) expansion ratio

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39
The Data Flow Hierarchy

a b
x P y level 0

a c p2
p1
f

d p4 5 b
p3 e g
level 1

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 40
Flow Modeling Notes
 Each bubble is refined until it does just one thing

 The expansion ratio decreases as the number of


levels increase

 Most systems require between 3 and 7 levels for


an adequate flow model

 A single data flow item (arrow) may be expanded


as levels increase (data dictionary provides
information)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 41
Process Specification (PSPEC)
bubble

PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 42
DFDs: A Look Ahead

analysis model
Maps into
design model

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 43
Control Flow Diagrams
 Represents “events
“events”” and the processes that manage
events
 An “event” is a Boolean condition that can be
ascertained by:
 listing all sensors that are "read" by the software.
 listing all interrupt conditions.
 listing all "switches" that are actuated by an operator.
 listing all data conditions.
 recalling the noun/verb parse that was applied to the processing
narrative, review all "control items" as possible CSPEC
inputs/outputs.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 44
The Control Model
the control flow diagram is "superimposed" on the DFD
and shows events that control the processes noted in
the DFD
control flows—
flows—events and control items—
items—are noted by
dashed arrows
a vertical bar implies an input to or output from a control
spec (CSPEC) — a separate specification that
describes how control is handled
a dashed arrow entering a vertical bar is an input to the
CSPEC

a dashed arrow leaving a process implies a data


condition

a dashed arrow entering a process implies a control


input read directly by the process
control flows do not physically activate/deactivate the
processes—
processes —this is done via the CSPEC
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 45
Control Flow Diagram
copies done
beeper on/off full
read
operator
input manage
problem
copying light
start

empty
reload create
process user
displays

perform
problem
diagnosis

display panel enabled

jammed

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 46
Control Specification (CSPEC)
The CSPEC can be:
state diagram
(sequential spec)

state transition table


combinatorial spec
decision tables

activation tables

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 47
Guidelines for Building a CSPEC
list all sensors that are "read" by the software
list all interrupt conditions
list all "switches" that are actuated by the operator
list all data conditions

recalling the noun-


noun-verb parse that was applied to the
software statement of scope, review all "control items"
as possible CSPEC inputs/outputs
describe the behavior of a system by identifying its
states; identify how each state is reach and defines
the transitions between states

focus on possible omissions ... a very common error in


specifying control, e.g., ask: "Is there any other way I
can get to this state or exit from it?"

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 48
Class--Based Modeling
Class
 Identify analysis classes by examining the
problem statement

 Use a “grammatical parse” to isolate potential


classes

 Identify the attributes of each class

 Identify operations that manipulate the attributes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 49
Analysis Classes
 External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-
computer-based system.

 Things (e.g, reports, displays, letters, signals) that are part of the information
domain for the problem.

 Occurrences or events (e.g., a property transfer or the completion of a series of


robot movements) that occur within the context of system operation.

 Roles (e.g., manager, engineer, salesperson) played by people who interact with the
system.

 Organizational units (e.g., division, group, team) that are relevant to an application.

 Places (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.

 Structures (e.g., sensors, four-


four-wheeled vehicles, or computers) that define a class
of objects or related classes of objects.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 50
Selecting Classes—
Classes—Criteria

Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 51
Class Diagram
Class name
System
systemID
verificationPhoneNumber
systemStatus attributes
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries

program()
display()
reset()
query() operations
modify()
call()

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 52
Class Diagram
FloorPlan
type
name
outsideDimensions

determineType ( )
positionFloorplan
scale( )
change color( )

is placed wit hin

is part of

Cam era Wall

t ype t ype
ID wallDim ensions
locat ion
f ieldV iew
panA ngle
Zoom Set t ing
determineType ( )
det erm ineType ()
computeDimensions ( )
t ranslat eLocat ion ()
displayID()
displayV iew()
displayZoom ()
is used t o build is used t o build

is used t o build

WallSegm ent Window Door

t ype t ype t ype


st art Coordinat es st art Coordinat es st art Coordinat es
st opCoordinat es st opCoordinat es st opCoordinat es
next WallSem ent next Window next Door

determineType ( ) determineType ( ) determineType ( )


draw( ) draw( ) draw( )
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 53
CRC Modeling
(Class_Responsibility--Collaborator)
(Class_Responsibility

 Analysis classes have “responsibilities”


 Responsibilities are the attributes and operations encapsulated
by the class

 Analysis classes collaborate with one another


 Collaborators are those classes that are required to provide a
class with the information needed to complete a responsibility.
 In general, a collaboration implies either a request for
information or a request for some action.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 54
CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 55
Class Types
 classes, also called model or business classes, are
Entity classes,
extracted directly from the statement of the problem (e.g.,
FloorPlan and Sensor).

 Boundary classes are used to create the interface (e.g.,


interactive screen or printed reports) that the user sees and
interacts with as the software is used.

 Controller classes manage a “unit of work” [UML03] from start to


finish. That is, controller classes can be designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from
entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or between the
user and the application.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 56
Responsibilities
(Attributes and methods relevant to the class)

 System intelligence should be distributed across classes


to best address the needs of the problem
 Each responsibility should be stated as generally as
possible
 Information and the behavior related to it should reside
within the same class
 Information about one thing should be localized with a
single class, not distributed across multiple classes.
 Responsibilities should be shared among related
classes, when appropriate.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 57
Collaborations
 Classes fulfill their responsibilities in one of two ways:
 A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class
can fulfill each responsibility itself
 Three different generic relationships between classes [WIR90]:
 the is part-of relationship
is--part-
 the has knowledge--of relationship
has--knowledge
 the depends
depends--upon relationship

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 58
Composite Aggregate Class
Player

PlayerHead PlayerBody PlayerArms PlayerLegs

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 59
Reviewing the CRC Model
 All participants in the review (of the CRC model) are given a subset of the
CRC model index cards.
 Cards that collaborate should be separated (i.e., no reviewer should have two
cards that collaborate).
 All use-
use-case scenarios (and corresponding use-
use-case diagrams) should be
organized into categories.
categories.
 The review leader reads the use-
use-case deliberately.
deliberately.
 As the review leader comes to a named object, she passes a token to the person
holding the corresponding class index card.
 When the token is passed, the holder of the class card is asked to describe
the responsibilities noted on the card.
card.
 The group determines whether one (or more) of the responsibilities satisfies the
use--case requirement.
use
 If the responsibilities and collaborations noted on the index cards cannot
accommodate the use- use-case, modifications are made to the cards
cards..
 This may include the definition of new classes (and corresponding CRC index
cards) or the specification of new or revised responsibilities or collaborations on
existing cards.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 60
Associations and Dependencies

 Two analysis classes are often related to one another in


some fashion
 In UML these relationships are called associations
 Associations can be refined by indicating multiplicity (the term
cardinality is used in data modeling
 In many instances, a client-
client-server relationship exists
between two analysis classes.
 In such cases, a client-
client-class depends on the server
server--class in
some way and a dependency relationship is established

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 61
Multiplicity
Wall

1 1 1

is used to build is used to build

1..* 0..* is used to build 0..*

WallSegm ent Window Door

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 62
Dependencies

DisplayWindow Camera

<<access>>

{password}

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 63
Analysis Packages
 Various elements of the analysis model (e.g., use-
use-cases,
analysis classes) are categorized in a manner that
packages them as a grouping
 The plus sign preceding the analysis class name in each
package indicates that the classes have public visibility
and are therefore accessible from other packages.
 Other symbols can precede an element within a
package. A minus sign indicates that an element is
hidden from all other packages and a # symbol indicates
that an element is accessible only to packages contained
within a given package.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 64
Analysis Packages
package name

Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOf TheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction

Charact ers

+Player
+Protagonist
+Antagonist
+SupportingRole

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 65
Behavioral Modeling
 The behavioral model indicates how software will
respond to external events or stimuli. To create the
model, the analyst must perform the following steps:
 Evaluate all use-
use-cases to fully understand the sequence of
interaction within the system.
 Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
 Create a sequence for each use-
use-case.
 Build a state diagram for the system.
 Review the behavioral model to verify accuracy and
consistency.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 66
State Representations
 In the context of behavioral modeling, two different
characterizations of states must be considered:
 the state of each class as the system performs its function and
 the state of the system as observed from the outside as the
system performs its function
 The state of a class takes on both passive and active
characteristics [CHA93].
 A passive state is simply the current status of all of an object’s
attributes.
 The active state of an object indicates the current status of the
object as it undergoes a continuing transformation or processing.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 67
State Diagram for the ControlPanel Class
t imer < lockedTime

t imer > lockedTime locked

password = incorrect
& numberOfTries < maxTries

reading comparing numberOfTries > maxTries


key hit
password
ent ered do: validat ePassw ord
password = correct

select ing

act iv at ion successful

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 68
The States of a System
 state—a set of observables that
state—
characterizes the behavior of a system at
a given time
 state transition—
transition—the movement from one
state to another
 event—
event —an occurrence that causes the
system to exhibit some predictable form
of behavior
 action—
action —process that occurs as a
consequence of making a transition

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 69
Behavioral Modeling

 Make a list of the different states of a


system (How does the system behave?)
 Indicate how the system makes a transition
from one state to another (How does the
system change state?)
 indicate event
 indicate action
 Draw a state diagram or a sequence
diagram

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 70
Sequence Diagram
ho meo wn er co n t ro l p anel syst em sen
senso
so rs
rs

read in g
syst em A
read y
p assw o rd en t ered

req uest loo ku p


co mp arin g

resu lt

pas sword = c orrec t


num berOf Tries > m axTries requ est act ivat io n
locked

t imer > lo ckedTime


A

select in g

act ivat io n successfu l act ivat io n su ccessfu l

Figure 8 .2 7 Sequence diagram (part ial) f or Saf eHome securit y f unct ion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 71
Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 72
Specification Guidelines
use a layered format that provides increasing detail
as the "layers" deepen

use consistent graphical notation and apply textual


terms consistently (stay away from aliases)

be sure to define all acronyms

be sure to include a table of contents; ideally,


include an index and/or a glossary

write in a simple, unambiguous style (see "editing


suggestions" on the following pages)

always put yourself in the reader's position, "Would


I be able to understand this if I wasn't intimately
familiar with the system?"

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 73
Specification Guidelines
Be on the lookout for persuasive connectors, ask why?
keys: certainly, therefore, clearly, obviously, it follows that ...
Watch out for vague terms
keys: some, sometimes, often, usually,ordinarily, most, mostly ...
When lists are given, but not completed, be sure all items are understood
keys: etc., and so forth, and so on, such as
Be sure stated ranges don't contain unstated assumptions
e.g., Valid codes range from 10 to 100. Integer? Real? Hex?
Beware of vague verbs such as handled, rejected, processed, ...
Beware "passive voice" statements
e.g., The parameters are initialized. By what?
Beware "dangling" pronouns
e.g., The I/O module communicated with the data validation module and
its contol flag is set. Whose control flag?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 74
Specification Guidelines
When a term is explicitly defined in one place, try
substituting the definition forother occurrences of the term
When a structure is described in words, draw a picture

When a structure is described with a picture, try to redraw


the picture to emphasize different elements of the structure

When symbolic equations are used, try expressing their


meaning in words

When a calculation is specified, work at least two


examples

Look for statements that imply certainty, then ask for proof
keys; always, every, all, none, never

Search behind certainty statements—be sure restrictions


or limitations are realistic

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 75
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 10
Architectural Design
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Why Architecture?
The architecture is not the operational software.
Rather, it is a representation that enables a
software engineer to:
(1) analyze the effectiveness of the design in
meeting its stated requirements,
(2) consider architectural alternatives at a stage
when making design changes is still relatively
easy, and
(3) reduce the risks associated with the
construction of the software.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
Why is Architecture
Important?
 Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in the
development of a computer-
computer-based system.

 The architecture highlights early design decisions that will have a


profound impact on all software engineering work that follows and,
as important, on the ultimate success of the system as an
operational entity.

 Architecture “constitutes a relatively small, intellectually graspable


model of how the system is structured and how its components work
together” [BAS03].

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Data Design
 At the architectural level …
 Design of one or more databases to support the
application architecture

 Design of methods for ‘mining


‘mining’’ the content of multiple
databases
 navigate through existing databases in an attempt to
extract appropriate business-
business-level information
 Design of a data warehouse—
warehouse—a large, independent
database that has access to the data that are stored in
databases that serve the set of applications required by
a business

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Data Design

 At the component level …


 refine data objects and develop a set of data
abstractions
 implement data object attributes as one or more
data structures
 review data structures to ensure that appropriate
relationships have been established
 simplify data structures as required

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Data Design—
Design—Component Level
1. The systematic analysis principles applied to function and
behavior should also be applied to data.
2. All data structures and the operations to be performed on each
should be identified.
3. A data dictionary should be established and used to define both
data and program design.
4. Low level data design decisions should be deferred until late in
the design process.
5. The representation of data structure should be known only to
those modules that must make direct use of the data contained
within the structure.
6. A library of useful data structures and the operations that may be
applied to them should be developed.
7. A software design and programming language should support
the specification and realization of abstract data types.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Architectural Styles
Each style describes a system category that encompasses: (1) a set of
components (e.g., a database, computational modules) that perform a
function required by a system, (2) a set of connectors that enable
“communication, coordination and cooperation” among components,
(3) constraints that define how components can be integrated to form
the system, and (4) semantic models that enable a designer to
understand the overall properties of a system by analyzing the known
properties of its constituent parts.
 Data-centered architectures
Data-
 Data flow architectures
 Call and return architectures
 Object--oriented architectures
Object
 Layered architectures

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Data--Centered Architecture
Data

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Data Flow Architecture

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Call and Return Architecture

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Layered Architecture

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Architectural Patterns
 Concurrency — applications must handle multiple tasks in a
manner that enables parallelism
 operating system process management pattern
 task scheduler pattern
 Persistence — Data persists if it survives past the execution of
the process that created it. Two patterns are common:
 a database management system pattern that applies the storage and
retrieval capability of a DBMS to the application architecture
 an application level persistence pattern that builds persistence
features into the application architecture
 Distribution — the manner in which systems or components
within systems communicate with one another in a distributed
environment
 A broker acts as a ‘middle-
‘middle-man’ between the client component and a
server component.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Architectural Design
 The software must be placed into context
 the design should define the external entities (other systems,
devices, people) that the software interacts with and the nature
of the interaction
 A set of architectural archetypes should be identified
 An archetype is an abstraction (similar to a class) that
represents one element of system behavior
 The designer specifies the structure of the system by
defining and refining software components that
implement each archetype

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Architectural Context
Safehome Internet-based
Product system

control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses

uses

sensors sensors

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Archetypes
Cont roller

communicat es wit h

Node

Det ect or Indicat or

Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
These courseware materials are to(adapt
be used
ed f in
romconjunction
[ BOS00] ) with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Component Structure
SafeHome
Execut ive

Funct ion
select ion

Ext ernal
Communicat ion
Management

Securit y Surveillance Home


management

GUI Int ernet


Int erface

Cont rol det ect or alarm


panel management processing
processing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Refined Component Structure
SafeHome
Executive

Ext ernal
Communicat ion
Management

Security

GUI Internet
Interface

Co n t ro l d e t e ct o r alarm
p an e l m an ag e m e n t p ro ce ssin g
p ro ce ssin g

Ke y p ad
p ro ce ssin g phone
sch e d u le r
co m m u n icat io n

CP d isp lay
fu n ct io n s
alarm

sennso
se so r
se
se so rr
nso
se
se nnso
sorrr
se nnso r
se n so r
se n so r

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment
description.
3. Describe the architectural styles/patterns that have been
chosen to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute
in isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3)
using the sensitivity analysis conducted in step 5.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."

architectural design

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
Deriving Program Architecture

Program
Architecture

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Partitioning the Architecture

 “horizontal” and “vertical” partitioning are


required

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
Horizontal Partitioning
 define separate branches of the module
hierarchy for each major function
 use control modules to coordinate
communication between functions
function 1 function 3

function 2
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
Vertical Partitioning:
Factoring

 design so that decision making and work are


stratified
 decision making modules should reside at the top
of the architecture decision--makers
decision

workers

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Why Partitioned Architecture?

 results in software that is easier to test


 leads to software that is easier to maintain
 results in propagation of fewer side effects
 results in software that is easier to extend

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
Structured Design

 objective: to derive a program


architecture that is partitioned
 approach:
 the DFD is mapped into a program
architecture
 the PSPEC and STD are used to indicate the
content of each module
 notation: structure chart

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
Flow Characteristics

Transform flow

Transaction
flow

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
General Mapping Approach
Isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center

Working from the boundary outward, map


DFD transforms into corresponding modules

Add control modules as required

Refine the resultant program structure


using effective modularity concepts

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
Transform Mapping

b g h
a e f
d
c i
j
data flow model

x1 "Transform" mapping

x2 x3 x4

b c d e f g i

a h j

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28
Factoring
direction of increasing
decision making typical "decision
making" modules

typical "worker" modules

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
First Level Factoring

main
program
controller

input processing output


controller controller controller

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30
Second Level Mapping
main
D
C
control

B A
A
B
C

mapping from the D


flow boundary outward

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31
Transaction Flow
incoming flow

action path
T

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
Transaction Example
fixture setting fixture
servos

commands
operator process
report display
operator
commands screen

robot control

robot
control
software
assembly
record
in reality, other
commands
would also be shown

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33
Refining the Analysis Model
1. Write an English language processing narrative
for the level 01 flow model

2. Apply noun/verb parse to isolate processes, data


items, store and entities

3. Develop level 02 and 03 flow models

4. Create corresponding data dictionary entries

5. Refine flow models as appropriate

... now, we're ready to begin design!

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34
Deriving Level 1
Processing narrative for " process operator commands"
Process operator command software reads operator commands from
the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
noun-verb
noun- report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
parse the robot control system.

Process operator command software reads operator commands from


the cell operator
operator.. An error message is displayed for invalid commands.
commands.
The command type is determined for valid commands and appropriate
action is taken
taken.. When fixture commands are encountered
encountered,, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected
selected,, the assembly record file is read and a
report is generated and displayed on the operator display screen.
screen.
When robot control switches are selected
selected,, control values are sent to
the robot control system.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35
Transaction Mapping Principles
isolate the incoming flow path

define each of the action paths by looking for


the "spokes of the wheel"

assess the flow on each action path

define the dispatch and control structure

map each action path flow individually

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36
Transaction Mapping
e f
a d
b
t i
g
h k
l j
data flow model
m
x1 n
Mapping
b t

a x2 x3 x4

d e f g h x3.1 l m n

i j
k
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37
Map the Flow Model
process
operator
commands

command determine
input type
controller

read validate produce fixture report send


command command error status generation control
message controller controller value

each of the action paths must be expanded further

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38
Refining the Structure Chart
process
operator
commands

command determine
input type
controller

read validate produce fixture report send


command command error status generation control
message controller controller value

read read calculate


determine format format
fixture setting setting record output report
status values

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 13
Software Testing Strategies
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Software Testing

Testing is the process of exercising a


program with the specific intent of finding
errors prior to delivery to the end user.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
What Testing Shows
errors
requirements conformance

performance

an indication
of quality

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Who Tests the Software?

developer independent tester


Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Testing Strategy
unit test integration
test

system validation
test test

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Testing Strategy
 We begin by ‘testing
‘testing--in-
in-the
the--small’ and move toward
‘testing
testing--in
in--the
the--large’

 For conventional software:


 The module (component) is our initial focus
 Integration of modules follows

 For OO software:
 our focus when “testing in the small” changes from an
individual module (the conventional view) to an OO class
that encompasses attributes and operations and implies
communication and collaboration
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Strategic Issues
 State testing objectives explicitly.
 Understand the users of the software and develop a profile for
each user category.
 Develop a testing plan that emphasizes “rapid cycle testing.”
 Build “robust” software that is designed to test itself.
 Use effective formal technical reviews as a filter prior to testing.
 Conduct formal technical reviews to assess the test strategy
and test cases themselves.
 Develop a continuous improvement approach for the testing
process.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
Unit Testing

module
to be
tested

results
software
engineer
test cases

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths

test cases
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Unit Test Environment

driver
interface
local data structures
Module boundary conditions
independent paths
error handling paths
stub stub

test cases
RESULTS
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Integration Testing Strategies
Options:

• the “big bang” approach


• an incremental construction strategy

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Top Down Integration
A
top module is tested with
stubs

B F G

stubs are replaced one at


a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-
re-run
D E

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Bottom--Up Integration
Bottom
A

B F G

drivers are replaced one at a


time, "depth first"
C

worker modules are grouped into


builds and integrated
D E

cluster
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Sandwich Testing
A
Top modules are
tested with stubs

B F G

Worker modules are grouped into


builds and integrated
D E

cluster
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Object--Oriented Testing
Object
 Begins by evaluating the correctness and consistency of
the OOA and OOD models

 Testing strategy changes


 the concept of the ‘unit’ broadens due to encapsulation
 integration focuses on classes and their execution across a
‘thread’ or in the context of a usage scenario
 validation uses conventional black box methods

 Test case design draws on conventional methods, but


also encompasses special features
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Broadening the View of “Testing”

It can be argued that the review of OO analysis and


design models is especially useful because the
same semantic constructs (e.g., classes, attributes,
operations, messages) appear at the analysis,
design, and code level. Therefore, a problem in the
definition of class attributes that is uncovered
during analysis will circumvent side effects that
might occur if the problem were not discovered
until design or code (or even the next iteration of
analysis).

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Testing the CRC Model
1. Revisit the CRC model and the object-
object-relationship model.
2. Inspect the description of each CRC index card to determine if
a delegated responsibility is part of the collaborator’s definition.
3. Invert the connection to ensure that each collaborator that is
asked for service is receiving requests from a reasonable source.
4. Using the inverted connections examined in step 3, determine
whether other classes might be required or whether
responsibilities are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be
combined into a single responsibility.
6. Steps 1 to 5 are applied iteratively to each class and through
each evolution of the OOA model.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
OOT Strategy
 Class testing is the equivalent of unit testing:
 operations within the class are tested
 the state behavior of the class is examined

 Integration applies three different strategies:


 thread-based testing
thread- testing—
—integrates the set of classes
required to respond to one input or event
 use--based testing
use testing——integrates the set of classes required
to respond to one use case
 cluster testing—
testing—integrates the set of classes required to
demonstrate one collaboration

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
Smoke Testing
 A common approach for creating “daily builds” for product
software
 Smoke testing steps:
 Software components that have been translated into code are
integrated into a “build.”
 A build includes all data files, libraries, reusable modules, and
engineered components that are required to implement one or
more product functions.
 A series of tests is designed to expose errors that will keep
the build from properly performing its function.
 The intent should be to uncover “show stopper” errors that have
the highest likelihood of throwing the software project behind
schedule.
 The build is integrated with other builds and the entire product
(in its current form) is smoke tested daily.
 The integration approach may be top down or bottom up.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
High Order Testing
 Validation testing
 Focus is on software requirements
 System testing
 Focus is on system integration
 Alpha/Beta testing
 Focus is on customer usage
 Recovery testing
 forces the software to fail in a variety of ways and verifies that
recovery is properly performed
 Security testing
 verifies that protection mechanisms built into a system will, in fact,
protect it from improper penetration
 Stress testing
 executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume
 Performance Testing
 test the run-
run-time performance of software within the context of an
integrated system

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Debugging:
A Diagnostic Process

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
The Debugging Process
test cases

new test results


regression cases
tests suspected
causes
corrections
Debugging
identified
causes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
Debugging Effort

time required
to diagnose the
time required symptom and
to correct the error determine the
and conduct cause
regression tests

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Symptoms & Causes
Symptom and cause may be
geographically separated

Symptom may disappear when


another problem is fixed

Cause may be due to a


combination of non-
non-errors
Cause may be due to a system
or compiler error

symptom Cause may be due to


assumptions that everyone
cause believes

Symptom may be intermittent

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
Consequences of Bugs

infectious
damage
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function
function--related bugs,
system--related bugs, data bugs, coding bugs,
system
design bugs, documentation bugs, standards
violations, etc.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
Debugging Techniques

Brute force / testing

Backtracking

Induction

Deduction

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
Debugging: Final Thoughts
1. Don't run off half-
half-cocked, think about the
symptom you're seeing.
2. Use tools (e.g., dynamic debugger) to gain
more insight.

3. If at an impasse, get help from someone else.

4. Be absolutely sure to conduct regression tests


when you do "fix" the bug.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 14
Software Testing Techniques
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Testability
 Operability—it operates cleanly
Operability—
 Observability—
Observability —the results of each test case are readily
observed
 Controllability—
Controllability—the degree to which testing can be automated
and optimized
 Decomposability—
Decomposability —testing can be targeted
 Simplicity—
Simplicity—reduce complex architecture and logic to simplify
tests
 Stability—
Stability—few changes are requested during testing
 Understandability—
Understandability —of the design

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
What is a “Good” Test?

 A good test has a high probability of finding


an error
 A good test is not redundant.
 A good test should be “best of breed”
 A good test should be neither too simple nor
too complex

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
Test Case Design

"Bugs lurk in corners


and congregate at
boundaries ..."
Boris Beizer

OBJECTIVE to uncover errors

CRITERIA in a complete manner

CONSTRAINT with a minimum of effort and time

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
Exhaustive Testing

loop < 20 X

14
There are 10 possible paths! If we execute one
test per millisecond, it would take 3,170 years to
test this program!!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Selective Testing

Selected path

loop < 20 X

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Software Testing

white-box black-box
methods methods

Methods

Strategies

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
White--Box Testing
White

... our goal is to ensure that all


statements and conditions have
been executed at least once ...

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Why Cover?
logic errors and incorrect assumptions
are inversely proportional to a path's
execution probability

we oftenbelievethat
believe that a path is not
likely to be executed; in fact, reality is
often counter intuitive

typographical errors are random; it's


likely that untested paths will contain
some

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Basis Path Testing
First, we compute the cyclomatic
complexity:

number of simple decisions + 1

or

number of enclosed areas + 1

In this case, V(G) = 4

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Cyclomatic Complexity
A number of industry studies have indicated
that the higher V(G), the higher the probability
or errors.

modules

V(G)

modules in this range are


more error prone

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Basis Path Testing
Next, we derive the
independent paths:
1

Since V(G) = 4,
2 there are four paths

3 Path 1: 1,2,3,6,7,8
4
5 6 Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
7
Finally, we derive test
cases to exercise these
8
paths.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
Basis Path Testing Notes

you don't need a flow chart,


but the picture will help when
you trace program paths

count each simple logical test,


compound tests count as 2 or
more

basis path testing should be


applied to critical modules

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
Graph Matrices
 A graph matrix is a square matrix whose size
(i.e., number of rows and columns) is equal to
the number of nodes on a flow graph
 Each row and column corresponds to an
identified node, and matrix entries correspond to
connections (an edge) between nodes.
 By adding a link weight to each matrix entry, the
graph matrix can become a powerful tool for
evaluating program control structure during
testing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Control Structure Testing
 Condition testing — a test case design method that
exercises the logical conditions contained in a program
module
 Data flow testing — selects test paths of a program
according to the locations of definitions and uses of
variables in the program

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Loop Testing

Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Loop Testing: Simple Loops

Minimum conditions—
conditions—Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-
(n-1), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
Loop Testing: Nested Loops
Nested Loops
Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
Test the min+1, typical, max-
max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.
Move out one loop and set it up as in step 2, holding all
other loops at typical values. Continue this step until
the outermost loop has been tested.
Concatenated Loops
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is
used to initialize loop 2.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
Black--Box Testing
Black

requirements

output

input events

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
Black--Box Testing
Black
 How is functional validity tested?
 How is system behavior and performance tested?
 What classes of input will make good test cases?
 Is the system particularly sensitive to certain input
values?
 How are the boundaries of a data class isolated?
 What data rates and data volume can the system
tolerate?
 What effect will specific combinations of data have
on system operation?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Graph--Based Methods
Graph
To understand the
object Directed link object
objects that are #1 (link weight) #2

modeled in
Node weight
software and the Undirected link
(value
)
relationships that object
Parallel links

#
connect these 3

objects (a)

new menu select generates document


In this context, we file (generation time < 1.0 sec) window
consider the term
allows editing
“objects” in the broadest of Attributes:
is represented as
possible context. It contains
encompasses data document background color: white
tex text color: default color
objects, traditional t or preferences
components (modules), (b)
and object-
object-oriented
elements of computer
software.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
Equivalence Partitioning

user output FK
queries formats input
mouse
picks data
prompts

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
Sample Equivalence
Classes
Valid data
user supplied commands
responses to system prompts
file names
computational data
physical parameters
bounding values
initiation values
output data formatting
responses to error messages
graphical data (e.g., mouse picks)
Invalid data
data outside bounds of the program
physically impossible data
proper value supplied in wrong place

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Boundary Value Analysis

user output FK
queries formats input
mouse data
picks prompts

output
input domain domain

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
Comparison Testing
 Used only in situations in which the reliability of software
is absolutely critical (e.g., human-
human-rated systems)
 Separate software engineering teams develop independent
versions of an application using the same specification
 Each version can be tested with the same test data to ensure
that all provide identical output
 Then all versions are executed in parallel with real-
real-time
comparison of results to ensure consistency

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
Orthogonal Array Testing
 Used when the number of input parameters is small and
the values that each of the parameters may take are
clearly bounded

Z Z

Y Y
X X
One input item at a time L9 orthogonal array

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
OOT—
OOT—Test Case Design
Berard [BER93] proposes the following approach:
1. Each test case should be uniquely identified and should be explicitly
associated with the class to be tested,
2. The purpose of the test should be stated,
3. A list of testing steps should be developed for each test and should
contain [BER94]:
a. a list of specified states for the object that is to be tested
b. a list of messages and operations that will be exercised as
a consequence of the test
c. a list of exceptions that may occur as the object is tested
d. a list of external conditions (i.e., changes in the environment external
to the software that must exist in order to properly conduct the test)
e. supplementary information that will aid in understanding or
implementing the test.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
Testing Methods
 Fault--based testing
Fault
 The tester looks for plausible faults (i.e., aspects of the implementation of the
system that may result in defects). To determine whether these faults exist, test
cases are designed to exercise the design or code.
 Class Testing and the Class Hierarchy
 Inheritance does not obviate the need for thorough testing of all derived classes.
In fact, it can actually complicate the testing process.
 Scenario--Based Test Design
Scenario
 Scenario-based testing concentrates on what the user does, not what the
Scenario-
product does. This means capturing the tasks (via use-
use-cases) that the user has
to perform, then applying them and their variants as tests.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28
OOT Methods: Random Testing
 Random testing
 identify operations applicable to a class
 define constraints on their use
 identify a miminum test sequence
 an operation sequence that defines the minimum life
history of the class (object)
 generate a variety of random (but valid) test sequences
 exercise other (more complex) class instance life
histories

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
OOT Methods: Partition Testing
 Partition Testing
 reduces the number of test cases required to test a class in
much the same way as equivalence partitioning for
conventional software
 state--based partitioning
state
 categorize and test operations based on their ability to change
the state of a class
 attribute--based partitioning
attribute
 categorize and test operations based on the attributes that they
use
 category--based partitioning
category
 categorize and test operations based on the generic function
each performs

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30
OOT Methods: Inter-
Inter-Class Testing
 Inter--class testing
Inter
 For each client class, use the list of class operators to
generate a series of random test sequences. The operators
will send messages to other server classes.
 For each message that is generated, determine the
collaborator class and the corresponding operator in the
server object.
 For each operator in the server object (that has been invoked
by messages sent from the client object), determine the
messages that it transmits.
 For each of the messages, determine the next level of
operators that are invoked and incorporate these into the test
sequence

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31
OOT Methods: Behavior Testing
The tests to be empty set up
designed should open acct setup Accnt acct

achieve all state deposit


coverage [KIR94]. (initial)

That is, the deposit

operation working
sequences should balance
acct
withdraw
cause the credit
accntInfo
Account class to withdrawal
make transition (final)

through all dead nonworking


allowable states acct close acct

Figure 1 4 .3 St at e diagram f or A ccount class ( adapt ed f rom [ KIR9 4 ] )

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
Testing Patterns
Pattern name: pair testing
Abstract: A process-
process-oriented pattern, pair testing describes a technique that is
analogous to pair programming (Chapter 4) in which two testers work together
to design and execute a series of tests that can be applied to unit, integration
or validation testing activities.
Pattern name: separate test interface
Abstract: There is a need to test every class in an object-
object-oriented system,
including “internal classes” (i.e., classes that do not expose any interface
outside of the component that used them). The separate test interface pattern
describes how to create “a test interface that can be used to describe specific
tests on classes that are visible only internally to a component.” [LAN01]
Pattern name: scenario testing
Abstract: Once unit and integration tests have been conducted, there is a need
to determine whether the software will perform in a manner that satisfies users.
The scenario testing pattern describes a technique for exercising the software
from the user’s point of view. A failure at this level indicates that the software
has failed to meet a user visible requirement. [KAN01]

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 26
Quality Managementcopyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

1
Quality
 The American Heritage Dictionary defines quality as
 “a characteristic or attribute of something.”
 For software, two kinds of quality may be encountered:
 Quality of design encompasses requirements, specifications,
and the design of the system.
 Quality of conformance is an issue focused primarily on
implementation.
 user satisfaction = compliant product + good quality + delivery
within budget and schedule

2
Software Quality

Conformance to explicitly stated functional and


performance requirements, explicitly documented
development standards, and implicit characteristics
that are expected of all professionally developed
software.

3
Cost of Quality
 Prevention costs include
 quality planning, formal technical reviews, test equipment
and Training
 Appraisal costs include
 In-process and inter-
In- inter-process inspection, equipment
calibration and maintenance, and testing

 Failure costs
 Internal failure costs (before delivery) include
 rework
 repair
 failure mode analysis
 External failure costs (after delivery) include
 complaint resolution
 product return and replacement
 help line support
 warranty work
4
Software Quality Assurance

Process Formal
Definition & Technical
Standards Reviews

Analysis
& Test
Reporting Planning
& Review
Measurement

The SQA group serves as the customer’s in-house representative.

5
Role of the SQA Group-
Group-I
 Prepares an SQA plan for a project.
 The plan identifies
 evaluations to be performed
 audits and reviews to be performed
 standards that are applicable to the project
 procedures for error reporting and tracking
 documents to be produced by the SQA group
 amount of feedback provided to the software project team

 Participates in the development of the project’s software process


description.
 The SQA group reviews the process description for compliance with
organizational policy, internal software standards, externally imposed standards
(e.g., ISO-
ISO-9001), and other parts of the software project plan.

6
Role of the SQA Group-
Group-II
 Reviews software engineering activities to verify compliance with the
defined software process.
 identifies, documents, and tracks deviations from the process and verifies that
corrections have been made.

 Audits designated software work products to verify compliance with


those defined as part of the software process.
 reviews selected work products; identifies, documents, and tracks deviations;
verifies that corrections have been made
 periodically reports the results of its work to the project manager.

 Ensures that deviations in software work and work products are


documented and handled according to a documented procedure.

 Records any noncompliance and reports to senior management.


 Noncompliance items are tracked until they are resolved.
7
Why SQA Activities Pay Off?
cost to find
and fix a defect
100 60.00--100.00
60.00
log
scale
10 10.00

3.00
1.50
1.00
1 0.75

Design test field


Req. system use
code test

8
Reviews & Inspections

... there is no particular reason


why your friend and colleague
cannot also be your sternest critic.
Jerry Weinberg

9
What Are Reviews?
 a meeting conducted by technical people for
technical people
 a technical assessment of a work product
created during the software engineering
process
 a software quality assurance mechanism
 a training ground

Reviews serve to uncover errors and defects that can then be removed
at various points during software engineering. 10
The Players
review
leader standards bearer (SQA)

producer

maintenance
oracle

recorder reviewer
user rep

11
Conducting the Review
1. be prepared—
prepared—evaluate
product before the review

2. review the product, not


the producer

3. keep your tone mild, ask


questions instead of
At the end of the making accusations
review, all attendees 4. stick to the review agenda
of the Formal
Technical Reviews 5. raise issues, don't resolve them
must decide whether
to (1) accpet the 6. avoid discussions of style—
style—stick to technical
product without correctness
further modification, 7. schedule reviews as project tasks
(2) reject the product
due to severe errors, 8. record and report all review results
or (3) accept the
product provisionally.
12
Review Summary
 A review summary report answers three questions:
 What are reviewed
 Who reviewed it
 What were the findings and conclusions

13
Review Guidelines
 Review the product, not the producer
 Set an agenda and maintain it
 Limit debate and rebuttal
 Enunciate problem areas, but don’t attempt to solve every
problem noted
 Take written notes
 Limit the number of participants and insist upon advance
preparation

14
Defect Amplification and Removal
 Figure 26.2
 Errors passed through
 Amplified errors 1: x
 Newly generated errors

 Figure 26.3
no reviews are conducted

 Figure 26.4
reviews are conducted (preliminary design, detail design, code)

15
Sample--Driven Reviews (SDRs)
Sample
 SDRs attempt to quantify those work products that are primary targets for
full FTRs.
To accomplish this …
 Inspect a fraction ai of each software work product, Record the number
of faults fi found within ai.
 Develop a gross estimate of the number of faults within work product i
by multiplying fi by 1/ai.
 Sort the work products in descending order according to the gross
estimate of the number of faults in each.
 Focus available review resources on those work products that have the
highest estimated number of faults.

16
Metrics Derived from Reviews
inspection time per page of documentation
inspection time per KLOC or FP
inspection effort per KLOC or FP
errors uncovered per reviewer hour
errors uncovered per preparation hour
errors uncovered per SE task (e.g., design)
number of minor errors (e.g., typos)
number of major errors
(e.g., nonconformance to req.)
number of errors found during preparation

17
Statistical SQA

Product Collect information on all defects


Find the causes of the defects
& Process Move to provide fixes for the process

measurement

... an understanding of how


to improve quality ...

18
An Example
 Figure 26.5
The causes of errors, number of errors be found, percentage

vital causes according to total percentage: IES, MCC, EDR


vital causes according to serious percentage: IES, EDR, EDL, PLT

19
Six
Six--Sigma for Software Engineering
 The term “six sigma” is derived from six standard deviations—
deviations—3.4 instances
(defects) per million occurrences—
occurrences—implying an extremely high quality
standard.
 The Six Sigma methodology defines three core steps:
 Define customer requirements and deliverables and project goals via well-
well-
defined methods of customer communication
 Measure the existing process and its output to determine current quality
performance (collect defect metrics)
 Analyze defect metrics and determine the vital few causes.

 Improve the process by eliminating the root causes of defects.


 Control the process to ensure that future work does not reintroduce the causes
of defects.

20
Software Reliability
 A simple measure of reliability is mean
mean--time
time--between
between--
failure (MTBF), where
MTBF = MTTF + MTTR

Where the acronyms MTTF and MTTR are mean-time-


to-failure and mean-time-to-repair, respectively.

MTBF

Running Repairing failure Running Repairing failure

21
Software Availability
 Software availability is the probability that a program is
operating according to requirements at a given point in
time and is defined as
Availability = [MTTF/(MTTF + MTTR)] x 100%

22
Software Safety
 Software safety is a software quality assurance activity
that focuses on the identification and assessment of
potential hazards that may affect software negatively and
cause an entire system to fail.
 If hazards can be identified early in the software process,
software design features can be specified that will either
eliminate or control potential hazards.

23
ISO 9001:2000 Standard
 ISO 9001:2000 is the quality assurance standard that
applies to software engineering.
 The standard contains 20 requirements that must be
present for an effective quality assurance system.
 The requirements delineated by ISO 9001:2000 address
topics such as
 management responsibility, quality system, contract review,
design control, document and data control, product identification
and traceability, process control, inspection and testing,
corrective and preventive action, control of quality records,
internal quality audits, training, servicing, and statistical
techniques.

24
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 27
Change Management copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only


May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

1
The “First Law”

No matter where you are in the system


life cycle, the system will change, and the
desire to change it will persist throughout
the life cycle.
Bersoff, et al, 1980

2
Software Configuration Management, SCM

 Identify change
 Control change
 Ensure that change is being properly implemented
 Report changes to others who may have an interest

3
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents

software models
Project
Plan
data
Test
code

4
The Software Configuration

programs documents

The pieces data

Also include software tools, such as editor, compiler, browser


and so on. 5
Baselines
 The IEEE (IEEE Std. No. 610.12-
610.12-1990) defines a
baseline as:
 A specification or product that has been formally reviewed and
agreed upon, that thereafter serves as the basis for further
development, and that can be changed only through formal change
control procedures.

 a baseline is a milestone in the development of software


that is marked by the delivery of one or more software
configuration items and the approval of these Software
Configuration Items (SCIs) that is obtained through a
formal technical review

6
Baselines
modified
SCIs
Project database

approved
Software Formal
engineering SCIs technical SCIs
tasks reviews

stored

SCIs

extracted
SCM
SCIs
controls

BASELINES:
System Specification
Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System

Figure 27.1
7
Software Configuration Objects
Data model

Design specification

data design
architectural design
module design
interface design

Component N

interface description
algorithm description
Test specification PDL

test plan
test procedure
test cases

Source code

Figure 27.2
8
SCM Repository
 The SCM repository is the set of mechanisms and data
structures that allow a software team to manage change
in an effective manner
 The repository performs or precipitates the following
functions [FOR89]:
 Data integrity
 Information sharing
 Tool integration
 Data integration
 Methodology enforcement
 Document standardization

9
Repository Content
u se -case s
b u sin e ss ru le s an aly sis m o d e l so u rce co d e
b u sin e ss fu n ct io n s sce n ario -b ase d d iag ram s o b j e ct co d e
o rg an izat io n st ru ct u re flo w -o rie n t e d d iag ram s sy st e m b u ild in st ru ct io n s
in fo rm at io n arch it e ct u re class-b ase d d iag ram s
b e h av io ral d iag ram s Const ruct ion
d e sig n m o d e l Cont ent
arch it e ct u ral d iag ram s
Business in t e rface d iag ram s
Cont ent co m p o n e n t -le v e l d iag ram s
t e ch n ical m e t rics t e st case s
t e st scrip t s
t e st re su lt s
q u alit y m e t rics
Model
Cont ent
V&V
Cont ent

Project
Management
p ro j e ct e st im at e s Cont ent
p ro j e ct sch e d u le
SCM re q u ire m e n t s
Pro je ct Plan
ch an g e re q u e st s Document s SCM/ SQA Plan
ch an g e re p o rt s
Sy st e m Sp e c
SQA re q u ire m e n t s
Re q u ire m e n t s Sp e c
p ro j e ct re p o rt s/ au d it re p o rt s
De sig n Do cu m e n t
p ro j e ct m e t rics
Te st Plan an d Pro ce d u re
Su p p o rt d o cu m e n t s
Use r m an u al

Figure 27.3 10
Repository Features
 Versioning.
 saves all of these versions to enable effective management of product
releases and to permit developers to go back to previous versions
 Dependency tracking and change management.
 The repository manages a wide variety of relationships among the data
elements stored in it.
 Requirements tracing.
 Provides the ability to track all the design and construction components
and deliverables that result from a specific requirement specification
 Configuration management.
 Keeps track of a series of configurations representing specific project
milestones or production releases. Version management provides the
needed versions, and link management keeps track of
interdependencies.
 Audit trails.
 establishes additional information about when, why, and by whom
11
changes are made.
SCM Elements
 Component elements—
elements—a set of tools coupled within a file management
system (e.g., a database) that enables access to and management of each
software configuration item.
 Process elements—
elements—a collection of procedures and tasks that define an
effective approach to change management (and related activities) for all
constituencies involved in the management, engineering and use of
computer software.
 Construction elements—
elements—a set of tools that automate the construction of
software by ensuring that the proper set of validated components (i.e., the
correct version) have been assembled.
 Human elements—
elements—to implement effective SCM, the software team uses a
set of tools and process features (encompassing other CM elements)

12
The SCM Process
Addresses the following questions …
 How does a software team identify the discrete elements of a software
configuration?
 How does an organization manage the many existing versions of a program
(and its documentation) in a manner that will enable change to be
accommodated efficiently?
 How does an organization control changes before and after software is
released to a customer?
 Who has responsibility for approving and ranking changes?
 How can we ensure that changes have been made properly?
 What mechanism is used to appraise others of changes that are made?

13
The SCM Process
Software
Vm.n

reporting

configuration auditing

version control

change control

identification

SCIs

14
Version Control
 Version control combines procedures and tools to manage different
versions of configuration objects that are created during the software
process
 A version control system implements or is directly integrated with four major
capabilities:
 a project database (repository) that stores all relevant configuration objects
 a version management capability that stores all versions of a configuration
object (or enables any version to be constructed using differences from past
versions);
 a make facility that enables the software engineer to collect all relevant
configuration objects and construct a specific version of the software.
 an issues tracking (also called bug tracking)
tracking) capability that enables the team to
record and track the status of all outstanding issues associated with each
configuration object.

15
Change Control

STOP

16
Change Control Process—
Process—I
need for change is recognized

change request from user

developer evaluates

change report is generated

change control authority decides

request is queued for action


change request is denied
user is informed
change control process—
process—II

17
Change Control Process-
Process-II
assign people to SCIs

check--out SCIs
check

make the change

review/audit the change

establish a “baseline” for testing

change control process—


process—III

18
Change Control Process-
Process-III
perform SQA and testing activities

check--in the changed SCIs


check

promote SCI for inclusion in next release

rebuild appropriate version

review/audit the change

include all changes in release

19
Auditing
Change
Requests SQA
Plan
SCIs

SCM Audit

20
Status Accounting

Change Change
Requests Reports ECOs
SCIs

Status Accounting

Reporting
Engineering Change Order, ECO, for 21
each approved change
SCM for Web Engineering-
Engineering-I
 Content.
 A typical WebApp contains a vast array of content—text,
graphics, applets, scripts, audio/video files, forms, active page
elements, tables, streaming data, and many others.
 The challenge is to organize this set of content into a rational set
of configuration objects (Section 27.1.4) and then establish
appropriate configuration control mechanisms for these objects.
 People.
 Because a significant percentage of WebApp development
continues to be conducted in an ad hoc manner, any person
involved in the WebApp can (and often does) create content.

22
SCM for Web Engineering-
Engineering-II
 Scalability.
 As size and complexity grow, small changes can have far-
far-reaching and
unintended affects that can be problematic. Therefore, the rigor of
configuration control mechanisms should be directly proportional to
application scale.
 Politics.
 Who ‘owns’ a WebApp?
 Who assumes responsibility for the accuracy of the information on the
Web site?
 Who assures that quality control processes have been followed before
information is published to the site?
 Who is responsible for making changes?
 Who assumes the cost of change?

23
Content Management-
Management-I
 The collection subsystem encompasses all actions required to create and/or
acquire content, and the technical functions that are necessary to
 convert content into a form that can be represented by a mark-
mark-up language (e.g.,
HTML, XML
 organize content into packets that can be displayed effectively on the client-
client-side.
 The management subsystem implements a repository that encompasses the
following elements:
 Content database—
database—the information structure that has been established to store all
content objects
 Database capabilities—
capabilities—functions that enable the CMS to search for specific content
objects (or categories of objects), store and retrieve objects, and manage the file
structure that has been established for the content
 Configuration management functions—
functions—the functional elements and associated
workflow that support content object identification, version control, change
management, change auditing, and reporting.

24
Content Management-
Management-II
 The publishing subsystem extracts from the repository, converts
it to a form that is amenable to publication, and formats it so that it
can be transmitted to client-
client-side browsers. The publishing
subsystem accomplishes these tasks using a series of templates.
 Each template is a function that builds a publication using one of
three different components [BOI02]:
 Static elements—
elements—text, graphics, media, and scripts that require no
further processing are transmitted directly to the client-
client-side
 Publication services—
services—function calls to specific retrieval and formatting
services that personalize content (using predefined rules), perform data
conversion, and build appropriate navigation links.
 External services—
services—provide access to external corporate information
infrastructure such as enterprise data or “back-
“back-room” applications.

25
Content Management

conf igurat ion object s

dat abase Cont ent


Management
Syst em

t emplat es

HTML code client -side browser


+ script s

server-side

26
Change Management for WebApps-
WebApps-I
classify t he
request ed change

class 1 change class 4 change

class 2 change class 3 change

acquire relat ed object s dev elop brief writ t en dev elop brief writ t en
descript ion of change descript ion of change
assess impact of change

t ransmit t o all t eam t ransmit t o all st ake-


members for rev iew holders for rev iew
changes
required
in relat ed
object s

furt her furt her


ev aluat ion ev aluat ion
is required OK t o make is required OK t o make

27
Change Management for WebApps-
WebApps-II

check out object ( s)


t o be changed

make changes
design, const ruct , t est

check in object ( s)
t hat were changed

publish t o WebA pp

28