UNO - Mobile applications for a taxi and delivery service

This is a very interesting case; it is about the comprehensive development of two mobile applications, an accounting and administrative system, and an air system for a taxi and delivery service. I will first talk about the application itself, about the development process, and at the end of the article I will describe some challenges, features, and atypical tasks in the process of clarifying requirements and designing the architecture. Of course, I am forced to omit many extremely interesting points due to the NDA. This project is extremely non-template; such a project cannot be made either according to a ready-made guide or according to a standard textbook like "Wiegers, Beatty. Software Requirements". No, this cooperation had a lot of features worthy of one of our most complex case projects. But as always, we expected these difficulties and were ready both for complex strategic decisions and for operational and tactical improvisations.

Since we specialize in developing systems for automating customer service, the development of administrative software and a mobile application for a taxi and delivery service in a single application immediately seemed to us an interesting project and, of course, a challenge, especially given the intense competition and apparent oversaturation of this market with technical solutions against the backdrop of the pandemic and the massive growth in demand for delivery in early 2021. For many years we communicated, in particular, with clients who planned to order the development of an online taxi service; we even had experience developing simple standard solutions from this area, but nothing extraordinary. And in mid-2021, a group of investors approached us with an atypical and complex project specifically in the taxi field. At that time, together with the described experience in the subject area, we already had experience with large (non-taxi) projects involving mapping services and GPS navigation, call centers, payment system implementation, and also experience working with real-time data and complex sets of data schemas. Based on this, we understood that we fully realized how to organize a team for the project, design it, architect the system, and program it.

The client came to us with existing drafts of the technical specification. Our business analyst audited the existing technical document, after which a number of improvements were proposed that changed the structure and content of the document.

The first important feature of this project turned out to be that the state of the design mockups was out of sync with the current state of the technical specification. Therefore, it was important to conduct a full comparison of the technical specification and the design to identify inconsistencies; there were many of them at the start, so we immediately involved a designer.

Our designer drew new mockups and made changes to existing ones. The mockups were additionally elaborated according to interface usage scenarios. We found new ways to reduce unnecessary interfaces or add new ones if it was truly necessary and impossible to reuse existing ones. Thus, we developed certain polymorphic patterns of visual display individually for this project, for this subject area.

From a management point of view, this involved forming text tasks for the designer, calls with him, testing the drawn mockups, and making corrections:

1. Thus, a document was compiled with 38 edits

2. And a task was written for the design of the second application, which included about 40 unique pages!

The design of the second application turned out to be more complicated, because the designer did not know the details and had to draw prototypes, which were then converted into finished mockups.

All the design was done in Figma - the most modern application for web design.

Initially, from the previous development team, we received a diagram that showed the logic of transitions between pages. It was useful for an initial understanding of the project. But later it was not used, because it was not correct and required reworking.

Below you can see the number of documents already created by our team at the requirements analysis and design stage.

During design, the architect documented the main technical decisions using a standard documentation approach. Entity-relationship diagrams using four main points - points of view:

1. Logic. Description of the main scenarios and interface changes when connected with the objects of the subject area of passenger and light cargo delivery.
2. Physics. Some key features of the project were documented from the point of view of required memory volumes, deployment features, scaling features, requirements for the speed of delivering new versions, and so on.
3. Statics. Description of the relationship diagram and types of states. Description of the subject area model in the form of interdependent classes in a timeless slice, description of possible states and data format and the list of possible actions with sets. Creation of the database and data models.
4. Dynamics. This is a description of the algorithm of the main processes and events that arise over time and their direct connection with the subject area model. Imagine a city with many roads, addresses, cars, and motor vehicles. People at a specific address need transport for trips and delivery. And all this happens in real time and is connected with a mass of subtleties in communication, especially when a live operator is not used. All these entities are instances of static models that have their own life cycle. Description of behavior and changes of objects over time, description of the algorithm sequence, calling dynamic methods of the subject area model - that is what was described in this point.

The team thought through the data schema based on the technical specification in Workbench. Its approximate size can be understood from the picture below. But it would have expanded further due to technical tables.

We separately worked through the diagram of the most important business processes (customer registration, contractor registration, order placement, order fulfillment on the customer side and on the contractor side). Because questions of implementation always arise when considering the algorithm in detail.

To assess the size of the project and the completeness of the requirements, its Technical Specification was more than 150 pages (77 pages, pure text without pictures!)