Agile System Implementation Guidelines

8/9/2019 Agile System Implementation Guidelines

1/58

DHS Office of Systems and Technology


2/58

Guideline Document for:

Agile System Implementation


3/58

Department of Human Services

Office of Systems and Technology

Agile System Implementation Guidelines

SECTION 1: PLANNING AGILE

PROJECTS ....................................................................................

5

1.1

Establish and Utilize a Single P!d"#t

$a#%l!g ............................................................................................

5

1.&

Re#!''ended Uni("e Re("ie'ent

Pi!ities ..........................................................................................

5

1.)

Size

Esti'ati!n ...............................................................................................................

............................

5

1.*

+"n#ti!n P!int

Esti'ate ..................................................................................................................

...........

,

1.5

S-ste' R!ad'a: Initial Plan !/

0!% .......................................................................................................

,


4/58

SECTION &: SSTE2 2ANAGE2ENT AN3 ENGINEERING

APPROAC4 ..............................

&.1

3e6ned P!7e#t Engineeing

Stateg- .........................................................................................................

8

&.&

S#"' 2anage'ent

A!a#h ...................................................................................................................

8

2.2.1

Planning and Executing the Four Week Engineering Sprints .....................................................................

9

2.2.1.1 Sprint Planning Part

1 ............................................................................................................................

9

2.2.1.2 Sprint Planning Part

2 ..........................................................................................................................

10

2.2.1.2.1 FEATUE TEA! SP"#T $A%&'()S * $U#+,(W#

%-ATS .......................................................

10

2.2.1.

Sprint %harters .....................................................................................................................................

10


5/58

2.2.1./ ,ail Stand+up Scru

!eetings ...........................................................................................................

11

2.2.1.

Sprint e3ie4 !eetings .......................................................................................................................

11

2.2.1.5

Sprint User Acceptance ........................................................................................................................

11

2.2.1.6

etrospecti3es ....................................................................................................................................

.

12

2.2.1.6.1 FEATUE TEA! SP"#T

ET(SPE%T"7ES.....................................................................................

12

2.2.1.6.2

S('UT"(# ET(SPE%T"7ES .........................................................................................................

12

2.2.1.8

Pre+Sprint Preparation .........................................................................................................................

12

2.2.2

)raphical ,epiction o Planned Sprint %cle ...........................................................................................

12


6/58

&.)

Sint 1: P!7e#t Stat"

A#ti9ities ............................................................................................................

1&

&.*

S!l"ti!n EngineeingA!a#h ................................................................................................................

1)

2./.1

%ollecti3e (4nership o the Solution ......................................................................................................

1

2./.2

Sprint Execution User 7alidation .............................................................................................................

1

2./.

Training !aterial Production ...................................................................................................................

1/

2././

%ontinuous "ntegration ............................................................................................................................

1/

2././.1 Sot4are $uilds: %ode

%opilation .....................................................................................................

1/

2././.1.1

S(FTWAE 7ES"(# %(#T(' .....................................................................................................

1

2././.1.2 ,E,"%ATE, $U"', !A%-"#E;SE7E * %(#T"#U(US "#TE)AT"(#

SE7E ...........................

1


7/58

2././.1.

AUT(!ATE, $U"',S .....................................................................................................................

1

2././.1./

P"7ATE ,E7E'(PE $U"',S .........................................................................................................

1

2././.1.

FAST;ase "ntegration ........................................................................................................

1

2././.2.1 7ES"(# %(#T(''E, ,ATA ,EF"#"T"(# 'A#)UA)E ?,,'@

S%"PTS .........................................

1

2././.2.2

AUT(!ATE, ,ATA$ASE "#TE)AT"(# ........................................................................................

15

2././.2. ,ATA$ASE A,!"#"STAT"(# A#,

TU#"#) .................................................................................

15

2././. Test ,ri3en ,e3elopent * %ontinuous

Testing .................................................................................


8/58

15

AR DHS Agile System Implementation Guidelines v0_!"doc#

$age %


9/58




2././..1

AUT(!ATE, U#"T TEST"#) ..........................................................................................................

15

2././..2 !A"#TA"#"#) ($UST U#"T

TESTS ..............................................................................................

15

2././.. %EAT"(# A#, !A"#TE#A#%E (F TEST

,ATA .............................................................................

15

2././../ U#"T TEST"#) F( ",E#T"F"E,

,EFE%TS .......................................................................................

16

2././.. AUT(!ATE, ,ATA %(#7ES"(# TEST"#) ..................................................................................

16

2./././ %ode "nspection and

e3ie4 ................................................................................................................

16


10/58

2./././.1 AUT(!ATE, %(,E 7E"F"%AT"(#: %(,"#)

STA#,A,S ............................................................

16

2./././.2

!A#A)"#) %(,E %(7EA)E .......................................................................................................

18

2./././. E'"!"#AT"(# (F ,UP'"%ATE

%(,E ..............................................................................................

18

2././.

,ocuentation

%opilation ...............................................................................................................

18

2././..1 AUT(!ATE, AP" %(!P"'AT"(#: %(,E

SPE%"F"%AT"(#S .............................................................

18

2././..2 AUT(!AT"% %EAT"(# (F A S('UT"(# ,ATA

,"%T"(#A= ........................................................

18

2././..

P(,U%T ,AS-$(A, PU$'"S-"#) ............................................................................................

18

2./.

Periodic Autoated En3ironental

eresh ...........................................................................................

19


11/58

2./..1 Autoated En3ironental eresh Approach and

Strateg ...............................................................

19

2./..2

Teporar En3ironental

Archi3e ......................................................................................................

19

2./.. eesta>lish $ase sste

%onguration ...............................................................................................

19

2./../

%ode

!igration ....................................................................................................................................

19

2./..

Structural ,ata>ase

!odications ......................................................................................................

20

2./..5

%onguration ,ata

'oad ......................................................................................................................

20

2./..6 'oading o Test

,ata ............................................................................................................................

20


12/58

2./..8

Shake+do4n

Testing .............................................................................................................................

20

2./.5

"ntegration Test and egression Test ......................................................................................................

20

2./.5.1

7erication.....................................................................................................................................

......

21

2./.6

Pair

Prograing .................................................................................................................................

...

21

2./.8

,esign

Approach ......................................................................................................................................

21

2./.8.1

%onguration 3s.

%ustoiBation ..........................................................................................................

21

2./.9

,ata>ase

%ustoiBation ..........................................................................................................................

21

2./.10

Solution

eactoring ................................................................................................................................


13/58

22

2./.10.1

'oad and Perorance

Testing ........................................................................................................

22

&.5

Ee#"ting a P!d"#ti!n Release

Sint .....................................................................................................

&&

2..1

elease

Planning ......................................................................................................................................

2

2..1.1

elease Sprint

StaCng .........................................................................................................................

2

2..2

Planning End+User

Training......................................................................................................................

2

2..

Stakeholder "n3ol3eent and

%ounication .......................................................................................

2/

2../

Technical

"pleentation .......................................................................................................................

2/

2..

'oad and Perorance

Testing ................................................................................................................


14/58

2/

2..5

Foral User e3alidation *

Acceptance .................................................................................................

2/

2..6

Execution o ,ata %on3ersion in

Production ...........................................................................................

2/

SECTION ): SUPPORT

PROCESSES ...........................................................................................

...

&5

).1

C!ntin"!"s P!#ess

I'!9e'ent ............................................................................................................

&5

).&

P!7e#t C!n6g"ati!n

2anage'ent .........................................................................................................

&5

).)

Ris% and Iss"es

2anage'ent ................................................................................................................

...

&5

..1%ontingenc

Planning ..............................................................................................................................

25

AR DHS Agile System Implementation Guidelines v0_!"doc#


15/58

$age !


16/58




).*

Ass"'ti!n and C!nstaint

2anage'ent ................................................................................................

&;

).5

Pe/!'an#e

2eti#s ...................................................................................................................

.............

&,

..1

Scope * Schedule

!anageent ..............................................................................................................

26

..1.1 Function Point Earn

ate .....................................................................................................................

28

..1.2 -ours per FunctionPoint .....................................................................................................................

29

..2

Tea Perorance

!etrics .....................................................................................................................

0


17/58

..2.1 Planned 3s. Actual Feature Tea 7elocit >

"teration .......................................................................

0

..2.2 Actual Feature Tea !e>er 7elocit >"teration ...........................................................................

1

..2.

eaining Product

$acklog .................................................................................................................

2

..


18/58

Failed

$uilds .........................................................................................................................................

...

Failed En3ironentalereshes ..........................................................................................................

5

).;

End Use

Taining ..................................................................................................................

...................

),

).,

Sta%eh!lde In9!l9e'ent and C!''"ni#ati!ns

2anage'ent .................................................................

),

SECTION *:

PERSONNEL .....................................................................................

............................

)

*.1

AGILE PROJECT

ORGANI


19/58

/.1.

AEA P(,U%T

(W#ES ........................................................................................................................

/0

/.1./

!ASTE S%U!!ASTE ........................................................................................................................

/1

/.1.

S%U!

!ASTES .....................................................................................................................................

/1

4.2

+EATURE

TEA2S ...................................................................................................................

....................

*&

/.2.1

FEATUE TEA! A!P+

UP .......................................................................................................................

/2

SECTION 5:

PROJECT +ACILITIES AN3

RESOURCES ..............................................................

*)


20/58

AR DHS Agile System Implementation Guidelines v0_!"doc# $age &


21/58




Section 1: Planning Agile Projects

$lanning an Agile soft'are development pro(ect is similar in many 'ays to planning pro(ects that use

alternative system implementation lifecycles" The main difference )et'een the t'o approaches is that agile

pro(ects consider initial plans to )e estimates of the 'or* that 'ill )e accomplished and not final

commitments that fully descri)e every activity that 'ill )e completed+ the e#act effort the activity 'ill ta*e+

and the e#act dates in 'hich it 'ill happen" In other 'ords Agile approaches are more agile and fle#i)le+

and that fle#i)ility )egins during the planning process" Agile soft'are development approaches also focus

on addressing the most important and most challenging components of the pro(ect as early as possi)le to

reduce ris*, this is accomplished through the use of uni-ue priorities for each story.re-uirement"

1.1 Estalish and !tili"e a Single Product #ac$log

The most important asset that is developed and regularly evolved on an Agile pro(ect is the $roduct /ac*log"

The )ac*log+ as the name suggests+ is a )ac*log of 'or* that must )e completed in delivering the intended

system and functionality to end users" ach pro(ect should have one+ and only one+ product )ac*log file" $ro(ect

teams should use the esta)lished )ac*log template as a starting point for their specific pro(ect.product )ac*log+

DHS_T$00_Re-uirements_$roduct_/ac*log 1see https2..ardhs"sharepointsite"net.guidelines.Shared

3%0Documents.T$00_Re-uirements_$roduct_/ac*lo g"#ls#4"

The assigned $roduct O'ner should meet 'ith )usiness users to esta)lish the initial version of the

pro(ect.product )ac*log and esta)lish an overall vision for the solution" 5ote that the )ac*log 'ill change

