How Apps Are Made
I'm Drew and today I will introduce you to how apps are made!
Most applications go through something called the Software Development Lifecycle.
The team responsible for building the app goes through a series of phases. These phases can sometimes include a couple more than what you will read about today, but here, we are going to talk through the most common ones.
Actually sitting down to configure, code or even design the app is just one in a series of steps.
First up is Mobilisation:
This is when the team comes together, we gather the right people for this particular app:
Most importantly, we have to have a person or people that understand what the 'need' is. What problem is this app going to solve? These people are integral to the process, and they are called subject matter experts.
We need a Business Analyst or (BA) to understand what the actual problems are that this app is going to solve, and to work on behalf of the user
We need someone to do the actual development of the app, taking all that great work that the BA does, and creating the product on the back of it.
We need an architect to oversee the design and to guide the development so we are confident we are making the right decisions for the app and for the user.
We need a UI/UX specialist to ensure the app looks right, that its accessible, branding is in place, fonts, forms colours are all there and that the experience serves the user.
We need software testers. We can’t just send the app out in to the world if we have missed something, so we bring in testers do make sure there is a quality assurance process in place.
Finally, we need a project manager. We have to keep all of the people in this team working towards multiple deadlines, with many dependencies on each other, there are subject matter experts, project team members and sometimes 3rd parties that all have their own timeline and task list to work towards, the PM makes sure that we are managing that time, budget and relationships.
Once this team starts this process, they begin to understand the problem, the process, the budget, timeline, and the proposed solution (if there is one) . This is where the team is set up so they can work as a team through each of the subsequent phases.
“By failing to prepare, you are preparing to fail.”
Next is Discovery:
Often there is a period after mobilisation where the team spend some time trying to reduce project risk. This is called a Discovery period.
Through Discovery, you want to learn as much as possible about the process, the people involved, the challenges, the opportunities, and the information that make up the actual building blocks of the project - these are called 'Requirements', its literally a list of whats required to solve the problem that your app will address. In the Discovery phase you will identify the reality of the situation, where the risk is, what has been done (if it has been done correctly) and what is left to do. It’s were you
When you exit Discovery, you should have identified your risk & have the building blocks of the analysis phase.
After Discovery we move in to Analysis:
As we move from phase to phase, we want to make sure we aren't repeating any mistakes we have made previously, so we should be meeting as a team, talking openly about what went well, what went wrong and how we can do better. We called this a lessons learned session or a phase review.
During analysis, we delve deeper in to the requirements, we elicit as much information as possible from the subject matter experts We learn about what the future process will look like, we document every form, every data entry point, every field, and the automation rules that need to be built in order for us to bring It to life. We also might create mock ups, and prototypes. This gives everyone involved a visual representation of the information they have been working on. It gives an early view of the app, showing how the user will move from one screen to another and interact with it. Once the requirements are all agreed by the parties involved, analysis can be closed and we can move on.
If the Analysis Phase represents the 'What' of app building, then the 'Design' phase represents the 'How.'
Now, we are ready for Design.
In the Design phase the technical team take the requirements, the mock ups, and process documentation and they design the App on paper. Well, digital paper. They come up with a design that meets the need set out in the analysis phase. This is then agreed with all who need to agree (usually the people paying for the app). Then we close out Design, finish talking about it and we start building!
The user has got to be at the centre of every decision that is made when it comes to system Design.
Now for the Techy bit - Build.
The Build phase is where the developers take the Design and the Requirements and use them as a blueprint to actually create the app. They lean on the BA to clarify information when they need it, they seek guidance from the Architect when they need a decision made that will impact the overall application, and they are kept honest by the Project Manager who keeps track of their tasks list and budget.
So now the app is built, we want to give the decision makers early access to it so they can get their hands on it and make sure that it meets the needs of the people that are going to be using it or managing it. We call this User Acceptance Testing, and it is the first time people will be able to run through full processes, and use the app in a way that mirrors what it will be like after it’s released to the public!
“Everybody should learn to program a computer because it teaches you how to think.”
Next up is Quality Assurance - QA
(Software Testing).
After the technical team have built the app, the professional Software Testers come in, they review the documentation, create a test plan, begin creating the tests that they are going to use to ensure the app is ft for purpose, then the testers begin moving through the application, trying their best to break it! If they find a part that’s broken, they log it, these broken parts are called 'Bugs', or defects. We send them through the development cycle if they are in fact bugs, and then retest them, if they pass we move on, if not, they go back into that dev cycle until they do pass.
Any application must undergo System testing to ensure the product is fit for purpose plus a phase of User testing to validate that the product solves the original business problem.
Ready.. Set..
So we are at the business end of the project, we have an app that meets the needs of the people that paid for it, its been tested by the users, its passed Quality Assurance and is now ready to Go-live and be released to the public.
The technical team are busy preparing the environment for the release (the place where the actual system will live, the website, portal etc..), any integration is in place, data has been migrated over, licenses are assigned, support teams are in place and there might also be a PR exercise to promote the app internally and externally, all of this is coordinated so that the go-live is as smooth as possible.
Once our App is live and available to use, there is usually a period of time afterwards where the app is supported by the tech team that built it, just in case any bugs slipped through the net. These are resolved in relation to the priority level of the bug, Priority 1 (or P1) being the most critical. This period of time is called PGLS - Post Go-live Support.
That’s it, these are the main phases of the software development life cycle, I am pretty confident that most websites and applications that you will use today will have gone through this journey. There are other parallel streams that can run alongside this process, like Organisational Change, Service Design and Training but these are so huge and important I am going to save them for another video.
Maybe you are new to the Tech world, or looking to get in to it, maybe you just have an interest in how things get made, but regardless I hope that next time you load an app on your phone or user a website or service you will have a new found appreciation for the massive amount of work it takes to get that app in your hands.
Thanks for reading, and take care of yourself.
