SDLC
The Software Development Life Cycle (SDLC) is a terminology used to explain how software is delivered to a customer in a series if steps. These steps take software from the ideation phase to delivery.
Last updated
The Software Development Life Cycle (SDLC) is a terminology used to explain how software is delivered to a customer in a series if steps. These steps take software from the ideation phase to delivery.
Last updated
The profession of “software developer” has existed since the first computers, and their operators, as far back as the days of ENIAC and vacuum tubes. Practices and methods for developing software have evolved over the decades since the invention of the computer.
Those methods have adapted to the state of the art in computer hardware, development tools, and modern thinking about the organizational management of software development teams. With this progress, new methods of software development have grown out of private and public software development efforts around the world.
These methods vary widely in approach, yet they share a common goal: to develop software as cheaply, efficiently, and effectively as possible.
Software is a complex product that is developed and delivered through a series of steps. That is the one thing all the various methods have in common: one way or another, software, like all products, starts as an idea. The idea then becomes a document, or perhaps a prototype, depending on the method in use.
Whether a document, diagram, or working software, the artifact created in one step becomes the input to the next step. Eventually, the software is delivered to the customer. The sequence of steps used by these methods is commonly referred to as the Software Development Lifecycle (SDLC.)
The process of software development is a never-ending cycle. The first release of a software application is rarely “finished.” There are almost always additional features and bug fixes waiting to be designed, developed, and deployed.
Reports from error monitoring software about usability and bugs feed back into the process of software development, and become new feature requests and improvements to existing features. This is why the Software Development Life Cycle is the most general term for software development methods. The steps of the process and their order vary by method. Regardless of method, they typically run in cycles, starting over with each iteration.
It’s very difficult to carry out a complex, team effort such as software development without some kind of plan. Each software development methodology (several will be detailed below) is a plan framework for how to develop software. There is much debate about which method is best overall, which is best suited to a particular type of software, and how to measure success in software development. One thing, however, is certain: any plan is better than no plan.
Without some kind of structured plan, software development teams tend to devolve into a “herd of cats.” Developers don’t know what they’re supposed to create. Project managers have no idea how much progress is made towards completion of a project. Without a plan, the business doesn’t even have a way to decide whether the final product meets their requirements.
A formally defined method for software development in the form of the SDLC achieves a number of benefits:
A common vocabulary for each step
Defined communication channels between development teams and stakeholders
Clear roles and responsibilities among developers, designers, business analysts, and project managers
Clearly-defined inputs and outputs from one step to the next
A deterministic “definition of done” that can be used to confirm whether a step is truly complete
These steps are (very) roughly the same from one methodology to another. They tend to occur in this order, though they can also be mixed together, such that several steps occur in parallel.
As we’ll discuss later, Agile methods tend to “wind together” all of these steps into a tight, rapidly-repeating cycle. Waterfall methods tend to take each of these steps in turn. Outputs from one become inputs to the following step.
The planning phase involves aspects of project and product management. This may include:
Resource allocation (both human and materials)
Capacity planning
Project scheduling
Cost estimation
Provisioning
The outputs of the planning phase include: project plans, schedules, cost estimations, and procurement requirements. Ideally, Project Managers and Development staff collaborate with Operations and Security teams to ensure all perspectives are represented.
The business must communicate with IT teams to convey their requirements for new development and enhancement. The requirements phase gathers these requirements from business stakeholders and Subject Matter Experts (SMEs.)
Architects, Development teams, and Product Managers work with the SMEs to document the business processes that need to be automated through software. The output of this phase in a Waterfall project is usually a document that lists these requirements. Agile methods, by contrast, may produce a backlog of tasks to be performed.
Once the requirements are understood, software architects and developers can begin to design the software. The design process uses established patterns for application architecture and software development. Architects may use an architecture framework such as TOGAF to compose an application from existing components, promoting reuse and standardization.
Developers use proven Design Patterns to solve algorithmic problems in a consistent way. This phase may also include some rapid prototyping, also known as a spike, to compare solutions to find the best fit. The output of this phase includes:
Design documents that list the patterns and components selected for the project
Code produced by spikes, used as a starting point for development
This phase produces the software under development. Depending on the methodology, this phase may be conducted in time-boxed “sprints,” (Agile) or may proceed as a single block of effort (Waterfall.) Regardless of methodology, development teams should produce working software as quickly as possible. Business stakeholders should be engaged regularly, to ensure that their expectations are being met. The output of this phase is testable, functional software.
The testing phase of the SDLC is arguably one of the most important. It is impossible to deliver quality software without testing. There is a wide variety of testing necessary to measure quality:
Code quality
Unit testing (functional tests)
Integration testing
Performance testing
Security testing
The best way to ensure that tests are run regularly, and never skipped for expediency, is to automate them. Tests can be automated using Continuous Integration tools, like Codeship, for example. The output of the testing phase is functional software, ready for deployment to a production environment.
The deployment phase is, ideally, a highly automated phase. In high-maturity enterprises, this phase is almost invisible; software is deployed the instant it is ready. Enterprises with lower maturity, or in some highly regulated industries, the process involves some manual approvals. However, even in those cases it is best for the deployment itself to be fully automated in a continuous deployment model. Application Release Automation (ARA) tools are used in medium and large-size enterprises to automate the deployment of applications to Production environments. ARA systems are usually integrated with Continuous Integration tools. The output of this phase is the release to Production of working software.
The operations and maintenance phase is the “end of the beginning,” so to speak. The Software Development Life Cycle doesn’t end here. Software must be monitored constantly to ensure proper operation. Bugs and defects discovered in Production must be reported and responded to, which often feeds work back into the process. Bug fixes may not flow through the entire cycle, however, at least an abbreviated process is necessary to ensure that the fix does not introduce other problems (known as a regression.)
The importance of a central source control repository cannot be overstated. Development teams that do not use source control are taking risks, both with the code, and their process. Using source control reduces risk by ensuring that work (code) is gathered together in a single place, on a regular basis. If a developer workstation or file server fails, the central repository saves the day. Modern Source control systems also support Continuous Integration.
The purpose of Continuous Integration (CI) is to keep the software in a functional state. Prior to the common use of CI, development teams would write thousands of lines of code, then attempt to integrate them. This integrating that much work all at once is tedious, painful, and prone to error. CI is an automation that builds software every time the code changes. If there is a problem, the CI system alerts the developers. Following proper CI practices, no further work is done until the build is successful. This prevents errors and defects from progressing into software that should be as bug-free as possible.
Large, complex software development efforts can be unwieldy and difficult to track. An entire class of software systems has grown around this problem: Application Life Cycle Management. The larger the effort, the more indispensable these systems become. They offer features in work management, bug tracking, and analytics to assist in decision making.
All software begins as a concept, and flows through a series of phases until a release is developed and deployed. The Software Development Life Cycle of an application or system continues, with updates and new features, until the day it is decommissioned or replaced. Several methods for software development have evolved over the decades.
Waterfall methods are still common, though Agile is rapidly overtaking it in companies large and small. Whichever method you choose, use the right tools for the job. Software is difficult to delivery reliably without them. There is no perfect method, but it’s far better to use some method than none.
