Manual for the Design and Implementation of Recordkeeping Systems (dirks)
| Вид материала | Документы |
- Design and installation of pipelines for heating systems usingpipes, 616.28kb.
- Design and installation of pipelines for heating systems usingpipes, 608.87kb.
- 1 Примеры программ ecad, 243.4kb.
- Audi Group Design Center. Уникальный проект audi ag и Audi Russia, направленный, 105.22kb.
- Тематика лекций по дисциплине «Механика грунтов, основания и фундаменты», 8.01kb.
- Web-дизайн Понятие веб-дизайна, 215.6kb.
- Web дизайн включает в себя визуальный дизайн (вообще), дизайн представления информации, 1039.6kb.
- Assessing Implementation of the eecca environmental Partnership Strategy – a baseline, 147.38kb.
- Государственный стандарт союза СССР информационная технология Комплекс стандартов, 428.01kb.
- Experience of tqm principles and iso 9000 implementation in the Pridneprovsky region, 67.13kb.
Conduct regular design reviews
Remember that it is important to involve system users in the process of the design or redesign of your technical components. Liaise with users about aspects of the design that affect them through both formal and informal means, and use this as a mechanism for obtaining useful feedback. Do not forget to have formal design reviews at critical stages in the design process, such as the completion of the design of a major system component.
Design reviews help to maintain links between the requirements you are aware of or articulated in Step C of your analysis, and the design activities you are now undertaking. These reviews will highlight requirements that have:
- not been properly addressed
- changed, or
- become infeasible due to other changes or new constraints.
Design reviews often result in requests for changes to requirements and/or to parts of the design itself. For this reason, it is essential to document the outcomes of the review. It is also vital that you maintain a visible documentary trail from the requests for change to resulting changes in requirements or design. Requested changes which are not implemented, or which are implemented only partially, must also be documented.
| ^ Tip: Remember to separate development and operational facilities According to ISO 17799, the International code of practice for information security management, it is important to ensure that design and testing operations for significant system redevelopment are separated from your operational environment. In clause 8.1.5, the standard states that the following controls should be in place: a) development and operational software should, where possible, run on different computer processors, or in different domains or directories b) development and testing activities should be separated as far as possible c) compilers, editors and other system utilities should not be accessible from operational systems when not required d) different log-on procedures should be used for operational and test systems, to reduce the risk of error. Users should be encouraged to use different passwords for these systems, and menus should display appropriate identification messages e) development staff should only have access to operational passwords where controls are in place for issuing passwords for the support of operational systems. Controls should ensure that such passwords are changed after use. The standard also states that 'rules for the transfer of software from development to operational status should be defined and documented.' |
Develop a migration and/or conversion strategy
If, at the end of your work in applying the design and standards tactics, you have developed new systems or redeveloped old ones, you may need to develop record migration and conversion strategies to ensure records are carried forward from old frameworks into new ones. You plan for and undertake these activities in Step F, Design of recordkeeping systems.
Migration is the 'act of moving records from one system to another, while maintaining the records' authenticity, integrity, reliability and usability'. [6]
Conversion is the 'process of changing records from one medium to another or from one format to another'. [7]
| ^ Example: When migration is needed You would need to undertake migration activities if:
|
| Example: When conversion is needed You would need to undertake conversion activities if:
|
Both migration and conversion activities need to be conducted carefully and need to be tested and well documented. See ARMS' guideline: Ensuring the accessibility of equipment/technology dependent records. This document contains a range of clear guidelines to help ensure you conduct conversion and migration activities in an accountable and efficient manner.
^
Documenting technical design
In most design projects documentation is an ongoing and prolific activity. System design documentation is developed progressively at different stages (or 'milestones') in the design process. In addition to the policies and procedures you may develop, each design solution generated by the project team or tendered by an external party should incorporate extensive design documentation, including:
- design diaries, detailing original design decisions and rationale, and documenting changes made to the design over time
- introductory, non-technical design descriptions which can be understood by senior management, staff and other stakeholders
- descriptions of redesigned or newly designed business processes
- logical and physical models of different aspects of the system
- metadata specifications
- structured, precise hardware and software design specification(s), aimed at computer system developers and vendors
- initial testing plans
- initial training plans, and
- skeletal system implementation plan.