System Development Lifecycle: System Initiation Phase, Study notes of Business

Download System Development Lifecycle: System Initiation Phase and more Study notes Business in PDF only on Docsity!

S E C T I O N T H R E E

III

System Development

Lifecycle

2. SYSTEM REQUIREMENTS

SECTION III: SYSTEM DEVELOPMENT LIFECYCLE

• Introduction
• 1. SYSTEM INITIATION
• 1.1 Prepare for System Initiation
• 1.2 Validate Proposed Solution
• 1.3 Develop System Schedule
• Measurements of Success
• Phase Risks/Ways to Avoid Pitfalls
  • ANALYSIS
  • Analysis 2.1 Prepare for System Requirements
• 2.2 Determine Business Requirements
• 2.3 Define Process Model
• 2.4 Define Logical Data Model
  • with Models 2.5 Reconcile Business Requirements
• 2.6 Produce Functional Specification
• Measurements of Success
• Phase Risks/Ways to Avoid Pitfalls
• 3. SYSTEM DESIGN
• 3.1 Prepare for System Design
• 3.2 Define Technical Architecture
• 3.3 Define System Standards
• 3.4 Create Physical Database
• 3.5 Prototype System Components
• 3.6 Produce Technical Specifications
• Measurements of Success
• Phase Risks/Ways to Avoid Pitfalls - 4. SYSTEM CONSTRUCTION - 4.1 Prepare for System Construction - 4.2 Refine System Standards - 4.3 Build, Test and Validate (BTV) - System Testing 4.4 Conduct Integration and - 4.5 Produce User and Training Materials - 4.6 Produce Technical Documentation - Measurements of Success - Phase Risks/Ways to Avoid Pitfalls - 5. SYSTEM ACCEPTANCE - 5.1 Prepare for System Acceptance - and Conversion 5.2 Validate Data Initialization - (TIER) 5.3 Test, Identify, Evaluate, React - 5.4 Refine Supporting Materials - Measurements of Success - Phase Risks/Ways to Avoid Pitfalls - 6. SYSTEM IMPLEMENTATION - Implementation 6.1 Prepare for System - 6.2 Deploy System - Organization 6.3 Transition to Performing - Measurements of Success - Phase Risks/Ways to Avoid Pitfalls

4. System Construction – throughout which the Project Team builds and tests the various modules of the application, including any utilities that will be needed during System Acceptance and System Implementation. As system components are built, they will be tested both individually and in logically related and integrated groupings until such time as a full sys- tem test has been performed to validate functionality. Documentation and training materials are also developed during this phase.
5. System Acceptance – during which the focus of system validation efforts shifts from those team members responsible for developing the application to those who will ultimately use the system in the execution of their daily responsibilities. In addition to confirming that the system meets functional expectations, activities are aimed at validating all aspects 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 production setting, and transition of ownership of the application from the Project Team to the Performing Organization.

The following diagram illustrates every phase, process and deliverable in the system development lifecycle.

4 Section III System Development Lifecycle

NYS Project Management Guidebook

Section III System Development Lifecycle 5

NYS Project Management Guidebook

System Initiation

Prepare forSystemInitiation ValidateProposedSolution DevelopSystemSchedule

ValidatedSolution System RequirementsAnalysis ScheduleHigh-Level SystemDevelopmentSchedule

Validated BusinessRequirementsand Models Functional Specification

Iterative andConcurrent

System

Requirements Analysis

Prepare forSystemRequirementsAnalysis DetermineBusinessRequirements DefineProcess Model DefineLogical DataModel ReconcileBusinessRequirementswith Models ProduceFunctionalSpecification

Prepare forSystem Design DefineTechnicalArchitecture DefineSystemStandards CreatePhysicalDatabase PrototypeSystemComponents ProduceTechnicalSpecifications

Prepare forSystemConstruction RefineSystemStandards Build, Test

andValidate(BTV) Conduct Integration andSystem Testing

ProduceUser andTrainingMaterials ProduceTechnical Documentation

Prepare forSystemAcceptance Validate Data Initializationand Conversion

Test,Identify,Evaluate,React(TIER) Refine SupportingMaterials

Prepare forSystemImplementation DeploySystem Transition toPerformingOrganization

System Design

System Construction

System Acceptance

System Implementation

BusinessRequirements Process Model Logical Data Model

TechnicalArchitecture SystemStandards Databaseand SystemFiles Technical

Specifications

Unit TestResults Integrationand SystemTest Results User MaterialsTraining Materials

Revised User/Training MaterialsRevised TechnicalDocumentation

TechnicalDocumentation

DataValidationResults AcceptanceTestResults

Refined SystemStandards

SystemPrototype

Figure 0-

NYS Project Management Guidebook The System Development Lifecycle

NYS Office for TechnologyProject Management Office