and gro' 'ith the pro(ect as additional tas*s are identified and added+ so the intent of the initial )ac*log is

to esta)lish a good enough understand to )e a)le to estimate the amount of time and resources needed to

complete the pro(ect successfully"

1.% &ecommended !ni'ue &e'uirement Priorities


22/58

Teams must indicate the uni-ue priority.importance of each re-uirement in the )ac*log" 5ote that the

assigned uni-ue importance must )e a uni-ue num)er" Teams should determine 'hat scale 'ill )e used

for priorities 1e"g" from to 5+ 'here 5 is ten times the total num)er of re-uirements in the $roduct

/ac*log4 for each and every re-uirement included in the $roduct /ac*log" In the e#ample provided+

priorities 'ould )e assigned in increments of 0, this readily ena)les the team to insert ne' re-uirement

priorities )et'een e#isting re-uirements as the pro(ect progresses" If the team )elieves that alternative

approaches 'ould )e more effective 1)ased on past e#periences4 they are free to use these practices

once the pro(ect is under'ay and opportunities for improvement are identified during the Sprint

retrospective meetings"

The teams initial priorities 'ill serve as the initial starting point for the $roduct O'ner to esta)lish overall

priorities for the solution during pro(ect startup 1see section &""% $ro(ect O65R for information a)out the

$roduct O'ners role4" The assigned priorities are also e#pected to heavily influence the proposed

development roadmap defined in section "7 System Roadmap2 Initial $lan of 6or* and the 8themes9 of

each resulting Sprint"

1.( Si"e Estimation

During the initial planning stages the team is also re-uired to assign each re-uirement a si:e estimate for

all re-uirements" DHS uses a generic si:e unit+ such as ;Story $oints


23/58




5ote that DHS does not intend to use or control pro(ects 'ith the a)ove mentioned generic si:e estimates,

the si:e estimates are used for planning Sprints+ specifically ho' much scope it is )elieved can )e

addressed 'ithin each Sprint and are 5OT considered commitments"

Teams should also define 'hich si:ing metric 'ould )e most )eneficial to use on a given pro(ect,

specifically the use of Ideal Days versus an ar)itrary generic si:e unit or perhaps even using =unction

$oints directly" The approach should )e a simple mechanism to use on the pro(ect for all staff that -uic*ly

and effectively ena)le the trac*ing of soft'are engineering tas*s"

Size Component

Project Definition and Guidance About Size

0- Zero


24/58

1

-Very Tiny

2

Tiny

!

- A"mo#t Tiny


25/58

$

- Very Sma""

%

Sma""

1!

&edium

21

'ar(e


26/58

!)

- Very 'ar(e

$$

*u(e

%+

&a##i,e


27/58

1)) eed more


28/58

