How similar are a factory production floor and an office of software developers?
Imagine a room full of programmers typing code into their computers. What if you treat their output like assembled widgets off a factory assembly line? Will the things that maximize production work here, too? Or is the development process more like other engineering disciplines?
Project managers have been trying to solve this since software development began. From these questions, the definition of the software development life cycle has emerged.
It's the process of creating software from scratch. While writing code is the core activity, it's much more than that.
The development process includes ideation and design before writing any code. The planning is easy to overlook. It doesn't feel like development the way writing code does. Yet answering crucial questions first strengthens the finished product. Is the project even worth pursuing? If so, what's the best way to go about it? What features are necessary and what features are nice to have? The answers give the project a better chance of succeeding.
While the steps are constant, their application varies. The reason why is software development is a new discipline. Engineering disciplines are mature with hundreds of years of history. Software development only goes back to the late 1940s. It's still a new discipline. The agile method is only 20 years old. Yet it's one of the most influential things to happen in the theory of software creation. Regardless, the six software development life cycle phases are common to all systems.
A development team can use the software development life cycle on a whole project or one feature. The evolution of the use of the SDLC has been about reducing risk by shortening the length of each step. In a moment, we'll look more at the different methodologies. First, let's examine the steps themselves.
Also, it's worth noting that you'll see variants in terms of the number of steps or their names. Sometimes steps are merged, like development and testing. Other times, you'll see one step divided into two, like planning becoming planning and analysis. In our case, we'll stick with these six as they clearly define the phases.
The planning phase is the most important step. The stakeholders need to consider everything including the feasibility of the project itself. It's okay to kill the entire project here. A healthy organization will empower stakeholders to do so if needed. Programmers will have less involvement during this phase in an enterprise setting. Product owners, business analysts, and other stakeholders voice their needs in this step.
The planning phase is the most important step. The stakeholders need to consider everything including the feasibility of the project itself. It's okay to kill the entire project here. A healthy organization will empower stakeholders to do so if needed. Programmers will have less involvement during this phase in an enterprise setting. Product owners, business analysts, and other stakeholders voice their needs in this step.
The design stage also includes user experience (UX) design. If the application has any user-facing components, UX design is a must. This includes user research by watching real people interact with product mockups. The reason this happens in the design phase instead of the development phase is timing. User sessions take time. Often more back-and-forth discussion with business stakeholders happens too from the data gathered.
Next, the development team tests the code. The code writer and tester should be different people. Even better is a non-developer quality assurance tester. Developers tend to think of happy-path scenarios only. Dedicated QA testing professionals tend to be better at thinking about how they can break the software. They're more likely to find bugs before deployment this way. The result is more stable software at release.
Unit tests and integration tests are often automated. Often a DevOps platform runs these tests on new code before merging it into the master branch. If you have limitations in developer skills, check out trusted codeless automation testing tools to meet your business needs.
Manual testing is far from obsolete. Automated tests do the same thing over and over. Yet a person doing manual testing can find bugs by accident during testing. It's the variability in manual testing that is its strength.
A unit test verifies a method only, nothing more. The function under test is the boundary. The developer writes the unit tests, and some SDLC frameworks mandate them. Extreme Programming requires them. It also prescribes test-driven development. This is the practice of writing unit tests first. Then writing the actual program code.
Integration tests check sections or features of the codebase. They are usually automated and run by the DevOps platform. What they verify spans more than a single method. An example is verifying that an API call persisted a new record in a database. Contrast this with a unit test verifying the API method too. The unit test would only be able to verify that a call to the database should happen. The integration test can prove that data flowed through the application as expected.
The final form of testing is full system testing. To recap, unit testing verifies a function only. Integration testing verifies a feature. But system testing treats the whole application as a single unit. Smoke testing is a light form of system testing. In it, the tester interacts with the system as a natural user might and ensures it behaves as expected. Contrasted with full end-to-end system testing, which is more rigorous. A full system test checks all parts of a system as a single entity. Also, a suite of integration tests may serve as a full system test.
The deployment phase is pushing the tested code into production. Automating the deployment makes it more reliable. Also, practicing production deployments increases the odds of a smooth deployment too. The development team practices with a testing environment called a staging environment. It should be identical to the production one. The more alike the two environments are, the more value the practice deployment has.
Everything up to this point in the SDLC will only be about a quarter of the total cost of ownership. Initial development cost of software is 25% of what the business will spend. The maintenance phase will cost the business around 75% of the total cost of ownership. The defense against ballooning maintenance costs is more attention to the earlier phases. This means better technical design, development, and more thorough testing. The alternative is technical debt. Like real debt, it gets more expensive over time.
While the steps of SDLC are unchanging, their implementation and execution order varies. The variety of software development methodologies allows companies to choose the one that can significantly minimize the time, resources, and costs needed for project realization. Let's look at the most popular ways organizations do the software development process.
What makes Agile unique is the focus on people. The Agile methodologies refocused the industry's attention. Prior, the focus was on the product, the software. Agile challenged that and focused on the individuals doing the process. Also, before the Agile Manifesto, Extreme Programming (XP) and Scrum had no connection. Yet, afterward, their practitioners united under the Agile banner.
Agile isn't a framework itself. It's a framework for frameworks. At its core, it's about focusing on people and quick iterations. It's exactly what the name says, agile. Done well there's flexibility in achieving the result. Processes are never done at the expense of people, who derive value from them instead.
Another key tenant of Agile is an iterative approach. The idea is to do blocks of work in shorter chunks of time. That way the business can adapt to changes in the marketplace faster. The ability to quickly change the direction of development is what makes it agile. At the same time, the development team can learn from what it has done in each iteration and improve. Agile teams do this in retrospective meetings after each iteration.
Extreme programming (often abbreviated XP) got its start in the early 1990s. Martin Fowler was one of the original signers of the Agile Manifesto. He thinks that Agile got its popularity due to the XP framework. Additionally, he maintains it's the best way to start doing Agile software development.
XP gets its name from its approach. It takes common good software practices and requires them. That's what makes it "extreme." XP requires things like unit tests, pair programming, releasing more often.
What makes XP a unique method is:
Lean wasn't Agile technically, but it has a similar feel to it in practice. Now it's accepted as part of Agile by most. Its focus is different from traditional Agile. Per the Agile manifesto, "Individuals and interactions over processes and tools." Lean focuses more on the software than the makers.
Its roots are the Lean manufacturing principles from Toyota. Here are the seven parts that define it. If you're familiar with manufacturing Lean, these will sound similar. They are:
Scrum is the most popular Agile method. According to the 14th State of Agile report, 58% of software companies use Scrum. If you include Scum hybrids, the percentage jumps to 84%. Which begs the question, why is it the most popular?
The answer is Scrum is all about getting more work done in less time. That appeals to businesses. Each iteration in Scrum is a "sprint." The name reinforces the idea of speed. Usually, a sprint is 2 to 3 weeks long. Once a Scrum team has planned a sprint, no one should alter it. New work has to wait until the start of the next sprint. This takes discipline on the part of the business stakeholders. In practice, this Scrum rule is often violated. That's why teams report doing a Scrum hybrid often.
Another characteristic of Scrum is the Scrum Master. This is one team member nominated to be in charge of keeping the sprint on target. Often, the Scrum Master is a developer from the dev team.
The most common variant of Scrum is ScrumBan, which is a mashup of Scrum and Kanban. Kanban has its roots in the Japanese Toyota manufacturing process like Lean. It's a system of just-in-time work.
Each item of work is like an iteration all its own. A developer only works on one thing at a time. The rule is one "in-progress" item per developer. This strict work-in-progress limit shines a light on any bottlenecks. Developers track work items in progress via a Kanban board. As a side note, that's where the name comes from. In Japanese, Kanban means "signboard."
The waterfall method is the earliest of all software development practices. It predates Agile by several decades at least. This method is older than its name, too.
It's the natural way companies have always done work. It's a linear process, and you start at the beginning. First, stakeholders compile requirements. They aren't doing this for a feature or two. No, business stakeholders scope out the whole project at once. Afterward, work begins. The developers do all the work without any iterating until completion.
The waterfall way is the easiest to understand conceptually. People do one thing at a time. That said, it's the riskiest to business success. If something is off-target, stakeholders can't correct it until project completion. The reason is it won't be even noticed until the project completion.
Finished software is one of three types. These types are system, programming, and application software. To illustrate, here's a cake-baking analogy. A mixer or spatula is the programming software. It enables you to make more cakes or more software applications in this analogy. When assembling a cake, the bottom layer is the system software. It's the foundation. Without it, you can't have a layered cake. The top layer would then be the application software. It's what's visible to most casual observers.
A computer's operating system is system software. It's crucial to the usefulness of it. Imagine a computer without an operating system. You'd only be able to interact with it via machine language. That's pure binary--just ones and zeros. You'd find it impossible to work with at any level of scale. System software opens up the usefulness of a computer.
Windows, macOS, and Linux are the most popular examples of system software. Device drivers are also system software. They extend the basic functionality of an operating system. Smart devices without an operating system use firmware to enable their functionality. It is also system software.
Programming software is a subset of application software. Any program a developer uses to create new programs would classify. They range from simple text editors to complex integrated development environments (IDEs). Most developers favor more complex programming software tools. Programs like Microsoft's Visual Studio help speed development.
Application software is the most common type. It's the software that lets you do things with a computer. It makes computers useful. Popular examples are programs like Microsoft Word and Excel.
Cloud software also falls into this category. Google Docs, Dropbox, and even Instagram are application software. If you ever feel confused if something is application software or not, here's a simple test. Does the program need something else to run? Windows or Android do not. They are system software. PowerPoint, or even a game like Call of Duty do need other things running to function, which means they are application software. Without device drivers and an operating system, they can't execute.
The methods of software development are still maturing. Yet regardless of the method used, the steps remain the same. Agile teams may iterate over them quicker, and Waterfall practitioners slowly move from one to the next. Yet, to build better software, you must strengthen the process for each step. They build on each other. The software development life cycle isn't a thing without one of its steps. The parts make the whole.
Think about what would happen if you left any step out. Without planning what you are making? Without design, the development process will be haphazard. Leaving out the development step is impossible. A lack of testing ensures the product will not perform as expected. If there is no deployment, no one will have access to use the product. An unmaintained application falls into disuse. Each step is crucial for a software product's success.
Engineers develop software that makes our lives easier. A lot goes into their process because...
by Sagar Joshi
Software is eating the world.
by Dibyani Das
You might find a lot of solutions that allow you to carry out complex tasks without coding.
by Vikas Nangia