Project Delivery Process D602
Blog: Biz-Performance, David Brown
D602 – Finalise interface design
DEFINITION
SUMMARY
-
specify the function and processing characteristics of an interface to another application (either internal or external),
-
define the physical media and data content format,
-
document responsibility and operating procedures governing the interface.
-
identify and resolve remaining issues regarding the function or operation of the interface,
-
provide technical and functional information needed by programmers to develop software implementing the interface.
PATH PLANNING GUIDANCE
DEPENDENCIES
-
Integration & Interface Review (R110)
-
Consider, review and plan approach to integration (D160)
-
Instigate non-Application Software Implementation parallel tasks (D650) – where programming work will be outside the scope of the project team
-
Modify existing non application software (D656) – for components of the work not using Application Software facilities
-
Modify package software (D658) – for components of the work using Application Software facilities
-
Build of corresponding programs / modules etc
RECEIVABLES
-
Definition of Requirements (DoR)
-
Delivery Approach Definition (DAD) or similar definition of conceptual design
-
Integration Issues IP
-
documentation for the other application(s) involved
-
site standards and procedures
-
physical data model
DELIVERABLES
-
Interface Design – Technical Implementation Paper per interface
TOOLS
-
Application Development Standards – Coding Standards
-
Application Development Standards – Naming Standards
-
Application Development Standards – File Definition Standards
-
Skeleton Implementation Paper
-
Guidelines: “Modelling Techniques”
-
Guidelines: “Custom Development”
-
IP Guidelines: “IP-Data Conversion”
-
IP Guidelines: “IP-Database”
-
IP Guidelines: “IP-Languages”
-
IP Guidelines: “IP-Handover”
-
IP Guidelines: “SIIPS 2 Feeder systems”
-
Examples: “Interfaces and output files worksheet”
-
Examples: “Conversion Worksheet”
-
Examples: “Contingency Plan”
-
Guidelines: “SAP development workbench” (to be written)
DETAILED DESCRIPTION OF TASKS
Requirements
Options
-
custom built programs
-
use of package facilities
-
use of interfacing tools
-
use of manual re-entry.
Recommendation
Finalise Interface Design
-
batch input processing (BDC), in which case sequential datasets would be read into transactions and dynpros or written to an external file,
-
CPI-C or RFC
-
PC upload or download,
-
Application Link Enabling (ALE),
-
hard coded writing into the database
-
the data fields to be interfaced, their source, format, and medium,
-
any conversion or translation routines (eg rules for summarising accounts or translation of customer ID codes)
-
volume and periodicity of the interface,
-
the destination of the data and any plausibility checks to be performed,
-
how to handle error situations if the interface fails,
-
control routines to be performed to ensure that all data has been transported correctly into the destination system,
-
the processing rules for the interface.
-
Module Name and Reference ID
-
Business Process Reference ID
-
Other application systems affected
-
Type (database, transaction, batch file, etc.)
-
Device (file, program-program, POS, etc.)
-
Source
-
Purpose
-
Frequency
-
Data elements
-
Grouping (sort sequence)
-
Control report format and content
-
Record
The Technical Implementation Paper
-
to assist key management and team members to understand and agree upon the business requirements for the topic,
-
to explore all options to address the business requirement (including procedural, process redesign, non-automated solutions),
-
to indicate the preferred solution and to identify why that recommendation is being made such that key management and team members will understand and accept the recommendation,
-
to define how the recommendation will be implemented in sufficient detail that no further design decisions will need to be taken (ie no further consultation, agreement or sign off is required),
-
to highlight any unresolved issues which may affect the various details, recommendations and decisions presented in the paper – such outstanding issues should normally be resolved before the paper is finalised.
-
Detailed requirements should still address business needs, but are more likely to contain technical information where the technical detail is a genuine requirement, for example the precise data format required for an automated input to a package. Accordingly, it is normal to see a wider range of techniques used to record such needs and some very detailed low-level information. For example, technical papers often contain:
-
data dictionary entries, record layouts, data models, database definitions etc
-
system specification documentation for other systems involved
-
details of any special techniques or approaches required to exploit the coherence of the overall technical solution, eg using the package’s built-in database, data dictionary or 4GL tools
-
detailed translation tables to convert from old data to new
-
validation rules and tables
-
details of timing, size, performance requirements
-
backup, recovery
-
details of standard automated controls and standard clerical procedures required to control the programming suites.
-
Options will vary considerably and normally include full automation and full manual treatment of the requirements.
-
Full systems integration is increasingly becoming a user demand, and the techniques to achieve it are constantly improving. This evolution tends to add greatly to the complexity of the most-functional options. Full integration cannot normally be achieved unless it was planned and designed into all the systems involved. Very often, the Implementation Paper will need to convince the management that full integration is too costly in terms of time, effort and money.
-
The option may sometimes include whether to accept the package’s functionality or whether to undertake modifications to the package itself.
-
Options may include options as to who does the work, eg should it be subcontracted out to the vendor.
-
Given that custom programming can often be expensive, time consuming and high-risk, very serious consideration must be given to evaluating the options and forming a recommendation.
-
The options frequently cross system and organisational boundaries and imply work on other computer systems affecting other IT teams and user departments – these issues must be included in the considerations, particularly any lead time or availability constraints.
-
Existing computer systems are often badly understood and poorly documented. Substantial work may be necessary to evaluate work required unless there is an effective existing system maintenance function covering the area. Always check the facts carefully.
-
The detailed instructions will often be very technical in nature. They should give enough detail so that further research and agreement is not necessary.
-
Large tables of facts may be best presented as appendices, eg validation tables, conversion tables, record layouts etc
It is not necessary to provide a full detailed program design specification as this should be defined as part of the non-Application Software work, performed in accordance with the agreed approach to custom development. The program designer would normally take the Technical Implementation Paper as the statement of user requirements.
Leave a Comment
You must be logged in to post a comment.