AR DHS Agile System Implementation Guidelines v0_!"doc# $age ?


29/58




1.) *unction Point Estimate

/efore )eing approved )y DHS+ all candidate Agile system implementation pro(ects are re-uired to

estimate the si:e of the pro(ect in =unction $oints" The =unction $oint estimate does not have to )e tied toindividual re-uirements in the initial $roduct /ac*log+ though it is e#pected that the planning team 'ill use

the re-uirements during the estimation" /ecause many of DHS9 pro(ect are re-uired to trac* and cost

allocate funds across various =ederally funded programs+ teams may )e re-uired to provide a =unction

$oint stimates for sets of re-uirements for the included program areas 1e"g" @edicaid and S5A$4" DHS

'ill use the total supplied =unction $oint estimate as an o)ligation.commitment governing the amount of

functionality delivered on the pro(ect"

.,era"" /unction Point #timate for So"ution

Area 1 /unction Point #timate

Area 2 /unction Point #timate

1.+ System &oadma,: -nitial Plan of or$

During pro(ect planning+ pro(ect teams should create a detailed roadmap that includes a high>level list of

activities that are e#pected to )e completed during the pro(ect" $ro(ect teams should use DHS9 standard


30/58

roadmap template+ T$00_Agile_$ro(ect_Roadmap_Template"ppt# 1see

https2..ardhs"sharepointsite"net.guidelines.Shared3%0Documents.T$00%_Agile_$ro(ect_Roadmap_Temp

late"ppt#4 'hen constructing their roadmap" The roadmap should include the initial identified.desired

soft'are releases+ as 'ell as the intended theme of each Sprint in the pro(ect"

Sprint themes on the roadmap 'ill li*ely correlate 'ith the eventual Sprint goal and identify the prioriti:ed

features that are aligned 'ith each Sprint in a 'ay that addresses )oth )usiness priorities and the greatest

ris* early in the pro(ect"


31/58

AR DHS Agile System Implementation Guidelines v0_!"doc# $age


32/58




Section %: System /anagement and Engineering

A,,roach

DHS9 preferred approach to ne' system development pro(ect is an Agile approach )ased on Scrum and

#treme $rogramming practices" 6ith this approach and industry>standard practices+ teams are a)le to

iteratively evolve soft'are solutions 'hile addressing the highest ris* components early" 1See the follo'ing

diagram for an illustration of DHS9 approach4" $ro(ect teams are free to e#plore alternative Agile

approaches 1e"g" Brystal Blear and Cnified $rocess4 and to enhance the Agile approach sho'n )elo'+

ho'ever pro(ect teams must clearly demonstrate the (ustification for and )enefit to )efore any alternative

approach is categorically approved for use"


33/58


34/58



35/58




%.1 Defined Project Engineering Strategy

/efore starting a system development pro(ect+ pro(ect teams should define a pro(ect engineering strategy

and descri)e ho' the strategy can )e used to deliver the intended solution and meet stated goals andneeds associated 'ith the pro(ect" A *ey component of the defined engineering strategy should include the

definitions of 8done9 at three 1!4 different levels2

The definition of done at the solution level is used to determine 'hen the system is finished and meets

DHS9 intended need1s4

The definition of done at a Sprint level indicates 'hen a Sprint goal is achieved 1see section %"%" $lanning

and #ecuting the =our 6ee* ngineering Sprints4,

The definition of done for the various coding related activities such as development+ data conversion+

training material creation+ and interface development"

Scrum /anagement A,,roach

As a general practice+ DHS understands and respects the Agile and Scrum principles of self>organi:ing

teams and shared o'nership of the pro(ect processes and results for their pro(ect" During pro(ect planning+

the pro(ect team pro(ect team provides details of the pro(ect management and pro(ect control methods that

they intend to use" The intent of these details is not to identify fi#ed processes and approaches for the

pro(ect+ )ut rather to identify practices that the pro(ect team )elieves are 'ell suited for the pro(ect" In other

'ords+ the details are considered to )e initial conventions that teams may use over the first fe' iterations+

and once the pro(ect is under'ay+ identify and implement process improvements throughout the pro(ect"


36/58

Planning and Executing the Four Week Engineering Sprints

In using the Scrum system+ a good practice and approach is using four 'ee* engineering Sprint.iterations"

During pro(ect planning+ the pro(ect team should define the initial Sprint duration and configuration that 'ill

)e used to manage the development activities" This guideline document provides an initial standard and

structure for ho' a Sprint cycle should )e e#ecuted"

As a general guideline+ a good approach is one that efficiently and effectively integrates the system in a

timely fashion" $ro(ect teams are encouraged to 'or* colla)oratively 'ith DHS management and involved

sta*eholders+ throughout the pro(ect to a esta)lish pro(ect approach that is )est suited to meeting the

specified needs of the pro(ect champion.sponsor"

Sprint Planning Part 1

In $art of Sprint planning+ the $ro(ect O'ner 1and Area $roduct O'ners on large pro(ects4+ e#ecutive

management and users meet 'ith representatives from each of the =eature Teams and the Scrum @asters

to esta)lish a goal for the Sprint" These meetings are also used to identify 'hat functionality 'ill )e )uilt in

the coming Sprint"

The part Sprint planning meeting lasts no more than & hours and during the meeting+ )usiness priorities

are discussed and then contrasted against the priorities in the $roduct /ac*log" If necessary the )ac*log

priorities may )e changed to reflect ne' information or changes in )usiness priorities" As the top priorities

are selected for inclusion in the scope of the =eature Teams Sprints+ careful attention is paid to the si:e of

'or* )eing ta*en )y each team in light of the teams9 corresponding velocity 1for more information a)out

=eature Team velocity see section %"%""! Sprint Bharters4"

It is important to note that+ for large pro(ects 'ith multiple =eature Teams+ the representatives from each

=eature Team are fully authori:ed and responsi)le for the assignment of 'or* to their associated team" At

the end of the part planning+ the =eature Team is fully committed to delivering the 'or* they have agreed

to ta*e on" Additionally+ as a good practice+ DHS uses an approach that openly allo's all =eature

AR DHS Agile System Implementation Guidelines v0_!"doc# $age E


37/58




Team mem)ers the opportunity to participate as the team representative in the part planning meeting

over a period of time" The esta)lishment of a rotating schedule of the team representative1s4 is a good

practice for accomplishing this"

During pro(ect planning+ the pro(ect team defines the accepted convention for ho' =eature Team mem)ers

are identified to attend the part planning meeting and ho' the teams 'ill maintain shared commitment

for the selected scope" Other conventions a)out ho' the part planning meeting 1such as 'hen in the

Sprint cycle2 )eginning or end4 is conducted should also )e noted" Teams should also consider ho' the

Sprint planning meeting can )e structured and managed to prevent overrunning the allocated & hour

duration"

Sprint Planning Part 2

The second part of planning for a Sprint involves the individual =eature Teams meeting and discussing the

'or* it committed to complete and ho' it intends to )uild the functionality into a product increment during

the Sprint" =or large multi>team pro(ects+ Area $roduct O'ners should )e availa)le to assist the =eature

Team in the detailed planning of their Sprint activities+ ho'ever the Area $roduct @anagers may )e

re-uired to split her.his time across multiple =eature Teams and hence may not )e availa)le to a specific

=eature Team for the full duration of the part % planning meeting" As 'ith the first Sprint planning meeting+

the second planning meeting lasts no more than four hours"

During pro(ect planning+ the team decides ho' they 'ill conduct the second part of the Sprint planning

meeting 'hile recogni:ing that self>organi:ing teams may alter those practices at a future time"

FEATURE TEAM SPRINT BACKLOGS & BURN-DON C!ARTS

The main output of the part % planning meeting is the Sprint /ac*log+ 'hich includes the tas*s the =eature

Team 'ill complete in )uilding the re-uired features+ estimates of the amount of time it 'ill ta*e to reali:e


38/58

those features 1prefera)ly in Ideal Days4 and a Sprint )urn>do'n chart template" The use of specific media

for the Sprint )ac*log items is specified )y each of self>organi:ed =eature Teams" Teams are encouraged

to use physical Sprint )ac*log media to trac* progress unless other specific practices are (ustified"

During pro(ect planning+ the pro(ect team should define ho' the )urn>do'n chart 'ill )e updated each day

and ho' records 'ill )e *ept to record the daily progress 1e"g" picture of the team )ac*log are ta*en and

electronically filed4" Additionally+ the pro(ect team should define ho' tas*s are identified and estimated and

ho' une#pected comple#ity is to )e handled"

As a general guideline+ each re-uirement should )e )ro*en do'n into smaller tas*s during the part %

planning meeting and during this decomposition each tas*s should )e assigned an Ideal Day estimate+

'hich is maintained throughout the Sprint+ )y the =eature Team"

Sprint C"art#r$

One of the main outputs of )oth of the Sprint planning meetings is a one page charter that indicates the

goal of the Sprint+ the dates for the )eginning and ending of the Sprint+ the time and location of the pro(ect

daily Scrum meeting as 'ell as dates+ times and locations for the Sprint Revie' meeting and the solution

retrospective meeting" =or large+ multi>team pro(ect+ the solution Sprint Bharter is made availa)le to all

sta*eholders interested in the pro(ect" Additionally+ the =eature Teams create au#iliary charters that include

relevant details a)out the scope of 'or* they have selected along 'ith relevant details a)out their teams

plans for the Sprint"

As a general guideline+ the =eature Team representatives )ring a partially completed team charter to thepart planning meeting" This partially completed charter includes the team9s targeted velocity 1in generic

si:e count4 and the =eature Team9s e#pected availa)ility over the Sprint 1e"g" accounting for *no'n

vacations and holidays4" 6hile the content of the charters may evolve over time+ pro(ect teams are

re-uired to use the esta)lished template+ T$00!_Sprint_Bharters_Template 1see