Section III System Development Lifecycle 7

NYS Project Management Guidebook

analysis effort, performed at the completion of each phase. This assessment is analogous in many respects to conducting the Post-Implementation Review as described in Section I, Project Closeout, although it is typically conducted in a less formal fashion. The responsibilities of the Project Manager include assessing 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 derive ways 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 that each phase and process is completed and agreed upon before the next phase begins. The reality is, however, that phases gen- erally overlap, with each successive phase introducing changes to the work of the prior phase, resulting in an iterative process.

This SDLC is also consistent with newer techniques for system development, such as Rapid Application Development (RAD). RAD allows users to participate in an iterative design and development process. Conceptually, the project “loops” through the Design, Construction, and Acceptance phases, fol- lowed by re-Design, revised Construction, Acceptance, and so on. Project management deliverables such as the Project Scope Statement, Project Schedule, and budget estimates are refined to reflect increasing clarity of scope and requirements with each iteration.

While there is the potential to compress Requirements Analysis, 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, Project Managers must actively and diligently address the management of Customer expectations and the maintenance of current doc- umentation.

The RAD approach has advantages, since it usually achieves results quickly, the design is less abstract, and users have assurance that up-to-date requirements are considered. Its disadvantages include difficulty in controlling the process and ensuring 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 are skipped, the Project Manager must record the reasons why, and must describe how the objectives of that process/deliverable will otherwise be met.

Understanding the Breadth of System Development Projects

When assessing the scope of a system development project, it is important that the needs, goals, and challenges of the proj- ect are understood from many perspectives. The business requirements , which define the high-level Customer objec- tives and vision for the system, are used to determine the scope of the system. When capturing the business require- ments, it is essential that the Project Team look at all aspects of the system, including:  Functional Requirements – describing processes and tasks that the Consumer must be able to accomplish through 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 human interaction with the system (for example, off-hours processing or the automated exchange of information between systems).  Technical Requirements – identifying technical aspects and constraints that must be considered when defining the new system. Considerations may include accessibility needs of Consumers, whether or not the storage and

8 Section III System Development Lifecycle

NYS 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 your approach 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 overall business drivers (legislated timeframes, overall time to market, etc.).

The following diagram illustrates some representative cate- gories of requirements that the team should consider when defining 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 fundamental point is that for those considerations that do apply to the proj- ect, there will be corresponding activities required throughout each and every phase of the SDLC, all contributing to the even- tual implementation of the system. Regardless of whether the Project Team is performing System Initiation, Requirements Analysis, Design, Construction, Acceptance, or Implementation activities, they will need to understand and address the full realm of functional, technical, operational, and transitional requirements to ensure a successful project. In an attempt to reinforce this point, this diagram will be revisited in each of the individual SDLC phases that follow, drawing specific references to the processes relevant to each phase of the lifecycle.

10 Section III System Development Lifecycle

NYS Project Management Guidebook

System Development Lifecycle

Representative SDLC Considerations

System System System System System System Initiation Requirements Design Construction Acceptance Implementation Analysis

Functional Requirements

• Common Functions
• GUI Functions
• Reporting Functions
  • Interface Functions
  • Batch Functions
  • Security Functions
• Data Conversion
• Release Validation
• Documentation
  • Training
  • Deployment

Transitional Requirements

• System Performance
• Data Archival
• Audit and Controls
  • System Administration
  • SQA
  • Business Continuity

Operational Requirements

• Accessibility
• Encryption
• Hosting
  • Environment
  • Disaster Recovery

Technical Requirements

Impacts the Business Process

Impacts the System Infrastructure

Impacts Operations and Support

Impacts Implementation

Figure 0-

Section III System Development Lifecycle 11

NYS Project Management Guidebook

Software Quality Assurance

In the way that project management provides the umbrella under which all project activities are directed, software quality assurance provides the foundation on which all system develop- ment activities should occur so that the highest quality system possible will be delivered. According to the IEEE Standard Glossary of Software Engineering Terminology, quality is defined as the degree to which a system, component, or process meets specified requirements and Customer needs and expectations.

Analogous to the Quality Assurance Plan associated with the project 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 followed throughout the project.

Software Quality Assurance Processes define practices and procedures to be used by the Project Team to meet the quality standards, and to provide management with evidence that these procedures are being followed.

Software Quality Controls comprise a series of reviews and audits that evaluate deliverables with respect to defined stan- dards and acceptance criteria. These controls include software testing techniques and peer reviews.

The key to these SQA efforts is that they must be performed throughout all phases of the project. In addition, all SQA efforts should ideally be performed by a third party, independent from the team members responsible for delivering the system. Availability of staff and budget are two factors that must be considered 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 are fully and correctly captured in the first place.

Section III System Development Lifecycle 13

