The Software Development Life Cycle (SDLC) - …

1 The Software Development life Cycle ( sdlc ). Document ID: REF-0-02. Version: 1 / 22. The Software Development life Cycle ( sdlc ) REF-0-02. For small to medium database applications Version 2. The Software Development life Cycle ( sdlc ) REF-0-02. For small to medium database applications Version TABLE OF CONTENTS. INTRODUCTION .. 4. THE sdlc WATERFALL .. 4. ALLOWED VARIATIONS .. 5. OTHER sdlc MODELS .. 6. 7. GENERIC STAGE .. 8. KICKOFF 8. INFORMAL ITERATION PROCESS .. 9. FORMAL ITERATION PROCESS .. 9. IN-STAGE ASSESSMENT PROCESS.

2 10. STAGE EXIT PROCESS .. 11. sdlc STAGES .. 12. 12. PLANNING 13. REQUIREMENTS DEFINITION STAGE .. 14. DESIGN STAGE .. 16. Development STAGE .. 17. INTEGRATION & TEST STAGE .. 18. INSTALLATION & ACCEPTANCE STAGE .. 19. CONCLUSION .. 20. SCOPE 20. PROGRESSIVE ENHANCEMENT .. 20. PRE-DEFINED STRUCTURE .. 21. INCREMENTAL PLANNING .. 21. 3. The Software Development life Cycle ( sdlc ) REF-0-02. For small to medium database applications Version INTRODUCTION. This document describes the Software Development lifecycle ( sdlc ) for small to medium database application Development efforts.

3 This chapter presents an overview of the sdlc , alternate lifecycle models, and associated references. The following chapter describes the internal processes that are common across all stages of the sdlc , and the third chapter describes the inputs, outputs, and processes of each stage. Finally, the conclusion describes the four core concepts that form the basis of this sdlc . THE sdlc WATERFALL. Small to medium database Software projects are generally broken down into six stages: Project Planning Requirements Definition Design Development Integration & Test Installation & Acceptance The relationship of each stage to the others can be roughly described as a waterfall, where the outputs from a specific stage serve as the initial inputs for the following stage.

4 During each stage, additional information is gathered or developed, combined with the inputs, and used to produce the stage deliverables. It is important to note that the additional information is restricted in scope; new ideas that would take 4. The Software Development life Cycle ( sdlc ) REF-0-02. For small to medium database applications Version the project in directions not anticipated by the initial set of high-level requirements are not incorporated into the project. Rather, ideas for new capabilities or features that are out-of-scope are preserved for later consideration.

5 After the project is completed, the Primary Developer Representative (PDR) and Primary End-User Representative (PER), in concert with other customer and Development team personnel develop a list of recommendations for enhancement of the current Software . PROTOTYPES. The Software Development team, to clarify requirements and/or design elements, may generate mockups and prototypes of screens, reports, and processes. Although some of the prototypes may appear to be very substantial, they're generally similar to a movie set: everything looks good from the front but there's nothing in the back.

6 When a prototype is generated, the developer produces the minimum amount of code necessary to clarify the requirements or design elements under consideration. No effort is made to comply with coding standards, provide robust error management, or integrate with other database tables or modules. As a result, it is generally more expensive to retrofit a prototype with the necessary elements to produce a production module then it is to develop the module from scratch using the final system design document. For these reasons, prototypes are never intended for business use, and are generally crippled in one way or another to prevent them from being mistakenly used as production modules by end-users.

7 ALLOWED VARIATIONS. In some cases, additional information is made available to the Development team that requires changes in the outputs of previous stages. In this case, the Development effort is usually suspended until the changes can be reconciled with the current design, and the new results are passed down the waterfall until the project reaches the point where it was suspended. The PER and PDR may, at their discretion, allow the Development effort to continue while previous stage deliverables are updated in cases where the impacts are minimal and strictly limited in scope.

8 In this case, the changes must be carefully tracked to make sure all their impacts are appropriately handled. 5. The Software Development life Cycle ( sdlc ) REF-0-02. For small to medium database applications Version OTHER sdlc MODELS. The waterfall model is one of the three most commonly cited lifecycle models. Others include the Spiral model and the Rapid Application Development (RAD). model, often referred to as the Prototyping model. SPIRAL lifecycle . The spiral model starts with an initial pass through a standard waterfall lifecycle , using a subset of the total requirements to develop a robust prototype.

9 After an evaluation period, the Cycle is initiated again, adding new functionality and releasing the next prototype. This process continues, with the prototype becoming larger and larger with each iteration. Hence, the spiral.. The theory is that the set of requirements is hierarchical in nature, with additional functionality building on the first efforts. This is a sound practice for systems where the entire problem is well defined from the start, such as modeling and simulating Software . Business-oriented database projects do not enjoy this advantage.

10 Most of the functions in a database solution are essentially independent of one another, although they may make use of common data. As a result, the prototype suffers from the same flaws as the prototyping lifecycle described below. For this reason, the Software Development team has decided against the use of the spiral lifecycle for database projects. RAPID APPLICATION Development (RAD) / PROTOTYPING lifecycle . RAD is, in essence, the try before you buy approach to Software Development . The theory is that end users can produce better feedback when examining a live system, as opposed to working strictly with documentation.