AR DHS Agile System Implementation Guidelines v0_!"doc# $age 0


39/58




https2..ardhs"sharepointsite"net.guidelines.Shared3%0Documents.T$00!_Sprint_Bharters_Template"doc #4+ at

the )eginning of the pro(ect"

Dail% Stan-'p S(r') M##ting$

=or large multi>team pro(ects+ Daily Scrum meetings are conducted at t'o levels each day, at the =eature

Team level for each team and at the nterprise level 'here representatives from each =eature Team

attend 'ith the $roduct O'ner and Area $roduct O'ners, small single team pro(ects only re-uire one Daily

Scrum meeting" Regardless of 'hich level the daily Scrum meeting is for+ it never lasts more than 7

minutes+ re-uires that all team mem)ers attend+ stand+ and provide ans'ers to the follo'ing ! -uestions2

6hat 'as completed since the last daily Scrum @eetingF

6hat 'ill )e finished )y the ne#t daily Stand>up @eetingF

6hat is preventing 'or* from )eing completedF

During pro(ect planning+ the pro(ect team defines ho' 'ill *eep the daily meetings under the 7 minute

limit+ ho' they 'ill handle non>=eature Team 1uninvited4 participation 1not attendance4+ and ho' they 'ill

schedule the =eature Team level meetings to facilitate a consolidated and accurate solution level meeting"

Sprint R#*i#+ M##ting$

Simply put+ the Sprint revie' meeting is a & hour demonstration of the ne' products and features that 'ere

)uilt during the latest & 'ee* Sprint" During the meeting representatives from the =eature Team1s4 present


40/58

the results of their 'or* to the $roduct O'ner+ Area $roduct O'ners+ management+ users and other

sta*eholders" The )ig>picture intent of the revie' meetings is to validate the solutions progress against

DHS needs and priorities and to mitigate pro(ect ris*"

$resenters at the revie' meeting should do as little as possi)le in preparation of the meeting, the meeting

is not intended to )e a polished presentation re-uiring additional pro(ect resources to prepare+ )ut rather a

functional vie' of the solution and its progress" During pro(ect planning+ the pro(ect team should define

ho' the meeting 'ill )e organi:ed+ ho' =eature Teams might identify presenters+ and ho' feed)ac* 'ill )e

collected"

As a general guideline+ DHS uses the revie' meetings as a sta*eholder involvement and communication

forum for many of the pro(ect sta*eholders" During pro(ect planning+ pro(ect teams should define ho' DHS

can involve the )roadest audience possi)le 1video conference+ 'e)inar+ etc"4 'hile completing the meeting

'ithin the four hour limit"

Sprint U$#r A((#ptan(#

Traditional Cser Acceptance Testing 1CAT4 is not readily possi)le 'hen using Agile pro(ect approaches" As

a result DHS has adopted a three pronged approach to addressing the need for formal acceptance of the

developed solution2

Sprint #ecution Cser alidation see section %"&"% Sprint #ecution Cser alidation"

Sprint Revie' Cser Acceptance 1this section4 at the end of each Sprint+ during the Sprint Revie'

@eeting+ DHS revie's and accepts the developed components presented in the revie'"

Release Sprint Cser Revalidation 'hile e#ecuting a Release Sprint 1see section %"7"? =ormal Cser

Revalidation Acceptance re-uirements4 DHS re-uires that Csers Revalidate the functionality that is

)eing released"

As a general guideline+ DHS provides acceptance of the developed features and components

demonstrated in the Sprint Revie' @eetings" All feed)ac* that re-uires a system change is incorporated



41/58




into the $roduct /ac*log for future Sprints" During pro(ect planning+ the pro(ect team should define ho' features

'ill )e demonstrated+ ho' feed)ac* 'ill )e collected and ho' acceptance 'ill )e documented"

R#tr,$p#(ti*#$

