Development Model
QLINC has developed and adhered to a replicable software development model. This development model has led to a successful record of delivering user-friendly applications within budget and within time constraints. This model is composed of three components: iteration approach, third-party tools, and eating dog food.
Iteration Approach
The traditional software development model dictates that a significant amount of time is spent gathering user requirements before any development is started. This method is sometimes referred to as the waterfall approach. The requirement gathering phase culminates in the creation of a lengthy document that is signed by the developer and the client. The developer then disappears for a time while the application is built. Upon completion, the developer returns to proudly show off the finished product and is offended when the client says "this isn't what we wanted."
QLINC utilizes the iteration approach. After a short period of user discussions, we like to quickly mockup a pilot solution. After each subsequent meeting with the client additional changes are made until the product gets closer and closer to the finished application. At times we will make changes during a client meeting. The client is intimately involved in the decision process and has experienced several iterations of the application. This method eliminates the surprises as the application nears completion.
Third-party Tools
At QLINC we do not want to reinvent the wheel at the client’s expense. We therefore avoid custom code wherever possible. We rely on third-party software tools to speed application development. Additionally, third-party tools tend to have their own documentation and support and therefore the client is left with a finished product that is typically easier to support and maintain.
Eating Dog Food
Software developers have a saying that a user interface is not complete until the developer has eaten his or her own dog food. By this we mean you have to use the system that you have developed for someone else. Sometimes this means actually sitting down with the user and keying in their data. Only then can you appreciate how the system will be accepted.