[Acceptance] [Adages] [Analysis] [Architecture] [Attitudes] [Audit] [Availability and ARM]
NOT YET AVAILABLE
Acceptance is a formal process of demonstrating and agreeing that obligations (usually contractual) have been met. Where the contract is for the production of a system these obligations will generally relate to demonstrating that the requirements for the system have been met.
Failure to adequately specify acceptance criteria lead to the customer being having different expectations when the product is offered up for acceptance. Leading to the product not being accepted, or costly changes being made after initial production.
The document on acceptance explicitly deals with the following topics:
IntroductionAdages are short sayings that contain some gem of truth about a subject. Their primary benefit derives from the fact that they are short, focus on a single idea, are often humorous, and as a consequence are easily remembered,
There is a vast amount of information and potential advice that might be relevant in any given situation. Much of it is complex. It is impossible to keep very much of it readily at our fingertips. Adages however do provide easily remembered rough and ready rules which we can apply if we think them appropriate.
This document gives a number of adages under the topic headings:
This chapter describes a number of well known analysis techniques. The checklist on when to use particular analysis techniques, given towards the end of the chapter, provides links to the specific techniques appropriate to addressing particular questions. Some of the links are to techniques described elsewhere in the Handbook.
Introduction
Tally Charts / Check Sheets
Histograms
Scatter Diagrams
N2 Charts and Interaction Matrices.
Stratification
Cause and Effect Analysis
Influence Diagrams/System Dynamics
Brainstorming
Nominal Group Technique (NGT)
Delphi Method
The five Whys?
Force Field Analysis
Control Charts
Affinity Diagram
Interrelationship diagram
Tree diagram
Matrix diagram or quality table
Process decision programme chart
Arrow diagram
Checklist on when to use particular analysis techniques
Miscellaneous Notes on the use of analysis
techniques
The term System Architecture is used to refer to a high level view of the System Design in terms of the system's major partitioned units (ie. subsystems/equipments) and their principal interconnections. An architectural description tends to use general terminology which allows it to be compared with other similar systems. We can thus talk about a system having a similar architecture to some other system, or might talk about it having a new architecture with respect to some particular part of it.
This chapter provides some details of precisely what is meant by 'System Architecture, gives guidance on developing a good system architecture, and identifies some of the issues which are often common in developing an architecture. Cross reference is given to SYSTEM PARTIONING where the considerations relating to determination of a system architecture are discussed in more detail.
Introduction
Examples of Common Generic Architectures
System Architecture Description
A good Architecture
Some common architectural design issues
Audits are an important part of any project, and are an independent check of a process or product to ensure it is being carried out according to agreed standards and/or guidelines. Audits are mostly about checking to see if what people say they are doing, eg. in their procedures and plans, is in fact what they are doing.
Introduction
Purposes of Audits
Differences between Audits and Reviews
Audit Techniques
First-, Second-, and Third-, Party Assessments
Steps in an audit activity
Audit Reports
Common areas covered by audits
Notes on Use of External Auditors
The Internal Audit Group
Internal Audit
Auditor Approach and Personality
Some Practical Issues associated with Auditing
Availability is a measure of whether or not something is in a state to be used when called upon to be so. Where the term is used care must be taken to ensure a common understanding since there are different ways in which it can be defined. In terms of a system design the concept of availability is a useful way of trading off aspects of the systems Reliability with that of its Maintainability.
Introduction
Alternative Definitions of Availability
ARM Modeling
Some general notes pertaining to Availability