SDLC is a common topic for designers, developers and engineers. This is a 6 Part series designed to provide an overview of the process and act as the foundation for developers to understand what is expected during each stage of the process.
Designing complex systems is always important for any company. The smaller organizations tend to let some aspects relax too far in order to maintain timelines and profitability. The problem with this is that there is a significant lack of quality, durability and stability in the product’s first few versions. In a similar extreme, large companies spend so much time on process that the products are often delayed past intended release dates. In both cases, there are problems can be viewed in several subtle levels.
In order to understand the problem it is important to provide a quick overview of the Software Development Life Cycle (SDLC). The SDLC has five basic tiers which include Requirements, Design, Development, Testing and Maintenance. Each is important in its own right and needs to be considered. The image displays the SDLC in a waterfall style relationship. This is easy to follow however more aggressive methodologies are currently employed in organizations to produce faster results through simplification of some of the steps.
All projects are based on requirements. The requirements of a project can be provided from several different areas. Each has a unique perspective on the concept and may interpret them differently. It is critical that everyone involved in the project understands the requirements and can agree on them.
When gathering the requirements the analyst needs to speak with the end user, development and the business in order to ensure that all needs are met. The user will provide nontechnical requirements and expectations of the project. Development will provide the technical design requirements necessary to build the project. The business will provide any financial, internal user or functional requirements necessary in addition to the user requirements. Each has its place and is necessary. The analyst must distill them down into something reasonable to design but still provide the desired needs for the system.
The design phase is handled by two separate tasks. The first is the Business Analyst (BA) who gathered the requirements and compiled them. The next step for the BA is to build the Business Requirement Document (BRD) that is necessary for the development staff to start the design of the system. The BRD must be signed off by the different departments to ensure that the requirements, project intent, and design concepts are accurate. When this is done it will be passed to the Software Designer for further expansion.
The Software Designer or Architect has the responsibility to take the BRD and refine it into a Systems Requirement Specification Document (SRS). There are additional documents that may need to be designed for the database, user interface, data flow, or other conceivable documents. The other documents can be provided in brief within the SRS and if a more detailed document is necessary the specific document will be provided for the project.
Both documents are reviewed by the design and development teams to ensure that the original requirements are still valid and have not changed without reason. If there are changes to the initial requirements then either the BRD or the SRS will need to be refined to incorporate the corrections prior to development.
The development team has the second hardest job during the SDLC process. The developers must turn the provided documentation into a practical application that will provide all of the requirements and still be easily maintainable. If the requirements, BRD or SRS are unclear the developer must interpret the requests and make the best judgment available to resolve all of the requirements. If there is a conflict of interest or in requirements then the developer must get with the analysts to work out a resolution. When the project is completed the developer is finished with the software it is ready to be passed on to the next stage.
Testing is handled through the Quality Assurance (QA) Department. This department could range from a single member handling the patch testing from time to time or a dedicated department that is highly structured. The team that handles the QA process needs to know the system that is being tested but also how the users can, should and should not use the system. By having a list of scenarios to test the team will be able to resolve any potential problems quickly and notify the development or design staff of the problems so that they can be fixed prior to deployment. Once the project passes all of the tests that the QA department can imagine the project is ready for deployment.
Project maintenance is typically handled through bug reports and issue trackers. After a project, sub project, or task has been deployed to the production environment a final series of tests are handled by the QA team periodically. These production tests are normally handled when it is first deployed and for several releases afterword. The intent is to look for any potential issues that were missed prior to deployment.
However, the majority of issues or bugs found in the production environment are discovered by the actual user base. Sometimes internal error reports are generated and relayed to the development staff but often they are communicated through a form on the site. The maintenance cycle for a project is never ending and some companies will maintain an older version of the application for security fixes while developing the newest technology. This is not always the case but it is still common enough that people will submit an issue ticket on a project that may be near end of life or end of maintenance.
The development team will prioritize anything found during the maintenance cycle and work with the QA team to ensure that it is truly an issue and that it requires a fix depending on the release cycle and style of the company.
The SDLC can be a highly complicated process and for an in depth understanding it is important to review and examine each step and its sub-steps in turn. However, by having at least a fundamental understanding of the SDLC anyone who needs to take part in the process will be better equipped to accept the responsibility and to assist the other team members with the overall process to ensure the final product release is a successful one.
next
SDLC Part 2, Requirements
SDLC Part 3, Design
SDLC Part 4, Development
SDLC Part 5, Testing
SDLC Part 6, Maintenance
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)