Requirement gathering

This stage is about defining what the application needs to do. This will be based on my own thoughts, existing solutions and user input. User input is crucial to the success of any project, as if you don’t create something which is needed by real users, it’s worthless, no matter how well it’s implemented. Despite this, it’s very important to avoid design by committee, which is where you add everything anyone wants, which results in a large, bloated product that is of use to no one.

I will then build up a basic feature list, divided by section. This will be a very high level overview, and will be expanded on as I begin each section. I just need to know enough at this point to figure out how everything will fit together when making the system architecture.

UI Design

This part will involve coming up with a design for all the common UI elements, such as header, navigation and footer. The exact design for the main content will vary with each section/page, and to a lesser extent, so will any secondary content, such as a sidebar, although they will be influenced by the overall style. This part could be done at any time, although it’s good to have it fairly early on, as it will be influence the design of each page.

This process will start with some hand drawn wireframes/computer generated wireframes, which will then lead to a more polished set of design elements. User feedback

Architecture overview

This stage involves coming up with a very high level overview of the implementation. It needs to think about how the data will be stored in the database, how these tables link together. What models, views and controllers I will need as well as additional libraries and helpers. At this stage, it will focus more on what the various classes need to do, instead of how they do it, which will happen in the next stage.

I will also plan some of the key use cases at this stage, which will be a starting point for the implementation.

Implementation

This is where the actual coding takes place. For each area of functionality, I will take the relevant use cases defined earlier and expand on them. I will then create the relevant database schema to accommodate this functionality

So by this point, I have an idea of the functionality required for the given section, and some of the key use cases. For each use case, I need to simultaneously tweak the use case and the UI, as they are both dependant on one another. The use case will specify what should happen, and the UI will be what dictates how it actually happens. Once this has been decided I can move onto the database schema. I already have a basic idea of how all the core object will interact with each other, but need to start thinking about all the attributes. I can then implement the required methods in the controllers, libraries, models etc and make the corresponding views.

Testing

This will cover both functional testing and user testing. User testing is the key point I want to focus on at this stage. This will involve getting real users to use the system, provide feedback on how to improve it, report any bugs etc. Although I will need to be confident most of the bugs have been resolved before launching the user testing, it is much more efficient to allow a large set of users to identify bugs in the system from real word usage then for me to find bugs in my own code. The user feedback process will involve some structured questions but will mostly be free form, so the users can use it as they want, and give back any information they want. All user feedback will then feed into the next development cycle.

Users

Users obviously need some way to access the system to view their projects and accompanying information. There are a number of ways this could be handled, and will be discussed in a future post.

Accounts

An account is a way of grouping users together. An account can be for a company, a group of users, a charity or any collection of users with a common interest. Then there are 2 types of accounts, company and client accounts, but they’re interchangeable, based on the current context within the application (you can even be both at the same time)

Projects

This is the whole purpose of a project management system, to manage projects. Each project has a company and a client, the company is the account doing the project, and the client is the account the project is being done for. These can both be the same account if it’s an internal project. A project is simple a collection of related items, including the ones outlined below. You can specify who has access to which projects instead of everyone in that project having access to every project (default).

Communication

Communication is the key to the success of any project. In most cases, this will take place via email, which means that not everyone is on the same page in terms of what’s going on. It also means there are numerous simultaneous ‘threads’ of communication, which are not easily searchable as they’re distributed. By using the PMS for all communication related to the project, it’s in a single location, making it easily searchable, and everyone knows what’s going on. For the times you need to communicate internally, you can send internal messages which the client won’t see.

Task management

It is important to know what needs to be done and by whom. Tasks and milestones help you to achieve this. Tasks tell you what needs to be done, and can optionally be assigned to a single user or group of users and milestones are dates by which point a set action needs to be done or something needs to be achieved by. It would also be possible to set internal milestones, which only the company sees. This is useful if the client only sets a final deadline, but you want to have internal deadlines to ensure the project executes on time.

File management

Most projects involve some sort of (electronic) documents. These can be office documents, images, archives or any other type (apart from executables or scripts). This will act as a central repository for all the documents. As well as just storing all the documents, it will also version them, meaning when you upload the same document again with some changes, instead of overwriting the file, it will keep both, but the new upload becomes the master copy, with the old being kept in case you need to revert back/see changes.

Time tracking

This is useful in projects which are billed hourly and fixed price projects. With billed hourly projects, you need an accurate breakdown of how much time was spent where, and with fixed price projects, you want to keep the total amount of hours down as much as possible, so with this you can see where you can improve efficiency. How this will be implemented is yet undecided, but it needs to be as streamlined as possible to encourage use.

Dashboard

This is the landing page in the application and it shows a summary of everything that is going on. It will be different for each user, based on the projects they’re part of. It will also be possible to focus the dashboard on a single project as well as all the users projects.