Design options ...

Design Options

Changes effect all users.

Developer:
Theme:
Components:

How We Do It

First Published (Original Date):
2007-07-17%
Datetime Format:
EDTF with spaces.

Introduction

Softmake wouldn't dream of relying only on its own experience to give you, the client, the right solution.

We have a Software Development System based on research from computer science and the software development field. That is, we draw on the experience of thousands of real world software development projects.

For the client those features of our Software Development System of direct interest include:

For the developer, or the curious client, further features of our Software Development Systems are:

A part justification of our Software Development System, of direct interest to Developers, can be found under a Simplified history of software development.

The remainder of this article is directed toward giving you, the client, an overview of our Software Development System, in so far as it describes our interaction with you to deliver a Software Solution.

Lifecycle

Whether it is a multiuser database application or a website we go through a similar software development lifecycle by default (Although the particulars of your project may warrant a change in the design of the lifecycle).

The "full lifecycle" could describe the period from initial recognition of the need for a software application to the time version 5.63 is uninstalled off the last user's computer. Here "lifecycle" will refer to the shorter period between integer releases, e.g. between initial idea and 1.0, between 2.0 and 3.0, or for analogous periods of development for websites.

With all but the smallest of projects you will necessarily be vague about what want. In part this the nature of initial ideas. In part what you want depends on what we can give you, the options we can provide. Indeed the entire software development lifecycle is a process of becoming less vague, more detailed, about what is wanted. We take responsibility for drawing out your requirements and providing you with clear and specific options.

Default Lifecycle Taxonomy in brief

There are all sorts of (partly arbitrary) ways to slice and dice the software development lifecycle. The classic waterfall has about seven phases (Requirements Analysis, Design, Coding, Testing, Integration, Install, and Maintenance).

Our Default Lifecycle Taxonomy has four "Eras" (Specification, Build, Delivery, and Maintenance) that overarch 16 phases.

Default Lifecycle Method (or "Software Development Process") from a client perspective.

Specification Era: Initial Requirements Gathering Interview

We begin with an Initial Requirements Gathering Interview to get an overview of what you are after. This can serve as an introduction to us and to allow you to bounce around a few ideas. You may be wishing to meet several software development businesses to listen to what they can do for you. The initial meeting is free and there is no obligation to continue with us.

Specification Era: Design Phases

If you wish to continue we may go through further Requirements Gathering interviews. We'll move into a design phases where we might use prototypes and mockups to explore proof of concept software architectures and draw out more detail about your requirements.

The line between "requirements gathering" and the "design" phases, as for most software development lifecycle phases, will not be distinct.

Further, there will be to-and-fro between the phases. For example, during the "code" phase a devil may emerge from the detail, revealing a design choice that can only be made by you, the client. A phone call to you might be required. This communication would count as a "requirements gathering" activity.

The Specification

There is one exception to the lack of clear distinction between the phases. The coding phase has a distinct beginning (although there may have been coding experiments during design).

The phases within the Specification Era will be aiming at the milestone of the final specification document(s). This defines the system to be built. You, as client, sign off the specification as representing what you wish. From this we will give you a fixed price quote and a schedule estimate.

For small projects these phases, prior to specification sign off, are free and there remains no obligation! You can take the specification documents to other software development businesses to get a quote. They will wish to spend some time, if they are any good, producing their own specification document(s). However the bulk of the specification era work will have been done.

Note that 40 - 60% of the total project time will need to be spent in the phases leading up to specification document(s) sign off.

Modelling your business requires a significant amount of detail. So these phases require a corresponding amount of time from you and/or user representatives.

This is time well spent and not only for the sake of getting a software system. We must always bend software to what we want it to do, not what it would have us do. However, going over your organization's workflow, in order to build the software, provides a powerful opportunity to evaluate how you operate. Often this process will bring clarity to your purposes and the way you do things. This process may also reveal how your workflow might be changed for the better.

For further details on what a "Specification" is see the specification section of our "Contributing Principles to a Software Development System".

Build Era

If you approve the quote we will move into the Build Era. We code the specification, perform alpha testing, write user and developer documentation, and train the users.

Note that the order of these phases serves as a quality assurance mechanism in itself. For example documenting the software system after coding is a good verification of the consistency of the design as coded. The documents are written for humans so that software system is verified for humans. If an inconsistency where discovered at this point then we could re-enter a design and code phase. This would be far less expense then discovering this after release, or even during the User Training phase.

Similarly, having users trained on the system before release does more than help a released system run smoothly. This serves as a check of the design. It is far less costly to catch a design mistake at this point rather than upon release.

This shouldn't be taken to diminish the purpose of the specification era. A properly conducted specification era is the time to iron out most design issues. The point here is merely that the ordering of the build era phases can serve as design checks.

Delivery Era

After on site installation and testing we will go through acceptance testing. This will be a series of automated and/or user conducted testing (directed by the developer) to demonstrate to you, the client, that the system works according to the specification.

After release, "go live", of a Software Solution (anything more than a static website) we'll keep a particularly close eye on the system in the first seven days. Only after seven days of operation according to the specification, without any significant issues, will the system be deemed "Delivered."

Static websites will be deemed "Delivered" after Remote Server Testing, beta, is complete.

Further Details

Although of direct interest to Software Developers, curious clients may want to look at a more detailed explanation of our Default Lifecycle Method.