Software (Systems) Development Life Cycle
Software Development Life Cycle (SDLC) is a process for designing and building quality software. The goal is high quality software that meets the customer’s needs. It also takes into account the amount of time needed to develop the software along with the cost of development. This includes cost of developer hours, software licenses, operations, and system requirements. It is a detailed plan to not only build but also maintain software. Each stage in the life cycle has it’s own inputs, processes, and outputs.
SDLC offers a basis for project planning, scheduling, and estimating, as well as providing a framework for a standard set of activities and deliverables. It is designed for project tracking and control so that it increases visibility of project planning to all involved in the the development process, from stakeholders to developers and QA.
SDLC underlies many of the most popular project management methodologies. It is the base class of project management from which many methodologies inherit. One of the most well known and misunderstood is Waterfall. This is the oldest and one of the simplest methodologies. Each stage must be completed before the next one begins, it waterfalls into the next one. The biggest issue is that a small error or detail missed can hold up the entire project.
The next most common methodology is Agile. This separates the application into cycles and delivers a working product for each iteration. It involves creating a succession of releases where testing creates a feedback into the development of the next iteration. The biggest issue here is if the customer doesn’t know what they need or gets lost in the weeds of a feature they can derail the process.
The iterative model is similar to Agile. In it the development team quickly creates an initial version of the application. Through testing it is improved on each successive version or iteration. If left unchecked this process can devour resources.
There are many more methodologies within SDLC which are based on those listed above. Most of them try to solve a particular problem found in one of the previous ones. Each one could be it’s own episode just to go into all the details of it.
As developers, especially early on in our careers, we may only see the bottom portion of this cycle. Most of the time we aren’t interested or involved in the high level decisions about projects and which ones to pursue. However, it is a good idea to understand what is going on so that you know what has already been done before work comes your way. More advanced and lead developers may be involved in some of the decisions or at least consulted on them. Use this information to help you understand what your managers are needing at each stage of this process.
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.
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.
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.
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 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.
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.
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.
The penultimate chapter, 11, is about teaming up. In the intro Kutner talks about a dream job where all health related services were available on site. The first section is call message-passing. Kutner starts off by assigning the goal of hosting a lunch and learn for your coworkers based on a single chapter of this book. The idea is one we’ve discussed on the show several times, that by teaching you are learning the material even more. In the next section Kutner talks about investing in your health and how healthy employees are better employees. He provides six pillars to an effective wellness program: get the boss involved, use carrots, get personal, make it free, partner up, and send a strong message. Next he goes into playing well with others and describes how to play dodgeball, every developers favorite middle school past time. In the final section, building a better team, he talks about the psychology behind building a team. He offers three goals for team building: give the team a name, compete with other teams, and set group goals. Take aways from this chapter are to discuss your health with others and show your enthusiasm for becoming healthier.
Tricks of the Trade
Understand the SDLC both in terms of how your development process works, but also in terms of who has the power in the organization. Move closer to the power and you’ll have more power too, and usually more money.