What Small and Medium Businesses should know about Software Development Lifecycle

Everything’s already been said, but since nobody was listening, we have to start again. © Andre Gide

The power of technology nowadays became obvious to everyone. We are living in storming waves of digital transformations. This is especially relevant for small and medium business organizations. At some time, the company is willing to move from do-everything-yourself mode to something more conventional and trending. So, how should SMBs (small-to-medium businesses) approach the challenge?

SDLC is The Heart of Each Well-Functioning Tech Business

You may wonder, but each small or medium organization utilizes SDLC in one way or another, even sometimes not recognizing it. They deliver the product, build new features, test it, deploy it to target audiences, and so on.

The variations of such activities without proper knowledge are a complete wonder and chaos at the same moment. But if the business wants to take its operation seriously, it should consider looking at the fundamentals of the software development lifecycle for better quality, efficacy, velocity, and delivery.

Especially the technology businesses. All the business units within the organization are serving the single goal — to produce a healthy and competitive product. To make the outcome efficient, better to have an outlined, clean and structured definition of the process that meets the following requirements:

• Clear separation of responsibilities (who does what and when)
• The transparent representation of the state of work at any given time
• Simple and yet effective enough process to be used outside of engineering
• Easily accessible set of artifacts that can be composed into an audit trail

Given the requirements above, let’s take a closer look at what the SDLC should generally look like.

The Big Picture

The diagram above depicts the fundamental building blocks for each software development lifecycle. The implementation of each, though, may vary depending on the company’s strategy, business goals, specifics of the technology, and so on. We will unveil some generic details later in the following article, but for now, let’s define what each block is about:

• Design: turning business requirements into software requirements
• Development: all the activities held to produce a versioned product
• Quality Assurance: ensuring the product is actually working flawlessly
• Delivery: moving the whole thing from engineering to the target audience

What is worth mentioning is that each of the phases is subject to cross-functional coordination and cooperation. The design phase would include stakeholders, product management, and engineering leads. The development phase is a joint work of project management and engineering departments. QA phase is just about everybody in the company engaged in building a product. Delivery is also a matter for multiple departments: development operations, delivery, marketing, sales, etc.

Let’s dive into each phase and see what common activities are held there.

Design Phase

The design phase is the vaguest, uncertain and, as a result of the previous two, the most difficult part of the software development lifecycle. You can get a whole pack of complications: scope creeps, schedule shifts, resource starvation, and others if you don’t treat it thoroughly. If you work this out correctly, chances are you won’t screw it in the next phases.

UX Prototypes: Any requirement breakdown should inevitably fall into UX/UI designer’s hands. The information flow and human interaction with the software are absolutely crucial and dramatically affect the software architecture outline. Designers should produce rough mockups of the future state of the UX/UI to give some insights to architects on how the system should act from a functional perspective: synchronous/asynchronous, scheduled/immediately executed, queued/stacked, and so on.

High-Level Design: This piece of work should outline the ability of the system to cover both functional and non-functional requirements of the system. Note, that the HLD documentation is often used for non-technical communication, so it should be written at a minimum level of technical jargon and consist mostly of the “bird’s eye” view of the system planned for implementation. How is it done? Take the prototypes for function definition and refine business requirements for non-functional constraints.

Specifications: This is a single or a set of documents logically combined into software requirement specifications that can be handed over to the engineering department for implementation. Consider having accurate wireframes of UI representation, high-level architecture definition, actors to be incorporated into the system, and use cases describing the information flow.

A short summary of the process:

• Define the use cases, actors, and information flow
• Produce rough mockups and reiterate over them to envision the UX/UI
• Refine the non-functional requirements and produce a high-level design
• Once the previous items are ready, create software requirements specs

Development Phase

Development, contrary to popular opinion, is by far the simplest and easiest phase to tackle. If you think a bit over the diagram, you may notice that the development phase is limited from both sides: “Design” and “Quality Assurance” respectively. So, as long as you keep these boundaries on a high-quality level, you can work the development out with whatever experience of the development team you have at your disposal.