NYS Project Management Guidebook

The Data/Process Modeler develops and maintains data and process models to represent the business information needs in the 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 and data models into an application architecture, establishes archi- tecture guidelines, and develops strategies for the creation and distribution of applications.

Application Developers include all those responsible for developing prototypes, technical specifications, and application code, and for executing test scripts.

The Software Quality Assurance (SQA) Analyst is responsible for establishing and executing the Quality Assurance Plan, for assisting in the preparation of test scripts and test data, and for participating in integration and acceptance testing efforts.

Technical Services (HW/SW, LAN/WAN, TelCom) include all those 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 for identifying and enforcing security standards and processes.

Technical Support (Help Desk, Project Administration, Documentation, Trainers) includes all those responsible for supporting the development of the new system. Support includes 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, and supporting the project and associated administrative processes.

14 Section III System Development Lifecycle

NYS Project Management Guidebook

Figure 0-4 New York State System Development Life Cycle Templates

Phase Template Description Page Page in in Text Appendix

System Business A document containing detailed functional, 45 99 Requirements Requirements technical, operational and transitional Analysis Document requirements for the system being developed System Functional A document describing the logical grouping 59 103 Requirements 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 109 architecture 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 115 applied and adhered to throughout the project. System Design Technical Specifications A compilation of system diagrams, module 109 121 specifications, and test plans that serve as a detailed, comprehensive blueprint for the system. System Defect Log A document used to log defects 145 131 Construction encountered when performing integration, system, data validation or acceptance testing, and track their resolution.

16 Section III:1 System Initiation

NYS Project Management Guidebook

Figure 1-

System Initiation

Prepare for System Initiation

Validate Proposed Solution

Develop System Schedule

Validated Solution

System Requirements Analysis Schedule High-Level System Development Schedule

Iterative and Concurrent

System Requirements Analysis

Prepare for System Requirements Analysis

Determine Business Requirements

Define Process Model

Define Logical Data Model

Reconcile Business Requirements with Models

Produce Functional Specification

Section III:1 System Initiation 17

NYS Project Management Guidebook

List of Roles

The following roles are involved in carrying out the processes of this phase. Detailed descriptions of these roles can be found in the Introductions to Sections I and III.

 Project Manager

 Project Sponsor

 Business Analyst

 Technical Lead

List of Deliverables

The following table lists all System Initiation processes, some techniques available for use in executing these processes, and process outcomes and deliverables.

Processes Techniques Process Deliverables (Outcomes)

Prepare for System Interviews Established Team and Initiation Document Gathering and Environment for System Reviews Initiation Validate Proposed Brainstorming Validated Solution Solution Research Develop System Brainstorming System Requirements Analysis Schedule Research Schedule Estimating High-Level System Development Schedule

Figure 1-

Section III:1 System Initiation 19

NYS Project Management Guidebook

1.2 VVAALLIIDDAATTEE PPRROOPPOOSSEEDD SSOOLLUUTTIIOONN

Purpose

The purpose of Validate Proposed Solution is to make sure that the original technology decision and system development approach still represent the optimal solution for the identified business need.

Description

Considerable time may have elapsed since the Project Proposal (and its constituent Proposed Solution) was developed, due to the vagaries of the budget process or to other procedural delays. In the interim, the Performing Organization may have changed its course and the state-of-the-art technolo- gy may also have changed significantly. With rapid advances in technology, it is cer- tain that the longer the period of time between the original proposal and the com- mencement of System Initiation, the more likely it is that the chosen technology is no longer supported, has become obsolete, or commands a vanishing talent pool.

To validate the Proposed Solution, the Project Team must:

 understand the agency’s current Strategic Plan, and how

the new system fits into it;

 assess the proposed technology solution in view of

Customer needs, the Performing Organization’s long term technology direction and constraints, and state-of-the-art technology; and

 confirm feasibility of the proposed system development

approach.

Roles

 Project Manager  Project Sponsor  Business Analyst  Technical Lead

If System Initiation closely follows the development of the Project Proposal, it may not be necessary for the Project Team to perform all parts of this validation process.

20 Section III:1 System Initiation

NYS Project Management Guidebook

In assessing the Proposed Solution, the team must consider how it fits into the Performing Organization’s application port- folio of existing or proposed systems. A System Context Diagram can be used to illustrate how the new system will make use of, or add to, existing major data stores, and how it will interface with other systems identified in the Strategic Plan (extract, update, data entry, etc.).

The next step is to confirm that the Proposed Solution is still the best option for the current set of business needs and con- ditions (as they are reflected in the Project Charter project management deliverable). For example, reorganization may have dispersed Consumers over a large geographical area, necessitating a re-evaluation of the originally proposed tech- nology that was best suited to many Consumers in close physi- cal proximity to one another.