Manual for the Design and Implementation of Recordkeeping Systems (dirks)

Вид материала

Содержание

Steps involved in technical design
Determine whether to buy, build or both
Conduct logical system design
Tip: Build good interfaces
Example: Metadata redesign
Conduct physical system design
Implementation of a recordkeeping system
Example: What if the system I have developed is too large?
Develop technical application testing plan

Подобный материал:

1 ... 43 44 45 46 47 48 49 50 ... 71

Steps involved in technical design

It is not the purpose of this step to describe in detail the different modelling tools used in computer system design. The following outline simply provides a brief introduction to the process and focuses on:

determining whether to buy or build
conducting logical systems design
conducting physical systems design, and
developing a systems testing plan.

Tip: Do not do the work, but advise on your requirements

If you are a recordkeeping professional, you do not need to undertake these technical design processes yourself. You should, however, be aware of what they involve and be prepared to advise IT staff on your requirements in relation to them.

Determine whether to buy, build or both

When it comes to designing or redesigning the technical components of your system, it is necessary to determine whether:

existing in-house technology can be utilized
additional technology should be bought and/or tailored, and
additional technology should be designed and by whom.

The recordkeeping requirements that you articulated in Step C, the recordkeeping gaps identified in Step D and the overall design strategies determined in Step E will indicate the complexity and scope of the technological components that you need.

Factors likely to influence the decisions you make about the technical components include in your decision to adapt, acquire or design include:

cost of the proposed strategy
the flexibility or lack of flexibility it contributes
the speed and/or ease of integration with existing technical and other system components, and
availability of staff or contractors to perform design work.

Conduct logical system design

Logical design pertains to the 'what and when' of a system, that is, its functions and processes. It focuses on what the system should do, and how it should appear to the users. Logical design involves the use of various conventions and modelling tools to translate the requirements identified and documented in steps C and E into detailed technical specifications for system inputs, outputs, interfaces and data stores.

Logical design includes the design of:

forms and templates, such as metadata templates, which enable the presentation and collection of information
user interfaces, such as menus and dialogue boxes, which enable users to interact with a system, and
data stores, such as databases, which enable data or information objects to be stored in a structured way.

During the logical design of an electronic system, users need to be actively involved in reviewing the design to verify that the system is usable and continues to meet requirements as it evolves.

^ Tip: Build good interfaces

Do not forget the importance of good user interface design. A good design will encourage and facilitate people's use of the system and is important to the success of the system you are designing.

^ Example: Metadata redesign

If, in the course of your Step D: Assessment of existing systems analysis you noted that your business system is not specifying adequate metadata, and you opted for the design strategy in Step E: Identification of strategies for recordkeeping, you should incorporate metadata redesign into your Step F work.

Consider the types of metadata required to meet your recordkeeping requirements and build these into your system design. Consider means by which metadata capture can be simplified through such means as automatic metadata attribution, metadata inheritance etc.

Consider how record classification can assist with metadata attribution. Can certain metadata elements - such as disposal, access, preservation, function etc - be applied to aggregates of records that have been similarly classified, to save you or your users from having to attribute metadata to each individual record? The business classification scheme you developed in Step B will help you to simplify your metadata management in this way.

Consider too, how you want staff to apply metadata. Do you want to include a lot of guidance in the system to help staff choose appropriate metadata? Do you want to build thesauri or other tools into the system, or a range of default values, to limit user choices and control the type of data that is input into the system? Choosing to follow this approach can be labor intensive in the design phase, but can help to reduce mistakes and the amounts of invalid data that is input into the system.

Metadata can be used in many different ways to help you meet your recordkeeping and other business objectives, so consider how you can make this happen during the course of your Step F deliberations.

You may also want to examine the ARMS Standard on Recordkeeping Metadata for additional guidance in this area.

Conduct physical system design

Physical design deals with the 'how and where' of a system. It involves specifying the technological characteristics of the system, including:

overall system structure
system integration
software program structures
hardware configuration, and
data (information) processing, storage, access and protection.

Tip: Use open systems and technical standards where possible

In their physical system design, it is strongly recommended that you specify and adopt open systems architecture and non-proprietary information technology standards to manage electronic records required for long-term access.

Note that system integration can include:

integration with existing electronic systems or applications (for example, an organization's legacy system, current electronic document management system or suite of document authoring applications), and
integration of specific recordkeeping tools (such as thesauri, retention and disposal schedules, or metadata creation tools) to enhance the recordkeeping functionality of the system.

A system integration plan should be compiled for use during implementation phase (Step G: ^ Implementation of a recordkeeping system). This plan is similar in concept and structure to the system implementation plan, but it relates only to the technological components of the system.

Decisions made earlier about whether to buy, build or combine both approaches will impact on the physical design of the system. In one sense, the decisions made at that time really constitute a part of the physical design. Inevitably, the choice of particular technologies will place constraints on the functional capabilities of system being designed.

It is possible that problems or errors will occur during physical design that can be traced back to the logical design stage. This may reflect inconsistencies in the requirements. Even at this late stage, you need to continue consulting with users, gathering additional information and, where necessary, making and documenting changes to the requirements and/or the system design.

As the final design activity before system implementation, physical design provides the last opportunity to ensure that the system design is consistent, complete, and meets the requirements. Changes to design after this time will prove both costly and time-consuming. It is therefore strongly recommended that system auditors and security specialists contribute to this activity.

^ Example: What if the system I have developed is too large?

You have developed a technical component for your system that meets all identified recordkeeping requirements. Unfortunately, however, it is too big. Storage costs are getting cheaper in the electronic environment, but infrastructure required to support systems is getting more expensive. Therefore your solution may be too costly for your department/section to implement or may require too much network space than can be allocated.

If you find yourself in this position you can:

negotiate with management and IT - demonstrate how your project is trying to provide solutions for key issues and the extra cost required to complete the project is therefore justified
use risk management techniques as a means of scaling back your solution - have you built in functionality that addresses only medium level concerns? Can some functionality that deals with such matters be removed as a means of decreasing system size? Is the system scalable - can the desired functionality be incorporated in full later when greater system capacity may be possible?
utilize other Step E tactics - if your full design plans are just not feasible, can you use policy or implementation tactics to meet your recordkeeping requirements? Will a combination of rules and training lead to the same outcome?

Develop technical application testing plan

One final activity in the design of the technical components of your system is to develop an overall testing plan. This plan is a sub-element of the testing processes referred to in Step G.

The system testing plan details the different kinds of testing which need to be carried out during implementation of the system, and specifies what form(s) the testing should take. Testing of electronic systems involves using test data and scenarios to verify that each component, and the system as a whole, works as intended under both normal and unusual circumstances. Working 'as intended' means meeting requirements as documented in the requirements specification.

Some examples of what needs to be tested during the implementation of an electronic recordkeeping system, or during the incorporation of recordkeeping functionality into an existing system, include:

system functionality (does the system do what it is required to do?)
system integration (how well do the different components work together?)
user interfaces (are menus, forms and templates understandable and usable?)
validation of inputs and outputs (does the system produce or allow the entry of erroneous data?), and
system response and recovery times (how quickly does the system perform tasks and how long does it take to recover from crashes or interrupts?).

As discussed above, system operating procedures will also need to undergo testing to ensure correctness, usability and understandability.

Tip: Competing priorities may affect timetables

Remember DIRKS projects, particularly if they involve technical design components, are very reliant on the efforts of a range of people across your department/section. These people will have a range of other demands on their time, and so making long-term commitments to achieving your DIRKS requirements may be difficult. Be prepared for compromises and delays that may be unavoidable due to competing priorities amongst your DIRKS team members.