Our process

for a mobile application (from a 30,000 feet view)

steps

Software requirements

First we try to understand what are the underlying problems, the expectations for the final product and the performance metrics needed. There are a few levels of stake holders supporting and championing the product in any organization. Each one has its own expectations and aligning them with the constraints (resources/time/risk) is one of the main goals at this stage.

Crafting the user-case scenarios

Usually, there is a protocol for moving from one phase of the project to another and the user-case scenarios or the testsĀ  designed at this stage are essential on establishing the release milestones for the project.

Software design

It is considered an internal process for us but with clear “sprints”, results and outcomes for the client. It is possible to have significant changes in the development stage but for the client the final result should be transparent to the implementation.

Getting the team

From the design phase it is becoming clear the development team structure and involvement during the project. The product manager, theĀ  project manager coordinating with the software manager will decide the time and effort for the software engineers.

Software implementation & Testing

We are adopters of agile methodology because is aligned with short time deliverables and keeps a close score of the risks involved with the project. We are using continue integration systems and developers are creating tests based in the criteria decided as acceptance conditions in the beginning of the project.

Releasing and setting the support framework

The software products have a second phase of “exploitation”, after deployment. At this stage, the bugs can still be found and fixed but mostly is about improvements, integration or adding features.

Comments

We consider the permanent dialog with the stake holders as an essential component for each successful project. Any "surprises" or course changes have to be agreed by both parties.

Another point of agreement is how the intermediate product is released, tested and bench-marked before moved to the next milestone release.

In some cases the user-case scenarios are altered due to alignment between expectations and constraints and better understanding of what is feasible with given resources.

We sometimes show a prototype of the product using wire-frames, stub interfaces and simulated functionality. This is the last stage where changes should be allowed.

examPles of Skills

Android 89%
NodeJS 61%
Photoshop 43%
InDesign 40%
Html & CSS 85%