NOT YET AVAILABLE

[Press for File]

Safety is primarily concerned with the extent to which people may be put in danger of injury or death by a system, though in some ways it is also concerned with the system itself.

In particular, safety is concerned with:

• The need to avoid injury to the people who use or maintain the system.
• The need to avoid injury to other people who might otherwise be inadvertently harmed by the system.
• The need to avoid the system itself being damaged.
• The need to avoid damaging other systems with which the given system interfaces or interacts.

Safety is concerned with the full life-cycle, including manufacture, test, use and support, and must recognise potential degradations during the life of the system, and also potential mis-use of the system.

There is often a statistical nature to safety since it is not possible to provide complete guaranteed protection, but only to provide a reasonable level of protection at an acceptable cost.

1. Legal security, such as government security classifications.
2. Commercial security, such as company Confidentiality, or customer required confidentiality.

Security is an issue with respect to:

1. The project itself in terms of its using and generating information which has security classifications
2. The project in terms of its needing to keep its information safe irrespective of its security classification.
3. The systems being derived by the project may themselves be used in or become secure environments, and therefore they need to be designed to meet security related requirements.

It is important that these different aspects of security are not confused, and that responsibilities for each of the above areas are clearly allocated. Thus a project or site security officer will generally be responsible for (a), project management will be responsible for (b) (with the IT manager being responsible for computer related information), and a security specialist working as part of the project team responsible for (c).

The primary topics discussed are:

• Time Management: ie. using your time effectively.
• Personal Information Management, ie. managing infomation.
• Self Management Systems, including in particular the 'Portfolio', ie. computer and paper based systems to support self management .

Also discussed are certain aspects of memory and stress.

The benefits of good self management should not be underestimated. Not only will they help you be more effective in your work, but the techniques will also be valuable in your home life. They will help reduce stress, and generally put you more in control of your life. Your life will be more satisfying as a result.

Proformas (and Usage Notes):  

Generic Activity/Action List
Delegation List
Contact List
Generated Documentation
Documentation Received
Documentation of Interest

The term can apply to:

1. A given item which is made operational so some particular activity can be carried out on it, such as to perform a test.
2. To an item as the final phase in bringing it up to an operational state such that operators can use it. A system may be expected to only go through a single Setting to Work activity in its life, such as Nuclear Power Station, or it may go through many Setting to Work activities, such as an aircraft before use.

Depending upon how a given project uses terms, Setting to Work can be seen as a subset of INSTALLATION.

NOT YET AVAILABLE

[Press for File]

This chapter is not intended to fully cover software developments. This is a large topic and there are many specialist books on this topic.

It does however give an overview of software developments, treating it as a specialist engineering discipline. It provides sufficient background to allow systems engineers and those involved in project management to integrate software design into general systems design.

It should be noted that there is no widely accepted definition of what is and what isn't 'specialist engineering'. And moreover what is and isn't considered as such changes over time. However it is a useful concept used extensively in this Handbook, and is a concept that helps in the wider understanding of systems engineering and how to manage system projects.

This chapter identifies the different types of specification typically used to manage and describe the design of a system, and gives some guidelines on the management of the specifications themselves.

Introduction

Types of Specification relevant to System Projects
Particular types of specification
Specification Trees
Characteristics Required of a Specification
Example contents of a System/Sub-System Design Specification
Impact of IT on specifications and use of specifications

1. Be against the system project, having for example vested interests in the world without the new system, or with an alternative system, or other uses of resources which might be applied to the project.

2. Be in favour of a particular form of the system project, or in certain of its characteristics. For example they may favour particular firms as suppliers of the system or components of it.

A stakeholder is anybody who has an interest in the outcome of a process or solution or who may have an influence on it. Understanding who the stakeholders are and acting on this understanding is an important part of managing system projects.

• A standard might define the use of given terminology, such as definitions of units, or of the use of given graphical symbols for a given purpose. Thus whenever the terminology is used it is used in the same way by all those who use it.

• A standard might define a given process, for example detailing a set of activities which might be undertaken for a given purpose. The standard is thus intended to incorporate best practice and lessons learnt with respect to undertaking the process.

• A standard might define the characteristics of a given material or component part, and thus whoever produces the material or part know what characteristics it must have, and whoever uses the material or part know what its characteristics are.

Standards may exist internationally, nationally, within a given industry, within a given organisation, or anywhere there is a group of interested parties. Applied appropratiately they are enormously valuable, and underlie much of the mass production that underlies modern society. They can also be a hindrance however where not applied properly, either through the application of inappropriate standards, or through the application of standards which have not been kept up to date.

