Executive Summary: U.S. House of Representatives Systems Development Life-Cycle Policy

U.S.
House of Representatives Systems Development Life-Cycle

Policy
EXECUTIVE SUMMARY
This document provides an overview of the Systems Development Life -Cycle (SDLC) process of the U.S. House of
epresentatives. The SDLC process consists of seven tailored phases that help mana!e a wide ran!e of activity to
conduct pro"ects or automate House activities with information technolo!y. SDLC is not limited to technical activity
#ut actually #e!ins with customer needs and evolves throu!h processes and user re$uirements to develop a solution
or support process. % detailed e&planation of SDLC procedures is outlined in a separate document and provides
!uidance' templates' chec(lists' and e&amples for successful implementation of this policy. The primary o#"ective of
implementin! a standardi)ed SDLC policy is to provide coordinated e&cellent service' at reduced costs' to support
the activity of customers and users within the House community. This concept is shown as*
User
Needs
Customers
SDLC Process (7 phases)
Information
Product or Service
The first section of the policy e&plains the purpose' #ac(!round' and #asic systems development concepts in order to
esta#lish a conte&t for policy description. The systems development methodolo!y' pro"ect mana!ement practices'
and mana!ement controls ma(e up the SDLC environment to which this policy applies. The SDLC phase concept is
further e&plained to ensure the policy or +!round rules, is understanda#le #y individuals other than technolo!y
specialists. % simplified and common framewor( for implementin! SDLC will improve communications and
promote coordination across pro"ects throu!hout the House community. The seven phases of SDLC are*
Project Definition System Build/Prototype/Pilot
User Requirements Definition Implementation and Training
System/Data Requirements Definition Sustainment
Analysis and Design
The second section of the policy e&plains selected (ey terms' descri#es the SDLC concept' and descri#es each phase
of SDLC in !reater detail. SDLC is not a common practice in performin! daily tas(s #ut is critical to develop ways
to support daily tas(s' and re$uires the cooperation of everyone involved. This SDLC policy re$uires that seven
SDLC phases #e used to conduct pro"ects within the House environment' and a pro"ect note#oo( maintained to trac(
the status of a pro"ect related to the SDLC phases. -olicy also re$uires a .or( /rea(down Structure (./S) #e
created to descri#e the wor( and schedule of pro"ect activity' appropriate to pro"ect scope and level of effort. The
./S will #e used as the #asis for pro"ectin! resource re$uirements and cost estimates.
Final 3/24/99
U.S. House of Representatives
Systems Development Life-Cycle
Policy
TABLE OF CONTENTS
Section -a!e
1
Policy
Overview............................................................................................................................................. 1-1
0.0
-urpose ...................................................................................................................................
..........
0-0
0.1
/ac(!round.............................................................................................................................
..........
0-0
0.2
Systems
Development ......................................................................................................................
0-0
0.3
SDLC -hase
Concept .......................................................................................................................
0-1
0.4
SDLC
-hases ....................................................................................................................................
0-1
0.5
oles and
esponsi#ilities................................................................................................................
0-3
0.6
elationships ..........................................................................................................................
..........
0-6
2
SDLC
Policy .................................................................................................................................................. 2-1
1.0
SDLC 7ey
Terms .............................................................................................................................
1-0
1.1
SDLC
-rocess ..................................................................................................................................
1-2
1.2
SDLC -hases with
8ilestones .........................................................................................................
1-2
Project Definition
.............................................................................................................................
1-4
User Requirements Definition
..........................................................................................................
1-6
System/data requirements Definition
................................................................................................
1-9
Analysis and Design
.........................................................................................................................
1-:
System
Build/Prototype/Pilot..........................................................................................................
1-0;
Implementation and Training
.........................................................................................................
1-00
Sustainment............................................................................................................................
.........
1-01
Appendix
A
................................................
....
Information Reo!rce "ana#ement Adviory Co!ncil
C$arter
Appendix
%
............................................................................
.....
&ec$nolo#y Coordination &a' (orce
C$arter
Appendix
C
.......................................................................................................
....... SDLC &erm and Definition
ii Final 3/24/99
Policy
Section 1
POLICY OVERVIEW
0.0 Purpose
This policy esta#lishes a consistent set of mana!ement practices and terms to conduct systems development in the
House environment. The Committee on House %dministration (CH%) has esta#lished a need for revised policy
providin! a hi!h-level plan to support the !oals and o#"ectives of 8em#ers and House staff. This policy esta#lishes
a standardi)ed process for conductin! pro"ects and automatin! House #usiness processes.
0.1 Backgroun
The House of epresentatives is a uni$ue environment re$uirin! the customi)ation of industry technolo!y practices
to automate House activity for effective and efficient operations. Tailorin! of a Systems Development Life-Cycle
(SDLC) policy in the House environment allows the House to #enefit from industry technolo!y and avoid costly
software development. % clear and simplified SDLC policy provides a #asis for all House staff participation in
systems development in a way that provides common understandin! and promotes chec(list style steps. % structured
and consistent approach to systems development ensures successful technolo!y initiatives that are coordinated
amon! the different areas within the House community. The <ffice of the Chief %dministrative <fficer (C%<)' with
support provided #y other House offices' supports the House of epresentatives in networ(in!' telecommunications'
and automation of support processes.
0.2 Systems Development
Systems development in the House environment is a specific effort to automate House activity (#usiness processes)
#y usin! hardware' software' people' and procedures. The SDLC process is defined as an or!ani)ed way to
determine customer needs and user re$uirements such that technolo!y can #e applied throu!h systems development'
and help customers and users perform their "o#s more effectively and efficiently. The process ends with maintenance
and sustainment activities #ut includes a way to use feed#ac( for continuous improvement of processes and systems.
-ro"ect mana!ement is a tool used to mana!e the use of a systems development methodolo!y (a structured approach
to systems development)' and ensure systems are #uilt that help the users and customers. The SDLC environment
includes a systems development methodolo!y' pro"ect mana!ement !uide' and mana!ement controls to esta#lish a
level of chec(s and #alances to ensure a successful process. This relationship is shown as follows*
Systems
SDLC
Pro!ect
Development
"anageme
nt
"et#oology $uie
"anagement
SDLC %nvironment
Controls
0-0 Final 3/24/99
U.S. House of Representatives Systems Development Life-Cycle Policy
0.3 SDLC P#ase Concept
The SDLC phase concept is used to descri#e functional systems development activity' to !ain control of the
comple&ities of systems development' and to ensure the needs of customers and users are the #asis for technical
activity. The SDLC process is #est descri#ed as a series of phases occurrin! in various de!rees and sta!es of overlap.
The dia!ram #elow shows the seven ma"or phases of systems development tailored to the House environment and
the overlap that may occur durin! e&ecution.
Project Definition
User Requirements
Definition
Sstem!data Requirements
Definition
Project
"na#sis and Desi$n
Sstem %ui#d!Prototpe!Pi#ot
Approval/Authorization
Imp#ementation &
'rainin$
BPI/BPR
Sustainment
Timeline
SDL P!ases
The SDLC phases provide an e&cellent opportunity to control' monitor' and audit the systems development process'
and ensure customer and user satisfaction. % feed#ac( process supportin! /usiness -rocess =mprovement (/-=) and
/usiness -rocess een!ineerin! (/-) is critical to ensure the correct process or activity is the #asis for the
technical activity leadin! to systems en!ineerin! and automation.
=t is necessary to draw a distinction #etween the seven SDLC functional activities (phases) and functional tas(s that
occur within the phases. The SDLC phases provide an opportunity for the House to mana!e and trac( the creation'
approval' and pro!ress of pro"ects or information technolo!y initiatives. The functional tas(s are mana!ed for each
pro"ect and may occur within one or more phases. Specific tas(s' such as technolo!y evaluations and
demonstrations' may #e conducted across several SDLC phases to ensure user and system re$uirements are defined
that are achieva#le with current technolo!y. =t is important to identify the mandatory tas(s for all pro"ects to provide
consistency amon! House pro"ects. The seven SDLC phases should #e used as a chec(list to ensure that each pro"ect
is mana!ed in a consistent and thorou!h manner at a level matchin! the pro"ect scope. >unctional tas(s will #e
descri#ed in section two of this policy as they relate to the SDLC phases.
0.4 SDLC P#ases
Summary definitions of the seven SDLC phases are provided #elow*
Project Definition ? The pro"ect definition phase prompts collection of information for the C%< and CH% to
determine if a pro"ect warrants the investment of personnel resources and fundin!. The pro"ect definition should
identify the customer' user' mandate' and #asic operatin! concept. %dditionally' the pro"ect definition should provide
a preliminary investi!ation of alternatives and ris( analysis' and a hi!h level cost-#enefit analysis to determine if the
pro"ect has a favora#le return on investment. The pro"ect information should show the e&pected cost increase or
decrease and the capa#ilities or #enefits !ained' and is critical to the pro"ect approval process. The pro!ram and
pro"ect mana!er should #e identified as well as pro"ected costs for trainin! and sustainin! efforts after the pro"ect is
completed. The (ey output of this phase is (nowin! e&actly what the scope of the pro"ect is prior to committin!
fundin! and resources' includin! the pro"ect timeta#le with milestone dates and resource estimates' and a formali)ed
approval@authori)ation or disapproval of the pro"ect #ased on the pro"ect definition.
User Requirements Definition ? The user re$uirements definition phase is #ased on the processes that users conduct
in their day-to-day activity. The user re$uirements should clearly descri#e what part of the user process (activity)
should #e automated or enhanced' and the e&pected capa#ilities and features. There may #e a num#er of other tas(s
to perform prior to developin! the user re$uirements' such as interviews' o#"ectives identification' and definin!
0-1 Final 3/24/99
operatin! concepts. The (ey output of this phase is a summary document of user re$uirements that e&plains what the
system is supposed to do.
System/data Requirements Definition ? The system@data re$uirements definition phase is #ased on mer!in! user
processes and re$uirements in a way that allows a system to support many different users or functions in similar
areas. The system@data re$uirements phase mar(s the start of esta#lishin! (ey technical areas to use technolo!y to
ma(e the wor( easier. Technical re$uirements are usually esta#lished as a su#-set of the system@data re$uirements
and incorporate e&istin! systems and technolo!ies currently used #y the or!ani)ation. Data re$uirements are a
critical road map for any information system desi!ned to process data. The (ey output of this phase is a summary
document of system@data re$uirements that e&plains what the system should #e #uilt to' how data should #e
processed' and what technical or support re$uirements may e&ist. =n addition' security and internal control related
re$uirements are also developed as appropriate to the scope of the pro"ect.
Analysis and Design ? The analysis and desi!n phase is a comple& and critical step in determinin! which system
desi!n' #ased on systems en!ineerin! and technolo!y analysis' meets the user and system re$uirements. >or non-
technical solutions' the desi!n may simply #e a support process to #e implemented over time. The desi!n may #e
presented as several options with trade- off analysis or a specific confi!uration' and may consist of Commercial-off-
the-shelf (C<TS) products (preferred approach) or customi)ed development. -rocurement options and cost
information should #e identified as determined #y resource re$uirements and the desi!n. The most si!nificant
milestone in this phase is the recommendation of what to do or #uy in order to meet the user and system
re$uirements.
System uild/Prototy!e/Pilot ? The system #uild phase is the e&ecution of the approved desi!n and in some cases
may #lend into the implementation phase. % smaller test system is sometimes a !ood idea in order to !et a +proof-of-
concept, validation prior to committin! funds for lar!e scale fieldin! of a system without (nowin! if it really wor(s
as intended #y the user. >or non-technical solutions' the system #uild may involve creation of a support process and
move directly to implementation. -rocurement activity #e!ins in this phase and may #e e&panded with deployment
durin! implementation. The validation' verification' and testin! plan should drive the system testin! and #e
conducted a!ainst the system@data and technical re$uirements to ensure the system is #uilt to specification. System
testin! should also #e conducted a!ainst the user re$uirements to ensure the system is operationally satisfactory. The
prototype or pilot concept also allows for refinements or ad"ustments #ased on user feed#ac( prior to a lar!er scale
implementation. The (ey output of this phase is validation of the desi!n prior to full commitment.
"m!lementation and #raining ? =mplementation includes all necessary activity to procure' receive' confi!ure' and
install the new or revised system. >or non-technical solutions' implementation may #e limited to a new support
process re$uirin! a chan!e in the #usiness process. Trainin! is conducted durin! this phase accordin! to the trainin!
plan' which would have #een developed in one or more of the previous phases. % +transition, or +cut-over, plan'
includin! any re$uired data conversion' will also #e re$uired to ensure a smooth transition to the new system
without interruptin! services. The development of appropriate documentation' such as manuals for operations and
maintenance' are re$uired for successful transition. The impact of runnin! old and new systems simultaneously
should also #e analy)ed to determine if there would #e e&cessive #urden in operatin! e&penses or personnel support.
Testin! also ta(es place in this phase and validates the usa#ility of the system or support process throu!h reports
such as test analysis' security evaluations' and system accreditation. System accreditation is the formal process for
determinin! if the system meets user e&pectations (user acceptance) as outlined #y the user re$uirements. The (ey
output of this phase is a successful transition to the new system with uninterrupted service.
Sustainment ? The sustainment phase is a dedicated effort to (eep the system operatin! at an optimum level #y
conductin! maintenance and enhancements as determined #y periodic reviews. >or non-technical solutions'
sustainment may #e the continuation of a support process. Chan!es in the environment' customer and user needs' or
technolo!y may prompt #usiness process improvement or reen!ineerin! initiatives to validate or revise the #usiness
process. Sustainment may also include chan!es to the system #ased on technolo!y advancement and can #e
addressed throu!h system enhancements or redesi!n initiatives. Sustainment activity may #e conducted #y C%<
personnel or contractors and #e supervised #y C%< staff or other House technical staff. Continuous improvement is
a re$uirement of the sustainment phase and shall #e reviewed #y identifyin! standards and measures of performance'
and documented in pro"ect status reviews. Chan!e mana!ement and $uality assurance is also a re$uirement in this
phase to ensure proper documentation of the system confi!uration in a thorou!h and accurate manner.
0-2 Final 3/24/99
0.5 Roles an Responsi&ilities
The Committee on House %dministration has assi!ned the C%< with the primary responsi#ility of implementin! an
SDLC process. There are several !roups that have (ey roles and responsi#ilities in the successful implementation of
an SDLC process. The assi!ned role descri#es what type of participation the !roup will have and the responsi#ility
descri#es what tas(s' events' or activities the !roup will en!a!e in for SDLC related activities.
0-3 Final 3/24/99
&$e C$ief Adminitrative Officer )CAO*
Role ? The C%< will perform as an e&ecutin! #ody and coordinate the esta#lishment of appropriate advisory
councils and wor(in! !roups' and coordinate participation of individuals or !roups outside the C%<.
Res!onsi$ilities ? The C%< has the followin! responsi#ilities for SDLC related activity*
(0) The C%< will coordinate the esta#lishment of an =nformation esources 8ana!ement %dvisory Council
(=8%C) or other such #ody with a role of steerin! SDLC concepts #ased on the environment of the House
and current needs of the 8em#ers and Committees. The =8%C will also advise on strate!ic initiatives
and #ud!et considerations. %ppendi& % of this policy descri#es the =8%C mission and charter.
(1) The C%< will ensure the esta#lishment of a Technolo!y Coordination Tas( >orce (TCT>) or other such
C%< #ody with a role of developin!' !uidin!' and implementin! pro"ect mana!ement' procedures' and
concepts to conduct systems development in an inte!rated and coordinated manner. The TCT> will #e
chaired #y the H= %ssociate %dministrator or desi!nated representative and maintain representation from
all ma"or !roups within the C%<. The TCT> shall also esta#lish and dissolve temporary steerin!
committees' as re$uired #y pro"ect activity' to oversee operational implementation for specific initiatives or
pro"ects. The TCT> will forward recommendations and issues to the =8%C re$uirin! approval or
!uidance a#ove the C%<. %ppendi& / of this policy descri#es the TCT> mission and charter.
(2) H= will esta#lish specific procedures and methodolo!ies for conductin! systems development in the
House environment and provide trainin! to maintain a level of common understandin! and coordinated
effort. H= will additionally conduct and trac( SDLC trainin! and awareness to ensure the House #enefits
from effective use of SDLC.
Aut%ority ? The C%< has authority to develop pro"ect mana!ement and systems development !uides to assist the
House community in participatin! in the SDLC process.
&$e Office of Inpector +eneral )OI+*
Role ? The <=A will perform in a review and advisory capacity and develop recommendations for improved
operations and cost effective alternatives.
Res!onsi$ilities ? The <=A has the followin! responsi#ilities for SDLC related activity*
(0) The <=A will provide representation to the =8%C or other such #ody as coordinated #y the C%<. The
<=A will provide !uidance on #est practices' strate!ic visions' and implementation of systems development
concepts in the House environment.
(1) The <=A will conduct periodic reviews of the SDLC process and ma(e recommendations to improve or
enhance the SDLC process #ased on industry #est practices as modified #y the uni$ue re$uirements of the
House environment.
Aut%ority ? %s provided in House ules =B' the <=A is responsi#le for conductin! periodic audits of financial and
administrative functions of the House. This authority includes reviews of the SDLC process and related activities'
usin! #est industry practices.
&$e Committee on ,o!e Adminitration )C,A*
Role ? The CH% will perform in a review and advisory capacity and provide oversi!ht !uidance in the #est interests
of 8em#ers and Committees' and the House in !eneral' related to information technolo!y and service support.
Res!onsi$ilities ? The CH% will provide representation to the =8%C or other such #ody as coordinated #y the
C%<. The CH% will review and approve policies or activity as recommended #y the C%<.
0-4 Final 3/24/99
Aut%ority ? The CH% has the authority to esta#lish or ad"ust all activities related to the SDLC process in the House
environment.
0.6 Relations#ips
The roles of =nformation esources 8ana!ement %dvisory Council (=8%C) and Technolo!y Coordination Tas(
>orce (TCT>)' or similar #odies' are an important part of ma(in! the SDLC process wor( in the House environment.
The =8%C provides an advisory or steerin! role to ensure SDLC is tailored to the House environment while the
TCT> provides development and implementation of specific procedures or concepts for successful pro"ects.
Determinin! "#!at to do$% !iven the uni$ueness of the House environment' is the primary role of the =8%C.
Determinin! "!o# to do it% and "doing it% is the primary role of the TCT>. The pro!ram and pro"ect mana!ers are
the detailed e&ecutors of pro"ect wor( #ut the TCT> is the over -archin! e&ecution #ody that ensures SDLC and
coordinated efforts achieve e&cellent service at reduced costs. Steerin! committees under the TCT> serve as
temporary or lon!er-term wor(in! !roups that en!a!e in activity e&tendin! #eyond a particular pro"ect or system.
TCT> steerin! committees provide critical support in #rid!in! the !ap #etween the users' technolo!y' and inter-
relationships of pro"ect areas. The relationship of the SDLC environment to the =8%C and TCT> is shown as
follows*
IRMAC (uidance &
(uidance & )versi$ht
)versi$ht
TC
TF
Systems SDLC Pro!ect Imp#ementation
Development "anagement & *+ecution
"et#oology $uie
"anagement
Steerin$ Controls
SDLC %nvironment Pro!ect %'ecution Committees
Systems development methodolo!ies' pro"ect mana!ement !uidance' and mana!ement controls are methods of
addressin! specific areas of SDLC implementation. SDLC procedures provide more detailed !uidance on
implementin! SDLC and specify preferred formats' template structures' or report content. Cach of the three areas of
the SDLC environment may also have detailed procedures developed to fit the or!ani)ations or !roups usin! SDLC
and will typically chan!e or evolve with e&ecution. % systems development methodolo!y outlines details of the
House approach to implementin! SDLC consistent with industry #est practices' which also evolves with technolo!y
and process chan!e. -ro"ect mana!ement is a structured approach to mana!in! the use of methodolo!ies to conduct
pro"ects or provide a support service. -ro"ect mana!ement courses are readily availa#le from industry or within
House trainin! opportunities while industry software tools' such as 8icrosoft -ro"ect' are availa#le to help mana!e
pro"ect activities. % well-defined SDLC process will help levera!e e&istin! technolo!ies and support the House
community at an afforda#le price. 8ana!ement controls contain elements from #oth the systems development
process as well as pro!rammatic practices and ensure close coordination #etween the two. The C%< and H= are
responsi#le to develop specific procedures and !uides' throu!h the =8%C and TCT>' to support the
implementation of an SDLC process tailored to the House environment. The relationship of this policy to specific
procedures' methodolo!ies' and !uides is shown as follows*
0-5 Final 3/24/99
Policy
SD
LC Polic
(#is Document
SDLC
Proce!ur
es
"e#ecutio$%
Customer,%ased SDLC SDLC
Sstems
Deve#opment Project -ana$ement -ana$ement
-ethodo#o$ (uide Contro#s
The SDLC policy is supported #y SDLC procedures esta#lished within the or!ani)ational area implementin! SDLC
or across the House community. The SDLC procedures are maintained in separate documentation and provide
detailed !uidance on the implementation of the SDLC process. -ro"ect mana!ement and systems development
methodolo!ies are more fluid in nature and are continually updated to reflect and ta(e advanta!e of the #est
practices of industry. -ro!rammatic tools' such as 8icrosoft -ro"ect' are availa#le to trac( pro"ect activity usin!
Aantt chart style schedules.
0-6 Final 3/24/99
Section )
SDLC POLICY
The SDLC process outlined in this document provides a standardi)ed method to help mana!e a wide ran!e of
activity to conduct pro"ects or automate House activities with information technolo!y. This process can #e used on
any selected pro"ect whether or not technolo!y is used to automate the activity. The SDLC policy re$uires e&ecution
of pro"ects within the framewor( of the seven identified phases and trac(in! with a pro"ect note#oo( to reflect the
SDLC status of pro"ects at any !iven time. The practice of conductin! structured systems development' #y
developin! customer-#ased processes and solutions' promotes a smarter and less e&pensive way of doin! #usiness in
the House.
1.0 SDLC *ey (erms
There are many different terms and e&pressions associated with systems development and pro"ect mana!ement. =n
order to provide a common #asis for definin! the SDLC phases and activities' some selected terms and definitions
are provided to help develop the conte&t for SDLC policy in the House environment.
Program/Project &anager
-ro!ram mana!er and pro"ect mana!er are two terms sometimes used interchan!ea#ly #ut actually differ in their
roles. The pro!ram mana!er has overall responsi#ility for all pro"ects within the pro!ram and the pro"ect mana!er is
responsi#le for e&ecutin! the tas( elements of the pro"ect. The followin! dia!ram shows the pro!ram and pro"ect
mana!er relationships*
Program Manager
As assigned
Project Project Project
-ana$er -ana$er
-ana$
er
Contractor
'as. 'as.
Leader Leader
Desi!nation of the pro!ram mana!er should #e #ased on whether the pro"ect serves a dedicated !roup or serves an
infrastructure role to support a wide user #ase where no particular !roup has ownership of the service or system. =n
the case of a dedicated type of pro"ect or system' the pro!ram mana!er should possess some #ac(!round from the
user perspective in order to ensure the user processes and re$uirements are fully represented in the pro"ect activity.
>or infrastructure type pro"ects' the pro!ram mana!er can #e selected from a wider e&perience #ase #ut should have
e&perience in the technical area of the pro"ect and sound pro!ram mana!ement s(ills. The pro"ect mana!er will #e
selected for the specific s(ills necessary to e&ecute the tas( elements of the .or( /rea(down Structure (./S)' or
simply' possess the s(ills and e&perience to mana!e the wor( necessary to complete the pro"ect.
Program &anager - The pro!ram mana!er is responsi#le for mana!in! pro!rammatic activities such as personnel
resources' #ud!et' schedule' user involvement' and overall status of the pro!ram. >or e&ample' the pro!ram mana!er
would #e responsi#le to ensure items li(e a Statement of .or( (S<.) and user re$uirements are included in a
procurement pac(a!e #ut the pro"ect mana!er would ensure the technical information is written. The pro!ram
mana!er also ensures the #usiness process dialo! occurs #etween the users and system desi!ners and coordinates
any activity with other pro!rams that have an impact or relation to pro!ram activity.
Project &anager - The pro"ect mana!er is responsi#le for development and e&ecution of the tas( elements of the
./S. The pro"ect mana!er oversees day to day e&ecution of the pro"ect and directs personnel in the
1-0 Final 3/24/99
accomplishment of tas(s. The pro"ect mana!er is responsi#le for (nowin! what part of the systems development
process the pro"ect is in at any time.
'ustomer/User
The second critical area for common understandin! is the difference #etween customer and user' and the relationship
they have in the systems development process. The followin! dia!ram shows how the customer needs should #e the
#asis for developin! user re$uirements as part of the SDLC process.
User
Needs
Customer
SDLC Process (7 phases)
Information
Product or Service
The user processes and output should #e clearly defined prior to any automation or enhancement which helps to
ensure the output (results) is what the customer is loo(in! for and the automation is user-friendly and an
improvement to the process.
'ustomer - The customer is the ultimate #enefactor of the service or information product. The customer needs
should provide the primary influence on how the user constructs their operatin! concept and #usiness processes.
User - The user (individual or !roup) that conducts the support processes' or uses the automation technolo!y or
system' to produce a service or product for the customer. The user has the (ey role of identifyin! the #usiness
processes and the areas for possi#le automation (new system) or enhancement (e&istin! system or support process).
=t is important to note that the customer can also #e a user such as a 8em#er havin! access to a hypothetical .e#-
#ased finance system to view the status of their pay transactions. The finance !roup would #e the primary user of
such an automated finance system that serves the 8em#er customer #ase. The 8em#er' in addition to !ettin! a
paychec( as a customer' would also #e a user of the system to +view only, the latest transactions for that 8em#er.
This is an e&ample of how the customer and user can #e the same individual at times' hi!hli!htin! the need to ensure
that customer needs #ecome the #asis for developin! user re$uirements.
1.1 SDLC Process
The SDLC process represents a House-wide coordination effort to conduct pro"ects in a structured manner that
promotes appropriate analysis necessary for pro"ect e&ecution. The SDLC process provides a framewor( of phases
that help trac( uni$uely created tas(s for each pro"ect. Tas(s differ from activities in that they produce specific
outputs such as decisions or documents on which further decisions can #e made. The overall view of the SDLC
process that demonstrates the +decision point, concept is shown as follows*
1-1 Final 3/24/99
Project Definition
Identify the customer and user
Assig
n a
Program and Project
Manager
User Requirements
BPI Definition
BPR
Sstem!data
Requirements Definition
T
h
e
u
s
er and
system/data
requirement
s must e
the asis for
system
design and
sele
ctio
n of
!"
T#
pro
duc
ts
"na#sis and Desi$n
#ystem
$nhancements
% Redesign Sstem %ui#d!
Prototpe!Pi#ot
Compar
e
Buy
"ptions
&eci
de
Build and
'alidate
Imp#ementation
and 'rainin$
S
u
stain
men
t
and
Transi
tion
(eep the
s
y
ma)e
improv
ements
Cach pro"ect is
assi!ned a pro"ect
mana!er to develop
the uni$ue pro"ect
tas(s (the ./S)
within each SDLC
phase. The pro"ect
mana!er shall (eep a
pro"ect note#oo( that
trac(s the SDLC
status of each pro"ect.
=f contractor resources
are used to help
e&ecute a pro"ect' then
a procurement
pac(a!e should #e
prepared detailin! the
e&act parts of the
SDLC process' and
the e&pected wor( to
#e performed #y the
contractor as
descri#ed in the
statement of wor(.
The procurement
pac(a!e should also
contain necessary
information from
previous phases to
provide a complete
pac(a!e and !enerate
a comprehensive
contractor response.
>or e&ample' a
procurement pac(a!e
for desi!nin! and
implementin! a
system should contain
the user and
system@data
re$uirements or an
appropriate
re$uirements
summary.
1.2 SDLC
P#ases
+it#
"ilestones
The seven SDLC
p
h
wit
h
(e
y
del
ive
ra#
les'
a
des
cri
pti
on
of
rec
om
me
nd
ed
tas
(s'
an
d a
su
m
ma
ry
of
rel
ate
d
co
ntr
ol
o#"
ect
ive
s
for
eff
ect
ive
ma
na
!e
me
nt.
=t
is
crit
ica
l
f
o
1-2 Final
3/24/99
SDLC P#ases
Project Definition
User Requirements
Definition
Sstem Requirements
Definition
"na#sis and Desi$n
Sstem %ui#d!
Prototpe!Pi#ot
Imp#ementation
and 'rainin$
Sustainment
Control
,&!ectiv
es
Co$tro
l
O&'ecti
(es
"anage
ment
Cont
rol
Doma
ins
P#annin
$ &
)r$ani/
ation
"cquisiti
on &
Imp#emen
tation
De#iver
&
Sup
port
-onit
orin$
SDL
P!ases
Related
to
&anage
ment
ontrols
To mana!e and control an SDLC initiative'
each pro"ect will #e re$uired to esta#lish
som
e
de!r
ee of
a
./
S to
capt
ure
and
sche
dul
e
the
wo
r(
ne
ces
sar
y
to
co
mpl
ete
the
pro"
ect.
The
./
S
and
all
pro
!rammatic material should #e (ept in the
+-ro"ect Description, section of the pro"ect
note#oo(. The ./S format is mostly left to
the pro"ect mana!er to esta#lish in a way
that #est descri#es the pro"ect wor(. There
are some (ey areas that must #e defined in
the ./S as part of the SDLC policy. The
followin! dia!ram descri#es three (ey areas
that will #e addressed in the ./S in a
manner esta#lished #y the pro"ect mana!er.
%
'
e
c
ut
ive Summary section +it# a
#ig#-level sc#eule of key
activ
ities
a
n
Detaile
pro!ect tasks
for t#e
applica&le
SDLC p#ases
Special interest areas
tracke outsie t#e
SDLC p#ase areas as
re-
uir
e
.
o
r
k

B
r
e
a
k
o
+
n
St
ru
ct
ur
e
.BS
'or(
Brea(do
#n
Structur
e )'BS*
+rgani,
ation
The upper section of the
./S should identify the
ma"or phases and
milestones of the pro"ect
in a summary fashion. =n
addition' the upper
section should provide an
overview of the full
scope and timeline of the
pro"ect and will #e part of
the initial pro"ect
description effort leadin!
to pro"ect approval. The
middle section of the
./S is #ased on the
seven SDLC phases as a
!uide for ./S tas(
development. The ./S
elements should consist
of milestones and +tas(s,
as opposed to +activities,
and have a definitive
period (usually two
wee(s or more). Cach
tas( must have a
measura#le output (e.!.
document' decision' or
analysis). % ./S tas(
may rely on one or more
activities (e.!. software
en!ineerin!' systems
en!ineerin!) and may
re$uire close
coordination with other
tas(s' either internal or
e&ternal to the pro"ect.
%ny part of the pro"ect
needin! support from
contractors should have a
S<. written to include
the appropriate tas(s
from the SDLC phases.
T
h
e

d
e
v
e
l
o
p
m
e
n
t
o
f
a

S
<
.

d
o
e
s

n
o
t
o
c
c
u
r
d
u
r
i
n
!

a

s
p
e
c
i
f
i
c
1 -
3
phase of SDLC #ut is developed to include the wor( from the SDLC process that may #e conducted #y e&ternal
resources such as contractors.
Cach of the seven SDLC phases is listed #elow with the #asic intent' (ey delivera#les' a description of
recommended tas(s' and summary points for effective mana!ement controls. The SDLC phases should #e e&ecuted
with simultaneous near -term (referred to as Trac( =) and lon!-term (referred to as Trac( ==) considerations to ensure
continuous support as well as inte!rated systems development. The delivera#les mar(ed with an asteris( are
re$uired under this policy to #e completed at a level appropriate to the scope of the pro"ect. The delivera#les without
an asteris(' and the tas(s listed under each phase' are re$uired for consideration for each pro"ect. %ny mana!er at the
pro"ect mana!er level and a#ove may assi!n a non-asteris( delivera#le to the pro"ect appropriate to the scope of
effort. >or pro"ects where costs in later phases are difficult to predict' procurements should #e #ro(en-up into lo!ical
pieces and used as decision points. %n appendi& provides definition of terms fre$uently used in the systems
environment.
Project Definition
Decription- The pro"ect definition phase must capture all information necessary to descri#e the full life-cycle
impact of the pro"ect at a summary level' and determine if a pro"ect warrants the investment of personnel resources
and fundin!. %t a minimum' the pro"ect definition document must identify the customer' user' mandate' #asic
operatin! concept' and provide a preliminary investi!ation of alternatives (includin! non-computer-#ased solutions)'
a preliminary ris( analysis' and a hi!h-level cost-#enefit analysis to determine if the pro"ect has a favora#le return on
investment. -ro"ect analysis should show the e&pected cost increase or decrease and the capa#ilities or #enefits
!ained' and is critical to the pro"ect approval process. Smaller pro"ects may #e descri#ed within 0-1 pa!es while
more comprehensive pro"ects may re$uire a pro!ram plan' ac$uisition plan' or other similar document to descri#e
the pro"ect in enou!h detail to support the plannin! and approval process. The anticipated pro!ram and pro"ect
mana!er should #e identified with any pro"ected costs for trainin! and sustainin! efforts after the pro"ect is
completed. -ro"ect description of the SDLC phases will re$uire estimates for impact or cost' prior to when they can
#e accurately determined' with su#se$uent revisions as the SDLC process unfolds. eplacement pro"ects must
conduct a /=@/- assessment to ensure the replacement effort is not conducted for invalid processes. The (ey
outputs of this phase is (nowin! what the scope of the pro"ect is prior to committin! fundin! and resources' and a
formali)ed approval@authori)ation or disapproval of the pro"ect #ased on the pro"ect definition.
1-4 Final 3/24/99
Delivera.le- - indicates mandatory documents appropriate to project scope.
-Project Definition Document
-'or( Brea(do#n Structure )top le/el #it! sc!edule*
ustomer Inter/ie#/Sur/ey Reports )needs analysis*
Alternati/es Analysis )may 0e separate from Project Definition Document for larger projects*
Ris( Analysis )may 0e separate from Project Definition Document for larger projects*
ost Benefit Analysis )may 0e separate from Project Definition Document for larger projects*
-BPI/BPR Assessment )for replacement projects*
Tec!nology 1/aluations
Program Plan )sometimes called Acquisition
Plan* Project Status Brief
Program Re/ie#s
"a/or &a'-
Customer@User =dentification ? provide a short description of who the customers and users will #e as related to the
pro"ect. =dentify whether there is any overlap of the customer participatin! as a user.
-ro"ect Description ? provide a description of the pro"ect and outline the pro"ect purpose and o#"ectives. -rovide a
simple operatin! concept dia!ram as appropriate to descri#e the pro"ect and other related areas or systems. Descri#e
any re$uired /-=@/- efforts that may #e necessary to validate or chan!e the #usiness process prior to automation
initiatives.
Customer =nterviews ? conduct and summari)e analysis of customer needs throu!h an interview process. This
information #ecomes the #asis for pro"ect e&istence and su#se$uent user re$uirements development.
%lternatives %nalysis ? provides an analysis of alternative approaches' includin! non-computer-#ased solutions such
as support processes or procedural solutions' that reasona#ly achieves pro"ect o#"ectives.
is( %nalysis ? provides a description of internal control and security vulnera#ilities' the nature and ma!nitude of
associated threats' and potential for loss or disruption to service. The analysis also includes recommendations for
miti!ation and safe!uards for the identified ris(s.
Cost@/enefit %nalysis ? provides a summary analysis of the #enefits of the pro"ect compared to the cost. 8ay
include return on investment analysis identifyin! the +#rea(-even, point.
Hi!h Level ./S@Schedule ? provide a summary ./S and schedule (Aantt Chart) of the pro"ect phases and ma"or
milestones.
"ana#ement Control- The pro"ect definition phase should provide a hori)ontal loo( at the full pro"ect life-cycle at
a hi!h level' #ut address certain (ey areas in order to mana!e pro"ect efforts within the strate!ic plannin! process.
Summari)ed control o#"ectives from the domain of Planning 2 +rgani,ation should #e continuously reviewed for
applica#ility and include*
0D -ro"ect relevance to the or!ani)ational strate!ic plan
1D oles and responsi#ilities of (ey !roups related to the pro"ect
2D is( assessment
3D Costs@/enefits
4D -ersonnel resources
5D -ro"ect mana!ement
6D Communications processes
User Requirements Definition
Decription- The user re$uirements definition phase re$uires the pro"ect mana!er to conduct a num#er of tas(s
leadin! to the development of a user re$uirements document. The customer needs will impact how the user
1-5 Final 3/24/99
esta#lishes the mission' o#"ectives' and operatin! concept for the support or service provided to the customer.
Developin! process flows at #oth the pro"ect level and user level will facilitate selectin! the (ey processes to
automate ? which constitutes the user re$uirements. The details of the user re$uirements (user performance
parameters) will #e refined throu!hout the pro"ect.
-oncept of +perations Document
3unctional +perating Areas Defined
User Inter/ie#/Sur/ey Reports
-3unctional Requirements
User )+perational* Process
3lo#s -User Requirements
Document
"a/or &a'-
Concept of <perations ? the process of developin! drawin!s and te&t that descri#es the hi!h-level activity of the
users. This document serves as the #asis for user re$uirements development and outlines the core #usiness process.
>unctional e$uirements ? the core #usiness processes are usually divided into ma"or !roupin!s called >unctional
<peratin! %reas (><%). The primary processes within the ><% !roupin! are candidates for automation and #ecome
the functional re$uirements. =dentification of the functional re$uirements helps to identify the related technolo!y
areas much earlier in the development process and #e!in technolo!y evaluations.
User -rocess >lows ? the user process flows are developed throu!h process en!ineerin! and may re$uire interviews
with the user community. The customer needs should have a si!nificant impact on the development of user processes
and #e fully addressed #y the user process.
User e$uirements Development ? the detailed activity of the userEs processes serve as a #asis for user re$uirements
development. The user re$uirements should accurately descri#e what part of the user processes are candidates for
automation or a support process. The user re$uirements should also include any security re$uirements and #e
validated to determine the final set of re$uirements eli!i#le for the development effort. =t is important to note that
redundancies and repetitive actions may e&ist at this point #ut are documented and will #e addressed #y the systems
en!ineerin! activity.
"ana#ement Control- The user re$uirements definition phase should e&amine a num#er of critical areas leadin!
to fully defined user re$uirements. Summari)ed control o#"ectives from the domain of Planning 2 +rgani,ation that
should #e continuously reviewed for applica#ility to the pro"ect include*
0D Compliance with e&ternal re$uirements
1D is( assessment
2D Costs@/enefits
3D Definin! relationships
4D User participation
5D e$uirements validation
6D Communications processes
System/data Requirements Definition
Decription- The system@data re$uirements definition phase is primarily dependent on completion of tas(s from the
user re$uirements definition phase. This phase is or!ani)ed #y identifyin! functional development areas that
facilitate technical activity or support cuttin! across many operational (#usiness) areas. This phase re$uires systems
en!ineerin! s(ills and technical support to com#ine the user re$uirements and processes in a way that reduces
redundancies' mer!es repetitive actions' and incorporates technolo!y concepts. % well-defined system process that
meets the user re$uirements is the #asis for system@data re$uirements. The technical re$uirements will #e a su#-set
of the system@data re$uirements and incorporate specifications of e&istin! e$uipment or systems. The system@data
re$uirements should clearly descri#e what part of the system process should #e automated or enhanced' which helps
1-6 Final 3/24/99
promote a solution that meets the needs of many areas (inte!rated solution). Directly automatin! or enhancin! the
user requirements may result in isolated systems' compati#ility pro#lems' and costly implementation issues. The
development of system processes and system@data re$uirements is the #asis for analysis and desi!n.
3unctional De/elopment Areas
System Process 3lo# Dra#ings
-System/data Requirements Document )may include tec!nical requirements*
-Security and Internal ontrol Plan
-Tec!nical Requirements )mandatory for tec!nology40ased projects only*
-Interface ontrol Document )mandatory for tec!nology40ased projects only*
"a/or &a'-
System -rocess >lows ? involves development of system processes that com#ine user re$uirements and processes.
System process flows are usually developed within >unctional Development %reas (>D%) which provide a !roupin!
of the anticipated technical activity. The systems approach allows elimination of redundancies and repetitive
activities while also incorporatin! technical concepts or use of automated steps.
System@data e$uirements Development ? provides information a#out which system processes should #e automated
or enhanced (capa#ilities and features) and identifies the operatin! environment and technical specifications. System
performance parameters and data#ase re$uirements are e&amples of information contained in the system
re$uirements. % com#ination of technical information such as system re$uirements' data#ase re$uirements' technical
re$uirements' interface controls' system security' and other information' comprise the system specification.
=nterface Control ? provides information a#out areas that must #e standardi)ed for data transfer or connectivity to
occur #etween systems. The technical part of interface control is dependent upon (nowin! where the #usiness
processes of related systems overlap or should #e inte!rated.
"ana#ement Control- The system@data re$uirements' alon! with the user re$uirements' provides the critical
information for analysis and desi!n. System@data re$uirements mar( the transition from the mana!ement control
domain of Planning 2 +rgani,ing into Acquisition 2 Implementation. %lthou!h plannin! and or!ani)in! continues
throu!hout SDLC' the system@data re$uirements serve as the #asis for determinin! a solution. % summary of
relevant control o#"ectives includes*
0D /ound the technolo!y direction
1D =dentify roles and responsi#ilities
2D eview trade-off analysis
3D %c$uisition considerations
Analysis and Design
Decription- The analysis and desi!n phase is #ased on reviewin! the contents of the user and system@data
re$uirements. The resultin! systems en!ineerin! effort could ran!e from the selection and confi!uration of an
e&istin! software product to a comprehensive systems development initiative involvin! software en!ineerin! and
customi)ation. >or non -technical solutions' the desi!n may simply #e a support process to #e implemented over
time. House policy is to see( the use of e&istin! solutions or C<TS products and avoid costly software development
or customi)ation. The analysis and desi!n process' alon! with the results of technolo!y evaluations' may prompt an
ad"ustment in the #usiness process (policy or procedures) in order to ta(e advanta!e of the cost savin! of C<TS
solutions. The most important aspect of this SDLC phase is to provide solution alternatives with trade-off analysis
that fit within the House environment and meet the validated re$uirements.
-System Design Document
-System Security and Internal ontrol Specification
-Detailed ost4Benefit Analysis )mandatory for tec!nology40ased projects only*
1-9 Final 3/24/99
Tec!nology 1/aluation Reports
Trade4off Analysis
"a/or &a'-
System Desi!n ? a systems en!ineerin! process that uses the results of technolo!y evaluation to develop a solution
or support process. The system desi!n is structured to produce capa#ilities' that when com#ined with procedures'
provides solutions for enhancin! performance or a support process. The security and internal control re$uirements'
tailored to the House environment' are also em#edded in the desi!n process and provide a com#ination of
technolo!y and procedures to achieve the desired security protection and sound internal control environment.
Desi!n <ptions ? provides two or more desi!n options that !ives varyin! levels of performance for different ran!es
of cost' #uild time' and capa#ilities. Trade-off and cost-#enefit analysis provides a means to present these options
tailored to the House environment.
"ana#ement Control- The analysis and desi!n phase is primarily covered #y the mana!ement control domain of
Acquisition 2 Implementation. % summary of relevant control o#"ectives includes*
0D >easi#ility studies
1D Comparison and ris( reports
2D Cost-effective security
3D =nformation architecture
4D elevance to strate!ic technolo!y !oals
System uild/Prototy!e/Pilot
Decription- The system #uild@prototype@pilot phase is the e&ecution of the approved desi!n and' in cases of a
sin!le system' may move directly into the implementation phase. >or non-technical solutions' the system #uild may
involve creation of a support process and move directly to implementation. =nitial procurement activity is conducted
to sta!e a system #uild prior to deployment durin! implementation. The prototype or pilot concept provides a !ood
opportunity to determine technical feasi#ility prior to a lar!e investment of fundin! and resources. User and system
testin! can also #e conducted in this phase and is covered in more detail in the implementation and trainin! phase.
The system #uild will also serve as an interim step prior to deployment of a system to ensure minimal disruption
durin! the deployment. The system #uild@prototype@pilot phase also serves as a means to collect feed#ac( and ma(e
refinements or ad"ustments prior to full deployment.
-Prototype/Pilot Report
-5alidation$ 5erification$ and Test Plan )mandatory for tec!nology40ased projects only*
-ompleted System 5alidation Report )esta0lis!es system 0uilt to specification* Security
1/aluation Report
"a/or &a'-
System /uild ? provides a controlled environment to conduct procurement' receivin!' sta!in!' confi!uration' and
other #uild-out activities on a smaller scale. The #uild-out process also allows validation of vendor e$uipment and
testin! within a controlled environment prior to deployment in a production mode.
Balidation' Berification' and Testin! ? testin! should #e conducted accordin! to the plan and conclusively
demonstrate that #oth the user and system re$uirements have #een met. =ndependent validation and verification
should #e used for more comprehensive pro"ects and appropriate reports created.
"ana#ement Control- The system #uild@prototype@pilot phase consists primarily of structured processes to meet
the approved system desi!n. The mana!ement control domain of Acquisition 2 Implementation encompasses this
SDLC phase. % summary of relevant control o#"ectives includes*
0D >easi#ility studies
1-: Final 3/24/99
0D Technolo!y evaluations
1D Development procedures
2D Documentation procedures
3D System software security
"m!lementation and #raining
Decription- The implementation and trainin! phase mar(s the #e!innin! of approved procurement to install the
system or support process for actual use. >or non-technical solutions' implementation may #e limited to a new
support process re$uirin! a chan!e in the #usiness process. =n cases when a prototype or pilot pro"ect is used' the
implementation may simply #e a lar!er scale deployment of a proven solution. =n cases when a sin!le system is
#ein! developed' the implementation may include si!nificant inte!ration activity and confi!uration durin! the
implementation process. >or replacement systems or si!nificant up!rades' data conversion may #e re$uired and will
#e conducted accordin! to the implementation plan and verified throu!h system@data testin!. The House
environment re$uires transition of new or replacement systems to #e done with minimal disruption to daily House
activity. -arallel operations and advance trainin! is critical to ensure continuity of services. Testin! should #e
conducted #oth for user acceptance and system specification. <perational Test and Cvaluation (<TFC) is commonly
used to ensure the system performs as the user e&pects and in compliance with the user re$uirements.
Developmental Test and Cvaluation (DTFC) is a type of testin! done to ensure compliance with the system
re$uirements and specifications. DTFC also ensures that system inte!ration is accepta#le and stress testin! is within
system specifications. The final sta!e of implementation also includes completion of documentation such as user
manuals' system drawin!s' operations manuals' and Standard <peratin! -rocedures (S<-).
-Implementation Plan
-5alidation$ 5erification and Testing Plan )may 0e in implementation plan for small projects*
-System Documentation )t!e "as 0uilt% document*
Interface ontrol Document updates
-Test Analysis Report )s!ould include security testing analysis*
-User Acceptance or System Accreditation Document/Report
Procurement Plan )sometimes called acquisition plan*
Transition Plan )sometimes called "cut4o/er plan%*
-Training Plan )may 0e included in implementation plan for small projects*
User &anuals
"a/or &a'-
=mplementation ? development and processin! of all re$uired documents (e.!.' purchase orders) to procure
e$uipment or services to deploy the system or support process. %dditional activities may include sta!in!'
inte!ration' confi!uration' and installation.
Trainin! ? trainin! should #e conducted accordin! to the trainin! plan and provide a +self sustainin!, capa#ility to
the House. The trainin! curriculum should support users as well as instructors to ensure new users are afforded an
immediate and continuous trainin! opportunity.
Documentation ? the process of formally recordin! information a#out the confi!uration of the system and the
procedures for usin! the system or support process to solve pro#lems and enhance operations. Typical documents
include user manuals' operations manuals' systems !uides' interface control documents' and maintenance !uides.
Balidation' Berification and Testin! ? testin! should #e conducted accordin! to the plan and conclusively
demonstrate that #oth the user and system re$uirements have #een met. =ndependent validation and verification
should #e used for more comprehensive pro"ects and appropriate report created to document results.
System %ccreditation ? final acceptance of the system is formali)ed throu!h the system accreditation process' which
provides ac(nowled!ment that the user and system@data re$uirements have #een met. The results of security
evaluation and analysis are included in this area and must #e accepta#le in order to complete system accreditation.
1-0; Final 3/24/99
"ana#ement Control- The implementation and trainin! phase re$uires dili!ent monitorin! of all activities
contri#utin! to system deployment. The primary mana!ement control domains related to this SDLC phase are
Acquisition 2 Implementation' and Deli/ery 2 Support. Summari)ed control o#"ectives for the deployment and
trainin! process to #e continuously reviewed for applica#ility to the pro"ect include*
0D -rocess and methods for =T ac$uisition
1D =nstallation procedures
2D Chan!e mana!ement procedures
3D Balidation' verification' and testin! strate!y@procedures
4D -rocess monitorin!
Sustainment
Decription- The pro"ect sustainment phase is dedicated to (eepin! the systems or support processes operatin! to
provide service to the customer or user. >or non-technical solutions' sustainment may #e the continuation of a
support process. Sustainment pro"ects will include periodic proactive actions identified in the ./S. Technolo!y
reviews for enhancements or updates to the software and hardware will also #e conducted. %n enhancement or
redesi!n may not chan!e the #usiness process #ut should not #e underta(en unless the current #usiness process is
validated. There should also #e periodic reviews of the #usiness process' which may lead to either an improvement
or reen!ineerin! effort. The Project Status Re/ie# should also contain after action reviews for pro"ect transition into
the sustaiment phase. -erformance measures of the sustainment process will help identify when actions or additional
pro"ects should #e initiated. Chan!e mana!ement and $uality assurance is also re$uired in this phase to ensure
thorou!h and accurate documentation of the system confi!uration.
-Performance &easures Documentation
-Program Status Re/ie#s )includes after action re/ie# for transition to sustainment*
-onfiguration &anagement Documentation
-!ange &anagement Documentation
BPI/BPR Reports
Tec!nology 1n!ancement Re/ie#s
"a/or &a'-
Sustainment %ctivity ? conduct maintenance and service activity to (eep the system operational. This includes
response to system failures and notification to users throu!h the system alert process. %ctivity also includes
proactive and preventive actions that help (eep the system from failin!. 8aintainin! updated documentation of the
system confi!uration is re$uired #y this policy and #e!ins at the pro"ect definition phase. %nother (ey element is the
control of chan!e to the system throu!h stron! enforcement of chan!e mana!ement and $uality assurance controls.
/usiness -rocess eviews ? conduct a review of the #usiness processes representin! the way the users operate under
the current policy and procedures. %ny revisions or reen!ineerin! in this area may have a tremendous impact on user
re$uirements and current system desi!n or support processes. % /-=@/- assessment should #e performed for any
replacement pro"ect initiative' which leads #ac( to the first phase of SDLC.
System eviews ? conduct periodic reviews of the system to ensure operatin! health and that software updates or
enhancements are tested and installed. Gew technolo!y may result in a technolo!y up!rade that improves
automation of the current #usiness process.
"ana#ement Control- The sustainment phase is dedicated to maintainin! systems' service' or support at optimum
levels. Control o#"ectives related to this SDLC phase overlap from mana!ement control domains of Deli/ery 2
Support' and &onitoring. Summari)ed control o#"ectives for monitorin! the development or support process' and
sustainment of the system' that should #e continuously reviewed for applica#ility to the pro"ect include*
0D Chan!e 8ana!ement
1-00 Final 3/24/99
0D =ndependent $uality assurance
1D C&ternal reviews
2D -rocess monitorin! throu!h -ro!ram Status eviews
3D eview of system and security operations
1-01 Final 3/24/99
/ppeni' /
INFORMATION RESOURCES MANA)EMENT ADVISORY COUNCIL C*ARTER
The attached charter for the =nformation 8ana!ement %dvisory Council (=8%C) is provided as re$uired #y the
C%< roles and responsi#ilities section of the SDLC policy.
%-0 Final 3/24/99
Information Reo!rce "ana#ement Adviory Co!ncil
C$arter
0. -urpose
The =nformation esources 8ana!ement %dvisory Council (=8%C) is esta#lished to coordinate information
resources plannin!' ac$uisition' development' and use within the <ffice of the Chief %dministrative <fficer and
other appropriate or!ani)ations within the House community.
1. /ac(!round
=nformation esources 8ana!ement (=8) is the mana!ement of information throu!h its entire life cycle ran!in!
from the methods of recordin! it' storin! it' and transmittin! it' to the decisions of archivin! or destroyin! it. %s an
o#"ective' =8 encompasses providin! the ri!ht information at the ri!ht time' in the ri!ht place' on appropriate
media' efficiently and at low cost' for use in ma(in! decisions' followed #y destruction or archival retention. The
efficient use of information resources is a primary concern of the Chief %dministrative <fficer. =8%C is to provide
for the efficient and effective mana!ement of information resources' institute cooperative actions to standardi)e and
improve the use of =nformation Technolo!y (=T)' telecommunications and provide an or!ani)ational means for
communication amon! the various House components on technolo!ical su#"ect matter.
2. Csta#lishment of the Council
=8%C is composed of the Chief %dministrative <fficer' %ssociate %dministrators for House =nformation
esources' servin! as Chairperson' <ffice of Human esources' 8edia and Support Services' <ffice of >inance'
<ffice of -rocurement and -urchasin!' and %dministrative Counsel. -articipation is also open to other House
offices. The <ffice of the =nspector Aeneral shall serve on the =8%C in an advisory capacity. % staff mem#er from
H= will provide administrative services and technical support for the =8%C' as re$uired.
3. Council esponsi#ilities
=8%C will meet $uarterly to consider and coordinate action at the senior mana!ement level with respect to
information resources pro!rams' pro!ress' and pro#lems' and will serve as a forum to address intra-<ffice issues.
=8%C may also esta#lish su#committees or wor( !roups to address those issues. C&amples of =8 concerns are as
follows*
(0) Data standardi)ation policy and mana!ement.
(1) System Development Life Cycle (SDLC) and Huality %ssurance.
(2) >ederal information processin! standards and industry #est practices for =T and telecommunications.
(3) =T and telecommunications re$uirements' confi!urations and interopera#ility.
(4) -rivacy and security of systems' data' and facilities.
(5) =T and telecommunications mana!ement' plannin! and #ud!etin!.
(6) 8ission implications of new hardware and software technolo!y.
(9) Computer-#ased office automation systems.
(:) =T and telecommunications technolo!y sharin!.
4. %uthority
=8%C will serve as a consultative and coordination #ody to the C%<. =8%C' as a result of e&amination of issues
affectin! =8' is to*
%-1 Final 3/24/99
(0) ecommend =8 policies' standards and !uidelines to foster user #uy-in and acceptance of the Chief
%dministrative <fficerEs =8 pro!ramI
(1) ecommend priorities for the Chief %dministrative <fficerEs =8 pro!ram initiatives (e.!.' the ac$uisition
and development of =T and telecommunications resources)I and
(2) ecommend actions needed to address the pro!ress of or pro#lems in the implementation of the Chief
%dministrative <fficerEs =8 pro!ram.
5. elationship to the C%< Technolo!y Coordination Tas( >orce (TCT>)
The =8%C provides a hi!h-level advisory role and focuses on applyin! mana!ement@technical concepts #ased on
policy' e&perience and the perspective of the C%< environment. The TCT> role is chartered to #e e&ecution oriented
(day-to- day activity) and focuses on development or implementation of concepts in response to its technical
advisory role. %s such' the two teams will re$uire continual coordination of activity and interaction.
The =8%C is open to participation #y other House offices and includes the C%< %%Js' C%< Aeneral Counsel' and
the <=A in an advisory role (<=A is not on the TCT>). The =8%C role is much more strate!ic in nature and would
not en!a!e in day-to-day activities that the TCT> is esta#lished to handle' such as schedulin! a vendor to #rief the
!roup for a pro"ect review' with discussions of process flows and re$uirements. Li(ewise' reviewin! the details of
.e#-#ased -rocurement Des(top and the #est technical direction would #e a TCT> rather than an =8%C activity.
The =8%C would' however' review a TCT> recommendation concernin! a pro"ect to ensure it fits within the !oals
and o#"ectives of the House community for technical development. %lthou!h many of the TCT> and =8%C
mem#ers are the same' their roles differ si!nificantly #etween strate!ic and operational roles of the two !roups. The
TCT> will #e more li(ely to su#stitute' or include' a representative for an %% concernin! technical matters. /oth are
re$uired to prompt technical activity to completion within desired !oals and o#"ectives of the House community.
%-2 Final 3/24/99
/ppeni' B
TEC*NOLO)Y COORDINATION TAS+ FORCE C*ARTER
The attached charter for the Technolo!y Coordination Tas( >orce (TCT>) is provided as re$uired #y the C%< roles
and responsi#ilities section of the SDLC policy.
/-0 Final 3/24/99
&ec$nolo#y Coordination &a' (orce
C$arter
0. -urpose
=t is essential that the House have a strate!ic' planed approach to the technolo!ical issues facin! it. =t is the purpose
of the Technolo!y Coordination Tas( >orce (TCT>) to provide for the development' deployment' and monitorin! of
C%< information technolo!ies and to facilitate coordination of efforts with other offices of the House and the
le!islative #ranch to the e&tent possi#le.
To this end the TCT> will develop and recommend to the C%< strate!ic o#"ectives for deployment of inter-opera#le
technolo!ical resources within the House.
=t shall #e the responsi#ility of the TCT> to assess the deployment of the technolo!ical resources within the C%<'
ta(in! into account the other offices of the House and other le!islative offices to the e&tent possi#le' and ma(e
recommendations to the C%< #ased on its assessment in con"unction with the adopted strate!ic o#"ectives. =n
ma(in! its assessments the TCT> will insure that interested parties' includin! users' are involved as an essential
component in developin! recommendations to the C%<.
=t shall #e the further responsi#ility of the TCT> to monitor deployed technolo!ical systems within the House to
ensure they continue to #e in compliance with the strate!ic o#"ectives.
The TCT> shall have as one of its (ey responsi#ilities oversi!ht of the Kear 1;;; -ro"ect and coordination of C%<
technolo!ical developments within that pro"ect.
The TCT> will also provide advice to the C%< on any other technolo!y issue the C%< may re$uest.
1. esponsi#ilities
=n the fulfillment of its purpose the TCT> shall*
0) Develop strate!ic o#"ectives for deployment of information technolo!y within the House that include #ut are
not limited to' the followin!*
0) =nter-opera#ility of software systems within the C%< and whenever possi#le the other offices of the House
as well as other le!islative #ranch offices
1) compliance with Kear 1;;; -ro"ect re$uirements
2) participation of the responsi#le offices in the assessment of needs and compliance of the technolo!y with
those needs
3) settin! of re$uirements for the implementation of technolo!ical pro"ects within the C%< such that the
strate!ic o#"ectives can #e met within accepta#le time frames
The strate!ic o#"ectives will #e comprehensive and lon! term in scope.
1) Develop and recommend to the C%< procedures for implementation of the HouseEs SDLC policy.
2) Set priorities when necessary for implementation of technolo!ical tools' where the priorities are in conformation
with the strate!ic o#"ectives.
3) Develop and recommend to the C%< procedures for monitorin! deployment of C%< technolo!ical systems so
that the strate!ic o#"ectives and SDLC re$uirements are met in the deployment.
/-1 Final 3/24/99
4) Develop and recommend to the C%< procedures for monitorin! deployed C%< technolo!y systems. Deployed
systems are to #e monitored in order to recommend' when necessary' steps for continued compliance with the
stated strate!ic o#"ectives of the House in re!ards to technolo!ical deployment.
2. Structure
The TCT> is comprised of*
% representative of the C%<
The %ssociate %dministrator and a technical representative from each of the followin! C%< or!ani)ations*
>inance <ffice
House =nformation esources
Human esources
8edia and Support Services
-rocurement and -urchasin!
Kear 1;;; -ro"ect 8ana!er
The TCT> will report directly to the C%<. The %ssociate %dministrator of House =nformation esources shall chair
it.
The TCT> may from time to time consult with and en!a!e in their deli#erations with representatives of the other
offices of the House' the le!islative #ranch' and other e&ternal or!ani)ations' as it finds useful.
3. 8eetin!s and eports
The TCT> will meet twice a month until the completion of the Kear 1;;; -ro"ect' after which it will meet monthly.
=t may also meet any other times that it finds necessary.
%dministrative functions shall #e performed #y Kear 1;;; -ro"ect 8ana!er or a su#stitute desi!nated #y the TCT>
chairman.
The TCT> will present the C%< with a formal report on a $uarterly #asis and will report at other intervals to the
C%< as either the C%< or the TCT> finds useful. =t will su#mit minutes of its re!ular meetin!s with attachments
includin! reports it has received' includin!' #ut not limited to re!ular reports from the Kear 1;;; -ro"ect 8ana!er.
The $uarterly report shall include a summary of its accomplished tas(s and a status report of outstandin! issues.
/-2 Final 3/24/99
/ppeni' C
SDLC TERMS AND DEFINITIONS
This appendi& provides definitions of terms related to the systems development environment*
Acti(ity) % state of #ein! active or performin! an operational' system' or methodolo!y process.
usiness Process) % term used to descri#e the daily activity of an or!ani)ation or !roup to conduct operations. The
#usiness process does not outline technical solutions #ut focuses on the operational process to which technolo!y or
improvement could #e applied.
usiness Process "m!ro(ement) %n effort to improve the operational or system activity (process) within the defined
operatin! concept of the or!ani)ation.
usiness Process Reengineering) %n effort to redesi!n or recreate the operational or system process due to a
si!nificant chan!e in the operatin! concept of the or!ani)ation.
'once!t of *!erations +'*,*PS-) % com#ination of drawin!s and te&t descri#in! the primary areas and
conceptual methods of an or!ani)ation conductin! activities and operations.
'ost/enefit) % comparison of the old@new e&penditures to the old@new #enefits derived from completion of the
pro"ect. The eturn on =nvestment (<=) analysis usually defines the time period re$uired to reach the more
favora#le situation.
'ustomer) The customer is the ultimate #enefactor of the service or information product. The customer needs
should provide the primary influence on how the user constructs their operatin! concept and #usiness processes.
De(elo!mental #est and .(aluation +D#/.-) % term used to descri#e testin! a system for compliance with the
system and technical re$uirements and determinin! that the system was #uilt to proper specifications.
0ife1'ycle) efers to the entire period of activity in transformin! customer needs into system or support solutions
and sustainin! activities.
&anagement 'ontrols) % comprehensive chec(list of control o#"ectives used #y #usiness process owners to ensure
thorou!h and coordinated e&ecution of the systems development life-cycle.
&et%odology) % structured approach usin! rules' procedures' and discipline to achieve desired results and
consistency in e&ecution.
*!erational #est and .(aluation +*#/.-) % term used to descri#e testin! a system for compliance to user
(operational) re$uirements and determinin! that the system meets the users performance e&pectation.
P%ases) % clusterin! of tas(s and activities that descri#es a functional area of the SDLC process.
Policy) % hi!h-level overall plan em#racin! the !eneral !oals and accepta#le procedures ? especially of a
!overnmental #ody )'e0ster6s*.
Process Flo2) % drawin! that shows the flow of processes or activities without focusin! on technical desi!n or
solutions.
Project) % planned underta(in! within a specified time period and usually consistin! of many tas(s and activities.
Prototy!e/Pilot) % scaled-down version of a support process or system that demonstrates +proof-of-concept, for a
minimal cost' and prior to committin! funds for lar!e-scale deployment.
C-0 Final 3/24/99
Requirement) Descri#es a part of a process to #e automated or enhanced in terms of capa#ilities and features. This
is a va!ue term until modified with the re$uirements type such as user' functional' system' or technical. Barious
re$uirement types include*
Data ? a description of what data elements are re$uired to conduct information processin! and where they e&ist
within the system process. =nformation access and sharin! re$uirements are usually included.
Functional ? a hi!h-level description of what processes of the operatin! concept are to #e automated or
enhanced. Usually !rouped into functional operatin! areas.
*!erational ? a description of what part of the operational (user) process should #e automated or enhanced
(interchan!ea#le with user).
System ? a description of what parts of the system process' after eliminatin! redundancies and repetitive
actions' should #e automated or enhanced (includes e&istin! system).
#ec%nical ? a description of the specifications' ran!es' protocols' or other technical information' includin! the
e&istin! system' that #ounds the desi!n process.
User ? a description of what part of the user (operational) process should #e automated or enhanced
(interchan!ea#le with operational).
Statement of 3or4 +S*3-) % listin! of tas(s that descri#e the wor( necessary to develop and implement a support
process or system meetin! the o#"ectives of the pro"ect.
Su$1system) % smaller functional area of a system that can #e analy)ed or modified #ut has an impact on the overall
system.
Systems De(elo!ment) % methodical approach to identifyin! needs and process-#ased re$uirements' and usin! a
structured process to desi!n and implement solutions.
Systems .ngineering) % practice of analy)in! and developin! systems-#ased solutions throu!hout the life-cycle
process or on desi!nated su#-systems.
System .n%ancement) %n ad"ustment to the support process or technical improvements to the e&istin! system such
as updated e$uipment or software (the #usiness process could remain the same).
System Process Flo2) % drawin! that com#ines user (operational) process flows with technolo!y concepts (not
desi!n) to reduce redundancies and repetitive actions.
System Redesign) % si!nificant chan!e in the support process or system technical components due to advancements
in technolo!y or chan!es in the #usiness process.
#as4) % piece of wor( to #e completed within a specified time period and with measura#le results. %n e&ample of
measura#le results includes documents' software' products' decisions' or analysis.
#ec%nology .(aluations) % tas( to review technolo!ies relevant to the selected #usiness processes to assist
re$uirements development and the desi!n process
#rac4 ") % term referrin! to near-term initiatives' in parallel with lon!-term efforts that provides immediate
capa#ilities for House operations. Trac( = initiatives are conducted with respect to the planned lon!-term efforts.
#rac4 "") % term referrin! to lon!-term initiatives to develop inte!rated systems or support processes and evolves
from +lessons learned, durin! Trac( = operations. Trac( == initiatives are conducted in parallel with Trac( = and
closely coordinated to ma&imi)e inte!ration and cost reduction.
C-1 Final 3/24/99
User) The user (individual or !roup) that conducts the support processes' or uses the automation technolo!y or
system' to produce a service or product for the customer. The users have the (ey role for identifyin! the #usiness
processes and the areas for possi#le automation (new system) or enhancement (e&istin! system or support process).
User Process Flo2) % drawin! that descri#es the operational activity (#usiness process) in accomplishin! the
o#"ectives and mission of the individual or !roup within the or!ani)ation.
3or4 rea4do2n Structure +3S-) % listin! of tas(s re$uired to #e accomplished in order to achieve success for a
!iven pro"ect.
C-2 Final 3/24/99

Executive Summary: U.S. House of Representatives Systems Development Life-Cycle Policy

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Executive Summary: U.S. House of Representatives Systems Development Life-Cycle Policy

Uploaded by

Copyright:

Available Formats

U.S.

House of Representatives Systems Development Life-Cycle

You might also like