Provable Quality

Applied Research & Engineering

To realize a set of processes which deserves the name Provable Quality, we remain steadfast advocates of these core development steps:

1. Requirements publication and review.
   

   Only when requirements are precisely known and agreed to by all parties is it possible to define the scope of development.  Determining costs cannot be done without clearly defined boundaries.
   

   In the course of detailing software system requirements we discover the requirements for doing business, information flows, physical processes, and the market payoff of business activities.

   These issues and the prototypes described below enable ROI calculations.

2. Prototype proofs and user interface storyboarding.
   

   Once the development boundaries are known, the application can be blocked out in terms of architecture and user interface storyboards.  Prototype code and interfaces may be built and tested to determine precisely how requirements will be met.

3. Return-on-investment proofs of software development.
   

   Given the requirements, scope documents, prototypes, and storyboards, plus the information learned about business operations, we can determine:

   1. Purchase -- What software and/or hardware will need to be purchased.
   2. Rollout -- How long development will take for an appropriate team.
   3. Longevity -- What the life expectancy of the system will be.
   4. Cost of Ownership -- What the maintenance costs are likely to be.
   5. Enabled Business -- What effect on business the system will have.
   6. Total Return -- The value of benefits the system will generate over its life.
   7. Black Ink -- When the system will have paid for itself.

   Only when the above are determined to a satisfactory degree may viable decisions be made as to the feasibility of the project and the ultimate scope of the system.

4. Logical and empirical proofs of design and implementation.
   

   Logical proofs are those that follow the principles of mathematical proof, i.e., Hypothesis, Conclusion, and Proof using known and constructed Theorems, Lemmas, and Corollaries.  These proofs may be constructed for many elements of software systems such as algorithms (e.g., sorting and cubing), mathematical calculations (e.g., financial formulas), and complex conditional structures, to name a few procedural examples.

   A common example of proof in software systems development is the set-theoretical proof of database structural design, wherein tables (sets), columns (elements), and relationships are converted to mathematical notation and proved in the language of set theory and first order logic.

   Empirical proofs are experiments that assert some behaviour (the hypothesis, i.e., initial or hypothesized conditions) and seek to prove compliance (the conclusion or assertion, i.e., expected behaviour) via experiments that observationally prove or indicate the conclusion (or not).  We do empirical proofs when it is not possible or too costly to prove a behaviour via pure logic.