overview of a decision-orientated software p. farrell-vinay · 2014-05-19 · overview of a...

Overview of a decision-orientated software

process model

P. Farrell-Vinay

This paper examines some current models of the software development process, attempts to definethe limits within which a model can exist, and describes the structure of a sdlution.

Introduction and overview of the field

Many current models of the software process (Huseth & Vines, Osterweil, Quid & Roberts,Chroust, Hoffnagle* ) concentrate narrowly on software development, attempting to reduce it to aseries of algorithms. Such models are characterised by A procedural orientation, the degree towhich titles such as "write specifications" are presumed (by the modellers) to be ultimatelytranslateable into some form of executable code, and a focus which mostly excludes such factors asthe people developing the software, their repertoires, environments, goals, channels ofcommunication, rationale, order effects, and cost. Similarly Bruynooghe et a£ concentrate on thefunctional, behavioural and organisational aspects of process enactment concerned with the what,when and who but ignoring issues such as the why and under what constraints.

There is an concern for process programming in many such systems which is unmatched by aconcern for results. We contend that while process programming may be invaluable for the processprogrammer, in that the mechanics of the process are (perhaps) laid bare, it provides no automatedclue to deciding whether the process is a good one. There's no test suite or debugging tool, noprocess checkers. There exists as yet no facility for criticising a process other than looking at itcritically as any manager would when faced with a project plan. Equally few process modelsprovide the Actors with facilities to help them understand why the process is as it is (so they couldsuggest improvements), or to what standards the process must conform. Similarly the qualityassurance consultant or certification body, when faced with such a process model, cannot easilydetermine the degree to which that process is standardised or conformant.

Heym and Osterle by contrast have focused explicitly on the need to represent softwareengineering methods as expressed by descriptions and standards. Their MERET model is intendedto provide a software engineering reference model for a number of firms in the RIM consortium.They recognise the importance of the decision which they see as an instantiation of an activity andattempt to validate process models through comparison of viewpoints^. They have used theirtoolset as a means of modelling a number of proprietary methods including Systems Analysis^,ISOTECA lEM/JMA?, IEM/EY&, and SSADM*. At present however the level of analysis onlyallows them to identify topographical difference between the methods.

Curtis et al^ have suggested 4 principal uses, for process models; facilitating humanunderstanding and communication, supporting process management and improvement, automatingprocess guidance, and execution support. To these can be added; standards and QA support,project and quality plan generation, project simulation and debugging and project historydefinition.

The QSE model

Lloyd's Register is currently defining a model which may be used for project planning, training,and simulation as well as analysis. This model is called QSE (Quality Support Environment) andis distinguished from the more procedural models previously mentioned, by three central elements:the decisions, the actors who take the decisions, and the environment in which the decisions aretaken

The difference between the two approaches can be encapsulated in the question why does theprocess exist? The centrality of the rationale is the basis on which most of the QSE model'sfeatures rely. The model is capable of using and choosing between several processes to achievenominally similar ends. It is also capable of including its own planning process, and has a limited

Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517

404 Software Quality Management

vision of where it's going. In this respect it is similar to GRAPPLED.

Limits

A purpose of this paper is to attempt to define the limits within which the QSE model exists.These are essentially purpose-dependant: any model can be developed of any part of the softwaredevelopment process, replete with whatever defaults and details were considered useful. Thequestion here is not so much Is the model complete? as Is the model a useful one? A useful modelmust allow us to:

See who is doing what to whom. Roles and activities must be observable from temporal, role-related or activity-related viewpoints.

