Planning
Planning focuses on the scope of the project. This involves resource allocation, both human and material. It also involves scheduling, capacity planning, and cost estimation. Planning looks at who and what is needed for a project compared to what other projects or commitments have demands on them.
The challenge here is to identify the problem and if it is feasible to solve. Cost/Benefit analysis is a large part of the challenge here. The team determines the costs and risks involved in the project. Then they compare that with the benefit of completing the project. There are several types of feasability checks for the team to assess. The economic check asks if the project can be completed based on the budget for it. Legal checks ask about regulatory requirements and laws with in the business domain. Technical checks ask if the current system can support the new application. The schedule check asks if the project can be completed on a given schedule.
Outputs of planning are project plans, schedules, cost estimation, and procurement requirements. Project managers will collaborate with development, operation, and security to ensure all perspectives are represented. These plans will include strengths and weaknesses of the current system(if there is one) and of the proposed new application.
Requirements
The focus here is on gathering requirements from stakeholders and Subject Matter Experts (SMEs). This involves communication between the business and the development teams. Business analysts who can speak both business language and technical jargon are invaluable here. The bridge the gap and act as translators helping the development team understand what is needed by the business.
Risk reduction is the main challenge at this stage. Risks are identified and documented. Sub-plans are made for each risk to reduce it’s impact on the project.
Outputs vary based on the particular methodology that you are using. Waterfall typically produces a document listing out all the requirements for the whole project. Agile, on the other hand, create a backlog of tasks to be completed.
Designing
Use of established architectural and design patterns becomes the focus in this stage. Architects may use a framework like TOGAF (The Open Group Architectural Framework) to create an application that fits the standards with other applications. Developers determine design patterns to use when solving problems. There may even be rapid prototypes created to determine the best solution to a problem.
The challenge at this stage is to incorporate stakeholders without ostracizing the non-technical members. Getting stakeholder input is important to ensure the project is solving the right problem. They will need to review the plan in order to offer feedback and suggestions. It’s important that they be able to get an idea of the project without being overwhelmed by technical details.
Both a high-level and low-level design document will be created here. High-level design documents give an overview of the project and it’s interactions with existing systems. This may include the name, outline, and brief description of each module. Interface relationships and dependencies between modules will be listed. Database information including schema and table names along with a few key elements. Low-level design documents get into the details of the project. These provide information about the functional logic of the modules along with listings of error messages. Complete details of the interfaces and any issues of dependency. Database information includes data types and sizes.
Developing
The focus of the development stage is on building the application based on the outputs of the previous stages. Depending on the SDLC methodology chosen, this may be done as one large block of work or combined with the stages around it in time-boxed sprints. This is the “working phase” of all these stages, where the developers are heads down coding.
If the previous stages have been done correctly this should be the least complicated. Developer’s biggest challenges will be around assigning or choosing tasks to complete. Other issues that may arise revolve around solving problems that do not fit into the existing standards. This could be because the business process or the technology is new.
This stage produces a viable product or application. If doing Agile each sprint or iteration will produce a potentially viable product. In Waterfall the team works on development until the application is complete.
Testing
Testing focusses on delivering a quality product. There are many different ways to measure quality including unit and integration testing, performance testing, penetration and security testing, and code quality compared to standards. When tests fail or defects are found the application returns to development to fix the issue. A key to good testing is to be able to continue testing other areas of the application even after a defect is found.
The biggest challenge in testing is consistency. Testers need to ensure that tests are run regularly and not skipped or ignored. This means rerunning tests when a new version or build comes from development. The best way to avoid these issues and ensure tests are run every time a new version comes from development is to automate them.
The target output in this stage is bug-free software that runs as expected. From here it is going to the production environment so it needs to be free of issues. Another part of testing is making sure that the application actually meets the needs of the client. Not only does this involve testing the code and quality assurance but getting users in for User Acceptance Testing.
Deploying
The deployment phase focuses on getting the application out to the public. This may be a limited release where user feedback is used to improve the application. Ideally deployment is fully automated and almost invisible. However in some industries regulatory requirements make that not possible so manual approvals are needed. In either case continuous deployment using release automation tools needs to be the standard.
Making sure the code runs and the application functions in production is the biggest challenge at this stage. Testing environments should replicate production environments. If the application depends on other apps or packages which have not been moved up to production then there will be issues. Security in production may be different than test and development so permissions need to be checked as well. Problems in deployment are rather frustrating as many times they have to do with configuration issues.
The goal here is to get the application moved into the production environment. If the application depends on something not in the production environment then that either needs to be added to the environment or the application needs to back to development. The application needs to work in the production environment just as it worked in test and development.
Maintenance
The focus of the maintenance stage is to ensure that the needs continue to be met by the application. Businesses grow and change over time so their applications need to be able to adjust to the changes in the business. If needs placed on an application change or new needs arise the maintenance stage is here to address these changes.
Once the application is deployed three things will need to be addressed: bug fixes, upgrades, and enhancements. Bugs may be found because testing did not consider a particular scenario or the users found something that wasn’t considered a bug in testing. Zero day vulnerabilities or deprecation of support for a product used in development may require an application to be upgraded to a newer version. Enhancements add new features to the existing applications, this could be from user request, regulatory requirement, or even changes in business functions.
The output of the maintenance stage is a better application in production. This will involved going back through the previous stages for the change being made. What makes this a life “cycle” is that this stage leads back into the planning to make the change. Depending on how you view it, this stage either encompasses all the previous ones or restarts the process for each change.