صفحه 1:
CSEB233 Fundamentals of
Software Engineering
Module 2: Software Processes
صفحه 2:
Objectives
* Dp desoibe types oP process Plows.
* Do exphia soPtwore provess potteras.
٠ Do tdediPy severd provers wsesswed
عمجم مرو له Proneworks
۰ موی و presoipive ond spevicized
امد provess wodels.
۰ Do select u process wodel واه و(
صفحه 3:
A Generic Process
Model
۰ @ spPiwwe provess:
باس تست تست اه مایت نت لا tusks,
whick oe perPorwed whe soPiuvore ts 17
.له و
۰ @ process wodel or Praxvework
Os where these usivites, uctives, umd fushs
reside, ood thot dePioes their retoivaship wity
المي سيو يسول حي هد رما باق ما
ut svPiwvurr process.
صفحه 4:
A Generic Process Model
(cnt’d)
اسب سای ۳( ۰
اه - hierarchy
ات رس
Software process
Umbrella activities
pomiksed by took. ةي
۰ Cook مت ty deed by o sete | Sho مل
fet ee haber a
(tke aot work to be Besa dl Dali
و ۳
©. he works produnty to ber
رال
تا عمجت سامت سا framework activity #n
tw be oped, cred زج اه سوه »اس
6 مات م۲ thot ual be شش | سس
لصي wy nabs the proper 0
تس سل لعي i
ee
صفحه 5:
Process Activities:
Framework and
Umbrella.
مر اه الج عجارتن عت جل برعي مين و
رس سس سا ان سا ورس یج
اس :یمام Soke pre nication, 0
رطع لت اوه
۰ Ovobrete uniivities:
مه و تا لو مه وولو ۵
امن prvjert vod help woeage ord ovoid progress,
res, ی رجا
موه و امه له مها موم علما1 ۵
صفحه 6:
Process Flow
* Oesmribes how the Prowework ontiviies aod the
upiives ced tasks that pour withic Pack activity ore
ار لحم respect io sequeere ocd tee.
٠ Whe Bows:
0. Dieear — exevute the Proawework oniiviies ic
سوه
اه با هه 0 ۲۰ - مها .9
سا ما روم وس
لح و وا رش با صجوو — Cucktouey .9
Somer.
@. Paull — exevutes vor or wore wives
wih viker actuiies. برص جصددانجهاد
صفحه 7:
جا
جا
صفحه 8:
Process Patterns
۰ woud be موم ۴ لخلیی soktioa to the probes,
هط وت ما و و ام
ی[
ی evant.
eros, 0 process pales provides yu wits لو و و۰
اس بو لمات موه مص[( ]ماو
و و ره بطاخم موه thre ی هه ما
سم سس 0 ۰
اد امس و لا ام لاوس و سوام
با ری هرود
ما وا امس با مات و نمی سا متام
اجه لامج
ارام ع وا موه موس و هارمه
صفحه 9:
Process Assessment and
Improvement
Opprenahes:
4. Oxankad ODO Ooorrecret Deter! Por Proveny ‘hegre
(Oo) :
ورن 000/1 اتا جا معطم موصعم جد رسيي سيت oem thro ear,
0
امح روف و
©. COO -Deerd Oppratrd Por tered Proveyy “Ieoprovenvent (OOO
4):
بمميخاد د chats eft Bor semen brett tir of سور
rcpt ere ar (AE! ODD cr be nr Po fe erm (Dan
Aree, OM kr bees rere by (AE se rho XD yang of
serch
9. O08 (OOMGOIGSOF):
+ karl fa denen at oP resurecoest Por Pune procene seme, Ther
acto he sachs مه وم و chub ox cba rack ae
متا of ane سای متا preveny. [SOOO]
تساه ۳ 5000:6000 1۵0 ۴
موه سم با موی مد مهم موم روت با و وا ما مود
kerk rey سا ساسا ,لو نج سم سول سر
[0420] موجه احج سج ۳
صفحه 10:
Prescriptive Process
Models
©) Crowote oo orderly, structured approach to
GE
8 عط Bou ل
115 دس room ات تا نتاس
اه و مجوومةة مجم سح طسو لت
ine ted tees eck?
۰ et, Pe rent tredicod process wodels (oad the
order they kop) ond rephice thew wth sowetiery
مر او رایع ۱ ی نلویو میا
تاه و موس مه موه ۶
صفحه 11:
Prescriptive Process
Models (cnt’d)
* OsterPal Dodel — represeuis eleweuts of o bear
process Pow
6
* deorewecid Dodel — cxobrey eke oP tea: ood
pardel provesy Plows
* Cuckitocary Oodel — Polos the euckacoay process
low that coxwbiaes ekecoecits oP tesar ed tereiive process
Plows
* اروصم
٠ Gpirdt
۰ ای - ا() حون eleweruts oF terete ood
|
صفحه 12:
۱۰ بطق The Waterfall Model
¢ Represents a linear process flow from
communication through deployment.
analysis
esign
* Also known as the classic SDLC
* The original Waterfall model proposed by Winston Royce
in 1970 made provision for feedback loops, but many
organizations apply this model as if it were strictly linear.
صفحه 13:
11۳ V-Model
QA variation in the
representation of
the Waterfall
‘System model.
Q |llustartes how اعم
۲ كه V&V actions are
[es associated with
earlier SE action.
nt ۲ ۱ أجل[ ست
Genention [| resting Q In reality, there is
no fundamentals
difference
۳4 between the
stware Waterfall model
and the. V-model.
صفحه 14:
The Waterfall
odel: An Analysis
Applicability
When requirements
are well understood
and unlikely to
change radically
during system
development (e.9.
ina well-defined
enhancement to an
‘existing system).
When software
development
technologies and
tools are well known,
The work tasks in the
project are to
proceed to
completion in a linear
Weaknesses
Real projects rarely follow
the linear flow that the
model proposes.
Although iteration is,
indirectly allowed,
changes are costly,
involve significant rework
and can cause confusion
to project team and
involve.
‘The model requires the
customer to state all
requirements explicitly,
which is often very
difficult to achieve.
‘The working software will
rot available until late in
the project, which can be
disastrous for late
discovery of major
defects
Leads to “blocking
states” in which some
11
Strengths
Simple and easy to
Usefexplain to
customers.
The staged development
cycle enforces
discipline: every phase
has a defined start and
fend point, and progress
can be conclusively
identified (through the
Use of milestones)
Characteristics
It suggests a
systematic,
sequential
‘approach to SE
staring from
requirements
specification going
through planning,
modeling,
construction,
testing, deployment
‘and support of the
completed system.
Each major activity
is marked by
milestones and
deliverables
(artifacts ie.
documents).
صفحه 15:
yf ne Incremental Model
e functionality and features
project calendar time
صفحه 16:
1 fone Incremental
Model (cnt’d)
Q Rather than deliver the software product as a
single delivery, the development and delivery
is broken down into increments with each
increment delivering part of the required
functionality.
Q User requirements are prioritised and the
highest priority requirements are included in
early increments.
Q Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can
continue to evolve.
صفحه 17:
ft The Incremental
4 odel: An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
صفحه 18:
qm felutionary Model:
Prototyping
2-0
صفحه 19:
۳ Model:
Prototyping (cnt’d)
Q Using this process model, a prototype (an early
approximation of a final software product) is
built, tested, and then reworked as necessary
until an acceptable prototype is finally achieved
from which the complete software product can
now be developed.
Q Although it can be implemented as a stand-
alone process model, it is more commonly used
as part of other process models.
Q The main purpose of the model is to help better
understand what it is to built when
requirements are fuzzy.
صفحه 20:
1 Model:
4 An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
صفحه 21:
هك
Model: مدده ان ۱ ۲
Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
deployment
delivery
feedback
construction
code
test
صفحه 22:
۳ Model:
Spiral (cnt’d)
Q A process model that combines the
iterative nature of prototyping with the
systematic aspects of waterfall model.
Q The spiral model can be thought of as a
repeating waterfall model that emphasizes
risk assessment and that is executed in an
incremental fashion.
Q Each loop/pass through the spiral model
consists of risk assessment and other
framework activities from
communication through deployment.
صفحه 23:
f titre Spiral Model:
4 An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
صفحه 24:
۸ ششک Process
صفحه 25:
۱ 1 ام Process
Model (cnt’d)
Q A process model that combines the
iterative and parallel elements of any of
the prescriptive process models.
Q In this process model, all SE activities
(framework or umbrella activities) exist
concurrently but reside in different states.
صفحه 26:
1۹ The Concurrent
4 odel: An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
صفحه 27:
Specialised Process
Models
* Opwpoud bused soPware developed (OOOO)
the process 7 opr wheo name fo devel cece
+ Ponwd webods
لسوت رتم بط ارو of برد هو
فص وه ماوت حرط من اسان ore wo
ites used.
* Qspectorieued svPware devebpweut (POCO)
proves a process ud weber اسر Bor
debian, speck any desea, وه او epee
* OcPed Process
سامت ,مسر وی و tercive ol
kerewedd’ soPLuae process bse) decd wk the
Oued Drdekay Lornaxe (DOL)
صفحه 28:
Specialised Process Models
(cnt’d)
* Gee Goa
0 نمی مهو b naneeiints ope ومطع سمت رمسم
anal depraved, whick supped rapa hence سوم و
* Persond Process Dodel
urhwotan he veal y revur enn مه ات ی اجه
هنن cine, ov hut keloke orc tev «ire chon
thew.
* Dean Provess Oodel
وه لاه لا( ot plow ed rack fete work, eto
rd, ord oun ae procemsen orl pnw. heme ox be pure
عن تحص جمدم اد Kier proxket exis (APT) oP bree ص
موه 60 مس
هت لجی ای بط نما جوم تنطا) tet مج onl he
بط مهاست تلا ماس با
صفحه 29:
Agile Development
* Combines a philosophy and a set of
development guidelines.
* The philosophy encourages:
7“ customer satisfaction and early
incremental delivery of software;
¥ small, highly motivated project teams;
¥ informal methods;
Y minimal SE work products; and
Y overall development simplicity.
* The development guidelines:
Y stress delivery over analysis and design,
and
¥ active and continuous communication
between developers and customers
صفحه 30:
The Agile Manifesto
1. Value individuals and interactions over
process and tools
2. Prefer to invest time in producing
working software rather than in
producing comprehensive documentation
3. Focus on customer collaboration rather
than contract negotiation
4. Concentrate on responding to change
rather than on creating a plan and then
following it
* Why?
٠ The modern business environment is fast-
paced and ever-changing. This process
model has been demonstrated to deliver
successful systems quickly.
صفحه 31:
8 ۰ Agile Principles
Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developers must work together
daily throughout the project.
Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
صفحه 32:
1 0 Agile Principles
(cnt’d)
: Working software is the primary measure of
progress.
8. Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10.Simplicity - the art of maximizing the amount of
work not done - is essential.
11.The best architectures, requirements, and designs
emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
ل ال i
صفحه 33:
Agile: Human Factors
* the process molds to the needs of
the people and team, not the other
way around
* key traits must exist among the
people on an agile team and the team
itself:
7“ Competence.
¥ Common focus.
Y Collaboration.
Y Decision-making ability.
Y Fuzzy problem-solving ability.
“ Mutual trust and respect.
Y Self-organization.
صفحه 34:
The Agile Process
Models
* Also known as approaches to agile
software engineering, which include:
+ Extreme Programming (XP)
* Industrial XP
8 Scrum
+ Adaptive Software Development (ASD)
٠ Dynamic Systems Development
Method (DSM)
٠ Crystal
+ Feature Driven Development (FDD)
+ Lean Software Development (LSD)
۰ Agile Modeling (AM)
* Agile Unified Process (AUP)
صفحه 35:
The Extreme
Programming (XP)
۰ The most widely used approach to
ser stories
values
acceptance test criteria
iteration plan
صفحه 36:
if tthe XP: Activities
XP Planning
Begins with the creation of “user 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 velocity” is
used to help define subsequent delivery dates
for other increments
صفحه 37:
۴ Activities (cnt’d)
XP Design
٠ Follows the KISS principle
٠ Encourage the use of CRC cards (see Chapter 8)
٠ For difficult design problems, suggests the creation of
“spike solutions”—a design prototype
+ Encourages “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 programming”
XP Testing
* All unit tests are executed daily
+ “Acceptance tests” are defined by the customer and
executed to assess customer visible functionality
صفحه 38:
ggme Programming
۹ (XP): An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
صفحه 39:
Selecting a Process
Model
* Oda te sidebars to pores PS ond PP.
* Okot we the lessocrlearued Prow these sidebars?
صفحه 40:
Selecting a Process
Model
° Punters ty cousider:
4 Dke choradtertotics oP the problews to be solved.
uk جم رما هه
(E92 sxople with clear, stuble requirewets, cocplen نت
rete مج
©. Vhe choravteristiog oP the project
رن الم انس لسوت معط سب موه سای اس
جا ریا رت مد
۱ بوصاصحادها جإسج حصا ب عمصو كج شوصت
اعاسين صا حك محص حت سيك بيطا[ .©
wette of te product, product docata, et عبج ]
یو رای سا ار رن بو وچ برس بل ۳
works
(uck oe polio, puke, Feoxuce str.
صفحه 41:
1 0 Key Questions in
Determining Task Set
* Different projects requires different task sets.
The tasks should be selected based on
problems and project characteristics.
* Q: What actions are appropriate for a
framework activity, given:
Y the nature of the problem to be solved;
۷۶ the characteristics of the people doing the work; and
Y the stakeholders of the project?
٠ Q: What work tasks (task set) that these actions
should encompasses of?
صفحه 42:
ete
Example
* Nature of the problems and project :
¥ Asmall software project requested by one person
(at a remote location) with simple, straightforward
requirements.
* Actions:
Y Opwxnunicuica uted! devebp requreweds
+ Task set:
۷ Make contact with stakeholder via telephone.
Y Discuss requirements and take notes.
۷۶ Organize notes into a brief written statement of
requirements.
zx
صفحه 43:
Process Management
Tools
° Obv kaaws os process wodelagy tools or process
teckel.
٠ مج ه منوا to dePtoe ged ooeue the خن تساه
poe wodel (untivites, ucive, tsk, work product,
wikesirues, ond QO poiuts/Piters).
* Gch tools dev provide detaled quidcame vo the عمدت
oP eack provess elewect.
٠ De tools wap dsy provide strrdad projevt
wwoeayewed tske sucks us esticvatiag, scbeduiegy,
tracker cod patrol.
© Cxcrople:
(ممه سس طه dart Process *
صفحه 44:
f PiBelecting a Process
4 Model: an Exercise
* The project:
Assume that you are in charge of a project to create a
portal for the Shah Alam district of Selangor state. This
portal would include a homepage with links to a wide range
of discounted travel packages to major destinations in
Selangor, links to certain featured places like golf courses,
shopping complexes and places to eat, links to the detailed
map of Selangor, and links to news and events listing. It
also includes a bulletin board and chat room feature where
tourists (international and local tourists) can exchange
information. The portal should also provide Automated
Teller Machine (ATM) locator, timezone converter, and
currency converter.
*Select a software process model that you
would recommend to be implemented:in the
صفحه 45:
Summary
"Dhere oe Pour yes of process Paws - near, tercive,
euokdiocary, ord parcel.
GoPuvare process puleras SOY PARKES! DOE DY Ore proven
نما مر ممه نايت problew Pro ver proevis, which aa be
rosea وا ذا pron.
opt mosis لو موه و اوه بو وال
pravticcers. روا اوه سا مه نا موسوم
۳ مص ی اسرد له مهو ۶و وله
ات تم veri وه مد من تا perro
process swede Por a soPwvare developoedt ام whick
rea ی ام re been iB toes srt Bo tse
project.
صفحه 46:
References and credit
Oontedts to the sides are adapted Prow the book ocd
امه نا لاد سا the book by R.G.
Presswon, SpPivore Bogiceeriag: ( Practiiccer’s
Opprowk, ‘Pk. Edition, OeCrav Wil, ۰
CSEB233 Fundamentals of
Software Engineering
Module 2: Software Processes
Badariah Solemon 2010
Objectives
• To describe types of process flows.
• To explain software process patterns.
• To identify several process assessment
and improvements frameworks
• To analyze prescriptive and specialized
software process models.
• To select a process model for software
development project.
• To determine task set for software
process activities.
Badariah Solemon 2010
A Generic Process
Model
• A software process:
a collection of work activities, actions, tasks,
which are performed when software is to
be created.
• A process model or framework
is where these activities, actions, and tasks
reside, and that defines their relationship with
the process and with one another.
Also known as an abstract representation of
a software process.
Badariah Solemon 2010
A Generic Process Model
(cnt’d)
•
•
The technical work
hierarchy – activities
encompassing actions,
populated by tasks.
Each action is defined by a
set of task that defines:
1. the actual work to be
completed,
2. the work products to be
produced,
3. the quality assurance filters
to be applied, and
4. The milestones that will be
used to indicate the project
and product progress.
Badariah Solemon 2010
•
Process Activities:
Framework and
Umbrella
Framework activities :
o generic activities that are applicable to all software
projects, regardless of their size or complexity.
o Include communication; planning; modeling,
construction; and deployment.
• Umbrella activities:
o complementary activities applied throughout a software
project and help manage and control progress, quality,
change, and risk.
o Include project tracking and control; risk
management; software quality assurance (SQA);
technical reviews; configuration management (CM);
etc.
Badariah Solemon 2010
Process Flow
• Describes how the framework activities and the
actions and tasks that occur within each activity are
organized with respect to sequence and time.
• The flows:
1.
Linear – execute the framework activities in
sequence.
2. Iterative – repeats one or more of the activities
before proceeding to the next.
3. Evolutionary – execute the activities in a ‘circular’
manner.
4. Parallel – executes one or more activities
simultaneously with other activities.
Badariah Solemon 2010
Process Flow
Badariah Solemon 2010
Process Patterns
• It would be useful if proven solution to the problems,
encountered as project team moves through a software
process, were readily available , which can be reused in
another project.
• In more general terms, a process pattern provides you with
a template [Amb98]—a consistent method for describing
problem solutions within the context of the software process .
• A process pattern
•
•
•
describes a process-related problem that is encountered during
software engineering work,
identifies the environment in which the problem has been
encountered, and
suggests one or more proven solutions to the problem.
Badariah Solemon 2010
Process Assessment and
Improvement
•
Approaches:
1. Standard CMMI Assessment Method for Process Improvement
(SCAMPI) :
•
Is used to identify strengths, weaknesses, and ratings relative to SEI CMMI appraisal
reference model, which is applicable to internal process improvement and external
capability determination.
2. CMM-Based Appraisal for Internal Process Improvement (CBA
IPI):
•
provides a diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment [Dun01].
However, CMM has been retired by SEI since the introduction of CMMI group of
standards.
3. SPICE (ISO/IEC15504):
•
standard that defines a set of requirements for software process assessment. The
intent of the standard is to assist organizations in developing an objective evaluation of the
efficacy of any defined software process. [ISO08]
4. ISO 9001:2000 for Software:
•
a generic standard that applies to any organization that wants to improve the overall quality
of the products, systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]
Badariah Solemon 2010
Prescriptive Process
Models
• Promote an orderly, structured approach to
SE
• 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?
Badariah Solemon 2010
Prescriptive Process
Models (cnt’d)
• Waterfall Model – represents elements of a linear
process flow
• V
• Incremental Model – combines elements of linear and
parallel process flows
• Evolutionary Model – follows the evolutionary process
flow that combines elements of linear and iterative process
flows
• Prototyping
• Spiral
• Concurrent Model – combines elements of iterative and
parallel process flows
Badariah Solemon 2010
The Waterfall Model
• Represents a linear process flow from
communication through deployment.
Communication
project initiation
requirement gathering
Planning
estimating
scheduling
tracking
Modeling
analysis
design
Construction
code
test
Deployment
delivery
support
f eedback
Also known as the classic SDLC
* The original Waterfall model proposed by Winston Royce
in 1970 made provision for feedback loops, but many
organizations apply this model as if it were strictly linear.
*
Badariah Solemon 2010
The V-Model
A variation in the
representation of
the Waterfall
model.
Illustartes how
V&V actions are
associated with
earlier SE action.
In reality, there is
no fundamentals
difference
between the
Waterfall model
and the
BadariahV-model.
Solemon 2010
The Waterfall
Model: An Analysis
Characteristics
Strengths
It suggests a
systematic,
sequential
approach to SE,
staring from
requirements
specification going
through planning,
modeling,
construction,
testing, deployment
and support of the
completed system.
Each major activity
is marked by
milestones and
deliverables
(artifacts i.e.
documents).
Simple and easy to
use/explain to
customers.
Weaknesses
The staged development
cycle enforces discipline:
every phase has a
defined start and end
point, and progress can
be conclusively
identified (through the
use of milestones)
Applicability
Real projects rarely follow
the linear flow that the
model proposes.
Although iteration is
indirectly allowed,
changes are costly,
involve significant rework
and can cause confusion
to project team and
involve.
The model requires the
customer to state all
requirements explicitly,
which is often very
difficult to achieve.
The working software will
not available until late in
the project, which can be
disastrous for late
discovery of major
defects.
Leads to “blocking
states” in which some
When requirements
are well understood
and unlikely to
change radically
during system
development (e.g.:
in a well-defined
enhancement to an
existing system).
When software
development
technologies and
tools are well known.
The work tasks in the
project are to
proceed to
completion in a linear
manner.
Badariah Solemon 2010
The Incremental Model
increment #n
Communic at ion
Planning
Modeling
analys is
des ign
C o n s t ru c t i o n
c ode
t es t
De p l o y m e n t
d e l i v e ry
fe e dba c k
delivery of
nth increment
increment # 2
Communic at ion
Planning
Modeling
analys is
des ign
C o n s t ru c t i o n
c ode
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
increment # 1
delivery of
2nd increment
Communic at ion
Planning
Modeling
analys is
des ign
C o n s t ru c t i o n
c ode
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
delivery of
1st increment
project calendar time
Badariah Solemon 2010
The Incremental
Model (cnt’d)
Rather than deliver the software product as a
single delivery, the development and delivery
is broken down into increments with each
increment delivering part of the required
functionality.
User requirements are prioritised and the
highest priority requirements are included in
early increments.
Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can
Badariah Solemon 2010
continue to evolve.
The Incremental
Model: An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
Badariah Solemon 2010
The Evolutionary Model:
Prototyping
Quick plan
Communication
Qu i ck
plan
co m m u n i ca t i o n
Modeling
Quick design
Mo d e l i n g
Qu i ck d e si g n
Deployment
DeDelivery
ployment
d&
e lFeedback
i v e ry &
fe e d b a ck
Construction
Co
ofn st ru ct i o n
oprototype
f p ro t o t y p e
Badariah Solemon 2010
The Evolutionary Model:
Prototyping (cnt’d)
Using this process model, a prototype (an early
approximation of a final software product) is
built, tested, and then reworked as necessary
until an acceptable prototype is finally achieved
from which the complete software product can
now be developed.
Although it can be implemented as a standalone process model, it is more commonly used
as part of other process models.
The main purpose of the model is to help better
understand what it is to built when
requirements are fuzzy.
Badariah Solemon 2010
The Prototyping Model:
An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
Badariah Solemon 2010
The Evolutionary Model:
Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
delivery
feedback
construction
code
test
Badariah Solemon 2010
The Evolutionary Model:
Spiral (cnt’d)
A process model that combines the
iterative nature of prototyping with the
systematic aspects of waterfall model.
The spiral model can be thought of as a
repeating waterfall model that emphasizes
risk assessment and that is executed in an
incremental fashion.
Each loop/pass through the spiral model
consists of risk assessment and other
framework activities from
communication through deployment.
Badariah Solemon 2010
The Spiral Model:
An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
Badariah Solemon 2010
The Concurrent Process
Model
none
Modeling activity
represents the state
of a software engineering
activity or task
Under
development
Awaiting
changes
Under review
Under
revision
Baselined
Done
Badariah Solemon 2010
The Concurrent Process
Model (cnt’d)
A process model that combines the
iterative and parallel elements of any of
the prescriptive process models.
In this process model, all SE activities
(framework or umbrella activities) exist
concurrently but reside in different states.
Badariah Solemon 2010
The Concurrent
Model: An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
Badariah Solemon 2010
Specialised Process
Models
• Component based software development (CBSD)
•
the process to apply when reuse is a development objective
• Formal methods
•
emphasizes the mathematical specification of requirements,
which can demonstrate software correctness but are not
widely used.
• Aspect-oriented software development (AOSD)
•
provides a process and methodological approach for
defining, specifying, designing, and constructing aspects
• Unified Process
•
a “use-case driven, architecture-centric, iterative and
incremental” software process closely aligned with the
Unified Modeling Language (UML)
Badariah Solemon 2010
Specialised Process Models
(cnt’d)
• Agile Process
•
An iterative approach to requirements specification, construction
and deployment, which support rapid changes to requirements.
• Personal Process Model
•
Emphasizes the need to record and analyze errors each individual
practitioner made, so that he/she can develop a strategy to eliminate
them.
• Team Process Model
•
•
Build self-directed teams that plan and track their work, establish
goals, and own their processes and plans. These can be pure
software teams or integrated product teams (IPT) of three to
about 20 engineers.
Show managers how to coach and motivate their teams and how
to help them sustain peak performance.
Badariah Solemon 2010
Agile Development
• Combines a philosophy and a set of
development guidelines.
• The philosophy encourages:
customer satisfaction and early
incremental delivery of software;
small, highly motivated project teams;
informal methods;
minimal SE work products; and
overall development simplicity.
• The development guidelines:
stress delivery over analysis and design,
and
active and continuous communication
between developers and customers
Badariah Solemon 2010
The Agile Manifesto
1. Value individuals and interactions over
process and tools
2. Prefer to invest time in producing
working software rather than in
producing comprehensive documentation
3. Focus on customer collaboration rather
than contract negotiation
4. Concentrate on responding to change
rather than on creating a plan and then
following it
• Why?
• The modern business environment is fastpaced and ever-changing. This process
model has been demonstrated to deliver
successful systems quickly. Badariah Solemon 2010
The Agile Principles
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together
daily throughout the project.
5. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–
Badariah Solemon 2010
to–face conversation.
The Agile Principles
(cnt’d)
7. Working software is the primary measure of
progress.
8. Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10.Simplicity – the art of maximizing the amount of
work not done – is essential.
11.The best architectures, requirements, and designs
emerge from self–organizing teams.
12.At regular intervals, the team reflects on how to
become more effective, then tunes andBadariah
adjusts
its
Solemon 2010
Agile: Human Factors
• the process molds to the needs of
the people and team, not the other
way around
• key traits must exist among the
people on an agile team and the team
itself:
Competence.
Common focus.
Collaboration.
Decision-making ability.
Fuzzy problem-solving ability.
Mutual trust and respect.
Badariah Solemon 2010
Self-organization.
The Agile Process
Models
• Also known as approaches to agile
software engineering, which include:
•
•
•
•
•
•
•
•
•
•
Extreme Programming (XP)
Industrial XP
Scrum
Adaptive Software Development (ASD)
Dynamic Systems Development
Method (DSM)
Crystal
Feature Driven Development (FDD)
Lean Software Development (LSD)
Agile Modeling (AM)
Agile Unified Process (AUP)
Badariah Solemon 2010
The Extreme
Programming (XP)
• The most widely used approach to
agile SE.
spike solutions
user stories
values
acceptance test criteria
iteration plan
simple design
CRC cards
prototypes
refactoring
pair
programming
Release
software increment
project velocity computed
unit test
continuous integration
acceptance testing
Badariah Solemon 2010
The XP: Activities
XP Planning
• Begins with the creation of “user 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 velocity” is
used to help define subsequent delivery dates
for other increments
Badariah Solemon 2010
The XP: Activities (cnt’d)
XP Design
•
•
•
•
Follows the KISS principle
Encourage the use of CRC cards (see Chapter 8)
For difficult design problems, suggests the creation of
“spike solutions”—a design prototype
Encourages “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 programming”
XP Testing
•
•
All unit tests are executed daily
“Acceptance tests” are defined by the customer and
executed to assess customer visible functionality
Badariah Solemon 2010
The Extreme Programming
(XP): An Analysis
Ask the students to analyze this process model
and to discuss their findings in class.
Badariah Solemon 2010
Selecting a Process
Model
• Analyze the sidebars in pages 45 and 47.
• What are the lesson-learned from these sidebars?
Badariah Solemon 2010
Selecting a Process
Model
• Factors to consider:
1. The characteristics of the problems to be solved.
•
•
Such as complexity of the problem, etc
E.g.: simple with clear, stable requirements, complex with changing,
unstable requirements, etc.
2. The characteristics of the project
•
•
Such as the customers who have requested the product and the people
who will do the work, etc.
E.g.: Uncertain requirements, breakthrough technology
3. The characteristics of the product.
•
Such as quality attributes or metric of the product, product domain, etc
4. The project environment in which the software team
works
•
Such as political, cultural, language ,etc.
Badariah Solemon 2010
Key Questions in
Determining Task Set
• Different projects requires different task sets.
The tasks should be selected based on
problems and project characteristics.
• Q: What actions are appropriate for a
framework activity, given:
the nature of the problem to be solved;
the characteristics of the people doing the work; and
the stakeholders of the project?
• Q: What work tasks (task set) that these actions
should encompasses of?
Badariah Solemon 2010
Example
• Nature of the problems and project :
A small software project requested by one person
(at a remote location) with simple, straightforward
requirements.
• Actions:
Communication action: develop requirements
• Task set:
Make contact with stakeholder via telephone.
Discuss requirements and take notes.
Organize notes into a brief written statement of
requirements.
Badariah Solemon 2010
Process Management
Tools
• Also known as process modeling tools or process
technology.
• Allows a team to define and manage the elements of a
process model (activities, actions, task, work products,
milestones, and QA points/filters).
• Such tools also provide detailed guidance on the content
of each process element.
• The tools may also provide standard project
management tasks such as estimating, scheduling,
tracking and control.
• Example:
• Igrafx Process Tools (www.micrografx.com)
Badariah Solemon 2010
Selecting a Process
Model: an Exercise
• The project:
Assume that you are in charge of a project to create a
portal for the Shah Alam district of Selangor state. This
portal would include a homepage with links to a wide range
of discounted travel packages to major destinations in
Selangor, links to certain featured places like golf courses,
shopping complexes and places to eat, links to the detailed
map of Selangor, and links to news and events listing. It
also includes a bulletin board and chat room feature where
tourists (international and local tourists) can exchange
information. The portal should also provide Automated
Teller Machine (ATM) locator, timezone converter, and
currency converter.
•Select a software process model that you
Solemon 2010
would recommend to be implementedBadariah
in the
Summary
• There are four types of process flows – linear, iterative,
evolutionary, and parallel.
• Software process patterns may suggest one or more proven
solutions to the problem from other projects, which can be
reused in another project.
• There are several process assessment and improvements
frameworks that can be exercised by practitioners.
• The analyses of prescriptive and specialized software
process models would help you select the most appropriate
process model for a software development project, which
can be proceeded with the identification of task set for the
project.
Badariah Solemon 2010
References and credit
Contents in the slides are adapted from the book and
the slides that accompanied the book by R.S.
Pressman, Software Engineering: A Practitioner’s
Approach, 7th. Edition, McGraw Hill, 2009.
Badariah Solemon 2010
