Term Paper: Processes of the System Development Life Cycel (SDLC)
The following hub presents a rewritten term paper on the subject of the Software Development Life Cycle (SDLC). The original paper was submitted to fulfil the requirements for a class in System Development. The paper broke down the processes of the SDLC into the nine main components and provided a brief explanation of each.
According to Pfleeger and Atlee (2006), there are nine major activities, or processes, involved in developing software. These processes exist with relation to the Software Development Life Cycle (SDLC) at various levels. This hub will define the nine process and the major sub-processes that comprise them. The relationship to the SDLC will be included for each sub-process following the process descriptions. This hub ends with a narrative demonstrating how the methods vary for projects developed using Agile methods.
The nine processes involved in developing software are as follows:
- Requirements analysis and definition
- System design
- Program design
- Coding the program
- Unit testing
- Integration testing
- System testing
Requirements Analysis and Definition
• Define the project domain or the business problem that the system will solve. The SDLC begins with a planning phase that all other phases follow.
• Identify the stakeholders whose problem the system will solve. Stakeholders are the users and decision-makers who will ultimately determine the success or failure of a project and this activity relates to the analysis phase of the SDLC.
• Interview the stakeholders to determine the business and functional requirements of the system. Requirements gathering are also part of the SDLC analysis phase.
• Publish the results of the analysis. The stakeholders must approve and buy into the gathered requirements and signals the end of the analysis phase in the SDLC.
• Design the architecture for the system. The overall system architecture will prescribe the program components that comprise the program design. All design activities, system and program, are included in the design phase of the SDLC.
• Design the user interfaces for the system. The new system will be useless if users cannot interact with the system.
• Design the data structures that make up the system. Program designers and programmers need to know on what data the system will operate.
• Publish the completed design of the system. SDLC processes end with the publishing of results to document the system.
• Design the algorithms or business logic that the programmers will use to construct the system. These algorithms will guide programmers in implementing the design.
• Design the data flow between the system modules. Modules within the system must be capable of communication among one another.
• Design test cases to be used to validate the system. Programs must be tested to validate their functionality.
• Write the code to implement the user interfaces. User interfaces must be implemented to enable operation of the program as part of the implementation phase of the SDLC.
• Write the code to implement the business logic. These program modules solve the business problem identified in the analysis phase of the SDLC.
• Write the code to implement output from the system. Output is necessary either to feed other program modules or to present the results to the users. This activity is also part of the implementation phase of the SDLC.
• Document the program modules. Documentation of the programming activities will be used by the system delivery and maintenance activities.
• Test each module implemented during the programming activities. Individual components of the system must be tested before integration testing proceeds. The SDLC incorporates all testing in the implementation phase.
• Document the results of each module test. Documentation will be used to aid integration testing.
• Provide feedback to programmers. Feedback is used from the SDLC standpoint to aid in future programming activities.
• Test the functionality of system modules that interact with each other. Validating the interaction of interacting modules is necessary before system testing may proceed as port of the SDLC implementation phase.
• Document the results of the integration tests. The integration documentation will aid system testers.
• Provide feedback to program designers. Program designers use the feedback to aid in future activities.
• Test the operation of the completed system. Successful results of system testing will lead to system delivery as part of the SDLC implementation phase.
• Document the results of the system tests. These results can be used to aid in user training and support activities.
• Provide feedback to system designers to aid in future design activities.
• Install the system components on the stakeholders' production equipment. This point in the SDLC signals the end of the project for designers, programmers, and testers.
• Train system users on the new system and provide documentation created during the project.
• Obtain the sign-off for project completion. This activity marks the end of the SDLC implementation phase.
• Perform corrective maintenance to fix software failures discovered after system delivery. All project activities after system delivery are considered part of the support phase of the SDLC.
• Perform adaptive maintenance to incorporate changes in requirements that occur after the delivery phase. Business requirements for a system often change after the development project is complete.
• Perform preventative maintenance on the new system. Maintainers may discover design flaws after system delivery and preventative maintenance aims to ensure those flaws do not manifest as failures.
The above processes were written to expand upon the SDLC model for system design, also known as the waterfall methodology. However, a major problem of the SDLC is that the model assumes that the technical goals for a system are well-defined and the model leaves little room to resolve problems discovered later in the process (Gasson, 2003). Adjusting this document to fit Agile methodologies would give the document a less than straight appearance.
Using an agile approach, the various phases would not flow from one to another, instead many of the activities would occur simultaneously and the structure of the document would take on a less rigid form. For instance, the requirements gathering activity would continue throughout the project along with the design activities. In fact, testers would provide feedback to designers, who may modify the design and instruct programmers to make changes. The programmers would then make the changes and send the modules back to the testers who would start the iterative loop once again.
The major processes that lead to a developed system are present whether the SDLC methodology or an Agile one lead to the completed product. There are some differences in the number of times processes occur and when certain processes take place, but the processes are all there. Agile methodologies, however, provide a means for system designers to overcome some of the problems of the SDLC model for system development.
Gasson, S. (2003). Human-centered vs. user-centered approaches to information system design [Electronic version]. JITTA: Journal of Information Technology Theory and Application. 5, 22.
Pfleeger, S., L. and Atlee, J., M. (2006). Why software engineering. Software Engineering Theory and Practice (3rd ed.). Upper Saddle River, NJ: Pearson Education, Inc.
Satzinger, J., W., Jackson, R., B., and Burd, S., D. (2004). Chapter 2: Approaches to system development. System Analysis and Design in a Changing World (3rd ed.). Boston, MA: Course Technology.