Distinguish between individual fallibility, structural dysfunction, and representationaldeficiency. The limitations of a system are its weak points relative to its goals. (Is some processfailing because of some individual actor, some group of actors, some inputs, plans, or tools? A poorworkman blames his tools is also management's excuse for its own failings.) We must be able tomodel down to the level of some type of person or tool. The bandwidth of the model must be bigenough, and its structures rich enough to permit us to eliminate faulty representation as a factor.

Define and observe entropy^ at work, the ripple effect of some decision, and theinconsistency and incompleteness of others. The model must allow the user to re-create errors(there's no point having a model if it can only tell us we're doing everything right) both at theindividual and team levels, as well as showing error recovery. Errors arise from failures to realise:the implications of some decision (a decision is itself a premiss on which other decisions weremade), that other premisses should have been considered, that the logic binding the premisses ofthat decision was faulty, that the execution of a decision was faulty, that the actual results of somedecision are other than the expected results, and that changes have occurred to the premisses onwhich some decision was based. Typically this occurs when there is inadequate communicationbetween development groups, or between such groups and the client. Changes may arise as theresult of: the realisation of the inadequacy of the internal structure of the solution domain, errorsin specifications or code in that some decision is inconsistent with its premiss, a change in the realworld, imposed by the client, and the realisation that an interpretation of the real world wasfaulty. If the granularity of the decisions taken is sufficiently small, the amount of entropy fromwhich some output suffers, and why actors are tempted to break the rules, can be decided.

Decide whether the changes it prompts us to make are useful. The QSE model is executable inthat given some inputs, some output is derived which will allow us to observe the passage ofoutcomes of the process. Thus the model can be used before, after or during a process. Its usefulnessis role-related in that one or all roles of the actors in the process might be taken by the user.Insamuch as the model is consistent with known project behaviour, it can be seen to be useful. Thiscan be determined by calibration, and validation.

Characterise the software being "developed", by size, structure (perhaps characterised byintegration strategy), difficulty, and degree of robustness required.

Identify those parts of the process requiring standardisation and metrication. Standards aremodelled as constraints on process execution (this is not wholly realistic of course: standards aresometimes ignored) mid metrics arc either modelled tis monitors of the processes (process metrics)or as calibration inputs (product and some process metrics)

Rationale of the QSE

The QSE environment is intended to assist project managers, project staff, quality assuranceconsultants and others to define, monitor and maintain quality parameters in a project.

Central to the environment are 7 issues:

1. project and quality planning and reporting,2. the use of metrics,3. the use of standards,4. help facilities,5. error estimating and tracking6. project histories,7. project simulation


Software Quality Management 405

Project and quality planning and reporting

There are three kinds of documents critical to a project's success; plans, forms and specifications.The QSE provides help in defining the first two with particular emphasis on work-packagedefinition and certification. Planning begins using the process modelling tool to define the waythe project is developed. Unlike traditional project planning tools the process modeller allows aproject manager to specify the standards to be used either automatically, by the use of processcliches, or manually using a clich6 editor. The process model output is used:

as a definition of the project schedule, by being input into a scheduling tool,

as the structure of a help system whereby any member of staff can examine the quality policyin the form of the standards set defined,

as the basis for the project simulator.

After the schedule has been produced, a set of work packages can be automatically generated. Theseare used during the project as an objective means of measuring project progress. The automatedsigning off of a workpackage as being complete is used by the project status report generator whichwill show which work-packages are late, on time and ahead of time, in both textual and graphicforms. The system generates both quality and project plan outlines'as well as much of the textrequired.

The QSE also provides help to project Quality Assurance staff in that it allows them to plan auditsin relation to the project plan, and enter audit observations with a tool which relates the standardand its requirement that has been transgressed, the evidence of the transgression, the recommendedaction to remedy the transgression, together with the confirmation that the remedial action has beentaken, using a tool to create both a series of text phrases and a logical representation that can feedinto the project history file.

The use of metrics

Metrics, particularly Function Points and COCOMO, are central both to the use of the projectsimulator and the plan generator. As process cliches are built into the process model, so each willhave a number of process metrics automatically included which may or may not be used by theproject. Additionally, support is given to the extraction of Function points from the specifications.These are used by one of the underlying representations of the process model to simulate thetransformation of specifications into code, manuals and tests. Built into this transformation is thegeneration, inclusion and removal of errors as a result of human fallibility, the quality policy, andthe verification and validation activities employed.

The use of standards

Standards are used in the QSE both as a legal expert system and as an aid to defining the qualitypolicy of a particular project. Each standard is composed of two kinds of texts:

background explanatory text,

standard requirements.

The background text is used in the help system, the standard requirements are translated intoassertions to constrain or promote the process model when the project is simulated to assist withthe generation of the workpackages, and also used in the Mp system to provide a logical answer toany query of the kind: wAy mwj( (Aw be done m (M; way, or wW jfandW u a/#caW€ (o (Awprocess ? Thus a requirement that A safety plan shall be agreed within 4 weeksof the end of the preliminary hazard analysis is translated into a Prologassertion within some process client and later used to prompt a project manager that the scheduledidn't show the safety plan being completed on time.

The standards are themselves in structured in an hierarchy:

At the top of the hierarchy lie such overall standards as ISO 9000, AQAP 13, and DoD2167 A,

At the second level are the LR Applied Information Engineering mandatory standardscovering such areas as general quality policy, requirement specifications, project and quality



planning and reporting, configuration management and system testing.

At the third level are the cliche-related standards covering such areas as coding, specification,auditing, Human-Computer Interface development and safety-critical software,

in addition there are a number of guides covering the principal processes. These are used toprovide supporting text.

A further advantage of the system is that it can be used to help draft new standards to cover thoseprocesses which are insufficiently standardised.

A quality system relies on rules as much as any other. It is useful to regard these as a legal system.As such it contains laws which can be coded in a manner similar to any other rule-based system.This is of use both to staff using the system as well as those who define standards. As qualitysystems become more complex, (for example the enormous mass of standards for the EuropeanFighter Aircraft) it is difficult for staff or standards-drafters to know whether one part of a standardcontradicts another. Similarly it is not always clear why some requirement should be adhered to. Alegal expert system with appropriate help facilities can generate textual answer's to such questions.Furthermore by tying the standards to the process model the set of standard requirementsappropriate to that process can be immediately defined, any unstandardized parts of the process can •be quickly identified, and any transgressions of the quality system can be more easily determinedby Quality Assurance staff.

Help facilities

Staff can interrogate the system to discover what they are supposed to be doing, and why, at anytime. This help is based on the work-package assigned to the staff. Since each work-package willhave a number of standards' requirements attached to it, it is a simple matter for the personconcerned to raise queries about: the standards to be used, why they are applicable, the inputs andoutputs of the processes, and time and order constraints.

Error estimating and tracking

Error simulation is central to the model's expressive power. If errors were not created softwareengineering as a discipline would not exist. Errors are handled in three ways:

1. in simulated form as a perverted Function point. That is, of the total number of functionpoints circulating through the system, a certain number are expected to be erroneous. Thesewill either be removed by V & V processes, or propagate as the system develops. From thisit is possible for example, to determine how efficient the V and V processes are in reality(because they will generate real error reports), how many errors are (probably) in the systemat any point, whether the number of errors in the system is likely to cause such a level ofentropy as to render the system unenhanceable^, and how efficient the modelled processesare likely to be.

2. in the form of error reports,

3. in the form of audit observations. These will relate the process to the specific requirementwhich is not being observed.

Project histories

Applied Information Engineering has access to a large number of project histories dating back to1977. These are being hand-coded into a set of process cliches. In addition the use of the QSE canitself generate further project histories. These can be used as an aid to future planning, and as aneducational tool.

Project simulation

The process model can be animated using the function points previously mentioned to:

generate a scries of possible outcomes of the project,

discover weak points in the planning such as staff with skills ill-matched to the tasks theyhad to undertake,



show which processes were insufficiently standardised.

Process cliches

Process cliches are created using an editing tool and exist at four levels: graphical, textual, logicaland finite state machine

Each level represents some or all of the following: process name, description (this may include aset of iterative sub-process representations), justification (in terms of standards or software),inputs, outputs, resources (in terms of tools and staff), triggers (a kind of input, being what theprocess requires in order to start) metrics and constraints (which may be the standards'requirements, order constraints (process A cannot begin until process B finishes), temporal (\hereview will last for 3 days) or resource-based (Process A cannot begin until Person X is free)

Process representation - graphical and textual

Figure 2 shows a cliche or partial model of part of the configuration management process describedin terms of the input and output processes, for a military aircraft software environment. Only theprocess names, inputs and outputs are shown.

Figure 2. The Configuration identification and planning cliche

By buttoning on the appropriate process name further processes are revealed.

-*f:"i'.2.'i"identify'the Software'"~f£ requirement* analyala documenta^ '.'.'.'.'.'.'.'.'...'.'.'....'.'.'..''.'.'..'.'.'.'.'.'.'.'.'.''........'.." *S> ........*p 1.2.2 Identify the Architectural deaign

p--»Vm.nn"™"!n •• "#c! <rv 1.2.3 Identify the Detailed dealg•'• documenta

1.2.6 Identify the Hardware/ a of tw a reintegration and teating documentaI: 1.2.7 Identify the Syatem integration and••• teating documenta

• 1.2.8 Identify the aoftware development

Figure 3. The Identify the software configuration items cliche



Buttoning on one of these sub-sub-processes shows the underlying process primitive.

Requirementsdocuments

General arrangement andinstallation drawings

Weapon system designand performancespecification

= Trigger

Description: As soon as any requirement vdocument is to be used by any other groupthan the one developing it, it must be put;under configuration management V

Constraints: Standard PT 025-0R3 Each item must be identified by name,version and/or variant.R4 Each item must be formally placedunder configuration control

1.2.1.3 Put requirements phasedocuments under configuration

/ Justification: prevents uncontrolled/ changes to the document occurring

S Resources: Configuration Librarian,Configuration management tool

Metrics: Number of documents underconfiguration management, Documentsize, Length of time an error has existed I

Figure 4. Part of the Identify the software requirements analysis documents cliche"

By buttoning on one of the hypertext buttons in the process primitive name a window is openedaccording to the type giving a textual representation of the process elements. Those inputs acting as

triggers are identified with a on the arrow connector.

Process representation - logical

Each process IS represented as a number of (say) deontic or other Prolog clauses thus:

obliged_to_put_under_configuration_management(conf iguration_manager, requirement: s_phase_documents)

and

is_generated_by(safety document, requirements_phase)

Similarly the text for the attributes of each process is also represented as a set of logical assertions.

Process representation - FSM

Each process is also represented, by a Petri-net with the Function points representing tokens.



Draft generalarrangement andinstallationdrawings

(

_

1 "l '

Approve 1.2.1.3 Putrequirementsdocuments urconfiguration

Release generalarrangement andinstallationdrawings

v J

phaseidercontrol

Figure 5. A finite state machine representation of part of the Identify the softwarerequirements analysis documents clichd

As each token or Function point passes some Place (in Petri-net terminology) or process, thesusceptibility of that Place to inserting or removing errors will cause either a proportion of theFunction points to become errors or to rectify those Function points which were previouslyerroneous. This susceptibility is determined partly by empirical analysis of a number of project errorlogs, and partly from the industry data and histories previously mentioned.

Project simulation

Once the cliches constituting the required process model had been assembled they can be exercisedby inputting the Function points derived from the (real) requirements specification. This willreveal: the expected level of errors in each document or module, at each stage of the project, anybadly-formed processes: that is processes whose inputs or outputs are undefined and the efficiencyof each process.

Use

In operational use the model is the responsibility of the project manager or some librarian to insertall critical decisions into such a model as they are made.

In training use the model is tailored to the student by the inclusion of default files containing thedecisions which the student is not responsible for generating.

In planning use the model relies on default files containing environment-specific data for theplanner to use. Typically this includes Cocomo or Function-point models.

In debugging use the model generates error messages identifying missing inputs or outputs,unmetricated processes and unjustified decisions, and displays metrics data.

The model is executable in that it generates messages telling us what's happening (Sam is coding ),and perhaps some final message (Client has paid for the product). These messages "prove"anything about the workproducts to the extent that a simulator (see below) is accurately calibratedagainst the output of previous projects.

When simulating, the QSE is itself a decision-taker and it is the kind and level of decisionsimplicit in its output that determines the granularity of the decisions left to the person(s) executingthe model. It is structured as a series of expected results, associated decisions, dependencies, genericpremisses, pre- and post-weights, models of actor, element, and environment types, and errorinsertion/deletion routines.

Following Albino et al^ the QSE uses a random number generator to fill a plane surface of mgroups of 16 squares where m = number of capabilities /functions /components, using anaggregation algorithm whereby the first square is always filled and the second is filled iff it iscontiguous to the first. This conveniently produces small boundaries at the beginning andparticularly at the end of a development with the result that the work product starts slowly, reachesa production peak in the first third of the time and thereafter declines. 75% of the work-product isfinished in 50% of the time. The shape of the plane figure can be varied to provide a closerapproximation to Pare to. These squares simulate the specifications and are filled with the functionpoints (erroneous and good) derived from the real specifications.



Errors are introduced randomly as \htfigure is completed such that iff two errors are contiguous, afurther n errors are also introduced. The type of errors depends on the process being executed, theexperience and motivation of the staff, the tools used, and the work-product involved.

The transformation of work products is simulated by a mapping between spaces occurs in which aproportion of existing errors are propagated automatically from one space to another and some areadded. The size of the space is determined partly by the Function-point model used by the studentand partly by calibration.

Entities

The language of the model is essentially entity-driven. These are grouped under Environments,Elements, and Actors.

Environments

Three environments are modelled in QSE:

The development environment consists of the tools, specifications, plans and standards whichcontain implicit (and sometimes explicit) definitions of the processes.

The business and financial environment contains the principal drivers and such externalconstraints on the project as budget^, code size, and timescales. It defines both the client, thecontracting firms, and the problem domain^.

The administrative environment defines for example the project geography, levels and definitionsof authority, the project internal constraints in the form of permissions and access to resourcesand that part of the project's working environment not explicitly related to the development andbusiness issues.

Each environment is defined in terms of their maturity^, the decision- making structure, thechannels of communication their band widths, filters, and speed, both between the environmentsand the actors within them.

Elements

The process elements are defined in terms of:

The contract(s), terms of reference, plans, and standards, and specifications by which the projectis run.

Extra-process inputs in the form of definitions of the problem, and the project objectives. Notethat specific inputs in the form of specifications are not used by the model. These are represented asa set of function points..

The assertions of a project are the contract documents, plans, standards and of course decisions.Some assertions are supported by others. Thus for example all assertions of a contract are part of thepremisses and logic of the resulting project and quality plans. Assertions may be strongly, weakly,or conditionally linked to their premiss(s). The assertion embodies the premisses and logic of thedecision. To be explicit and modelled, a decision must be embodied in some assertion. The contractis modelled as a set of (changeable) authorisations and constraints.

Actors

The process actors are defined in terms of:

Their roles, which may be the client, the client staff, project management, development staff, (whomay be designers, coders, testers, technical writers, and metaprocess modellers, in terms of theirauthority, relationships, and channels of communication.

Their goals, which may be private and professional.

Their repertoires, which may include the abilities to work in a team, solve a problem wholly orpartly (by recognising, analysing, abstracting out essentials, acquiring knowledge of*° andmapping analogous solutions onto it), administering themselves by expressing decisions fluently,



checking that decisions have been executed, allocating resources, working to some level of accuracy,and planning ahead. These are represented as sets of capabilities and constraints (defined in termsof some rate of work, and motivation with respect to some capability). In addition the repertoiresinclude ontologic, meta, and procedural knowledge of both the application and softwareengineering.

Actors have some notion of chunking such that an actor can include a number of activities underone goal name and recognise when these activities are needed together such that he can parse theminto some goal - and thus perhaps remember some non-intrinsic attribute or caveat of that goal, orthat set of activities.

Decisions

Central to the relationship of these actors and elements in their environments lies the decision.Motivated by project and personal goals, actors take decisions in an attempt to transform someproblems into some solutions. These decisions are structured as shown below and are recorded insome document. A problem is partially solved if it matches some part of the repertoire of some actorin a position to solve it. This solution is embodied as some decision, and each-solution so derivedbecomes a problem for some other actor in the process.

Decision structure

Environment) 1premiss 1 |

i 'logic

t(actor) 1

premiss 2

(element)premiss3

actorIF (premiss)

V 1logic 1

X 1 ,H decision

•— ^ i '^ ^ ^ embodied in

—

1 element

— usmg n n

,11 environment

~~*J actor1

X^i — |j element

Figure 1. The structure of a decision. (Only a sample of possible relations is shown)

Here the model departs from reality: decisions are sometimes taken without ever being recorded.They may thereafter have a long half-life.

A decision is represented by:

The premisses, which themselves consist of any part of the environment, elements, and actors whichthe model can derive from their definitions and other input or generated partial solutions includingthe expected and actual results of that decision. The actual results of some decision is the set ofchanges to the set of elements and actors on which the decision operates.

The logic or relation between the premisses which can usually be defined as a because (of someconstraint) or in order to (achieve some result) relation but other relations such as has authority toand must are involved.

The actors taking and affected by that decision insofar as some actor has the capability (withinhis/her repertoire) and authority to take some decision, and another actor is subject to and/orobserves that decision.

The elements affected by that decision which include the tools, workproducts, plans, and standardsof some project These too may be the assertions used as premisses in some "later" decision.

As a project develops, a network of many-to-many connexions of decisions also develops. Such anetwork remains mostly invisible even when captured in one of the project documents because nomeans of capturing the decisions on the fly has yet been developed. Another purpose of this modelis to simulate such a network such that the shape of a project's decisions can be clarified.



Decision types

Decisions may be categorised as: planning, designing, buying, coding, testing etc. Each decision isconcerned with form, method, content, and some authority level. Each may have an generic (in termsof accepted methods or body of knowledge) set of premisses which may or may not be consideredwhen the decision is taken. Such generic decisions may be regarded as cliches (We all know thatCM involves...) and may imply many other subsidiary decisions. Such cliches are reflected in theelements the actors' repertoires, and in the simulator (see below).

Decision attributes

Limitations on the efficacy of such decisions derive from the degree to which the decision-makingprocess is error-prone, and of course from the degree that they can be adequately represented both inthe "real-world" and some model. An analysis of a decision network requires both a language and arepresentation, such that a critical grammar can be derived:

An error in a decision means that some expected result didn't occur.

A bad decision is one which is inconsistent with a previous decision^, or chosen rather than onewhich either achieved more results or met the same number of expected results with a lower post-weight, (see Decision metrics below) or some combination of results and weights.

An arbitrary decision is one which has some premisses which are implicit, (existing in terms ofsome later dependency or model of expected premisses (possibly represented as assumptions) butwhich are not taken into account at the time a decision is taken. Alternatively not all the possibleoutcomes may be considered.

Decision metrics

Representing decisions to some level of detail renders some degree of metrication possible:

The vulnerability of some decision is the number of premisses it has, ordered by generation. Thusa premiss will have n immediate premisses (1st generation) each of which will have m (secondgeneration) premisses, etc.

q=8 m=7 n=3

decision (d)

Figure 2. A decision and its premisses. (The hierarchy shown here disguises the fact that a p-2 mayalso = some p, thus rendering the decision (d) even more vulnerable)

Thus a change to p-2a will affect p-la, p-lb, and p-lc, and thus every premiss on which decision(d) is taken.



The converse of the vulnerability of a decision is the importance of some decision: reversing p-2awould affect 7 other decisions. The speed with which the other decisions were changed would affectthe efficiency of the process, and any failure to change those decisions reflects the degree of entropywithin the process.

The post-weight of some decision is the number of person-hours required to achieve the goal ofthat decision. The pre-weight of that decision is the number of person-hours required to arrive atthat decision. Thus the pre-weight of the client's decision to give you the project is the total man-hours of pre-sales work by client and salesman, and the post-weight of the client's decision is theamount of work to complete the project. Weights are critical as quality and planning determinants.As each decision (d) is taken, some work is generated before the goals of that decision are achieved.Thus a lime-lag occurs before the results of such a decision are observable. During that time, otherdecisions (d+1) may cite decision (d) as a premiss. If the goals of decision (d) are not met to someextent, this may render the (d+1) decisions invalid.

The importance of some decision is

Z (decisions citing it as a premiss) * (decision post-weight)

The success of some decision is

Z (goals met by that decision)/(post-weight) A decision can always be revalued in that it isfound to achieve more goals than expected and/or with a lower/greater post-weight..

A careless person may be modelled as one who fails to cite more than n % of the premisses of ageneric decision. The weight of a decision is critical to determining if the process in which thatdecision is taken is good.

Input

The inputs to the model are the simulator default files, containing:

empirical input drawn from projects in terms of specifications, plans, data and memoranda,reworked by interrogating the project participants to determine their premisses for eachdecision

calibration input in terms of accumulated project management heuristics and data,

And the user files containing:

definitions of the environments (including definitions of software tools in terms of thedecisions they need and the premisses and workproducts they provide), elements and actors.

definitions of the role being taken by the user, and the level of feedback to be given,

definitions of the project goals and constraints including the degree of robustness required.

Note that the plans alone exist merely as constraints which the student may ignore (at the cost of aproblematic quality assurance audit) or change, with approval from his management. The decisionswhich the plans outline must still be made.

The decisions are structured in the form of: Person (actor title), Do (decision), Because((anterior) premiss set), In order to (expected results),Using (tool), Embodied in (element),Affecting (element, environment, actor) and, During (project phase)

Note that only the underlined fields are mandatory. The Because field may not be required since thestudent need not necessarily be under (or aware of) any previous compunction. The Using field isredundant if no tool is used. The result of the decision may only affect the element embodying it,and the During field is merely for accounting purposes such that some decision can be related tothe timing constraints of the process model.

A student may explicitly chunk a set of decisions together (as say Integration test) and merelygive the one decision.

Decision validation. If a user cite some decision and/or expected result not included in the default



files as a generic, the user must define, using a new process cliche", how the expected result is to beachieved, in terms already known to the simulator. This is one of the weaknesses of the model inthat the validity of some unknown process is questionable until some actual project conduct somecomparable process such that calibration of the model process can be achieved.

Output

The output of the model are the Help files showing generic decisions to be taken, and theassociated premisses which may be cited, a graph showing all the decisions and their premisslinks. The level to which we need to see the graph and the decisions can be limited to some rangeof weights. Smaller decisions could be subsumed (or chunked) within larger decisions (unless thereare dependencies). Other outputs are: Messages indicating the status of the model in terms of thebehaviour of the actors, the changes to the environment and elements, and the errors made, a projectaccount showing the cost to date of the decisions, and the relevant timesheets, lists of decisionsordered by importance, vulnerability, and success and lists of errors both in the work-products, andin the student decisions.

Validation

Validation occurs at two levels; the macro and the micro, as well as intermittently during thedevelopment of the model as a tool and during the use of the model. At a macro-level, by ensuringthe model can exhibit such "laws" of software evolution as Lehman and Belady^O proposed and ata micro level, against real project-derived-da ta . Validation continues during the development ofthe system model (as each entity is introduced, refined, and related to others) and during the use ofthe model as users informally compare the output with their experience. All the data on which themodel is built is traceable to some source.

There remains the problem of defining the validity of the software built by some process in themodel. If we can accept that all errors are ultimately process errors , then a way of validating someprocess as being "better" than another is to substitute it in an otherwise identical development. Thiscan then be echoed at the model level but even so we could not be certain that it would producebetter software.

It is not always the case that some procedure is unique-to-task. There may be several. Part of beinghuman is that we can chose. Another part is that we may err. Thus a procedure to module test somesoftware need be executed with more rigour if that module is life-critical than otherwise. Equallythere may be no advantage that a software engineer know how to design well if he is ordered bysome uncomprehending manager to curtail reviewing^.

UseoftheQSE

Let us assume the QSE is in teaching mode. A student has logged on and acquired the role of (say)project manager. The student may review the decisions already taken concerning the development,business and administrative environments, those available and the project process model.

He%4 then decides to tell the senior analyst to write version 1 of the requirements specificationin English. The system has a function-point-like metric of the problem to be solved. It also has amodel of the senior analyst and his abilities. If the student doesn't assign anyone else to the task,the requirements specification (version 1 ) would be written very slowly and with very few errorsdue to internal communications difficulties. However, since the system has a process model of theproject, it realises that the senior analyst will need more help to finish on time and advises thestudent accordingly.

The system represents the requirements specification as a work-product with a function-pointnumber and a number of errors of various types related both to the problem type, the abilities ofthe staff working on the problem and the tools used. The student then decides to review thespecifications using a team of experienced analysts. Many errors are found and the systemrepresents their discovery by removing many of the errors from the requirements specificationwork-product file, (and adding some more).

The version of the requirements specification, is given to the client to review while a team ofdesigners begins work on version 1 of the technical specifications. The client finds few errors andrequests few changes (The student did not decide to provide the client with a prototype ). Thosechanges required, are incorporated directly into the requirements specification (version 2) withouta review. The team of designers finish version 1 of the technical specification, and the studentdecides to perform a walkthrough. This finds a number of errors, partly in the requirements but



mostly in the technical specification. The student decides to incorporate the changes from version2 of the requirements specification.

The client requests further extensive changes in the form of 45% extra capabilities in therequirement specification and the removal of 25% of the existing ones, and demands a workingversion in a shorter timescale than was planned. The number of function points and errors isincreased.

The student refers to the contract and estimates the cost of providing the extra capabilities. He isordered by his manager to move some of his staff 60 miles onto the client site where the,development environment is provided and maintained by the client in order to provide the workingversion. The student estimates the cost of the working version and of the communicationdifficulties this will entail. He does not specify the telephone and fax facilities required. Nor doeshe specify a clause in the contract concerning the availability of the client development system.

It is not difficult to imagine the problems which will beset the student in the future. Thosementioned are large-grained and principally contractual. Other problems concerning (say) thestructure and capabilities of the analysis and design teams, and the work-product handover method,are introduced depending on the activity to be modelled and the role to be played by the student

Conclusions

Due to limitations of space several aspects of the Quality Support Environment concerned withQuality audits, Standards development and Audit planning have been ignored. It is hoped that thiswill not cause readers undue confusion. Similarly the project as currently envisaged rests on a largenumber of unstated assumptions.

Acknowledgements

The author thanks Rod Rivers of Logica Cambridge for several useful discussions on the roles andnature of clients.

1 Proceedings of the 3rd software process workshop

2 Bruynoogh R. F., Parker J. M. and Rowles J. S. PSS: A system for process enactment. ICLKidsgrove.

3 Heym M., and Osterle H. A semantic data model for Methodology Engineering. Proceedingsof the Fifth International Workshop on Computer-Aided SW engineering. IEEE. July 1992.

4 Heym M., and Osterle H. A reference model for information systems development. ReportNo. IM2000/CCRIM/15 Version 1.4. University of StGallen. Switzerland.

5 Yourdon E. Modern Structured Analysis. Prentice-Hall, London 1989.

G Iruormationstrukturanalyse Version 2.2 und Funktionstrukturanalyse Version 2.1, EDVStudio. Ploenzke.

7 ISP - Information Strategy Planning handbook, James Martin Associates Ltd. Dublin, 1987.

8 Navigator systems series reference and analysis phases manuals . Release 1.0 Ernst andYoung.

9 SSADM support tools conformance appraisal scheme. Version 1.08. CCTA, London 1989.

10 Bill Curtis, Marc I. Kellner and Jim Over Process modelling. CACM Sept 1992.

11 Huff K. E. And Lessor V. R. A plan-based intelligent assistant that supports the softwaredevelopment process In Software Engineering Notes of the ACM. 13. 5 1989.



12 This approximates to Lehman's (in M Lehman and L Belady, Program Evolution AcademicPress. 1985.) second law as well as a useful discussion in R Jensen and C Tonies. SoftwareEngineering Prentice-Hall. 1979.

* 3 See T.A. Ham id and S. E. Madnick Software project dynamics - an integrated approach (Prentice-Hall 1991) for a discussion of this.

* 4 V Albino, S Cavallone and G Mummolo. A new approach in the engineering projectanalysis: the aggregation game . In Project Management. Butterworth. Vol 6 No. 1 February1988.

* For as discussion see B C W Boehm and F C Belz Reasoning about iteration, a cost-benefit approach in M Dowson (Ed.) Proceedings of the 3rd Software Process Workshop.1987

1 & Thus the model is amenable to a risk-driven environment such as that proposed by Boehm inA spiral model of software development in Software Engineering Notes. ACM SIGSOFT.August 1 986

17 For a discussion see W Humphrey Characterising the Software Process in Software. IEEE.March 1988. Indeed an objective of the model is to be able to identify and model riskswhatever their origin. We contend that unlike (the implicit assumptions of) some authors thesoftware development process is only one source of risks.

1 8 Measured in terms both of latent inclination to learn, and exposure to the problem.

19 In that either none of the premisses of the previous decision was common to that decision(excepting the previous decision) or that the one or more of the premisses of the previousdecision were the negations of the premisses of the later decision.

20 Opcit.

2* Typically embodied in: the Project history file, the Project debriefing report, the Projectplans and quality plans, error report forms, contracts and memoranda, comments both in thecode, and in the source code management files relating code changes to errors found, andoutput from design or code reviews.

22 it wasn't my fault, it was the process

23 We have seen the enemy and it is us: Leon Osterweil (Private communication).Unfortunately the us refers not only to software engineers but their managers, users and theclient.

24 = she for the purposes of this paper.

25 Words in italics in the following 6 paragraphs indicate model-specific actions.
