Software Engineering-II (CS605) Assignment No.

5
Assignment No. 5: Project planning
Subject: Software
Engineering-II
Assigned: 18-12-200 Assignment Marks: !0
Instructor: "S05 #eam Due Date: 2-12-200 Attached Files: Non
Objective:
1- #$e o%jecti&e of t$is assignment is to 'e&elop s(ills a%o)t project planning an'
trac(ing.
Instructions:
1- #$is is an in'i&i')al assignment. *o) will s)%mit +o)r wor( in'i&i')all+ t$ro)g$ +o)r logins.
2- ,rite +o)r name an' roll n)m%er at t$e start of t$e assignment.
!- -o not cop+ an' paste an+ t$ing from t$e internet. *o)r wor( m)st %e original.
.- Please note t$at +o) m)st 'o +o)r own wor(. If an+ one fo)n' cop+ing from anot$er
st)'ent/ no mar(s will %e gi&en to $im0 $er.
5- -ea'line for t$is assignment is 2t$ -ecem%er/ 200. #$is 'ea'line will not %e e1ten'e'.
- No assignment is accepte' t$ro)g$ email %efore an' after t$e ')e 'ate.
2- If +o) feel an+ pro%lem/ feel free to mail at "S053&).e').p(.
Case Study:
Background:
Project management can be described as te acti!it" of bringing a## $artici$ants from
witin a de$artment to s%ccessf%##" com$#ete a $rod%ct de#i!erab#e. Iterati!e $#anning and
trac&ing are tecni'%es %sed b" some $roject managers to a!oid a!ing to coose
between red%cing te n%mber of feat%res or e(tending te sced%#e.
Abstract
Project management can be described as te acti!it" of bringing a## $artici$ants from
witin a de$artment to s%ccessf%##" com$#ete a $rod%ct de#i!erab#e. Iterati!e $#anning and
trac&ing are tecni'%es %sed b" some $roject managers to a!oid a!ing to coose
between red%cing te n%mber of feat%res or e(tending te sced%#e.
Introduction
)eca%se software is e$emera#* software $rojects are fre'%ent#" diffic%#t to $#an* trac&*
and assess. Iterati!e $roject management tecni'%es e#$ ma&e te obsc%re c#earer.
+ost s%ccessf%# $roject managers &now ow to set %$ a $roject $#an. ,e" &now wat te
standard mi#estones or e!ents for te $roject need to be (-.Conne##* /006)* and te" $#an
te $roject according#". ,e" $#an te sced%#e according to a s$ecific critica# $at
(genera##" tas&s). +cConne## (+cConne##* /006) and oters a!e sown tat once a
$roject as missed a mi#estone* te $roject.s staff cannot 1ma&e %$1 te time. Project
managers ma" face te coice between e(tending te sced%#e and dro$$ing te feat%res.
,e management $art of $roject management is re'%ired to manage te sced%#e and
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan /
Software Engineering-II (CS605) Assignment No. 5
inc#%de te feat%res.
,ere is an a#ternati!e to te b#ind coice of e(tending te sced%#e or dro$$ing feat%res.
As a $roject manager* if "o% can 1c%n&1 te feat%res* and gi!e "o%rse#f s%fficient
f#e(ibi#it" in #earning abo%t te feat%res and $roject sced%#ing* ten "o% can redirect te
critica# $at* and sti## ma&e te sced%#e wit te $#anned feat%res. ,is metod of
de!e#o$ing a n%mber of sma## inde$endent feat%res* and fre'%ent re$#anning is iterati!e
$roject management.
,is $a$er $resents an iterati!e $roject sced%#ing tecni'%e togeter wit two e(am$#e
re#eases from an organi6ation.
Initial Project Planning
Senior management fre'%ent#" fi(es te si$ dates wito%t a good &now#edge of te
feat%res to be $rod%ced. Nat%ra##"* te engineers decr" tis as a terrib#e* awf%# ting.
P#anning and e($ecting to com$#ete#" meet a fi(ed sced%#e $roject wito%t ade'%ate
feat%re &now#edge is tr%#" is a terrib#e* awf%# ting. 7or e(am$#e* imagine tis scenario.
8an* te $roject manager* as j%st ta#&ed to senior management. "Those **&&** just did
it to me again. They told me to ship this next release in 4 months. Our competition just
announced availability in 8 months. No e need to announce availability in less than !
months. "e don#t even $no hat it#s going to ta$e to design this %eature& never mind
implement it ithin this architecture. 'o the hec$ can ( sell this to the engineers) "hat
am ( going to tell my project team) They#re going to $ill me* or hat#s orse& they#ll all
al$ out. 'o could senior management do this to us) +on#t they $no hat it#s li$e to
develop so%tare)"
It.s not tat senior management is bad or st%$id. Commercia# com$anies a!e significant
mar&et forces tat ma" $re!ent tem from f%##" %nderstanding wat te" are re'%esting
of te $rod%ct de!e#o$ers. +ar&et forces dri!e com$anies to ma&e coices before te
com$an" is rea##" read" to do so. Iterati!e $roject $#anning a##ows a com$an" to get
started on a $roject wen on#" te major iss%es of te feat%re set are %nderstood* b%t te
si$ dates are set in stone.
Critical Paths
,ere are m%#ti$#e critica# $ats in a gi!en $roject. ,e tas&#ist generates a $artic%#ar
critica# $at. ,e $eo$#e wor&ing on te $roject create anoter critica# $at. And* ard
reso%rce a!ai#abi#it" creates "et anoter critica# $at. ,e tr%e $roject critica# $at is te
critica# $at tro%g a## tree !iews9 tas&s* $eo$#e* and reso%rces.
8%ring te initia# $#anning $ase of man" $rojects* te tas&s and e!ents are $#anned* and
wit an" #%c&* te tas& critica# $at emerges. +an" $roject managers are a#so aware tat
$eo$#e and ard reso%rces (i.e. macines* networ&s* etc.) a!e an im$act on te critica#
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan :
Software Engineering-II (CS605) Assignment No. 5
$at* and te" $#an for %sing tese scarce reso%rces a$$ro$riate#".(;o#dratt* /00<)
In a $roject were te $roject manager and te tecnica# staff do not a!e s%fficient
&now#edge of te f%## feat%re set %nder de!e#o$ment* a traditiona# a$$roac does not
g%arantee s%ccess. ,e traditiona# a$$roac ass%mes te $roject manager &nows and
%nderstands te critica# $ats of tas&s* $eo$#e* and reso%rces. In a #ess-f%##" s$ecified
$roject* it is %n#i&e#" tat te $roject manager wi## &now a## te critica# $ats. ,e $roject
manager wi## $robab#" be s%r$rised b" new tas&s tat arise* %nforeseen tas&s* or new
e($ertise ma" a!e to be de!e#o$ed* and new reso%rces ma" be re'%ired.
=en $roject &now#edge is im$erfect an iterati!e a$$roac is more s%ccessf%#9
1. Plan the major milestones. Estimate the feature freeze, code freeze,
system test freeze, beta ship and product ship dates. Determine the criteria
by which the project staff can agree that these milestones have occurred.
2. Plan each segment of the project as it crystallizes, staying at least four
wees ahead of the current state.
!. "s each project segment completes, the project manager and technical
staff have a better understanding of the project and the eventual product,
so more complete planning can tae place. #y the time the project has
reached the feature freeze milestone, the tass re$uired to get to code
freeze are well understood. #y the time code freeze is reached, the rest of
schedule can be laid out and planned.
,is iterati!e a$$roac red%ces %ncertaint" for te c%rrent $roject wor&* and a##ows
re$#anning of te critica# $at at a n%mber of $oints in te $roject.
Milestone Definitions
,is set of mi#estones is %sef%# for defining software $roject sced%#es9
Milestone Criteria
7eat%re free6e
,e date wen a## re'%ired feat%res are &nown
and te detai#ed design as %nco!ered no more.
No more feat%res are inserted into te $rod%ct.
Code free6e
Im$#ementation of te design as sto$$ed.
Some testing of te feat%res as occ%rred.
S"stem test free6e
Integration testing is com$#ete. Code free6e for
s"stem test to start.
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan >
Software Engineering-II (CS605) Assignment No. 5
)eta si$
,e date te )eta software si$s to )eta
c%stomers
Prod%ct si$
,e date te $rod%ct si$s to te genera#
c%stomer base
7or sma## $rojects* tere ma" be on#" one of eac free6e and )eta si$. 7or #arger or more
com$#e( $rojects* f%nctiona#it" ma" be gro%$ed so tat $art of te $rod%ct is read" for
code free6e wi#e $art of te $rod%ct as sti## not met feat%re free6e.
Milestone Planning and Criteria
Effecti!e $roject managers and software engineers %nderstand tat a genera# a$$roac of
1. %e$uirements planning
2. &eature definition 'leading to feature freeze(
!. Design and implementation 'leading to code freeze(
). *erification and *alidation 'leading to ship(
is a time-effecti!e and cost-effecti!e wa" to im$#ement a $roject. In addition* ear#" and
often re!iews and ins$ections wi## red%ce $roject time (;i#b* /00>). Project managers
fo##owing tis tecni'%e can get a better and#e on te mi#estones of feat%re free6e* code
free6e* s"stem test* beta free6e* and si$ free6e.
In an iterati!e#" $#anned $roject* it is critica# tat te $roject team agrees on wat eac
mi#estone means. ,e $roject manager de$ends on acc%rate information abo%t te c%rrent
state of tas&s from te $roject team. ?ow can te $roject be s%ccessf%# if te $roject
manager and team do not %nderstand wat te mi#estones mean@
,o %se te iterati!e $#anning tecni'%e* te $roject manager $#ans te major mi#estones
(e.g. feat%re free6e* code free6e* s"stem test* beta free6e* and si$ free6e)* and ten
iterates on te wor& between te mi#estones.
(Re)Planning the Next Project Phase
E!en for an iterati!e#"-$#anned $roject* some tas&s are c#ear#" defined in eac $ase. 7or
e(am$#e* if a forma# beta test is $#anned* ten a## te $re-beta tas&s need to be com$#eted
before beta can start. ,ese tas&s can and so%#d be $#anned in te initia# $roject
sced%#e. An" tas&s tat can be $#anned in ad!ance so%#d be $#anned.
-ne of te benefits of not doing detai#ed $#anning of te ne(t major $ase is tat te
$roject can ad!ance more '%ic&#". Some $eo$#e are intimidated b" a #arge sced%#e wit
man" tas&s (+ag%ire* /00A). Eiter te" tin& te" can.t $ossib#" ma&e an" $rogress* or
te" fig%re since tere are so man" tas&s* if teir tas& s#i$s* it.s not a big dea#. ?owe!er*
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan A
Software Engineering-II (CS605) Assignment No. 5
an" tas& s#i$$age diminises te abi#it" to re$#an te rest of te $roject. If te $roject
manager sows $eo$#e a $roject $#an wit #ess detai#* and contin%a##" as&s tem for more
detai#* te" are more moti!ated to com$#ete teir tas&s. +" e($erience as been tat
$eo$#e are an(io%s to com$#ete teir wor&* and get te ne(t batc of wor&. =en tere is
%ge tas& #ist of e!er"ting tat needs to be done* $eo$#e get bogged down.
)" $#anning te c%rrent $ase in detai#* and grad%a##" increasing te detai# on te ne(t
$roject $ase* $eo$#e can see ow $rogress is being made* and te" come %$ wit
$ossibi#ities te $roject manager ma" a!e missed to acce#erate te $roject.
In a fi(ed-si$ sced%#e* te $roject manager is a#wa"s #oo&ing for wa"s to ad!ance te
$roject. A## too often in traditiona##" $#anned $rojects* $roject ad!ances (tas&s finising
ear#") are wasted (;o#dratt* /00<). ,e reasons for tis are te fo##owing9
1. +here is no rush to start this tas, so the tas owner starts at the last
minute. ',oldratt calls this -.tudent .yndrome-, waiting until the last
possible minute to start the assignment.(
2. /hen people multitas between different tass, they waste time changing
conte0t between tass. '.ee 'De1arco, 1234(, '/einberg, 122)(, and
'/einberg, 1224( for an e0cellent e0planations about the damages of
conte0t switching on effective wor.(
!. Dependencies between steps can waste all advances, if the dependencies
between steps and resources are not uncovered and planned for before the
tass are started.
In an iterati!e#" $#anned $roject* no one $erson as a %ge #ist of tas&s* so #ac& of
$rogress is more !isib#e. Since tere are fewer tas&s* tere is incenti!e to start eac tas&
as '%ic&#" as $ossib#e* so tat forward $rogress can be re$orted.
A fi(ed-sced%#e $roject as a dee$ sense of %rgenc"* so te $roject manager can red%ce
te re'%ests for and effects of m%#ti-$roject m%#titas&ing. 5sing an iterati!e $#anning
a$$roac* te sced%#e becomes more and more detai#ed o!er time. ,e de$endencies are
%nco!ered ear#"* and re$#anning can occ%r wen more de$endencies are %nco!ered.
Replanning
3e$#anning is necessar" wen tere is a $roject ad!ance or de#a". Project de#a"s
$ro$agate to #ater $roject ste$s (;o#dratt* /00<). ,ime can ne!er made %$* on#" $#ans can
cange.
In traditiona# com$#ete#"-$#anned $rojects* tere are on#" two a#ternati!es to $roject
de#a"s (=einberg* /00A)9
1. %educe the number of features
2. .lip the schedule
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan 5
Software Engineering-II (CS605) Assignment No. 5
If "o% %nderstand $recise#" wat it wi## ta&e to com$#ete te feat%res* and "o% %nderstand
te c%rrent $roject state* tere are no oter a#ternati!es. ,e reason is tat te $roject
critica# $at is fi(ed.
Shifting the Critical Path
In a #ess we##-defined $roject* owe!er* tere are a#ternati!es. 7or e(am$#e* if "o%
%nderstand te c%rrent critica# $at b" tas& and $erson $erforming tat tas&* tere ma" be
an a#ternati!e to wo $erforms te tas& at wat time.
If te critica# $at cannot be sifted* ten te $roject manager on#" as te two coices
abo!e- red%cing feat%res or s#i$$ing sced%#e.
xa!ple
,is is two e(am$#es of iterati!e $roject $#anning and trac&ing wit a sma## gro%$
de!e#o$ing a midd#eware comm%nications a$$#ication. 7or te $%r$oses of tis
disc%ssion* we wi## ca## te $rod%ct 1+essenger1. In tis case* senior management did not
f%##" %nderstand feat%res* and te si$ dates were fi(ed.
,e origina# $roject mi#estone dates were9
/B/5B06
Com$#ete re'%irements (feat%re
free6e)
>B>/B06 Code free6e
AB/5B06 )eta si$
5B/5B06 Prod%ct si$
)" >B/5B06* te $roject was in tis state9
/. ,e $roject manager ad not written a $roject $#an (te $rose defining te feat%res*
a$$roac* and re#ease criteria).
:. 7eat%re free6e ad not occ%rred. ,wo of te tree major feat%res for te re#ease ad not
been ade'%ate#" defined tecnica##".
>. A tas& #ist e(isted* b%t man" tas&s were defined as tree to fo%r wee&s d%ration. In
rea#it"* te $roject team was s#i$$ing abo%t a wee& e!er" two ca#endar wee&s. ,e
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan 6
Software Engineering-II (CS605) Assignment No. 5
origina# tas& #ist on#" ad abo%t a do6en more tas&s tan te e(cer$t abo!e.
,e tecnica# staff were wor&ing on wat te" to%gt was im$ortant to do* b%t it t%rned
o%t te" were not wor&ing on te $roject.s critica# $at. ,e" were wor&ing on wate!er
was interesting to tem* and on c%stomer $rob#ems (3otman* /00<).
)" A$ri# /* it was c#ear tat a mid-+a" $rod%ct si$ date was not going to be $ossib#e.
,e origina# $roject manager was re$#aced in A$ri# /006 b" a more e($erienced manager
wo ten wor&ed wit te tecnica# staff to create a new $roject $#an.
,e first $roject sced%#e from te second $roject manager #oo&ed #i&e tis9
AB5B06 7eat%re 7ree6e
AB/:B06 Code 7ree6e
AB/CB06 S"stem test free6e
AB::B06 Start S"stem test. Start beta test.
6B/AB06 Prod%ct Si$
,e new %nder#"ing tas& #ist ad s%bstantia# detai# for te feat%re free6e and code free6e
mi#estones. ,ere was #itt#e detai# $ast te 1Start S"stem test1 mi#estone. ,ere was !er"
#itt#e detai# in te beta test $ase* $rimari#" beca%se 7eat%re 7ree6e ad not been met "et.
?owe!er* te major mi#estones* and some of te s$ecifics of te end game
(man%fact%ring dates* etc.) were s$ecified* beca%se te" were &nown* and teir
de$endencies were %nderstood. ,e $#an was to get to te S"stem test free6e date. If te
s"stem test entr" and beta entr" criteria co%#d be met* te rest of te sced%#e co%#d be
$#anned. ,e $roject team %nderstood tat teir first $riorit" was to get te software
feat%res im$#emented and stab#e.
=itin two wee&s* b" AB/5B06* it was ob!io%s tat beta test was not going to start on
AB::B06. ,ese tings a$$ened9
• .enior management and the project manager discussed the promises made
about this product release to the customers and the press. +he e0ternal
promises were for -.econd $uarter 1225-, rather than a hard date.
• +he customers were willing to tae beta software that had not been
through system test.
• .enior management understood that the project was about three months
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan <
Software Engineering-II (CS605) Assignment No. 5
late.
,ese rea#i6ations a##owed te rea# re$#anning to start. In mid-A$ri#* not a## te feat%res
were f%##" designed. ,e $roject team wor&ed wit te $roject manager to determine
wat wo%#d define te feat%re free6e* and came to (not '%ite b#ood") agreement.
In mid-+a"* te mi#estones were9
AB>0B06 7eat%re 7ree6e
5B/B06
Code 7ree6e* start s"stem test. Start initia# beta test
,ere was incredib#e detai# in te $roject tas& #ists*
itemi6ing wic testing was to be done wen* so tat
$eo$#e and macines were not waiting on one
anoter.
<B//B06 7ina# code (and doc%mentation) free6e.
<B/:B06 Prod%ct Si$
At te A$ri# $roject assessment* based on te $rogress and c%rrent s#i$ rate* it was not
c#ear tat te $roject co%#d com$#ete before A%g%st. In D%#"* senior management was
o!erjo"ed tat te $roject was #ess tan tree f%## monts #ate. ,e c%stomers were
tri##ed. ,e" ad ne!er recei!ed a +essenger re#ease tis c#ose to on time* wit as few
defects as tis re#ease ad.
,e origina# missed time co%#d not be made %$* b%t iterati!e $#anning was %sef%# for
containing te $roject s#i$s.
,is same $roject team ten started anoter $roject wit initia# dates9
0B>B06 7eat%re 7ree6e
/0B<B06 Code 7ree6e* Start s"stem test
//B/AB06 )eta free6e* Start beta test
/:B/AB06
7ina# code (and doc%mentation)
free6e.
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan C
Software Engineering-II (CS605) Assignment No. 5
/:B>/B06 Prod%ct Si$
In tis case* tere was s%bstantia# tas& #ist detai# for te feat%re free6e and $art of te code
free6e mi#estones. ,ere were no tecnica# tas&s #isted for te rest of te sced%#e. )" te
time te team acie!ed eac s%ccessi!e mi#estone* te $#anning for te fo##owing
mi#estone was com$#ete.
8%ring te im$#ementation $ase (0B>B06-/0B<B06)* a major $rob#em was %nco!ered. ,e
origina# design for a $artic%#ar feat%re co%#d not be im$#emented in te defined time. So*
te re$#anning acti!it" defined tas&s for starting a $artia# s"stem test in tandem wit te
com$#etion of te feat%re. ,e mi#estone #ist now #oo&ed #i&e tis9
0B>B06 7eat%re 7ree6e
/0B<B06
Partia# code 7ree6e* Start $artia# s"stem
test
//B/B06 7ina# code free6e* start f%## s"stem test
//B/AB06 )eta free6e* Start beta test
/:B/AB06 7ina# code (and doc%mentation) free6e.
/:B>/B06 Prod%ct Si$
,e diffic%#t feat%re was not dro$$ed* nor was te o!era## $roject sced%#e s#i$$ed. ,e
s"stem arcitect and feat%re designer s$ent m%c time redesigning and $rotot"$ing te
feat%re. ,at (origina##" %n$#anned) wor& $roceeded in $ara##e# wit te s"stem testing.
,e tas&s %nderneat te #isted mi#estones canged aro%nd to accommodate te
additiona# wor& on te feat%re.
Senior management and +essenger.s c%stomers were asto%nded tat te initia# si$ date
was met. In addition* beca%se e!er"one agreed to a$$ro$riate si$ criteria* te $rod%ct
ad !er" few c%stomer-!isib#e defects
Dear Student, this article is about Iterative Software Project planning and
Tracking with two examples.
1. Question: You are required to read it with full
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan 0
Software Engineering-II (CS605) Assignment No. 5
concentration and summarize this in your own
words with at least one real world example
(excluding these two) satisfying this article
2 Co$" 3igt 4irt%a# 5ni!ersit" of Pa&istan /0