Software Engineering for Humans #4
It’s all been leading up to this moment, dear reader, the culmination of everything I’ve explained so far has arrived.
How do we, as a company, apply these Software Engineering processes?
The previous articles addressed software engineering processes on a very high level. Today we’ll take a deep dive into a step by step guide, to managing your software team.
The information you are about to see today has been essential for R&D for years and years, so buckle up and enjoy the ride.
Before we start the software engineering process, we need to know what to performed on.
We first need to perform project discovery and scope definition activities.
1- Business Analysis
After the product has been conceptualized, it will go through a few stages before it enters the good ol’ Software Process to develop, and this is the first one.
The definition of business analysis is that it’s a disciplined approach for introducing and managing change to organizations. Basically, what a business analyst does is figure out the weak business areas to be able to improve upon them and increase the efficiency of the business process. They work closely with the product owner as to prevent them from making “bad business decisions”.
Business analysis has to occur at the start of every project because issues have to be identified and solutions have to be found for them before any serious steps in the project are taken.
2- Requirements Analysis
After you struggle through the previous stage, there comes a time where you actually start thinking about your product. Requirements analysis is where you define the expectations of the users for the application that is to be built. It’s when you analyze, document, validate and manage software or system requirements. Software Requirements analysis helps to keep the requirements in line with the need of the business. A good project requirements analysis process will render a software application that caters to the objectives of the business set forth.
Your developers start working on their tasks based on the established priority
Our Software Engineering Process
As we’ve previously discussed, the software goes through a lot of stages during its creation and there are many types of models Software Developers can choose from to develop their Software in an orderly and efficient manner.
Here in Tech Hive, we use the Agile Model (shocking).
Today, we’re gonna walk through the stages a product goes through in its very early days.
After the product goes through business analysis and requirements analysis, it is now ready to enter the real world.
So, you looked at this photo and must have wondered, “Nice colours, but what the hell am I looking at?”.
This is our project management portal.
If you look to the left in the screenshot above, you’ll see a list of statuses, what does each one mean?
Picture this: your client could enter your company’s portal and report a task they’d like to be done; or the product owner could have talked to the client and entered a new task for your team; or your business analyst could have done a competitor’s analysis and found a nice feature that you could steal for your own product, so they add it to the pipeline; or your very talented developer thought, “Hey! We could optimize this feature.” and they would report that to the team; or it even could be your Quality Control reporting that a task needs to be done for your Software to be running smoothly.
After any of these events occur, the product owner lists all these reports according to priority and adds any helpful resources to achieve them in the best way possible.
Following that, your quality control engineer starts working on a test cases document in which they tinker ways to test the new reported/desired feature. The document must be highly detailed and structured. Inside the document there should be a bunch of scenarios with expected results, so that whoever is working on that feature knows what they are working towards achieving, also this way, your client would know what they are expecting out of you.
Once your test documents are finished, pat yourself on the back because the task is now groomed.
At the start of every sprint (See: Agile methodology), the product owner fills the sprint backlog with groomed tasks and sets everyone’s expectations to, “Ayo, this task is included within this sprint and all this groomed stuff should be done.”
After estimating the sprint and at the start of it, each developer takes a task and set its status to In Progress and start working on their tasks based on the established priorities.
In each project, there’s someone called the “Scrum master” (Again, see: Agile methodology), think of them as the team captain. They make sure that everyone is doing their work accordingly and nobody is waiting for somebody to finish a particular task to start theirs, because that would be a waste of time. If there are tasks in progress, there’s a scrum master.
After a developer finishes a task, they set its status as completed which hands it to the QC to test it out. If the feature passes all its test cases, its status is set to accepted, if not, well… to rejected it goes, or blocked if they’re hindered in some way (Let’s say, someone’s working on a feature, and they are awaiting feedback from the client or somebody from the team or even a third party. Well, now they are blocked from completing the task ‘til that’s solved) If that occurs, the developer who worked on that feature is notified and its status is reverted to In Progress.
Once the task is accepted at last, it goes to be reviewed by the client. If the client gives their thumbs up, it’s Client Verified, and the task is done. If not, the cycle starts all over again.
At the end of the sprint, all the client verified tasks are taken and deployed to the live environment to the users.
Et Voila! This is what all our projects go through to ensure the highest quality possible for the end-users.
And with that, I must bid you farewell, dear reader because we have reached the end of this series. It’s been an honor.
See you again in a few weeks though!