Retrospection is a *ey activity that drives continuous improvement during the pro(ect" During pro(ect

planning+ the pro(ect team should provide teams 'ith a )rief summary of techni-ues that they 'ill use

during retrospective meetings" Additionally pro(ect teams should define 'hen retrospective meetings are

conducted 'ithin the Sprint cycle" A recommended guideline is to conduct retrospective meetings at the

end of a Sprint )ecause any opportunities for improvement 'ill )e fresh in the teams9 minds" 5ote that for

large+ multi>=eature Team+ pro(ects retrospective meetings are conducted at t'o levels"

FEATURE TEAM SPRINT RETROSPECTIES

At the end of each iteration+ each =eature Team must conduct a retrospective meeting to inspect their

processes+ identify potential improvements+ assess any limitations and challenges faced )y the team+ and

determine solutions that potentially eliminate the challenges" During pro(ect planning+ the pro(ect team

should define ho' the =eature Teams 'ill conduct retrospectives+ 'hen they should )e conducted and any

particular approaches that might )e helpful 1e"g" Jai:en+ 7>6hys4"

SOLUTION RETROSPECTIES

In addition to the =eature Team retrospectives+ the DHS $ro(ect O'ner or @aster Scrum @aster 1for very

large pro(ects4 conduct a solution level retrospective 'ith the focus of improving operations and

efficiencies at the overall pro(ect level" A *ey input to the solution level retrospective is the challenges and

ideas from the =eature Team retrospectives" The enterprise retrospective meetings are also conducted

after the end of each Sprint and 'ill )e led )y the $roduct O'ner or designee and attended )y the Area

$roduct O'ners+ DHS management and other interested sta*eholders"


42/58

During pro(ect planning+ the pro(ect team must provide input and recommendations a)out ho' the solution

retrospective meetings should )e scheduled to ena)le input from the =eature Team retrospectives as 'ell

as more general recommendations a)out ho' DHS can implement enterprise improvement activities"

Pr#-Sprint Pr#parati,n

As a regular and on>going activity )efore each Sprint+ in anticipation of the Sprint planning meetings+ the

DHS $ro(ect O'ner assesses and updates the $roduct /ac*log to reflect current priorities+ recent

legislative changes or other e#ternal influences" These updates also include the closing out of

re-uirements that 'ere addressed in the previous Sprint as 'ell as updates to the $roduct /urn>do'n

Bhart"

Graphical Depiction of Planned Sprint Cycle

6ithin the Defined $ro(ect Strategy+ pro(ect teams should create a graphical depiction of the Sprint

cycle.timeline that 'ill )e used to meet DHS9 re-uirements" This graphic depiction should sho' ho'

activities conducted 'ithin each Sprint are laid out, it is not considered to )e a final+ rigid plan for each

Sprint+ )ut rather a visual aid to help pro(ect team mem)ers to understand the timing of events 'ithin the

Sprint"

%.( S,rint 1: Project Startu, Acti0ities

As part of their pro(ect planning efforts+ pro(ect teams should define the approach that 'ill )e used to

complete the installation+ configuration+ and start>up activities that are re-uired )y the pro(ect+ )ut not

currently in place" These activities usually include2

sta)lishment of the proposed technical environments

Installation and )ase configuration of any necessary soft'are pac*ages

AR DHS Agile System Implementation Guidelines v0_!"doc# $age %


43/58




Bonfiguration of the development toolsets 1i"e" ID+ testing tools+ see section %"&"& Bontinuous Integration4

sta)lishment of the pro(ect performance metric utilities 1section !"7 $erformance @etrics4

#ecuting Sprint $lanning 1parts and %4 for Sprint % 1%"% Scrum @anagement Approach4

sta)lishing pro(ect facilities and 'or*spaces 1if re-uired4

The plan for the pro(ect startup activities 'ithin Iteration should include a Sprint Bharter 1and Solution

Bharter for large pro(ects4 and a Sprint /ac*log" These materials accelerate the e#ecution of the e#ecution

activities for the first Sprint" The pro(ect team should also provide details a)out the tas*s that must )e

e#ecuted+ any constraints that are *no'n+ dependencies )et'een tas*s+ and the level of resourcing

re-uired to complete the 'or*"

=or all identified iteration tas*s+ the pro(ect team should insert re-uirements into the $roduct )ac*log at the

end of the list and assign uni-ue priorities that effectively convey that these tas*s must )e completed in the

first Sprint" =or e#ample+ the first Sprint may )e used to elicit Cser Stories.Re-uirements from )usiness

users for a given set of functions, the elicitation of re-uirements in each area may )e suita)le tas*s for the

Sprint product )ac*log"

%.) Solution Engineering A,,roach

In order to ma#imi:e efficiency+ minimi:e ris*+ and implement the desired solution in the shortest possi)le

time+ DHS ma*es heavy use of #treme $rogramming 1K$4 concepts" During pro(ect planning+ pro(ect

teams are encouraged to use additional.alternative techni-ues and methods that have )een proven to yield

effective results for soft'are engineering in the past"

In Agile terms+ the four 'ee* development iterations must produce a ;potentially shippa)le product


44/58

associated materials re-uired to implement that soft'are" It is important to note that the soft'are may

re-uire additional components to function in the production environment 1e"g" a user interface4 )ut the unit

component 1e"g" data)ase stored procedure4 is of production -uality"

Collectie !"nership of the Solution

It is imperative that everyone on the pro(ect+ from the most (unior team mem)er to the $ro(ect O'ner and

management+ to have a strong sense of collective o'nership for the successful implementation of the

desired solution 'ithin the defined schedule" This is reflected in the 8hori:ontal9 nature of the organi:ation

chart sho'n in section &" AGIL $ROMBT ORGA5INATIO5" During pro(ect planning+ the pro(ect team

should decide ho' they 'ill actively foster and maintain a culture of shared o'nership across the team and

'ith other pro(ect sta*eholders"

Sprint Execution #ser $alidation

DHS uses the concept of 8validation9 to ensure that the systems meet the intended needs+ or 8goodness of

fit9" Hence validation cannot )e completed 'ith automated testing+ at least initially" alidation must involve

su)(ect matter e#perts 1S@s4 'ho understand the nature of the intended solution" Through close

colla)oration during each Sprint+ the $ro(ect O'ner+ Area $roduct O'ners+ S@s+ and other participants

validate the evolving solution during each Sprint"

Traditionally+ validation is accomplished during Cser Acceptance Testing 1CAT4+ 'hich is not readily

possi)le 'hen using Agile concepts" As a result DHS has adopted a three pronged approach to addressing

the need for formal acceptance of the developed solution2

Sprint #ecution Cser alidation 1this section4" During the e#ecution of the Sprint+ the $ro(ect O'ner and

Area $roduct O'ners regularly provide input+ use and revie' the 'or* of the =eature Teams"

Sprint Revie' Cser Acceptance see section %"%""? Sprint Cser Acceptance

Release Sprint Cser Revalidation see %"7"? =ormal Cser Revalidation Acceptance

AR DHS Agile System Implementation Guidelines v0_!"doc# $age !


45/58




=or an Agile approach to )e successful+ fre-uent and regular interaction must ta*e place )et'een the