Ensuring the balanced application of standards to a systems project is none trivial, and failure to get it right makes a product more costly to develop, manufacture, and support than it might otherwise have been. Erring on the side of avoiding use of standards can mean a lot of relearning of lessons previously learnt and embodied in standards; erring on the side of using standards which might not be completely appropriate can mean a stifling of innovation and monies spent on features which are not relevant. Too often system projects pay inadequate attention to the different types and uses of standards, and to truely understanding their context, history, and thus appropriateness to a given project.

NOT YET AVAILABLE

[Press for File]

An understanding of statistics is important to the system engineer/manager for two reasons:

1. One of the most important characteristics of complex systems is uncertainty. Given uncertainty, we do not give up, we find ways of working with what we know and finding ways of characterising the uncertainty. Statistics is the language of characterising uncertainty.
2. Many of the specialists who support the system engineer/manager will use statistics. Without some understanding of it the system engineer/manager will not be able to talk the same language as the specialist, or to recognise weaknesses in the statistical approach adopted by others.

It is unfortunate that so many people immediately switch off at any mention of statistics. They believe it is some complex theoretical subject which they couldn't master if they tried. However the statistics that most people require is in fact very simple, and covers only half a dozen concepts. An ability to work with these concepts will greatly enhance one's ability to understand some of the subtleties of system engineering/management.

A method can be defined as a structure design method if it involves the use of defined symbols/notations, precise rules for relationships between symbolic/notational elements, and procedures for how the notations should be used to derive a design definition.

It is not an a priori truth that structured design methods should or shouldn't be used in support of system projects. Some projects would benefit, for others it would be a waste of money and a distraction. Structured Design methods have grown out of software design. In truth they are still largely most appropriate for software designs, and as discussed in this chapter are very weak at capturing many of the concerns associated with system design in general. Note however that the use of structured design methods is not necessarily an all or nothing approach, and the methods could be applied to a part of a system, or to a particular aspect of a system.

The application of structure design methods for any complex project requires computer based tool support, and the effectiveness with which the method can be applied is largely dictated by the characteristics and quality of the computer based tool itself.

Sub-contracting is a major element of most system projects. It is one of a number of different types of Procurement activity, namely one in which the sub-contractor is making a contribution over and above simply providing a standard product or service.

This chapter gives some basic background as to what is meant by a sub-contract and what the major issues of concern are. Much of the detail given elsewhere in this Handbook is also of relevance to the effective running of a sub-contract.

It is important to note that effective running of a sub-contract requires both systems engineering and project management specialists to work together. If the sub-contract is viewed as being the responsibility of one or the other then it will almost certainly be poorly set-up and run.

Sunk costs are a useful business concept. Sunk costs are simply spend already made, and unrecoverable no matter what is done in the future.

In business the term is used as a reminder that we can't do anything about spend already made, and we should therefore ignore it when making decisions about what to do in the future. Thus, just because we have spent a large amount of money on something does not mean we should continue it (to use a cliche, 'we should not let good money follow bad'). We should only continue it if it is the best way forward given where we are.

The concept of Sunk costs is a useful one to bear in mind with respect to anything we do. We should always consider what is best to do based on the situation we are in, and the possibilities that now exist, and not be constrained by what we have done or not done in the past.

A Supplier is someone who provides goods or services to a Customer, generally in exchange for money. This exchange is formally agreed and written down in terms of a contract - see CONTRACTING.

The terms Supplier and (Sub-)Contractor are frequently used interchangeably. However there is often an underlying differentiation in the context within which the terms are used. The term (Sub-)Contractor is generally used where there is a requirement statement and the goods/services provided must be demonstrated to meet that requirement. The term Supplier is generally used where an order is placed for goods or services which the supplier provides and they must simply be demonstrated to be compatible with supplier provided information (eg. product descriptions).

Supply Support is concerned with ensuring the requirements for spares, repair items, consumables, etc. are identified, and providing for their supply.

The Supply support activity is often thought of as being in two parts:

• An initial provisioning, which is provided at the same time as the initial system is provided for.
• A sustaining activity, which is ensuring previously identified levels of spare parts, etc. are maintained in the light of use of some items.

The term support documentation refers to any/all technical documentation/data which is required to support a system/equipment. It thus includes: Design Description documentation/data, Production Details, Installation and setting to work manuals/instructions, Test Documentation, Operating Documentation/Manuals, Maintainer Documentation/Manuals, Repair Documentation/Manuals, Training Documentation/Manuals.

