A high quality software development life cycle explained easy
A guide for everybody to understand it
To avoid some misunderstandings and prevent disappointment, let’s first start with some definitions. A life cycle is a set of steps that an idea faces in order to evolve and become a real Software solution (an app, a website, or even just an algorithm).
A life cycle is not a methodology, it is a process, which means that this post is not about agile, but about a more abstract concept instead. The process defines what to do, meanwhile the methodology defines how it is done.
Unfortunately, this difference is not taken in count and surprisingly, there are a lot of companies around the world implementing poor software development practices because of their own lack of knowledge or understanding of the whole. These companies usually face delays, offer bad customer experiences, their development teams are discouraged and frustrated, and eventually they become a time bomb, where every change can be enough to knock the company product down. The following image represents perfectly what I want to say.
The “major leagues of software development” have their own secret recipe and it is not publicly shared. I personally, don’t know what are the processes that Facebook, Apple or Google implement, but I asure you something: they do implement high quality processes and practices to guarantee a successful product, a productive team and a perfect timing organization.
Theory proposes spiral and waterfall like life cycles. That’s books stuff that it is good to know, but let’s go to the real thing now. This is the recipe of success that I have experienced working with great success and that you can implement in your company or project too. Spoiler alert: you will hardly find this process somewhere else so, fasten your zip belt!
- After sharing the idea and the requirements, it is needed to have a process of product thinking, where for at least 1 week, the stakeholders and technical engineers with client empathy skills will re-think the idea, gather requirements and define if the project will be an app, a website, a process, a digital transformation or something else that is not software at all. Believe it or not, there is a lot of people that only want an app because the competitor has one, or because they believe they can solve a certain problem that can be solved by hiring the right person, or by a change in the internal process of the client’s company. I will write a complete post about this topic later.
- With the product thinking’s output, the User Experience (UX) design team team is ready to have interviews with the client to define the UX. The UX is the most important part of all the process, a bad user experience, a disorganized app or the lack of intuitive interaction marks the failure of the project. No matter how great your idea, the code or the UI is, if the user does not understand how to use an app, it is its end. The output of the UX is a sketch, most of the times made in paper, of how the user will navigate from a screen to the other. This “map of interaction” is called Wireframe and it looks like this image bellow.
The wireframe is built together with the client, in different meetings where the engineers and designers gather requirements from the stakeholders through games and interactive activities to understand what’s in their minds.
3. Before theUX team finishes its work, the UI designers can start designing the first app screens. They will define colors compatible with the client’s branding, buttons, icons, fonts and basically, the style of every single screen element that you see in an app. The designers create the style files in their computer, but then it is uploaded to a tool like inVision, which is a repository of screens that developers use to follow the designed screens as a guideline to create software UI.
4. Before the designers finish their work, the backend development team can start implementing the app first endpoints, data base models and tests. To avoid delays, backend developers always work at least 1 week ahead frontend/mobile. This way, when frontend/mobile start working, all the data to perform the server requests is already defined, created and ready to use. It is important to have a proper documentation of the backend endpoints, attributes for the requests and response. This means that at least, the backend guys need to create a google drive doc or a website with this basic information. A powerful tool to use is Dictum, only available for Ruby in Rails. You can find it in this link.
5. Now it’s time for frontend/mobile to start working. Meanwhile backend continues and the UI designers are still on the project only to attend questions or suggestions from the developers. It is important for you to understand that most of the times, developers have the final word in how a screen should look like, because designers are used to create amazing layouts, but some of them cannot be represented in a screen because of technology limitations. It is very important that developers and designers have a good team work spirit, as they need to interact a lot and share some time together working in the same projects.
6. Once every new feature has been finished, developers must assign it to the testing team. Testing is underestimated many times and this is a critical important area that should never be absent in any company. Backend and frontend/mobile are tested exhaustively, even when both sides have unit testing practices. The tester has the final word to decide if he approves or not a feature. If he or she finds any bugs or has ay specific suggestions related to the UX, UI or app behavior, the developer should fix those issues or a least discuss with the tester to reach an agreement.
7. After testing comes continues integration, the project grows every time a bit more and there is a new MVP after some weeks of work. An MVP is a estable version of the software which is a working product, although that it is limited in its functionality because there is still work in progress. MVP stands for Minimum viable product. At this point, the client receives a robust functional version of the app. Development teams continue working until the project ends. From now on, the loop is: development, testing, MVP revisions and back to development again. Once in a while, it is a good practice and a good advice to have a full review. A full review is an exhaustive testing process that evaluates all the functionality of the app, to ensure that the new features didn’t affect the correct behavior of the previous ones.
8. Once all the features has been implemented, the last MVP is the product’s final version that can be delivered to the client. In this final step, the client must receive the code, any documentation related to the software like the backend list of endpoints and attributed for the requests and responses, testing documentation, decision making docs or any other relevant information that has been written for his project. Sometimes, clients ask for the code in their own github repo, meanwhile the access to the server should have been provided by himself at the beginning of the project. There’s usually a final meeting with the sales representatives, team manager and client stakeholders to receive feedback and start a possible collaboration in the future.
After this step, companies usually offer maintenance and support, which can be up to 20 hours per month, depending on the company standards.
Additionally, nowadays there are companies that are driving their digital transformation and they want to continue developing the project. It is a good practice (for business and customer experience) to offer recruitment, training and assistance to the client. This would be the step number 9 in the list.
I hope this complete overview give you new tools and help you to define the life cycle framework for your company. If you have questions or doubts, contact me and I’ll be happy to assist you.
