These general guidelines cover the open system acquisition and supply processes.<\/p>\n
There is an increasing requirement for systems designed and produced by industry, particularly in the aeronautic, space and defence fields, to be used with other systems designed, produced, acquired and operated independently.<\/p>\n
The concept of open systems is touched upon in many systems engineering documents. This document deals specifically with this subject. To this end, through the various processes applied, it provides information to stakeholders (buyers, suppliers, designers, subcontractors, supervisors, etc.) on the best practice to be adopted.<\/p>\n
The specific nature of openness for a system is defined by all the following properties:<\/p>\n
Interchangeability,<\/p>\n<\/li>\n
Interoperability,<\/p>\n<\/li>\n
Upgradability,<\/p>\n<\/li>\n
Reusability,<\/p>\n<\/li>\n
Reversibility,<\/p>\n<\/li>\n
Flexibility,<\/p>\n<\/li>\n
Affordability.<\/p>\n<\/li>\n<\/ul>\n
These properties are defined in the glossary for these general guidelines.<\/p>\n
These general guidelines are largely based on the structure and system life cycle processes described in standard ISO\/IEC 15288:2008.<\/p>\n
The characteristics of openness also relate to:<\/p>\n
The products or services offered by the company (target systems resulting from use of company processes).<\/p>\n<\/li>\n
The company\u2019s processes (project systems). Several stakeholders, with their own assignments, cultures, jobs and geographical locations, different working methods, modelling frameworks, standards, tools and aids, etc. are involved in the activities, which are sometimes multidisciplinary, of the internal and external processes of a company. These diverse elements are not necessarily all suited to working together without causing certain risks, a loss of autonomy, effectiveness and\/or efficiency, etc. A company must, for example, develop its ability and capacity in terms of interoperability both internally (between the systems of which it is made) and externally (with other partners), including, by way of an example:<\/p>\n<\/li>\n
Ability of each stakeholder and each department involved to maintain efficient and trusting relationships with other stakeholders, taking into account deadline, cost and quality objectives,<\/p>\n<\/li>\n
Ability to exchange, communicate and use the necessary flows (data, information, knowledge, materials, energy) autonomously, without error and dynamically throughout the life cycle of the target system,<\/p>\n<\/li>\n
Ability to coordinate, synchronise and manage common tasks and share and use resources (human, machine or application) and services efficiently and appropriately.<\/p>\n<\/li>\n<\/ul>\n
| PDF Pages<\/th>\n | PDF Title<\/th>\n<\/tr>\n | ||||||
|---|---|---|---|---|---|---|---|
| 4<\/td>\n | Contents Page <\/td>\n<\/tr>\n | ||||||
| 5<\/td>\n | Foreword <\/td>\n<\/tr>\n | ||||||
| 6<\/td>\n | 1 Scope <\/td>\n<\/tr>\n | ||||||
| 7<\/td>\n | 2 Normative references 3 Terms and definitions and abbreviated terms 3.1 Terms and definitions <\/td>\n<\/tr>\n | ||||||
| 10<\/td>\n | 3.2 List of abbreviations 4 Acquisition process 4.1 An acquisition strategy is established 4.1.1 Define an openness strategy <\/td>\n<\/tr>\n | ||||||
| 11<\/td>\n | 4.1.2 Define an acquisition strategy 4.2 A supplier is selected and the selection justified 4.2.1 Define selection criteria 4.2.2 Justify the choice of supplier <\/td>\n<\/tr>\n | ||||||
| 12<\/td>\n | 4.3 Communication with the supplier is maintained 4.4 A contract is drawn up 4.4.1 State the acceptance criteria for openness 4.4.2 Stipulate the legal conditions <\/td>\n<\/tr>\n | ||||||
| 13<\/td>\n | 4.4.3 Define the means for checking openness characteristics 4.5 A product or service conforming to the contract terms is accepted <\/td>\n<\/tr>\n | ||||||
| 14<\/td>\n | 4.6 The contract is closed 5 Supply process 5.1 A buyer or a market for a product\/service is identified and a proposal made 5.2 A contract is drawn up and communication maintained 5.3 A product or service conforming to the contract terms is provided <\/td>\n<\/tr>\n | ||||||
| 15<\/td>\n | 5.4 Ownership is transferred to the client 5.5 The contract is closed 6 Life cycle model management process 6.1 The strategy and the processes required for managing the life cycle model are defined 7 Infrastructure management process <\/td>\n<\/tr>\n | ||||||
| 16<\/td>\n | 8 Budget management process 8.1 The opportunities, investments or requirements of the investment plan are defined, prioritised and selected 8.2 Resources and budgets are identified and allocated for each project 9 Resource management process 9.1 The core skills required by the projects are identified <\/td>\n<\/tr>\n | ||||||
| 17<\/td>\n | 9.2 The necessary human resources are provided for the projects 9.3 Staff core skills are developed, maintained or enhanced 9.4 Conflicts in multi-project resource demands are resolved 9.5 Individual knowledge, information and core skills are pooled, shared, reused and improved throughout the organisation <\/td>\n<\/tr>\n | ||||||
| 18<\/td>\n | 10 Quality management process 11 Project planning process 11.1 The project plan is available <\/td>\n<\/tr>\n | ||||||
| 19<\/td>\n | 11.2 Stakeholders, responsibilities and authorities are identified 11.3 The resources and services required for project completion are formally requested 12 Project control and assessment process <\/td>\n<\/tr>\n | ||||||
| 20<\/td>\n | 13 Decision-making process 14 Risk management process 14.1 The scope of risk management is determined <\/td>\n<\/tr>\n | ||||||
| 21<\/td>\n | 14.2 Appropriate risk and opportunity management strategies are defined and implemented <\/td>\n<\/tr>\n | ||||||
| 22<\/td>\n | 14.3 Risks and opportunities are identified as soon as they emerge, managed until a conclusion is reached and funded <\/td>\n<\/tr>\n | ||||||
| 23<\/td>\n | 14.4 Risks and opportunities are analysed and their priority (for allocation of resources) is determined 14.5 Risk management\/opportunity exploitation measures are defined, implemented and evaluated to determine changes in the risk\/opportunity status and the progress of activities to deal with them 14.6 The appropriate action is taken to integrate the opportunity into the project 15 Configuration management process <\/td>\n<\/tr>\n | ||||||
| 24<\/td>\n | 15.1 A configuration management strategy is defined 15.2 Define a configuration management strategy 15.3 The items requiring configuration management are defined 15.4 Configuration references are established <\/td>\n<\/tr>\n | ||||||
| 25<\/td>\n | 15.5 The configuration of configuration items is managed 15.6 The status of configuration items is available throughout the life cycle 16 Information management process 16.1 The information to be managed is identified <\/td>\n<\/tr>\n | ||||||
| 26<\/td>\n | 16.2 Information formalism is defined 16.3 Information is modified to suit requirements 16.4 Information is kept available 16.5 Information is up-to-date, complete and valid <\/td>\n<\/tr>\n | ||||||
| 27<\/td>\n | 16.6 Information is made available to the designated parties 16.7 Information is made available to the designated parties whenever changes are made 17 Measuring process 17.1 Information requirements for the technical and management processes are identified 17.2 An appropriate set of assessment measurements, based on information requirements, is identified and\/or developed. <\/td>\n<\/tr>\n | ||||||
| 28<\/td>\n | 17.3 Assessment activities are identified and planned 17.4 The required data is compiled, stored, analysed and the results interpreted <\/td>\n<\/tr>\n | ||||||
| 29<\/td>\n | 17.5 Information products are used to uphold decisions and provide an objective basis for communication 17.6 The measuring process and the measurements are evaluated 17.7 Improvements are communicated to measuring process managers 17.8 Appendix: ATAM (\u201cMethod for Architecture Evaluation\u201d) <\/td>\n<\/tr>\n | ||||||
| 30<\/td>\n | 18 Requirement establishment and analysis process 18.1 Establishment of stakeholder requirements 18.1.1 Define the requirement <\/td>\n<\/tr>\n | ||||||
| 31<\/td>\n | 18.1.2 Identify the stakeholders 18.1.3 Identify the requirements and constraints of the openness 18.2 Definition of stakeholder requirements 18.2.1 Establish usage scenarios <\/td>\n<\/tr>\n | ||||||
| 32<\/td>\n | 18.2.2 Characterise the operational flows and list the interfaces of the target system 18.2.3 Characterise the interfaces and define the openness requirements for the interfaces 18.2.4 Highlight the services that the system must provide 18.2.5 Define the functions that the system must carry out 18.2.6 Define the requirements that may restrict architectural choices <\/td>\n<\/tr>\n | ||||||
| 34<\/td>\n | 18.2.7 Identify the openness characteristics associated with the MMI <\/td>\n<\/tr>\n | ||||||
| 35<\/td>\n | 18.2.8 Define the requirements which have inevitable consequences for contracts and technical or project decisions 18.2.9 Formulate the Manufacturing, Integration and Transition requirements specific to the openness 18.2.10 Formulate Verification and Validation requirements <\/td>\n<\/tr>\n | ||||||
| 36<\/td>\n | 18.2.11 Prepare the information to be provided with regard to the operational openness requirement in the various documents at the beginning of the design phase 18.3 Analysis of stakeholder requirements 18.3.1 Analyse all requirements obtained 18.3.2 Select the critical requirements with regard to openness <\/td>\n<\/tr>\n | ||||||
| 37<\/td>\n | 18.3.3 Validate the specification of requirements with the stakeholders 18.3.4 Trace the requirements in a way appropriate to management of requirements 18.4 Requirement monitoring throughout the system life cycle 18.4.1 Continue monitoring requirements during the whole life cycle of the system 19 Architecture design process <\/td>\n<\/tr>\n | ||||||
| 38<\/td>\n | 19.1 Describe and model prospective architectures <\/td>\n<\/tr>\n | ||||||
| 39<\/td>\n | 19.2 Define, document and manage the architectures, mainly the interfaces, of the system 19.3 Compare the prospective architectures and select the one that best meets the requirement and the openness criteria 19.4 Check and validate the openness characteristics of the architecture and certify the interfaces 20 Execution process 21 Integration process <\/td>\n<\/tr>\n | ||||||
| 40<\/td>\n | 21.1 Establish an integration strategy 21.2 Define the design constraints resulting from the integration 22 Verification process 22.1 Establish a verification strategy <\/td>\n<\/tr>\n | ||||||
| 41<\/td>\n | 22.2 Define the design constraints so the system can be verified 22.3 Check the openness characteristics 22.4 Identify and correct non-conformities <\/td>\n<\/tr>\n | ||||||
| 42<\/td>\n | 23 Validation process 23.1 Establish a validation strategy 23.2 Define the constraints resulting from validation 23.3 Validate the openness characteristics <\/td>\n<\/tr>\n | ||||||
| 43<\/td>\n | 23.4 Identify and correct nonconformities 24 Qualification process 25 Operating process 25.1 Prepare a strategy for operation <\/td>\n<\/tr>\n | ||||||
| 44<\/td>\n | 25.2 Monitor the level of openness of the system throughout its operating cycle <\/td>\n<\/tr>\n | ||||||
| 45<\/td>\n | 26 Maintenance process 27 Withdrawal from service process <\/td>\n<\/tr>\n | ||||||
| 46<\/td>\n | Bibliography <\/td>\n<\/tr>\n<\/table>\n","protected":false},"excerpt":{"rendered":" Aerospace series. Programme Management. General guidelines for acquisition and supply of open systems<\/b><\/p>\n |