What is a software development life cycle? That’s what Will Johns came to discuss with our Seekers last month. Will describes software life cycles as a twist on system design life cycles. “It’s a generic description of a thing; a process,” he explains. “In short, it’s the feedback loop that we use to iterate on our jobs.”
A software development life cycle is composed of a number of clearly defined and distinct work phases which are used by software engineers developers to plan for, design, build, test, and deliver software systems.
Will broke out this process into 6 phases and how different roles interact with each phase.
During the planning phase, project managers work closely with the business stakeholders to evaluate capabilities and priorities. Business stakeholders can consist of product managers, business analysts, engineering managers, directors, VPs, and anyone who is in more of a strategic role and responsible for identifying initiatives that they believe will add value to the business.
“Given the selection of work you have going on in a backlog, [there’s a] group of people [who] are responsible for saying ‘these are the things most important to us in the near term’,” Will explains.
Next is the analysis phase. This is when project managers and the engineering team work together to identify and create a high-level breakdown of the goals and requirements for the planned items and lay out the scope of the project so that the engineering team can prioritize their efforts.
“[It’s] not necessarily how you would go about implementing certain tasks, but what objectives or scopes are required for those tasks.”
In the design phase, the engineering team documents a detailed description of the work needed to meet the goals and requirements identified in the analysis phase. If phase 2 defines the scope of the outcome, this phase outlines the general path towards that outcome.
The implementation phase is where “hands-go-to-keyboards,” as Will describes, and the engineering team writes the code to fulfill the items documented in the design phase. The previous two phases deal with higher level planning, but this is where things take shape.
The testing and integration phase is quite literally that, the engineering team collaborates with quality assurance to validate the implementation versus design, and integration with other software. “This is where you’re going to deploy your code out and make sure that whatever you’ve done matches the spec,” Will explains. “And additionally, that you didn’t break anything else along the way.”
After something new has been implemented, the quality assurance team monitors the deployed software internally while project managers and engineers work together to ensure the changes continue to work and also to identify other potential areas for improvement. “The feedback captured here, whether it’s a bug or optimization, goes directly back into the planning phase and the whole cycle starts over again,” states Will.
He also points out that another pipeline not connected to this process lives somewhere between Phase 6 and the return to Phase 1 – that is an input of new work from “the business.”
But how do you apply software development life cycles to software development?
“A lot of software development life cycles are built on top of a lot of traditional engineering like mechanical and industrial applications,” he explains. “So you’ll hear terms like LEAN, or Agile, and those styles are all twists on the manufacturing process.”
One of the most common processes you’ll hear about is the Agile methodology. In fact, NSS’s student project teams use this methodology. Within the Agile methodology lie 3 common frameworks, each having their own slight variations in implementation. They are Scrum, Kanban, and LEAN.
You may also hear about Waterfall, Spiral, Iterative, or Big Bang methodologies. Big Bang is most common to start ups, and Waterfall in hardware and industrial applications. However these are generally not considered to be a part of the “Agile” methodologies.
An important note on these. You may see people talk about capital A Agile vs agile. Agile, the proper noun, refers to a specific practice and set of terms, where agile the simple noun is used to refer to the company’s ability to quickly iterate and respond to business demands. That is to say it is possible to be agile, without being Agile. A confusing, but significant distinction.
Will Johns ended his talk by encouraging developers to not be afraid to ask questions about the processes their team uses. “There’s no guarantee that the way it’s being done is the best way that it could be done,” he says. Continuing to look for ways you and your team can create the best possible processes for the job is a great way to continue your growth as a developer!