exampledevplantemplate.doc

8/16/2019 ExampleDevPlanTemplate.doc

1/9

CA305 Project & Process Management

Sample Contents: "SW Development Plan" template

1. Introduction

2. Project organisation

3. Managerial process

4. Software engineering process

5. Work packages (WPs! sc"edule and #udget

$ppendi% $& Work package 'and ain acti)it*+ descriptions

,. -eplatespecific con)entions / notes 0 M for actual projects

1. Angle brackets < … > contain material that must be replace b! project"speci#ic

ata. $or emphasis% this material is sometimes in bold italics.

2. ole s'uare brackets [ … ] elimit te(t that ma! or ma! not be applicable%

epening on project. A pair o# separators ) | is use to ienti#! alternati*e +orings%epening on project nees.

3. ,uielines are italicised an% in part% ma! be paraphrase #or speci#ic projects.

4. -itle page an heaers & #ooters/ must be replace b! the appropriate project

speci#ics.

312334.oc Page o# 1


2/9


1. Introduction

1.1 Project overview

Self explanatory; keep fairly brief.

1.2 Project deliverables and milestones

List the deliverables in a table ordered by work package, each deliverable being

associated with a work package.

List the major project milestones – each milestone should usually coincide with

starting or ending a work package.

1.3 Evolution of SDP

State at which points it is planned to issue the S! during the course of the project and outline what will be new to each issue. For example , for a standard waterfall

se"uence, one could have

Issu

e

When issued Outline

# !re S$ phase %utline plan for whole project – identified tasks are probably

based mainly on re"uirements at this stage.

!rovide &at least rough' estimates of cost and schedule.

Specify in detail the S$ phase activities.

( )n S$ phase $efine plan for whole project * tasks may be based on S+

components &e.g. classes' at this stage. !rovide more precise estimates of cost and schedule.

Specify in detail the phase activities.

)n - phase Should include a work breakdown structure &+S' directly

related to S+ components.

/stimate cost and schedule accurately.

)nclude a planning network showing interrelationships between

coding, testing and integration.

0 )n phase $efine 1 update the +S as work progresses.

etail project activities until final acceptance.

$efine the job schedule.where S$ 2 S+ re"uirements, - 2 -rchitectural or high level design, and 2

detailed design and production.

1.4 Reference materials

1.5 Definitions & acronms

Self*explanatory.

312334.oc Page 2 o# 1


3/9


2. Project organisation

2.1 Process model

3he organisation4s 5uality 6anagement System &56S' provides overview and detailed guidelines of the processes involved in any software project, and should be

consulted in defining the process model of the current project.

)n addition, the high*level, general process model presented in 7igure (.#*# &from

8!roject management for information systems9, :eates 1 adle, #


4/9


Figure 2.11: ! general proess mo#el $ma%or #elivera&les'results s(o)n in *allouts+,

312334.oc Page 6 o# 1

7nitialclient

contact

8eceipto# 7--

& bi

process

Contractnegotiation

$inalise an!subcontracts

Monitor bi

process

Projectstart"up

i ebrie#

an re*ie+

9e*el"

opment

9eli*er!to site

:iteinstall"

ation

:iteaccept

"ance

:ub/s!stem

commission

Custom"er take"

o*er

7n"ser*iceli*e running

arrant!support an

mainten"

ance

;nhance"ment an

#uture

e*elop"ment

9ocumentation prouction

9ata ac'uisition

an take"on

:ta## training

#amiliarisation

:ite sur*e!s an

re arationProject plan :9P/=ualit! plan :=AP/Project organisation

Project aministration

8e'uirements speci#ication

-echnical speci#ication9etaile & moule esign

Protot!ping

& : moules

Moules!stem integration:!stem testing

$actor! acceptance

7ntegration +ith other s!stems

Actual ata an operationControlle conitions


5/9


3. Managerial process

3.1 %ana"ement objectives & $riorities - self explanatory

3.2 ssum$tions' de$endencies & constraints - self explanatory

3.3 Ris( mana"ement

3o help identify risks, use following &not necessarily complete' checklist?

No. Potential area of risk

# !roven business case@ 7unding approved@ $ight type of contract

( -reas of contract ill*defined or not agreed@

ustomer? sufficient access@ effective decision making procedures@

0 Bser committed@ 5uality 1 stability of user re"uirements

C -cceptance criteria specified in contract@= Level of definition 1 stability of external interfaces

D -de"uacy 1 availability of resources including team members.

E -vailability 1 "uality of tools.

< 3eam member training 1 experience AAAA efinition of responsibilities

#F Short time scales. $apid build*up of staff re"uired. %ver*optimistic planning.

## 3echnical novelty of the project. 3echnical complexity of the system.

#( emanding performance, reliability, availability, maintainability re"uirements

# >ew development environment. 6is*match between development and target

#0 ought*in items

Table 3.3-1 !hecklist for potential risk identification

!rovide an assessment of risk– for example, use as a basis for comparison, a risk map

such as 7igure .*#. /ach identified risk is assigned to a cell of the map?

"ikelihood of occurrence-# $i%h &edium "o'

Potential

scale of

impact

"ar%e

&oderate

(mall

Fi%ure 3.3-1 )isk map template

!rovide a plan for reducing any identified risks.

3.4 %onitorin" and controllin" mec)anisms

• State how progress towards reaching project objectives will be measured ...

• State how difference, for both resource and schedule, between planned and actual

GexpenditureG will be analysed &for example by 8earned value analysis9'.

• State fre"uency 1 content of project status reports &to give visibility on progress'.

• State how project reviews will be prepared for and organised...

3.5 Staffin" $lan * more detail t)an section 2.4

312334.oc Page 5 o# 1


6/9


4. Software engineering process

4.1 Standards' met)ods' tools and tec)ni+ues

-s relevant to specific project needs?

• )dentify standards, including

