SAS Global Forum 2012 Planning and Support - Paper 194-2012 - The Systems Development Life Cycle (SDLC) as a Standard

Oct 25, 2026

The paper discusses adopting the Systems Development Life Cycle (SDLC) as an organizational standard to benchmark project progress, emphasizing that documentation alone cannot replace rigorous analytical work. It explains how incomplete requirements lead to testing failures, especially when independent testers obtain more complete versions. Detailed guidance covers producing sound requirements, design, and testing protocols, with attention to planning, risk assessment, critical path analysis, and integrating legacy software retirement into SDLC.

LanguageEnglish

CategoryTechnology

FormatPDF

Pages5

Reading Time13 min

AccessFree to download

Introduction

Phases

Planning

Critical Path Analysis

Analysis - Requirements for Clinical Trials Statistical Analysis Plan (SAP)

Use case and template development

SAS Global Forum 2012 Planning and Support Paper 194-2012 The Systems Development Life Cycle (SDLC) as a Standard: Beyond the Documentation Dianne Louise Rhodes, U.S. Census Bureau, Washington DC ABSTRACT Has your company adopted the Systems Development Life Cycle (SDLC) as a standard for benchmarking progress on a project? Have they developed Word and other templates for documents created during SDLC? In three of my most recent positions, the stress was on completing the documents according to schedule, rather than emphasizing the work. The work involved cataloguing requirements, analyzing them and developing a good design document, and thoroughly testing the resulting code. When I first started programming in SAS® , I was lucky to get any users requirements at all; it was always “I’ll know it when I see it.” But with the emphasis on the documentation, and not on the analytical work behind them, the project still falls behind schedule because of missed requirements. If the requirements are not thoroughly complete when coding begins , it is likely to fail in the testing phase, especially if the independent test team gets abetter, more complete version of the requirements than the development team. We discuss the work that is involved in detail for producing sound requirements, design, and testing protocols. Consider the retirement of legacy software as part of the SDLC. INTRODUCTION PHASES The exact naming and components of the phases can vary and are adapted to your company’s specific needs and adjusted to the scope of the project (Fulton 2003) . Traditional view of the SDLC is a waterfall approach. One phase keys off the end of the previous phase. Figure 1 : Waterfall Approach Figure 2: Iterative Process A more flexible and accurate description is of an interative process. No one ever gets it exactly right the first time and an iterative process depicts this. 1 SAS Global Forum 2012 Planning and Support PLANNING In this phase, the background and scope of the SAS and other programming to complete the project are Figure 3: Gantt Chart estimated. This is done to determine the size and level of effort, staffing plans and budget. The project goals are set, and roles and responsibilities are identified. A project plan for performing the work and managing the project is developed. This should include tasks, schedules, and assignments. The project management will be implementing tracking and oversight mechanisms, configuration management activities, training, and a test plan / strategy. (Helton 2002) At this phase, documentation and validation that will be required are developed. These efforts may be described as “proof of concept.” The job is to identify risks and risk assessment of assumptions and identify the critical path (CPA) of the work. The critical path is often identified using software such as Microsoft Project. Within a project the final project plan is often in the form of a Gantt Chart (using Microsoft Project or other software for projects of medium complexity or an excel spreadsheet for projects of low complexity) . The benefit of using CPA within the planning process is to help you develop and test your plan to ensure that it is robust. Critical Path Analysis identifies tasks which must be completed on time for the whole project to be completed on time. It also identifies which tasks can be delayed if resource needs tobe reallocated to catch up on missed or overrunning tasks. The disadvantage of CPA, if you use it as the Figure 4: Critical Path Analysis SAS Global Forum 2012 Planning and Support technique by which your project plans are communicated and managed against, is that the relation of tasks to time is not as immediately obvious as with Gantt Charts. This can make them more difficult to understand. A further benefit of Critical Path Analysis is that it helps you to identify the minimum length of time needed to complete a project. Where you need to run an ac

FAQs

Why does the paper argue that documenting SDLC steps is not enough?

It argues that documentation without the underlying analytical rigor can still cause projects to fall behind schedule and fail testing when requirements are incomplete.

How do incomplete requirements affect the testing phase according to the paper?

If requirements are not thoroughly complete when coding begins, testing is likely to fail, particularly if an independent test team has a more complete version.

What is the role of Critical Path Analysis (CPA) in planning?

CPA helps identify tasks that must be completed on time, which tasks can be delayed by reallocating resources, and the minimum time needed to finish a project.

What does the paper say about the critical path example at Denver airport?

It describes failure to identify the critical path to success, where baggage handling was critical; the system underperformed, deadlines slipped, and costs increased significantly.

Oct 25, 2026

Upload by AfterMidnight