SDLCNYSITS.org / Sarah Lauser
Saturday, April 24, 2010
PRE-TEST QUESTIONS
What does SDLC stand for?
Name at least 3 standard SDLC deliverables.
How are SDLC and Project Management related?
Give examples for each type of requirement -functional, technical, operational, and transitional.
Describe at least 2 SDLC methodologies.
Saturday, April 24, 2010
SYSTEM DEVELOPMENT
LIFECYCLE
Saturday, April 24, 2010
6 PHASES
Saturday, April 24, 2010
PHASE 1System Initiation
Saturday, April 24, 2010
DELIVERABLESValidated Solution, System Schedule
Saturday, April 24, 2010
PHASE 2System Requirements Analysis
Saturday, April 24, 2010
DELIVERABLESBusiness Requirements, Process Model,
Logical Data Model, Functional Specification
Saturday, April 24, 2010
PHASE 3System Design
Saturday, April 24, 2010
DELIVERABLESTechnical Architecture, System Standards,
Database, Prototype, Technical Specification
Saturday, April 24, 2010
PHASE 4System Construction
Saturday, April 24, 2010
DELIVERABLESRefined System Standards, Unit/Integration/System Test
Results, User and Training Materials, Documentation
Saturday, April 24, 2010
PHASE 5System Acceptance
Saturday, April 24, 2010
DELIVERABLESData Validation Results, Acceptance Test Results,Refined Training Materials and Documentation
Saturday, April 24, 2010
PHASE 6System Implementation
Saturday, April 24, 2010 Saturday, April 24, 2010
Saturday, April 24, 2010
Integrating SDLC with the Project Management Lifecycle
Saturday, April 24, 2010
SDLC Methodologies
Waterfall
Fountain
Saturday, April 24, 2010
SDLC Methodologies
V
Saturday, April 24, 2010
SDLC Methodologies
frequent "releases" in short development cyclesfrequent "releases" in short development cycles
Agile real-time communication
XP pairs programming
JAD users participate in the SD process
LD adding value to the customer
RAD minimal planning, rapid prototyping
Scrum product backlog, daily standup meetings
Saturday, April 24, 2010
REQUIREMENTS
Saturday, April 24, 2010
FUNCTIONAL
Saturday, April 24, 2010
TECHNICAL
Saturday, April 24, 2010
OPERATIONAL
Saturday, April 24, 2010
TRANSITIONAL
Saturday, April 24, 2010
Saturday, April 24, 2010
SQASoftware Quality Assurance
Saturday, April 24, 2010
SQA
Software Quality Standards
Software Quality Assurance Processes
Software Quality Controls
Saturday, April 24, 2010
PROJECT ROLES
Facilitator
Business Analyst
Database Administrator
Data/Process Modeler
Technical Lead/Architect
Application Developers
SQA Analyst
Technical Services
Information Security Officer
Technical Support
ator
eler
rchitect
pers
ty Officer
Saturday, April 24, 2010
BREAK REVIEW
What does SDLC stand for?
Name at least 3 standard SDLC deliverables.
How are SDLC and Project Management related?
Give examples for each type of requirement -functional, technical, operational, and transitional.
Describe at least 2 SDLC methodologies.
Saturday, April 24, 2010
GLOSSARYMmmmm.... Alphabet Soup
Saturday, April 24, 2010
BCP/DRBusiness Continuity Planning
Disaster Recovery
Saturday, April 24, 2010
BPRBusiness Process Re-engineering
Saturday, April 24, 2010
CMMCapability Maturity Model
Saturday, April 24, 2010
CASEComputer-Aided Software
Engineering
Saturday, April 24, 2010
CSSQcost, scope, schedule, quality
Saturday, April 24, 2010
CSFCritical Success Factor
Saturday, April 24, 2010
CRUDcreate, read, update, delete
Saturday, April 24, 2010
ERDEntity Relationship Diagram
Saturday, April 24, 2010
GUIGraphical User Interface
Saturday, April 24, 2010
JADJoint Application Design
Saturday, April 24, 2010
LAN/WANLocal Area NetworkWide Area Network
WLANWireless Local Area Network
Saturday, April 24, 2010
MT/CSMulti-Tier/Client-Server
Saturday, April 24, 2010
RADRapid Application Deployment
Saturday, April 24, 2010
SEISoftware Engineering Institute
Saturday, April 24, 2010
TQMTotal Quality Management
Saturday, April 24, 2010
UMLUnified Modeling Language
Saturday, April 24, 2010
WBSWork Breakdown Structure
Saturday, April 24, 2010
REVIEW QUESTIONS
Saturday, April 24, 2010
QUESTION 1
____________ is the process of translating a task into a series of commands that a computer will use to perform that task.
A. Project design
B. Installation
C. Systems analysis
D. Programming
Saturday, April 24, 2010
QUESTION 2
____________ spend most of their time in the beginning stages of the SDLC, talking with end-users, gathering information, documenting systems, and proposing solutions.
A. Business analysts
B. Project managers
C. Network engineers
D. Database administrators
Saturday, April 24, 2010
QUESTION 3
The ____________ determines whether the project should go forward.
A. feasibility assessment
B. opportunity identification
C. system evaluation
D. program specification
Saturday, April 24, 2010
QUESTION 4
A _______ is used to schedule the time it will take to complete computer tasks or program development.
A. WBS
B. Gantt chart
C. data flow diagram
D. data dictionary
Saturday, April 24, 2010
QUESTION 5
Within data flow diagrams, the transformations that occur within the lowest level are described by
A. development methodologies
B. structure charts
C. selection constructs
D. process specifications
Saturday, April 24, 2010
QUESTION 6
Which of the following is the tool used by database designers to document a conceptual data model?
A. Entity-Relationship diagram
B. Partition statement
C. Matrix diagram
D. Data-flow diagram
Saturday, April 24, 2010
QUESTION 7
Technical writers generally provide the ____________ for the new system.
A. programs
B. network
C. analysis
D. documentation
Saturday, April 24, 2010
QUESTION 8
In a systems development process, users are made active members of development project teams. This is an example of
A. RAD
B. JAD
C. Waterfall
D. documentation
Saturday, April 24, 2010
QUESTION 9
The stage in a system’s life cycle in which logical and physical specifications are produced is called
A. initiation
B. design
C. construction
D. acceptance
Saturday, April 24, 2010
QUESTION 10
In most organizations, the entire system-building effort is driven by
A. availability of packaged applications
B. existing hardware
C. user training requirements
D. user information requirements
Saturday, April 24, 2010
S E C T I O N T H R E E
IIISystem Development
Lifecycle
Introduction 3
1. SYSTEM INITIATION 15
1.1 Prepare for System Initiation 18
1.2 Validate Proposed Solution 19
1.3 Develop System Schedule 23
Measurements of Success 25
Phase Risks/Ways to Avoid Pitfalls 26
2. SYSTEM REQUIREMENTSANALYSIS 31
2.1 Prepare for System Requirements Analysis 36
2.2 Determine Business Requirements 38
2.3 Define Process Model 49
2.4 Define Logical Data Model 51
2.5 Reconcile Business Requirements with Models 54
2.6 Produce Functional Specification 56
Measurements of Success 63
Phase Risks/Ways to Avoid Pitfalls 64
3. SYSTEM DESIGN 71
3.1 Prepare for System Design 76
3.2 Define Technical Architecture 78
3.3 Define System Standards 85
3.4 Create Physical Database 92
3.5 Prototype System Components 94
3.6 Produce Technical Specifications 97
Measurements of Success 120
Phase Risks/Ways to Avoid Pitfalls 121
4. SYSTEM CONSTRUCTION 129
4.1 Prepare for System Construction 134
4.2 Refine System Standards 136
4.3 Build, Test and Validate (BTV) 137
4.4 Conduct Integration and System Testing 142
4.5 Produce User and Training Materials147
4.6 Produce Technical Documentation 148
Measurements of Success 149
Phase Risks/Ways to Avoid Pitfalls 151
5. SYSTEM ACCEPTANCE 157
5.1 Prepare for System Acceptance 162
5.2 Validate Data Initialization and Conversion 163
5.3 Test, Identify, Evaluate, React (TIER) 165
5.4 Refine Supporting Materials 170
Measurements of Success 171
Phase Risks/Ways to Avoid Pitfalls 172
6. SYSTEM IMPLEMENTATION 177
6.1 Prepare for System Implementation 181
6.2 Deploy System 183
6.3 Transition to Performing Organization 187
Measurements of Success 188
Phase Risks/Ways to Avoid Pitfalls 189
SECTION III: SYSTEM DEVELOPMENT LIFECYCLE TABLE OF CONTENTS
3
Section III IntroductionThere are currently many different methodologies employed for system devel-opment projects within New York State agencies. Many methodologies aredriven by the application development tools, by the software architecturewithin which the application will operate, or by the “build versus buy” deci-sion. There are standard phases and processes, however, that all systemdevelopment projects should follow, regardless of environment and tools. Thissection describes the standard phases and major processes of the New YorkState System Development Lifecycle (SDLC), using a common language andin sufficient detail to enable a Project Manager to plan and manage a systemdevelopment project.
System Development Lifecycle Overview
The material in this section is organized according to a generic system devel-opment lifecycle. While no two development efforts are exactly alike, all proj-ects should progress through the same six phases:
1. System Initiation – in which the Business Case and Proposed Solutiondeveloped during Project Origination are re-examined to ensure that theyare still appropriately defined and address an existing organizationalneed. This validation effort provides the Project Team with the basis fora detailed schedule defining the steps needed to obtain a thoroughunderstanding of the business requirements and an initial view ofstaffing needs. In addition, a high level schedule is developed for sub-sequent system development lifecycle phases.
2. System Requirements Analysis – in which the needs of the businessare captured in as much detail as possible. The Project Manager leadsthe Project Team in working with the Customers to define what it is thatthe new system must do. By obtaining a detailed and comprehensiveunderstanding of the business requirements, the Project Team can devel-op the Functional Specification that will drive the system design.
3. System Design – which builds upon the work performed during SystemRequirements Analysis, and results in a translation of the functionalrequirements into a complete technical solution. This solution dictatesthe technical architecture, standards, specifications and strategies to befollowed throughout the building, testing, and implementation of the sys-tem. The completion of System Design also marks the point in the proj-ect at which the Project Manager should be able to plan, in detail, allfuture project phases.
4. System Construction – throughout which the Project Team builds andtests the various modules of the application, including any utilities thatwill be needed during System Acceptance and System Implementation.As system components are built, they will be tested both individually andin logically related and integrated groupings until such time as a full sys-tem test has been performed to validate functionality. Documentationand training materials are also developed during this phase.
5. System Acceptance – during which the focus of system validationefforts shifts from those team members responsible for developing theapplication to those who will ultimately use the system in the executionof their daily responsibilities. In addition to confirming that the systemmeets functional expectations, activities are aimed at validating allaspects of data conversion and system deployment.
6. System Implementation – the final phase of the lifecycle, which com-prises all activities associated with the deployment of the application.These efforts include training, installation of the system in a productionsetting, and transition of ownership of the application from the ProjectTeam to the Performing Organization.
The following diagram illustrates every phase, process and deliverable in thesystem development lifecycle.
4 Section III System Development LifecycleNYS Project Management Guidebook
Section III System Development Lifecycle 5NYS Project Management Guidebook
Sys
tem
In
itia
tio
n
Prep
are
for
Syst
em
Initi
atio
n
Valid
ate
Prop
osed
So
lutio
n
Deve
lop
Syst
em
Sche
dule
Valid
ated
Solu
tion
Syst
em R
equi
rem
ents
Anal
ysis
Sch
edul
eHi
gh-L
evel
Sys
tem
Deve
lopm
ent
Sche
dule
Valid
ated
Bus
ines
sRe
quire
men
ts
and
Mod
els
Func
tiona
l Spe
cific
atio
n
Itera
tive
and
Conc
urre
nt
Sys
tem
R
eq
uir
em
en
ts A
na
lysi
s
Prep
are
for
Syst
em
Requ
irem
ents
Anal
ysis
Dete
rmin
e Bu
sine
ss
Requ
irem
ents
Defin
e Pr
oces
s M
odel
Defin
e Lo
gica
l Dat
a M
odel
Reco
ncile
Bu
sine
ss
Requ
irem
ents
with
Mod
els
Prod
uce
Func
tiona
l Sp
ecifi
catio
n
Prep
are
for
Syst
em D
esig
n
Defin
e Te
chni
cal
Arch
itect
ure
Defin
e Sy
stem
St
anda
rds
Crea
te
Phys
ical
Da
taba
se
Prot
otyp
e Sy
stem
Co
mpo
nent
s
Prod
uce
Tech
nica
l Sp
ecifi
catio
ns
Prep
are
for
Syst
em
Cons
truct
ion
Refin
e Sy
stem
St
anda
rds
Build
, Tes
t an
d Va
lidat
e (B
TV)
Cond
uct
Inte
grat
ion
and
Syst
em T
estin
g
Prod
uce
User
and
Tr
aini
ng
Mat
eria
ls
Prod
uce
Tech
nica
l Do
cum
enta
tion
Prep
are
for
Syst
em
Acce
ptan
ce
Valid
ate
Data
Initi
aliz
atio
n an
d Co
nver
sion
Test
, Id
entif
y,
Eval
uate
, Re
act
(TIE
R)
Refin
e Su
ppor
ting
Mat
eria
ls
Prep
are
for
Syst
em
Impl
emen
tatio
n
Depl
oySy
stem
Tran
sitio
n to
Perfo
rmin
g Or
gani
zatio
n
Sys
tem
De
sig
nS
yste
m C
on
stru
cti
on
Sys
tem
Ac
ce
pta
nc
eS
yste
m I
mp
lem
en
tati
on
Logi
cal D
ata
Mod
el
Proc
ess
Mod
el
Busi
ness
Requ
irem
ents
Tech
nica
lAr
chite
ctur
e
Syst
emSt
anda
rds
Data
base
and
Syst
emFi
les
Tech
nica
lSp
ecifi
catio
ns
Unit
Test
Resu
lts
Inte
grat
ion
an
d Sy
stem
Te
st R
esul
ts
User
Mat
eria
lsTr
aini
ng M
ater
ials
Revi
sed
User
/Tr
aini
ng M
ater
ials
Revi
sed
Tech
nica
l Do
cum
enta
tion
Tech
nica
lDo
cum
enta
tion
Acce
ptan
ceTe
st
Resu
lts
Data
Va
lidat
ion
Resu
lts
Refin
ed S
yste
mSt
anda
rds
Syst
emPr
otot
ype
Figu
re 0
-1 N
YS P
roje
ct M
anag
emen
t Gui
debo
okTh
e Sy
stem
Dev
elop
men
t Life
cycl
e
NY
S O
ffic
e fo
r Tec
hnol
ogy
Pro
ject
Man
agem
ent
Off
ice
Mapping the Project Management and System Development Lifecycles
The phases of the system development lifecycle generally alignwith the phases of the project management lifecycle; however,SDLC phases do not correspond one-to-one with the projectmanagement phases. One of the challenges for system devel-opment projects is aligning the SDLC with the project manage-ment lifecycle. The following diagram demonstrates how thephases of the two lifecycles may be integrated.
In reality, each phase of the SDLC can be thought of as a mini-project in itself, requiring planning, execution, and analysis. Asthe Project Team proceeds through the project, they will needto create a clear and detailed plan for the phase immediately infront of them, along with a higher-level view of all remainingphases. As the team executes each phase, they will collectadditional information that will enable the detailed planning ofsubsequent phases. Some of this information will be a naturalby-product of having performed the processes associated withthe current phase (e.g., as the detailed technical design evolvesthroughout the System Design phase, the team will have amuch better understanding of the modules that will need to bebuilt during construction, and will therefore be able to refineany prior estimates and plans for System Construction).Additional information can be obtained through a focused
6 Section III System Development LifecycleNYS Project Management Guidebook
Project Management Lifecycle
System Development Lifecycle
ProjectOrigination
SystemInitiation
SystemRequirements
Analysis
SystemDesign
SystemConstruction
SystemAcceptance
SystemImplementation
ProjectInitiation
ProjectPlanning
ProjectCloseout
Project Executionand Control
Figure 0-2
Section III System Development Lifecycle 7NYS Project Management Guidebook
analysis effort, performed at the completion of each phase. Thisassessment is analogous in many respects to conducting thePost-Implementation Review as described in Section I, ProjectCloseout, although it is typically conducted in a less formalfashion. The responsibilities of the Project Manager includeassessing how closely the phase met Customer needs, high-lighting those aspects of the phase that worked well, identify-ing lessons learned and best practices in an attempt to deriveways to improve upon processes executed throughout the proj-ect, and, most importantly, communicating results.
The SDLC defined in this section may appear to have charac-teristics of a classic “waterfall” approach, which assumes thateach phase and process is completed and agreed upon beforethe next phase begins. The reality is, however, that phases gen-erally overlap, with each successive phase introducing changesto the work of the prior phase, resulting in an iterative process.
This SDLC is also consistent with newer techniques for systemdevelopment, such as Rapid Application Development (RAD).RAD allows users to participate in an iterative design anddevelopment process. Conceptually, the project “loops”through the Design, Construction, and Acceptance phases, fol-lowed by re-Design, revised Construction, Acceptance, and soon. Project management deliverables such as the ProjectScope Statement, Project Schedule, and budget estimates arerefined to reflect increasing clarity of scope and requirementswith each iteration.
While there is the potential to compress RequirementsAnalysis, Design, and Construction in RAD approaches, com-pression introduces increased risks. It is important, therefore,to include risk analysis in each iteration of the design, build,and evaluate loop. When a prototype is presented, ProjectManagers must actively and diligently address the managementof Customer expectations and the maintenance of current doc-umentation.
The RAD approach has advantages, since it usually achievesresults quickly, the design is less abstract, and users haveassurance that up-to-date requirements are considered. Itsdisadvantages include difficulty in controlling the process andensuring the creation of an acceptable product.
In any approach, the basic SDLC processes must be performed– what differs is the timing of their execution. As with the proj-ect management methodology, if processes or deliverables areskipped, the Project Manager must record the reasons why, andmust describe how the objectives of that process/deliverablewill otherwise be met.
Understanding the Breadth of System Development Projects
When assessing the scope of a system development project, itis important that the needs, goals, and challenges of the proj-ect are understood from many perspectives. The businessrequirements, which define the high-level Customer objec-tives and vision for the system, are used to determine thescope of the system. When capturing the business require-ments, it is essential that the Project Team look at all aspectsof the system, including:
! Functional Requirements – describing processes andtasks that the Consumer must be able to accomplishthrough the use of the system. These can typically be categorized as processes that require action on the part of Consumers (data entry, selection of a system command,etc.), and those that are not directly related to humaninteraction with the system (for example, off-hours processing or the automated exchange of informationbetween systems).
! Technical Requirements – identifying technical aspectsand constraints that must be considered when defining thenew system. Considerations may include accessibilityneeds of Consumers, whether or not the storage and
8 Section III System Development LifecycleNYS Project Management Guidebook
Many factors may impact your choice of approach to follow when developing a system.The better you know your Customers and Stakeholders, and the better you understand
the factors that may influence their assessment of the project, the more likely it will be that yourapproach will suit their personalities, preferences, vision, and needs.
The key is to pick the approach that you believe will provide the best complete solution, bal-ancing the preferences of your Customers, the abilities of your Project Team, and the overallbusiness drivers (legislated timeframes, overall time to market, etc.).
Section III System Development Lifecycle 9NYS Project Management Guidebook
handling of data must follow specified encryption regula-tions, or whether the system will operate on internalagency hardware or will be hosted at either an internal orexternal data center.
! Operational Requirements – specifying any administra-tive constraints or expectations that must be supported bythe system. These requirements may include system performance expectations, technical infrastructure constraints, security mechanisms that must be followed,the need to regularly archive data, and any mandated audit and control processes.
! Transitional Requirements – defining the realm of conditions that must be satisfied prior to physically implementing the system in a production environment, orto relegating support responsibilities to the PerformingOrganization. Data conversion requirements and develop-ment and delivery of Consumer training programs andmaterials fall into this category.
Formally organizing thoughts along these four dimensions willdrive the identification of tasks to be performed beginning inSystem Initiation and continuing throughout the lifecycle. TheProject Manager is responsible for creating this broad view ofrequirements and communicating it to the Project Team, estab-lishing a pattern that should be carried throughout all projectphases.
The following diagram illustrates some representative cate-gories of requirements that the team should consider whendefining tasks and activities throughout the system develop-ment project.
It should be noted that not all considerations may be applica-ble to every project, and additional categories may be discov-ered that are not represented in the diagram. The fundamentalpoint is that for those considerations that do apply to the proj-ect, there will be corresponding activities required throughouteach and every phase of the SDLC, all contributing to the even-tual implementation of the system. Regardless of whether theProject Team is performing System Initiation, RequirementsAnalysis, Design, Construction, Acceptance, or Implementationactivities, they will need to understand and address the fullrealm of functional, technical, operational, and transitionalrequirements to ensure a successful project. In an attempt toreinforce this point, this diagram will be revisited in each of theindividual SDLC phases that follow, drawing specific referencesto the processes relevant to each phase of the lifecycle.
10 Section III System Development LifecycleNYS Project Management Guidebook
System Development Lifecycle
Representative SDLC Considerations
System System System System System SystemInitiation Requirements Design Construction Acceptance Implementation
Analysis
FunctionalRequirements
• Common Functions• GUI Functions• Reporting Functions
• Interface Functions• Batch Functions• Security Functions
• Data Conversion• Release Validation• Documentation
• Training• Deployment
TransitionalRequirements
• System Performance• Data Archival• Audit and Controls
• System Administration• SQA• Business Continuity
OperationalRequirements
• Accessibility• Encryption• Hosting
• Environment• Disaster Recovery
TechnicalRequirements
Impacts theBusiness Process
Impacts theSystem
Infrastructure
ImpactsOperations and
Support
ImpactsImplementation
Figure 0-3
Section III System Development Lifecycle 11NYS Project Management Guidebook
Software Quality Assurance
In the way that project management provides the umbrellaunder which all project activities are directed, software qualityassurance provides the foundation on which all system develop-ment activities should occur so that the highest quality systempossible will be delivered. According to the IEEE StandardGlossary of Software Engineering Terminology, quality is definedas the degree to which a system, component, or process meetsspecified requirements and Customer needs and expectations.
Analogous to the Quality Assurance Plan associated with theproject management lifecycle, software quality assurance pro-grams should be comprised of three components – quality stan-dards, quality assurance processes, and quality controls.
Software Quality Standards define the programming stan-dards, and development/testing standards to be followedthroughout the project.
Software Quality Assurance Processes define practices andprocedures to be used by the Project Team to meet the qualitystandards, and to provide management with evidence that theseprocedures are being followed.
Software Quality Controls comprise a series of reviews andaudits that evaluate deliverables with respect to defined stan-dards and acceptance criteria. These controls include softwaretesting techniques and peer reviews.
The key to these SQA efforts is that they must be performedthroughout all phases of the project. In addition, all SQA effortsshould ideally be performed by a third party, independent fromthe team members responsible for delivering the system.Availability of staff and budget are two factors that must beconsidered in determining the feasibility of applying an inde-pendent SQA Analyst or team to the project. In developing the
As will be stressed throughout the following chapters, it should be noted that simply meeting requirements is not enough to guarantee a successful system development
effort. Ultimately, Customer needs and expectations can be met only if the requirements arefully and correctly captured in the first place.
overall system development plan, the Project Manager needs toallocate sufficient time and resources to perform the appropri-ate level of SQA activities, and must obtain management com-mitment to providing these resources as called for in theProject Schedule.
Project Roles and Responsibilities
As presented in the Section I Introduction, Project Roles andResponsibilities, there are many groups of people involved inboth the project and project management lifecycles. Whenstaffing system development projects, there are a number ofroles that should be considered. It should be noted that theSDLC only provides details to the phase and process level,whereas the PM lifecycle further decomposes activities down toindividual tasks. As a result, while the roles identified within theSDLC are representative of those that are typically required in asystem development effort, the function of the role as it relatesto a given SDLC process may not be specifically described with-in that process narrative.
The Project Team consists of a Project Manager and a variablenumber of Project Team members who are responsible for plan-ning and executing the project. Team members specific to theSystem Development Lifecycle are described below.
The Facilitator leads sessions to identify business requirementsand issues, keeps sessions focused and productive, draws outissues and ideas from all participants, and maintains clear andopen communications within the session.
The Business Analyst effectively leads discussions with theCustomers to determine the business requirements, participatesin preparing the data and process models, prepares module spec-ifications, test data, and user documentation materials, assistsin prototyping activities, and develops strategies for testing andimplementation.
The Database Administrator is responsible for providing andmaintaining database administration policies and procedures,approving and executing database scripts, performing databasetuning activities, and transforming a pictorial representation ofthe system data (the Logical Data Model) into physical databasetables that support the final system.
12 Section III System Development LifecycleNYS Project Management Guidebook
Section III System Development Lifecycle 13NYS Project Management Guidebook
The Data/Process Modeler develops and maintains data andprocess models to represent the business information needs inthe area under study, develops and defines the data dictionary,validates models with the Customers, and participates in pro-totyping.
The Technical Lead/Architect drives the logical process anddata models into an application architecture, establishes archi-tecture guidelines, and develops strategies for the creation anddistribution of applications.
Application Developers include all those responsible fordeveloping prototypes, technical specifications, and applicationcode, and for executing test scripts.
The Software Quality Assurance (SQA) Analyst is responsiblefor establishing and executing the Quality Assurance Plan, forassisting in the preparation of test scripts and test data, andfor participating in integration and acceptance testing efforts.
Technical Services (HW/SW, LAN/WAN, TelCom) include allthose responsible for the ordering, installation and main-tainence of hardware and software components, LAN/WAN com-ponents and telecommunications components.
The Information Security Officer (ISO) is responsible foridentifying and enforcing security standards and processes.
Technical Support (Help Desk, Project Administration,Documentation, Trainers) includes all those responsible forsupporting the development of the new system. Supportincludes the documentation of user, training, operation materi-als, and help files, training for Customers, responding to tech-nical and business questions forwarded to the Help Desk, andsupporting the project and associated administrative processes.
14 Section III System Development LifecycleNYS Project Management Guidebook
Figure 0-4 New York State System Development Life Cycle Templates
Phase Template Description Page Page inin Text Appendix
System Business A document containing detailed functional, 45 99Requirements Requirements technical, operational and transitionalAnalysis Document requirements for the system being
developed
System Functional A document describing the logical grouping 59 103Requirements Specification of related processes and the mapping of Analysis those processes to business requirements
and data items.
System Design Technical Architecture A document describing the system 81 109architecture in terms of hardware, software, tools and peripherals, and the distribution of system components and processes across this architecture.
System Design System Standards A document detailing the standards to be 87 115applied and adhered to throughout the project.
System Design Technical Specifications A compilation of system diagrams, module 109 121specifications, and test plans that serve as a detailed, comprehensive blueprint for the system.
System Defect Log A document used to log defects 145 131Construction encountered when performing integration,
system, data validation or acceptance testing, and track their resolution.