S+ re"uirement standards

S+ design standards &e.g. B6L as tailored to companyHs needs'

S+ code standards

Standards for test cases, procedures and results &probably in Software

Ierification 1 3est !lan &SI3!''

• efine the selected methods and tools

S+ re"uirements methods 1 tools &e.g. tool for B6L'

S+ design methods 1 tools &e.g. tool for B6L' !rogramming language&s', coding tools, compilers, linkers, loaders ...

J+ platforms for tools

Summarise how use of project standards, methods and tools will be monitored and

enforced &maybe refer to SI3!, for example, for planned reviews and inspections'.

4.2 Project su$$ort functions

$efer to separate Software onfiguration 6anagement !lan &S6!' for software

configuration management.

$efer to separate Software Ierification 1 3est !lan &SI3!' for organisation and

planning of software verification, including but not limited to testing.

$efer to separate Software 5uality -ssurance !lan &S5-!' for software "uality

assurance activities.

,4.3 %ana"ement of reusable software $roducts-

3wo aspects are distinguishable.

• )ncorporate reusable S+ products

)dentify &Scope of search@ List already known@'

/valuate &riteria@' )ncorporate &Jow@'

• evelop reusable S+ products &cf !omponents in earlier lectures'

)dentify opportunities

/valuate opportunities

$eport opportunities

,4.4 andlin" of critical re+uirements-

)f relevant, state any special measures for re"uirements designated as critical, such as

re"uirements for assurance of safety, security or privacy.

312334.oc Page ? o# 1


7/9


5. Work packages (WPs! sc"edule and #udget

5.1 /or( brea(down structure 0/S' wor( $ac(a"es and tas(s

5.1.0 Work breakdown structure (WBS)

3he level of detail should be commensurate with the project siKe.

-he #ollo+ing +ork breako+n structure $igure 5..0"/ has been establishe #or the

P8@;C-.

WPs -ain !tivities as/s

1. 0 Name

. ame>

etc .. ame>etc

2. 0 Name

2. ame>

etc 2.. ame>

etc

n. 0 Name

n. ame>

etc n.. ame>etc

Figure .1.1: Pro%et Wor/ rea/#o)n Struture

-he #ollo+ing sections pro*ie o*er*ie+s o# each +ork package. 9etaile +ork

package [an main acti*it!] escriptions are pro*ie in Appeni( A.

5.1.1 WP1


8/9

CA305 Project & Process Managementidentified in the +S of section C.#.F. 3he estimates should be accumulated for each

main activity, work package and the overall project.

WPs -ain !tivities as/s 5a&our

$person #a6s,

7t(er osts

$monetar6,1. 0 Name

. ame>

etc .. ame>

etc

2. 0 Name

2. ame>

etc 2.. ame>

etc

n. 0 Name

n. ame>etc n.. ame>

etc

8S9-!8D P7;8C 7!5Sa&le .31: Summar6 o< re=uire# resoures

Note on estimation?

asic approach?

• reak work into 8small9 tasks, then estimate time and cost for each task. 7inally

estimate whole project by accumulating or synthesing the individual task estimates.

• )t is wise to base estimates on valid past experience.• )n addition, other approaches may be sometimes useful such as

* prototyping

* cost models &e.g. %%6%, function points'.

-s indicated in section #. of this template, refined estimates can be documented in

later versions of the S! corresponding to more detailed versions of the +S.

5.4 ud"et and resource allocation

Show how resources are allocated over the project lifetime, broken down as necessary

into work packages or lower level activities. an be presented in tabular form andAor

using one or more figures &such as histograms'.

5.5 Sc)edule

efine the project schedule &preferably using a bar*chart or antt chart', identifying

the dates of the major milestones, deliverables, external inputs to the project &and any

other external dependencies', the duration of each workpackage broken down, to

sufficient resolution, to activities and tasks.

312334.oc Page o# 1


9/9


$ppendi% $& Work package 'and ain acti)it*+ descriptions

omplete, as necessary, work package descriptions &+!s' &or similar' for work

packages and major activities. -s a minimum include a +! for each work package.

- sample blank +! form is as follows?

W7> P!C>!?8 D8SC9P97@ $WPD, F7-P7;8C:W7> P!C>!?8

itle: e

exampledevplantemplate.doc

Documents