Planning: The following piece of work should produce a meaningful work breakdown structure (WBS) document. Decomposition and overall expertise are the keys here. WBS should represent the implementation plan divided by actionable items for developers to work on. Either task, epics, features, or whatever. Think of WBS as an implementation plan that you can assess, plan, schedule, control, monitor, and change.

Coding: “Getting stuff done” piece of the SDLC. Any coding activity (either as an individual or team effort) should result in a tangible artifact that can be shipped and versioned. Given the software requirements specification documentation and work breakdown structure provided to the engineering team, it should be by far the simplest task in the whole lifecycle. Don’t overcomplicate it.

The software development phase as a whole is a far more vast topic and won’t be considered here; however, we covered just enough to explain its role in the software development lifecycle.

Quality Assurance Phase

This is where quality and satisfaction are being engendered. The following phase encompasses a couple of crucial activities: defect analysis, test plan execution, and bug hunting. Consider the QA phase as the warden of quality and continuous delivery.

Pre-Deployment: This is an integral part of the QA phase overall. At this point, the potential release candidate build should be delivered to a dedicated environment for testing execution (commonly called “Staging Environment”). The following process helps to uncover a whole set of system issues: version mismatches, data migration issues, backward compatibility problems, and many more, related to the system as a whole.

Test Cases / Plan: The mother of quality and success. It consists of writing meaningful test cases for the dedicated feature. These sets of cases are put together into a test plan — an activity to be executed for a specific set of functionality that covers a business case.

Manual/Automated Testing: Yet another “GTD” piece of work, where it is being executed according to the aggregated test plans or being run through the test automatization system. Another crucial piece of work here is also customer defect analysis, where you provide reported investigation results about the issue mentioned by the end user, and estimate the escalation level and urgency of the fix.

Delivery Phase

Everything we did in the previous three phases was to gather the artifacts we need for proceeding with the one most important phase: delivery of a product to our customers. And it is not only about deploying the codebase to production.

Pre-Deployment: It is certainly a good idea to deliver the product to pre-production environments; in most cases — this would be a beta environment exposed to loyal customers; the core idea here is to let the change settle down in a less-critical environment to collect issues that are likely to slip the Q/A phase.

Go to Market: The release has to be announced and advertised. The whole go-to-market step is about preparing marketing materials and engaging existing and potential target audiences with the upcoming release. It is also a critical part of aligning the actual changelog of the version to the expectations set by the marketing department and making sure you’re going to fulfill the expectancy.

Go Live: You are ready to roll! But make sure you have a rollback plan if something goes wrong. This is usually a coordination step between delivery, operations, marketing, and engineering departments aimed to deliver seamless or near-seamless deployment.

Summary

So at this point of reading, you should get a decent familiarity with the way of handling the product delivery from 0 to 1. Let’s create a bullet list of the key points in nailing down the whole SDLC process:

• Gathering requirements
• Design phase: convert requirements into software specifications.
• Development: get things done and produce a shippable artifact.
• Quality Assurance: set up a bar for quality and continuous monitoring of the state of the product.
• Delivery: align market expectations, set up success metrics, and conquer the world.

Key Takeaways

The process described in the following article is completely agnostic to any modern project management & software development methodologies: Agile, Waterfall, Lean, etc. In fact, it is fairly complementary to the latter. You can reiterate steps in each of the phases, or conduct a rigid planning action to deliver the product in an old-fashioned way.

You may have noticed that each step in the process results in a tangible artifact. And this is how it should be. Artifacts, kept along the way, help you to conduct audit trails aimed at constant improvement of the processes used. Here’s a list of artifacts that are usually produced:

• Design phase: UX/UI wireframes, high-level design, and SRS
• Development phase: WBS, shippable and versioned product
• Quality assurance: Test cases, test plans, analysis reports
• Delivery: Marketing materials, briefs, release-candidate artifacts

Moreover, in case you have a step with no artifact, you should eliminate it or reconsider its purpose to actually produce one.