Introduction

What I am about to inflict

• Introduction
• Apologies and Disappointments
• Life Cycle Models and other Myths
• But ...
• Not Getting any Better
• The Problem
• Understanding the Objective
• Understanding the Process
• Attributes of the Process
• Parts of the Solution
• The Source
• Changing and protecting the source
• How to express the transformations
• Validating the source and transformations
• Validating the source and transformations cont.
• Church's Lemma
• Funkenhauser's Rebuttal
• Conclusion

Apologies and Disappointments

Not an apology to the audience,

but to our clients, users, and employers ...

As a community, our track record stinks ...

and we don't appear to be improving despite out efforts since the mid 60s with:

• Documentation techniques
• Languages
• Standards
• Design techniques
• Formal methods
• Software metrics
• Software tools
• Structured Programming
• C.A.S.E.
• Countless other U.P.M.L.A.s
• ...

Life Cycle Models and other Myths

Manage software as if its development consists of:

But ...

Unfortunately software management is:

Not Getting any Better

Problems are multiplying ...

• Greater client expectations
• Greater Competition
• Greater Complexity
• Worsening Environments

The Problem

The problem is that producing software is complex ...

maintaining it is even worse ...

but ... I believe that by:

• understanding your objectives;
• understanding your process; and
• ensuring your process leads to the achievement of your objectives;

you can eliminate many solvable expensive problems that plague the software industry.

Understanding the Objective

Have fun and make money ...

...

An achievable goal: ensure that the developers' efforts are transformed into running client-site software, such that:

• the client got what the developer intended; and
• what the client got, can be fixed.

Understanding the Process

``Software Process'' has a lot of dimensions ...

Concentration on the transformations of programmer efforts into a client-site instantiation so that we know:

• what was delivered was supposed to be delivered and
• all that was supposed to be delivered; and
• if we screwed up, we can reproduce it so that we can fix it.

Attributes of the Process

An appropriate process is the product of a set of transformations that is:

• Mechanical
• Reproducible
• Known
• Complete
• Testable
• Consistent
• Robust
• Efficient??
• Incremental?
• Universal
• Flexible
• Succinct

Parts of the Solution

A partition of the areas of concern:

• The source;
• How the source is changed and protected;
• How the transformations are expressed;
• How the source and the transformations are validated.

The Source

The source is:

• the product!!!!
• all the information required to produce, validate, audit, test, document, and control the product in its current and historic forms.

Changing and protecting the source

Probably a good idea that:

• people have a common understanding of how this is done.
• people understand the responsibilities inherent in the act of changing the source.

Should be audited -- easy to roll-back, roll-forward, snap-back and undo.

How to express the transformations

To dispel commonly held beliefs:

• make(1) is not enough;
• imake(1) is filling a much needed gap.

A common failure is to not have procedures to compensate for the limitations of the approach used.

A solution is to acquire qef, but ...

Validating the source and transformations

... worth many times the price of registration

#{ @gobo 1999/08/24 01:40:52
# QEFHALTFILE: /p/web/o/fsic/%qef11841b.hlt
+ cush -o. ,inst.rls -d /p/web/d rls -sN/
+ cush -o. ,objs.rls -d .. rls -sN/
+ bfsic -I ,inst.rls -O ,objs.rls > ,p.errors
+ rm ,inst.rls ,objs.rls
+ transl '/p/web/d/\0' ,i.tmps | /usr/qtree8.4/bin/sort -o ,i.tmps
+ rep -Z '/<_|[!$_][on]>\#' ,i.tmps | linked -nf | rmlist -f
+ fexists -l ,i.tmps | /usr/qtree8.4/bin/sort -o ,i.tmps
+ fexists -e ,[iop].* | rmlist -q
+ untouch -c ,o.tmps
+ (cd ..; ls fsic/,*) | /usr/qtree8.4/bin/sort -u -o ,o.tmps - ,o.tmps
+ fixflist -aq -r -d.. -s'..' ../fsic/,o.tmps
+ lls -o .FL ,[iop].* | rtabs -T 8l16l6R
	,o.tmps		     4
	,p.errors	     3
#} E0 gobo@/p/web/o/fsic 1999/08/24 01:40:53(1)

Validating the source and transformations cont.

Test, test, test

Bare metal builds, when you can afford it, not when you need it.

Believe in Murphy

Church's Lemma

``It's easy if you know how'' -- Stephen Church, 1994

He's right ... but ...

Funkenhauser's Rebuttal

``No it isn't'' -- Mark Funkenhauser, 1994

No matter what you do it's difficult -- building and delivering software effectively is a mind boggling difficult thing to do, even if you know how.

The process has to be continually tuned and tested;

Training should be continuous; and

Use every lever you can

Conclusion

What I meant to say ...

• Understand what you are trying to do ...
• Understand how you are trying to do it ...
• Ensure that everyone involved understands what they are to do ...
• Understand the limitations of your tools and evolve your process to compensate for deficiencies
• Test that you are meeting your objectives;
• Test that you can do so in the future by protecting the current.

church.qh - 1.11 - 03/10/24