Project Delivery Process D700

D700 - Parameterisation

DEFINITION

Set up the package’s system parameters, codes, structures, etc.

SUMMARY

Each aspect of the system's basic configuration system should be set up in accordance with the agreed implementation papers.  This will often be achieved efficiently by transferring the parameters from the Design Prototype set up in process D400 - Design / Prototype.

Informal tests may be performed to check the setup prior to formal testing.  This technique is known as a “Development Prototype”.  Any changes identified may require the Implementation Paper to be amended following Issue Control and/or Change Control procedures

It is often most efficient to run this process in parallel with the corresponding documentation tasks and tasks to prepare for testing and training.

PATH PLANNING GUIDANCE

Normal Practice

Where appropriate, this process can be subdivided in the segment plan into processes numbered 70x.  This may be used to define separate tasks per major aspect of functionality or part of the system.  Detailed task lists will normally identify all the elements to be entered.

DEPENDENCIES

Prerequisites (Finish-Start):

• corresponding Implementation Paper defining this area (see Process 400 - Design / Prototype)

Prerequisites (Finish-Finish):

• normally, user documentation for this topic should be prepared at the same time (and should be ready for the subsequent formal testing)

Dependent procedures (Finish-Start):

• integration testing of this aspect of the solution

RECEIVABLES

• Implementation Paper defining this area (see Process 400 - Design / Prototype)

DELIVERABLES

• working, documented functionality ready for formal testing

TOOLS

• various package specific materials, toolkits etc
• Application Software Configuration Guides
• Application Software Implementation & Management Guide (IMG)

DETAILED DESCRIPTION OF TASKS

About Parameters

In order for their software to meet the needs of a wide range of organisations, vendors design their applications with a variety of operating options that are configured through software tables and logic parameters.  These options must be correctly configured to the client’s unique operating needs before the software will meet their requirements.  These software parameters are often interrelated, where the functionality provided by one parameter is altered by setting a different parameter.  It is also common for the descriptions for each parameter option, as found in the vendor documentation, to be nebulous or misleading.

It is important to understand system parameters and how they will affect the system before configuring them.  It is also important that the parameter settings are tested to validate that what it was assumed the system would do once configured would actually happen.

Hints:

• Logic tables and parameters are often interdependent.  It is important to understand how the application will use these codes and how they interrelate with other system codes before the values are established.
• Printed layouts of the tables and parameters can be used as worksheets to draft values prior to entry.
• Parameters can often be documented by “cut and paste”, ie the text of the parameter screen is copied directly into the word processor.

The initial investigation and testing of significant parameters will have been performed in Process D400 - Design / Prototype.  During the D700 - Parameterisation process it may be necessary to investigate detailed parameters further, particularly where minor aspects have not been considered in detail in the Implementation  Papers.

The Implementation Paper

An Implementation Paper (or Brief Implementation Paper) defining the required work should have been developed, reviewed and signed off.  This paper will have considered design decisions and no significant aspect of the design should be outstanding.

Setting the parameters

In most cases, the Design / Prototype work performed in the preparation of the Implementation Paper will have included a design prototype of the full final solution.  This can often be used directly to generate the final version of the parameterisation, either by direct transfer or by copying some or all of the prototype solution, preferably using “cut and paste” techniques.

Where the design prototype included only a subset of the full solution, the full tables will now be constructed.  For example, a validation table may have been prototyped with only a few entries but may need several thousand.  Distinguish, however, the case where master file data is to be captured - this is normally handled in  data conversion tasks.  Sometimes the distinction is hard to make, the key difference being the formal testing and approval of items which are considered to be parameters rather than data.

Good housekeeping

Care should be taken to preserve the parameters against accidental loss, corruption or overwriting.  It may be appropriate to use similar approaches to those used to maintain the source of custom programs.  Keeping an electronic (and/or paper) copy of the settings and tables may prove worthwhile.

Some packages include facilities to control and document changes.  For example, with an Application Software system when changes have been made the Status Note of the IMG must be maintained along with cutting and pasting the new or revised values into the Implementation paper.  Along with this copy must be an explanation of why the values have been changed and the date  and who made theses modifications.

Note a particular problem concerning parameters.  It is often hard to distinguish between fixed parameters (eg organisation’s name), changing control parameters (eg current processing period and date), static but changeable table data, (eg validation table for expense codes), fixed but modifiable customisation parameters (eg screen layouts), master file data (eg name and address file) and transaction data.  This is often both a conceptual problem and a practical one.  Many packages do not make a clear distinction and do not allow the partial restoration of the database (which may include parameters and data) without losing overall coherence and integrity of the database.  Thus it may be impossible to restore data without reverting to the older version of the parameters.  It may also be difficult to transfer subsets of the full parameters, for example from the development system to the test system, and/or training system and/or live system.

Thought should be put into the strategy for backing up and restoring such data.  Fixed data and tables may be required in their latest condition, whereas changing control parameters, and transactions may need to be restored to a given point in time.  It is useful to get this policy right during Development Prototyping since it can be of great value in prototyping or testing the system if tests can be repeated on the same data but with amended parameters.  Needless to say, such procedures will also be required in due course for the proper running and management of the live system.

Documentation and associated tasks

Several aspects of the overall work can often be performed most efficiently if they are done at the same time.  The user documentation of the topic can be prepared at the same time, capturing parameter settings from the system using printouts or by “cut and paste”.

Materials can also be prepared for the formal testing, in particular the definition of the intended processing rules to be tested.  It may also be valuable to extract training materials at this time.

These tasks are handled in other processes, but can be scheduled in parallel with the parameterisation.

Informal testing / Development Prototyping

Formal testing is considered in Process D800.  Before reaching that formal proof of functionality, it may be appropriate to test the setup informally, that is without review and sign off from the responsible user management.  This form of informal testing can be referred to as “Development Prototyping”, as opposed to the “Design Prototyping” performed in Process D400.  Note, however, that any changes to items agreed in the Implementation Paper would need to be logged and controlled through the Issues Control process (if the paper is not yet frozen) or the Change Control process.

It is easy for parts of the system’s setup to be affected by changes made elsewhere.  As parameters are set or changed, care should be taken to ensure that the effect is understood, communicated to other team members where appropriate, and that unforeseen effects are looked for and dealt with.  It can be a particular problem if design prototyping is taking place in the same environment and at the same time as development prototyping, since the designers will wish to feel free to try out any system settings.  If this is the case, particular care should be taken to control the usage of the parameters and to ensure that developed aspects are not undone by prototyping designers.  (Ideally, the design work would use a discrete technical environment or otherwise be logically separated from the development system.)

Ideally, all major problems will have been uncovered by the design prototyping in Process D400, and the development prototyping in this process.  This should lead to an easy passage through the formal stages of testing.