Dissecting SDLC within SMB

10 min readMay 7, 2021

A supposedly short paper on a Software Development Lifecycle (SDLC) within a Small-to-Medium Business environment. Now you might be thinking something along the lines of “why? there is a ton of them”… Well, here’s the thing: 99% of those approaches to SDLC have no correlation with the real world’s BPs within SMB. An approach would typically range from an idealistic “smoothie-driven-unicorn-startup-SDLC” down to a “we-are-20-years-old-corp-full-of-dinosaurs-SDLC”; and none of those are even remotely close to how a typical SMB operates on a daily basis.

Target Audience

So whom this paper is for? Generally speaking, it’s intended for Software Architects and for senior technical management (of any Small-to-Medium business that is not a startup) whose focus is making a transition from a “garage-band” kind of operations up to the “executed-as-planned” approach, more common in the world of business.

However, a long-lasting effect of fiddling with an SDLC within any SMB (especially a one that deals with technology) would touch on pretty much every department within a company; meaning — everyone will have to deal with it, one way or another (depending on how much mess you will create or eliminate by tampering with SDLC).

Why Bother with SDLC?

Well, here is why: while you might not quite recognize this, most of the business processes within your SMB would actually be shaped around an SDLC you’re using. Now, depending on how good your predecessors were — this might range from “good enough” down to “mother please take me home”. Oh, and also there’s an exceptional case, when you might think you’re not using an SDLC, which is wrong: there is always an SDLC in place, but sometimes, in rare cases, it’s been so badly treated that it’s never been defined in-writing…

Problem Statement

We need an SDLC that would be reflecting on the real process as close as possible, so that we can arrange and orchestrate all the other business processes around it in an actually useful way. Now the first problem, or rather a common pitfall is copy-pasting the existing mess you’re calling a process and entitling this an “SDLC”. Yes, a good SDLC should somewhat be modeled against the existing processes, but not too far. Our endgame is a depiction of a process that’s both: realistic & healthy.

The Usual Suspects (Requirements)

A state of development at any time must be represented within SDLC
If there are any short-circuits (early ins & outs) — those must be defined
Our SDLC must be simple enough to be used outside of engineering
Segregation and indication of the responsibility zones: who does what
Every step of the SDLC has to produce an auditable paper trail (artifact)

The Rough Draft

So here’s the very basic SDCL that we are going to start off. It’s a bird’s-eye view over the real SDLC for SMBs that we are going to end up with, by the end of this paper. Our simplified process begins with the business requirements; ends with a product hitting our end-users. There are four key stages we’re going to work with:

Design: turning business requirements into software requirements
Development: turning S/W requirements into a working thing
Quality Assurance: marking sure it works and behaves as intended
Delivery: getting a product from engineering to consumers

SDLC: Design

Technical design is a centerpiece of the entire SDLC: if you get this wrong — nothing else will matter at the end of the day. Believe it or not — getting a technical design of your product right — is about 50% of the success. As in: it’s going to be much harder to screw everything up when you’ve got a decent design for your product. So let’s take a look at the bare minimum “Design” stage of our SDLC.

Prototyping: grind through the supplied requirements and create a quick-and-dirty mock up of the user experience; requirements can be supplied in any form or shape, depending on the maturity of the business environment: a piece of napkin from a CEO or a 50-pages-long document from the operations; it’s a good practice to iterate this phase multiple times (check in with management on every iteration to make it’s going towards the desired experience).
Software Architecture / High-Level Design: get the prototype of user experience, combine with the supplied business requirements, and produce an HLD of how this UX should be implemented (on a grand scale) to be tightly integrated within the current ecosystem; it’s a good practice to keep the details at a satisfactory minimum: often SA/HLDs are being shared with 3-rd parties for different purposes: integration, potential B2B partnership, etc.
Specifications: produce an SRS (Software Requirements Specification) by combining the prototype, the SA/HLD, the business requirements initially supplied and potentially more materials into a single document that would be handed off to the engineering to produce the actual product or feature; we’ll get into more details about this in the upcoming sections.

Now that we have covered the three basic steps for the “Design” phase, let’s take some time to make a set of brief remarks; these are going to be short notes that will increase the chances of your SDLC not going terribly wrong:

Always start with the UX prototype as a first step
Iterate over the UX prototype until everyone thinks it’s perfect
Once it’s perfect — iterate over it again and remove non-critical things
Never mix the SA/HLD as a part of any other phase: it’s separate
Keep the level of details within HLD at a sufficient minimum
Always assume that an HLD may be shared with 3-rd parties
Take on SRS only once prototype & HLD are finalized

SDLC: Development

Unlike what most of the nerds think — this is the least important phase of the SDLC. As long as you have got the “Design” phase and the “QA” phases right — you can get away with pretty much anything during the “Development” phase. As in — if you got the designs perfect and your QA team is a bunch of berserks — it does not really matter how sloppy your developers are or how cheap did you get them…

