Methodology (aka How We Design Software)

We offer custom software development services - but what does that really mean?

In a nutshell: You tell us what sort of business process you want to automate, or what sort of data or metrics you need to store and use, and we'll build you a program that will do those things for you.

There's a lot more to it than that, of course:

Requirements

First we'll work with you to define your "requirements", which is a fancy way of saying that we'll figure out what you really need. This will include a lot of discussions with the key players, a review of your current processes, and many other processes. We will also discuss responsibilities and the chain of command - for example, who is allowed to authorize changes to the project, who is the point of contact for IT environment decisions, etc.

Environment

Next, we'll define your "environment" - what sort of database you'll use, what sort of operating system will the program support, what sort of client devices will you be using, how do your users need to access the utility (web, mobile, desktop, etc).

During this phase we'll also review your current environment to see if we can leverage any existing software or hardware you already have in place. For example, if you're looking for a customized CRM system and are already using SAP, we may be able to just add functionality to your SAP system instead of re-inventing the wheel.

Proposal

Next, we'll write up a proposal that will define all of these things, will spell out responsibilities of each party, and expectations of the overall project. Once that proposal is accepted, we'll price the project.

Design

This is where some clients get confused. "Design" is different from "develop". During the Design phase, we'll begin the process of actually designing the components of your program. This would include the user interface screens, menuing/navigation system, security methods, outputs (reports, text files, data exports, XML, etc), and the help system, to name a few. Some of these may have been specified earlier, but this phase is when they actually begin to take form.

This is also the phase where we often must deal with the "it looks like a program, so why can't I use it" syndrome. During the Design phase, many of the items you'll review will be mockups, or will be nonfunctional to a great degree. Our intent during this phase is to give you a sense of how your program will look and feel, not to give you a fully functioning program.

Development

This is where the actual coding takes place, and it's one of the last steps. During this phase we'll "wire up" those interfaces, reports and other processes we defined above. This is where the program begins to actually function, and where you and your team really come into play (see the Test and Tune phase below).

This step can be somewhat frustrating to clients. They see a program that is starting to take shape, and they see that they can now do the things they're paying for, like storing customers, or printing reports, or sending out email invoices to customers. There is often a very great desire on the part of the client to rush this process, to get it done under deadline.

And we'd like nothing better but we also must take time to insure that the code is solid, reliable, stable, extensible, scalable, reusable - in short, that you get what you're paying for.

 Chances are you'll want changes made to the system after using it for a while, and we want to be sure that we build the code in such a way that those additions and features can be easily incorporated without upsetting your working, functional program (this is known as "extensibility"). You may also want to want to move from your local LAN-based network to support your remote workers in Chicago (this is known as "scalability"). This type of forward thinking takes extra time to implement, but the rewards you'll reap from this methodology are tremendous, and well worth the extra time on the front side of development.

Test and Tune

Test and tune goes hand-in-hand with the Development phase. During this time, we'll be delivering pre-release versions of the software for you to test. We want your feedback on this, and the more promptly you provide that feedback the quicker we can get your project finished.

We depend on you to thoroughly test the versions we provide, so please be sure to make time during this phase. We have in-house testing, and of course we do an extensive amount of testing during development, but we're developers, and we are not the best group to use for testing. We can arrange to have dedicated testing firms test the program for you, but of course this can be expensive, and to be honest you are the best judge of whether the program works for your needs.

And we want any feedback, whether positive or negative. We love for you to tell us that the new customer entry screen works perfectly, but we also love for you to tell us the Inventory screen doesn't allow you to add a quantity greater than 50, or that the email system gives you an error when you enter an invalid address, or that the report that shows how many Orders are going out from each Warehouse is hard to read and not grouped correctly.

And don'w worry. We have very thick skins. You can't hurt our feelings, and you can't offend us. This is your program, and we want you to be satisfied with it.

The Parallel Build

Once we've completed the development phase, and we're confident that we have a working version of the program, we implement a "parallel build" for final testing (this is known as a Release Candidate, or RC). In this, we'll actually install the program for you and a handful of designated testers in your environment, and we'll provide a testing database to use with the RC. If we're building a system to work with existing data, we'll port a copy of your current live data to the RC system, and turn your testers loose on it.

This is the final test phase, so it's important for the test users to thoroughly test the system and all it's outputs. It's not uncommon to find processes that work correctly, but don't quite meet your intended needs. Don't worry - because of our methodology, it is exceedingly rare that these issues are show-stoppers, and in most cases we can make changes quickly and get you back to testing.

Delivery, Training & Documentation

This is one of the last steps in the deployment cycle, and this is one that can cause a lot of panic. After all, you're taking a huge step in your business - you're about to turn over a healthy portion of your business to a brand new program that hasn't yet been tested in a live environment. The specter of data failure always hangs heavy, and there's no way to insure that the system won't simply crash, and shut down your entire company.

Don't worry. We've done this before, and we take great pains to insure that all works as planned, and that you're happy with the program. Because of the Parallel Build phase, we've tested the system against your live data, and we're very careful to make full backups before going live with your new system.  

During this phase we'll also package the application for deployment to your end users, and provide you with the documentation (if needed).

We can provide training for your users. Note this is generally not included in the cost of your software (unless your contract specifically states so), so please be sure to budget this in if needed. We can do onsite training, or we can do so using several remote access methods.

Support

We wouldn't be much good if we built your program and then left you hanging, so we have several different methods of support. We've recently installed a Remote Support page here on our site, where our technicians can remotely access your machines and help you with issues you might have. We also offer on-site support, if needed, and phone/email/chat support.

A Word about Milestones

Once we reach an agreement to work with you on your project we'll often give you a timeline of when we can start the work, when we expect to finish the project, and what milestones you might expect in between. A "milestone" is a specific event that we can use to gauge the progress of your project. For larger projects, for example, we might include a "database build" milestone, which would occur when we have finalized the design and structure of the database schema. Other milestones might include items specific to your project - for example, we might have an "email send" milestone, where me mark the event when the program can successfully send and receive emails.

Note that smaller projects often have no milestones other than the delivery of the final product. 

Milestones are often accompanied by payments from the client, and please understand that we strictly adhere to these milestone payments.