How the Software Development Process Works
The Sales Call
The Engagement Letter
Design and Prototyping
Change Orders
Delivery
Payment
More Questions?
|
|
How the Software Development Process Works
|
Maybe you've never contracted for custom software before, and thus don't know what to expect.
Or maybe you've had the unfortunate experience of working with someone who, well, didn't have it all together, and so ended up
with a less-than-satisfactory result. In either case, it's good to know that there is a well-defined, managable process for designing,
building and delivering custom software. Here's how I've been building apps for the last 20 years.
|
The Sales Call
|
In my experience, building custom software is a lot like building a new house. There's an
initial "sales call" where I determine the size and scope of the project to make sure it's within my capabilities, where you
sound me out to see if you're going to be comfortable working with me, and and where we mutually set expectations for
the development process, costs, deliveries, and responsibilities of each party.
|
The Engagement Letter
|
These expectations are laid out in writing in what professionals in other lines of work, such as accounting and law, call
an "engagement letter". Since software development - particularly the beginning phases - can be a rather ethereal process,
the purpose of this letter is to document how the process works and what each party's expectations and responsibilities are.
For example, the final acceptance meeting is no time to start asking about ownership of source code, although I've seen it
done by other developers on other projects!
|
Design and Prototyping
|
Hopefully the sales call leads into the design process. If you've done any sizable house construction or remodeling, you know this
is the fun part, where you get to go through your 'wish list' and see it come to life through blueprints and floor plans.
In the software world, it's even better, as I often prototype screens and reports and you can see very much what the finished
application will look like.
More than one customer in the past has
wondered "What's left?" after seeing a demonstration of a detailed prototype. (The answer is "just about everything - data,
business rules, connection to the Internet, testing, and so on.") Viewing a prototype is like walking down the main street of
a town in the old Wild West, where the buildings have grand facades, but when you peek behind, you realize there's nothing there.
The end result of the design process is a detailed specification that describes the application as well as itemizes the schedule,
milestones, pricing, and covers how testing, change orders, development process in more detail.
|
Change Orders
|
Once construction starts, there are often changes to the specification/blueprint. With a house, it's not uncommon to hear a
homeowner say, "You know, now that I see what this looks like, I'm thinking we could...." Even more so, software development lends itself to iteration, as the customer discovers new possibilities (as they see what the
software is capable of in the hands of the developer) as well as making changes in their company processes. It's a rare application
that ends up the way it was initially designed.
Maintenance of an existing application has many similarities to doing remodeling of an existing house. In addition to budgetary constraints (it usually
doesn't make sense to put a $200,000 addition on a $70,000 house), there's always
a process of discovery when construction starts: "Why did they put a pipe in the middle of THAT wall?"
So it goes with making
modifications of an existing application, which is often undocumented and usually contains hidden algorithms and unconventional ways of
performing standard tasks. Some folks use formal change orders while others are comfortable with verbal requests. I prefer the
written documentation route, as it serves to alleviate misunderstandings and provides an up-to-date description of the system.
As with blueprints for a building, the
only thing worse than no documentation on a software application is out-of-date documentation.
With house building, the inspector comes by at regular intervals to inspect the various subsystems, such as plumbing, electrical wiring,
mechanicals, and so on. With software, a well-managed project has frequent milestones where pieces of the project are delivered for
testing and acceptance.
|
Delivery
|
Depending on the type and structure of the application, delivery can be made in one of two ways.
The first is in pieces, where segments of an application are
delivered and installed, ready for use while other parts of the system are still being built (much like being able to use the
new den even though the kitchen isn't finished).
The other way is all at once. Even though parts of the application are delivered for acceptance testing, the nature of the application
is such that it can't be installed and used until the entire system is ready - again, much like not being able to move into a new
house despite the framing, electrical, mechanical and plumbing being installed - it's drafty without windows and awkward without
kitchen applicances or sinks and bathtubs.
|
Payment
|
The design phase of a project is done on a time and materials basis. Some customers pay in advance with a retainer, thus
ensuring that they get first dibs on my time, which can be advantageous for a critical project. Others prefer to be invoiced on
a regular basis for work completed to that point.
The development of the system, including programming, testing and delivery, is done via invoicing per milestone as per the schedule
in the specification. Charges for change orders for all parts of an application are included with the invoicing for the current
milestone.
|
More Questions?
|
This has been a brief outline of how I do software development just to give you the big picture of what you can expect.
You'll more than likely have more questions, either
about the process in general or about a specific application. Please feel free to contact me - email is best! -
here.
|
|