Where the system contains upgradeable/programmable software then a suite of software related documentation will be required which will include: programming manuals, program source listings, program documentation.

Documentation will also be required for support items themselves, including potentially all the type of documentation identified above.

This chapter provides a checklist of items required to support a system or equipment, together with additional notes on areas not already covered elsewhere.

Proving that support systems meet their requirement is a special example of ACCEPTANCE and TESTING. This chapter however discusses some specific issues arising with respect to support systems.

Introduction

Types of Support system acceptance tests

This book is about the design of systems. To be more specific it is about the design of certain types of systems, namely complex hardware/software systems. However the concept of systems is far wider than this book's subject matter. This chapter discusses some of these wider concepts, and introduces some of the principles associated with them. This is intended to give the reader a greater insight into what systems thinking is all about.

This chapter provides a brief overview of the systems approach to problem solving, which itself underlies the core concepts behind systems engineering.

Introduction

A design is a physical description of the component parts of something together with information on how they interact. The component parts of a system are its sub-systems/equipments. A system design is thus a description of the sub-systems/equipments and their interactions.

This chapter does not attempt to describe how to do system design. This is done in the Overview section, and will not be repeated here. This chapter:

• Discusses some of the more philosophical aspects of system design.
• Gives some details on particular aspects of system design not addressed as specific topics elsewhere.

System Design Rules are requirements/constraints applied across the system intended to ensure a common approach to certain issues across the various subsystem/equipments. The System Design Rules (SDRs) will be referred to from the specific subsystem/equipment specifications and be a part of the requirement on the given subsystem/equipment.

The SDRs will be developed in parallel with the system/equipment and the interface specifications. They can be thought of as merely a way of avoiding repeating certain aspects of the requirement in each specification.

System Design Tools

This chapter identifies different types of systems engineer, and how the term is frequently used (and mis-used).  In particular it is pointed out that many engineers have the title systems engineer, but in reality their systems engineering skills only apply to a given type of system product.

Introduction

Relative Characteristics of Systems Engineering and Product Systems Engineering
Skills Required of the Systems Engineer
Development Path for a Systems Engineer

This chapter identifies precisely what is meant by systems engineering, and differentiates it from the project engineering and specialist engineering.

Introduction

Systems Engineering Specific Activities
Systems Engineering Outputs
Major Areas of specialision co-ordinated by Systems Engineering
System Engineering Management Plan (SEMP)
Is Systems Engineering an engineering discipline?

This chapter refers to evaluation of the system once it is in-service.  It identifies why this should be done, what areas frequent require to be evaluated, how to go about it, and the need to consider the needs for in-service evaluation during the initial design of the system.

Introduction

Areas that may require evaluation
Data Recording Requirements
Means of gathering data and important aspects of the use of forms
Design for In-Service Evaluation
Feedback for Future Upgrade or New System Design

The concept of system failure is not so obvious as that for equipment or component failure, due to the multi-functional nature of a system, and the fact that some aspects of the system may fail to a greater or lesser extent whilst other aspects continue to work normally.  This chapter clarifies use of the term 'Systems Failure', and discusses some of the issues associated with it.

Introduction

What is meant by Failure?
Types of Failure
High Level Causes of Failure
Causes of Weaknesses in the Design
Costs of Failure
Environment Exceeded Failure
Software Failure
Responsibilities for Failure
Designing Against Failure

This chapter briefly describes the main stages of a system products life-cycle, and the principle systems engineering related activities that apply to each stage.

Introduction

Project Definition/Concept
Feasibility/Analysis Phase
System Design
Detailed Design
Production
Installation and Setting to Work
Acceptance
In-service support
Major Upgrade
American Departement of Defence System Life-Cycle

This chapter identifies the important characteristics required for effective management of system projects.

Introduction

Differences between system project, project, and organisational Management
Management Techniques directly applicable to systems management
Start-Up-Project Management vs Mature-Project Management
Good vs Mediocre/Poor Management
System Design Teams

This chapter looks in a general way at principle criteria and approaches to system partitioning.

Introduction

Partitioning Criteria
Commonly used System Partitioning Processes
A practical approach
A Functional Partitioning Process
Benefits of Minimising Sub-system interfaces
Issues in assessing a given system partition
Risks introduced by Poor System Partitioning
Different Viewpoints on the Partitioning Process