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 I hope you will have a software development cycle that gives great results.
In this post I will be covering changes within the app’s specifications and how to deal with them. If you have not yet read the previous chapters I advice to read them first:
Part 1 – Concept
Part 2 – Planning
Part 3 – Design
Part 4 – Development
I Hope you will enjoy reading the series as much as I have writing it.
Everybody that has worked on a IT project can surly tell you that there comes a time you will be dealing with changes to your project. This usually happens long after the functional design or design documents are finalized and the project is far into it’s development stage. It’s best to be prepared to deal with this situation and know how to correctly handle changes.
The method described in this chapter may seem a bit overkill, especially for small teams or single (freelance) developers this may be very different compared to the way they are used to handle changes within their projects, but you will find that both you and your clients will benefit from this method. If you are a single developer working on your own apps you might want to reconsider applying the techniques from this chapter, since it does give some extra overhead and mostly is based on avoiding communication errors and keeping the project within budget. I Do recommend every developer to read this chapter because you never know when you will be put into a situation where you are managing a project for a client.
As I mentioned before this method is created to avoid communication errors and keeping a project within budget. This means by using the techniques from this chapter you will less likely to exceed a deadline or forced to deal with an unhappy client when deploying the software. But most clients will not be used to work this strictly when dealing with changes. Therefor you should always communicate exactly how you are dealing with changes to the client before the first invoice is send. This gives you the opportunity to refer to your work method when a client does takes the incorrect way’s to request a change to the project. If you have not clearly communicated this from the start of the project a client might get frustrated by the fact that it takes more effort to get his changes made to the project. But in the end even the client will benefit by getting his project completed in time and within budget. So it’s a win win situation.
A Common mistake
A Common way in most projects a change would be requested by a client sending an email to the project manager. He in it’s turn talks to a developer and asks if the change can be done in without much effort and the developers needs to answer on the spot. He in his turn will tell the project manager if it’s a small change and if so the manager will try to keep the client happy and comply. In some cases the manager will send an invoice for the change but usually this is where the road ends.
The manager thinks he has done a good job, the client is happy and the company may even get some extra money for applying the change. But now the client has learned an important lesson; he can make any request and there are no consequences to his actions apart from an occasional bill in the mail. So next week he thinks of an other change and the process repeats itself. In the end the project might exceed it’s deadline and nobody knows what went wrong. The ending product differs a lot from the official functional design document and the product is hard to test because of this. This leads to an unhappy client and maybe even a project that go’s over budget and ends up to cost the developers money instead of making them money. So what how can we overcome this problem?
First off every change should be documented, and every change will have it’s reflect to the development cycle. This means that with every change request the design documents need to be adjusted and the deadline and budget for the project need to be recalculated. This is an essential part of dealing with changes in a correct way and will might change the way you think about changes to a project in the future.
It all starts with the change request document. In this document the party requesting the change will write down exactly what changes are to be made and why. The change request document need to include the following information:
- Name of the person requesting a change.
- Chapter(s) and document(s) that are affected by the change.
- The actual change.
- A Motivation on why the change needs to be made.
- Signed and approved by the person in charge within the requesting party.
After this document is received the project manager will create an invoice and recalculated the deadline for the project. It’s important that the client making the request knows that by filling in a request for a change it may lead to an invoice and recalculation of the deadline, therefor I recommend to add this information to the change request form. I Would even suggest to make the text bold so it will not be overlooked.
Once the change request is approved the change can be applied to the appropriate documents. These usually are the functional/technical and user interface design documents. In the change document the developing party will write down all changes to be made to these documents. The change document will have the following information:
- Id of the change request document.
- Chapter(s) and document(s) that are affected by the change.
- The actual change. (Note that this is may not be the same as in the change request form. This is because this document is written by a technical expert and may have it’s own interpretation on how to implement the wishes of the client)
- Signed and approved by the developing party.
- Signed and approved by the requesting party.
As you can see this document needs to be signed off by both parties before going moving to the next step.
After the change document is approved, the developing party can now adjust the appropriate documents like the functional design or technical design document. This will lead into a new version of these documents and therefor all of these documents should contain a log of the changes made to these documents. It should be enough to just attach the change document to these documents to create a change log.
After the new version of these documents are made they should also be approved by both parties before they can be used in future development stages. This is no different than the fact that the first versions also need approving before continuing the development stages.
As you can see changes need to be a part of your development process. By doing so you will improve your communication and cut back risks. Although it might be an overkill for single developers that only work on their own apps, it will make working with clients easier and in the end both parties will benefit.
Till next time
That’s it for this post. In the next chapter I will cover how to deploy your app to the public. You can subscribe to my blog with the RSS icon on the top of this page.
Till next time, happy coding!