Planning: assess all the materials produced during the “Design” phase, and create a Work Breakdown Structure (WBS) that will represent an implementation plan broken down by tasks per developer; group the tasks by high-level deliverables, such as features or stories to be able to work through the plan efficiently, and to be able to gauge the completeness of the plan.
Coding: by far the easiest part of getting everything right; given the WBS — produce the code according to the SRS provided; don’t overthink, don’t overcomplicate — write as little code as possible to satisfy the requirements; conduct weekly evaluations of the progress: adjust the WBS every iteration.

We are not going to talk much about the actual software development phase in this paper, since it’s a considerably vast topic that is way outside of our current scope. Speaking in terms of SDLC however, the “Development” phase is a fairly trivial and it’s quality largely depends on how well have you implemented the “Design” phase.

SDLC: Quality Assurance

Assuring quality of the product (or a change set) does not boil down to eliminating bugs from a product after the development phase; it actually spans much more than that and encompasses operations: defect analysis and similar routines. Setting up the “QA” phase of your SDLC will let you provide exceptional delivery, continuously.

Pre-Deployment: an often underestimated integral part of the QA process; essentially — this is delivering a build (a change set) to a dedicated environment, such as staging, by the means of CI/CD (in most cases); if done right — it will uncover a whole cluster of bugs: migrations, backward compatibility, version mismatches and a lot of other problems that pertain to debugging deliveries.
Test Cases + Plan: a cornerstone to the entire “QA” phase; consists of writing out meaningful test-cases and aggregating those into buckets knows as test plans; a way of writing out the cases should be prescribed by a policy: a key piece here is to write cases in a way where any QA engineer (even from an outside of the company) will be able to walk through such a case.
Manual Testing: carrying out manual testing of a delivery against the test cases (aggregated into test plans) crafted in the previous step; the secondary entry point for manual testing is defect analysis: verification & investigation of a defect reported by customers (early adopters or fully-fledged ones). The result of a manual testing must be concluded in a protocol that captures all the essential information about this delivery along with the “known issues”, if any.

In this chapter about quality assurance — I am deliberately omitting the QA testing automation. Although such automation is incredibly efficient in terms of operational expenses — it’s a part of a whole different topic; the one that has a substantial amount of quirks when exercised within a Small-to-Medium-Business environment. This falls under a somewhat in-depth topics that hopefully I am going to cover in the next series of papers about getting SMBs to tick right, in a business-efficient manner.

SDLC: Delivery

Everything we did in the previous three phases was in order to gather artifacts we need for proceeding with the one most important phase: delivery of a product to our customers. And no, unlike what most of you think — this is not about deploying code to production environment, since deployment is only a first little step of the roll-out.

Pre-Deployment: lets start off by deploying our delivery against 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 set “rest” on a less-critical environment to collect issues that are likely to slip the Q/A phase. The most common pipeline is to deploy to staging and then go for beta.
Go to Market: the most important thing that often gets ignored; this step needs to be executed well before actually deploying to production. The gist of this step actually require a entire book to be written about this. But to keep it short: all the marketing materials need be prepared and well aligned with that has been delivered to the pre-production environments (in a previous step).
Go Live: a key for getting the go-live step right is to coordinate the deployment: the goal is to make the transition seamless, and if not that — then at least a butter-smooth one; on top of that — make sure all the marketing materials prepared within the GTM step is getting exposed at the time of deployment. In order to cover for all bases — prepare the rollback plan before going live.

The last phase of the cycle is actually all about coordination; the specifics of how to properly coordinate is going to be well differentiated based on the factors that are fairly specific to the business & technological environment you’re operating in. The general rule of thumb here is to have a high-level delivery plan; and for that plan to be effective — you must have check-ups on a regular basis (weekly, etc).

Aftermath

If you have gotten this far into the paper — then by now you would have a pretty decent idea of how would a structure of a viable SDLC look like. The SDLC we have depicted in here is not a final approach that you should be taking, but rather a step-by-step walkthrough of a basic skeleton that you can use as a starting point for your own lifecycle that would be inline with the way you are running your operations.

As mentioned previously in the paper — I am going to outline a ballpark list of artifacts that you should be producing as you’re moving a change set through the SDLC. The artifacts are important — they will ensure that you have an auditable paper trail after every delivery, which will allow you to transition into an accountable business model:

Wireframes: low-definition mockups of UI that illustrate the UX
SA / HLD: solution architecture outlined as a high-level tech-design
SRS: specification of the software requirements: functional & other
Mockups: high-definition, detailed mockups of the entire UI & UX
WBS: work breakdown structure that covers end-to-end implementation
Docker Image: all that coders do must result in a versioned image
Test Plan: step-by-step guide for how to run through all the test cases
Test Cases: set of cases with granular steps for testing every feature
Verification Protocol: who & when tested what on which environment
Marketing Brief: tell what has been done in a non-technical manner

Once you’re done with the list above (and keep in mind that this is merely a baseline rather than an exhaustive list) — there is one thing that you should always keep in mind: if you have steps in SDLC that do not product an artifact — lose those steps. Anything that does not generate a material, tangible artifact — is a distraction that consumes resources without producing anything that can be accounted for.