If there’s one career description I notice more frequently nowadays, it’s probably ‘engineer’. Why? What makes an engineer? More specifically, what makes a Software Engineer? Why would one person be a programmer and the next one be a Software Engineer? Is there a difference or is the debate totally open to interpretation?

If we were inclined to embark on even the slightest fraction of research (which we are), Wikipedia will tell us that one instance of an engineer is someone who “develops solutions for technical problems” and can do so “while considering the limitations” of cost (among other things). Likewise, they say that a programmer can be defined as someone who writes code and also that there are other “software engineering skills, beyond programming.”

Having been a Software Engineer for upwards of 12 years, I propose that the Software Development Life Cycle (SDLC) sheds an expansive amount of light on this topic. I firmly believe that by following the SDLC’s structure we can turn any task into an engineered or thoughtfully developed task. It is also logical to say that the SDLC can be seen as an instrumental component of not just engineering or Software Engineering, but of general activities of everyday life!

Luckily for us, the steps of the Software Development Life Cycle are as equally clear as they are structurally sound. Fundamentally, the SDLC is the suggested process for developing software or even making changes to software, but, in my opinion, this cycle of checkpoints can be applied to virtually any activity, whether it is professional or personal. I think of it as the suggested process for development, period. It’s not unreasonable to compare building a website to building a tree house for your kids or even something as common as making dinner, for instance. And all we have to do is follow 5 easy steps to see why.

Step 1: The Requirements and Analysis Stage

This stage is meant to “determine the needs or conditions…for a new product” and is “critical to the success of a project.” It is the stage for gathering information. This step puts the client or person requesting the change on stage, so to speak. They should feel encouraged to be as expressive as possible. After all, the more information that can be gathered, the better the final result will be, regardless of the project. 

Naturally, curiosity is a fun part of this stage. If you are making dinner, you might ask yourself who will be attending or whether they need a particular cuisine. If you are building a tree house, some things to find out might be where it should be placed and what colors your kids want it painted. Similarly, if you are making software changes, see if the user has a particular way they want it to look as well as how they’d like the fields to behave. Don’t be afraid to complete this stage exhaustively. No detail should be left out since anything unattended will probably be noticed at some point during the later stages and can potentially cause increasing disruption the longer it is forgotten. It would be helpful and fun to set a goal for yourself until you get familiar with this stage. For instance, try to ask three (or even five!) questions about each piece of the request, no matter what. It might be easier than you think since those questions will most likely lead to others.

Additionally, it is recommended that the client thoroughly visualize what they are requesting. If they are part of a group of people making a request, it is beneficial that they brainstorm with their team and come to an agreement on all of the possibilities. At a minimum, they should be able to verbalize some of the general areas below:

• The business function it will provide. Or simply, “what it will do?”
• What it needs in order to operate. Does it rely on other pieces?
• How it will look (Tip: Be specific)
• The details of each piece (Tip: Keep these organized)
• When it will be used. Is it automatic? Should it be retroactive?
• Where it should be placed. How does it fit into the rest of the environment?

Step 2: The Design Stage

This stage can be summarized simply by saying that it is the planning stage. Based on the requirements, how will we reach the solution? This stage would be the blueprints, the recipe, or the map. It is the layout of the process. To be successful in this stage, your plan should:

• Consider alternatives
• Use resources that already exist (when possible)
• Be concise
• Be flexible to change
• Handle adverse conditions
• Focus largely on the task at a conceptual level before getting bogged down into specifics.

In other words, it should strive to consider whole scale omissions, ambiguity, and inconsistencies. Just as blueprints can’t be designed without knowing the dimensions of the house, this stage should begin only after the Requirement stage is sound.

Step 3: The Implementation Stage

After we’ve analyzed the request and designed a solution, we can implement our plan. The Implementation phase is the programming piece of the process. This is when Software Engineers actually program the code for the project. It is the easiest stage to describe and, depending on the previous two steps, its actualization can also be greatly minimized.

Step 4: The Testing Stage

This is “an integral and important phase of the software development process.” This component is meant to ensure that defects (from any previous stage) are recognized as soon as possible. Different types of testing can ensure that nothing has been overlooked. As expected, System testing should be done to ensure that the product follows the requirements. Acceptance testing is also very important and should be done to verify that the solution works for the user.

Step 5: The Evolution Stage

Our final step should include measures such as training, measuring the effectiveness of the application, evaluating potential enhancements, deployment, and maintenance. Once a system has been stabilized through adequate testing, the SDLC ensures that proper training on the system is performed or documented before transitioning the system to its support staff and end users. (You would never send your kids into the tree house without doing some sort of ‘weight test’ first and we all know that any good cook will taste their creation before serving.) Following deployment, it is possible that maintenance is necessary as companies shift personnel or establish new procedures. The SDLC would begin anew.

As we have seen, programming was ultimately only one small part of the typical Software Development Life Cycle that a Software Engineer would use for a given project. Anyone can follow this group of methods to plan, develop, and complete projects whether they are in the realm of software or simply doing some day-to-day activity. Therefore, I encourage you to embrace this methodology until you are following it in your sleep. Sweet structured dreams!

For a blog post on a similar topic, check out:
Why Business Process Improvement is Still Important

This blog post was authored by Kira Porter:

Kira Porter is a consultant with Meaden and Moore’s Business Solutions Group. She primarily works with clients in the manufacturing industry, assisting them with business process evaluation, and providing application training and implementation services of Enterprise Resource Planning Software Systems.