Project Delivery Process D710

D710 - Screens, queries and reports

DEFINITION

Set up the customisable screen layouts, enquiry facilities, and reports.

SUMMARY

Screen layouts, enquiry facilities, and reports should be set up in accordance with the corresponding 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 use and content of these facilities prior to formal testing.  This technique is known as a “Development Prototype”.  Any significant changes identified may require the Implementation Paper to be amended following Issue Control and/or Change Control procedures.  It is, however, unusual (and probably unhelpful) for the Implementation Paper to specify absolutely precise layouts rather than to describe the overall need.

This process is very similar to D700 - Parameterisation.  The key difference here is that the facilities and layouts to be set up do not affect the fundamental structure of the system - they are reporting or data entry tools which do not significantly change the way the basic system functions.  As such, they tend to be of lower priority.  They are also areas in which it is possible to be more flexible in allowing users and management to see previews using the “Development Prototype” and to make changes to the layout or generate new formats.

It is often most efficient to run this process in parallel with the corresponding documentation tasks and tasks to prepare for testing and training.  In particular, the screen and report layouts tried at this time may be suitable for inclusion in user’s manuals and training materials.

PATH PLANNING GUIDANCE

Optional - as required

Where appropriate, this process can be subdivided in the segment plan into processes numbered D71x.  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 D400 - 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 D400 - Design / Prototype)
• optionally - Implementation Paper(s) defining standards to be used in report and screen layouts and in the user interface

DELIVERABLES

• working, documented functionality ready for formal testing

TOOLS

• various package specific materials
• Example:  Data Element Description
• Example:  Screen Layout
• Example:  Screen Fields Worksheet
• Example:  Report Layout
• Example:  Report Fields Worksheet
• Example:  Source Document Layout
• Example:  Source Document Fields Worksheet

DETAILED DESCRIPTION OF TASKS

About screens, queries and layouts

Most packages include facilities to set up or modify screen layouts, query facilities and reports; many packages have more than one method available.  Not all packages supply a good set of standard facilities - they use the argument that they provide a flexible, user-friendly report writer, query generator, screen painter, etc, and so do not need to supply a library of standard facilities.  It is common, therefore to undertake this form of customisation.

The techniques used will vary from package to package, and based upon the project’s needs and chosen approach (as defined in the relevant Implementation Papers).  Some packages perform the customisation as an integral part of the parameterisation, whereas some would use external report writers or query tools.  The use of external tools is particularly common where the package is based around an industry-standard relational database.  There are often further options available to “download” data from the package such that it can be examined or reported upon within a totally separate system such as a PC spreadsheet.

If the customisation requires custom programming techniques, then care should be taken to ensure that the work is properly conducted and cannot impact upon the basic functioning of the package.  Where customisation would (or could) affect the basic package, custom development techniques should be used, rather than this process (see Processes D600 and D650).

The team should check that the approach taken has no adverse effect on the contract with the vendor or the level of support that they will receive.  In general, the vendor will not directly support the users’ customised versions of the screens and reports, but they will support the underlying basic versions as supplied and the in-built customisation facilities.  For this reason, it may be better to copy and rename a screen or report before applying modifications, so that the original version can be used if there is any doubt about the cause of subsequent problems.

The initial investigation and testing of significant parameters will have been performed in Process D400 - Design / Prototype.  During the D710 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.  Papers may also have considered and agreed overall design standards to be used for layouts, user interfaces etc.  These papers will have considered design decisions and no significant aspect of the design should be outstanding.  It is, however, unusual (and probably unnecessary) for the Implementation Paper to specify absolutely precise layouts rather than to describe the overall need.

Setting the parameters

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

Usually there will be more work required to generate the full set of required screens, reports and queries.  These should include all standard facilities which it is planned to release to the users.  Many packages allow end users to generate their own reports or queries.  Where this is to be allowed, it is normal to set up (and test) examples of typical uses of the facilities.

Hints:

• Parameters can often be documented by “cut and paste”, ie the text of the parameter screen is copied directly into the word processor.
• Cutout layouts of blank screens and reports can be used as worksheets to draft layouts electronically using a word processor.
• Copying and then modifying an existing report is usually easier than starting from scratch.
  Errors in reports are often missed - particularly where not all the intended data is extracted and summarised.  Careful consideration should be given to test data and expected results to check the results are right.  This may often be easier if the test database used for this purpose does not allow changes from other areas of the project’s testing.

Good housekeeping

Care should be taken to preserve the set up details and 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 specific concerns about the partial restoration of parameters are considered in Process D700 - Parameterisation.  These can also apply to reports, screen layouts and query facilities, but their impact tends to be less severe.

The modifications may be lost if a new version of the basic system is subsequently installed.  It is particularly valuable to:

• make changes to a renamed copy of the original screen or report so that the user organisation’s version is not overwritten by new releases,
• retain the paper copies of the revised design and how the customisations were performed,
• retain the actual parameters and settings in an electronic form for re-application if necessary.

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 layouts and examples from the Development Prototype by “cut and paste”.

Materials can also be prepared for the formal testing, in particular the definition of the expected results from reporting functions.  The definition of a fixed database for reporting tests may be useful so that the expected results are fixed and are not affected by other aspects of the overall testing.  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

Errors in reports and queries are often missed - particularly where not all the intended data is extracted and summarised.  Careful consideration should be given to test data and expected results to check the results are right.

There is also an issue concerning the testing of user-driven ad-hoc reporting facilities.  If it is agreed that such facilities should be made available, then project team will have little influence over what future uses will made of them and the amount of care which the generator of the report or query will put into validating the results.  It may be possible to set the facilities up such that only “sensible” questions can be asked, or the project team may set up a library of tested examples.  If so, the packaging of this should also be tried out and tested.

A caveat regarding user-defined reports and queries

There are several issues regarding user-defined reports.  Generally, free access to information is a good thing and most systems provide extensive facilities for interrogation.

It is, however, dangerous to allow users free access to report  and query definition facilities (as opposed to using standard definitions with their own required parameters).  The risks should be balanced against the potential benefits.  The two main risks are:

• impact on the computer resources (response times, disk space, paper, printing time) of asking a question inefficiently,
• risk of wrongly defining the question so that the data reported is not what the user believes it to be (eg cost centre expenditure which misses out transferred items, or a customer list containing “deleted” entries).

The potential usage of such facilities should be considered and, if appropriate, tried out, prototyped and tested by the project team.  It may be appropriate to publish guidelines for the users based on this investigation.