Phase 0 - Tools Development and Evaluation
Outside the periphery of the process described below, development, enhancement, and evaluation of frameworks and toolsets for the development team should not be ignored. There are a lot of time and effort saving solutions out there that can facilitate and speed up development significantly!
Phase 1 - Initial Concept
Fundamental to any software project is the core concept to be delivered to the User. In many cases, this initial concept will be relatively short and vague, somewhat in the nature of a Mission Statement - “I want to enable a <type of User> to be able to <do something>”. One goal statement should be defined for each anticipated type of user of a product.
Phase 2 - User Stories / Wireframe Design
From the initial concept, a set of user stories are extrapolated and organized into a basic set of wireframes. These wireframes are/become the overall information flow of the finished application. The details of the user experience, such as appearance, animations, etc; are not typically put together at this point, but having the basic information flow and a good idea of the tasks a user will need to perform at each stage of the information flow allows development to begin. In addition, This set of use cases and wireframes imposes a natural boundary on the scope of the software development effort.
This style of application development is a top down approach, relying on user needs to form the scope limitations of the project, as opposed to developer limitations. If engineering considers a given feature to be unnecessarily difficult or impossible, the story is shelved for later and the user stories are redrawn to meet User needs as best as possible without the feature.
Phase 3 - User Interface Implementation
Note that at all points, the User needs are the priority. A commonly heard counter-argument to this philosophy is that a UI will often change, but the underlying business logic will always be there. Shouldn’t, then, the development focus be on developing the core of the product and then, when the core is well on its way, designing a UI to fit that core? Many organizations have developed this way for some time, with varying degrees of success. The goal of this strategy, however, is one of speed. Remember that the end user will experience nothing of your ‘core product’ that they cannot access through the UI. In developing the UI layer first, one can define the set of interfaces expected from the underlying system, even if that system does not exist. The product is then ‘code complete’ when the underlying ‘core product’ meets the expectations of the UI. In MVC terms, we develop the Views and the Controllers to determine what we expect out of the model, potentially saving unnecessary development effort in the core product due to poorly defined boundaries.
So, In coordination with the continued UI Design effort, development on the UI should now begin. For most mobile application development, the user interface comprises the majority of the development effort, and in making use of MVC / MVP patterns, the UI also comprises most of the overall application structure. At this point, UI elements should be written to pull data from interface/protocol objects that will eventually become our model. The developers working on the UI should also write mock implementations of those objects, returning static/hard coded data as appropriate to the situation. Meanwhile, the UI developer is working closely with the designer to add in the various pictures, textures, colors, and components that will comprise the finished product.
Phase 4 - Model / Complex Behaviour Development
As the definition of the interfaces/protocols defined by the UI solidify, work should begin on the Model implementation, as well as any other complex behaviour your application might require. The scope of effort put in to model development should be limited to the interfaces required by the UI, and with a well defined interface/protocol, is relatively straightforward development. Complex behaviours, of course, vary depending on the application being developed and are beyond the scope of this document.
Phase 5 - Debugging and Testing
Nominally, you’re finished! But of course programming is the process of putting bugs in, so at this point you’ll want to ensure that your application meets your own defined expectations of quality. Remember that users will forgive the occasional bug, especially if the developer is responsive to their complaints, so don’t spend too much time in this phase - just get the product to the point where it seems like something you’d want to use.
Phase 6 - Deploy, ???, Profit!
You’ve finished and your app is on the market! Congratulations are in order - you’ve sat down to do something and by golly you’ve done it - the world of Play/App store awaits!
Additional Considerations
- Keep in mind your feature backlog while developing. It’s a lot easier to code a new feature in later if you think about how you might implement it in the future - often just thinking about it briefly makes you structure your code better and more flexibly.
- Don’t get too bogged down in architecture to begin with - pick a pattern, draw out a quick class diagram on paper, and start coding. Often you’ll find a pattern that works for you as you go
- As has been said many, many times, code to an interface[protocol] - not an implementation. Even if you only ever write one implementation of an interface, code written this way is almost always flexible, easy to work with, and easy to understand. You can certainly go overboard with design, but find the balance that works for you and you can't go wrong.
