1814 - Hand Out Modul A Manajemen Proyek

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

These courseware materials are to be used in conjunction 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
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
Framework Activities
Communication
Planning
Modeling
Analysis of requirements
Design
Construction
Code generation
Testing
Deployment
Umbrella Activities
Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Work product preparation and production
Reusability management
Measurement
Risk management
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
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.
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)
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
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
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
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
The Primary Goal of Any Software
Process: High Quality
Remember:
High quality = project timeliness
Why?
Less rework!
Software Engineering: A Practitioner’s Approach,
6/e
Chapter 3
Prescriptive Process Models
copyright © 1996, 2001, 2005

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?
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
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
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
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
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
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
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)
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
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
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery code
feedback test
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
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
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
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)
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
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
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
Software Engineering: A Practitioner’s Approach,
6/e
Chapter 4
Agile Development
copyright © 1996, 2001, 2005

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.

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
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
Agile Team
Characteristics
Competence
Common focus
Collaboration
Decisiveness
Fuzzy problem-
problem-solving ability
Mutual trust and respect
Self--organization
Self
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
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
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
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)
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
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.
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
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
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
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)
Chapter 6
System Engineering
copyright © 1996, 2001, 2005

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
Computer--Based System
Computer
A set or arrangement of elements

organized in order to accomplish some
predefined goal by processing
information
System Engineering
Elements of a computer-
computer-based system
Software
Hardware
People
Database
Documentation
Procedures
Systems
A hierarchy of macro-
macro-elements
The Hierarchy
Business or
Product Domain
World view
Domain of interest
Domain view
System element
Element view
Detailed view
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.
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
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
System Engineering
Two variants exist:
Business Process Engineering

Product Engineering
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
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
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
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
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
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
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
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)
Product Architecture Template
(after Hatley-
Hatley-Pirbhai)
user interface processing
input process and control output

processing functions processing
maintenance and self-test
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
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
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
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
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( )
Chapter 7
Requirements Engineering
copyright © 1996, 2001, 2005

Stages:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management
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
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
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
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
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?
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
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?
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
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
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 (;-(;-)
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
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.
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?
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
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
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
Class Diagram
From the SafeHome system …
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure()
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

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.
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”
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?
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?
Chapter 8
Analysis Modeling
copyright © 1996, 2001, 2005

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.
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
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.
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
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.
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)
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
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
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)
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
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
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)
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
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
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
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
Building a Class
class name
attributes:
operations
attributes:
operations:
What is a Class?
occurrences roles
things organizational units
places
external entities
structures
class name
attributes:
operations:
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”
Class Hierarchy
PieceOfFurniture (superclass)
Table Chair Desk ”Chable"
subclasses of the
instances of Chair
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.
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?
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
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?
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
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
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
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
The Flow Model
Every computer-
computer-based system is an
information transform ....
computer
input based output
system
Flow Modeling Notation
external entity
process
data flow
data store
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
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
Data Flow
Data flows through a system, beginning

as input and be transformed into output.
base
compute
area
triangle
height area
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
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
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
Level 0 DFD Example
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal
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
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
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)
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
DFDs: A Look Ahead
analysis model
Maps into
design model
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.
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
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
Control Specification (CSPEC)
The CSPEC can be:
state diagram
(sequential spec)
state transition table

combinatorial spec
decision tables
activation tables
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?"
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
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.
Selecting Classes—
Classes—Criteria
Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements
Class Diagram
Class name
System
systemID
verificationPhoneNumber
systemStatus attributes
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries
program()
display()
reset()
query() operations
modify()
call()
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( )
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.
CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: 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
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.
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.
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
Composite Aggregate Class
Player
PlayerHead PlayerBody PlayerArms PlayerLegs
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.
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
Multiplicity
Wall
1 1 1
is used to build is used to build
1..* 0..* is used to build 0..*
WallSegm ent Window Door
Dependencies
DisplayWindow Camera
<<access>>
{password}
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.
Analysis Packages
package name
Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOf TheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Charact ers
+Player
+Protagonist
+Antagonist
+SupportingRole
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.
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.
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
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
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
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
Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
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?"
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?
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
Chapter 10
Architectural Design
copyright © 1996, 2001, 2005

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.
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].
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
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
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.
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
Data--Centered Architecture
Data
Data Flow Architecture
Call and Return Architecture
Layered Architecture
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.
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
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
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
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
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
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.
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
Deriving Program Architecture
Program
Architecture
Partitioning the Architecture
“horizontal” and “vertical” partitioning are

