Creating your own Android app: Part 2 – Planning

Introduction

The Android platform has millions of users and is growing each day. With this growth so do the number of people that want to explore the platform by creating their own Android app. While a lot of those people are professional software developers, there are many that have little to no experience in developing and publishing software. This led me to write this series on creating your own Android app: “Creating your own Android app, from vision to reality”

In this series I will be covering the development cycle from concept to deployment. I Will give my recommendations on what steps you should undertake to get your app to the public.

Keep in mind this series is meant to be a helpful guide and not a set of instructions that should be followed exactly step by step. Try out what steps work best for you and in the I hope you will have a software development cycle that gives great results.

In this post I will be covering the planning stage. If you have not yet read the previous chapter “Concept” I advice to read that post first:
Creating your own Android app: Part 1 – Concept

I Hope you will enjoy reading the series as much as I have writing it.

– Martin

Planning

All of your ideas are written down and now you want to start creating the app. Planning is one of those steps most small teams or individual developers skip. And that’s a shame because planning will help you to actually release your app and get updates done on time. With good planning your project will more likely see an actual release and help you save time. So spend some time and keep your project within budget.

If you are working in a team, I can recommend the following books on this subject.

Roadmap

The first thing I like to do when I start a new project is to create a road map. This will guide me trough the process of maintaining the app and knowing when certain features will be released. I Like to view the road map more as a guideline than a carefully planned schedule. Now I must address that the flexibility to deviate from the road map depends on the flexibility of your company or team, if you are a single developer than you have much more flexibility than working in a large company.

To start writing your road map just take your feature list and divide your features into groups. For example you can have a group with social network features, or features like sorting, backup and restore, etc. Try find relations between the features, for example you cannot sort a list of items if there is no way to add items to a list. These relations will help you determine the order of development of the features.

Now take all of these features and groups and mark them by importance. The importance of a feature can be determine by the following questions “Will the app be usable without this feature” (must have) or “Does this feature bring something unique to my app” (great for marketing). You can now divide the features into versions of your app. The first version of your app should only contain must have features. (you don’t have to actually release this version to the public) Try to include a whole feature group in one release, while also try not to put too many features into each version. It’s better to have ten versions with only a few features than to have two that will take forever to develop.

The key to this process is to get your app to grow into that ultimate app you visualized before. Many but small releases will also re-leave you or your team from stress. Large releases with many features are much harder to plan correctly and need much more testing. By developing many small incremental releases you will find that you will be more in control over the whole process and less likely to run out of time before a deadline.

Adding deadlines to your road map can help specify when a certain feature must be completed. For example if you have an app that catalogs all kind of candy you might want to have a version that contains a feature to buy candy online out before Halloween. But if you do not have much experience in developing apps setting deadlines might be a hard task, so I would advice new developers to only set a deadline on your first version if they are forced by budgets.

A Good road map will guide you in your development process and helps getting your app released to the public.

Functional design

A Functional design is a document in which you write out all features of one release. For professional software developers a functional design is usually used to communicate to a client what the software product will actually do. Although some people will add user interface designs to the document, I would not recommend it. Functional design and user interface designs should be two different stages in your development process.

The functional design should be written to be understand by non technical readers. For example you could write a section covering adding and editing contacts. If you do so you would not specify what buttons there are in the application nor would you write how the data is stored. You should however specify what kind of fields there are and what kind of input they will be receiving. For example you could specify a contact like this:

Contacts

The application has an option to insert, edit and delete contacts. These contacts will be available to the user in a list and details can be viewed.

Name Input type Required Check
First name Text Yes First letter must be a capital.
Surname Text Yes First letter must be a capital.
Phone number Phone number (Numeric) No Valid international phone number
Email address Email (text) No Valid email address
Birth date Date No

The functional design will be used to write the technical design. (covered in the chapter development) It can also be used to test if the final product contains all the features that are specified. It should be clear enough to know what features are to be made, but leave room for technical interpretations and designing of the user interface.

A Functional design can be used as a communication tool between a development team and a client to specify the final product.

Till next time

That’s it for this post. In the next chapter I will cover the Design stage, make sure not to miss it by subscribing to my blog with the RSS icon on the top of this page.

Till next time, happy coding!

Leave a Reply

Your email address will not be published. Required fields are marked *