SOFTWARE PROCESS MODELING
Benjamin Dixon
U60537340
PROCESS CHARACTERISTICS AND MAJOR
ACTIVITIES
Characteristics
Major Activities
Software Process: “A software process is a
set of related activities that leads to the
production of a software product.”
 Software specification The functionality of
the software and constraints on its
operation must be defined.
 Software design and implementation The
software to meet the specification must be
produced.
 Software validation The software must be
validated to ensure that it does what the
customer wants.
 Software evolution The software must
evolve to meet changing customer needs.
Includes:







Requirements
System Design
Program Design
Coding/implementation
Unit/integration/system testing
Delivery
Maintenance
SOFTWARE PROCESS MODELS
Prescriptive
Descriptive
 A prescriptive model defines the path software
development should follow ahead of time.
 A descriptive model tracks the real progress of
the project as it is ongoing.
Reasons for Modelling




Organize efforts
Track progress
Track changes in requirements
Keep up with deadlines
THE WATERFALL MODEL
Description
 Separates the development process into the
sections shown on the left.
 Each segment proceeds strictly after the
previous.
Pros
 Easier for managers and onlookers to
understand
Cons
 Inflexible
Reality
 Segments actually overlap and repeat
constantly
Peter Kemp/ Paul Smith – Wikipedia.org
WATERFALL MODEL WITH PROTOTYPING
Description
 A type of Waterfall Model that involves
creating a partial product and reworking it over
and over.
Pros
 Allows more flexibility.
 Allows for product verification at multiple
phases.
Cons
 Can increase overhead time/effort costs.
Reality
 Improves upon the original Waterfall method.
Gary Shute, University of Minnesota
THE V-MODEL
Description
 Breaks development into 3 parts: execute, write,
check
 Execute: defines project goals and design
 Write: write the code and implement the system
 Check: unit testing, integration testing, system testing
Pros
 Each testing phase connects back to its
associated design phase, illustrating the
iteration process.
Cons
Harmonicss.co.uk
 Unfortunately, it is not flexible to change.
PROTOTYPING MODEL
Description
 Quickly develop prototypes matching
requirements.
 Customer can evaluate prototype.
 Either refine or reject the prototype.
Pros
 Customers are more involved in the final
product.
istqbexamcertification.com
Cons
 Can spend a lot of wasted time on rejected
prototypes.
OPERATIONAL SPECIFICATION MODEL
Description
 Requirements are assessed prior to design and
implementation.
 Allows requirements to be solidified and refined
prior to spending time implementing incorrectly.
S. Pfleeger and J. Atlee
TRANSFORMATION MODEL
Description
 Codifies requirements into a formal document
 Formal requirements are transformed
incrementally into a deliverable system
S. Pfleeger and J. Atlee
PHASED DEVELOPMENT MODEL
Description
 Systems are produced in different phases
spaced over time.
 Gets products out quicker.
 Allows the customer to have something usable
while the rest of the system is being developed.
S. Pfleeger and J. Atlee
INCREMENTAL AND ITERATIVE MODELS
Incremental
 Produce individual subsystems one at a time,
adding functionality to the overall product over
time.
Iterative
 Produce a full system, adding/changing
subsystem functionality over time.
S. Pfleeger and J. Atlee
SPIRAL MODEL
Description
 Combination of development and risk
management.
 Each quadrant of the spiral represents a
different activity:
 Evaluating Risks/Alternatives
 Developing/Testing
 Planning
 Goal Planning
S. Pfleeger and J. Atlee
AGILE METHODS
An alternative method to software
development.
Improves flexibility in the development
process.
Follows the principles of the Agile
Manifesto:
 Individuals and interactions are greater than
process and tools
 Focus on working software rather than
documentation
 Customer collaboration over contracts
 Respond to change rather than plan
Examples of Agile Programming




Extreme Programming (XP)
Crystal
Scrum
Adaptive Software Development (ASD)
12 FACETS OF XP
 The planning game
 Small release
 Metaphor
 Simple design
 Writing tests first
 Refactoring
 Pair programming
 Collective ownership
 Continuous integration
 Sustainable pace
 On-site customer
 Coding standard
TOOLS FOR PROCESS MODELING
Notation: dependent on goal of the model
 Text-based or graphical flow-charts
Different types of modeling
 Static Models
 Dynamic Models
S. Pfleeger and J. Atlee
STATIC MODELING
Name
Synopsis
Complexity type
Data type
Artifact-state list
parked
Lai Notation







Activity
Sequence
Process model
Resource
Control
Policy
Organization
initiated
moving
Car
This is the artifact that represents a class of cars.
Composite
(car_c, user-defined)
((state_of(car.engine) = off)
(state_of(car.gear) = park)
(state_of(car.speed) =
stand))
((state_of(car.engine) = on)
(state_of(car.key_hole) =
has-key)
(state_of(car-driver(car.))
= in-car)
(state_of(car.gear) = drive)
(state_of(car.speed) =
stand))
((state_of(car.engine) = on)
(state_of(car.keyhole) =
has-key)
(state_of(car-driver(car.))
= driving)
((state_of(car.gear) =
drive) or (state_of(car.gear)
= reverse))
((state_of(car.speed) =
stand) or
(state_of(car.speed) = slow)
or (state_of(car.speed) =
medium) or
(state_of(car.speed) =
high))
Car is not moving, and
engine is not running.
doors
engine
keyhole
The four doors of a car.
The engine of a car.
The ignition keyhole of a
car.
The gear of a car.
The speed of a car.
Car is not moving, but the
engine is running
Car is moving forward or
backward.
Sub-artifact list
gear
speed
Relations list
car-key
car-driver
S. Pfleeger and J. Atlee
This is the relation between a car and a key.
This is the relation between a car and a driver.
DYNAMIC MODELING
Shows resources at each step of
development
Simulates alternatives and changes
Systems dynamic approach
 Improves productivity
 Shows how changes in one thing affect other
things
S. Pfleeger and J. Atlee
PRACTICAL PROCESS MODELING
Marvel Specification Language (MLS)
TICKET:: superclass ENTITY
status : (initial, open, referred_out, referral_done,
closed, fixed) = initial;
diagnostics : (terminal, non_terminal, none) = none;
level
: integer;
description : text;
referred_to : link WORKCENTER;
referrals
: set_of link TICKET;
process
: link PROC_INST;
end
diagnose [?t: TICKET]:
(exists PROC_INST ?p suchthat (linkto [?t.process ?p]))
:
(and (?t.status = open}(?t.diagnostics = none))
{TICKET_UTIL diagnose ?t.Name}
(and (?t.diagnostics = terminal)
(?p.last_task = diagnose)
(?p.next_task = refer_to_WC3));
(and (?t.diagnostics = non_terminal)
(?p.last_task = diagnose)
(?p.next_task = refer_to_WC2));
S. Pfleeger and J. Atlee
Class
definition
for trouble
tickets
 Tool envelopes, classes, rules
 Three main concepts define a process
description
 rule-based
 Object-oriented
 Interface between process and external systems
Rulefor
diagnosing
ticket
REFERENCES
 Sommerville, Ian. Software Engineering. Boston: Pearson, 2011. Print.
 S. Pfleeger and J. Atlee, Software Engineering:Theory and Practice. Upper Saddle River [N.J.]: Prentice
Hall, 2010.