=eature Teams and Su)(ect @atter #perts 1S@s4" As a result of this interaction+ the =eature Teams gain

heightened insight a)out the re-uired solution and lo'ers ris* associated 'ith the delivery of the right

solution" Due to the nature of the feed)ac* and S@ interactions+ the =eature Teams use their (udgment

)ased on the scope of the feed)ac*, for feed)ac* 'ith small resulting changes the team assesses ho' to

incorporate the change 'ithin the e#isting Sprint, for larger changes that cannot )e accommodated in theSprint the =eature Team 'or*s 'ith the $ro(ect O'ner and Area $roduct O'ner to communicate that an

additional tas* 1or tas*s4 needs to )e added to the $roduct /ac*log"

During pro(ect planning+ the pro(ect team should discuss ho' features 'ill )e demonstrated+ ho' feed)ac*

'ill )e collected+ and ho' validation 'ill )e trac*ed to ma*e sure that all ne' components receive user

scrutiny"

As a general guideline+ the $ro(ect O'ners and Area $roduce O'ners regularly engage sta*eholders

e#ternal to the pro(ect to use features and components developed in the Sprint+ and past Sprints+ to

validate that the solution fits its intended need"

A )est practice for user validation involves recording user interactions 'ith the system in an automated

manner that ena)les 8play)ac*9 of the user actions" During pro(ect planning+ the pro(ect team should

discuss ho' this information 'ill )e captured+ managed throughout the pro(ect+ and used 1played )ac*4 to

facilitate Cser Revalidation during Release Sprints 1see %"7"? =ormal Cser Revalidation Acceptance for

more details4"

%raining &aterial Production

$ro(ect teams should use engineering approaches that incorporate the development of training materials

seamlessly into each Sprint" In other 'ords+ =eature Teams should )e staffed 'ith people 'ho have s*ills

necessary for the development of training materials" $ro(ect teams should also give thought to the type of

type of training material1s4 that 'ill )e developed and ho' those materials are integrated into the soft'are

solution 1e"g" on>screen help+ training manuals and video tutorials such as ouTu)e4"


46/58

Continuous Integration

DHS mandates and verifies that all pro(ect teams ma*e full use of Bontinuous Integration 1BI4 from the

)eginning of the pro(ect through the end of the pro(ect" During pro(ect planning+ pro(ect teams should

define an approach to implementing continuous integration practices on the pro(ect including the

fre-uency and proposed times 'hen integration cycles 'ill )e e#ecuted 1e"g" 0 A@ and % $@ each

)usiness day, full regression each Saturday at $@4" The pro(ect team should also include a discussion

of the tools 1e"g" BI tool+ )uild tool+ version control and others4 that are re-uired to implement the proposed

approach"

6here possi)le+ DHS uses freely availa)le+ open>source tools for e#ecuting a continuous integration

strategy" 6henever a pro(ect team identifies soft'are tools that do not include a license free of charge+ the

pro(ect team must clearly (ustify 'hy the tool is needed and 'hy a similarly>featured free of cost tool

cannot )e used and re-uest the purchase of the tool through the DHS Office of Systems and Technology

1OST4"

S,.t+ar# B'il$/ C,# C,)pilati,n

Ideally+ system code should )e compiled at least three times daily 1t'ice during normal )usiness hours

and once overnight4" As a general good practice+ DHS also encourages more fre-uent compilations" Doing

so ena)les the rapid detection of defects and issues 'ith the code )ase that can rapidly )e resolved

)ecause the events that triggered the corresponding error 'ould still )e fresh in the pro(ect team9s

memory" During pro(ect planning+ the pro(ect team should define their approach to code compilation+including any tools that 'ill )e used"

AR DHS Agile System Implementation Guidelines v0_!"doc# $age &


47/58




SOFTARE ERSION CONTROL

During pro(ect planning+ pro(ect teams should define their approach and toolset that 'ill )e used to

maintain control of versions of soft'are" /ecause a single program.file may )e modified )y multiple people

simultaneously 1shared solution responsi)ility4 it is important that the proposed tool )e capa)le of

reconciling multiple changes as the solution progresses" It is re-uired that ALL code )e chec*ed in every

day )efore the end of the day"

2000102 DEDICATED BUILD MAC!INESERER & CONTINUOUS INTEGRATION SERER

During pro(ect planning+ pro(ect teams should define ho' )uilds 'ill )e created+ specifically focusing on

hard'are and net'or* resources" As a general good practice+ )uild cycles must )e completed as rapidly as

possi)le+ and in most cases e#ecuted in a fe' minutes" $ro(ect teams should also determine the

configuration of the )uild server and any specific re-uirements of such a machine that ena)le rapid )uild

cycles"

As a general guideline+ a )uild server 'ill+ under normal circumstances+ not re-uire any unusual hard'are

or configurations, in most cases a developer 'or*station can satisfy the re-uirements of a )uild server"

AUTOMATED BUILDS

During pro(ect planning+ pro(ect teams should esta)lish their )uild cycle+ the events that are triggered+ the

order of the events+ dependencies and e#ceptions handling"

PRIATE DEELOPER BUILDS


48/58

As a general guideline+ continuous integration process and+ more specifically+ the regular solution )uilds+

should )e uneventful processes on the pro(ect" One effective means to accomplish this goal is to mandate

that all developers conduct a local )uild 'ith modified code prior to chec*ing their modified solutions into

the common repository"

During pro(ect planning+ pro(ect teams define ho' their pro(ect approach addresses this re-uirement as

'ell as 'hat e#pectations are included for private developer )uilds"

FAST3UICK BUILD C4CLES

/uild cycles should e#ecute rapidly in order to provide timely feed)ac*" $ro(ect teams should descri)e the

conventions that 'ill )e esta)lished on the pro(ect to )alance the speed of the )uild cycle and associated

feed)ac* against the need to provide ade-uate coverage of tests during the cycle" $ro(ect teams should

continually see* 'ays to refine the )alance )et'een useful inspection and rapid )uilds should the pro(ect

team e#perience longer than accepta)le )uild times"

C,ntin','$ Data5a$# Int#grati,n

As 'ith the continuous integration of soft'are code )ased products+ DHS mandates that data)ases

technologies )e continually integrated 'ith soft'are solutions" Bontinuous data)ase integration ena)les

pro(ect teams to esta)lish a solid foundational domain model 'ith 'hich to )uild application layers" Doing

so reduces the ris* of defects associated 'ith multiple layers of the system from ta*ing heightened effort to

trou)le shoot and resolve" Additionally+ continuous data)ase integration accelerates testing as the

application and associated data model are esta)lished in a 'ell>defined and *no'n state"

ERSION CONTROLLED DATA DEFINITION LANGUAGE 6DDL7 SCRIPTS

Any development resource should )e a)le to create or modify data)ase components 'ithin the system"

The modifications and definition of data)ase components must )e accomplished 'ith DDL scripts that are