required
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
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
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
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
Flow Characteristics
Transform flow
Transaction
flow
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
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
Factoring
direction of increasing
decision making typical "decision
making" modules
typical "worker" modules
First Level Factoring
main
program
controller
input processing output

controller controller controller
Second Level Mapping
main
D
C
control
B A
A
B
C
mapping from the D

flow boundary outward
Transaction Flow
incoming flow
action path
T
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
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!
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.
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
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
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
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
Chapter 13
Software Testing Strategies
copyright © 1996, 2001, 2005

Software Testing
Testing is the process of exercising a

program with the specific intent of finding
errors prior to delivery to the end user.
What Testing Shows
errors
requirements conformance
performance
an indication
of quality
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
Testing Strategy
unit test integration
test
system validation
test test
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
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.
Unit Testing
module
to be
tested
results
software
engineer
test cases
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
Unit Test Environment
driver
interface
local data structures
Module boundary conditions
independent paths
error handling paths
stub stub
test cases
RESULTS
Integration Testing Strategies
Options:
• the “big bang” approach

• an incremental construction strategy
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
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
Sandwich Testing
A
Top modules are
tested with stubs
B F G
Worker modules are grouped into

builds and integrated
D E
cluster
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
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).
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.
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
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.
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
Debugging:
A Diagnostic Process
The Debugging Process
test cases
new test results

regression cases
tests suspected
causes
corrections
Debugging
identified
causes
Debugging Effort
time required
to diagnose the
time required symptom and
to correct the error determine the
and conduct cause
regression tests
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
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.
Debugging Techniques
Brute force / testing
Backtracking
Induction
Deduction
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.
Chapter 14
Software Testing Techniques
copyright © 1996, 2001, 2005

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
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
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
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!!
Selective Testing
Selected path
loop < 20 X
Software Testing
white-box black-box
methods methods
Methods
Strategies
White--Box Testing
White
... our goal is to ensure that all

statements and conditions have
been executed at least once ...
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
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
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
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.
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
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
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
Loop Testing
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
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
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.
Black--Box Testing
Black
requirements
output
input events
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?
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.
Equivalence Partitioning
user output FK
queries formats input
mouse
picks data
prompts
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
Boundary Value Analysis
user output FK
queries formats input
mouse data
picks prompts
output
input domain domain
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
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
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.
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.
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
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
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
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 ] )
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]
Chapter 26
Quality Managementcopyright © 1996, 2001, 2005

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
Chapter 27
Change Management copyright © 1996, 2001, 2005

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

1814 - Hand Out Modul A Manajemen Proyek

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1814 - Hand Out Modul A Manajemen Proyek

Transféré par

Droits d'auteur :

Formats disponibles

MATERI KULIAH

• MK Rekayasa Perangkat Lunak

Week Date Lecture Topic Readings

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

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

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

copyright © 1996, 2001, 2005

For University Use Only

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

Why must it change?

• “Project requirements continually change but this

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

• “The only deliverable work product for a successful project

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

For University Use Only

identifies is examined by identifies capabilities

High quality = project timeliness

For University Use Only

Prescriptive process models advocate an orderly approach to

That leads to a few questions …

A.k.a.: Classic Life Cycle

project calendar t ime

Applies elements of the waterfall model in incremental fashion

Const r uct ion

Useful when the customer has a legitimate need but is

Combines iterative prototyping with systematic aspects of the

A state is some externally observable mode of behaviour

For University Use Only

Kent Beck et al.

Rapid, incremental delivery of software

ref act oring

Promoted by the DSDM Consortium (www.dsdm.org

Crystal — distinguishing features:

For University Use Only

A set or arrangement of elements

Used to verify and validate models before implementing

Helps eliminating surprises during implementation

Allows system engineers to “test drive” the specifications

Two variants exist:

Business Process Engineering

Data architecture provides a framework for the information

Application architecture encompasses those elements of a

Technology infrastructure provides the foundation for the

Business area analysis (BAA)

Construction and delivery

user interface processing

input process and control output

maintenance and self-test

CLSS processing & control report timing/location data

part shunt shunt

raw bar bin