The Software Development Processes
In this article, I want to guide you through the entire software development process from the very beginning. For this purpose, let’s assume that we need to build a web app (mobile or any other).
The Process in General
Ok, so we know that we need an app and at least something to start with or something that can prove our business concept, or MVP – Minimum Viable Product – if we are prepared better. We don’t know if there is any need in planning and allocating resources for the far future yet. However, we do know that it has to be coded, so the process should look like the one in the picture below.
The Simplest Software Development Process
Yes, we need to find someone who can code the app for us. At the same time, we are aware of the need to understand what is it that we want; because these thoughts will have to be explained to our developer, so you’d better write them down on a piece of paper. This helps us create and keep in mind a full scope of work, come up with priorities and milestones for future work. That’s a job for an Analyst (sometimes, it is done by the Project Manager instead of the Analyst). Once that’s done, we know that the developer is not a universal mind, so there are will be some errors in his/her work (we call them bugs). This is why we need to check for those bugs systematically or periodically and make the developer fix them. This task is the responsibility of a QA (Quality Assurance) Engineer.
Organize and deploy
Later, we noticed the development performance going down, and all of these people (Developers and QA Engineers) less willing to cooperate. Therefore, we solved the issue with the help of a Project Manager, who keeps the process running, or in other words – organizes the work for us. Weeks or months have passed and the MVP is ready, so we want to have it running on a web server. This is when we need somebody who would help us with it (quite often, it’s the developer himself). In addition, we need to check everything on the production server. We understand that something will be implemented wrong anyway, so we require guarantees on the result, which is usually a period of free tech support. The work scheme appears to be the following:
Each cycle here is an activity, which requires time and efforts, and should be completed regardless of the number of people in our team: either we or dedicated professionals have to do it.
- Clarify, spec cycle – This cycle consists of defining development milestones and composing technical specifications (Carried out by the Business Analyst or Project Manager).
- Code cycle – Obviously, programming code (Carried out by Developers).
- Organize cycle – Managing work activities, like adjusting communication and controlling work progress (In most cases, carried out by the Project Manager).
- Test cycle – Fixing bugs and verifying app correspondence to specifications (Carried out by QA Engineers or Developers).
- Deploy cycle – The process of app deployment on a server (Carried out by DevOps Engineers or Developers).
- Final Test cycle – Final check of the app (Carried out by QA Engineers).
- Tech Support cycle – Carried out by the entire team in case of any malfunctions.
Development Process with Occasional Changes
Sometimes, we change our minds or have a new idea, which we want to test in our MVP. New changes in software development restart the whole process repeatedly. So, it’s better to automate what we can with minimum efforts and add some control for code quality. By improving code quality, we save the app from huge rework efforts in case of changes we need to add in the future. Here are new cycles in the process.
- Code Quality cycle – This cycle implies controlling of code quality by the Senior Developer, mostly by conducting Code Review.
- Continuous Delivery cycle – (Continuous Integration) Automation of deployment processes in software development.
Growing the App
If we are running the business properly, we want to refine the app. We need to add methodical improvements. Evolving life of the app requires continuous delivery of new features to production. First, we need to forward a development plan for a certain period to the development team (milestone or sprint) and do it for each development iteration or each feature. This means, we need to build a smooth process of requirements clarification. Sure, we don’t want to waste resources on manual deployment of the code to servers for each iteration. This is where the full-featured continuous integration system should help us out. Meanwhile, things are becoming more complicated with organization of work, so we simply rely on Agile and apply a bit of this philosophy in our management.
The app is growing and new people are welcome in the team, so we start thinking about one more metric – the speed of becoming productive for new employees. First, we start making some notable explanations inside the code, tests, deployment processes and so on – the documentation in general. Code quality and software architecture are becoming more and more crucial, so we adapt the code to new growing requirements and that’s what refactoring is for.
Growing App Scheme
- Continuous work on Requirements cycle – It means working closely with Product Owner to get the most of collaboration (Carried out by the Business Analyst).
- Agile cycle – Agile Software Development, well-known organization principles in software companies (Carried out by the Project Manager).
- Refactoring cycle – To ensure app scalability, the code should be revised and adapted to changing needs (Carried out by Developers).
- Docs cycle – The app is growing and the team is growing with it, so new people need to dive into the process ASAP. Moreover, serious changes to the code eventually drag out expertise in app architecture from team members. That means, the code (especially core) should be supported with documents and explanations (Carried out by Developers).
- Unit Tests cycle – In the real world, changing stuff leads to consequences, and in the software industry, it is mostly about broken functionality. Of course, it will be detected on the Test cycle and returned back to Code cycle, but for the purpose of preventing delays and overheads, we use Unit tests. Unit tests show malfunctions after insertion of the new code and if there is anything wrong, the developer just fixes it and doesn’t push changes further to the Test cycle (Carried out by Developers).
In this article, we briefly cover 3 main stages of software development. In a short-term period, each stage could be considered as a project type. Based on these stages, projects could be divided into 3 categories:
- MVP Projects – We don’t care about future improvements or growth. The main criteria is budget, so we sacrifice quality and flexibility. We just need to put the project on rails and test it out.
- MVP + Changes – More often, we have plans to add some changes to the initial MVP.
- Growing Projects – Here, we have a functioning app and we want to improve it periodically.
(Note: There is, actually, one more category – Large Projects. However, this is not a topic of this article.)
Each project category requires activity cycles described above. Each cycle is a process. Each individual company forms them individually, some have more process, some have less, but in general, the idea is the same.