to )e included in the version control repository" sta)lishing this practice on the pro(ect ena)les the

Bontinuous Integration process to 'ipe and esta)lish re-uired data)ase structures from scratch in a *no'n

sta)le state"

AR DHS Agile System Implementation Guidelines v0_!"doc# $age 7


49/58




AUTOMATED DATABASE INTEGRATION

The Bontinuous Integration process used )y the pro(ect team must have the capa)ility to automatically create

and refresh data)ases" /ecause data)ase solutions are integral components of the overall solution+ it is critical

to esta)lish practices that mitigate the ris* of esta)lishing a fragile data)ase platform"

DATABASE ADMINISTRATION AND TUNING

DHS re-uires DDL and D@L scripts that are created and managed along 'ith the solution code" As a

result+ it is possi)le for D/A>type resources to periodically revie' and tune the data)ase construction

scripts" This also ena)les this activity to )e conducted 'ith little or no impacts to =eature Teams 'ho are

e#ecuting 'or* on the solution"

During pro(ect planning+ pro(ect teams should define ho' they 'ill plan for and ena)le *no'ledgea)le

individuals 'ith e#perience tuning data)ases to tune the system to improve performance and the solutions

capa)ilities"

T#$t Dri*#n D#*#l,p)#nt & C,ntin','$ T#$ting

The soft'are engineering approach used )y DHS is heavily dependent on continuous integration and test

driven development as ris* mitigation mechanisms" $ro(ect teams must define ho' they integrate test

driven development concepts and ho' tests are conceptuali:ed and associated 'ith Sprint )ac*log items"

The pro(ect teams should also determine 'hat tools 'ould help to automate the unit testing process and

should also define the strategy.architecture of the unit testing approach"

AUTOMATED UNIT TESTING


50/58

/ecause the regular+ multi>daily )uild>and>test cycle must e#ecute -uic*ly+ the pro(ect team must esta)lish

sets of tests that vary in scope and comple#ity that e#ercise the system differently depending on the

availa)le time" In other 'ords+ that automated tests run during )usiness hours are relatively small+ )ut

those that run each night are more comprehensive in nature" $ro(ect teams should use an approach that

ena)les unit tests of the system to )e performed at various levels" During pro(ect planning+ pro(ect teams

should descri)e such tiers of tests 'ill )e esta)lished+ configured and maintained over time as the System

evolves"

MAINTAINING ROBUST UNIT TESTS

Systems often re-uire thousands of unit tests to )e run )y the completion of the pro(ect" 6ith this in mind+ it

is important to esta)lish an architecture for the unit tests in aggregate to prevent them from )ecoming

8fragile9 over time" =or e#ample+ hard coding a future date into a unit test ma*es the test sensitive to the

current date and at some point in the future the test results 'ill change 'hen the current date passes the

hard coded date" $ro(ect teams should give thought to defining ho' to ma*e the unit testing approach

maintain a ro)ust testing system that avoids fragile tests" $ro(ect teams should also define ho' the unit

tests 'ill )e com)ined in se-uence to form testing scenarios"

CREATION AND MAINTENANCE OF TEST DATA

As the system evolves+ it )ecomes increasingly important to esta)lish test data that maintains integrity

across the application 1e"g" esta)lishment of client demographics associated 'ith a client ID that is

referenced throughout the system4" One 'ay to esta)lish this data is the use of Structured Puery

Language 1SPL4 scripts to populate data directly into the data)ase on the )ac* end" During pro(ect

planning+ the pro(ect team defines ho' referent+ high integrity test data 'ill )e created and maintained in

the application in a manner that ena)les -uic*+ fre-uent+ and prefera)ly automated+ environmental

refreshes"

AR DHS Agile System Implementation Guidelines v0_!"doc# $age ?


51/58




UNIT TESTING FOR IDENTIFIED DEFECTS

It is inevita)le that defects 'ill )e in(ected into the system as part of the engineering cycle" 6hile

unavoida)le during initial in(ection+ it is possi)le to prevent future occurrences of the defect )y esta)lishing

tests that verify the defect condition does not reoccur" As a general guideline+ DHS re-uires that all

detected defects )e covered )y unit tests that detect any future instance of the defect"

AUTOMATED DATA CONERSION TESTING

The conversion of data from e#isting applications into the system is included in the scope of Sprints as

necessary )ased on selected Sprint scope" 6ithin this in mind+ during pro(ect planning+ pro(ect teams

should define an approach to converting data from e#isting systems into the target.ne' system+ 'hat tools

'ill )e used to facilitate the conversion 1e"g" #tract>Transform>Load 1TL4 tool4+ ho' errors and

discrepancies 'ill )e resolved+ and ho' the process 'ill )e integrated into the continuous integration cycle

and environmental refreshes"

DHS ma*es production data availa)le to the team to test data conversion routines and processes on an as>

needed )asis" During pro(ect planning+ pro(ect teams should define+ in detail+ ho' they 'ill identify the need

for production data+ ho' they 'ill 'or* 'ith other DHS staff to o)tain the data+ ho' the data 'ill )e stored

to protect confidentiality+ ho' the data 'ill )e used+ and ho' often the data is e#pected to )e refreshed

1e"g" ne' data pulled at the end of each Sprint and made availa)le )efore the )eginning of the ne#t4" As a

general practice+ the pro(ect team should identify specific individuals 'ho are authori:ed to access

production systems+ there)y ena)ling her.him to e#tract sensitive production data that are made availa)le

to teams to construct and test data conversion programs"

DHS is interested in innovative approaches to the integration of data conversion activities into the soft'are

engineering approach" $ro(ect teams are encouraged to identify practices and recommendations that are

)elieved to )e relevant and potentially )eneficial for DHS9 to use" Additionally+ due to the sensitive nature of

production data+ pro(ect teams must also identify 'ays that mandatory HI$AA re-uirements can )e met and

ho' the pro(ect team 'ill help *eep the data secure from unauthori:ed access"


52/58

6hile structuring the team+ pro(ect planners must not identify a single 8Bonversion =eature Team9 for the

pro(ect" In the spirit of Agile soft'are development practices each =eature Team should have s*ills and

competencies availa)le to address all re-uired conversion activities 'ithin a Sprint"

C,# In$p#(ti,n an R#*i#+

$ro(ect teams regularly and aggressively revie' and inspect code 'or* products )eing created on the

pro(ect to maintain a high degree of technical -uality" DHS appreciates highly efficient Agile engineering

teams and understands that the results of this high performance e-uates to a large volume of solution

code" Therefore+ it is al'ays necessary to esta)lish automated and continuous practices to ensure that

esta)lished standards are )eing met to avoid unnecessary technical comple#ity and reduced efficiency"

AUTOMATED CODE ERIFICATION/ CODING STANDARDS

During pro(ect planning+ the pro(ect team must identify the coding conventions that 'ill )e used on the

pro(ect as 'ell as the toolset that 'ill )e used to verify the code against esta)lished standards" If the

pro(ect team needs to modify the system9s e#isting coding standards+ the team must e#plain the rationale

for the change and ho' the ne' coding standards 'ill )e enforced in tandem 'ith pre>e#isting system

standards" The team should also e#plain ho' deviations from the esta)lished standard 'ill )e resolved )y

pro(ect teams and ho' the standards are modified and maintained 'ithin the selected toolset"

The process of automated code verification against the esta)lished standard must )e fully integrated intothe continuous integration cycle"



53/58




MANAGING CODE COERAGE

During pro(ect planning+ the pro(ect team defines 'ays use automated unit testing to ensure that ade-uate

testing coverage of the soft'are solution" The pro(ect team should also descri)e the tools that 'ill )e used

to monitor testing coverage" It is important for the pro(ect team to provide a thorough description of the

overall philosophy )ehind managing testing code coverage+ 'hat percentage of code coverage is targeted+

and ho' deviations from that target 'ill )e addressed"

ELIMINATION OF DUPLICATE CODE

During pro(ect planning+ the pro(ect team should define ho' the code 'ill )e assessed and revie'ed to

identify duplicate or redundant code or code components" DHS understands that large>scale code sets

inevita)ly contain duplication of code structures and that this duplication must )e managed to preserve the

overall solution -uality" The pro(ect team should define 'hat tools 'ill )e used to revie' code for

duplication and ho' the revie' 'ill )e integrated into the regular engineering activities+ including the BI

cycle"

D,(')#ntati,n C,)pilati,n

DHS )elieves that a self>documenting solution is the )est mechanism through 'hich to create solution

documentation"

During pro(ect planning+ the pro(ect team should define ho' solution documentation 'ill )e compiled+

stored+ and pu)lished 'ithin the continuous integration cycle" Specifically+ the team should descri)e ho'

often the documentation 'ill )e compiled and 'hat specifically 'ill )e compiled" The team should define

the toolset that 'ill )e used to create and pu)lish the documentation"


54/58

At a minimum+ DHS re-uires the automated generation of2

A system Application $rogramming Interface 1A$I4

A data dictionary that fully descri)es data models that are implemented 'ith systems and

AUTOMATED API COMPILATION/ CODE SPECIFICATIONS

Test Driven Development process is e#ecuted shortly )efore a set of activities dedicated to specifying and

coding of soft'are" In other 'ords the specifications are developed at the same time the code is developed

to satisfy esta)lished automated unit tests"

During pro(ect planning+ the pro(ect teams define the proposed approach for automatically generating high

-uality A$I code specifications" The pro(ect teams should also discuss any toolsets that 'ill )e used to

generate the specifications and ho' these specifications 'ill )e integrated into the system9s integrated

li)rary"

AUTOMATIC CREATION OF A SOLUTION DATA DICTIONAR4

During pro(ect planning+ the pro(ect team should define ho' a data dictionary 'ill )e automatically created )y the

system" As a general practices+ DHS prefers a dictionary that ma*es use of HT@L technologies"

PRODUCT DAS!BOARD PUBLIS!ING

At the completion of each BI cycle+ a dash)oard summari:ing the results of the various activities is

created" The dash)oard is visually appealing and easily naviga)le to facilitate e#ecutive DHS management

in understanding the technical status of the solution" During pro(ect planning+ the pro(ect team should

identify dash)oards that 'ill )e used" In addition+ the pro(ect team should indicate desired and

recommended approaches for communicating the status of the technical solution to interestedsta*eholders"


55/58



56/58




Periodic Automated Enironmental 'efresh

DHS continually see*s to esta)lish development and test related environments that are regularly

automatically reconstructed 'ith fresh versions of the solution+ configuration data+ and test data" The intentof the regular refresh is to avoid un*no'n or undocumented+ )ut re-uired+ configurations that may lead to

issues and slo' development progress" As a result of the previous point+ DHS does not use a )ac*up or

disaster recovery mechanism to satisfy this re-uirement as this approach still leads to un*no'n and

misunderstood configurations"

Ideally+ an environment refresh 'ould involve the automated esta)lishment of a fully functional version of

the system from a clean+ )ase system image" During pro(ect planning+ pro(ect teams should descri)e ho'

to accomplish a fully automatic refresh of all proposed environments from the )ase configuration to a

specified version.)aseline of the system" The automated refresh approach ma*es heavy use of the BI

solution descri)ed in section %"&"& Bontinuous Integration" $ro(ect Teams should descri)e in particulardetail2

Ho' the e#isting environment 'ill )e temporarily )ac*ed up and 'hen the temporary )ac*up is deleted

Ho' the )ase system installation is reesta)lished

Ho' the system version is migrated to the specified environment

Ho' any structural data)ase modifications are applied

Ho' configuration data is applied.loaded into the )ase installation

Ho' test data is loaded


57/58

Ho' 8sha*e>do'n9 testing is conducted on the ne'ly esta)lished environment

5ote that DHS uses scripts that can )e e#ecuted+ )oth manually and programmatically+ that accepts

parameters 1target environment+ DHS system version+ etc"4 to trigger the refresh using the proposed

Bontinuous Integration tools"

A't,)at# En*ir,n)#ntal R#.r#$" Appr,a(" an Strat#g%

During pro(ect planning+ the pro(ect team should define in detail their approach to automatically refreshing

each proposed environment to a )ase>state 'ith a *no'n version of soft'are+ data model+ configuration

data+ and test data"

The continuous integration toolset is used to accomplish the automated environment refreshes" =or each

environment+ the pro(ect team should specify the fre-uency of the refresh 1e"g" development refreshednightly+ system test 'ee*ly and CAT )efore each validation cycle4"

T#)p,rar% En*ir,n)#ntal Ar("i*#

During pro(ect planning+ the pro(ect team should e#plain ho' a temporary )ac*up of a given environment is

)ac*ed up )efore )eginning the refresh" /ecause the refresh is fully automated+ the pro(ect team should e#plain

ho' success and failure of the )ac*up impacts the refresh cycle" The pro(ect team should e#plain ho' the

)ac*up 'ill )e stored+ accessed+ and if necessary+ restored" The pro(ect team should also provide a )riefdiscussion of ho' long the )ac*up 'ill )e maintained )efore )eing deleted"

R##$ta5li$" Ba$# $%$t#) C,n.ig'rati,n

During pro(ect planning+ the pro(ect team should e#plain ho' the environment 'ill )e reset to a )ase

version of the system once the environment is )ac*ed up" If the system involves the restoring of server

images+ the pro(ect team should e#plain ho' the images 'ill )e esta)lished+ refreshed+ stored and

maintained"

C,# Migrati,n

During pro(ect planning+ the pro(ect team should )riefly e#plain ho' the code for the system 'ill )e

migrated to the specified environment after the esta)lishment of the )ase system"


58/58

Date post:	01-Jun-2018
Category:	Documents
Upload:	nach
View:	239 times
Download:	0 times