technical reference model for the government …government procurement of information systems...

1

Technical Reference Model for the Government

Procurement of Information Systems (TRM) 2010

June 2011

Information Services Industry Division, Commerce and Information, Policy Bureau,

Ministry of Economy, Trade and Industry

Information-Technology Promotion Agency, Japan

This document has been translated by Erklaren Co., Ltd.

2

Contents

1. Introduction .................................................................................................................................. 4

1.1. Background ................................................................................................................................... 4

1.2. Objectives ...................................................................................................................................... 4

1.3. Audiences ...................................................................................................................................... 5

1.4. Coverage ....................................................................................................................................... 5

1.5. Document Structure ....................................................................................................................... 6

1.6. Overview of Revisions to the 2009 version ................................................................................... 6

1.7. Revisions Planned in the 2011 version ......................................................................................... 7

2. Overview ....................................................................................................................................... 8

2.1. TRM Relationships with Other Documents, Guidelines, or Reference Models ............................ 8

2.2. Structure of this Technical Reference Model ................................................................................ 11

3. Definition (Categorization of Technologies) ........................................................................... 18

4. Procurements and System Design Policies ............................................................................ 24

4.1. Functional Configuration Model .................................................................................................. 24

4.2. Physical Configuration Model ...................................................................................................... 34

4.3. Categorization of Service-Work................................................................................................... 37

4.4. Policies for Defining Business Application .................................................................................. 40

4.5. Policies for Common Databases ................................................................................................. 46

4.6. Policies for Implementing Common Business System for Ministries .......................................... 48

4.7. Virtualization Technologies .......................................................................................................... 49

4.8. Standpoints of Cloud Users ......................................................................................................... 52

4.9. Standpoints of Cloud Integration ................................................................................................. 63

4.10. Security Issues ............................................................................................................................ 68

4.11. Policies for Employment of Green-IT .......................................................................................... 77

4.12. Notes on Employment of IPv6 .................................................................................................... 79

5. Descriptions of Technological Domain ................................................................................... 80

5.1. BI/DWH/ETL ................................................................................................................................ 82

5.2. EAI ............................................................................................................................................... 94

5.3. iDC Facility .................................................................................................................................. 96

5.4. SOA Related Functions ............................................................................................................. 100

5.5. Maintenance Environment......................................................................................................... 109

5.6. Servers ...................................................................................................................................... 120

5.7. Storage ...................................................................................................................................... 134

5.8. Shared PC / Office Printer ......................................................................................................... 139

5.9. Operations Management/Security ............................................................................................. 158

5.10. EIP ............................................................................................................................................. 193

5.11. Open Web Server ..................................................................................................................... 196

5.12. Groupware, File Server, and Mail Server .................................................................................. 206

3

5.13. Integrated Account Management, Authentication, Authorization (Access Control) .................. 221

5.14. Integrated Directory ................................................................................................................... 233

5.15. WAN, Ministerial LAN, DNS/DHCP/Proxy, Remote Access ...................................................... 238

5.16. Workflow, BAM .......................................................................................................................... 267

5.17. Common Elements in Domains ................................................................................................ 268

6. Procurement of services ......................................................................................................... 269

6.1. Support for master plan formulation .......................................................................................... 271

6.2. Support for procurement ........................................................................................................... 278

6.3. System Integration (Design/Development) ............................................................................... 297

6.4. Operation ................................................................................................................................... 323

6.5. Helpdesk.................................................................................................................................... 348

6.6. Maintenance .............................................................................................................................. 372

6.7. Tasks incidental to procurement of devices .............................................................................. 425

6.8. Tasks incidental to procurement of iDC equipment ................................................................... 444

6.9. Network procurement ................................................................................................................ 466

6.10. Cloud service ............................................................................................................................ 504

6.11. Cloud construction .................................................................................................................... 505

6.12. Security ..................................................................................................................................... 506

6.13. Other ......................................................................................................................................... 538

7. Recommended Technology Standard .................................................................................... 539

7.1. Requirements for technology standards in conformity with the “Framework for Interoperability

Relating to Information Systems” .............................................................................................. 539

7.2. Items for technology standard evaluation cited in “TRM 1st issue: The Report on the Results of

Validity Examination” ................................................................................................................. 542

7.3. Guidelines for the Selection of Recommended Technology Standards .................................... 543

7.4. Recommended Technology Standard ....................................................................................... 550

Appendix 1 Case Examples of Procurement................................................................................ 555

Appendix 2 Case Examples: Service Procurement Specifications ........................................... 559

Appendix 3 Table: Guidelines on the transition of encryption algorithms ............................... 567

Appendix 4 References ................................................................................................................... 570

4

1. Introduction

This document provides information about procurement of information systems, aiming to be used

as a supplemental reference to the “Basic Guidelines for Government Procurement Related to

Information Systems.”

1.1. Background

The integration of separately-procured information systems following the

separation-of-procurement-policy recommended in the “Basic Guidelines for Government

Procurement Related to Information Systems,” effective from July 2007 (agreed at the Liaison

Conference of Chief Information Officers (CIO) of Ministries and Agencies, hereinafter referred to as

the Procurement Guidelines), could, in some cases, create problems due to the lack of

interoperability of the individual business systems with the common platform system caused by the

incompatibility of employed vendor-specific technologies, especially the interface for service-calls. In

addition, the individually implemented systems may often lack user-friendliness, because, situations

where the ministries and agencies have independently implemented their portal systems—home

pages or portals for electronic submission. The Japanese users are often required to have different

client systems for the different systems prepared by the ministries and agencies: those systems often

require unique software or a specific web browser for the client systems on the user-side, or a version

mismatch of execution environments interferes with the use of the systems. Moreover, even if the

systems implemented in the ministries and agencies through independent procurement are optimum

in the sense that they follow the Procurement Guidelines, the “Guidelines for Optimizing Operation

and Systems” (agreed at the Liaison Conference of Chief Information Officers (CIO) of Ministries and

Agencies in March 31 2006), and “Framework for Interoperability Relating to Information Systems”

(announced by the Ministry of Economy, Trade and Industry in June 29 2007, hereinafter referred to

as “Framework for Interoperability”), such systems might not be optimum from the stand point of the

government as a whole, due to the lack of applicability to other systems.

1.2. Objectives

The objectives of this “Technical Reference Model for the Government Procurement of Information

Systems” (hereinafter referred to as “Technical Reference Model”) are as follows:

• Improving user friendliness,

• Ensuring system integration of separately-procured systems,

• Minimizing total cost in the job-operations and systems lifecycle,

• Improving efficiency of procurement.

5

This Technical Reference Model, with the intention of being used as a reference for optimum

procurement and implementation of information systems, provides the following:

• Technical guidelines for ensuring separation of procurement and integration following the Procurement Guidelines (Ch. 4),

• Technical guidelines for realizing visualization, clouds, and green IT,

• Functional configuration model consistent with the typical procurement models (Ch. 4),

• Physical configuration model consistent with typical government information systems (Ch. 4),

• Definition of technology domains (categories) — possible minimum group of procurement items (Ch. 5),

• Example of neutral descriptions of requirements for each technology domain in cases of the procurement of goods (Ch. 5),

• Essentials of requirement descriptions for each procurement category in case of the procurement of services (Ch. 6),

• Interoperable open standards to be preferentially employed (Ch. 7),

• Supplemental case examples (Case examples of procurement),

• Notes on ensuring security (Encryption algorithm transfer issues).

1.3. Audiences

This Technical Reference Model is prepared with the assumptions that it is referenced by the

following audiences:

• CIOs, Deputy CIOs, and support staff in the ministries and agencies, the independent administrative institutions, and the local governments,

• Persons in charge of information system design / planning / operations in the ministries and agencies, the independent administrative institutions, and the local governments,

• Persons in charge of procurement in the ministries and agencies, the independent administrative institutions, and the local governments,

• Procurement supporters

• Vendors bidding for the government information systems procurement. Note that, in the application of this Technical Reference Model to the procurement of systems other

than government information systems, adjustments, according to individual procurement policies or

system integration policies, are necessary as for the scale of procurement items and the technologies

or open standards to be employed preferentially.

1.4. Coverage

This Reference Model provides technical information applicable typically to the following systems:

• Information systems of the central government,

6

• Information systems of the independent administrative institutions,

• Information systems of the local governments. Note that, although this Technical Reference Model is basically applicable to the implementation and

procurement by the above information systems, adjustment or customization is necessary in some

cases such as the application to systems other than those of the central government.

Note that this Technical Reference Model will be revised periodically, reflecting requests from

persons in charge of the government procurement of information systems, or for catching-up with

changes in the trends of system requirements or product-features.

Note that this Technical reference Model, in accordance with the Procurement Guidelines, is

prepared to help create procurement specifications having no ambiguity in requirements, having no

unrealistic requirements, and having no requirements or factors in favor of specific hardware or

software products or technologies.

1.5. Document Structure

Besides this Technical Reference Model, which provides technical information, the following

documents constitute the document family of the technical reference model for the government

procurement of information systems: “Utilization Manual of the Technical Reference Model for the

Government Procurement of Information Systems (TRM)” (hereinafter referred to as “Utilization

Manual”), and the List and Descriptions of Technologies, an attachment to the TRM published on the

website.

1.6. Overview of Revisions to the 2009 version

In the 2010 version, the following are added to the 2009 version or modified:

• Addition: classification of service procurement,

• Addition: essentials of descriptions of requirements in service procurement,

• Addition: technical guidelines for virtualization,

• Addition: technical guidelines for the utilization of clouds,

• Addition: technical guidelines for the implementation of clouds,

• Modification: improvement and augmentation of descriptions on information security,

• Modification: addition of detailed descriptions of guidelines for the selection of recommended technical standards,

• Modification: separation and publishing on the website of the technology list and descriptions of technologies.

7

1.7. Revisions Planned in the 2011 version

In the 2011 version, the augmentation of the descriptions is planned as follows:

• Revising the technical requirements for the procurement of goods,

• Adding typical requirement-descriptions for the procurement of services,

• Adding typical requirement-descriptions on the utilization of clouds,

• Adding typical requirement-descriptions on the implementation of clouds,

• Adding descriptions on the utilization of open standards in procurement specification documents.

8

2. Overview

This chapter provides the general overview of this Technical Reference Model.

2.1. TRM Relationships with Other Documents, Guidelines, or Reference Models

This Technical Reference Model provides the technological information necessary, in order to

prepare specific requirement-descriptions in a request for information (RFI) or a request for proposal

(RFP), for breaking-down the principles recommended in the following documents, guidelines, or

reference models:

•Guidelines for Optimization of Government Information Systems, described in the

Guidelines for Optimizing Operation and Systems,

•Guidelines for Government Procurement, described in the Procurement Guidelines,

•Guidelines for Interoperability of Information Systems, described in the Framework for

Interoperability,

•Guidelines for Information System Security described in the Standards for Information

Security Measures for the Central Government Computer Systems.

2.1.1. Relationship to the Guidelines for Optimizing Operation and Systems

This Technical Reference Model provides the technical information to implement the principles of

the following guidelines recommended in the Guidelines for Optimizing Operation and Systems:

[Guideline 4-1]

As for the computerization of the whole or a part of job-operations, if such operations are similar to

those executed in other ministries, agencies, divisions, or departments, etc, and the computerized

systems can be applied to the operations in other entities, construct a unified computer system and

share the system among the entities, for the purpose of consolidation and centralization of

information systems.

In addition, even in a case where distributed data-management by the individual ministry or agency

is preferable, reduce the cost required for system development and maintenance while keeping the

interoperability, through the unification and centralization of functions required by applications and the

unification of requirements for data management;

[Guideline 4-2]

Reduce the number of LANs used in ministries or agencies to one per a ministry or agency, by

consolidating mail or other basic job-operation systems and centralization of maintenance jobs;

9

[Guideline 4-3]

Use LAN terminals connected to ministry’s internal LANs for accessing information systems to

execute job-operations. Use ministry’s internal LANs or other infrastructure networks for

accomplishing server-to-server connection or server-to-user connection;

[Guideline 4-4]

Use the Kasumigaseki-WAN for the connection between ministries or agencies. Use the local

government wide-area network (LGWAN) for the connection of government ministries or agencies to

local governments;

[Guideline 4-5]

Employ hardware, software, and communication protocols that are open and conforming to

international or de-facto standards in the implementation of information systems;

[Guideline 4-6]

Consolidate and reduce the number of the connection points to the information systems used to

publish information on the internet such as home pages, and apply comprehensive security measures

covering other information systems connecting to such systems;

[Guideline 4-7]

Prepare back-up systems for the systems where integrity and high-availability is required, among

the systems shared by ministries and agencies, or the systems tightly linked to the citizens’ lives or

social / economic activities of Japan.

2.1.2 Relationship to the Procurement Guidelines This Technical Reference Model provides technical information following the Procurement

Guidelines, promotes flawless government procurement in accordance with the guidelines, and

supports trouble-free implementation of information systems. This Technical Reference Model

enables the followings:

• Separation of procurement along phases of design or development;

• Management of design or development processes;

• Completeness of information necessary for preparing proposals;

• Separation of the procurement of hardware and the procurement of software

• Separation of procurement in the phase of design, development and deployment, the procurement in the phase of operation, and the procurement in the phase of maintenance;

• Elimination of ambiguity in requirements; • Requirement description based on open standards.

Note 1: “Open standards” refer to the standards satisfying the following:

(1) The standards are agreed through a publicly-open participation process, and the specifications are public

10

down to the implementation levels; (2) No one is rejected to adopt the standards; (3) Multiple products that

implement the standards are available in the market.

Note 2: This Technical Reference Model uses the term the “common platform system” as a term collectively

referring to the “common platform system” used in the Procurement Guidelines and the “H /W infrastructure used

in the “Application Manual of the Basic Guidelines for Government Procurement Related to Information Systems”

(Ver. 2) (published in July 1, by Administrative Management Bureau, Ministry of Internal Affairs and

Communications, hereinafter referred to as the Application Manual). In the same way, Technical Reference

Manual uses the term “common platform system provider,” collectively referring to the “common platform system

provider” and the “H / W infrastructure provider.”

2.1.3. Relationship to the Framework for Interoperability This Technical Reference Model provides information following the Framework for Interoperability:

the provided information supports the preparation of procurement specifications in accordance with

the government policies on information system and the interoperability presented in the Framework

for Interoperability. This Technical Reference Model includes the following:

• Policies on the neutrality of requirements;

• Policies on the preferential employment of open standards;

• Policies on the selection of the optimum information system;

• Policies on the adoption of openness. In addition, this Technical Reference Model recommends that the individual business systems should

be loosely connected to the common platform system through loosely coupled services.. The

recommendation is in accordance with the following guideline presented in the Framework for

Interoperability:

Guideline: When procurements of systems are separated into individual functions, it is desirable to

avoid putting limitations on computers and platforms on which such functions are executed.

Therefore, service interfaces should be platform-independent, and the individual services are

asynchronously and loosely coupled.

2.1.4. Relationship to the Standards for Information Security Measures for the Central Government Computer Systems

This Technical Reference Model provides the technical information necessary for the preparation of

procurement specifications that are following the Standards for Information Security Measures for the

Central Government Computer Systems and in accordance with the Standards for Information

Security Measures for the Central Government Information Systems.

Note: The latest version of the Standards for Information Security Measures for the Central

Government Computer Systems was released on April 23, 2011. Refer to the following URL:

http://www.nisc.go.jp/active/general/kijun01.html

11

2.1.5. Relationship to the Security-by-Design Policy and the Risk-factor Reference Model This Technical Reference Model, in the section 4.10, provides the guidelines of security measures,

by introducing the generals of security-by-design and the risk factor reference model.

2.1.6. Relationship to the Government Shared Platform System This Technical Reference Model, in the section 4.8, provides the general idea of using “clouds,” the

idea will be applicable to the use of the Government Common Platform.

2.2.Structure of this Technical Reference Model

This Technical Reference model, in Ch.3 and in the following chapters, provides technical

information as summarized in the following sub-sections.

2.2.1. Ch. 3: Definition (Categorization of Technologies) Ch. 3 shows the technology categories defined in this Technical Reference Model and the

Separated appendix: Table of Technical Categorization (Technical Domains).

This Technical Reference Model, for the purpose of avoiding ambiguities in the communications

between the procurers and providers, categorizes the technologies from the view points of the both

parties. Ch.3 categorizes technologies from the view point of providers through layering of the IT

system structures, formalizing the layered structure according to the TRM framework, and mapping

the individual elements of technology onto the framework by their usages or features

12

Break-Down -Structure of the IT-Technologies

Top Level Second Level Technologies Specific Items

Functions

Hardware

Platform

PC /

In-Office-shared

Printers

Personal Computer

Thin Client

In-Office-shared Printer

Server Server Hardware Server Hardware

Storage Disk Storage

Tape Storage

Network LAN Switch

Secure Wireless LAN

WAN Router

Remote Access

Private Line Service

Business

Operation

Platform

PC / Office

Printer

Common Operation Environment OS Kernel

Peripheral Support

Command Line Interface

Web Browser

Video Viewer

Server Server Operating System OS Service

Thin Client Server

Network DNS / DHCP / Proxy DNS Server

DHCP Server

Proxy Server

VoIP

Application

Platform

Application

Execution

Environment

Web Server

AP Server

Data

Management

Meta Data Registry

DB Server

File Sharing

Integrated Directory

Data Exchange

/ Linkage

EAI

Data Adapter

Legacy-System Integration

Table 2.2-1: Technology Category (Part)

Figure 2.2-2 shows the technology domains mapped on the layer of TRM Framework.

13

Hardware Platform

(H/W) Server

Job-Operation Platform

(Server OS)

Application Platform

(General-Purpose

Middleware)

Base Applications

BI/DWH/ETL

iDC Facility

Sys

tem

Ope

ratio

n M

anag

emen

t

Sec

urity

EIP(Shared S/W)

File Server

Individual Business Applications

Com

mon

Tec

hnol

ogie

s to

All

Dom

ains

EAI(Web

Service)

(Protocol)

(H/W)WAN, Ministry’s

Internal LAN

Remote Access

(H/W) Shared PC, Shred-in-

Office Printer

(Client OS)

(Base S/W)

Groupeware, Mail Server

Public Web

Server

App

rova

l

Mai

nten

ance

Env

ironm

ent

Workflow, BAM

Legacy Integration

(Individual Business System)

SOA-Related

Functions(SOA)

(Ded

ecat

edM

iddl

ewar

e)

Authentication, Integrated Account

Management, Integrated Directory

(Net

wor

k S

ervi

ce)

Colors indicate where the technology in the box is used.

(H/W)Storage

(Common Business System)

DN

S, D

HC

P, P

roxy

Mainly used in client environments: PCs or printers

Mainly used in server environments: servers or storages

Same as described at the left

Network related technologies

Technologies common to the entire IT sphere: independent of specific environments

Figure 2.2-2 Technology Domains mapped on the TRM Framework

2.2.2. Ch. 4: Procurements and System Design Policies Ch.4, from the standpoint of procurers, shows the goods and services to be purchased in each

technical domain: domains are defined through classifying and categorizing the target functions,

making models—patterns—of functions for each unit of purchase, assembling necessary

technologies likely procured at one time as certain groups —domains—and allocating the functions to

the domains. At the same time Ch. 4 shows where, in the physical configuration of the ministry and

agency systems, each domain in the Function Configuration Model is allocated. Note that it is not

always required to realize each function shown in the configuration diagram with a separate piece of

hardware: from the standpoint of optimization, realization on a single server of functions allocated to

multiple technology domains would be preferable. For example server consolidation, utilization of

existing servers, or utilization of communication equipments for remote-access are preferable

methods. Elimination of redundant services or goods through optimization-assessment is essential.

Also, Ch.4, for the purpose of complementing the Guidelines for Optimizing Operation and

Systems, and the Procurement Guidelines, shows the policies of designing information systems to be

procured; and for the purpose of Request For Information (RFI), and Request For Proposal (RFP)

and procurement specifications, shows policies of designing business application, policies for

common databases, utilization of common business system for Ministries, policies of employing

green IT, policies of security, policies of virtualization, and policies of utilization and implementation of

clouds.

14

2.2.3. Ch. 5: Descriptions of Technology Domains

Ch. 5 provides the descriptions of Technology Domain from the standpoint of the procurers of

goods, with examples of requirement specifications for general — common to ordinary specifications.

Although the functional or non-functional requirements shown in those examples are realistic

because the technologies or goods are available and proven in Japan at the time of publication of this

Technical Reference Model. Those specifications are only general purpose examples. Therefore,

when applied to the actual procurement, the example specifications should be customized according

to the situations: the parameters (variables) in { } need to be modified, the example descriptions in [ ] needs to be modified or selected, and addition or elimination of requirements will be necessary. Note

that, in such customization, sufficient consideration or care is required for avoiding

unreasonably-severe conditions or putting in unnecessary requirements.

Also, note that it is not always necessary to procure all the technical elements shown in the

domains: previously procured technological elements or certain elements purchased in other

purchase orders may be reusable. Utilization of existing resources or elements included in other

purchases and avoidance of duplicated procurement through the optimization assessment is

necessary when actual specifications are prepared by applying the descriptions in Ch.5.

2.2.4. Ch. 6: Procurement of Services

Ch. 6 shows the categorization of services to be procured from the standpoint of procurers, and

then shows the overviews of services to be described in specifications for each of the categories

defined. Also, Ch.6 provides information on the following: prerequisite information prepared by

procurers to be described as a detailed requirement; outputs of services; essential points to be

described in procurement specifications and comments / interpretations; and project-dependent

points and information-system-feature-dependent points to be taken into account. Note that, in

comparison with Ch.5, Ch.6 does not provide information so that the descriptions can be copied to

actual specifications, for the reason that the service-procurement specifications will be more

dependent on project-specific factors than those of the procurement of goods, and therefore the

specifications must be prepared so that the outputs of the service-procurement in the proceeding

phase is sufficiently detailed.

15

Figure 2.2-3: Classification of procurement of services

6.2 （等）

要件定義開発フェーズ運用・保守フェーズ

6.2 - 1 調達支援

（等） 6.1 全体計画策定支援

6.4 運用 6.3

6.3 ハードウェア更改 6.3 機能追加

・設備） 6.9 Network procurement

6.7 Tasks incidental to procurement of devices

6.8 Tasks incidental to procurement of iDC equipment

6.12 Security

6.2.3 Support for procurement (Project management, etc.)

Planning phase

Requirements definition phase

Development phase Operation/maintenance phase

6.2.2 Support for procurement (requirements definition, etc.)

6.1 Support for master plan formulation

6.4 Operation

6.3 System integration (design/development)

6.5 Helpdesk

6.6 Maintenance

Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance

16

Figure 2.2-4 Descriptions of the Services Service Service operation


Planning the systematization initiative and systematization plan creation

6.2 Support for procurement Service operations of supporting procurement for ministries: e.g. implementation of requirements definition, deciding on procurement policies/procedures, creation of procurement specifications, request for comment, evaluation of contractors, and project management.


Service operations concerning information system integration: e.g. design, development, migration, operation, operation/maintenance design of information systems.

6.4 Operation Service operations concerning information systems (“6.5 Help desk” may be considered as part of the operations of 6.4; however, it is separately described in Chapter 6.5)

6.5 Help desk Service operations concerning help desk to respond to inquiries from users on system operationuse

6.6 Maintenance Service operations of information system maintenance: e.g. correction of information system faults, modification of system/software products after delivery and adaptation to changed environments


Service operations generated incidental to procurement of devices(*excluding maintenance): e.g. installation, configuration of devices necessary for information systems (including ready-made software, such as OS which is inseparable from hardware)


Service operations such as installation and configuration of various equipment in facilities (data center) prepared by customers, and operation monitoring of relevant systems (and operations incidental to it)

6.9 Network procurement Services related to construction of networks, such as LAN and WAN (Wide Area Network), and service operations incidental to service procurement, such as WAN service and internet service.

6.10 Cloud service Service operations using cloud system services 6.11 Cloud construction Service operations to construct cloud systems 6.12 Security This section describes security cautions in procurement

of services and security approaches during construction of information systems

6.13 Other (to be created) Service operations not included in 6.1 – 6.12, such as procurement of business package software.

17

2.2.5. Ch. 7: Recommended Technology Standards Ch. 7 shows the open standards to be preferentially employed especially in the procurements of

government information systems. Note that those open standards are solely chosen for the purpose

of the separation of procurement recommended in the Procurement Guidelines, and will not cover all

the technologies to be procured. Also note that as for the employment of open standards, the

excessive employment of open standards to the layer where the interoperability is unnecessary may

limit the selection of technologies or products to open-standard conforming products. Therefore, open

standards in procurement specifications should be specified only in the following layers: the interface

between the elements of information systems to be procured separately; and the interface of the

existing environments and the newly procured elements of information systems. It is preferable to

leave the decision of open-standard employment of the lower levels to the vendors.

2.2.6. Separated appendix 1: Samples of Procurement Separated appendix 1 introduces the actual specifications of the government procurement as a

supplement to this Technical Reference Model, for the purpose of reducing the work load in preparing

high-quality procurement specifications. In preparing actual specifications, it is preferable to use the

examples as well as the descriptions in the main chapters of this Technical Reference Model. The

web page of the Ministry of Internal Affairs and Communications and the web pages of other

ministries publish procurement examples not shown in this separated appendix.

2.2.7. Separated appendix 2: Samples of Procurement Requirements of Service Separated appendix 2 shows a table, listing the actual procurement specifications, on which Ch. 6

is based.

2.2.8. Separated appendix 3: Encryption Algorithm Transition Separated appendix 3 introduces the necessity of the transition of the encryption algorithm SHA-1

and RSA1024 widely used at present to more secure algorithms.

2.2.9. Separated appendix 4: References Separated appendix 4 lists the documents or articles helpful to understand this Technical

Reference Model, and shows how to access them.

18

3. Definition (Categorization of Technologies)

The purpose of this Technical Reference Model in this document is to promote smooth and less

ambiguous communications between the procurers and the bidders by providing categorizations for

technologies that are well accepted by both the procures and the providers. Chapter 3 categorizes

technologies in technology domains mainly from the providers’ point of view, provides a layered

structure of IT systems, configures the TRM framework, and maps element technologies onto the

framework.

Hardware Platform

(H/W) Server


(Server OS)


Base Applications

iDC Facility

Syst

em O

pera

tion

Man

agem

ent

Secu

rity

Office Applications


Com

mon

Tec

hnol

ogie

s to

All

Dom

ains

WebService

(Protocol)

(H/W) Network

(H/W) PC, In-office-shared Printer

(Client OS)

SOA-Related

Functions

Data ManagementApplication

Platform

Data Utilization

Information Access /

Collaboration

Business / Process

Management

Data Exchange / Linkage

Dev

elop

men

t / M

aint

enan

ce E

nviro

nmen

t

Net

wor

k Se

rvic

eColors indicate where the technology in the box is used.






(H/W) Storage

Figure 3-1: TRM Framework

The Figure 3-2 can be used as a reference to how the technology domains are mapped in the layers

of the TRM Framework.

19

Hardware Platform

(H/W) Server


(Server OS)


(General-Purpose

Middleware)

Base Applications

BI/DWH/ETL

iDC Facility

Sys

tem

Ope

ratio

n M

anag

emen

t

Sec

urity

EIP(Shared S/W)

File Server


Com

mon

Tec

hnol

ogie

s to

All

Dom

ains

EAI(Web

Service)

(Protocol)

(H/W)WAN, Ministry’s

Internal LAN

Remote Access

(H/W) Shared PC, Shred-in-

Office Printer

(Client OS)

(Base S/W)

Groupeware, Mail Server

Public Web

Server

App

rova

l

Mai

nten

ance

Env

ironm

ent

Workflow, BAM

Legacy Integration

(Individual Business System)

SOA-Related

Functions(SOA)

(Ded

ecat

edM

iddl

ewar

e)

Authentication, Integrated Account

Management, Integrated Directory

(Net

wor

k S

ervi

ce)

Colors indicate where the technology in the box is used.

(H/W)Storage

(Common Business System)

DN

S, D

HC

P, P

roxy






Figure 3-2: Technology Domains mapped on TRM Framework

20

Table 3.1: Break-down Structure of IT-Technologies

Break-Down -Structure of the IT-Technologies

Top Level Second Level Technologies Specific Items

Functions

Hardware

Platform

PC /

In-Office-shared

Printers

Personal Computer

Thin Client

In-Office-shared Printer

Server Server Hardware Server Hardware

Storage Disk Storage

Tape Storage

Network LAN Switch

Secure Wireless LAN

WAN Router

Remote Access

Private Line Service

Business

Operation

Platform

PC / Office

Printer

Common Operation Environment OS Kernel

Peripheral Support

Command Line Interface

Web Browser

Video Viewer

Server Server Operating System OS Service

Thin Client Server

Network DNS / DHCP / Proxy DNS Server

DHCP Server

Proxy Server

VoIP

Application

Platform

Application

Execution

Environment

Web Server

AP Server

Data

Management

Meta Data Registry

DB Server

File Sharing


Data Exchange

/ Linkage

EAI

Data Adapter

Legacy-System Integration

Web Service ESB (Enterprise Service Bus)

21

Web Service Protocol Base Technology

Security Service

High-Reliability Messaging

Service

Transaction Service

Base

Application

Information

Access /

Collaboration

Mashup Portal

EIP Portal Sites

Personalize

Application Integration

Contents Management System

Groupware

E-mail

Instant Message

Full Text Search

Web Conference

Screen Sharing Service

Business /

Process

Management

Business Process Management

Business Activity Monitoring

Business Model Simulation

Work Flow

Data Utilization Business Intelligence

Data Warehouse

ETL (Extract / Transfer / Load)

Data Mart

OLAP (Online Analytical

Processing)

ODS (Operational Data Store)

Data Mining

Dashboard

Reporting Tool / Service

SOA Related

Function

Management

Service Repository / Registry

Office

Application

Office Application Image Processing

Word Processing

Presentation

Spread Sheet

Facsimile

Image Publishing

22

Document Processing

Calculation

System

Operation

Management

System

Operation

Management

System Operation Management Availability / Performance

Management

Client PC Management

Server Management

Network Management

Storage Management

Service Desk

Security Security Security Management Trail Management Function

Virus Protection Function

Virus Gateway

Internet Content Filtering

Function

Firewall Function

Intrusion Detection / Protection

Function

Network Connection Monitoring

Function

Encryption Function

Anti-Spam Mail Function

Integrated Account Management

Directory Linkage

OS Access Control

Web Single Sign-on

Desktop Single Sign-on

Common

Technology to

All Domains

Common

Technology to

All Domains

Coded Character Set

Graphic Format

CD-ROM Format

DVD Format

Character Symbol

Tagset / Markup-language

Definition

Data Element Standard

Video Format

Compaction / Archiving

Magnetic Tape

Business Information

Geographic Information

23

Character Set / Data

Representation

Locale / Native Language

Support

Programming Language

Modeling Support

Accessibility

Network

Service

Network

Service

Communication Protocol

Time Service

Development /

Maintenance

Environment

Development /

Maintenance

Environment

Development Environment

Development Tool

Configuration / Version

Management Tool

Project Management Tool

Test Tool

Product /

Service

specific

Technology

Product /

Service specific

Technology

Video Processing

Voice Information Processing

CAD (Computer Aided Design)

Expert System

E-learning

Kiosk

Mobile Device

Product Information

Mobile / Wireless

IC Card

Media Distribution Service

Geographic Information Service

Document Management Service

TRM

Supporting

Technology

TRM Supporting

Technology

IT Service Management

Software Lifecycle Management

Internal Control Framework

24

4. Procurements and System Design Policies

4.1. Functional Configuration Model

This chapter, from the standpoint of procurers, shows the allocation of technology elements

configuring applications, the common platform systems, and networks to the technology domains in

the Functional Configuration Model. In particular, on the boundary between the common platform

system and networks, allocation of network-technology elements are defined as consistent as

possible with actual situation of technology elements procured. Note that the Functional Configuration

Model includes elements configuring private-cloud environments (a private cloud refers to a cloud

constructed and used locally within an organization.).

Application

Common Platform System

Network

Workflow / BAM

EAI

Function for SOA

Server

System Operation Management / Security

Common Business System

WAN /Ministry’s Internal LAN

Groupware / File Server

Remote Access Shared PC

In-office-shared Printer

EIP

Public Web Server

Legacy System Integration

Functional Configuration Model


Integrated Account Management / Authentication / Permission

Individual Business System

BI/DWH/ETL

iDC Facility

Maintenance Environment

: Technology Domains

Storage

Figure 4.1-1 Functional Configuration Model

4.1.1. Definition of Technology Domains

Technology Domains, defined through categorization and classification of technologies in such a

way that the items of actual procurement in the central government fit in, are also used as top level

classifications to coarsely categorize or classify the nonnegligible technologies or products belonging

to more than one domain, or difficult to precisely allocate.

The Technology Domains are defined as follows:

25

Application

Technology Domain Definition

Individual

Job-operations

• Job-operations defined in the Job-operation Manual

• Individual business applications of job-operation

Legacy System

Integration

• Mechanism existing in the application layer to make a linkage

between the job-operations realized on legacy systems and

those on the common platform system

• Note that EAI, etc. are excluded.



Common Job-operation • Common job-operations defined in the Job-Operation Manual

available on the common platform system.

• The services commonly available to individual job-operations.

Workflow / BAM • A versatile mechanism to manage or monitor job-processes

• Note that web-service-based BPM is excluded.

BI /DWH / ETL • A versatile and high-performance mechanism for data

referencing / search / analyzing data, effective for reducing

individual implementation of job-operation input / output

display screens or forms.

• Also, refers to a versatile mechanism for data handling.

EAI • A versatile mechanism for linking job-operation systems.

SOA Related Function • Web-service-based framework for organizing the entire

operation systems through linking the web-services

• Also, refers to related technology standards to support the

framework.

System-operation

Management / security

• The entire mechanism for managing operations or preserving

security of the common platform system and applications.

• Note that mechanisms required to be implemented in the

individual applications are excluded.

Maintenance

Environment

• The mechanism for implementing the environments required

for the maintenance of the common platform system and

applications.

• Also, in cases, specifically refers to the mechanisms for

enabling maintenance including in-operation-maintenance

procedures, development tools, or automatic-testing.

Server • Server hardware and software supporting all the functions

26

described above so far.

• Required to be an integrated environment under unified

management with reliability, availability, and flexibility; and, in

cases, virtualized implementations are required.

• Network equipments such as routers or switches are

included.

Storage • Storage hardware and software supporting all the functions

described above so far.

• Required to be an integrated environment under unified

management with reliability, availability, and flexibility; and, in

cases, virtualized implementations are required.

iDC Facility • A physical environment and programmed operation /

maintenance services supporting the servers and storage

devices described above. (Physical environment: the entire

facility and location-environment including buildings /

machine-rooms / installation-spaces, and equipment for

power / air-conditioning / communication / fire-extinguishing

/security.)

Network


EIP • An integrated portal service used in a limited capacity by the

ministries.

• Note that functions related to groupware are generally

excluded, and mechanisms for information-delivery and

sharing through portals are included.

Public web server • Hosts the public — externally accessible — homepages

• Desired to have integrated content-management functions

including CMS, etc.

• Also desired to have simple functions for information

gathering / acceptance

Groupware / File Server • A mechanism supporting groupware functions such as

mailing / scheduling / booking facilities or conference rooms,

and handy information sharing.

• Note that, when the technology domain is implemented using

portals, some functions overlap with those of EIP.

Integrated Account

Management /

• Refers to a mechanism comprehensively managing users in

an integrated manner.

27

Authentication /

Permission

• Unique IDs are allocated to all users for authentication and

access-control.

Integrated Directory • A meta-directory supporting the above-described Integrated

Account Management / Authentication / Permission.

• Desired to serve as a parent directory of various directories

implemented and used in other systems.

WAN Ministry’s Internal

LAN

• A main body of network services, including physical

communication lines and DNS / DHCP / Proxy.

• Desired to have basic security features.

Shared PC /

In-Office-Shared Printer

• PCs or Printers shared in offices.

• Must be equipped with mechanisms for implementing and

maintaining versatile and secured environments.

• Note that dedicated equipment for specific job-operations is

excluded.

Remote Access • A mechanism for accessing a ministry’s internal LAN from

outside of the ministry office.

• Desired to have supplemental security-protection functions

such as VPN or authentication, as well as a

network-connection environment.

28

4.1.2. Intended Items of Procurement This subsection shows the intended items of procurement where the definition of domains for

services and goods are listed separately, where services, designs and developments are described.

Note that expense of operation / maintenance, migration / transition, or installation is excluded.

Application


Network

Design and Implementation of Workflow / BAM

Design and Implementation of EAI / External Linkage

Design and Implementation of SOA(Design and Implementation of ESB, BPM, Service Repository and Web Service)

Design of Operations and Development of Management Tools (including the following functions: Monitoring, Back-up, Trouble Administration, Recovery Operations, Configuration Management, Resource Management, Resource Planning)

Security Design and Construction (including network security and personal information protection)

Design and Development of Common Business System (including physical design of DB)

Design and Implementation of a WAN

Design and Construction of a Ministry’s Internal LAN

Design and Implementation of Groupware

Design and Implementation of a File Server

Remote Access Design and Implementation of Shared PCs

Design and Implementation of Printers shared in Of f ices

Design and Implementation of EIP

Design and Implementation of a Public Web Server

Structure of Items of Service Procurement

Design and Implementation of an Integrated Directory

Integrated Account Management / Authentication / Permission

Design and Implementation of BI / DWH / ETL

iDC facility

Design and Implementation of Maintenance Environment

Design and Implementation of Legacy-system Integration

Design and Development of Individual Business System (including physical design of DB)

Design, Implementation, Deployment and Installation of Server(Configuration Design / High Reliability Design / Performance Design / Integration and Virtualization Design / Physical Design of DB)

Design, Implementation, Deployment and Installation of Storage (Configuration Design, High Reliability Design, Functional Design, Integration / Virtualization Design)

Figure 4.1-2 Structure of Items of Service Procurement in Relation to Technology Domains

29

Workflow Products

BAM Products

Products for EAI

Products for SOA

(including ESB, BPM, Service Repository, Web-service Products)

System Operation Management Software Products

Security Software Products

Software Products used as an element or an engine of common business system

Communication-line subscription for WAN

Equipments for Ministry’s Internal LAN

Groupware Products

File Server Products

Mail Server Products

Products for Remote Access

Shared PC (PC, COE Management Software, OA Software Products, Security Software Products, OS)

Shared Printers in Offices (Hardware and Software Products for Management

Software Products for EIP

Software Products for Public Web Servers

Products for Remote Access

Structure of Items of Procurement of Goods

Software Products for Directory Management

Software for Integrated Account Management / Authentication / Permission

(Software Products working as a functional element or an engine in individual business system)

(Dedicated Terminals or Printers)

(AP Server, Development Tools)

Products of BDI / DWH / ETL

iDC facility

Maintenance Environment (including Development Tools and automatic-test tools)

Server Product (Server, Router, Switch, High-reliability Product, Integration / Virtualization Product, Web Server, AP server, DBMS, OS)

Storage Products (including storage devices, high-reliability products, products for integration or virtualization)

Application


Network

Figure 4.1-3 Structure of Items of Procurement of Goods in Relation to Technology Domains

4.1.3. Guidelines for Necessity-judgment of the Employment of Technology Domains in Procurements

Note that the Functional Configuration Model or Categorization of Procurement described above

should be flexibly applied to actual procurement: unnecessary items, even if listed in such models,

should be excluded, and on the other hand necessary ones should be added. Basic ideas for

deciding whether a certain technology domain must be included in the procurement or not is shown

below:

Application

Technology Domain Necessity of Technology Domain

Individual job-operation ・ Mandatory

Linkage to legacy

systems ・ Optional (rarely required)

・ Required in case of the procurement of dedicated tools for linkage. Generally the function is included in job-operation

systems, EAI, or external linkages.

30



Common job-operation ・ Optional (highly required)

・ For details, refer to “4.3. Guidelines for Procurement of Job Applications.”

Workflow and BAM ・ Optional (rarely required)

・ For workflow tools (other than BPM). If such tools are commonly used among more than one individual

job-operation system, such tools should be included in the

procurement of common platform systems..

BI / DWH / ETL ・ Optional (fairly required)

・ In many cases, such tools are more reasonably implemented as a part of an individual job-operation system than

implemented as a component of the common platform

system.

EAI ・ Optional (fairly required)

・ In some certain cases, the function is fulfilled in SOA-related-functions.

SOA Related Function ・ Optional (highly required)

・ Refer to “4.3. Guidelines for Procurement of Job Applications.”

System operation and

Security ・ Mandatory

・ Note that the functional coverage should be determined carefully.

Maintenance

Environment ・ Mandatory

・ Note that the functional coverage should be determined carefully.

Server ・ Mandatory

・ Note that the functional coverage should be determined through a trade-off analysis with use of external resources.

Storage ・ Optional (not highly but likely required)

・ In cased of small configurations, storages will often be included in servers.

IDC and Equipment ・ Mandatory

・ Note that the coverage should be carefully determined through a trade-off analysis with use of external IDC

resources: whether having IDCs in-house is better or not than

using outside resources.

31

Network


EIP ・ Optional (fairly required)

・ In some cases, the function is fulfilled in a groupware or a file-server.

Public Web Server ・ Optional (fairly required)

・ In some cases, public web servers are often procured independently.

Groupware and

File-server ・ Optional (highly required)

・ In some cases, a groupware, or a file-server is procured independently.

Integrated Account

Management,

Authentication, and

Permission

・ Optional (fairly required)

・ In some cases, those functions are included in procurement such as common job-operation systems or individual

business applications.

Integrated Directory ・ Optional (fairly required)

・ In some cases, the function is fulfilled in other procurements such as integrated-account-management, or authentication

and permission.

WAN and Ministry’s

Internal LAN ・ Mandatory

Shared PC and

In-office-shared Printer ・ Optional (highly required)

・ In some cases, those are procured independently.

Remote Access ・ Optional (fairly required)

・ The purchase decision depends on specific requirements of ministries and agencies.

Also note that, as for packaged software products or middleware software products described later

in “4.4. Policies for Defining Business Application,” decisions of procurement should be done after

trade-offs, such as whether the products should be procured for the use limited in the individual

job-operations, or whether they should be procured as an infrastructure shared by more than one

job-operation. For an example, CRM software products or RIA software products, not listed as an

infrastructure on the assumption that they are used in individual job-operations, are allowed be

procured included in shared infrastructures.

Refer to “5. Descriptions of Technology Domains” for preparing procurement specifications of

packaged software products or middleware software products, where “Basic Features”—functions

expected to be included in standard products—are effective to eliminate products not having

acceptable features, and “Additional Features” should be used to pick up products having features

32

that are expected to be effective or indispensable to the realization of the individual job-operation.

Especially for the procurement of large systems on which the separate-procurement rule is expected

to be applied, it is recommended to use fully “Additional Features” not to overlook indispensable

features from the standpoint of expandability or automation of system operation and management.

On the other hand, for a small-scale system, note that the “Basic Features” may be

over-requirements from the standpoint of functions, performance, and reliability, and trade-offs should

be made before picking up the features as indispensables.

4.1.4. Items of Procurement

Although services and goods should be procured separately, installation work requiring no design

work, such as carrying-in and emplacement of hardware or installment of software, can be included in

the procurement of goods and services as incidental work. Also, maintenance of hardware products

and software products should be included in procurement of goods.

In addition, in the case of low-budget procurement, services and goods are allowed to be

procurement simultaneously if such combined procurement of services and goods will be fully

expected to contribute to the simplification of the maintenance scheme or the simplification of

procurement process.

- Procurement of Service

As for a unit of service procurement, different policies should be applied to different phases — the

design / development phase and the maintenance / operation phase. These policies are described

below. Note that they are supposed to be applied to the procurement of service, and in other cases

they should be used only as references.

In the design / development phase, different policies are applied to individual job-operations and

common job-operations. Especially, for the case of common job-operation, treat all elements grouped

in the technical domains for the common platform system as a unit of procurement, and then,

according to the necessity of specialized technologies, determine the domains to be procured

independently while taking care to prevent the increase in the number of vendors by limiting the

targets of separation to as few as possible. At the same time, determine the unit of separation flexibly

but generally following technology domain separation.

In the maintenance / operation phase, it is essential to treat maintenance and operation separately.

Maintenance means handling problems, addition of functions, modification, and tuning, etc. by

vendors having sufficient knowledge of the system. Operation means system monitoring, preliminary

failure analysis, and back-up by vendors having no special knowledge of the system, and working

according to manuals. Note that hardware maintenance or software-product maintenance should be

procured as a part of the procurement of goods, and not dealt with here.

33

Generally, maintenance should be done continually by the providers of the design or development

in the design / development phase. Note that, though, because maintenance of packaged

software-products or simple systems done by minimal development effort requiring no special tuning

could be assigned to other vendors than the provider of the system. It is necessary to take the above

into consideration.

System operation, because less dependent to the vendors of design / development, will be

recommended to be consolidated as tightly as possible not simply following the unit of procurement in

the design / development phase or maintenance phase.

- Procurement of Goods

The procurement of goods should be consolidated so that the number of procurements is as small

as possible. Note that, however, special-not generally available-goods, goods not procured along with

other goods, or goods probably requiring contract-renewal on design modification or redesign will be

practically procured separately.

34

4.2. Physical Configuration Model

The Physical Configuration Model was prepared as a reference model for designing entire

information system configurations, providing tangible system configurations of the two types of

systems—“network systems” and “common platform systems,” which were accepted as realistic

models in the government and will be frequently referenced to in actual government procurement

processes.

Note that the Physical Configuration Model, represented in the diagrams below, should be used as

a configuration example. Therefore, it is not required to install individual physical devices or

equipment corresponding to the functions shown in the model: more than one functional element

could be realized by a single device, or some functional elements could be fulfilled by existing devices.

Items to be procured — systems or devices — should be determined by taking into consideration all

factors of the individual project, such as requirements of optimization or utilization of existing

resources.

Of the Physical Configuration Model, the Network Physical Configuration Model provides the entire

model-structure of networks used inside government ministries or agencies, and the Common

Platform System Physical Configuration model provides the basic model-structure common to the

servers on the Network Physical Configuration Model.

The Network Physical Configuration Model is based on the outputs of the 4th working group

(information security) of the Liaison Conference of Deputy CIOs, etc, providing the six model

segments of the internal network of the ministries and agencies — S1 to S6 — created through the

analysis of the information system optimization plans by the ministries and agencies, where the

segments S1, S2, S3, S4, S5, and S6 respectively correspond to DMZ, intranet servers, the central

government LAN, outside-the-central-government servers, network, and information remote-access /

extraction.

35

Figure 4.2-1: Physical Configuration model of Network

The Common Platform System Physical Configuration Model was created from the stand point of

servers in the ministries and agencies, providing the structural model, where common platform

system basic functions are fundamental functions commonly used in the ministries and agencies,

including the following: network access, user registration / authentication, common database

management (optional), API or protocols for individual business applications, linkage to other

systems (optional), common security infrastructure, system operation / maintenance infrastructure,

common applications (optional), common public portal (optional), common repository, and others

(“optional” indicates that the function is selectively required).

36

Figure 4.2-2: Physical Configuration Model of Common Infrastructure

37

4.3. Categorization of Service-Work

While, in the case of procurement of goods, the technology domains in the Functional

Configuration Model —defined with a focus on the procurement of gods, —is well-applicable, in the

case of procurement of service, a categorization according to the procurement phases of information

systems would be easier to understand and apply. Procurement of services starts with the planning

phase, and proceeds to the requirement definition phase, the development phase, and the system

operation / maintenance phase. Major categories of service-work are shown in Figure 4.3-1 in relation

with the phases of procurement. Refer to the Ch.6 for the details of service-work and the essential

points to be described in procurement specifications.

Figure 4.3-1: Categorization of Procurement of Service

6.2 （等）


6.2 - 1 調達支援


6.4 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


38

The system development phase consists of the sub-phases — design, development, test, and

system-migration — and is followed by the system-operation / maintenance phase. Note that the

following are included in the category of system development: development from scratch (new

development); renewal of existing systems (system renewal); system migration required for renewing

hardware (hardware renewal); and addition of sub-systems for augmenting functions (functional

augmentation). Also note that application maintenance, in some cases, includes partial modifications

of existing applications. For details, refer to the Figure 4.3-2 for the relationship of maintenance

service-work to the categorization of the system development service-work (design / development).

Also, note that the procurement of service-work requiring design work (basic design or detailed

design), and the procurement of service-work (including correction of design documents) requiring no

design work are respectively categorized into the Section 6.3 System Integration (Design /

Development), and in Subsection 6.6.3 Application Maintenance of Section 6.3 Maintenance. Refer

to the Ch.6 for description in detail.

<Maintenance>

Application Maintenance

<Maintenance>

Application Maintenance

Design Development / Test / System MigrationMaintenance

(Scheduled Maintenance / Inspection)

■New Development■System Renewal■Hardware Renewal■Sub-system-level Functional Augmentation

Attributes of Service Service Items

<Design / Development in System Integration>New DevelopmentSystem RenewalHardware RenewalFunctional Augmentation

■Modification (Correction, Functional Augmentation, Bug-fixing)

■Procurement of Application Maintenance requiring no development work

Including Defect-warranty work

Including Defect-warranty work(Design Correction)

■Maintenance of others <Maintenance> Hardware Maintenance,Software Maintenance,System Infrastructure Maintenance

Including Defect-warranty work

Figure 4.3-2 Mapping of Application Maintenance on Categorization Chart of Design /Development

39

The Figure 4.3-3 shows the mapping of the categories of service work on the Functional

Configuration Model for Procurement of Service, suggesting the following: as for the development

phase, almost all the services in the Functional Configuration Model are categorized in system

integration, compared with the procurement of networks or incidental work to iDC equipment

categorized as individual services. As for the procurement of server or storage, design / integration

are contained in the category of system integration, and implementation / installment is categorized

as an incidental work to procurement of goods. System operation / maintenance are procured in the

system-operation / maintenance phase. Note that, in the Figure 4.3-3, the planning phase or the

requirement definition phase is not shown.

6.7 機器調達付帯作業

6.8 iDC設備調達付帯作業

6.9 Network procurement

6.4 Operation

6.6 Maintenance


6.3 System construction

6.8 Tasks incidental

to procurement

of iDCequipment

6.9 Network procurement6.3 System construction

Figure4.3-3 Mapping of Services on the Functional Configuration Model for Procurement of Service

40

4.4. Policies for Defining Business Application

The applications in the Functional Configuration Model are defined according to the Job-Operation

Manual— the individual job-operations are defined in “application” and the common-job operations

are defined in “common platform,” respectively. However, as for common job-operations, the different

types of descriptions are generally used according to the following three cases:

A: Specific job-operations belonging to higher job operation layers such as electronic payment;

B: System functions provided by the common platform system such as BPM or BI;

C: The lower common-services used by the higher services defined in the SOA.

Generally, defining the boundaries of common jobs and individual jobs — more specifically,

extracting common job-operations from entire job-operations— is not easy. However, in the case of A,

because the functions are defined more clearly compared with other cases, definitions or extractions

as mentioned are easily accomplished by defining interfaces to and from individual job-operations

through clarifying the scope of the job-operations, functions and requirements.

As for B, the difficulty comes from the lack of consensus or clear image of the functiond provided by

the common platform system. This Technical Reference Manual is expected to solve this difficulty

through sharing knowledge of the functions provided by the common platform system. If the common

platform is used for the purpose of running applications on the common platform, it is indispensable to

have attitude to use various functions proactively; through the utilization of the common platform

system, it is expected to reduce the volume of development, risk and cost of the project, or

maintenance cost of application.

As for C, the degree of difficulty depends largely on the service granularity described in the SOA or

how the common job-operation is extracted and defined. Because widespread of SOA concepts and

related technologies such as SaaS are insufficient and the applications still remain in transitional

stages, the difficulty requires time to be resolved. Therefore, especially for C, it is recommended to

treat the category as one of the step-wise approaches described later, and at the first step, procure

individual systems closed to individual job-operations from the developers of individual job-operation

systems instead of procuring the common platform system from the developer of such common

platform systems.

In the following sub-sections, policies of application-system development of job-operations are

described.

4.4.1. Stepwise Approach and Redefinition of the Entire System Architecture

41

The Stepwise approach is one of the critical methods of the system configuration-design of

common job-operations, especially for category C described in the previous sub-section: because

when a project's scale is large and a long-term “waterfall-model” development approach should be

applied, the coverage, functions, and strictly-defined requirements are required to be completed prior

to the development, job-operation analysis including BPR, and “ToBe” type breakdown of business

processes from the highest concept to detailed processes is prerequisite — thoughtless acceptance

of the existing job-operation flows, or simple copy-paste of the existing displays would result in a

re-building of old legacy systems.

However, in many cases, such an approach like that described above is not easy to apply because

of a shortage of skills and experiences on either the procurer or provider side, especially in today’s

situation where the SOA or its related technologies such as SaaS are not proliferated and widely

accepted.

Therefore, a practical way is recommended as follows: first of all, squeeze the scale of a project

suspected to be a long-term-waterfall type, and then apply a stepwise-development approach.

For squeezing the scale of project, the following two approaches, except for cutting-down the

system coverage or reducing job-operation functions are generally applicable:

The first is division of project — dividing a project into reasonable pieces satisfying time and cost

conditions, where the job-operations are allocated to sub-systems that are loosely coupled by EAI or

some other similar methods: also, division into sub-systems is accomplished so that an integrated DB

based on DOA (data center) is placed at the center around which applications are placed. The

approach requires redefinition and reconstruction of the entire architecture. Note that the approach

will not produce a simple division of procurement in accordance with the structure of the existing

sub-systems.

The second is the application of package-products described later which will drastically reduce the

volume of development, where division of project and fundamental reduction of development-volume

should be simultaneously considered. Note that the clear definition of the entire architecture is

indispensable as a prerequisite of such considerations.

As described above, the project-scale squeeze and the development-volume reduction will make

up the application of the stepwise approach. The stepwise approach will desirably proceed along the

steps as follows: at the early stage, construct the system on the basis of services of large granularity

connected loosely by an EAI-like method; then, divide each service into services of smaller

granularity step-by-step; and finally specify common services.

Note that the stepwise approach should desirably be applied incrementally to a single flow of

design to system-operation, and cyclically over a long period.

The stepwise approach should be realized through the formulation of the entire architecture at first,

followed by proof-of-concept experiments or prototyping of the common platform system and pilot

job-operations, executed in the following processes or in the combinations of processes:

• Persons procurers, execute in the planning phase following the advices made by Deputy CIO;

42

• Contracted service provider executes architecture formulation, proof-of-concept experiments, and

prototyping;

• Contracted system providers execute in the “confirmation of basic requirements” work.

Through the processes in the stepwise approach, the systems are incrementally implemented, and

at the same time maintenance and restructuring of the entire architecture are necessary. This

Technical Reference Model is expected to support the formulation of the entire architecture and

smooth execution of subsequent work.

4.4.2. Fundamental Reduction of Development Volume through Employment of Packaged Products

Some of the computer systems used in public sectors, developed in the early days of computing,

still continue to use the architectures of those days.

Packaged software applicable to job-operations requiring no customization would be perfect for

fundamentally reducing system development volume. Although those applicable to the job-operations

in the ministries and agencies are rare, some of general-purpose packaged software products,

middleware products, and internet technologies will be applicable.

Therefore, although the best is to find and employ packaged products just-fit to the objective

job-operations, the application of packaged products, even if best-fit packaged products were not

available, could fairly reduce the development volume in some cases like those described below:

• CRM products: Case Management

CRM products are used in businesses for comprehensively managing customers — attributes,

sales-history, sales-promotion-history, conversations, and support-history including response to

complaints.

CRM software products will be applicable to the government job-operations requiring case

management to individually support citizens and private businesses, such as tax-related jobs or

health-insurance-related jobs: CRM products are expected to serve there as engines.

• Spreadsheet: Ledger Management

In job-operations requiring management of ledgers, spreadsheets will be desirably used for

creating electronic images of ledgers. In cases where the ledgers are shared among job-operators, or

large sheets exceeding the capacity of spreadsheet are used, RDBs on the back-end linked by SQL

or web-services to the front-end spreadsheets will serve well. Also, middleware software is applicable

there.

• BI tools: Reference / Search, Outputting in forms, and Statistical Processing

43

BI tools will be successfully applied to data reference / search / analysis, and printing-data-in-forms,

and drastically reduce development volume in case management, ledger-management, or in other

systems. Especially for statistical analysis jobs, the data-mining functions of BI tools are highly useful.

• RIA Technologies: Screen-handling Programs

In the screen-handling programs used in mainframes, due to various technical constraints, the

volume of information displayed on a screen is limited: job-operation screens were divided into pieces,

and the operators had to execute jobs through complicated job menus for the computer-system-side

convenience. Also, as for C / S based job-systems, it was a concern that as a consequence of an

easy transfer of C / S to Web, the user friendliness which the originals have had would be lost, or the

volume of information on a screen would be limited due to the limitation posed by the features of the

browsers used for screens.

Recently, RIA technologies such as Ajax enable web-based systems to provide user-friendliness

and sufficient information on screen: through the use of such technologies, the following is expected:

reduction of the number of screens and development volume; improvement of user-operability,

job-operation-efficiency, and user-satisfaction; and reduction of maintenance / training cost.

Moreover, because having superior functionality for linkage to services on the internet, the RIA

technologies are effectively applied to low-cost-use of information on the internet such as map

information or bibliographic information.

• PC Packages with SOAP Interface: Screens

One of the integration methods of job-operation systems using SOA is as follows: the servers

provide various types of functions usable as Web-services, and PC packages with SOAP interfaces

use the Web-services as the users of services. The approach will be effective for providing flexible

screens satisfying individual user requirements — with smaller development man-hours.

The PC software products for the above-described purpose are supposed to be the following:

software packages for OA such as spreadsheet-software; mailers; and dedicated products to the

job-operations. On the other hand, the Web-services on servers will be implemented in the following

ways: applying the products whose functions are usable as a web-service based on SOA; or

augmenting the existing systems by adding Web-service interfaces.

• BPM and Integrated Directory: Workflow Management of decision-making processes

Workflow management of decision-making processes is a mechanism for the management of

decision-making processes called “Ringi” where more than one decision maker sequentially reviews

and approves a circulated decision-request. In workflow management, in such processes,

44

considerable work is spent on the preparation of information necessary for decision-makers or the

arrangement and management of circulation routes. Utilization of BPM products available on the

common platform system and the integrated directory available on networks will be one of the

effective alternatives to specialized products for workflow management.

• Service-Reuse: BPM products and ESB Products

In cases where service-reuse is required, the utilization of BPM products or ESB products should

be considered first. One of the reasons that service-reuse is difficult in conventional application

systems is that how functions are combined or what branching conditions change the course of

processes is coded in the programs or JCLs. On the other hand, the utilization of functional services

through BPM products or ESB products is expected to promote the reuse, and as a result the

business applications are expected to become more flexible and more maintainable.

The concept of service-orientation — the base of SOA — puts more emphasis on reusability than

on system-development. Job-operation models, job-flow models, and common / standard functions

based on the concept of usability are becoming available, of which the application can be expected to

largely reduce the risk and the volume of development.

• Utilization of Cloud Services

The functions so far described will realistically be realized by cloud services in addition to the

utilization of packaged products (reference to “4.8: Standpoints of Cloud Users” for the utilization of

cloud services, and “4.9: Standpoints of Cloud Designers” is recommended.)

Because cloud services are expected to rapidly expand from those that have been described so far

and those currently available on the public cloud such as CRM, Spreadsheet, BI, and Groupware,

application of cloud services should be considered in every project in future.

Although the employment of cloud services has potential advantages such as low-initial

development cost, short lead-time, flexibility to increase / decrease of the operational requirements,

smaller operational work-load, or low energy consumption, assessments on the following should be

made before the decision of employment of cloud services: availability of services; institutional

constraints; security and BCP; and SLA. List and confirm the critical items of the service level

agreement (availability, reliability, data management, and security). Also note the following: the

application of cloud services still remains in its early stage, and the number of domestic applications

is still small; they will be procured by procurement-of-service, instead of procurement-of-goods; and

procurement of cloud services, especially public cloud services, will possibly lead to another

vendor-lock-in — narrowing the selection of vendors —, because market-availability is still small.

4.4.3. Requirement-Definition in the Application of Packaged Products, etc.

45

The easy duplication of requirements of the existing systems without re-evaluating the necessity, or

simple acceptance of the requirements by job-operators leads, in many cases, to a situation where

the application of packaged products is difficult and the estimated development-volume remains

large.

To avoid such situations, hold, as a goal, the application of packaged products and keep the policy

of satisfying the true job-requirements through the application of packaged products.

The design method strongly recommended is the following: at the early stage where the packaged

products to be used are not yet determined, design the system based on the generally available

functions referring to Ch. 5 of this Technical Reference Model and others, and after determining which

packaged products to use, review, make adjustments, and finalize the design.

4.4.4. Review Process in Stepwise Approach

The stepwise approach, in addition to the advantages in reduction of project-risk or development

volume, will greatly contribute to the implementation of a high-user-satisfactory system.

In the conventional waterfall-model approach, as a matter of practice, modification of design or

implementation following the users’ comments in a timely manner is not easy: request for comments

on the system design collects no responses because the users could not imagine how the systems

will be used in the actual job situation of them, and users return comments or complaints back just

after the implementation is completed when they touch the system; and those comments given in the

final phase are often not reflected in the system because such reflection would roll-back the project,

or even put the project into confusion.

In the stepwise approach, review of the actual system is strongly recommended in the design

phase: primary functions and screens, not necessarily all, are implemented in the design phase;

users are requested to operate the system and make comments; and those functions and screens

are modified to satisfy the users; and the rest of functions and screens are determined sequentially.

The review-on-the-system, described above, is largely expected to contribute, not only to

user-satisfaction, but to reduction of roll-back in the final stage and avoidance of project-risk, and

reduction of development-volume or promotion of packaged-product-application as a result of these

efforts to make the reviews easy.

46

4.5. Policies for Common Databases

On the reconstruction to a large extent of systems towards total optimization, data-review is also

indispensable: reviewing locally-optimized databases and then constructing the totally-optimized

common database (hereinafter referred to as a “common DB”) is expected to, through the

rationalization of the entire system, to contribute not only to the cost-reduction, but also to high-level

administrative work and the provision of services to citizens.

4.5.1 Definition and Realization of the Common DB

The following three types of databases orienting the common DB have been under consideration in

forward-thinking ministries and agencies:

Common DB as total optimization: optimized DB used by the whole government;

Common DB as core: DB used as a core of primary jobs of specific ministries;

Common DB for reference: DB widely-used for referencing the data related to specific jobs of

specific ministries.

The common DB as total optimization is expected to collectively store the fundamental data of

private businesses or citizens. For private businesses, total-optimization focusing on the corporate

financial / tax information data based on commercial-registration data is required, and for citizens,

optimization — spanning ministries, and local governments — focusing on the data on the Basic

Resident Register based on the census register is required. Because there are many problems of

concern due to a large number of stakeholders, big influence, and protection of personal information,

the common DB as total optimization is out of the scope of this document.

The common DB as core — well expected to be used for patent administration in the Japan Patent

Office — is expected to be an essential database for specific ministries and agencies required to do

particular jobs. However, the target ministries and agencies are limited.

The common DB for reference — well expected to be used for statistical analysis, etc. — is desired

to be planned or implemented in many ministries and agencies.

Although, whether the preparation of the Common DB is treated as an individual job or as a

common job is dependent on the decisions of the ministries and agencies, an architecture covering

the entire system that minimizes the overlaps over more than one job-operation. At the same time, a

common data base, even when implemented for the purpose of particular ministries and agencies, is

desired to be implemented in such a way that interfaces compatible with open standards for the

public access or referential access are prepared.

Note that such data as that expected to be prepared in particular common business system for

Ministries — personnel and payment, document management — is out of the scope of this document.

47

4.5.2. Policies for Job-Operation System-Implementation using Common DB

Systems using common DBs should be designed and implemented on the basis of software

products such as BI or CRM. Even implemented from scratch or add-on — customizing such

products and adding on the system, those systems should be designed so that, in accordance with

the concept of DOA, applications surrounding the database placed in the center of those applications,

use the database, instead of the data embedded and confined in applications.

Also, the systems should be designed so that processes related to data modification and

processes related to data reference are separated, for purpose of wide data-sharing. Especially in

cases where the SOA is applied, processes (services) related to data modification should be able to

provide the modified data as a service provider to allow the processes (services) related to data

reference to use the data as a service consumer: such service-functions such as providing and

referencing data will promote not only wide-sharing of common DBs, but system reuse.

4.5.3. Responsibility Sharing among Integration Service Providers on Common DB

As a general rule, physical design / implementation of common DBs is the responsibility of the

providers of common platform systems, and logical DB design / implementation is the responsibility of

the providers of individual job-operation systems.

However, note that in cases where construction of common DBs is treated as a common work

instead of independent work, the provider of common platform system will be responsible for

everything, because the provider does the work of DB logical design / implementation.

Note that system operation / maintenance is allowed to be assigned to the provider that did the

design / implementation work.

4.5.4. Stepwise Approach in Common DB Planning / Implementation

As for the common DB planning / Implementation, it is strongly recommended to apply the stepwise

approach — proof-of-concept experiment, implementation of parts of systems, and implementation of

the entire system.

Also in the early stages of the stepwise approach, it is recommended to arrange the development

structure so that the provider assigned to the logical design / implementation takes the responsibility

of physical design / implementation: it will improve the efficiency of work.

Note that individual DB-implementation will easily lead to problems such as inflation of

maintenance costs and troubles when the system is required to expand: it is desirable to consider as

seriously as possible the application of DBs that are widely shared.

48

4.6. Policies for Implementing Common Business System for Ministries

One of the purposes of common business system for Ministries is total optimization — optimizing

the government systems as a whole beyond the boundaries of ministries. Therefore, common

business system for Ministries must be visibly effective in reducing and streamlining

ministry-dedicated systems.

4.6.1. Policies for Connecting with Ministry-dedicated Systems

Common business system for Ministries should connect with ministry-dedicated systems through

interfaces that are as simple and as loose as possible, because common business system for

Ministries linked to other various systems, should be as immune as possible to the changes in those

systems, as generally required in system connections. For such loose connections, use interfaces

that are prepared by the common business system for Ministries, and do not implement unique

interfaces unless strongly required for some special reasons.

Workflow, authentication infrastructure, and other common functions prepared by the common

business system for Ministries should be proactively used, because such functions will be a

considered as a part of common job-operations. However, note that employment of such common

functions does not always result in the elimination of the necessity of ministry-dedicated

implementation of the functions. Ministry-dedicated systems are not only required tentatively and

temporally in the case of stepwise implementation / deployment, but required in the case of a

To-Be-model to satisfy particular requirements of ministries, where the simple and individual

implementation of ministry-dedicated systems would be more realistic than the complicated

application of common business system for Ministries. Note, therefore, that in any case, the decision

of individual implementation should be done after sufficient consideration and assessment.

4.6.2. More Total-optimization-oriented Implementation Approach

In implementing common business system for Ministries, arrangement and planning from the

standpoint of total optimization is strongly recommended even though implementation and migration

of common business system for Ministries is often planned on system-by-system basis, because

common business system for Ministries have mutual dependency in such functions as authentication,

workflow, and employee information.

In such total arrangement and planning, the following are included as major issues: deployment

schedule; data migration; and linkage to existing systems. In addition, covering existing systems and

also systems in the planning phase, arrangement and planning on the following is strongly

recommended: directory information, authentication, and character code including extended codes

49

4.7. Virtualization Technologies

Virtualization masks boundaries or physical features of IT resources by inserting a virtual layer

between a resource and a resource-user (OS or application) to enable flexible use of resources

(Figure 4.7-1) which originated in the technologies developed to improve the hardware utilization

efficiency in 1960s, Virtualization has recently been gathering attention as one of the solutions for IT

problems such as utilization-efficiency-decrease and cost-increase in infrastructure, cost-increase in

IT management, and increase in energy consumption. Section 4.7 provides policies for virtualization

where the IT resource is hardware, and the user is an OS (refer to *1). Note that there are two types

of virtualization mechanisms: realized by hardware for virtualization; and realized by software for

virtualization.

Hardware (Server, Storage, Network and others)

OS, Middleware

Application

Virtual Layer

Virtual Layer (*1)

Figure 4.7-1: Conceptual Diagram of Virtualization

4.7.1. Policies for Application of Virtualization Technologies

Virtualization technologies can enable improvement of the efficiency in IT resource utilization. Also,

hardware virtualization expectedly reduces footprint and power consumption, and in addition,

increases system flexibility that leads to a reduction in system-operation and management work load.

However, note that virtualization could increase system overhead, or in case of the virtualization of

existing systems, migration may sometimes require modifications of application programs.

4.7.2. Types of Virtualization ・ Server Virtualization

In one type of virtualization, more than one virtual server shares one physical server, and in another

type, one virtual server runs on more than one physical server utilizing all the power. This sub-section

describes the former, because it will be more realistic in the actual procurement. Server-virtualization

software products enable construction on a physical server of more than one virtual server running

independently by an independent OS. Virtual Machine Monitor (VMM) is one of such products,

50

providing independent virtual servers (virtual machine) through hardware simulation, — in some

cases the virtual server is called a “guest server,” and the OS on a virtual server is called the “guest

OS.” VMM software products are generally categorized by host-type VMM and hypervisor-type VMM,

which are shown in the Figure 4.7-2.

Host-type VMM

Hardware

Host OS

Application Application

Application

Application Application Management Tool

Guest OS Guest OS

Guest OS Guest OS Management OS

Virtual Machine Virtual Machine

Virtual Machine Virtual Machine Virtual Machine

Hardware

Hypervisor-type VMM

Host-type VMM Hypervisor-type VMM

Figure 4.7-2 Two Types of Server Virtualization

・ Storage Virtualization Various types of storage virtualizations are available: in “dividing storage,” one storage device such

as a hard-disk drive has more than one virtual storage; in “storage consolidation,” more than one

physical storage is consolidated into a huge virtual storage; and in “storage-capacity virtualization,”

the storage-capacity that a server will know, is not limited by the physical capacity. Note that by

storage-consolidation more than one physical server can be consolidated beyond the boundaries of

its chassis, in comparison with the storage device consolidation enabled by RAID.

・ Network Virtualization “VLAN” is a virtual network independent of physical connections, enabling terminal-grouping.

Another is “network device virtualization,” where a physical device such as a router, switch, firewall,

or load balancer works as more than one independent device, or more than one device is

consolidated to work as a single device.

・ Desktop Virtualization Desktop virtualization is a screen-transfer-type thin-client technology where the server processes

applications or saves data, and the client handles input / output devices such as a keyboard or mouse.

As shown in the Figure 4.7-3, screen-transfer is realized by server-based-computing, a blade-PC, or

a virtual PC (VDI). In the virtual PC scheme, more than one virtual client machine is composed on a

physical server where OSs or applications belonging to virtual machines are running.

51

Desktop AP

Desktop AP

Desktop AP

Desktop AP

Desktop AP

Desktop AP

Desktop AP

Desktop AP

Desktop AP

Terminal Service

Server OS

Hypervisor

Virtual Machine

Virtual Machine

Virtual Machine

ClientOS

Client OS

ClientOS

ClientOS

ClientOS

ClientOS

Blade Hardware

Blade Hardware

Blade Hardware

Server-based-computing Blade-PC Virtual PC Figure 4.7-3: Three Schemes of Desktop Virtualization

4.7.3. Points to Consider in Integration by Virtualization The following are points to consider in system-integration by applying virtualization technologies:

・ Design and assessment should be done for each unit of virtualized-resource allocation, physical resource, and resource-pool, instead of conventional hardware- resource sizing;

・ Consider application, in the virtualized layer, of an N-to-N model covering the entire resource-pool for the server-availability requirement, instead of the conventional design based

on one-to-one or N-to-one model in hardware layer;

・ Consider monitoring and security of the management-layer of the hypervisor, virtualized server, and cloud, in addition to the conventional system design;

・ Pay attention to the possible performance-degradation, invisibility of resources from the management side (difficult to view), and resource-conflicts in multi-tenant environments;

・ Confirm the compatibility of the hardware products planned to be procured with the virtualization scheme to be employed;

・ Confirm the compatibility of the software (program) products planned to be procured with the virtualization scheme to be employed;

・ Note that there is a possibility, in the migration phase to the virtualized system, that the virtually realized functions — especially those related to device drivers — do not work in the same way as

the originals.

・ Prepare migration plans (of sizing, verification, data-migration, and others) for the migration from physical environments.

52

4.8. Standpoints of Cloud Users

“Cloud” generally refers to an information processing mechanism using networks through which

information-services are provided or used on demand, which should be treated from the following two

standpoints: users' standpoints that a cloud is an environment through which information services are

provided to be consumed by users; and service-providers' standpoints that a cloud is a tool

implemented by providers to deliver services. This section describes the points that cloud users

should remember from the standpoints of users — who use services delivered through the cloud.

4.8.1. Basic Policies for Selecting Cloud Services Clouds, which could be categorized in many ways, are basically, according to the user-acceptance

policy, categorized into the following two: a public cloud constructed on the internet and providing

services on the assumption that it is accessible by the general public; and a private cloud providing

services constructed on the assumption that it is accessible only by specific users. Note that a cloud

closed to a “community” formed by users having common objectives is called a community cloud,

which can be categorized in between those mentioned above.

This section describes policies for selecting service-delivery mechanisms among the following:

commercial public clouds by private providers; the ministry clouds, closed in a ministry and agency;

community clouds such as the government common platform, shared by ministries and agencies; and

on-premise, a conventional service-delivery not categorized in clouds.

Note that, for classifying clouds, except for the categorization by openness mentioned above, the

following categorizations by what is delivered as a service is helpful: SaaS (Software as a Service),

where services are delivered to applications; PaaS (Platform as a Service), where services are

delivered to a platform (on which applications run); and IaaS (Infrastructure as a Service), where

services are delivered to an infrastructure (hardware or iDC).

Figure 4.8-1 shows the categorization of clouds along two axes; assumed users of services, and

provided services. Note here that, because combination of clouds, such as “hybrid” (combination of

different services) or “multi” (combination of services from different providers) can be allowable,

assessments matching the usage or purposes will be necessary.

53

Public Cloud Community Cloud Private Cloud

SaaS Commercial Service Providing Web-mail Related FunctionsCommercial Service Providing CRM Related Functions, etc.

Government Common Platform

Local Government Cloud (Local Government ASP)

Ministry Cloud (Common Job-operation)

PaaS Commercial Service Providing Business Application Environments


Local Government Cloud (Shared Service-Center)

Ministry Cloud

IaaS Commercial Service providing Infrastructures


Local Government Cloud (Shared Service-Center)

Ministry Cloud

On-premise

Business Application

Infrastructure

Figure 4.8-1 Categorization and example of clouds

Generally, clouds will contribute to cost reduction because of its scale merit, application of

virtualization technologies, and on-demand-based charging. In the case of IaaS, improvement of the

hardware-use-efficiency by the application of virtualization technologies is expected to reduce cost,

compared to the cases of on-premise systems where the server-configuration is determined to

ensure the availability of individual application systems at the peak load — at an off-peak, plenty of

resources are not utilized. In the case of PaaS, in addition to the effects by IaaS, cost-reduction is

expected in system-operation / software-maintenance which can be eliminated by the employment of

PaaS. In the case of SaaS, in addition to the effects mentioned above, cost-reduction is expected in

the development / maintenance of business applications in the same way as expected in the

employment of job-packages. Although additional cost is required due to a lot of factors in the

deployment of cloud-based systems, reduced cost surpassing such additional cost is generally

expected.

On the other hand, for the individual systems using clouds, it is necessary to determine which type

of service-delivery (including on-premise) is best. The essential factors to take into consideration are

the following: cost, swiftness, data-linkage, service-menu, legal-constraints, and service-level. Note

that, in cases where the best cloud service is not ready-to-use, it is necessary to figure-out alternative

solutions through the assessment of those factors. Assessment policies of those factors are

described as follows:

54

- Cost

Generally, a public could is the lowest-cost option, followed by a community cloud, a private could,

and an on-premise system— the highest: a public could is advantageous in scale-merit and expected

to contribute to the total efficiency — the existing reasonable fee structures including a contract option,

which, especially in case of using IaaS, allows users to contract a minimum configuration for their

normal time with an option of adding resources in their peak time or busy seasons. In addition, even

in temporal use, a public cloud is expected to contribute to cost-reduction because of its reasonable

cost-structure: such features of a public cloud would be another advantage in cost-reduction.

Note that because fee structures, which fundamentally determine cost, are determined and

controlled by individual providers, in some cases they may be out of the scope of general

assumptions: especially in cases of community clouds or private clouds constructed by the fund of an

organization in charge of construction, in some cases, the fee structure does not match the actual

expense paid by user-organizations because the fee structure is determined by non-economic

reasons, and requires users to decide the use of the service from higher standpoints, taking into

account the discrepancies between the user optimum solutions and the total-optimum solutions.

Also note that users are required to make an assessment of the total cost because, in addition to

the fee, extra expenses will be required for additional work such as re-structuring job-operation

systems, the hybrid-type use or the multi-type use mentioned above, implementation /

system-migration, and additional security measures.

- Swiftness

The on-demand-feature is one of the advantageous features generally expected for cloud services

such as PaaS or IaaS — meaning that services become instantly available when demanded — in

comparison with the cases of conventional systems where such convenience has to be realized on

prefabricated menus of standardized features for infrastructures designed / implemented on

order-made basis. Such swiftness is generally expected in PaaS or IaaS, whether based on a public

cloud, a community cloud, or a private cloud. Note, though, that in the case of community clouds or

private clouds, such swiftness might not be attainable due to the lead time and procedures required

before the service becomes available, as long as those in the case of conventional on-premise

systems, or additional time might be required for analyzing how the cloud will be used because of the

lack of care for on-demand capability on the constructor side. In some cases because of the lack of

integrity in service menus, extra time is required for devising appropriate application measures and, in

extreme cases, a longer time than that in on-premise cases will be required where detailed

consideration and negotiations between cloud-service users and providers, which are

time-consuming when several organizations are involved.

Also note that in the case of SaaS, because of the necessity of job-operation restructuring and

consideration on a linkage mechanism to services, significant advantages / disadvantages are not

55

generally certain advantages are expected only when public-cloud based applications are employed

in small job-operations or some particular job-operations.

- Data-linkage

In a community cloud such as the Government Shared Platform System, the data-linkage capability

is significantly required: the data-linkage capability, considered as a function of PaaS, enables

secured and low-cost implementation of high-level data linkage among the systems belonging to the

community through common functions provided by the clouds.

Such capability is expected to produce the most powerful effect in community clouds: the

Government Shared Platform System, the following are expected: data linkage across the borders of

ministries and agencies, system-linkage among the common business system for Ministries, and

finally the system linkage between the individual ministry systems that share the common

government systems.

Although the data-linkage capability is also expected to produce effects in private clouds, the effect

will be limited inside ministries.

In public clouds or on-premise-based systems, where conventional data-linkage mechanisms are

required, the capability will not produce any particular effects.

- Service Menu

Service menus should be selected so that the system modifications that would be required for

transferring the existing systems to the systems using services or applications available on clouds will

be minimized. As for IaaS, in most cases, the transformation will be feasible if the menu includes the

OSs or DBMSs required by the existing systems, and as for PaaS, beyond OS or DBMS,

system-operation management or processing might be modified. So, when comparing IaaS and

PaaS from the point of system-transfer to cloud, IaaS is easier but the effects are smaller, and PaaS

is harder but the effects are larger.

On the other hand, in the case of implementing new systems on clouds, a feasibility study should

start with SaaS and proceed to PaaS instead of IaaS. Procurement specifications should be created

based on the standpoints of cloud-utilization because the utilization of cloud would be unattainable if

the procurement specifications were created based on on-premise systems, lacking the standpoints

of utilization of clouds.

Note that, in case of hybrid-type or multi-type use, attentions should seriously be paid on interface

design, emergency measures, and responsibility-divide including security issues, even if their

employment is desired when a clear plan for the utilization exists and the effects are well expected.

- Legal Constraints

56

Generally, a public cloud is most likely to be legally constrained, followed by a community cloud, a

private cloud and an on-premise system where handling legal constraints are easy. Note that issues

on legal constraints are dependent on providers. Refer for details to “4.8.2. Institutional Issues.”

- Security Constraints

Generally, a public cloud is the most severely constrained on the server / data storage locations for

the security requirements on data archiving, followed by a community cloud and a private cloud of

which situations are most close to those of on-premise systems. Also, because data and systems are

concentrated, a public cloud is the most severely constrained, followed by a community cloud, a

private cloud, and an on-premise system.

Note that, however, large-scale clouds would have advantages with regard to security technologies

or security-management operations because it could be easier to concentrate the expert skills and

knowledge, or monetary resources in a case of a large-scale cloud.

Also note that security constraints are highly dependent on individual providers. Refer to “4.8.10.

Security Issues,” and “6.12. Security.”

- Service Level

Generally, in cloud services, because the computer systems or facilities, etc. owned by the

providers systems and their situations of operations are not the easily visible from the user side,

users are always concerned about the ambiguity in the responsibility-divide as well as the risk of

service-down due to system faults. Therefore, the providers must prepare SLAs (Service Level

Agreement) which are used for confirmation of mutual — users and providers — understandings with

regard to the quality assurance standard for service functions, service coverage, or service quality.

Because the service level is largely dependent on the provider, it can be assumed that no essential

differences derived from the differences of the types of clouds (public, community, or private) exist in

SLAs. Refer to “4.8.3 Selecting Providers or Services.”

4.8.2. Institutional Issues Institutional issues should be taken care of when clouds are used. In this sub-section, the details in

relation to the following are described: “Location of Data,” “Relations to the Act on the Protection of

Personal Information,” “the Guidelines for Safety Management of Medical Information Systems,” “the

Guidelines for Information Disclosure of Safety and Reliability of ASP / SaaS,” “Issues on the

Copyright Act,” “Relations to e-Document Act” and “Foreign Exchange and Foreign Trade Act”

- Data locations

One of the problems when using a cloud is that users are unable to know where the data is stored:

57

the data may be stored in a place belonging to a foreign county, or it may be hopping from one

country to another, without staying in some place. Because data archiving is restricted legally by the

laws of the country where the data physically exists, the laws and regulations of the countries where

data is archived should be investigated. Note that some cloud-service providers do not disclose

where data is stored.

On the use of clouds, it is necessary to know where data is stored: if the data is stored in the United

States, the users should pay attentions on a risk that the data could be seized legally for investigation,

because, while the Electronic Communications Privacy Act (ECPA) prohibits the disclosure of

communications to investigative authorities without a search warrant, the PATRIOT Act gives more

power to the investigative authorities, and furthermore, users should know that, in some countries,

other countries even the internet is censored.

- Relations to the Act on Personal Information Protection Act

In Japan, the Act of the Protection of Personal Information, Article 22 stipulates as follows: “When a

business operator handling personal information entrusts an individual or a business operator with

the handling of personal data in whole or in part, it shall exercise necessary and appropriate

supervision over the trustee to ensure the security control of the entrusted personal data.” Article 23

stipulates that, except in some particular cases, business operators are not permitted to provide

personal data to a third party without obtaining the prior consent of the person. Also the Article 16

stipulates that business operators are not permitted to handle personal information about a person

without obtaining the prior consent of the person beyond the scope necessary for the achievement of

the Purpose of Utilization specified at the time of obtainment. On the other hand, there are no legal

constraints on the location of preserved personal information. As a conclusion, in Japan, preserving

personal information on servers provided by the third party including foreign business operators is

permitted insofar as the obligations such as supervision of subcontractors stipulated in the “Act on the

Protection of Personal Information” are fulfilled.

The EU directive prohibits moving personal information of inhabitants in EU to the third countries

that do not assure sufficient protection. The following eight countries are certified to have sufficient

protection (as of November 2010): Switzerland, Canada, Argentina, Bailiwick of Guernsey, the Isle of

Man, Isle of Jersey, Faroe Island, and Israel. Registered business operators in the United States are

admitted as eligible for handling personal information according to the safe harbor rules. Business

operators in Japan, in some cases, would be judged as ineligible for handling personal information.

- The Guidelines for Safety Management of Medical Information Systems, version 4.1

(Feburuary,2010)

Using data centers in foreign countries for SaaS is practically — in order to follow the guidelines —

difficult, because the guidelines require as follows: “The applications, platforms, servers, and

58

storages, etc. used for providing ASP / SaaS services must be placed at the locations within the

jurisdiction of domestic laws and regulations in order to promptly submit the documents required by

laws to the supervisory authorities.”

- The Guidelines for Information Disclosure of Safety / Reliability of ASP / SaaS

Since April 2008, the certification system based on the “Guidelines for Information Disclosure of

Safety / Reliability of ASP / SaaS” has been effective as the scheme of information disclosure on

safety / reliability of ASP / SaaS providers. Note that the certification systems would not effectively

work unless the providers were prohibited to start business without the certification, and the

certification system was acknowledged by both domestic and international providers. As a conclusion,

the certificate could be used as a criterion for selecting providers, depending on to what extent the

certification system is acknowledged.

- Issues related to the Copyright Act

Since the effectuation of the revised “Copyright Act” on January 2010, certain improvements have

been made, such as the curtailment of rights of reproduction for information search services and the

curtailment of rights of reproduction for information analysis.

However, providers have been expressing concern that some services permitted and provided in

other countries, could be judged illegal by domestic laws, such as holding copyrighted works in trust

by storage service. As for analyzing copyrighted works on clouds and providing the added value, the

providers are worried about the risk of being judged as committing an “indirect violation of providers’

rights.” Other services, such as recommendation services or thumbnails referencing multimedia

copyright protected works, could be judged illegal.

- Relations to the e-Document Act

Since the effectuation in April 2005 of “Act on Utilization of Telecommunications Technology in

Document Preservation, etc. Conducted by Private Business Operators, etc.” (Hereinafter referred to

as “e-Document Act”), preserved electromagnetic records in addition to written documents have

become legally acceptable in cases of about 250 laws. However, the e-Document Act does not care

much about preserving such documents in the servers of third parties, because the main concern of

the act is computerization of written documents.

As a consequence, some particular laws or regulations still put limitations on data-preservation

measures: “Ordinance Enforcement of the Installment Sale Act” stipulates that the books shall be

preserved in principle sales-offices, and the “Ordinance for Enforcement of the Corporate Tax Act”

stipulates that the books shall be preserved at the location of tax payment. Therefore, for the jobs

related to such laws, use of publicly available cloud services is limited.

59

- Foreign Exchange and Foreign Trade Act

The “Foreign Exchange and Foreign Trade Act” (hereinafter referred to as “Foreign Exchange Act”)

stipulates that in order not to undermine the maintenance of international peace and security, a

resident who intends to provide specific technology in the specified region, or to specific

non-residents / corporations, shall obtain a permission from the Minister of Economy, Trade and

Industry, and in Article 25, Paragraph 3, that as for the “electronic transactions designed to provide

the specified technologies to specified countries,” the permission shall be obtained. Therefore, as for

transmission of information from a location inside Japan to a server of a third party located in a

foreign country, transmission to a server located in a foreign country owned by the sender of

information with an intention of providing information to users in foreign countries, or transmission of

the outputs of computational processing by the server resources located inside Japan, the sender, in

some cases, will be required to obtain such a permission.

The specified technology mentioned above refers to a technology related to weapons of

mass-destruction such as nuclear weapons or conventional weapons. Note that many technologies

used for non-military purposes, such as cryptographic technologies, are included in the restricted

technologies, and require careful handling.

4.8.3. Selecting Providers and Services For utilizing clouds, providers of services should be selected through careful assessment. Points of

the assessment are described below for each of the following factors: “Server / Data locations,”

“Management of Multi-Tenants,” “Information Security Measures,” “Business Sustainability,”

“Services,” “SLA,” “Service Continuity,” “Service Cost,” “Continuity of System Environment in case of

Changing Providers,” and “Evidence of Data-erasing on Service Termination.”

- Server / Data Location

Note that while cloud-service providers who use servers and storages located at several distributed

sites in an integrated way for ensuring the availability of services do not always disclose the site

information, in recent examples, providers on the request of users — especially corporate users —

disclose the geographical information of servers preserving the data of the user concern. Make the

selection of providers taking such locations issues into account.

- Management of Multi-Tenants

Generally, except for a so-called “private cloud,” more than one corporation and business entity

share the same environment — it is called multi-tenant type of cloud usage. In such multi-tenant

environment, additional measures for security and availability will be required to enable such shared

60

use. In some cases where as high confidentiality as that of a private cloud is required, an IPsec VPN

based environment is employed. Therefore, attentions should be paid to what security services are

provided by what providers.

- Information Security Measures

Attentions should be paid to providers’ actions or attitudes to the ISM system (JIS Q27001: 2006,

ISO / IEC 27001: 2005) and the privacy-mark system of the Ministry of Economy, Trade and Industry,

what providers have a system to accept “audit of contractors as a part of internal control,” or instead

to provide reports compatible with “SAS70 (Statement on Auditing Standards No. 70,” or “Audit

Committee Report No.18 ‘Assessment of Control Risk of Entrusted business’ — Report 18 Audit — of

“The Japanese Institute of Certified Public Accountants.” Note that in addition Type II of SAS70 is an

important assessment reference because the compliance of providers’ job-operations to the laws and

regulations is assessed.

- Business Sustainability

Because, when using clouds, users have no other choices than leaving their business

infrastructures to providers’ hands, attentions should be paid to the healthiness of management

foundations of providers. Note that, in some cases where providers are based in foreign countries, of

which the information of business is difficult to obtain, special cares should be taken such as

requesting providers for confirmations before making the decision to use their services.

- Satisfiability of Functions

Note that, because specifications of the provided functions are out of the reach of users — users

just use those functions— a FIT / GAP analysis and preparation of counter measures to “GAPs” is

necessary before selecting services, to the same extent as required in the case of employing

packaged products.

- Satisfiability of SLA with the Requirement

Providers rarely agree on user specific SLAs, because providers are doing business with a wide

range of users. Furthermore, even SLAs prepared by major providers are only on the availability of

services, not including performance, back-up, recovery from service downs, or level of security. Note

that it is necessary to understand the service level of the services to be provided, make assessments

on the satisfiability, and request confirmations to the provider as much as possible if the satisfiability

is not clear, before finalizing a contract.

Also note that it is necessary to make assessments on a proposed service level according to

61

system needs and estimations on the utilization, and pay attention to the trade-offs — higher costs for

higher functions — between service levels and costs not easily accepting the general tendency that

services with higher service level obtain higher evaluations.

- Service Continuity

Note the necessity of requesting confirmations from the providers on the continuity of services

because services are prone to be updated for improvement by providers. Request the provider to

announce version-ups well in advance and to assure that the same services are available after the

version-ups.

- Service Cost

In many cases of cloud services charging system is based on the quantity of service provided.

However, continuously note the possibility of the charging system modification due to the economic

conditions or the situations in competition, and at the beginning of service, prepare for such

modifications of the charging system. Also note the necessity of cost evaluation — focusing on

whether or not using cloud service will contribute to cost reduction — from the standpoint of total

life-cycle cost.

- Continuity of System Environments in case of Changing Providers

Note the necessity of the study in advance on whether the development-environment, the

development tools, or the data in use are transferable to another provider’s environment: especially,

in the case of SaaS, confirmations are necessary on whether the data in use is downloadable in a

ready-to use manner the data structure preserved.

- Evidence of Data-erasing on Service Termination

At the termination of service, the data in use must be saved and eliminated from the system

completely — to the extent that recovery is impossible — destroyed, not just erased. Note the

necessity of requiring a report certifying the completion of the elimination of data, especially for highly

classified data.

4.8.4 Points of Procurement and Contract In this sub-section, several points that need attentions in procurement or contract of cloud services

are described from the following standpoints: “Click-wrap Contract,” “Application of

Separation-of-Procurement Policy (Procurement Standards),” “Avoidance of Provider-lock-in,” and

“Preservation of Interoperability.”

62

- Click-wrap Contract (shrink-wrap contract)

Note that in some cases, subscription of cloud services is contracted by the click-wrap style—

similar to the shrink-wrap contract in the case of packaged software products — where the click on

the agreement document is deemed as the consent to the subscription. Although the validity of such

contracts is not clear in Japan — in the U. S. there is a judicial precedence supporting the validity of a

shrink-wrap contract, but none as for a click-wrap contract — , much attention should be put on

contracting procedures in the case of click-wrap.

- Application of Separation-of-Procurement Policy (Procurement Standard)

The policy recommends separation of procurement for applications or system infrastructures.

However, in the case of cloud services, the situation is different in the following ways: in case of SaaS,

because only services are procured, there are no procured objects that the policy may care about; in

the case of developing applications on PaaS, because details of the development depend on

providers, it is difficult to obtain estimations on applications before the selection of provider; and in the

case of making assessments on IaaS as a development base, because applications are to be

developed on the IaaS development base — estimations on applications is inseparable from that of

IaaS — decisions of use of IaaS should be done before procuring applications.

Furthermore, there exists a case where more than one provider is involved that provides SaaS

services on IaaS or PaaS. In such a case, it is essential to make the responsibility boundaries of

providers clear between IaaS / PaaS and SaaS.

- Avoidance of Provider-lock-in

In the government procurement system, a service is procured on a fixed term basis, and on the

expiration of the term, the contract is renewed through another competitive bidding for the purpose of

giving a chance of entry to all providers: it means that the service may be transferred to another

service provider. Therefore, it is critical to ensure a smooth transfer of service and data, especially in

case of PaaS, because the applications developed in the former environment may not work well in

the next environment, and in case of SaaS the smooth transfer of data is essential.

- Preserving Interoperability

In cases where the interoperability with other systems is required, a to-full-extent investigation of the

service on its interoperability is indispensable. Also note that an extensive investigation on the

possible problems on the service level or security level is necessary.

63

4.9. Standpoints of Cloud Integration

This section describes the essential points from the view of the cloud integrator— a person in

charge of the integration on the procurer side or an integrator on the provider side. The two different

standpoints are useful to each other and share the same objective of providing cloud services in cloud

procurement / integration.

Because most of the clouds to be implemented in the ministries or agencies can be classified in the

category of private cloud, the descriptions in this section are based on the assumption that the cloud

is a private cloud. Moreover, the descriptions will help , procurers or integrators on the provider sides

when they prepare for the cases where the cloud is to be shared by more than one ministry or agency

— community cloud, or to be composed of multiple clouds — hybrid cloud.

4.9.1. Components of Cloud Clouds consist of a variety of components, of which types and product-implementations are

dependent on the service type of the clouds — SaaS, PaaS, and IaaS. In the generally available

cloud, a “resource pool” preserves IT resources such as hardware and software available to users on

an on demand-basis: those resources are provided to users as information services on a network

through the “network infrastructure” and “operation / management infrastructure.” Note that with

regard to SaaS and PaaS, detailed element-by-element consideration or design are required.— for

example, what types of software resources such as application-software provided as a job-service,

operational environment for applications, or database, should be prepared, and how many of them

should be implemented and stored in the resource pool.

- IT Resource

Servers and storages are the basic components of a cloud. In clouds, through the application of

virtual technologies, physical components such as servers and storages are generally virtualized:

those virtual servers execute information processing jobs in collaboration with the virtual storages

composed of physical devices such as internal disk-drives embedded in physical servers or

independent disk-drives.

- Network Infrastructure

The major function of network infrastructures is the provision of LAN functions inside the cloud

system and connection-interfaces to external networks. NAS / SAN working for the high-speed and

large-capacity data-transmission between servers and storages is one of the major components of

network infrastructures. Through the application of virtualization technologies to networks, a

virtualized network such as VLAN is available. Note that, in some cases, specialized network

64

functions, such as load-balancing or SSL acceleration, are treated as an IT resource and stored in a

resource-pool.

- Operation-Management Infrastructure

Operation-management infrastructures provide cloud-specific monitor / control functions similar to

the monitor / control functions common to conventional systems. In a cloud, the application of

virtualization or automation technologies has made the execution / management functions for

dynamic provisioning and deployment indispensable. Except for those, the operation-management

infrastructures work for user ID / security management, provide user-interfaces such as

service-menus or management-portals, and manage SLA.

The Figure 4.9-1 shows an example of how the conventional system shown in the Figure 4.2-1 is

constructed through the application of cloud-resources, where some of conventional components

have been replaced by cloud-services. In the figure, the servers inside the round rectangles are

realized by the application of cloud resources. Note that a group of servers distributed in different

segments are realized through the application of cloud services. The purpose of the figure is to

illustrate how the components are connected by networks, so the details of network infrastructure or

operation-management are not shown.

Figure 4.9-1 Example of Cloud-Resource Application

65

4.9.2. Service Menu Service menus, in the case of clouds, list the standard services prepared by providers for users,

aiming for prompt and stable provision of services: in some cases, the service menu includes options

for a specific service or options applicable for the entire menu.

Basically, the service should desirably consist of a limited number of standardized functions —

even though modifiable to some extent by options — and what the service provides to users should

be clearly described in the menu: providing services in such a way as described above would lead to

the uniformity of service — similar kind of services provides similar level of functions — and

contribute to the efficient use of resources or improvement of service quality. It is worth adding that

automation of a part or the entire service-providing processes would contribute to a speed-up of

service delivery.

Service prices, are sometimes determined case by case, using the menus and options: such

flexibility of pricing in accordance with the user situations is expected to guide users to some

specifically patterned usage of services, or to promote reasonable sharing of resources.

Note that, although requiring the services not listed on service menus is possible, it could not

always lead to the total-optimization, or could be even disadvantageous from the point of investment

recovery, because, in some cases, due to additional development or procurement, extra time would

be required for defining specifications, making price-estimations, or finalizing the SLA (described in

the following sub-section), and in addition the start of service would be delayed.

4.9.3. SLA SLA, in the case of clouds, is prepared by providers, proposing the agreement on the quality of the

standardized services for the purpose of prompt service delivery — in some cases, the SLA can be

selected by users through making selections of menus or options mentioned in the previous

sub-section.

A cloud has no unique business factors for determining requirements of an SLA, or the

technological / operational factors involving the selection of an SLA, except for that, in comparison

with cases of conventional systems individually designed in accordance with a predefined SLA, cloud

services are designed by providers on some assumed level of service: it is such a large difference

that the consensus in case of cloud is built through such a process that the user selects the services

from the service menu including options prepared by the provider.

Note that, although it is possible that some cases require services that enable SLA requirements

not listed on the menu It might not always lead to total-optimization, and could be even

disadvantageous from the point of investment recovery, because, in some cases, due to additional

development or procurement, extra time would be required for defining specifications, making

price-estimations, and furthermore the start of service would be delayed.

66

4.9.4. Use Case and Defining Requirements Requirements for cloud services are defined by use-cases where defined players involved in the

integration of systems based on cloud services, or the use of services act according to their role.

Players and their roles are defined as follows:

- The provider: preparing environments for SaaS, PaaS, or IaaS

Required to care about the security of services and resources; maintainability, completeness, and

reliability of resources on the cloud; effective handling of resources on the cloud; and scalability in

data size, number of tasks, and number of users.

- The consumer: implementing services on the service-environment provided by the provider

Required to care about the short-lead-time to start-of-service, and pay-as-you-go charging policy.

- The end-user: using customer services implemented on the cloud

Required to care about the types and functions of services, the completeness of data and requests

on the cloud.

- The enabler (vendor): providing services or goods to providers and users

- The operator: operating the cloud environment

4.9.5. Points to Take Care Cloud Implementation The points to take care cloud implementation are listed below:

・ It is required to design systems and operations by selecting the optimum virtualization mechanism and suitable management infrastructures, depending on the scheme of

service-providing such as SaaS, PaaS, or IaaS.

・ It is required to prepare the service menus acceptable and suitable to the assumed users, and construct the operation and management infrastructure (including management portal,

monitoring / statistics system) to realize them.

・ It is required to keep watching the utilization situation of each tenant.

・ It is required to implement a system that can scale-in or scale-out dependent on demand.

・ It is required to take care of and eliminate a point-of-failure.

・ It is recommended to, for functions such as monitoring, back-up, job-execution, logging, or authentication, employ models sharable in the entire cloud system, whenever possible.

・ It is required to, in the case of a hybrid cloud composed through the combination of several cloud environments, consider the implementation of functions for authentication / user-management /

billing-management, etc.

・ It is necessary to present the responsibility-divides and SLAs to the users.

67

・ It is required to set-up suitable and acceptable SLAs for users, and implement monitoring / controlling systems for satisfying them.

・ It is necessary to, for the successful transfer of cloud-service environments, which is expected in future, prepare clearly defined validation criteria of transfer-completion.

・ It is required to pay attention to the necessity of checking security situations of the VM images or the environment to be provided.

・ It is necessary to, in case of resource-pool sharing by more than one user, properly execute performance designs / expansion plans / security designs.

・ Note that, in some cases, attentions must be paid on external constraints — domestic or foreign legal constraints such as the EU directive for data-protection or the U. S. Patriot Act,

geographical situations including earthquakes or weather conditions, power cost and capacity,

power-grid margin rate and reliability, and network-bandwidth.

68

4.10. Security Issues

Information security entails not only the security capability of information systems, but also

ensuring the “safety and reliability” of the social system and businesses: the objective of information

security is ensuring confidentiality, integrity, and availability of information through the construction of

ISMS (Information Security Management System).

Information systems are facing not only external “threats” such as computer virus, unauthorized

intrusions, or denial of service attacks, but internal “threats” such as lack of security capability, and

inappropriate software operation / management. “Vulnerability” refers to the possibility of problems

raised by those threats: completely eliminating vulnerability from an information system is impossible.

Threats exploit vulnerability, which is impossible to eliminate, raising “incidents” such as system

troubles. Such troubles give unfavorable “influence” to information systems, social systems, and

businesses. That is the chain reaction caused by insufficient security protection.

Cares for security-protection measures are necessary from the following three standpoints:

・ Technical Measures for Security Protection Embed security protection capabilities, including those in the individual technology domains and

security factors in non-functional elements, in the systems to be implemented.

・ Organizational Measures Prepare the organizational structure for security protection.

・ Operational Measures For protecting security, proper operations of information systems through utilizing the

organizational structure mentioned above are required: the points for the protection of security

are those described with regards to the common procurement of services, or those described

with regard to the categories of procurement of service.

Also note the following two security measures for avoiding security chain-reactions.

・ Security measures eliminating threats and vulnerability to avoid security incidents,

・ Security measures to prevent incidents from leading to damages, even if the occurrence of an incident could not be prevented.

Security could be enhanced as completely as possible if cost and operability is not taken into

consideration. However, to what extent the security is enhanced should be determined by the balance

of cost and operability in the employment of measures and also the following two issues:

・ The probability of the chain reaction — “incident” resulted from “vulnerability” exploited by a “threat.”

・ The severity of “influence” resulted from an “incident.”

69

4.10.1. Recent Changes in Threats to Information Security and Problems

It is necessary to pay attention to changes as shown below in threats to information security and

the problems, which can be seen in the trends in information systems and communication networks in

recent several years:

・ More diversified, sophisticated, and complex attacks to information systems and communication networks

Attacks to information systems and communication networks that had, although they had already

existed in the early days of the internet, have recently changed in their mechanisms and the

sophistication levels. In comparison with past cyber attacks such as the defacing of the web-pages of

governments or large corporations for the purpose of a demonstration of technical excellence, or a

publication of political propagandas, as well as an intrusion into corporate internal networks just for

pleasure — the attack mechanisms are comparatively simple the attacks in these days aim to steal

money using information obtained by deception and are executed in more coordinated ways. The

following are descriptions of such recent attacks (also refer to the Figure 4.10-1):

Attacks raising the attack-success probability by flexibly up-dating multi-staged attack means

according to the target.

Attacks using virus-subspecies for degrading virus-detection accuracy of protection software

using pattern matching.

Zero-day attacks exploiting unknown vulnerabilities to others, which are difficult to detect or

difficult to analyze due to the complexity of influence, or selective attacks picking off specific

targets.

Although the actions against security breaches have been executed simultaneously among

organizations inside or outside by sharing damage information, as for the attacks described above,

because of the difficulties of disclosing and sharing damage information, it becomes difficult to apply

effective measures by a single method.

70

Single Separated Attacker

Coordination (Botnet)

Unauthorized Intrusion / Defacing

Building Attack-Bases

2000 2004~Multi-staged Attack (based on Botnet)

Exploiting Authorized Services as Cyber-

attack Base

2009~2006~

Victimizing PCs and Defacing Homepages

？

Exploiting Authorized Sites/Services

Impact on e-Market Business or Settlement Business, etc.Deception of Account Collection Information, etc: Impact on Supply-chain Risk Management

Destruction of PC, Defacing of HPChanges in Aspects of Damages (Impact on Job-Operations)

Object: PC or ServerTarget: Information Systems (of Organizations or Businesses)

Information Deception, etc.

Unchanged Design Methodology

Countermeasures using Security Products (Available on Market)Design Methodology based on Security Products

Age of Less-Visible Full Aspect and Points of ThreatInformation Protection by Established Information-Operation Structure (Information Collaboration)Design Policy: Avoiding deep-level intrusions even allowing shallow-level ones Embedding Protection Mechanisms in System Designs or Network Topology Designs

Single-attack to Single-vulnerability

Coordination among AttackersMulti-Intension Attack(Information Deception)

Explosion of Virus Sub-species Sequential Malware (Multi-staged Attack)Using Zero-Day VulnerabilityVirus Production Using ToolsTargeting Information Systems

Tactical Attack

Figure 4.10-1: Comparison of Cyber Attacks; Traditional and Recent

・ Growing Ambiguity of Influence on Organizations and Responsibility Divides

These days, when information systems take critical roles as a business infrastructure participating

in various aspects in business processes, and the entities involved in information systems are widely

distributed having different and complicated relations to each other, it is not easy to know who should

take the responsibility on the occurrences of troubles, or what frameworks should be employed to

take actions.

Therefore, there exists an increasing necessity for a new approach for resolving problems.

・ Diversified meaning of security

These days, in a similar way that the meaning of information systems to the society has been

beyond a simple technology, the information-security field has been related to various social systems

or business processes. In addition, what the information process means is understood differently

depending on the standpoints of the involved social systems or business processes: it means that the

diversification of the meaning of information security is going-on along with the diversification of

understanding of security issues. In addition, the position of information security has been diversified

as well as it is different depending on the responsibilities and purposes of the involved job-positions,

71

(Refer to the Figure 4.10-2). Therefore, in discussing information security, it is necessary to sort-out

the acceptance-and-delivery processes of information, clarify the standpoints of the discussion, and

make a consensus.

Products and Solutions

Management of System Design (including security functions)

Incidence Report (CSIRT)

Judgment of Organizational Measures (Assessment of Influence on Organizational Operations)

Compliance and Information-management

Security Rating

Safety of Manufacturing Line and Cost Efficiency

Protection of Intellectual Property of Private Businesses, etc.Organizational

ChallengeTechnical Challenge

Business Challenge

Standards, Guidelines, etc.

What are your organizational objectives?What is your role?What influence is predicted to what extent?Who attacks and for what?

Information Integrity

National Security

Investigations of Public Security

Crime-Prevention, Criminal Investigations

Internet Security

Communication Integrity

Security Business

Legal ComplianceBusiness Continuity

Protection of Critical Infrastructures

Audit

Academic Research

Communication-Carrier (ISP), Service

Management Judgment

Intelligence

Economy

Figure 4.10-2: Related Fields to Information Security

Much attentions has been paid to CND (Computer Network Defense) fields, as the changes in

threats and problems about information security have been widely noticed.

72

4.10.2. Treatment of Security in Separation Procurement of Services It is necessary, in procurement of services, to make a security assessment and determine security

measures for each procurement-of-service category, where the points of assessment of security are

as follows:

・ Planning Phase Predict the severity of risks through making assessments of threats, vulnerability, and the severity

of influences, and then determine the level of the countermeasures required for complying with the

results of the assessments..

・ Requirement Definition Phase Define the requirements for security corresponding to the severity of risks and the level of the

required counter-measures determined in the Planning Phase.

・ Development Phase Break-down of the requirements for security defined in the Requirement Definition Phase and

define the requirements for security in operation / maintenance.

・ Operation / Management Phase Execute the security counter-measures defined in the Development Phase, and also, pay attention

to new threats, new vulnerability, and changes in influence across the ages.

4.10.3. Outline of Measures for Ensuring Information Security in Planning / Design Phase (SBD)

For implementing security measures, it is desirable to note that actions in the up-stream of projects

have influence the down-stream, and take actions for ensuring security in the earlier stages of a

project so that integrity of security policies and traceability is ensured, and that re-run of work from

earlier processes is avoided in every stage of procurement of service.

If security requirements are not explicitly specified in procurement specifications, disadvantages

both to the procurer and to the provider could be produced. Examples are as follows:

(1) Possibility of financial damages due to re-run of work or extra procurement as a result of a lack

of consensus between procurers and providers in the stages from procurement to operation /

maintenance caused by ambiguity or unfairness in procurement specifications of information

systems.

(2) Possibility of disadvantages due to improper — excessive or dissatisfying — security measures

implemented as a result of a lack of clear requirements for proper security.

For resolving such problems, in all the stages, even in the planning phase, flawless implementation

of proper security measures is ensured through reducing the disadvantages on both of procurers and

providers. For such purposes, in addition to this Technical Reference Model, on the request of the

Information Security Policy Conference, the National Information Security Center published, at the

end of FY 2010, the “Manual for Defining Requirements of Information Security in the Government

Organizations Related to Information Systems” as a result of discussions in the “Discussion Group for

73

Measures for Ensuring Information Security in Planning / Design Phase (SBD)” (hereinafter referred

to as “SBD Discussion Group”)

The manual, covering procurement jobs for information systems including “up-dating” and “new

development,” is expected to be used especially by the administrative job-operators in charge of the

procurement of information systems to define security requirements on their own responsibilities and

write them down in procurement specifications. Also, the Manual is expected to be used by providers

of information systems to obtain information (including information on the process of building the

Manual) supporting their understanding on security requirements specified in procurement

specifications.

It is expected that security measures matching the necessities are ensured by preferentially and

clearly writing essential and effective requirements in procurement specifications paying attention to

information-protection measures in information systems and measures against security breaches.

4.10.4. Outline of Risk Factor Reference Model (RM)

4.10.4.1. Fields of Security Covered by Risk Factor Reference Model (RM) Security measures of information systems are categorized into IA and CND as follows (refer for the

Figure 4.10-3):

IA (Information Assurance): The actions to be taken to manage the risks in data use / process /

preservation / transmission or the risks of systems / processes using data. This document

specifically uses the term (information assurance) as the protection measures against leakage

or falsification of information through managing information according to formalized guidelines

or standards.

CND (Computer Network Defense): The actions to be taken for protection / monitoring /

analysis / detection of misconducts, and actions for responding to them (response). This

document specifically uses the term (computer network defense) as the actions to be taken

against cyber-attacks from the outside, for protecting communication networks and information

systems, to keep the systems operating and to prevent information theft.

As for IA, since the Standards for Information Security Measures for the Central Government

Computer Systems were formalized, the protection measures, including the internal control system

as a major protection measure, have been systematically deployed. As well as the deployment of the

internal control system, the system requires, in the operation phase, the execution of PDCA

(Plan-DO-Check-Act) cycle and the management of information of a level higher than predetermined.

As for CND, security protection measures have been deployed on a particular-system basis, such as

the implementation of firewalls, employment of secure communication-protocols, or the employment

of virus-detection mechanisms, partly because the departments in charge of security have put their

power entirely on the task of preventing the individual cyber-attacks which are constantly being

changed and sophisticated.

In these days, when the threats and problems of information security have changed, more

74

systematic approaches are required for CND. For such purpose, it is essential that the early stages of

the procurement of information systems such as planning or design contain work for embedding

security measures.

What should be protected:

Target Field of Information Assurance

Type 4: Factors in management, etc. (human, facility, rules, etc.)

Target Field of Cyber-Attacks

Threats and risks come from outside of organizations

Threats and risks emerge in the organization

Organizational CapabilityBusinessTrustworthiness

Type 2: Information theft issues

Type 1: Attack Issues

Protection from state-of-the-art attacks

IA (Information Assurance)CND (Cyber-Attack Protection)

CND (Cyber-attack defense) and IA (Information assurance) have different objectives (different operations)

Type 3: Information Management Functions

“Information leakage by cyber-attack (theft)”

Figure 4.10-3: Field Covered by RM

In order to figure out effective measure in the cyber-attack field (CND) as described above, it is

essential to apply the “Design of Counter-measures Based on the Correct Knowledge on the Present

Attacks” based on the Risk Factor Reference Model (RM).

4.10.4.2. Philosophy of Risk Factor Reference Model (RM) The “Risk Factor Reference Model (RM)” is an approach that enables judgment, based on the

shared knowledge of present threats and issues of influence to organizations in the sophisticated

CND fields, of the necessity of measures in system design, and the application of the

effectiveness-proven design of counter-measures.

The conventional “measures by management,” which generally requires the application of uniform

measures in design, have problems in the confirmation of the necessity and effectiveness of the

measures, and in addition is prone to lead to an escalation of cost for measures.

On the other hand, the RM is an approach that makes the necessity and effectiveness of measures

clear, and to intensively apply measures by system design to the essential parts found through the

impact analysis.

75

Furthermore, since the emergence of these new-types of cyber-attacks, the measures based on

the conventional design approach of installation of security-solution products have become less

effective without the aid of other means. In order to solve such problems, the RM has employed a

new design approach so that the necessity and effectiveness of measures is judged based on precise

knowledge of the aspect of actual attacks and the impacts on job-operations (refer to the Figure

4.10-4).

The approach of analysis based on the RM is as follows:

(1) Analyze and categorize the actual cyber-threats in detail, define “attack patterns” based on the

analysis and categorization, and predict specific attack scenarios.

(2) Formulate the information system design models for each type or characteristic of systems.

(3) Attack the model system on a desktop using the attack scenarios and trace the attack

(simulated desktop-attack). Then, analyze impacts of the attack and the effectiveness of the

designed measures.

(4) Document the results of traced attacks (simulated desktop attacks) as “System-Design

Measures.”

The results of analysis based on the RM is assumed to be used by both the procurer and the

provider of information systems for sharing the consciousness of problems and specifying the

necessary requirements of procurements based on the “System-Design Measures.”

Analysis of Object Systems of ProtectionAnalysis of Threats of Attack

(1) Analysis of Attack Patterns and Formulation of Attack Scenario

(2) Categorization of System/design Model

Impact / Risk Analysis

Analysis of Measures

(3) Attack Trace (Simulated Desktop Attack)

(4) Formulate System-Design Measures from Trace of Simulated Attack

Classification of Severe Threat models and Analysis of Attack Specifications

Classification of object Systems of Protection into the Four Categories shown above

a. Intranet Model b. Closed Area Model

c. iDC Model d. SaaS Model

Analysis of Inf luence of Attack and Ef fectiveness of Measures Taking Job-mission Impact into Consideration

Figure 4.10-4: Analytic Approach Based on the RM

The basic models of cyber-attacks assumed in the RM, used as the basis of counter-measure

design concepts, are the following:

Analysis of various modeled patterns of attack has revealed that any attack consists of more than

one stage, the first to the third, and the success or failure of the third attack is, almost commonly to

76

any pattern, deeply involved in the mission-impacts.

Therefore, the RM has, taking into account the limited effect of measures in the first stage, included

in to the scope of the conventional measures, proposed the measures by design-management,

focusing on the avoidance of the attacks in the third stage.

The RM has, in addition to the conventional measures, categorized such measures as measures

by design for “Avoidance of the Final Impact on the Mission of the Organization.”

For avoiding the organizational influence (mission impact) caused by the current cyber-attacks,

re-definition of threats and re-analysis of design philosophy and organization-operation policy is

necessary.

★第２、３段階の阻止により組織インパクトを回避

The ultimate impact on organizations (systems) is avoidable by preventing the invasion of main attack units and attack-objectives (information theft) even for attack tactics on which vulnerability-patch or AV pattern measures is not effective.

Blocking the communication with DL servers executed in the second / third stage.

Avoid the ultimate damage by blocking the attacks in the second / third stage, and then clean viruses and execute anti-vulnerability measures.

Preliminary Stage: Object / Motivation / Attack Base

First Stage: Initial Invasion to System (by various means)

(1) Initial Attack by Malware attached to Selective-attack e-Mail(2) DL Server Inducement by Web Attack(3) Initial Media-Mediated Malwareetc.

Abuse of vulnerability

Second Stage: Induction to DL Servers and Drop of Attack Malware

Dropping Initial Attack Unit

Dropping Main Attack Unit

Formulation of Attack Plan

Identification and Trace of Attack Pattern

★戦術的攻撃バターンの全体像の把握とパターン監視

Extract the characteristics of the attacks, which will be the keys to measures by design, by tracing attack patterns (behaviors)

★Avoiding the mission-impact by blocking the second / third attack

★Blocking the attainment of the final attack objective, and then destroying the threats

★Figuring-out of the Entire Tactical Attack Pattern and Watching for the Appearance of Tactical Patterns

Use of attack-bases

Execution of Attack on Final Destination

Third Stage: Information Theft by Deception and Handing-over to Attack Commander

Basic Model of Tactical Attack Philosophy of Measures by Design

The Ultimate Threat to Organizations

Figure 4.10-5 Common Basic Models of Cyber-attack assumed in the RM

77

4.11. Policies for Employment of Green-IT

Green-IT refers to a philosophy of applying information technologies giving considerations to the

environment. In Japan, on the framework of the Basic Act for the Promotion of a Recycling-Oriented

Society, enacted in January 2001, the laws and regulations regarding the recycling of resources and

improvement of energy-consumption efficiency have been established or revised. The government

procurement of information systems, as well as contributing to the realization of environmental-load

reduction through proactive actions, which should be a model to the society, is expected from now on

to contribute to the reduction of power consumption through consolidation of equipment, employment

of low-power-consumption equipment and energy-saving technologies, and the optimization of

cooling and power-supply.

The Philosophy of Green IT generally consists of the “Consideration of Environment in IT” (Green

of IT) and “Consideration of Environment by IT” (Green by IT). The former is about the reduction of

environmental load imposed by the equipment installed for information systems: it is a subject to be

discussed mainly in the procurement of goods. The latter is about the reduction, by the proactive use

of information systems, of environmental load imposed by the existing job-operations, social activities,

and the social systems: it is a subject to be discussed mainly in the planning processes of the

government procurement of information systems.

4.11.1. Application of Green IT to Procurement of Goods

As for the application of Green IT to procurement of goods, the “Consideration of environment in IT”

is the main subject. Especially, as for the activities covering the entire purchase and procurement, the

“Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other

Entities (Act No. 100, May 31, 2000)” and the “Basic Policy for the Promotion of Procurement of

Eco-Friendly Goods (Revision to Cabinet Approval on February 5, 2010)” (hereinafter referred to as

“Act on Promoting Green Purchasing”) have been in effect. According to those acts, in the

procurement of specified goods for procurement by the government, independent administrative

agencies, etc., local governments, and local independent administrative agencies, the compliance to

the compatibility conditions stipulated in the Act of Promoting Green Purchasing is required as

procurement conditions. Relations of the specified goods for procurement to the technology domains

in this Technical Reference Model are shown below; the conditions stipulated in the Act on Promoting

Green Purchasing are described in Ch.5 as the basic items of non-functional requirements for each

technical domain, and, if there exists standardized green IT technologies in a technology domain

other than those specified in the Act on Promoting Green Purchasing, they are described in Ch.5 as

basic or desirable features.

78

Specified Goods for Procurement in the Act on Promoting Green Purchasing, FY 2009

Technology Domain, Technical Reference Model for the Government Procurement of Information Systems (TRM), FY 2010

Computers 5.6.3. Server hardware

5.8.2. Personal Computer

Magnetic Disk Drive 5.7.1. Disk Storage

Printer 5.8.6. Printer Shared in Office

Digital Printer 5.8.6.2. Multi-Functional Printer

Copy Machine(Multi-Functional Printer) 5.8.6.2. Multi-Functional Printer

Display 5.8.2. Personal Computer

4.11.2. Application of Green IT to Procurement of Service

By the “Consideration of Environment in IT (Green in IT),” the essentially a concept in the

procurement of goods, although the short-term effects on reduction of environmental load is expected,

the long-term and significant effects on the reduction of environmental load is difficult. On the other

hand, the idea of “Consideration of Environment by IT (Green by IT),” is expected to contribute to

significant reduction of environmental load necessary for the realization a of low-environmental-load

society, because it aims for the reduction of environmental load through the reformation of the

existing job-operations, social activities and social systems. Therefore, much more effort should be

put into the field.

More specifically, reduction of the consumption of paper (reduction of environmental load by the

reduction of paper) required in the existing job-operations through the utilization of BI, etc, reduction

of geographical transportation of workers (reduction of environmental load by the reduction of

automobile-run) through the utilization of electronic conferences will be the realization-examples of

the “Consideration of Environment by IT.” Also, the use of cloud services has an advantage for the

reduction of IT equipment on the side of the “Consideration of Environment in IT,” and, at the same

time, an advantage in the reduction of the procurement or operation-load on side of “Consideration of

Environment by IT.”

In addition, as for the use of data centers, the consideration of both of the energy efficiency of IT

equipment and the energy efficiency of incidental facilities such as cooling systems is required in

procurement.

79

4.12. Notes on Employment of IPv6

The reservoir of IPv4 global addresses necessary for the Internet connection has dried-up ,

and the allocation of new addresses has been impossible (newly allocated global address will be

IPv6). Therefore, addition of servers with IPv4 global addresses, or new construction of DMZ

with IPv4 is difficult in normal situations. In addition, because IPv6 has no compatibility with IPv4,

IPv6-based networks or servers are unable to communicate with those based on IPv4 by simple

means: special schemes are required, such as co-existence or parallel use of IPv6-based

environments with the existing IPv4-based environments.

As for the equipment, such as networks, servers, or PCs connecting to the internet, in order to

properly achieve such co-existence or parallel use, preparatory consideration must be made for

the details of operation / management / monitoring / maintenance and security measures as well

as those for design or procurement.

Refer to “Guidelines for IPv6 Support in e-Government Systems”

http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070402_5_bt1.pdf

http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070402_5_bt1.pdf

80

5. Descriptions of Technological Domain

This chapter describes the Technology Domains from the standpoint of procurers, showing

representational examples of requirements to specify in procurement specifications. Note that, on the

application to the actual procurement specifications, the words and phrases shown in the examples

have to be modified according to the actual situations, as follows:

The words or phrases parenthesized in “{},” curly brackets, are variable elements dependent on the

systems to be procured. Replace them with the appropriate words in accordance with the

requirements of the actual information systems.

The words or phrases parenthesized in “[],” square brackets, are exemplifications for clearer

understanding. Replace them with appropriate information in accordance with the requirements of the

actual information systems. Many of those will refer to product-names or trademarks, etc. They must

be replaced with more than one product-name or trademark followed by “etc,” for clearly showing that

they are exemplifications, in order to avoid specifying particular products, unless there are no proper

reasons for explicitly referring exactly to particular products in cases where the assets procured in the

past are intentionally used. If such proper reasons exist, describe in detail the information identifying

the particular products.

In the tables in the following sections, which list requirements, the requirement items labeled as

“Basic” are fundamental requirements — normally available products will satisfy these requirements.

In the evaluation-by-total-score based procurement, it is allowable to use them as the indispensable

requirement technical points items. On the other hand, the label “Additional” indicates that the

requirement item is not always necessary, or not always satisfied by normally available products. As

for the evaluation-by-total-score based procurement, those items should be used as additional

technical point items, unless they are indispensable to the system to be procured. The label

“Selective” indicates that more than one of the items listed in the description is required to be

satisfied.

Note that, because those labels used in the sample requirement tables are given to the assumed

ordinary requirement items in the technology domain, it is necessary, when they are referenced for

creating actual procurement specifications, to consider which requirement items should be labeled as

“basic” or “additional.” Pay attentions on how the items in the examples are labeled as “basic,”

“additional,” or “selective. Also, note that, because some of the requirement items labeled as “basic”

might be over-specifications for small-scale systems, it is necessary to select the requirement items

carefully in the design or implementation phase. In addition, it is necessary to make adjustments so

that unnecessary items for the actual information system to procure are eliminated, and the

requirement items necessary for the actual systems are included, even if they are not listed in the

sample requirement tables.

81

The technologies listed in the table “Related Technology” are those supposed to be referenced in

procurements, or the related open-standards. Referencing them in procurement specifications

requires sufficient care and sufficient knowledge about those technologies. Simple copy of items

listed in the sample requirement items would in some cases lead to less possible procurement

realization — strikingly reduce the room of choice of products to be procured —, or lead to difficulties

in the utilization of the existing assets due to the discrepancies between versions of open-standards.

Therefore, in the reference of the sample tables, attention must be paid to total consistency in relation

to the procurement.

82

5.1. BI/DWH/ETL

5.1.1. Definition

BI / DWH / ETL collectively refers to a system that provides proper information in a proper style, at

a proper time, and to a proper user: it is a mechanism for referring to or analyzing data in

job-operations through searching, referencing, operating, transforming, and archiving in a integrated

and multi-purpose way.

In addition, it contributes to the reduction of person-months required for the development of

screens for analytic-operations or job-forms.

Figure 5.1-1 Elements and Usage in Job-Operations of Business Intelligence

Selectively combining the functions or services of BI / DWH / ETL listed in the table below, enables

the functions or services shown below. (Note that they are examples).

・ Business Performance Management

83

The objective is to realize productivity improvement — by measuring and monitoring the

effectiveness of job-operations, and making predictions through applying quantitative or qualitative

benchmarks — and to enable prompt detection of trends or risks.

It will support job-operators in every situation, by seamlessly connecting a series of

job-management activities, such as assured delivery of tactically important information of

job-operations or events, predictions on job-operations and problem-resolution, enabled by

integrating relational databases existing in data-marts, spreadsheets, and tools for analysis such as

data-mining, into a single large system.

・ Integrated Financial Analysis

Integrated Financial Analysis enables financial analyses such as a cost-effectiveness analysis

through providing all the decision-makers with the critical financial information on job-operations in a

secured and effective manner,.

It serves as an analysis tool in job-operations executed in a systematic and integrated way on the

platform consisting of data warehouses, ODSs or spreadsheets, and OLAP. Therefore, it also

requires correctness of data and high-level security.

In addition, it contributes to the effectiveness-improvement of the existing various job-operations

involving statistics.

Functions and Services of BI / DWH / ETL Functions and Services Definition / Description Business Intelligence (BI)

Refers to the following: an approach to utilizing a large-volume data output from job-operation systems, etc.; a mechanism or an activity enabling job-operations and predictions, based on a philosophy of establishing knowledge or insight available for making decisions through systematically and methodically storing, classifying, searching, analyzing, and processing factual data; and a system or technology supporting such activities. It aims to flexibly analyze the required information on job-operations and be utilized to provide improvement for various kinds of job-operations.

Data Warehouse(DWH) Refers to the following: a collection of time-series data organized and integrated in groups according to the objectives of use, without mechanisms for deleting or updating, where transaction data is extracted from job-operation systems, re-organized, and stored there to be used for information analysis or decision-making; and a decision support system based on large-scale databases, or an integration concept of such systems.

ETL — Extract / Refers to a series of data processes that extracts data,

84

Transform / Load (Functions for data extraction, process and saving)

transforms it so that it is easily used in a data warehouse, etc, and then loads it into target systems such as data warehouses, etc.; and a software function that supports such a series of processes.

Data Mart Refers to a database, in comparison with the central data warehouse integrating and managing the entirety of job-operation data, composed of data extracted from data warehouses, edited, and stored for specific departmental or private purposes; and a subset of data extracted for the use of specific departments or users.

OLAP — Online Analytical Processing (Tools for data collection or analysis)

Refers to a philosophy and the realization of an analytical application so that end-users directly search / tabulate data existing on a database for finding problems or actions to take: it is generally categorized in the following three ways: ROLAP using databases, MOLAP using multi-dimensional data bases, and HOPLS combining the two.

ODS — Operational Data Sore (temporal data saving system)

Refers to a collection of job-operation data, extracted and temporarily stored for auxiliary purposes such as search etc.

Data Mining Refers collectively to knowledge-finding methods or processes, by which, through the analysis of huge amount of data by different analytical techniques, the hidden knowledge on how the data links to each other or what the data indicates is uncovered. The models created through such processes will be available as the foundation of predictions or simulations.

Information dashboard Refers to a personalized software tool for accessing information on portals, or sharing information such as outputs of analysis: it is available for consolidating communication paths.

Reporting tool (Reporting service)

Refers to a tool for providing a variety of viewpoints for data generated through job-operations, by summarizing, classifying, prioritizing, and display: it supports creation, management, or delivery of written or interactive web-based reports.

Spreadsheet Refers to application software for tabulating or analyzing numerical data, by interpreting numerical data or mathematical expressions written in a cell at a cross section of a row and a column of a table, automatically executing the calculations, and putting the results into designated cells. Being equipped with interactive cross-tally tables, it is available as a front-end of BI by standardized open-formats or interfaces to web-services.

85

5.1.2. Business Intelligence (BI)

BI refers to an approach of utilizing an enormous amount of job-operation system output data, etc,

for decision-making, by storing, classifying, searching, analyzing, and transforming factual data: it

also refers to a scheme or an activity for realizing the idea of extracting useful knowledge or insights

in a systematic way and enabling business predictions, or systems and technologies supporting such

activities. Its objective is to utilize information for improving job-execution efficiency through flexibly

analyzing the required information.

In comparison with conventional data-analysis, which is closed in individual stand-alone systems,

along with the implementation of system-linkage infrastructure such as SOA, the cross-system

analysis of data separately stored in individual systems after being homogenized has become

necessary, and the mechanisms for the management and transformation of meta-data has been

implemented. Note that the corresponding mechanism (meta-data registry) has almost the same

functions as those of the combination of ETL and DWH. Functional Requirement 1 Basic Capability of storing / classifying / searching / analyzing /

transforming data in a systematic and integrated way. 2 Basic Mechanisms for enabling the production, through analysis, of useful

knowledge or insights. 3 Additional Capability of combining [data-warehouse, ETL, data-mart, OLAP,

data-mining] methods according to the needs. 4 Additional Capability of visualizing the results of analysis on [BSC, information

dashboard, reporting-tool, and spreadsheet, etc.] according to the needs.

5 Additional Mechanisms for interactively selecting various forms or graphs. 6 Additional Mechanisms for raising an alert for proper users triggered by a

predefined threshold. 7 Additional Mechanisms of meta-data registry (transformation of meta-data or

homogenization of data-quality at the exchange of data between systems), effective on the analysis of linked data on a system-linkage infrastructure.

Non-functional Requirements (write only when individually required) Backup Additional Functions of data-backup or data-recovery. Security Additional Permission for the explicitly authenticated users by IDs to

execute processes of data-search / data-check. Related Technologies Format of Meta-Data Registry

ISO / IEC 11179ISO JIS X4181-3 (JIS X4181-1, JIS X4181-2) — JIS standards fully-compatible with the international standard, ISO / IEC 11179)

86

5.1.3. Data Warehouse

A Data Warehouse refers to a collection of time-series data integrated and edited according to

purposes, which basically, have no mechanisms for data deletion or staying up-to-date: it is used for

information analysis and decision-support through extracting, re-organizing, and archiving transaction

data generated by job-operation systems. It also refers to a decision-support system based on a

large-scale data base, or the system-construction concept of such systems.

Functional Requirement 1 Basic Configuration as a collection of time-series data integrated and arranged

according to purposes. 2 Basic Capability of archiving, for a long time, raw data (detail data), not yet

transformed into forms suitable for analysis. 3 Basic Capability of extracting, re-configuring, and archiving transaction data. 4 Basic Application of independent development of business application systems. 5 Basic Deletion or updating of data is prohibited under normal conditions.

5.1.4. ETL — Extract / Transform / Load (Data Processing Capability)

ETL refers to a series of data processing that extracts data stored in job-operation systems, etc

(Extract), transforming into forms suitable for being used in data warehouses, etc (Transform), and

loading into target systems such as data warehouses, etc. (Load). It also refers to functions

supporting such data processing. ETL enables data-cleansing, etc.

Functional Requirement 1 Basic Capability of extracting data from various types of data-sources

[standard-format files, data bases, or FTP, etc.]. 2 Basic Provision of selections for consolidation / transformation of data

available [filtering, tabulation, division, binding, conditional branching, or derivation (creating row-values according to the formula embedded in the input row, and storing of the results as a new row or replacing an existing row)].

3 Basic Capability of loading data from target systems [data warehouse, or data mart, etc.].

Related Technologies Interfaces for DB Access

SQL

87

4 Basic Capability of exception-handling, for such cases as error events in various types of data-flows.

5 Additional Capability of setting / executing [various types of operations of data or flow-controls, etc].

5.1.5. Data Mart

A Data mart refers to a database consisting of the data extracted and reorganized, for departmental

or private purposes, from the archives in the data warehouse: it is a subset of data extracted

according to the operational needs of particular departments or users, while the central data

warehouse manages, in an integrated way, the entire job-operation data.

Functional Requirement 1 Basic Employment of databases consisting of the data extracted according

to purposes separate from the data archived in the data warehouse. 2 Additional Employment of a database of summarized data for efficiently

responding to requests of search or analysis.

Related Technology Interfaces for DB Access

SQL


SQL

88

5.1.6. OLAP — Online Analytical Processing (Data Tabulating / Analyzing)

OLAP refers to a philosophy and a system realization of an analytical application, allowing

end-users to directly search / tabulate data existing on a database for finding problems or actions to

take. It is generally categorized in the following three ways: ROLAP (Relational OLAP) using

relational databases, MOLAP(Multidimensional OLAP) using multi-dimensional data bases for

aggregating and tabulating data, and HOLAP (Hybrid OLAP) with high-speed preprocessing and

scalability.

Figure 5.1-2: Elements and Usage in Job-operations of OLAP

Functional Requirement 1 Basic Assurance of end users’ direct search / tabulation of data existing in

databases. 2 Basic Employment of a relational database or pre-optimized data-management

system. 3 Basic Provision of multi-dimensional conceptual views. 4 Basic Accessibility from a reporting function or a spreadsheet through

[pivot-table service (PTS), etc.]. 5 Basic Assurance of users’ easy access to data without the knowledge of

physical storage-structure of the data.

89

6 Basic Capability of providing any dimension or cell with functions of [slicing, dicing, or drilling, etc] with the equal performance.

7 Basic Uniformity of structure and operations in every dimension. 8 Basic Capability of executing dynamic matrix-processing. 9 Basic Accessibility by multiple-users simultaneously. 10 Basic No functional limitations of software in cross-dimension processing. 11 Basic Capability of flexible reporting. 12 Basic No limitations on the number of dimensions or members 13 Basic Capability of individually executing each processing [slicing, dicing, or

drilling, etc] without the help of menus.

5.1.7. ODS — Operational Data Store (System for Temporarily Preserving data)

ODS refers to a collection of data which consists of job-operation data extracted from job-operation

systems and temporarily stored for additional purposes such as search etc. Functional Requirement 1 Basic Function as database for extracting and temporarily storing data from the

job-operation system. 2 Basic Capability of storing volatile real-time data. 3 Basic Capability of the short-term preservation of data


SQL

Query Language

MDX (Multi-Dimensional Expressions) — used in obtaining or manipulating multi-dimensional data.


SQL

90

5.1.8. Data Mining

Data mining collectively refers to knowledge-finding methods or processes, by which, through the

analysis of huge amounts of data by various analytical techniques, the hidden knowledge on how the

data links to each other or what the data indicates is uncovered. The models created through such

processes will be available as the basis of predictions or simulations.

Figure 5.1-3: Elements, Processes, and Usage in Job-Operations of Data Mining

Functional Requirement 1 Basic Mechanism for, through the analysis of huge amount of data, finding the

hidden relationships of data or knowledge. 2 Basic Mechanism for visualizing relationships of data or knowledge. 3 Basic Mechanism for creating prediction-models from relationships or

knowledge, and functions for making predictions through the application of such models to a new data-set.

4 Basic Mechanism for assessing the accuracy of predictions. 5 Basic Mechanism for selecting algorithms [correlation rules, clustering,

decision-trees, naive Bayes, neural nets, etc.] to apply to the analysis. 6 Basic Mechanism for repeating analysis in a trial-and-error way aided by a GUI.

91

7 Additional Functions for data-access or output through [reporting tools or spreadsheets, etc].

5.1.9. Information Dashboard

The Information Dashboard refers to a personalized software tool for accessing portals, or sharing

information such as analysis outputs: it is used for the purpose of consolidating communication paths. Functional Requirement 1 Basic Capability of constructing portal sites without difficulty, satisfying specific

requirements from target users, based on the integrated portal framework. 2 Basic Capability of constructing more than one type of web site [private site,

departmental site, intranet site, extranet site, internet site, etc.]. 3 Basic Employment of authoring tools enabling easy content posting. 4 Basic Capability of allowing the owner of information to specify, through the built-in

functions, how and when to deliver the information to the specified users. 5 Basic Capability of personalizing the information to be delivered. 6 Basic Employment of a framework for comprehensively-integrating applications,

enabling construction of composite-applications. 7 Basic Functions for application-governance to detail-control the

application-execution environment.

5.1.10. Reporting Tool (Reporting Service) A Reporting tool refers to a tool for providing a variety of view points for data generated through

job-operations, by summarizing, classifying, prioritizing, and displaying: it supports creation,

management, or delivery of written or interactive web-based reports.


SQL

92

Figure 5.1-4 Elements and Usage in Job-Operations of Reporting Tools

Functional Requirement 1 Basic Capability of providing user-friendly visualized information through

[summarizing, classifying, or prioritizing, etc. 2 Basic Capability of allowing users to select data-sources and access methods. 3 Basic Provision to users of report-creation functions, report-templates, and

report-management screens. 4 Basic Functions for assisting the creation of written or interactive web-based reports

[creation and management of forms]. 5 Basic Capability of allowing users to specify the viewers in the publication or delivery

of reports.

5.1.11. Spreadsheet

Spreadsheet refers to application software for tabulating or analyzing numerical data, by

interpreting the numerical data or mathematical expressions stored in a cell at a cross section of a

row and a column of a table, automatically executing the calculations, and storing the results in the

93

designated cells. Being equipped with interactive cross-tally tables, it is available as a front-end for BI

through standardized open-formats or interfaces to web-services. Functional Requirement 1 Basic Capability of serving as a front-end of OLAP or data mining (or others

categorized in BI). 2 Basic Capability of embedding automatic-execution mechanisms or constraint

conditions. Note: Also, refer to “5.8.5 Definitions of Common Operations,” and “5.8.5.8 Functional

Requirements for Table Calculations.”

94

5.2. EAI

5.2.1. Definition EAI (Enterprise Application Integration) collectively refers to functions, middleware / application

packages, or integration technologies for linking / integrating different computer systems or business

application packaged products by means of a hub-and-spoke architecture, and providing strategically

enhanced functions or enriched information.

Conventionally, data-exchange between servers has been executed by means of a file-transfer or

messaging technologies. However, as the number of servers requiring data-exchange has increased,

the idea has emerged that it will be more efficient, if the development and maintenance cost is taken

into consideration, to establish such a data-exchange function as a standard function than to

individually develop and maintain each data-exchange mechanism. In EAI, which has emerged out of

such ideas, data-exchange is generally executed asynchronously (loosely coupled) for the purpose of

preventing ripple effects of EAI processing-delays to the inter-connected servers by allowing the

servers to execute processes independently and asynchronously.

Figure 5.2-1 Schematic Diagram of EAI

Definition of EAI Function and Service Name of Function or Service

Definition

EAI Function It links / integrates, in a organic way, different computer systems and business-packaged software products by means of a hub-and-spoke type architecture, and provides them as more strategic information resources. In addition, it provides more than one adapter for the purpose of inter-system connection, such as an application adapter enabling easy

95

connections to business packages, a technology adapter for enabling easy connections through standard protocols, and a mainframe adapter enabling easy connection to main frame computers.

5.2.2. Functional Requirement Functional Requirement 1 Basic Capability of format-transformation — transforming data or characters

written in individual formats or character-codes used in a system or an application connected to the EAI to other different formats or codes.

2 Basic Capability of routing — delivering data to more than one recipient according to the contents of the data.

3 Basic Employment of more than one connection support mechanism (adapter) prepared to reduce the interface development work on the side of servers to be connected to the EAI.

4 Basic Capability of process-control — enabling automatic job-execution by combining different functions such as routing and format-transformation.

5 Basic Capability of data-item-mapping — mapping a data-item used in a system to a data-item used in other system.

Non-functional Requirement (write only in a case of individual-purchase) Meta-Data Definition

Additional Employment of meta-data definitions in an industry standard format, such as SWIFT, FIX, or EDIFACT: by using the prepared format, users are able to greatly save the cost of developing meta-data from a scratch.


Additional Functions of EAI middleware products preparing GUI development environments where “drag & drop” or built-in functions enables “intuitive” development, instead of coding in a programming language: it will ensure high development-efficiency and maintainability (easy maintenance), because members without programming expertise can participate in the development.

96

5.3. iDC Facility

5.3.1. Definition iDC (Internet Data Center) Facility refers to a highly-secured and quake-resistant facility equipped

with high-speed telecommunication lines, power generators, and high-power air-conditioning systems

that hold servers, network-equipment, etc. (hereinafter referred to as “equipment,” etc.) on which

job-operation systems run. It is used for operation-work such as monitoring and troubleshooting of the

equipment, etc and the applications.

The services provided by an iDC are categorized generally into housing services and hosting

services. In the housing service, users install the equipment of their property in the iDC, and receive

services such as the internet connection or operation of that equipment. On the other hand, in the

hosting service, users use the equipment (dedicated to the user or shared) connected to the internet

of the providers’ property and receive the service of operational work: generally, the hosting service is

used for web servers or mail servers.

Note that, because in the case of a housing service, equipment etc is generally purchased

separately, therefore procurement specifications for such equipment are necessary. In normal cases,

because equipment, etc. is provided installed in a rack, the procurement specification should be for

such racked equipment, etc, where the items of the specification are as follows: rack-size; number of

racks; rack-weight (total weight of rack and equipment); power (maximum power consumption after

equipment-installation); amount of heat generation (total for all equipment installed); and

power-supply (voltage, shape of receptacle, and number of receptacles).

Also, note that purchase of telecommunication lines (including monitoring service) is categorized

as a separate-purchase, and is not included in the purchase of an iDC.

Functions and Services of iDC Facility Functions and Services Definition Location Requirement Refers to requirements for the location such that the iDC

will not lose the ability of providing services even in a situation caused by a natural disaster such as an earthquake where the iDC is damaged.

Facility / Machine-room Requirement

Refers to a requirement for facility-structures such as quake-resistance of the building or duplexing of communication equipment such that the iDC will not lose the ability of providing services. A machine requirement refers to a requirement for installation-environments (sites) of the racks loaded with equipment, etc.

Power / Air-conditioning Requirement

Preservation of redundancy such as duplexing of power / air-conditioning system such that the equipment, etc. (or the services) will not lose the ability to run due to problems in the power / air-conditioning system.

97

Security Requirement Physical security measures preventing illegal intrusions / interferences / destruction, or illegal access to the properties in the iDC that are closed to public, excluding work on implementing security measures on equipment, etc. which are categorized as operational services separately purchased. As for such operational services, refer to “5.9. System-Operation Management / Security.”

Operation Requirement Maintenance / management of iDC facility, excluding monitoring, configuration, malfunction-control, or storing backup equipment, etc., which are categorized as operational services separately purchased. As for such operational services, refer to “5.9. System-Operation Management / Security.”

5.3.2. Location Requirement A location requirement refers to a requirement of location for an iDC. Functional Requirement 1 Basic An iDC shall be located in a place where earthquake damage is expected

to be minimal. (Be sure to avoid places close to active faults pointed-out in documents, or places pointed-out in documents that have suffered liquefaction damage in the past.)

2 Basic An iDC shall be located outside of dangerous zones designated in hazard-maps, etc. publicized by the MLIT or the local governments

3 Basic An iDC shall not be located in a place where a flood caused by tsunamis, high-tides, or torrential rains is expected.

4 Basic An iDC shall not be located in a place within {100 meters} of which the total number of hazardous-material producing facilities or high-pressure-gas producing facilities located exceeds that designated by the Fire Defense Law.

5 Basic An iDC shall be located in a place accessible by maintenance-service providers within {30 minutes}.

5.3.3. Facility / Machine Room Requirement A facility requirement refers to a requirement for a facility, such as quake-resistant structure of a

building or duplexing of telecommunication equipment. A machine room requirement refers to a

requirement for the installation environment for racks or equipment, etc.

Functional Requirement 1 Basic Employment of a quake-resistant or quake-absorbing structure against

an earthquake of intensity 6 upper. 2 Selective Employment of a fire-alarm (fire-protection) system compliant with the

Building Standard Act and the Fire Defense Law, or a system capable of sensitively catching changes in the room environment to detect early signs of a fire.

98

3 Selective Employment of fire-extinguishing equipment that is water-proof against the floods caused in fire-fighting activities, and of zero-ozone-depleting coefficient. Or, employment of nitrogen-fire-extinguishing equipment for the purpose of protection against the floods caused by fire-fighting, environmental protection, and the avoidance of influence on human bodies.

4 Basic Buildings with more than {2} doorways for ensuring more than one evacuation route available.

5 Basic Capacity for installing more than {2} provider-independent telecommunication lines running on different routes.

6 Basic Structure of machine rooms protecting the rooms from being viewed from outsides, such as a windowless structure.

7 Basic Free-access floor that resists against more than {500} gals of maximum of acceleration. In the case where the building is of quake-absorbing structure, the building or the quake-absorbing equipment shall resist against the acceleration mentioned above.

8 Basic Machine-room with ceiling height of more than {2,400} millimeters, excluding the height of a free-access floor.

9 Basic Free-access floors able to resist against more than {600} kg / m2 of the floor load including the equipment separately purchased and the racks implemented with equipment.

10 Basic Machine-rooms compartmented against fire. 11 Basic Provision, for security reasons, of individual compartments separated

from the spaces for other users. Or, the racks are able to be locked user by user for the separation of users.

12 Basic Provision of the installment environment (functions) specified in the specification of racks or equipment separately purchased.

Non-functional Requirement (write only when individually specified) Environmental Requirement

Basic Certification of compliance with the international standards of environmental management systems, ISO14001.

5.3.4. Power / Air-conditioning System Requirement A power / air-conditioning system requirement refers to a requirement for power / air-conditioning

systems for redundancy-ensuring such as duplexing of those systems. Functional Requirement 1 Basic Full-non-interruptive access to electricity even during periods of legal

inspection. 2 Basic Employment of uninterruptible power supply systems (UPS), constant

voltage and constant frequency units (CVCF), and power generators. The generators shall be operative fully-undisrupted, by re-fueling through all the period they are used,

3 Basic Availability of more than {2} external power-supply routes / methods, and redundancy of electricity ensured in the facility by duplexing, etc.

99

4 Basic Employment of air-conditioning systems with redundancy ensured by duplexing, etc. Such systems shall be continuously operable for more than {24} hours in a situation where water supply is lost due to natural disasters.

5 Basic Capability of providing the power supply systems (functions) specified in the procurement specifications of racks or equipment separately purchased.

6 Basic Capability of providing the air-conditioning systems (functions) specified in the procurement specification of racks or equipment separately purchased.

5.3.5. Security Requirement A security requirement here refers to a physical security requirement.

Functional Requirement 1 Basic Authentication-for-security mechanisms for the entry to the building and for

entry to the machine room are independent to each other; and in addition, security measures at the entrances, by such means as the stationing security guards.

2 Basic Automatic security systems [such as intrusion detectors, surveillance cameras, or entry / exit management systems, etc.]

3 Basic Management of entry / exit operating on a 24 hour / 7 day basis. 4 Basic Employment of Identification systems, such as IC card systems or

biometric identification systems for managing entry / exit to / from the rooms inside the iDC, and monitoring cameras in shared spaces or server rooms.

Non-functional Requirement (write only when individually specified) Assessment / Certification of Security

Basic Certification of compliance with “Information Security Management System (ISMS) Compliance Evaluation System (JIS Q 27001, ISO / IEC27001),” and a permission as a business operator to use the privacy mark.

5.3.6. Operational Requirement An operational requirement refers to a requirement for maintaining / managing the iDC facility

Functional Requirement 1 Basic Development of a management unit on a 24 hour / 7 day basis of iDC

facilities and a contact office for problem management, etc. 2 Basic Execution of inspections of the iDC facilities based on time table, etc.

5.3.7. Compatibility with Virtualized Systems Functional Requirement 1 Basic Capability of implementing the software products used in the

physical-server environment in the environment realized by virtualization mechanisms, etc., which consist of virtualized guest-servers and virtualized networks, so that such software products work in the same way as they do in the physical environment.

100

5.4. SOA Related Functions

5.4.1. Definitions 5.4.1.1. SOA(Service Oriented Architecture)

SOA is an architecture that enables “services” — software functions corresponding to the individual

job-operations — to be accessible and linked to each other on a network by the standardized

protocols and work as an integrated system. At present, such architectures are generally compliant

with the Web service technical specifications. The architecture also ensures prompt system

constructions and high maintainability, by defining interfaces between services and linking them on

the network.

Enterprise Service Bus

Business Process Management

Mashup Portal

Adapters

Management Development Environment

Service Repository /

Registry

Business Activity Management

Service Intermediation, Security / Policy Management

Messaging, Connection, Information Delivery

Application Monitoring, Management of SLA and KPI

Organizing Business Processes Compatible with Standards, Workflow Management

Providing Connections to Web Services, Legacy Systems, Data Bases, ERPs, banckback-end Systems, Custom-Application & Service, or JCA

Providing IDE or Application-Development Framework

Providing MashupService as the Front-Gateway

Web Services Protocol

Infrastructure Security, High-Reliability Message, Transaction

Centralized Management of Information on SOA Services

ERP / Legacy Application Custom Application / ServiceWeb Service Business Intelligence

Figure 5.4-1 Major Components in SOA

Functions and Services of SOA Function / Service Definition Business Process Management

Supports the execution of business processes through defining combination and flow control for different services.

Enterprise Service Bus Realizes the integration of services by enhancing the independency of services from others and assuring the message reliability by means of encapsulation of interfaces between the applications distributed.

Management Intermediates services and manages security and policies.

101

Mashup Portal Works as a front gate way and provides the mash-up services. Business Activity Monitoring

Monitors job-operations and processes, associates SLA or KPI (Key Performance Indicators) with the actual business processes, and visualizes them.


Provides IDE for the development of SOA services and a framework for the development of applications.

Service Repository / Registry

Enables the life-cycle management of services through registering, publicizing, and searching the information on SOA services, and at the same time enables job-applications to call services dynamically.

Adapters Provide connections to web services, legacy systems, databases, ERPs, back-end systems, custom applications, and services.

Web Services Protocols Enable integration of applications existing on the different platforms using the internet technical standards. For details, refer to “Function / services of web service protocols.”

Note that the following are additional descriptions on some of the functions or services in the table

above:

An Enterprise Service Bus provides messaging or data-conversion functions for the realization of the

integration of applications;

Business Process Management, which manages individual services, realizes job-applications by

combining services and controlling their execution by use of adapters (through web service

protocols);

Business Activity Monitoring collects the performance data and alert information from the Business

Process Management, and displays it as job-process information in a visualized form;

Mashup Portal Service receives information-contents or data from the Business Process

Management, and provides the users of the system with the contents or data in a mashed-up form;

Service Repository / Registry will support the environment for easy mash-up development through

providing the SOA information.

System administrators and developers on the provider side also benefit from the SOA functions for

management in the collection of service-log information or statistical monitoring information. In

addition, from the development, they benefit from the development environment because it provides

an integrated environment for the development of applications with resistance to changes because of

the separation of services and interfaces.

102

Figure 5.4-2: SOA Components and Their Relations

5.4.1.2. Web Service Protocol Web Service Protocol collectively refers to technologies for linking applications distributed on

networks: it is a mechanism enabling collaboration with applications on a different network, or a

mechanism enabling the creation of new applications or services by linking web-services realized on

the basis of web service protocol.

Figure 5.4-3: Fundamental Component of Web Service Technology

103

Functions / Services of Web Service Protocol Function / Service Definition Base Technology Publicizes descriptions of services — what functions the

web-service has, or what requests are required for using them. In addition, it authenticates a service published for use to exchange messages.

Security Service Component

A Service component, selective and usable with others: it enables a web service to enhance its function to realize the integrity and confidentiality of a message.

High-Reliable Messaging Service Component

Service components, selective and usable with others: They enable a web service to enhance its function to improve message-reliability in the communications with applications distributed on networks.

Transaction Service Component

Service component, selective and usable with others: it enables a web service to enhance its function to realize transactions to applications distributed on networks.

5.4.1.3. Common Technology Standard It refers to a standardized technology, commonly used as the basis of SOA or web service protocol:

it ensures the realization of highly-interoperable functions or services.

Function / Service of Common Technology Standard Function / Service Definition Common Technology Standard

Technology standard used as a basis of SOA or Web service protocol

5.4.2. Business Process Management Functional Requirement 1 Basic Provision of data-manipulation functions for defining data or control-flows for

business process 2 Basic Capability of defining processes by combining and using functions such as

service-calls, data-manipulation, malfunction notification, exceptional processing, or process-termination

3 Basic Capability of executing management jobs according to the standards for communicating with services (Web service protocol, etc.) or implementation-rules.

Non-functional Requirement (write only when individually required) Backup Additional Saving backup of business process configuration information

5.4.3. Enterprise Service Bus Functional Requirement 1 Basic Provision of a common back-bone with a configuration independent from particular

network-transport technologies for linking different systems 2 Basic Capability of transforming data or communications based on one protocol to that

based on a different protocol

104

3 Basic Capability of converting data in one format to that of other format 4 Basic Capability of routing messages according to their contents 5 Basic Capability of sending messages without loss between remotely-distributed

applications in a situation when malfunctions in applications or the network occurs, in order to enable roll-back transactions to notify errors, or re-sending transactions after the problems have been resolved

6 Basic Capability of being used independently from, or without disturbing, the processes of other components using the bus

Non-functional Requirement (write only when individually required) Backup Additional Saving for backing-up the setting information of service linkage

Related Technology XML Query Language

X Query: Query language of XML data

XML Transformation Language

XSLT: language for specifying transformation scheme of XML data

5.4.4. Management Functional Requirement 1 Basic Capability of defining policies for controlling service-operations (access-policies,

logging-policies, or contents-verification, etc.), or monitoring schemes for access or execution of services

2 Basic Capability of applying policies without modifying existing services 3 Basic Capability of centrally managing and visualizing statistics of monitored information

Non-functional Requirement (write only when individually required) Backup Additional Saving backup of policy-settings and statistical monitoring information

105

5.4.5. Mashup Portal Functional Requirement 1 Basic Provision of functions for combining more than one service interface into one portal

application 2 Basic Capability of modifying UI without needing to modify the business logics of existing

applications

Non-functional Requirement (write only when individually required) Backup Additional Saving backups of settings related to the configuration of portal

applications

5.4.6. Business Activity Monitoring Functional Requirement 1 Basic Provision of functions for monitoring job-operations or processes and visualizing

them 2 Basic Provision of functions for analyzing the actual business processes in comparison

with an SLA or KPI, and visualizing them 3 Basic Provision of functions for monitoring job-operations and processes and raising alerts

Non-functional Requirement (write only when individually required) Backup Additional Saving backup of information obtained through business process

monitoring

5.4.7. Development Environment Functional requirement 1 Basic Provision of the Integrated Development Environment (IDE) for developing SOA

services 2 Basic Provision of an application development framework for developing SOA services 3 Basic Capability of supporting the entire life-cycle of SOA service development (modeling,

program-development, debugging, testing, profiling, tuning, deployment). In addition, to be executable from the IDE

Non-functional Requirement (write only when individually required) Backup Additional Saving backup of source-codes and configuration settings used in the

SOA service development

Related Technology Design Notation UML (Unified Modeling Language): an unified notation for program-design

used in the software development phase, developed by OMG and based on the object oriented method

106

5.4.8. Service Repository / Registry Functional Requirement 1 Basic Provision of a mechanism for registering, publishing, and searching of information on

SOA services, based on the standards 2 Basic Capability of imposing access-permission of search, acquisition, modification, or

deletion on any component 3 Basic Provision of management-interfaces for registering, publishing, or searching

published SOA services

Non-functional Requirement (write only when individually required) Backup Additional Saving backup of settings on service repository / registry 5.4.9. Adapter Functional Requirement 1 Basic Connections to [web services, legacy systems, databases, ERPs. Back-end

systems, or custom application systems] 2 Basic Capability of allowing synchronous-calls of application- transactions, work-flows,

query-application data 3 Basic Capability of allowing transmission or receipt of events to or from

central-job-application

Non-functional Requirement (write only when individually required) Backup Additional Saving backup of connection settings

Related Technology Web Service Description Language

WSDL (Web Service Description Language): a specification of description of web-service interfaces in XML language

Industry Standard

Industry standards used in business fields, such as XBRL (eXtensible Business Reporting Language: XML vocabulary for financial data description, UN / CEFACT CCL (Core Component Library): coded information-items used in various industry segments), or the government standard

5.4.10. Web Service Protocol 5.4.10.1. Web Service Protocol (Base Technology) Functional Requirement 1 Basic Use of internet-standard communication protocols (TCP / IP or HTTP) 2 Basic Provision of a mechanism for realizing message-exchange or procedure-call based

on XML 3 Basic Provision of an environment for developing and deploying web services 4 Basic Provision of a mechanism for realizing data-transmission or receipt to or from web

services

107

5 Basic Capability of defining what function a service has or what request is required for using the service

Non-functional Requirement (write only when individually required) Performance Additional Configuration with a sufficient processing power for avoiding an

unallowable delay of the processing of the existing programs, while a web service protocols are being processed

Backup Additional Saving backup of settings of web service interfaces

Related Technology Web Service Communication Protocol

SOAP (Simple Object Access Protocol): XML-based protocol for calling data or services existing on other computers

Web Service Description Language

WSDL (Web Service Description Language): specifications for describing web-service interfaces in XML format

Web Service Interoperability Profile

WS-I Basic Profile: a guideline for the enhancement of the interoperability of SOAP-message-exchange or WSDL descriptions. The V1.1 agreed in WS-I is the present ISO standard as follows ISO / IEC 29361::2008 — WS-I Basic Profile Ver. 1.1 ISO / IEC 29362::2008 — WS-I Attachments Profile Ver. 1.0 ISO / IEC 29363::2008 — WS-I Simple SOAP Binding Profile Ver. 1.0

5.4.10.2. Web Service Protocol (Security Service Related Component Functional Requirement 1 Basic Provision of a mechanism to assure the integrity and confidentiality of message

content 2 Basic Ensuring of the availability of [the attachment of a digital signature, the attachment of

user-authentication data (token), or the encryption of messages]. In addition, the capability of protecting the security of them.

3 Basic Configuration allowing any standard signature or encryption algorithm 4 Basic No requirements of modifications on the processes of components related to other

web-service protocols

Non-functional Requirement (write only when individually required) Performance Additional Configuration with sufficient processing power to prevent running

programs from disturbance during signature processing or encryption processing.

Backup Additional Saving backup of settings for message integrity and confidentiality of a message

Related Technology Web Service Security

WS-Security: technology base for realizing the security of web-services, by specifying the method of implementing the existing security technologies such as XML-signature or XML encryption into a header of a SOAP message, and providing a common base for integrating security

108

technologies. Secure Communication Protocol

SSL (Secure Socket Layer): protocol for transmitting or receiving encrypted data on the internet

5.4.10.3. Web Service Protocol (High-Reliability Message Related Service Component) This sub-section stipulates here only the title, because more discussions are expected to be

required before such an item is actually procured.

5.4.10.4. Web Service Protocol (Transaction Related Component) This sub-section stipulates here only the title, because more discussions are expected to be

required before such an item is actually procured.

5.4.11. Common Technical Standard

Related Technology XML Description Language

XML (eXtensible Markup Language): a markup language for describing structured data or documents

XML Schema Language

W3C XML Schema: a schema language for defining structures or data-types of XML documents

109

5.5. Maintenance Environment

5.5.1. Definition Maintenance Environment refers to a physical work-environment for maintenance or management

of systems: it is, after systems’ cut-over, used for functional enhancement of application programs, or

verifications of version-ups, required on the expiration of the support contract, of software, such as an

OS, commercial software packages, or open-source software, etc. More specifically, it contains

maintenance process manuals for methods and maintenance procedures of systems including the

(actual) operation-environment, hardware / software used in maintenance work, maintenance tools

(development tools), and automatic test tools.

The maintenance environment is completely independent of the “development environments”

installed in vendor sites and used for software development: it consists of the following; the Software

Engineering Environment used for support works such as software maintenance, modification, or

correction, etc.; and the Software Testing Environment used for software tests.

PCs for Development-work in Maintenance

Development Tool (Maintenance Tool)

Test Tool (for unit-test or functional test)

Version Management (Configuration Management Tool)

Conf iguration Management Server

Staging Environment

Test Tool (for Vulnerability Test)

Test Tool (for Stress Test)

Test Environment (for Acceptance Test)

Build Tool

Development LAN

Job-Operation (actual) Servers

PCs for LAN System Operator

Job-Operation (actual) LAN

Inter network (Bridge) LAN


Software Engineering Environment Software Test Environment

Test LAN

Firewall (or Router)

Firewall (or Router)

Figure 5.5-1 Schematic Diagram of Maintenance Environment

110

The following table describes the definition of functions or services in the maintenance environment.

Function / Service Definition Maintenance Process Refers to methods and procedures for correcting or modifying

system configuration items (CI) such as hardware or software, etc. Audit Process Refers to methods and procedures for confirming that the

information security rules have been applied compatibly and properly.

Development Tool Refers to methodologies, processes, and tools for design / development / maintenance, or an aggregation of tools (Integrated Development Environment: IDE)

Configuration / Version Management Tool

Refers to a tool for managing versions of application programs or documents — design documents or procedure manuals — expected to be updated frequently: it is used for, controlling and recording modifications on hardware, software, or firmware throughout systems’ lifetimes., By collectively managing the information of configuration items (CI) used in development or operational environments, it provides configuration information for maintaining the integrity of the system.

Development LAN Refers to an internal LAN used by the software engineering environment: for the security reasons, it is physically and logically separated from the job-operation (actual) environment.

Test LAN Refers to an internal LAN used by the software test environment: for the security reasons, it is physically and logically separated from the job-operation (actual) environment

Inter network (Bridge) LAN

Refers to an internal LAN used for connecting the development LAN and the job-operation (actual) LAN: in some cases where those LANs are separated logically, the inter network (Bridge LAN) is replaceable with equipment such as switches or routers, etc.

Test Environment (for Acceptance Test)

Refers to an environment for verification work such as builds, connection tests, system tests, or regression tests of the application programs after completion of a unit test by the vendors

Test Tool Refers to a test tool used in the maintenance environment, for the purpose of preventing system deterioration or performance-degradation accompanying system modifications, to ensure efficient execution of regression tests or performance tests

Staging Environment Refers to a test environment of a similar scale of system configuration (both hardware and software) to that of the job-operation (actual) environment: it is used for checking security-patches or bug-fix patches before the application to the job-operation environment for confirming that the application of those patches causes no troubles. In some cases, it is constructed on visualized servers and storages.

111

5.5.2. Functional / Non-functional Requirements for Maintenance Processes The Maintenance Process defines the actions, methods, and procedures required in a case of

hardware or software malfunctions or functional modifications, in job-operation (actual) environments

or development environments.

Functional Requirement 1 Basic Complete definition of methods or procedures of works to be done in the phase

starting at the completion of development and the beginning of system operations, and ending at the termination of operations and abolishment of system

2 Basic Clear definition of rules such as a rule of request for modification or a rule of approval of modification

3 Basic Definition of maintenance process for each of the job-operation (actual) environment and the maintenance environment

Non-functional Requirement (write only when individually required) Integrity Basic Definition of the maintenance process consistent with the

system-lifecycle and the requirements defined in procurement plans, procurement specifications, and basic system design documents.

Related Technologies IT Service Management

Refers to a mechanism for executing the management and operations of IT services matching the level of customer-requirements, and continuously improving the service quality. ISO / IEC 20000, JIS Q 20000, ITIL v. 3

Software Maintenance

Refers to a series of modification-work of codes and documents of software for resolving malfunctions, or satisfying requests for improvement or requests for compatibility to new environments. ISO / IEC 14764, JIS X 0161

Software Lifecycle Process (SLCP)

Refers to a framework on which the parties involved in software development define the details of various works to prevent mutual misunderstanding among them. ISO / IEC 12207, JIS X 0160, Common Frame 2007

Information Security Management

Refers to a management method of establishing, implementing, operating, monitoring, reviewing, and improving / maintaining information security in accordance with polices for avoiding business risks. ISO / IEC 27002, JIS Q 27002

Software Engineering

Refers to activities for improving software or its development / maintenance work, through using theories, methods, and software development or maintenance expertise. SWEBOK2004 (ISO / IEC TR 19759)

112

5.5.3. Functional / Non-functional Requirements for Development Tools Development Tools consist mainly of an IDE used for upgrading or functionally enhancing software,

and test tools for automatically testing application-programs under development.

Functional Requirement 1 Additional Capability of debugging programs source codes 2 Additional Capability of assisting source-code-refactoring in a case where

object-oriented languages are used 3 Additional Capability of, in coordination with test tools, automatically executing tests

and automatically generating templates of test-programs suitable for test targets in a case where object oriented languages are used

4 Additional Capability of automating code-generation processes in coordination with build-tools

5 Additional Capability of assisting team-development through the coordination with the configuration management / version management tools

6 Additional Availability of stand-alone development terminals in a local environment or alternatively, a team environment which allows access to the resources of the development environment through network connections

7 Additional Capability of coordinating with configuration / version management tools 8 Basic Capability of compiling source-codes to binary codes, and packaging the

compiled codes 9 Additional Capability of automating build-work or preparing scripts for build-work, for

the purpose of improving quality and productivity

Non-functional Requirement (write only when individually required) Compatibility Basic Version-level-compatibility with the languages such as [C#, Java,

C++, etc.], and the development frameworks such as [OSS such as Struts, Turbine, Spring, Hibernate, Seasar2, etc., or compatible commercial products], used in the development phase

Related Technologies Development Language

C# JIS X 3015 2006, ISO / IEC 232702006 JAVA TRX X 0005-1: 2006 COBOL85 JIS X 3002. 1992, ISO / IEC 1899: 1985 COBOL2002 ISO / IEC 1989: 2002 FORTRAN77 JIS X 3001:1982, ISO / IEC 1539: 1980 FORTRAN90 JIS X 3001. 1994, ISO / IEC 1539: 1997 FORTRAN95 JIS X 3001-1: 1998, ISO / IEC 1539: 1997 C++ JIS X 3014: 2003, ISO / IEC 14882: 2003 C JIS x 30102003, ISO / IEC 9899: 1999

Development Framework

Apache Struts (1.2.x, 1.3.x.), Apache Struts2 (2.0.x.): Application framework designed based on MVC design Jakarta Turbine: Application framework based on servlet. Version 2.3.x. and its derivatives are mainly used. Spring 2.5.x: Application framework composed by small components framework Hibernate 3.3.x: Object-Relation Mapping framework

113

5.5.4. Functional / Non-functional Requirements for Configuration / Version Management Tools

The Configuration / Version Management tool manages modifications on the following in the entire

system life-cycle, from development to abolishment, through the collective management: all

information of the configuration items (CI) used in the system; hardware configurations; and versions

of application-source / execution files.

Functional Requirement 1 Additional Capability of recording all information on modifications on the configuration

items (CI) used in the system — including why, what, and by whom the modifications were executed, through the coordination with back-tracking tools

2 Basic Capability of centrally managing versions of the entire system 3 Basic Capability of simultaneously allowing more than one vendor to implement the

modifications, and merging differences in any revisions resulted from such parallel development

4 Basic Authentication function for prohibiting non-authorized users from system access 5 Additional Capability of permitting checking-in or checking-out, in coordination with the

integrated development environment (IDE) included in the maintenance tool 6 Additional Capability of finding what and how, according to which

specification-modification, files have been modified by collectively managing all the revision information preserved in the configuration management repository

Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced availability

by means of redundant hard-disk drives Security Basic Employment of a configuration protective against security risks such

as illegal access, information leakage, or falsification of settings, etc.

Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc.

Expandability Basic Configuration allowing flexible performance enhancement for catching up with the expansion of target systems or the contents

Back up Basic Capability of backing-up all the preserved data and the entire environment

Related Technology Software Configuration Management Process

Refers to activities of keeping records of changes in software configurations or configuration items throughout the software lifecycle, for the purpose of re-creating any of the situations in the past as required. ISO/IEC TR 15846

・The chapters or sections shown below of the Operation Manual describe what mentioned is above: 3.(2){3}a Management of Source-Code Modification History, etc. (pp.49), Chapter 3 Procedures of Separated Procurement; 4(3) Source Code Related Matters (pp. 66), Chapter 4: Management of Project on Separated Procurement

114

5.5.5. Functional / Non-functional Requirements for Test Environments (Acceptance Test Environment)

Test Environment (Acceptance Test Environment) refers to an environment for executing builds,

integration tests, and system tests for applications produced on the development environments of

contracted venders.

Functional Requirement 1 Basic Capability of executing builds of program sources generated on development

environments 2 Basic Capability of executing integration tests, system tests, and software validation tests 3 Basic Capability of creating and maintaining more than one environment in a physical test

environment (Acceptance Test Environment) by means of creating more than one AP server, or utilization of virtual environments, etc.

4 Basic Authentication function for prohibiting un-authorized users from access


by means of redundant hard-disk drives Security Basic Employment of a configuration protective against security risks such

as an illegal access, an information-leak, or a falsification of settings, etc.

Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc.

Expandability Basic Configuration expandability for keeping up with the expansion of target systems or contents preserved there

Back up Additional Capability of backing-up all the preserved data and the entire environment

115

5.5.6. Functional / Non-functional Requirements for Test Tool The Test Tool refers to a system for testing: it consists of tools for automatically executing

procedures for individual test cases, and management tools for preserving test-results in databases.

Functional Requirement 1 Additional Capability of automating tests by means of automatic execution of test scripts

(test cases) or test tools 2 Additional Capability of managing test-results in conjunction with test-cases through

coordinating with configuration management tools 3 Additional Capability of managing, in an integrated way, information on testing such as

requirements (specifications), test-cases, test-scripts, or test-results, etc. 4 Additional Capability of automatically collecting, summarizing, and analyzing test-result

data generated by automatic-test tools 5 Additional Capability of allowing the Integrated Development Environment (IDE) to

integrate and use the test-tools for unit-tests or function tests 6 Additional Employment of stress-test tools with a capability of generating large amounts

of transactions by multiple servers, and functions for collecting test-results generated by the servers-on-test onto test-control terminals, so that functions for distributing loads, such as load balancing, are testable

7 Additional Capability of executing regression tests

Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced

availability by means of redundant hard-disk drives, etc. Security Additional Employment of a configuration protective against security risks

such as illegal access, information leakage, or falsification of settings, etc.

Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc., in addition, a hardware-software configuration with performance and functions equivalent to those of the operation-environment in the case of performance tests.

Expandability Additional Configuration with flexible expandability for keeping up with the addition of test-tools or updates

Back up Additional Capability of backing-up test environments and test data

116

5.5.7. Functional / Non-functional Requirements for Staging Environment The Staging Environment refers to an environment used for checking whether software

modifications will cause troubles or not, such as the application of patches on OSs or software, etc.

for the enhancement of security levels. Note that the Government Standards recommends that the

verification of those patches should be executed on the environments such as a Staging Environment

for evaluation in advance of their application to the job-operation environment.

Functional Requirement 1 Additional Employment of hardware and software configuration equivalent to that of the

operation (actual) environment with the equivalent functions and performance 2 Additional Capability of constructing staging environments on the basis of virtual servers

and storages realized by virtualization software products, in a case where the equivalent hardware devices to those used in the operation(actual) environment are not available. In the staging environment realized in the virtual environment, the equivalent software products equivalent to those used in the operating environment shall be installed and perform the equivalent functions to those in the operating environment.

3 Additional Availability for users’ education / training of procedures inexecutable in the operation (actual) environment including updating processes

4 Additional Capability of executing performance-tests or stress-tests, etc. with same level of data or load as that of the operation (actual) environment in cases of constructing the staging environment without using virtual environments

5 Basic Implementation on a different physical environment or on a virtual environment existing on a different physical environment from the operation (actual) environment, so that evaluations of patches required in advance of the application to the operation (actual) environment, or tests by re-creations of malfunctions on the operation environment are executable.

6 Basic Authentication function for prohibiting un-authorized users from access


by means of redundant hard-disk drives Security Basic Employment of configuration protective against security risks such

as illegal access, information leakage, or falsification of settings, etc.

Performance Additional Configuration ensuring sufficient processing power for executing final tests estimated by clearly defining performance requirements in-advance

Expandability Additional Configuration with flexible expandability for keeping up with enhancement or upgrading of operation-environment

Back up Additional Capability of backing-up the entire staging environment, including backing-up the entirety of each server in the case when virtual servers are used.

117

5.5.8. Functional / Non-functional Requirements for Development LAN, Test LAN, Inter network LAN (Bridge LAN)

The Development LAN and Test LAN are internal networks closed off in a building and dedicated to

the maintenance environment. An Inter Network LAN (Bridge LAN) is a network to connect a

Development LAN and Test LAN to the operation (actual) LAN. The government standards requires

the clear separation of the maintenance environments from the operation environment.

Functional Requirement 1 Basic Separation of Development LAN / Test LAN from the operation (actual)

LAN by physical configurations or by VLAN, etc. 2 Additional Implementation of communication equipment such as switches or

routers, at the connection points of the Development LAN or Test LAN to the operation (actual) LAN, for the purpose of blocking communications except for those between permitted terminals or servers.

3 Additional Dedication of the Development LAN, Test LAN, or Inter network LAN (Bridge LAN) for internal use without connections to external networks such as the internet.

Non-functional Requirement (write only when individually required) Availability Additional Capability of redundantly installing network-equipment

according to situations Security Basic Capability of controlling communications between the

maintenance environment and the operation (actual) environment by means of filtering functions of routers or switches, etc.

Performance Additional Configuration ensuring sufficient processing power as a test environment for the maintenance environment, by clearly defining the performance requirements in advance

Expandability Basic Configuration that allows flexible enhancement of processing power for keeping up with functional enhancement or version-up of the maintenance environment

Related Technology Refer to “Related Technology” in 5.15. WAN, Ministry’s internal LAN. DNS / DHCP / Proxy.

118

5.5.9. Audit Process Audit Process refers to a process for verifying / evaluating how properly the risk control is prepared

/ executed in accordance with the risk assessment. Auditing activities include internal audits by the

internal-auditing department, and third-party audits by external organizations.

Functional Requirement 1 Additional To periodically execute internal audits and external audits (third-party

audits) on the operation environment, the development environment, and the test environment according to the “System-Audit Standards” prepared by the Ministry of Economy, Trade and Industry

2 Additional To confirm that proper actions have been taken according to the advice and recommendations by auditors.

3 Additional To be compatible with the “System Audit Standards” (revised on October 8, 2004), “Information Security Management Standards” (formulated on March 26, 2003), and the operational guidelines, prepared by the Ministry of Economy, Trade and Industry.

4 Basic To prepare medium-to-long term plans for system audits in order to effectively and efficiently check and evaluate information strategies and information systems for the fulfillment of business objectives. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government.

5 Basic To prepare basic plans for system audits annually according to the medium-to-long term plan. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government.

6 Basic To prepare individual plans for system auditing according to the medium-to-long term plan and the basic plan. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government.

7 Additional To, give a contract to experts outside the government for a part of the audit in accordance with the situation.

8 Basic To audit according to the individual audit plan 9 Basic To confirm that the design / development / operation / maintenance of the

target-system of the audit has been executed properly from the standpoint of reliability, safety, and efficiency

Non-functional Requirement (write only when individually required) Independency Basic The auditor shall not have strong position of interest with the

audited entity. Expertise Basic The auditor shall have the proper education and experience for

auditing, and have the knowledge and expertise for auditing. Authority / Responsibility

Basic The authority and responsibility of the auditor shall be clearly defined in documented rules or contract agreements.

119

Related Technology IT Internal Control Framework

IT Internal Control Framework refers to an IT-based mechanism for managing, monitoring, and assuring evidence that the job-operations are, according to rules and procedures of the organization, executed without illegal activities, irregularities, mistakes, or errors,. ISO/IEC 38500:2008、COBIT(R)4.1

CORBIT (R) is a trademark of the Information System Audit and Control Association: ISACA / IT Governance

Institute: ITGI). Descriptions on the contents of COBIT (R) are protected by the copyright of ITGI (R).

120

5.6. Servers

5.6.1. Definition A Server refers to a computer that provides functions, data, and services on the common platform

system, etc.

Because servers process requests from the terminals connected to the ministry’s internal LAN /

WAN or the individual business systems and return the results of processing, the server hardware

and the network, as well as its configuration, responsible for communications between servers, is

required to have high reliability, availability and maintainability.

Servers work for different roles (Web server, DB server, AP Server, etc.) according to the services

and functions they provide. The proper configuration or placement of such different types of servers is

indispensable: especially for the purpose of stable provision of services or for the preparation for the

future increase in system load, the expansion / enhancement method matching the server type must

be available, such as a scaling-up method (server configuration method enabling performance

increase by enhancing the performance or adding the number of the CPUs, etc. into a chassis) or a

scaling-out method (server configuration method enabling performance enhancement by adding a

server-chassis for parallel processing).

In addition, functions provided by servers are required to be allocated or configured so that a group

of servers providing the individual services can, by the application of virtualization software, be

implemented in a single physical server. Virtualization software, which refers to software that enables

a single hardware server to run more than one virtual machine, enables more than one operating

system to run on single server hardware with minimum loss of performance: the individual operation

system is allocated virtual CPUs, network interfaces, and storages. (Refer to Figure 5.6-2.)

Highly reliable, highly available, and highly maintainable servers, collaborating with storage

mentioned in Section 5.7, are able to realize distributed processing, and are expected to be further

visualized, consolidated, or integrated because of their adaptability to centralized and integrated

management.

Note that this subsection describes the servers installed in server rooms, and the network on the

server firmware access-layer (server LAN). For the descriptions on the core edge access layer such

as the ministry’s internal LAN / WAN, or the network as a whole, refer to the subsection 5.15.

Function / Service of Servers Function / Service Definition Server hardware Refers to server devices to process functions or services available

on the common platform system: it is required to have functions and configurations with high efficiency, reliability, availability, flexibility, and maintainability so that those functions and services work well even in a situation where operating systems, middleware, or applications are added, or changed, or the volume of information to

121

process is increased. Server LAN Refers to LANs or network equipment for communication between

servers on the common platform system Web Server Refers to software responsible for web-based information delivery or

hardware configured for the execution of such information delivery: it provides services for saving the data such as HTML documents or images, or retrieving and arranging, and delivering such data to the client on the request from web-browsers, etc.

DB Server Refers to programs that provide the services of saving and retrieving master-data or transaction data processed by the functions and services available on the common platform system, or the hardware configured for the execution of such services: it has the capability of high-speed processing of queries written in query languages. Note that the information on DB servers should be arranged so that it is available to queries made by the services or functions on the common platform system in such a way that the performance requirements (response time, throughput, capacity) are satisfied.

AP Server Refers to programs that execute and manage business logics contained in the services available on the common platform system, or the hardware configured for the execution of such logics: it works for providing interfaces to web services available on the common platform system, executing business logic, managing transactions, and connecting to databases, etc.

5.6.2. Schematic Diagram The diagram below shows the allocation of functions or services (server hardware, Server LAN,

Web Server, DB Server, and AP Server) in the infrastructure configuration model.

Server Hardware

Server LAN Storage

DB Server Web Server AP ServerTechnology Domain

Legacy Integration

Individual Job-Operation

Workflow BAM

Common Job-Operation

Legacy System

Back (Indiv idual)

Server

ERP Server

Workflow Server

System Linkage

Personnel and Payment System

Document Management

System

Budget Implementation Management

System (SEABIS)

Application Software Region

EAI External Linkage

Channel Region

Remote PC

the Internet Communication Equipment

Load Balancer

Load Balancer

Authentication Server

Public Web Server

Mail Server

Ministry Web

Server

Portal Server

Directory Server

Ministry Mail

ServerWeb-Service-Related Function

SOA-Related Functions(ESB, BPM, UDDI / Service Directory, Service Management)

Job-Operation PC

Process Region

Com

mun

icat

ion

Equi

pmen

t

Development Server

Application-Core Service

Technical Support


Application Platform Region

Information (Data) Region

DB Server

DWH ServerData

Exchange Server

Server

Legacy System

Common Element Region

Operation Management

Server

Operation Management

Security

Server / Storage (AP Server, Web Server, DB Server, etc)

Figure 5.6-1: Allocation of "Server" Services or Functions in the Infrastructure Configuration Model

122

Figure 5.6-2: Virtualization of Server Environment by Virtualization Software

5.6.3. Server Hardware Functional Requirement 1 Basic Capability of allowing the following to run;

an execution-basement for application programs operating on servers; and operating systems able to provide interfaces between the application programs and the execution-basement [Linux, Windows, and Commercial Unix, etc.]

2 Basic Capability of booting the operating system [Linux, Windows, and Commercial Unix, etc.] from the embedded disk-drive or an external disk-drive

3 Basic Network-equipment interfaces [Ethernet (IEEE 802.3) and RS-232C, etc.], and, in a case where connections to peripherals are required, [Serial ATA, PCI, SCSI2, SCSI3,iSCSI, SAS, Infiniband, FibreChannel, etc.

4 Additional Capability of collecting information for problem-management (including protection or detection) and providing information for that purpose, and the features of [e-mail delivery of failure point information, or failure-notification by SNMP trap, etc.]

5 Additional Capability of monitoring configuration or status-information of the server through interfaces compatible with the standard specification [SNMP or CIM, etc.]

6 Basic Operating system having a capability of providing the application programs with services and functions through APIs (Application Program Interfaces): the API shall be compatible with standardized and widely accepted specifications.

7 Basic Operating system is to be compatible with standardized and widely accepted specifications or equipped with command-utility functions based on CUI (Character-based User Interface), which is widely accepted

8 Basic A program (devise-drive program) that is able to control all the devices and executable on the operating system shall be available.

123

Non-functional Requirement (write only when individually required) Install Space (Chassis)

Basic The following shall be included in the server chassis, when it is referred to: processors (CPUs), memory, main boards, internal disk-drives (not required in case of servers where no internal disk-drives are necessary), peripheral interfaces, and power supplies, etc. • A server chassis shall have a configuration of [rack-mount, blade, tor tower, etc.] • In the case of a rack-mount configuration, each server shall be installable in a 19-inch server-rack {4U} compatible with EIA (Electronic Industry Alliance) standards. • In the case of a blade configuration, up-to six blades shall be installable in a 19-inch server rack {7U} compatible with EIA standards. • In other configurations than those mentioned above, the foot-print is {190 cm W x 200 cm D x 220 cm H} and the maximum weight per unit area shall be less than {100 kg / m2}. The load capacity of an ordinary office is around 100 kg /m2. However, because the load capacity over 1,000 kg / m2 is not extraordinary for data centers, server-equipment with the weight per unit of over 1,000 kg / m2 will be purchased under the condition that it is installed in a data center. Therefore, on the application of the specifications here, especially the exemplifications in {}, pay sufficient attention, and modify the value in {}, according to the facilities where the servers will be installed. If the facilities where such equipment will be installed are not determined, use the above-mentioned load capacity of office or of data center as a reference value.

Performance of Processors

Basic Sufficient power for satisfying requirements of job-operations. The processor power shall exceed {64 bit, operating frequency of 2 GHz, and 4 cores}, or satisfy the following: • The performance value in {SPECint 2006 base} shall be {30} or more. • The performance value in {SPECweb 2006 base} value shall be {5,000} or more. • The performance value in {SEPCfp 2006 base} value shall be {30} or more.

Processor Instruction-set Architecture

Basic Executable instruction-set architecture already made public, allowing third parties to develop application. [x86, x64, IA64, POWER, or SPARC, etc.]

Expandability of Processor

Additional Capability of expanding processors by adding processors or upgrading the processing power, in preparation for the expected performance-enhancement requirements of the future. However, in a case where the software running on the server is required by specifications to be expandable in

124

performance by means of scaling-out, the expandability on the side of servers is unnecessary.

Backup Basic Configuration that allows each of the operating systems used in the server to back-up the system or data stored in the internal or external disk drives.

Memory Capacity Basic Sufficient memory capacity to satisfy job-operation requirements or to process data: the volume of the mounted memory shall be {4 GB} or more, or {4 GB} or more of memory per a core processor shall be mountable.

Memory Expandability

Basic Capability of expanding the memory capacity in order to satisfy the processing requirements, to {16GB} or more at maximum, except for the cases where the software running is, according to its specification, capable of expanding its processing capacity by means of scaling-out.

Memory Availability

Basic Capability of, on the occasion of single-bit-errors, not depending on the operating system, automatically correcting the error in data without stopping hardware functioning, to continue processing

Additional Capability of, on the occasion of multi-bit-errors, not depending on the operating system, automatically correcting the error in data without stopping hardware functioning, to continue processing

Expandability of I / F transmission capacity

Additional Capability of expanding the data-transmission capacity by means of combining more than one I / F card, etc. in a situation where the required data-transmission capacity is not attained, except for the case where the software running is specified to have a capability of expansion of processing power by means of scale-outing, the expandability of I / F transmission capacity of the server is unnecessary.

I / F Availability Additional Capability of automatically continuing processing by the other healthy I / O interfaces of the same type when an I / O interface is in trouble due to a failure

I / F Maintainability Additional Capability of allowing the replacement of the troubled interface during system operation, or a capability of, by means of clustering, etc., allowing the replacement of the troubled interface without stopping the services provided by the system

Capacity of Internal / External Disk Drive

Basic Disk area capacity more than {100MB}, where the capacity means “physical capacity.”

Availability of Internal or External Disk Drive

Basic Capability of combining more than one [disk drive, or SSD, etc.] so that it works as a single device, for the purpose of preventing a loss of data a or stop of job-operations

Additional Capability of allowing the replacement of disk drives without stopping the server

Expandability of Disk Area

Basic Capability of expanding the data area up to {200 GB} maximum

Capacity of Power Basic Capability of supplying sufficient power to keep the server

125

Supply running Maintainability of Power Supply

Additional Capability of allowing power supplies to be replaced without stopping the server.

Availability of Power Supply

Additional Duplex configuration of power supplies to keep supplying the necessary power even in a situation where a single power supply is in trouble due to a failure

Availability of Power

Additional • Capability of keeping the server running for {longer than five minutes} by means of using an uninterruptible power-supply systems (UPS, etc.), in cases of problems in the power-lines such as an electricity outage • Capability of automatically putting the system in normal termination, in a situation where the abnormal state continues for longer than {five minutes}

Duplexing of Power Lines

Additional Power-line configuration of two power lines to supply power to the server for operation even in the case of maintenance / construction of the facility

Fault-tolerance Capability of Uninterruptable Power Supply System

Additional Capability of, even on the occasion of UPS malfunctions, continuing power supply by means of by-passing the UPS circuit, or a capability of the equivalent level of backing-up by means of a two power-line configuration, and notifying the system administrator of troubles.

Maintainability of Uninterruptable Power Supply System (UPS) Battery

Additional • Capability of self-diagnosing during running and notifying the administrator of abnormalities • Capability of sending a message to recommend battery replacement to the system administrator in advance before the system fails to continue normal operations • Capability of automatically executing battery checks every period of less than {two weeks} • Capability of raising battery alarms by an SNMP trap

Redundancy of Hardware Module

Additional Configuration to enable a single or a combination of more than one hardware chassis to duplex the major components [CPU, Memory, Hard-disk Drive, Power Supply, and Fan, etc.] for the purpose of continuing job-operations in a situation of failures on a single component. Not that, in the case where such redundancy is ensured by software functions, the requirement is unnecessary.

Procurement Lead-Time

Basic Time required for the addition of servers or implementation of new servers (Procurement Lead-Time) is less than {eight weeks} in normal situations.

Addition of Hardware Components

Additional Capability of executing the addition of hardware components of server — specifically, [processors, memory, physical disk-drives, or peripheral interface-boards, etc.] — without stopping the server, or to have a system configuration allowing the addition of hardware components without stopping services of the system by means of clustering.

Maintainability of OS / Middleware

Additional The following features are for maintenance: • Down time of the system service required for the application

126

of security patches to the system is shorter than {two hours}. • Time to the expiration of maintenance / support is longer than {five} years. • Down time of the system service required for the application of correction patches is less than {two hours}. • In a situation where the service-down-time required for the application of security or correction patches is predicted to exceed {two hours}, the down time of job-operations for longer than {two hours} shall be prevented by the manual operations of allocating the job-operations to an auxiliary server in the system with a redundant server configuration such as clustering, etc.

H / W Maintenance Term

Basic Term of support for the failures of hardware composing the server longer than {five} years.

Green Procurement

Basic Compatibility with the basic polices based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”

International Energy Star (Green IT)

Additional Compatibility with the International Energy Star Program

Related Technology Protocols for Monitoring and Control / Standard Interface Specifications for Server Management

SNMP (Simple Network Management Protocol) CIM (Common Interface Model)

Network Interface, or Peripheral Interface

Serial ATA, PCI, RS-232C, Ethernet (IEEE 802.3), Fiber Channel, SCSI2, SCSI3, iSCSI, FC-AL, FC-SW, and Infiniband

EIA Electronic Industries Alliance “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”

http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19bp.pdf

SPEC SPEC (Standard Performance Evaluation Corporation) SPECint, SPECfp

Kernel API Standard POSIX API Standard (ISO / IEC 9945-1) Linux Standard Base

Operating System Command / Utility Standard

POSIX Command Standard (ISO / IEC 9945-2.1993 Information Technology, IEEE Std. 1003.2)

Specifications of Battery Failure Notification / UPS Abnormality Notification

JEMA (Japan Electrical Manufacturers' Association) http://www.jema-net.or.jp/Japanese/standard/ups/

Criteria, etc. for Decisions of Manufacturers, etc. on

Criteria, etc. for Decisions of Manufacturers, etc. on Improvement of Performance of Electronic Computer,

127

Improvement of Performance of Electronic Computer

Announcement No. 194, Ministry of International Trade and Industry, March 31 1999, Final (Complete) Amendment, Announcement No. 50, Ministry of Economy, Trade and Industry, March 29 2006

5.6.4. Server LAN Functional Requirement 1 Basic Capability of communicating based on TCP / IP 2 Basic Capability of packet-switching in the data-link layer / network layer 3 Additional Network equipment with management-interface functions 4 Additional Function of traffic-control for setting or modifying bandwidth-limitation 5 Basic Function of a fire-wall, and to be equipped with communication lines with the

maximum effective-performance of {1 Gbps} or more and the maximum number of packets of {2 Mpps} or more

6 Basic Function of intrusion-detection and protection for the purpose of detecting and blocking an illegal access, with the maximum bandwidth of the connection being {1 Gbps} or wider

7 Basic Function for detecting falsification with a performance — the packet processing performance of the detector — of {2 Mpps} or more

8 Basic Function of virus-detection with a performance — the packet processing performance of the detector of {2 Mpps} or more

9 Basic Capability of configuring load balancers redundantly by means of implementing more than one load balancer; and, in a situation where a load balancer is experiencing problems, letting another pre-determined load balancer take over the sessions held by the troubled server in order to keep the users’ accesses undisturbed.

10 Basic VLAN feature for, creating virtual groups in the data-link layer independent of the physical connections: the group-creation capability of the VLAN feature is {16} or more.

Non-functional Requirement (write only when individually required) Bandwidth Basic Capability of realizing the communication speed of {1 Gbps,

theoretical} or higher Availability of Router / Switch

Additional Redundancy ensured by full-duplex internal-configuration of routers or switches or duplexing devices

Maintainability of Router

Additional Capability of completing the update of routing information or firmware held in a router within {five minutes} or less, or switching the network connection to redundant equipment, so that said up-date will not disturb the job-operations.

Easiness of Maintenance Activity of Router / Switch Operators

Basic Capability of managing routers / switches via the network. In addition, operations required in a problem situation, such as deactivation of ports or re-writing of routing information are executable via a different network reserved for maintenance.

Maximum Down Time

Additional Down-time of the LAN in the common platform system — the monthly longest time-span while the LAN is not available — is {one hour} or less.

128

Average Response Time

Basic Monthly average of node-to-node round-trip delay time (node: communication equipment or server) shorter than {100 ms}. Note that an assumption is available here that the network usage rate is within {30 %}.

Availability of Routing Function

Additional Capability of redundantly configuring paths in the data-link / network layer

Availability (Duplexing LAN)

Additional LANs have redundant configurations.

5.6.5. Web Server Functional Requirement 1 Basic Capability of, in return to a request from client PCs such as web browsers,

delivering the contents preserved on the Web server by HTTP or a compatible protocol; and creating and returning HTML data by executing programs

2 Basic Function of session-management for controlling log-in states or screen-transition

3 Basic Capability of, by means of IP authentication or user authentication, etc., authenticating web sites to give permissions (approval) to the sites; and collaborative authentication or permission with external directory services

4 Additional Capability of logging access-related information: IP address of the origin of access, time and date; accessed file names; destination page of link; name of the web browser used for access, or name of the OS; time consumed for processing; number of bytes received; number of bytes transmitted; and the service status code, etc.

5 Additional Capability of notification of an audit event: notifying, on a real-time basis, the administrator of an event of access-denial or non-authorized access.

6 Additional Capability of preparing audit reports: preparing summaries of log information as a report reviewable and browsable

7 Basic Capability of encrypting WWW-communication data, using protocols such as SSL or TSL, etc. — for the purpose of protection against data-spoofing, data-falsification, or spoofing)

8 Additional Capability of monitoring the services or functions provided by web servers for confirming that they are functioning normally; and, on the detection of performance degradation, notifying the integrated management tool of the problematic events, and saving data for later analysis and identification of the type and cause of problems.

Related Technology Communication Protocols TCP/IP LAN Standard Ethernet Virtual LAN (VLAN) IEEE 802.1Q Monitoring / Control Protocols SNMP(Simple Network Management Protocol) Green Procurement “Basic Policy for the Promotion of Procurement of

Eco-friendly Goods” http://www.jkiss.or.jp/green/siryo2.pdf

129

9 Additional Capability of managing configuration information of servers through PCs placed in remote sites

10 Basic Capability of load-balancing — collectively receiving processing requests bound for servers, managing the requests, allocating the requests to more than one server-group, and transmitting the requests to the allocated servers

11 Basic Capability of selecting the load-balancing method from the round-robin method and the response-time-based load-balancing method; and, in either method, terminating the allocation of processing to the servers that have failed to send-back responses within a predefined response-time

Non-functional Requirement (write only when individually required) Processing Power Basic Sufficient processing-power (number of requests processable per

second) estimated on the basis of the assumed service-request-level and peak value of usage

Server Expandability

Basic Capability of enhancing processing efficiency by means of balancing the load on more than one server for multiplex-processing

Server Expandability

Basic Capability of executing enhancement-work — addition or enhancement of web servers — without interrupting job-operations

Availability Basic Capability of, in the event of a problem on a single server, letting web-server software run on more than one server-hardware in order for the other healthy servers to take over the acceptance of requests coming after the event

Service Hours Basic Capability of providing web-services during the following service hours; {from 8 a.m. to 10 p.m. on weekdays}

5.6.6. DB Server Functional Requirement 1 Basic Composed of systems that manage databases of relational-type

data-representation (relational database management system) or XML database systems with a capability of handling XML data

2 Basic Capability of defining a database, accessing data, and controlling access, by executing programs written in a query language (Data Definition Language: DDL), a data manipulation language (DML), or data control language (DCL)

3 Basic Capability of transaction-processing

Related Technology Mark-up Language HTML Directory Service LDAP Dynamic Web-page Generation

JSP (Java Server Pages) Java Servlet ASP.NET

130

4 Basic Authentication and Permission: Capability of authentication and permission — by an identifier, identifying a user trying to access databases, and permitting the access when the user is authorized or denying otherwise Capability of, according to the user’s job-assignment, restricting user actions on each type of database object (table, view, or column)

5 Basic Capability of encrypting or decrypting data that is managed and maintained in a database; and choosing encryption scheme

6 Basic Audit: Function for auditing databases — logging the execution history of SQLs by users, notifying the management-tools, etc. of unauthorized accesses beyond the range of permission, or preparing a reviewable or browsable report summarizing the information saved in the logs

7 Basic Performance Management: Function for managing performance — monitoring the performance indicators of server components (transaction-processing throughput, and response-time, etc.) to confirm the normal provision of services, and, on the detection of evidence of performance degradation, optimizing processes automatically or manually.

Non-functional Requirement (write only when individually required) Availability Basic Configuration of one or the combination of the following to, in a

case of a malfunction, automatically detect abnormalities, and resume DB accesses in {ten minutes} or shorter:; • Fault tolerant • Hot-standby • Clustering • Mirroring

Processing Power Basic Sufficient processing-power to satisfy the performance requirements for databases (such as throughput or response time)

Data Capacity Basic Sufficient capacity to store the data handled in the common platform system with a volume of {2 TB}.

Expandability of Processing Power

Basic Capability of improving processing efficiency of database access by load balancing on more than one server by multiplexing processes, or by adding computational resources inside the database server

Database Fault-Tolerance

Basic Means for recovering the database-system and the data handled in the data-base system in a problem situation such as the destruction of data

Backup Basic Capability of online back-up Basic Capability of backing-up the difference or entirety of a table or

database Additional Capability of backing-up a whole storage medium (device)

Service Hours Basic Capability of providing database-functions during the following service hours; {from 8 a.m. to 10 p.m. on weekdays}

131

5.6.7. AP Server Functional Requirement 1 Basic Capability of providing web services, based on web-service technologies such as

SOAP or WDSL, etc. 2 Basic Employment of an infrastructure on which component applications made of Java

components or .NET components, etc. are created and executed 3 Basic Function and interfaces for the application programs running on the AP server to

connect to a database on the DB server for accessing data, 4 Basic Distributed Transaction: Capability of distributed transaction-processing —

processing a data-update request involving more than one database or server, as a single transaction

5 Basic Distributed Object: Function for enabling distributed-objects — programs located in remote-servers — to exchange messages with each other

6 Basic Security: To have security functions for protecting the AP server and the applications against the following threats: • Network Spoofing (between a Web server and an AP server, between an AP server and a DB server) • Illegal Access Where the protection functions are not necessarily implemented in the AP server it is possible such network spoofing functions are realized as a function of the entire system by using functions provided by network equipment, etc.; that protection against network spoofing does not necessarily require the encryption of communication if there is no possibility of AP communication packet-flows except for those between a Web server and an AP server or between an AP server and a DB server; and that, if the accesses to APs are limited to those from a Web server by address-restriction, the requirement for protection against illegal accesses is considered to be satisfied.

7 Basic Performance Management: Capability of managing performance with functions for monitoring the performance of DB-server components (transaction-processing throughput, and response-time, etc.) to confirm the normal provision of services; and, automatically or manually, optimizing performances on the detection of signs of performance degradation.

8 Basic Capability of delivering and broadcasting application programs and services to AP servers, and activating those applications and servers into a ready-to-use state

Related Technology DB Query Language SQL92

SQL99 SQL2003 XQuery Xpath

Directory Service LDAP Data Encryption Technology DES

AES RC4

132

9 Basic Capability of authenticating and permitting (approval) process-requests to an AP server; and executing such activities in collaboration with directory services outside the AP server.

Non-functional Requirement (write only when individually required) Processing Power Basic {Average number of transactions processed per second} {30} or

more. Server Multiplexing (Load Balancing) Function

Basic Capability of improving processing efficiency by distributing processes to more than one server

Multiplexing Threads (Mulithread Processing)

Basic Capability of improving the overall efficiency by creating and executing more than one thread in the server

Reliability of Request under System Overload

Basic Capability of, in a situation where the processing requests to the AP server are increasing (Heavy Load), queuing requests in wait on the AP server for preventing the loss of requests

Server Expansion and Dynamic Re-configuration

Basic Configuration that ensures server expansion, and execution of the expansion while the system is running — without interrupting the system

AP Server Availability

Basic Capability of monitoring the services and functions for confirming whether they are functioning normally (Alive Monitoring); and automatically detecting and recovering from malfunctions

Service Hours Basic Capability of providing services of an AP server for the following service hours; {from 8 a.m. to 10 p.m. on weekdays}

Related Technology Web Service Related Technology

Basic SOAP WSDL

Component Program Execution Infrastructure

Basic J2EE .NET

Database Access Technology

Basic OLE DB ODBC JDBC ADO.NET

Distributed Transaction Technology

Basic Java Transaction API (JTA) COM+

Directory Service Technology

Basic LDAP

133

5.6.8. Preparation for Virtualization 1 Basic Capability of installing the software equivalent to that in the physical server

environment, and allowing it to perform the equivalent functions in the virtualized environment composed of virtual guest servers, virtual storages, or virtual networks, realized by virtualization mechanisms

134

5.7. Storage

5.7.1. Definition Storage refers to an external memory device to store the information handled in the common

platform system.

The device assumed as storage in the common platform system is a hard-disk drive or tape drive.

High reliability and high performance is required for storage because it is used for storing data on the

requests from the terminals connected to the ministry’s internal LAN / WAN or the individual business

systems.

Storage must enable distributed processing through having high reliability, availability, and

maintainability in close linkage with the server described in 5.6. At the same time, because storage is

well controlled in an integrated way, further virtualization, consolidation, or integration will be

expected.

Functions and Service of Storage Function / Service Definition Disk Storage Refers to an external memory device for storing mainly the data,

database, and system data handled in the common platform system: here, a hard-disk drive is assumed as storage.

Tape Storage Refers to an external memory device for backing-up/ archiving / migrating / data-exchanging mainly the data, database, and system data handled in the common platform system.

5.7.2. Disk Storage Functional Requirement 1 Basic Capability of activating operating systems [Linux, Windows, or Commercial

UNIX, etc.]. 2 Basic Capability of combining more than one disk drive to make it work as a single

device for the prevention of data-loss or job-operation interruption in the case of a malfunction in a single drive

3 Additional Employment of a means of handling a situation of simultaneous malfunctions on more than one drive

4 Basic Space in an array device to install more than one spare disk 5 Basic Capability of access-controlling through zoning features [Fiber-channel

switches], or settings on the disk-drive 6 Basic Access control function of shared storages — a capability of denying

accesses from the unnecessary servers by using logical unit numbers [LUN] 7 Additional Employment of redundant configuration and sufficient capacity of power

supplies for preventing service-shutdown in a situation of a malfunction on a single power supply

8 Basic Employment of an I /O interface on a storage device, such as [TCP / IP, FC, FCIP, FCoE, SCSI, SAS, Infiniband, etc.]

135

9 Basic Function for assisting adjustment work such as access-performance tuning inside the storage, or optimization or expansion of configuration

10 Additional Capability of realizing malfunction management features for the proper management of storage — through the collection of information for fault detection and protection on the configuration modules (physical disk-drives, tape-drives, power supplies, cooling fans, I / O, control-devices and interfaces, cache memories, or I / O ports, etc.), using the functions owned by the storage, or operation management tools, etc.

11 Basic Function for remote-controlling — preserving configuration information and status of the storage, sending such information to the remotely-located integrated-management system or tools, or receiving requests for configuration changes from the remote sites

12 Additional Employment of, for the purpose of remote data-recovery, functions for saving the coherent data in a remote site to be recovered in the situation of a disaster for resuming job-operations or businesses

Non-functional Requirement (write only when individually required) Availability of Array Device

Basic Capability of accepting data-accesses continuously in a situation of a failure in disk drives through RAID technology, etc.; and automatically recovering data-redundancy.

Maintainability of Array Drive

Additional Capability of adding or replacing disk-drives without interrupting the operation of the storage

Configuration Change of Logical Disk Volume

Additional Capability of enabling the operating systems, which use the storage, to modify the configuration of the logical disk-volume, and add or replace logical disk-volume, without interrupting the system operation

Availability of I / O Interfaces

Additional Interfaces [TCP/IP, FC, FCIP, FCoE, SCSI, iSCSI, SAS, or Infiniband, etc.] of storage should have redundant configurations.

Bandwidth of Storage Data

Basic Employment of maximum data-transmission capacity between server and storage of {100 Mbytes / sec} or more

Expandability of Channel / Host Interface

Additional Capability of expanding data-transmission capacity by binding more than one interface of the same type, for a case where the required data-transmission capacity is unattainable

Transmission Capacity of Channel / Host Interface

Basic Data-transmission capacity of I / O channels or host interfaces {100 m bytes / sec} or more.

Data Capacity Basic Sufficient capacity to store {2 TB} of data handled in the common platform system

Data Volume Allocatable to User

Basic Capability of allocating an area of {1 GB} or more per user at maximum when users request allocation of memory-areas in NAS or file servers, etc.

Modification of Volume of Data Allocation

Basic Capability of enabling operation systems, which use the storage, to dynamically enlarge the allocated memory volume of the server where the operating system is installed

136

Back-up Additional Capability, as a feature of the storage device, of making a copy of a volume, independently of the operating system.

Availability of Power

Additional • Capability of keeping the storage alive {for five minutes or longer} by using uninterruptable power supply systems (UPS), etc., in the case of failures of power lines such as a power outage • Capability of automatically putting the storage in normal termination after {five minutes} or longer have passed since the abnormal event occurred

Multiplexing of Power Line

Additional Configuration of two-power-line-electricity-acceptance for holding power to keep the storage alive even during inspection / construction works

Fault Tolerance of Uninterruptable Power Supply System (UPS)

Additional Capability of continuing the supply of power in the case of UPS failure by bypassing the UPS circuit; or by a configuration of two-power-line-electricity-acceptance enabling the equivalent effect to that of USP-by-passing; and notifying the system administrator of the failure.

Maintainability of Batteries in Uninterruptable Power Supply System

Additional Capability of making a self-diagnosis during operation; and notifying the system administrator of the detected failures. • Capability of sending a message of recommendation about battery replacement in advance before the system falls into a state unable continue the normal operations • Capability of automatically executing battery checks every {two weeks} • Capability of raising battery alarms by an SNMP trap

Procurement Lead Time

Basic Time required for addition of storages or implementation of new storages (procurement lead-time) less than {eight weeks} in normal situations.

HW Redundancy Additional Hardware components composing a storage unit shall have redundant configurations, except for an emergency stop switch, back-boards, or a chassis, etc.

System Performance Value

Basic I / O performance value of the storage operations {larger than 10,000 SOC-1 bench mark} or equivalent.

Expansion of Storage Capacity

Basic Capability of allowing post-installation expansion of storage capacity up-to {5 TB} in total

Term of HW Maintenance

Basic Term of warranty for failures of storage hardware is longer than {five years}.

Green Procurement (Green IT)

Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Disk-Drive” of the “Basic Policies for the Promotion of Procurement of Eco-friendly Goods”).

137

5.7.3. Tape Storage Functional Requirement 1 Additional Employment of a redundant configuration and sufficient power-capacity for

preventing failures of a single power supply from causing service-interruptions

2 Basic Employment of I / O interfaces such as [SANFC、SCSI、or SAS, etc.] 3 Basic Capability of, by using features of the storage device or operation

management tools, etc., enabling malfunction-management functions for the proper management of failures through collecting information necessary for the detection and protection from failures on the configuration modules [tape-drive, power- supply, cooling-fan, control device and interface, cache memory, and I / O port, etc.]

4 Additional Function of automatically detecting or eliminating data-duplications on the occasion of data-saving

Non-functional Requirement (write only when individually required) Data Bandwidth of Tape Storage

Basic Maximum data-transfer volume between server and tape-storage {80 M bytes / sec} or more

Channel Transfer Capacity

Basic Data transfer capacity of I / O channel / host interface {100 M bytes / sec} or more.

Equipment Lead-Time

Basic Time required for the addition of storages or implementation of new storage procurement lead-time) shorter than {eight weeks} in normal situations..

Data-store Capacity

Basic Maximum volume of data storable in the tape-storage {10 TB} or more.

Related Technology Technologies for Reliability Improvement of Disk Drive

RAID, and Grid Storage

Storage Interface Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS, and Infiniband

Monitoring / Control Protocol SNMP (Simple Network Management Protocol) “Basic Policy for the Promotion of Procurement of Eco-friendly Goods

http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19bp.pdf

Battery Alarm Specifications / UPS Alarm Specification

JEMA (Japan Electronic Manufacturing Industry) Refer to http://www.jema-net.or.jp/Japanese/standard/ups/

Criteria, etc. for Decisions of Manufactures, etc. on Improvement of Performance of Magnetic Disk-Drive

Criteria, etc. for Decisions of Manufacturers, etc. on Improvement of Performance of Magnetic Disk-Drive, Announcement No. 195, Ministry of International Trade and Industry, March 31 1999, Final (Complete) Amendment, Announcement No. 51, Ministry of Economy, Trade and Industry, March 29 2006

138

5.7.4. Preparation for Virtualization 1 Basic Capability of installing the equivalent software to that used in the physical

environment and allowing it to function equivalently in the virtual environment composed of virtual storages and others realized by virtualization software

Related Technology Storage Interface Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS,

Infiniband Monitoring / Control Protocol SNMP (Simple Network Management Protocol)

139

5.8. Shared PC / Office Printer

5.8.1. Definition

A Shared PC / Office Printer refers to a terminal used by individuals for the purpose of accessing

information systems, or executing office-work such as the preparation of documents. In this section,

the computer software providing the operational environment, etc. and used by the shared PCs is

referred to as the common operation-environment. Shared PCs are categorized into two ways;

personal computer, stand-alone and able to access the common operation-environment; and

thin-client, working as a client of a thin-client-server, able to access the common

operation-environment through the thin-client-server. The items of Shared PC / Office Printer are

defined as follows;

Shared PC / Office Printer Item Definition Personal Computer Refers to a stand-alone terminal able to use the

common-operation environment Thin-Client Refers to a terminal connected to a thin-client server, etc. Office-Printer Device Refers to a computer peripheral that prints information, etc. on

sheets of paper, according to the instructions by information systems

Note that a thin-client server is defined as a server that provides thin-clients with the common

operation environment and accepts their connection requests through network.

5.8.2. Common Functional Requirements for a Shared PC / Office Printer

The following are the common functional requirements for a Shared PC / Office Printer:

Common Functional Requirement for Shared PC / Office Printer 1 Basic Accessibility via the network by terminals that are operative

(Note that the requirement mentioned above should be applied to terminals operative inside the ministry building. The condition “operative” should be eliminated for the terminals that have been carried out on a business trip.)

Common Non-functional Requirement for Shared PC / Office Printer Term of Hardware Maintenance Contract

Basic Term of warranty for hardware components (maintenance term) is longer than {five years}.

140

Related Technology Accessibility JIS X 8341 Series

ISO 9241-20 ISO / IEC 10779

5.8.3. Functional / Non-functional Requirement for a Personal Computer Functional Requirement 1 Basic Capability of using the common operational-environment 5.8.3.1. Desk-top Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU higher than {1.0} GHz.

On-chip cache memory shall have a capacity larger than {4} MB. Capability of execution of more than {two} threads simultaneously.

Basic Employment of internal memory for main memory of a volume larger than {1} GB

Basic Employment of an internal disk-drive of a capacity larger than {80} GB

Expandability Basic Employment of more than {one} LAN port compatible with 1000 BASE-T, 100 BASE-TX, and 10 BASE-T embedded

Basic Employment of more than {three} USB 2.0 ports embedded Basic Keyboard connected through PS2 or USB. Additional Modem functions unavailable to an isolated — stand-alone —

personal computer. Size Basic Body / keyboard, etc. fitting in a space (referred to as “body

size”) of {60} cm wide, {40} cm high, {40} cm deep; and with a weight less than {10} kg.

Display Basic Screen size of {14} inches — {35.56} cm — or more with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction. [Conventional-type screen] Aspect ratio — width: height — of 4:3 or 5:4 [Wide-type screen] Aspect ratio of 8:5 or 16:9

Security Additional Capability of attaching a theft-protection lock or wire Additional Feature of BIOS password lock Additional Feature of hard-disk password lock


Basic Compatibility with the basic polices of the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”

141

Basic Procurement of products compatible with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered

Internal Drive Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or a capability of attaching such a drive externally

Mouse Additional Employment of a USB connectable two-button optical mouse with scrolling feature and 400-count resolution or finer

Key-Board Basic Bundling with the following features: JIS Standard Key-Arrangement (109 key), or OADG-compatible (109 key) or equivalent; Connectable to the PC through PS2 or USB

5.8.3.2. Note-Book Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU shall be higher than {1.0} GHz.

Cache memory on the chip shall have a capacity larger than {4} MB. Execution of more than {two} threads simultaneously.

Basic Employment of internal memory of a volume larger than {1} GB, used as main memory

Basic Employment of an internal disk-drive of a capacity larger than {80} GB


Basic Employment of more than {two} USB 2.0 ports embedded Additional Unavailability of modem functions to an isolated — stand-alone

— client PC. Size Basic Body / keyboard, fitting in a space (referred to as “body size”) of

{60} cm wide, {5} cm high, and {40} cm deep, with a weight less than {5} kg.

Display Basic Screen size of {14} inch — {35.56} cm — or more with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction.

Availability Additional Drip-proof Security Basic Capability of attaching a theft-protection lock or wire

Additional Feature of BIOS password lock Additional Feature of hard-disk password lock

Battery Capacity

Additional Operability for more than {two} hours measured according to JEITA Battery Operation Hour Measurement Method

142



Basic Compatibility with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered

Drive Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or capability of attaching such a drive externally


Key-Board Basic JIS Standard Key-Arrangement (87 key), or OADG-compatible (86 key) or equivalent, embedded in the body of the computer

5.8.3.3. Portable Note-Book Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU higher than {1.0} GHz.

Cache memory on chip with a capacity larger than {4} MB. Capability of executing more than {two} threads simultaneously.

Basic Employment of internal memory of a volume larger than {1} GB, used as main memory

Basic Employment of an internal disk-drive with a capacity larger than {80} GB


Basic Employment of more than {two} USB 2.0 ports embedded Additional Unavailability of modem functions by an isolated —

stand-alone — client PC. Size Basic Size containing the body / keyboard, etc. in a space (referred to

as “body size”) of {40} cm wide, {5} cm high, and {40} cm deep, with a weight less than {5} kg.

Display Basic Employment of a display with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction.

Availability Additional Drip-proof Additional Capability of attaching a theft-protection lock or wire

Security Additional Feature of BIOS password lock Additional Feature of hard-disk password lock

Battery Capacity

Additional Operability of more than {two} hours measured according to JEITA Battery Operation Hour Measurement Method

143



Basic Procurement of products compatible with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered

Drive Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or a capability of attaching such a drive externally


Key-Board Basic A keyboard having the following features: JIS Standard Key-Arrangement (85 key), or OADG-compatible (85 key) or equivalent

Related Technology Hardware OADG Technical Reference (Hardware) Power Saving International Energy Star Program (Ver. 5.0) Peripheral Connection

USB 2.0

Display Connection

Analog RGB (D-Sub 15 pins), DVI-D, HDMI, Display Port

Wired LAN 1000 BASE-T / 100 BASE-TX / 10BASE-T Wireless LAN IEEE 802. 11 a / b / g / n Bluetooth Bluetooth 2.1+EDR

5.8.4. Functional / Non-functional Requirements for Thin-Client / Thin-Client Server 5.8.4.1. Thin-Client

A Thin-client refers to a terminal that uses functions belonging to the other systems on the network

for a part of its functions executed by its configuration items. In some types of thin-clients, only the

storage function is executed on the network, and in other types, the entire processing excluding

screen-display-processing or user-key-entry processing, is executed by a server on the network.

Functional Requirement 1 Basic Capability of connecting to thin-client servers 2 Basic Capability of using the common operation environment through functions

on the server — in some cases, some of the features of the client might

144

help 3 Basic Employment of no recordable medium — hard-disk drive, etc. —

embedded in the body and available to users

5.8.4.2 Thin-Client Server

Thin-client server refers to a server that provides the common operation environment, and accepts,

via the network, connection requests to the environments from thin-clients. The configurations of a

thin-client server are categorized in a configuration where a single OS instance accepts more than

one session, a configuration where a virtual machine is created for each session, and a blade

configuration where an individual hardware is assigned to an individual session.

Functional Requirement 1 Basic Capability of accepting accesses from personal computers or from

thin-clients

5.8.5. Definition of the Common Operation Environment

The Common operation environment refers to a system composed of software that executes

hardware management, application execution, and file manipulation. The environment is available to

personal computers or thin-clients. The following are functions and services of the common operation

environment.

Common Operation Environment Function / Service Definition OS Through working operations of the system, executes

the fundamental functions, such as the management of resources — CPU or memory, etc. — or the management of accesses to such resources, etc.

Virus Protection To periodically scan memory devices to detect virus infections, continuously monitor inputs / outputs of files or communications on the network, and to take the necessary actions such as virus-cleansing on the detection of virus infections

Web Browser Web browser refers to a program for browsing the WWW.

Personal Fire-wall Quarantine To monitor inbound or outbound communications and give permissions only to the communications from authorized applications

Image Processing To create or modify images Document Creation To create or modify documents Presentation To create or modify slides for presentation Spreadsheet To create or modify tables, or to execute calculations

145

on tables Mail Client To send or receive electronic mails Viewing Video To view video files Web Page Creation To edit HTML and post on a web site Creation of Electric Printed Document

To create an electronic printed document through virtual printers using the application print function

Command-line Environment To execute file-manipulation or configuration-modification using command-lines or batch-processing

Japanese Character Input (Kana-Kanji Conversion)

Conversion of Japanese characters entered by the alphabet-entry-method or kana-entry-method, to kanjis

Reception of Software Function for receiving software or corrections delivered from the software management server

Collection of Inventory Information

To create a list of software, correction programs, signatures of anti-virus software, or user-saved files, etc. installed in the terminal and send it to the server

Encryption To encrypt the system, files, or passwords, etc. Protection against Information Leakage

To restrict copying and delivering information via USB memory devices, etc.

Related Technology Web Browser HTTP, FTP, SSL/TLS, Java Script

HTML 4.1 Document Creation, Presentation, Spreadsheet

ISO/IEC 26300 Open Document Format (ODF) ISO/IEC 29500 Office Open XML Format (OOXML)

Still Image JPEG, GIF, PNG Video MPEG-1, MPEG-2, MPEG-4/H.264, SMPTE VC-1 Printed Document

Adobe Portable Document Format Version 1.7 (PDF) ECMA-388 XML Paper Specification (XPS)

Document Compression

ZIP

5.8.5.1. Functional / Non-functional Requirements for OS OS, through working operations of the system, has the role of executing the fundamental functions,

such as management of resources — CPU or memory, etc. — or management of accesses to such

resources, etc.

Functional Requirement 1 Basic Capability of collecting CPU utilization on a real-time basis 2 Basic Capability of collecting usage rates of physical hard-disk drives 3 Basic Capability of collecting information on input / output performance of

physical hard-disk drives

146

4 Basic Capability of collecting information on free space in physical memory devices

5 Basic Capability of collecting information on free space in virtual memory devices

6 Basic Capability of collecting information on the number of processes in the active state simultaneously

7 Basic Capability of collecting the utilization of CPU and usage rate of virtual memory devices for each process

8 Basic Capability of collecting input / output information on network interface cards

9 Basic Capability of recording and monitoring system events 10 Basic Capability of monitoring the statuses of services (daemon processes)

active on the OS 11 Basic Capability of preserving data for a term sufficient for internal control

audits 12 Basic Capability of allowing usage in multi-user mode (ordinary users and

administrators, etc.) 13 Basic Capability of browsing device information [CPU, memory, physical disks,

logical disks, MAC address, and external devices, etc.] 14 Basic Capability of browsing information on installed software 15 Basic Capability of browsing information about the OS [OS, version, computer

name, and network information such as IP address, etc.]

Non-functional Requirement Back-up Basic Capability of saving collected data into external storage devices

according to the situations in such a way that it can be recovered at any time required

5.8.5.2. Functional / Non-functional Requirements for Virus Protection The Virus protection function periodically scans memory devices to detect viral infections,

continuously monitors inputs / outputs of files or communications on the network, and, on the

detection of viral infections, takes necessary actions such as virus-cleansing. Refer to 5.9.7.1 for the

requirements.

5.8.5.3. Functional / Non-functional Requirements for Web Browser

The Web browser has functions for browsing the WWW. Refer to 5.9.7.2 for the requirements. Functional Requirement 1 Basic Capability of having communications with web servers to obtain

information from the designated URL 2 Basic Capability of displaying the web contents created by using only the

functions compatible with the W3CHTML Standard and the ECMA Script Specifications, and accepting inputs through input forms

3 Basic Capability of displaying images with the data-format of JPEG, GIF, or Adobe Flash

147

4 Basic Capability of controlling automatic data-downloading 5 Basic Capability of controlling pop-up windows 6 Basic Capability of controlling access to the URLs of phishing sites 7 Basic Capability of selecting encoding

5.8.5.4. Functional / Non-functional Requirements for Firewall Quarantine A Firewall has a capability of monitoring inbound and outbound communications to permit only the

communications from the authorized applications to pass.

Functional Requirement 1 Basic Capability of controlling communications to permit or deny access

according to port numbers 2 Basic Compatibility with both of the protocols of IPv4 and IPv6 3 Basic Capability of saving logs

Non-functional Requirement Performance Basic Capability of continuing processing normally on the receipt of a

large amount of packets Availability Basic Not to lose functioning due to piled-up logs

5.8.5.5. Functional Requirements for Image Processing Image Processing has functions for creating or editing images. Images here refers to images built

in a format compatible with one of the standard formats mentioned in the sections relating to standard

formats.

Functional Requirement 1 Basic Capability of reading image files 2 Basic Capability of creating images 3 Basic Function of image-editing such as [cut, copy, paste, edit-color, and

scaling, etc.] 5.8.5.6. Functional Requirements for Document Creation

Document Creation has functions for creating or editing a document.

Functional Requirement 1 Basic Capability of creating a document 2 Basic Capability of editing a document, such as [cut, copy, paste, or

edit-color, etc.] 3 Basic Capability of starting addition from any line in the document without a

sequence of operations for changing lines 4 Basic Capability of creating, reading or editing a document written vertically 5 Additional Capability of reading image files 6 Additional Capability of saving a document in a standard format

5.8.5.7. Functional Requirements for Presentation Presentations have functions for creating or editing slides.

148

Functional Requirement 1 Basic Capability of creating a slide 2 Basic Capability of editing a slide, such as [Cut, copy, paste, or edit-color,

etc.] 3 Basic Capability of executing a slide show 4 Additional Capability of reading image files 5 Additional Capability of reading audio files 6 Additional Capability of reading motion-image files 7 Additional Capability of saving a slide in a standard format 5.8.5.8. Functional Requirements for Spreadsheets

Spreadsheet has functions for creating, calculating, or editing a table.

Functional Requirement 1 Basic Capability of creating a table 2 Basic Capability of calculating a table (including applications of

mathematical operators or basic functions) 3 Basic Capability of editing a table, such as [cut, copy, paste, edit-color, or

insert / delete line, etc.] 4 Basic Capability of creating a graph from data in a table 5 Basic Capability of editing a graph, such as [setting of an axis, etc., or

edit-color, etc.] 6 Additional Capability of reading image files 7 Additional Capability of saving a sheet in a standard format 5.8.5.9. Functional Requirements for Mail Clients

A Mail Client has functions for sending or receiving electronic mail messages

Functional Requirement 1 Basic Capability of having connections through protocols commonly used in

mail servers (SMTP, POP3, and IMAP) 2 Basic Capability of full-text-searching mails using a combination of sender

name, address (destination), title, body, and date 3 Basic Capability of setting of mail-transfer 4 Basic Capability of setting a notice of absence 5 Basic Capability of controlling the automatic downloading of images to be

displayed in the body of an e-mail for the purpose of protecting against web beacons,

6 Basic Capability of encrypting data saves locally 7 Basic Capability of blocking attached-files with a file-extension raising suspicion

of virus infection 8 Basic Capability of encrypting mail body or attachment files and restricting

available functions for the mail (printing, etc.) 9 Basic Capability of applying SMTP authentication 10 Basic Capability of displaying an address book using LDAP 11 Basic Capability of auto-complete function for address, such that a part of

address entered is automatically completed

149

12 Basic Capability of using encrypted mailboxes or address books 13 Basic Capability of accepting and responding to a mail requesting a read

receipt 14 Basic Function for reading an HTML mail in text or rich-text format 15 Basic Capability of displaying an HTML mail without help help of browsers 16 Basic Function for filtering out SPAM mails 17 Basic Capability for allowing a user to easily know whether a mail has an

attachment or not 18 Basic Capability of sorting a mail into folders according to a pre-defined

character string included in the mail-body or title, or sender information, etc.

19 Basic Capability of sorting mails in order of title, date, or sender, etc. 20 Basic Capability of exporting a mail message in a text format or in other

commonly used format 21 Basic Capability of exporting or importing an address-book in CSV format or

another commonly used format such as vCARD 22 Basic Capability of optimizing a mail box

5.8.5.10. Functional Requirement for Viewing Video Viewing Video has a function of viewing video files.

Functional Requirement 1 Basic Capability of viewing video and still images, and playing audio compatible

with MPEG1, MPEG2, and MPEG4

5.8.5.11. Functional Requirements for Web Page Creation Web Page Creation has a function for creating and editing HTML pages, and posting them on web

sites.

Functional Requirement 1 Basic Capability of editing a HTML page 2 Basic Capability of posting a HTML page on a web site 5.8.5.12. Functional Requirements for the Command-Line Environment

The Command-Line Environment has functions for manipulating files or modifying settings through

command lines or batch processes.

Functional Requirement 1 Basic Capability of manipulating files or modifying settings through command

lines 2 Basic Capability of batch-processing

5.8.5.13. Functional Requirements for Japanese Character Entry (Kana-Kanji Conversion) Japanese Character Entry has functions for entering Japanese characters by the alphabet-entry

method or the kana-entry method, and converting them to kanji.

150

Functional Requirement 1 Basic Employment of the basic functions necessary for entering Japanese

words, such as consecutive clause conversion, learning features, and alphabet / kana entry, etc.

2 Basic Function for converting a word to kanji 3 Basic Capability of entering at least the JIS X 0208 Character-set 4 Additional Capability of showing differences of meaning or example sentences

for homonyms 5 Additional Function for assisting conversion of zip code to addresses, and entry

of date 5.8.5.14. Functional Requirements for the Receipt of Delivered Software

The Receipt of Delivered Software has functions for receiving software and correction programs

delivered by the software-management server.

Functional Requirement 1 Basic Capability of receiving software and correction programs (including

virus-pattern files) 2 Basic Capability of confirming the results of the installation of the received

software and correction programs 3 Basic Capability of, in a case where restarting the computer after the

completion of receiving and installing is required, displaying a prompt-message requesting restart, to a user working at the display

4 Additional Capability of suppressing or hiding GUI displays while installing received software or correction programs in order to avoid disturbance to a user working at the display

5 Additional Capability of allowing ordinary installers to execute set-up jobs

5.8.5.15. Functional Requirements for Collection of Inventory Information Collection of Inventory Information has functions for creating and sending to the server, a list of

software installed in the terminal, correction programs, signature files of anti-virus software, and

user-saved files. Functional Requirement 1 Basic Capability of creating and sending to the server, a list of software installed

in the terminal, correction programs, signature files of anti-virus software, and user-saved files

5.8.5.16. Functional / Non-functional Requirements for Encryption Encryption has functions for encrypting a file or a password, etc.

Functional Requirement 1 Basic Capability of automatically encrypting a hard-disk and managing it by the

decryption key, collectively in collaboration with the authentication authority

2 Basic Capability of encrypting file by file, in collaboration with the authentication authority

151

3 Basic Capability of encrypting folder by folder, in collaboration with the authentication authority

4 Basic Capability of executing encryption / decryption by a simple operation 5 Basic Capability of easily encrypting a file when stored in an external medium

Non-functional Requirement Back-up Basic Capability of recovering an encrypted file with a backed-up

decryption key in a situation of a failure of the terminal where the encryption was executed

5.8.5.17. Functional Requirements for Protection against Information Leakage Protection against Information Leakage has functions for protecting information against leakage.

Functional Requirement 1 Basic Capability of controlling access to classified documents (review, print,

or up-date, etc.) on a file-by-file basis in collaboration with the authentication authority

2 Additional Capability of inhibiting the making copies onto external devices such as USB memory devices

3 Additional Capability of inhibiting transmission or transfer, etc. of files attached to an e-mail, in collaboration with the authentication authority

152

5.8.6. Functional / Non-functional Requirements for an Office Printer Device

An Office Printer Device refers to a printing device installed and used in an office environment.

Among them, a printer that is shared, works as a data-processing machine and has no other

functions than printing characters, graphics or photos, etc. onto sheets of paper is defined as an office

printer; a printer that is dedicatedly connected to an individual PC is defined as a small printer; and a

printer that, in addition to functions for printing, has functions of copy machine, scanner, or

fax-machine, etc. is defined as a multi-functional printer.

5.8.6.1. Functional / Non-functional Requirements for Printer

A Printer refers to a printing device that is shared, works as a data-processing device, and records

characters, graphics, or photos, etc. on paper.

Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions from

a terminal 2 Basic Capability of sorting pages and stapling, in the case of printing a

multiple-page document 3 Additional Capability of, by electronic means, sorting pages, or collating pages, etc. in

the case of printing more than one copy of document 4 Basic Printing options, independent of the style of a document, for printing multiple

pages on a single page (n-up printing, both-side-printing, or monochrome-printing, etc.) in the case of making more than one copy of a document

5 Selectable No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, both-side-printing, page-arrangement in book style, or sorting, etc.)

6 Additional Function for restricting network band-width available for print-data transmission

Non-functional Requirement (write only when individually required) Printing Speed

Basic Capability of printing {30 pages in monochrome, or 30 pages in color} or more A4 pages per minute

Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of {multi-color / color} printing Printing Resolution

Basic Capability of printing with a resolution equivalent to {1200} dpi or finer

Printing Basic Employment of laser printing, LED printing, ink-jet printing or

153

Method sublimation / thermal transfer printing Maximum Power Consumption

Basic Less than {2.0 K} W

Size Basic Size, excluding attachments, smaller than {1,200} mm wide x {1,000} mm deep, and {1,500} mm high

Weight Basic Weight, excluding attachments, of lighter than {300} kg Power Basic Requirement of no other special power arrangement than

ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan)

Tray Capacity

Basic Capability of using an auto sheet-feeder and feeding {500} sheets or more

Interface Basic Employment of an interface of standard parallel or USB connection, or both

Basic Employment of interfaces (10BASE-T, 100BASE-TX, or 1000BASE-T, etc.) for connecting to information systems

Security Additional Capability of restricting the taking-out of printed sheets Additional Capability of restricting the receipt of data (printing) using IP

addresses Additional Capability of authentication for access to setting information Additional Capability of deleting print-data saved in the equipment in order to

prevent the data from being re-used Management Additional Capability of confirming or modifying settings remotely

Additional Function for the realization of an integrated management method including status-monitoring or settings, or page-count management or monitoring of multiple devices

Additional Capability of restricting available functions by user groups [color-printing]

Additional Capability of installing driver programs through a single install program


Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Printer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”).

Basic Product compatible with the International Energy Star Program, notified to the government lead office, and registered

Additional Eco-mark certified product

5.8.6.2. Functional / Non-functional Requirements for Small Printers

A Small Printer refers to a printing device that is dedicatedly used and prints characters, graphics,

or photos, etc. onto sheets of paper.

154

Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions

from a terminal 2 Basic Printing options, independent on the style of documents, for printing

multiple pages on a single page (n-up printing or monochrome-printing) in the case of printing a document

3 Additional Printing options, independent on the style of documents, for printing two pages on the both sides of a sheet in the case of printing a document

4 Selective No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, etc.)

5 Additional Function for restricting network band-width available for printing data Non-functional Requirement (write only when individually required) Printing Speed


Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of multi-color / color printing Printing Resolution


Printing Method

Basic Employment of laser printing, LED printing, ink-jet printing or sublimation / thermal transfer printing

Maximum Power Consumption

Basic Less than {30} w for a portable type, or {450} w for a stationary type

Size Basic Size, excluding attachment, smaller than {350} mm wide x {180} mm deep, and {85} mm high for a portable type, and {450} mm wide x {450} deep x {450} high for a stationary type

Weight Basic Weight, excluding attachments, lighter than {2.2} kg for a portable type, and {20} kg for a stationary type

Power Basic Requirement of no other special power arrangement than ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan)

Additional Capability of operating using AC (100-240)V. Power plugs compatible with the receptacles used in other countries should be available

Tray Capacity


Interface Basic Employment of an interface of standard parallel or USB connection, or both

Additional Employment of interfaces (10BASE-T, 100BASE-TX, or 1000BASE-T, etc.) for connecting to information systems

Security Additional Capability of restricting receipt of data (printing) using IP addresses

Additional Capability of deleting print-data saved in the equipment in order to prevent the data from being re-used

155

Management Additional Function for the realization of an integrated management method including status-monitoring or settings, or page-count management or monitoring of multiple devices

Additional Capability of installing driver programs through a single install program


Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Printer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”).

Basic Product compatible with the International Star Program, notified to the government lead office, and registered


5.8.6.3. Functional / Non-functional Requirements for Multi-Functional Printers

A Multi-Functional Printer refers to a device that has the functions of a copy-machine, a scanner,

and a fax-machine, in addition to printer functions. Furthermore, it is able to save an original as an

electronic image. Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions

of a terminal 2 Basic Capability of making a photo-copy of a paper document 3 Basic Capability of sorting pages and stapling, in case of printing a

multiple-page document 4 Basic Capability of scanning a document and storing it as an electronic-data

file 5 Basic A combined machine with fax-functions connectable to a telephone, with

a capability of sending or receiving facsimile signals. 6 Basic Capability of temporarily saving electronic copies of an original, scanned

or sent, to retrieve, read, or be deleted later by manual operation 7 Basic Printing / copying options, independent on the style of a document, for

printing / copying multiple pages on a single page (n-up printing, both-side-printing, or monochrome-printing, etc.) in the case of making more than one copy of a document

8 Selective No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, both-side-printing, page-arrangement in book style, or sorting, etc.)

9 Additional Function for restricting network band-width available for print-data transmission

Non-functional Requirement (write only when individually required)

156

Printing Speed


Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of {multi-color / color} printing Printing Resolution


Printing Method

Basic Employment of laser printing, LED printing, ink-jet printing or sublimation / thermal transfer printing

Maximum Power Consumption

Basic Less than {2.0 K} W

Size Basic Size, excluding attachments, smaller than {1,200} mm wide x {1,000} mm deep, and {1,500} mm high

Weight Basic Weight, excluding attachments, lighter than {300} kg Power Basic Requirement of no other special power arrangement than

ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan)

Tray Capacity


Copy Function

Selectable Capability of selecting color / monochrome copying

Automatic Document Feeder

Basic Capability of automatically feeding a document consisting of more than one page (single-sided, double-sided, different sized), in the case of scanning, facsimile-sending, or copying

Fax Functions

Basic Capability of registering or managing the fax-destination phone numbers

Scanning Function

Basic Capability of attaching scanned-data files to an e-mail Basic Capability of storing scanned-data files into private folders or

shared folders on the network Basic Capability of viewing, loading or deleting the tentatively saved

data by operations on terminals through the network Basic Capability of selecting color-scan, or monochrome-scan Basic Capability of scanning with a pre-defined resolution [200dpi,

400dpi, or 600dpi, etc.] Basic Capability of selecting a format for saving scanned data (PDF,

XPS, JPEG, or TIFF, etc.) Interface Basic Employment of an interface of standard parallel or USB

connection, or both Basic Employment of interfaces (10BASE-T, 100BASE-TX, or

1000BASE-T, etc.) for connecting to information systems Security Additional Capability of restricting the taking-out of printed sheets

Additional Capability of restricting the receipt of data (printing) using IP addresses

Additional Capability of authentication of access to setting information Additional Capability of deleting [copy, fax, scan, or print, etc.] data saved in

the device, in order to prevent the data from being re-used

157

Management Additional Capability of confirming or modifying settings remotely Additional Function for realization of an integrated management method

including status-monitoring or setting, or page-count management or monitoring of multiple devices

Additional Capability of restricting available functions [copy, fax, scan, or print data, etc.] by user groups

Additional Capability of installing driver-programs through a single install program


Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Copy Machine” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”).

Basic Product compatible with the International Energy Star Program, notified to the government lead office, and registered


5.8.7. Preparation for Virtualization

Functional Requirement (Preparation for a virtualized environment) 1 Basic Capability of installing the software equivalent to that in the physical

server environment, and allowing it to perform the equivalent functions in the virtualized environment composed of virtual guest servers, virtual storages, or virtual networks realized by virtualization mechanisms

158

5.9. Operations Management/Security

Operations management represents the activities needed to maintain unerring control of the environment, thus enabling the various systems running, mainly on computers, to provide various services to their users without interruption that may be triggered by unexpected external causes. Security refers to the construction and maintenance of environments that safeguard information assets from internal/external threats, such as viruses or unauthorized access, thus ensuring a safe and secure computer environment for all users.

Management screen

Connection control

Various dataNetwork devices

Incident

Management server

Agent

Anti-virus software

Agent

Anti-virus software

Agent

Anti-virus software

Agent

Anti-virus software

Client PC

Help deskClient PC

management

Security

Figure 5.9-1 Schematic Overview of Operation Management (Client PC system)

159

Management screen

Network devices

Incident

Management server

Objects of management (Web server, AP server, DBMS, etc.)

SAN storage

Help deskAvailability/performance

management

Network management

Storage management

Server management

OS

Agent

OS

Agent

OS

Agent

OS

Agent

Web server AP server DBMS

Agent

Internet protocol response time measurement server

Symbols

Response time measurement

Viability monitoring

Various data

SAN

Figure 5.9-2 Schematic Overview of Operation Management (Server system)

External hub

Office room

Server room

Anti-virus gateway server

Spam mail filter

Contents filer server

Proxy server

Log collection server

Mail server

Business server

FWVPN

DMZIDS/IPS

Operation/management segment

Floor segment

Floor segment

Virus pattern distribution server

Internal segment

Internet content/spam

filter

Anti-virus gateway

Intrusion detection/protection

Trail management

Encryption (VPN)

Encryption (file)Virus protection

function (of fice PC)

アクセスログAccess log

Measures against information take-out

Internet

Figure 5.9-3 Schematic Overview of Security System

160

The functions and services provided by the operation management and security are defined as follows. Function and service

Definition

Performance management

Performance management provides centralized administrative control over availability information of OSs and applications, and, when a failure takes place, supports causal investigation based on the gathered data

Client PC management

Client PC management provides centralized gathering and administrative control of information of the client PCs (hardware configuration, OSs and applications running on them) deployed in the network compatible environment. It also provides resource distribution functions – configuration management and introduction/deletion of software to/from the networked PCs – as well as remote controlling of the PCs.

Server management

Server management monitors operational status and loading conditions of the business servers that constitute the information system within the Cabinet Office and the Ministries, takes measures against data destruction in case of disaster (installation of a duplicated system in a remote location, storage of backup media in a remote location), and manages ancillary facilities (uninterrupted power systems, rack temperatures) in the server installation environment. In all, the server management assumes the job scope usually covered by the system operation administrator, or its equivalent. Note, however, that it leaves out consideration for a case in which the operation of the servers within the Cabinet Office and Ministries is outsourced to external service providers. Nor does it take into consideration requirements imposed on the data center business operator (e.g. business size).

Network management

Network management assumes the following functions: (1) Operation of the network within the Cabinet Office and Ministries consisting mainly of L2-L3 equipment (switches, routers, etc.) (2) The functions normally covered by the information system operator within the Cabinet Office and Ministries from the viewpoint of ICT system administration (3) The functions required to enhance quick recovery from a network failure, and to minimize business disturbances caused by it, as well as to provide effective preemptive measures against it Note, however, the requirements for the following business operators are

not taken into consideration: NI/SI business operators that act as a maintenance proxy, and iDC business operators.

Storage management

Storage management provides functions for effective centralized management of external memory unit resources (storage devices) used to store data and programs, including such additional functions for performing configuration display, performance/state monitoring, and various event notification.

Service desk Service desk provides such functions that enable it to work as the one-stop center for accepting problem notifications and various usage inquiries regarding the information system. The events are accepted through telephone or e-mail and their contents will be registered to a database, which is open to user access. Through linkage with other system’s fault

161

control and configuration management capabilities, these functions can be utilized for resolving problems when they occur.

Security Security provides functions for detecting unauthorized access to computers and viruses, and for monitoring the status of information security – e.g. frequency of access denials performed by the contents filtering server. It also provides the hazardous event notification function that issues an appropriated level of alarms depending on the severity of the event. In addition, it includes such functions as giving graphically-represented statistical reports for monitoring results that include analysis and improvement proposals.

Job management

Job management provides functions to compile procedures for routine tasks, and execute them regularly at given intervals or link them with particular events for triggering.

5.9.1. Functional and Non-Functional Requirements for Performance Management 5.9.1.1. Centralized management of server availability information

This function is used to centralize availability information of the monitored objects for unified

control.

Functional Requirements 1 Basic Capability to manage both OSs and applications from single screen. 2 Basic All operations for OS and application monitoring must be communalized. 3 Basic The objects to be monitored must have a hierarchy structure for easy

localization of failure events. 4 Basic Quick and easy access to the report screen pertaining to the monitored object. 5 Basic Restriction of the scope of operations depending on the user’s authority. 6 Basic Accessibility to operational viability information of the monitored server. 7 Additional Availability of the operations history (operation log) for setting changes, etc. 8 Basic Capability to monitor the operational status of the management server and

monitored processes. 9 Additional Centralized management method easily applicable to the management of

virtualized resources. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Clustered configuration capability of the management servers. Security Basic Availability of login management to avoid unauthorized

modification of configuration information etc. Extendability Basic Capability to store necessary amounts of gathered data (sufficient

to cover the audit period for internal control). Backup Basic Backup capability of configuration definition information and

operational log.

162

5.9.1.2. Information Gathering and Management of Performance Target location for Information gathering and abnormality detection includes the management

servers and the units under monitoring.

Functional Requirements 1 Basic Provision of default monitoring items (threshold valued included). 2 Basic Capacity for creating monitoring items freely. 3 Basic Functionality that allows e-mail dispatch and command execution in case a

measurement value exceeds a given threshold. 4 Additional Setting option not to store data (i.e. threshold monitoring only) 5 Basic Capability to consolidate the gathered data regularly (on hourly, daily, weekly,

and monthly basis). 6 Basic Capability to automatically delete old data when a given storage period

expires. 7 Basic Capability to gather arbitrary measurement data as defined by the user. 8 Basic Functionality to avoid data loss even in the case of communication failure

between the management server and monitoring agent. Non-functional Requirements (description provided only when relevant requirements are given) Backup Basic Capability to backup monitoring definitions. Extendability Basic Capability to store necessary the amount of gathered data (sufficient to

cover the audit period for internal control). 5.9.1.3. Report Management

Report management provides methods to create graphical representation of the gathered

operation qualification data.

Functional Requirements 1 Basic Provision of multiple graphical format options (bar graph, line chart, pie chart,

etc.) 2 Basic Provision of report templates as a default report format. 3 Basic Provision of a method to freely create new templates. 4 Basic Capability to display a multiplicity of measurement data - multiple monitoring

items of OS and applications – in a single graph. 5 Basic Capability of overwriting large amounts of data from different points in time

(current data and past data from any given point in time). 6 Additional Provision of a report saving function on the display screen. 7 Basic Capability to save reports and measurement data automatically. 8 Basic Capability to freely adjust the time window of the graphical display. 5.9.1.4. OS Performance Management

This function provides methods for gathering information regarding the performance of OSs.

Functional Requirements 1 Basic Capability to gather operation data of CPU utilization. 2 Basic Capability to gather operation data for each CPU (in case of a multi-CPU system).

163

3 Basic Capability to gather operation data for each CPU core (in case of a multi-core CPU system).

4 Basic Capability to gather utilization information of physical hard disks. 5 Basic Capability to gather I/O performance information of physical hard disks. 6 Basic Capability to gather free space information of physical memory. 7 Basic Capability to gather free space information of virtual memory. 8 Basic Capability to get the number of concurrently running processes. 9 Basic Capability to gather information of CPU and virtual memory utilization on a

process-by-process basis. 10 Basic Capability to gather I/O information of a network interface card. 11 Basic Capability to monitor event log. 12 Basic Capability to monitor the state of services provided by OS (i.e. daemon

processes). Non-functional Requirements (description provided only when relevant requirements are given) Extendability Basic Capability to save gathered data in external storage devices on an as

needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to

cover the audit period for internal control). 5.9.1.5. DBMS Performance Management

This function provides methods for gathering information regarding performance of DBMSs.

Functional Requirements 1 Basic Capability to gather utilization information on a table-by-table basis. 2 Basic Capability to gather information on the SQL statements currently executing. 3 Basic Capability to monitor the state of connections. 4 Basic Capability to obtain the dispatcher IP address and program information of an SQL

statement. 5 Basic Capability to monitor the occurrence status of locking. 6 Basic Capability to gather input/output information (number of times, etc). Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered DB servers, the management agent must be able

to manage all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as


cover the audit period for internal control). 5.9.1.6. AP Server Performance Management

This function provides methods for gathering information regarding performance of AP servers.

Functional Requirements

164

1 Basic Capability to gather access number information. 2 Basic Capability to obtain the number of garbage collections that have taken place. 3 Basic Capability to obtain the execution time required by a garbage collection. 4 Basic Capability to gather information on the heap usage required for running component

applications (Java components, NET components, etc.). 5 Basic Capability to gather average response time information of Web services. 6 Basic Capability to obtain the number of sessions. 7 Basic Capability of obtain the number of queuing threads. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered AP servers, the management agent must be able

to manage all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as


cover the audit period for internal control). 5.9.1.7. Performance monitoring of Internet services

This function provides methods for gathering information on operational performance of the

services provided by the Internet protocol.

Functional Requirements 1 Basic Capability to gather response time information of Web pages (HTTP, HTTPS,

etc.). 2 Basic Capability to record the series of events taking place on a Web site, enabling

the ability to gather total response time information. 3 Basic Capability to obtain the response time of a particular operation during the

course of events described in the item above. 4 Basic Capability to determine the correctness of a Web page’s content during the

course of events described in the item above. 5 Basic Capability to gather response time information in mail transmission/reception

(SMTP, POP3, IMAP4 etc.) 6 Basic Capability to gather response time information required for address resolution

(DHCP, DNS, etc.) 7 Basic Capability of obtain a TCP port connection time. 8 Basic Capability to run a program to measure the response time of a given

application, and gather relevant information from it. 9 Additional Capability to gather communication messages between the management

server and agents. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered measurement servers, the management server

must be able to operate on the cluster. Extendability Basic Capability to save gathered data in external storage devices on an as

165


cover the audit period for internal control). Related technologies Hyper Text Transfer Protocol

HTTP(Hyper Text Transfer Protocol) A protocol used for transmission and reception of data between Web servers and clients (e.g. Web browser), capable of transmitting/receiving HTML and other various formatted documents with their attached files (images, sound, and animation) and representation information. IETF standardized HTTP/1.0 as RFC 1945, and HTTP/1.1 as RFC 2616. HTTPS(Hyper Text Transfer Protocol Secure) A protocol derived from HTTP - used for transmission and reception of data between Web servers and clients (e.g. Web browser) - with addition of encryption capability using SSL. It enables secured communication that involves confidential information (privacy information, credit card numbers, etc.) through encryption of correspondence between the server and browser. Major Web browsers (Internet Explorer, Firefox, Safari, etc.) are compatible with this protocol, making it the de facto standard. SSL is an encryption protocol propounded by Netscape Communications. In addition to HTTP, it is also applicable to such protocols as FTP and TELNET.

Dynamic Host Configuration Protocol

DHCP(Dynamic Host Configuration Protocol) A protocol to automatically assign necessary information (an IP address and others) to a computer connecting temporarily to the Internet. A DHCP server is allocated with a pre-defined range of IP addresses (to be assigned for Gateway servers and DNS servers, and for subnet masks and clients), and it provides necessary information to the computer that is accessing the server through dial-up or through other schemes. When a client terminates its communication, the DHCP server automatically recovers the address for use with other computers. The use of DHCP enables even the casual users – who may not be familiar with network settings - to establish connection to the Internet without difficulties. It also enables the network administrators to manage large numbers of clients in a unified fashion.

Domain Name System

DNS(Domain Name System) A system to match a host name in the Internet to a IP address. This is a distributed database through which the DNS servers all around the world make concerted operations. A host name can be searched from an IP address, and vice versa. Each DNS server maintains a set of domain information under its control, and registers the domain name and its own address to the route servers (approx. 10 route servers are in operation around the world). A client program (called “resolver”) resolves the conversion by first making inquiries about the domain name (or IP address) with the route server, and then examining the DNS server that manages the domain, followed finally by extracting necessary information from the DNS server. A majority of the DNS servers operating in the Internet use the BIND server, which was developed by UCB (University of California at Berkley).

166

5.9.1.8. Performance Management of the Job Management Server

This function provides mechanisms for gathering information regarding performances for job

management servers.

Functional Requirements 1 Basic Capability to gather the number of jobs currently executing. 2 Basic Capability to gather the number of jobs that have failed. 3 Basic Capability to gather the number of jobs that are staying dormant. 4 Basic Capability to gather the number of jobs that are delayed in their execution. 5 Basic Capability to gather information regarding the operational status of DBMSs in use. 6 Basic Capability to gather latency time information of the jobs. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered job management servers, the management

agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as

needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient

to cover the audit period for internal control). 5.9.1.9. Performance Management of Web Server Management Software

This function provides mechanisms for gathering information regarding performance for Web

server management servers.

Functional Requirements 1 Basic Capability to gather access count. 2 Basic Capability to gather the count of “Not Found” (*) occurrences. 3 Basic Capability to gather throughput information. 4 Basic Capability to gather transfer rate information (transmission and reception). (*)“Not Found” count: the number of times when the Web site is not located using the given URL. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered Web servers, the management agent must be able

to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as


cover the audit period for internal control).

167

5.9.1.10. Performance Management of Business Applications

This function provides mechanisms for gathering information regarding performance for business

applications.

Functional Requirements 1 Basic Capability to gather response time information, and to detect occurrences of

response time-out. 2 Basic Capability to gather dispatcher latency time information. 3 Basic Capability to gather DBMS request time information. 4 Basic Capability to gather the number of logged-in users. 5 Basic Capability to gather log information. 6 Basic Capability to gather working process information. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered business application servers the management



cover the audit period for internal control). 5.9.1.11. Performance Management of Groupware

This function provides mechanisms for gathering information regarding performance for

groupware.

Functional Requirements 1 Basic Capability to gather information regarding mail transmission/reception. 2 Basic Capability to gather network information (i.e. data transmission and reception). 3 Basic Capability to gather mail server queue information. 4 Basic Capability to gather file information of the database in use (cache hit ratio, disk

capacity, etc.). 5 Basic Capability to monitor the state of service provisioned by groupware. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered groupware servers, the management agent must

be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as



168

5.9.1.12. Performance management of distributed transactions This function provides mechanisms for gathering information regarding performance for distributed

transactions.

Functional Requirements 1 Basic Capability to gather performance information related to RPC (Remote Procedure

Call). 2 Basic Capability to gather the number of accesses done to files. 3 Basic Capability to gather the number of commits/rollbacks. 4 Basic Capability to gather communication status information of the distributed

transaction servers. 5 Basic Capability to gather information relating to the queue manager’s operational

status. 6 Basic Capability to gather information relating to the handle status. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered distributed transaction servers, the management




5.9.2. Functional/Non-Functional Requirements for Client PC Management 5.9.2.1. Client PC configuration management

Client PC configuration management provides functions to gather information regarding the

hardware and software implementation of the client environment, thus enabling unified control of it.

These functions can also be used as a security measure and serve to detect network connection

attempts from unauthorized clients and use of malicious software.

Functional Requirements 1 Basic Capability to browse device information – CPU, memory, physical disk, MAC

address, external storage devices, etc. 2 Basic Capability to gather information regarding the software implemented on each

terminal.

Related technologies Remote Procedure Call

RPC (Remote Procedure Call) A procedure, developed by Sun Microsystems, used to enable processing among dissimilar machines deployed on the Internet. This technology has widespread use in UNIX systems, and is also finding its implementation in Windows NT. The DCOM – Microsoft’s distributed object technology – was developed based on RPC.

169

3 Basic Capability to browse OS information – type and version of OS, computer name, and network information (IP address, etc.).

4 Basic Capability to gather configuration and other information at any time, on a group-by-group and user-by-user basis.

5 Basic Selectability of the terminals used to gather information. 6 Basic Capability to stop displaying (or hide temporarily) GUI elements while information

gathering is taking place (a measure to avoid interrupting user operation). 7 Basic Capability of unifying all management, and browsing and conditional searching of

the information gathered.

5.9.2.2. Resource Distribution Management

Resource distribution management provides the server with the methods to perform software

distribution services – e.g. remote installation of common standard software and security patches – to

multiple client PCs en block.

Functional Requirements 1 Basic Capability to distribute software from the server to the terminals. 2 Basic Capability to distribute to all the terminals. 3 Basic Capability to stop displaying (or hide temporarily) GUI elements while the

distribution process is being carried out (a measure to avoid interrupting user operation).

4 Basic In case a system restart is required at the end of the distribution operation, a message must be displayed to prompt the working user to reboot the system.

5 Basic Capability to handle setup operations using major installer formats (msi, exec, etc.)

6 Basic Capability to define the types of software that can be installed/uninstalled for each terminal and for each group.

7 Basic Capability to distribute only to specified terminals and groups. 8 Basic Capability to verify the results of the software distribution. 9 Basic Capability of performing the following cycle: powering-on of a terminal,

distribution of software, followed by an automatic powering-off of the terminal. 10 Basic Capability to automate resource distribution operations (user operations from

installation to system restart) and scheduled execution of them.

Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic Availability of active client PCs even in the case of management

server failure. Performance Basic Capacity of controlling multiple PCs (up to several thousand) through

synchronization. Extendability Basic Extendability of the range of control up to several thousand PCs by

utilizing distributed servers and other schemes. Security Basic Access authority to the gathered PC configuration information must

be assigned only to qualified personnel.

170

11 Basic Capability to allocate distribution load appropriately to minimize its effect on other services, especially in the case of a large scale resource distribution such as a service pack.

12 Basic Capability to detect, after resource distribution, the client PC where normal distribution failed, enabling a retry of distribution.

13 Basic Capability to perform an installation/version upgrade of software without any user operations, even if it does not normally allow silent-mode installation. Note that, this requirement is considered to be met if distribution operation can be performed based on the installation operation log and its modifications on a particular terminal.

Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capacity to control multiple PCs (up to several hundred thousand)

simultaneously. Extendability Basic Extendability of the range of controllable PCs up to several million by

utilizing distributed servers and other schemes. Security Basic Only the authorized users are allowed to perform distribution

operations, and refer to the distribution resources. 5.9.2.3. Remote Operation

Remote operation is a part of management functions that enables the server to perform remote

client operations to the client PCs.

Functional Requirements 1 Basic Capacity of controlling multiple PCs (up to several hundred thousand)

simultaneously. 2 Basic Capability to remotely restrict the users that are authorized for connection. 3 Basic Capability of remote connection and file transfer to the connected terminal. 4 Basic Capability of remote connection and restart of the connected terminal. 5 Basic Capability to remotely control a client PC even while it is not logged in. 6 Basic Capability of encrypting communication contents for remote operations, and

recording operation details. 7 Basic Capability to record operations, as log information, performed to change the state

of operational objects (i.e. terminals) – logon, shutdown, restart, etc. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capability to perform operations through the network, which requires

the capacity to reduce line load (required band-width) depending on the line speed employed.

5.9.2.4. Others Functional Requirements 1 Basic Capability to record the operations log performed to the client PCs, and the

information must be browsable. The operations log must at least include program invocations and file operations.

171

5.9.3. Functional/ Non-Functional Requirements for Server Management 5.9.3.1. Server configuration management

Server configuration management includes functions that enable control of hardware and software

information required to define the configuration of the server.

Functional Requirements 1 Basic Capability of the centralized management of the latest set of configuration

information for all servers, including device information, system information (OS, CPU, memory, etc.), software information, network information, and disk information.

2 Additional Capability to display the revision history of server configuration information, and changes before and after a modification.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Operations, except for those related to server configuration

management, must be available to the terminals (console terminals) even while the management server is down.

Performance Basic Capacity to control multiple servers (up to several hundred) simultaneously.

Extendability Basic Extendability of the range of controllable servers up to several hundred.

Security Basic Accessibility to all of the gathered server configuration information (device/system/software/network/disk information) must be appropriately provided.

5.9.3.2. Performance Management

Performance management includes management functions to monitor the level of performance

required by the server. Functional Requirements 1 Basic Capability to the gather kernel configuration information of each OS. 2 Basic Capability to gather performance information of such system elements as IO,

memory, cache, space, deadlock, and database usage (e.g. SQL frequency). Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Any failure in performance management functions must not have an

effect on the execution of other services (functions), and methods must be provided for easy restoration.

Extendability Basic The performance management must be capable of controlling multiple databases and OSs.

Extendability Basic The performance management must have the flexibility to meet the requirements of new versions of databases and OSs.

5.9.3.3. Fault Control

Fault control provides functions to detect server failures, and to cope with irregular situations in the

servers comprising the business system.

172

Functional Requirements 1 Basic Capability to monitor the output functions of specified log information, and

issue a notification (e.g. alarm) to the administrator in case it detects one of the given events.

2 Basic Capability to record operations, as log information, performed to change the state of operational objects (i.e. terminals) –shutdown, reboot, etc.

3 Additional Capability to perform polling on each of the server communication ports under the control of various services and daemons (e.g. HTTP/HTTPS, DNS, SMTP, and any other specified ports).

4 Basic Capability to monitor the operational status of various services, daemons, and processes that are resident on the server.

5 Basic In the event of hardware failures and other abnormal events, the system configuration must have the provision to notify staff members, maintenance contacts, and the administrator in charge by means of e-mail (including e-mailing to mobile phones). This function must cover all the servers installed in a given machine room.

6 Basic Capability, when a failure occurs, to identify and locate the range of the affected area.

7 Basic Capability to manage failure history information. Non-functional Requirements (description provided only when relevant requirements given) Extendability Basic The failure management functions must be compatible with multiple

databases and OSs 5.9.3.4. Resource Management

Resource management provides management functions to display/notify the utilization information

(used/free space) of the hard disks incorporated in the server.

Functional Requirements 1 Basic Availability of graphic display and file output of hard disk utilization information

(used and free space) incorporated in all server hardware. 2 Basic Availability of a function to monitor disk usage threshold, and automatic notification

to the person in charge. 5.9.3.5. Backup Management

Backup management provides controlling methods against data destruction that may be caused by

disasters and system failures (including human errors).

Functional Requirements 1 Basic Capability of online backup (for the software compatible with online backup). 2 Basic Compatibility with scheduled backup. 3 Basic Availability of both full and incremental backup. 4 Basic Capability of monitoring backup operation status (success and failure) 5 Basic Restoring capability on file, folder, logical volume, and server basis. 6 Basic Accessibility to restore operations from other servers than that obtained the

backup.

173

7 Basic Capability to create backup media that can be used for system area restoration.

8 Additional Capability of the backup media to start and perform system area restoration operations.

9 Basic Additional implementation of segments dedicated for backup operations, in cases where there are concerns that the backup operations might overload the business use of the network.

10 Basic Capability of the management of backup media generation. Linkage with library equipment is required to archive the given number of data generations in the media.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Backup must not trigger operational discontinuation of the server, nor

produce the need for a system reboot. Security Basic Authority to make a reference to the backup media must be strictly

limited only to the authorized users. 5.9.3.6. Inter-Equipment Linkage

Inter-equipment linkage provides functions to manage irregular events that may occur in the related

set of equipment essential for system operation.

Functional Requirements 1 Basic Capability to monitor the status of equipment installed in a given machine room

(air-conditioning, power unit, water leakage, temperature, etc.), and to provide notification for the occurrence of irregular events.

2 Basic Provision of assistance functions for the operator/administrator to control and shutdown the equipment installed in the machine room where irregular events are taking place.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Capability to issue a server shutdown command in no uncertain

manner when an equipment failure is detected. Extendability Basic Provision of an interface enabling detection of equipment failures. 5.9.3.7. Resource Distribution Management

This function provides the management server with management functions to perform software

distribution services – e.g. remote installation of common standard software and security patches – to

multiple servers en block.

Functional Requirements 1 Basic Capability of the management server to distribute software to target servers. 2 Additional Capability to stop displaying (or hide temporarily) GUI elements while the

distribution process is being carried out (a measure to avoid interrupting user operations).

3 Basic In case system restart is required at the end of a distribution operation, a message must be displayed to prompt the working user to reboot the system.

174

4 Additional Capability to handle setup operations using major installer formats. 5 Basic Capability to define the types of software that can be installed/uninstalled for

each server and for each group. 6 Basic Capability to distribute only to specified servers and groups. 7 Basic Capability to confirm the results of the software distribution. 8 Additional Capability to automate resource distribution operations (user operations from

installation to system restart) and scheduled execution of them. 9 Basic Capability to allocate distribution load appropriately to minimize its effect on

other services, especially in the case of a large scale resource distribution such as a service pack.

10 Basic Post-distribution capability to locate the server on which normal distribution failed, enabling a retry of distribution.

11 Additional Capability to perform software installation (or version upgrade) without any user operations, even if the software does not normally allow silent-mode installation.

Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capacity of controlling multiple servers (up to several hundred)

simultaneously. Extendability Basic Extendability of the range of controllable servers - up to several

hundred - by utilizing distributed management servers and other schemes.

Security Basic Only the authorized users are allowed to perform distribution operations, and refer to the distribution resources.

5.9.3.8. Others Functional Requirements 1 Basic Capability to record an operations log performed to the servers, and the log

information must be browsable.

175

5.9.4. Functional/ Non-functional Requirements for Network Management 5.9.4.1. Network configuration management

Network configuration management includes functions that enable the control of network

equipment and software information required to define configuration of the network.

Functional Requirements 1 Basic Capability to automatically create the network map from network

configuration information. 2 Basic Capability to automatically gather arbitrary MIB information from each node. 3 Basic Capability to manage installation and setting information of the network

devices. 4 Basic Capability to manage the number of installations of network equipment. 5 Basic Capability to gather network configuration information automatically and each

network device must be capable of invoking regular updates of configuration information.

6 Basic Capability to customize the network map, enabling the creation of hierarchical network maps on a hub and floor basis.

7 Basic Browsability of configuration information using a GUI. 8 Additional Capability to display the results of past configuration modifications, as

changes before and after a modification. 9 Basic Capability to display configuration information in the way most suited to each

hub and section. 10 Basic Capability of a screen-by-screen display of the different types of configuration

information. 11 Additional Capability to display types of configuration information based on the VLAN

route. 12 Basic Capability to distinguish the state (normal/failed) of devices and line

conditions on the screen – for example, by the changing of icon colors. 13 Basic Capability to locate an operational bottleneck (CPU of a network

device/server, memory, etc.), which requires tracking of changes in the business throughput and load.

14 Additional Capability to maintain continued operational monitoring – without any delay associated with device switching – even in the cases of device failure in the operational management server.

15 Basic Capability to restrict types of operations allowed to the operator and administrator: a measure to prevent network problems caused by inadvertent operations.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic The servers and client PCs must be able to perform non-networking

tasks even while the network is down. Performance Basic Capability to manage multiple PCs (several hundred thousand) and

servers (several hundred) simultaneously. Extendability Basic Extendability of the range of controllable PCs (up to several hundred

thousand) and servers (up to several hundred).

176

Security Basic Capability to assign the authority of accessing the gathered configuration information of monitored devices only to qualified persons.

Related technologies Network management protocol

SNMP (Simple Network Management Protocol) In a TCP/IP network, this protocol is used to monitor/control the networked communication devices (routers, computers, terminals, etc.) through the network. The devices to be controlled have a management information database, called MIB, and the controlling device configures the target devices appropriately based on MIB. (Specifications) http://www.ietf.org/rfc/rfc2570.txt?number=2570 (Link & information portal) http://www.simpleweb.org/

MIB MIB (Management Information Base) MIB is the management information contained in a SNMP-controlled device. Two versions are currently available (MIB1 defined by RFC 1156 and MIB2 defined by RFC 1213), of which the latter has become more prevalent. The specifications for this database are standardized by the IETF. (Specification) http://www.faqs.org/rfcs/rfc1213.html

5.9.4.2. Traffic management

Traffic management provides methods to control the traffic over the network.

Functional Requirements 1 Basic Capability to measure and gather traffic information in real time. 2 Basic Capability to define a threshold on the measured traffic information and to notify

the person in charge automatically in case the actual traffic exceeds it. 3 Basic Capability to monitor the traffic passing through the network, and to perform fine

bandwidth management (i.e. control of bandwidth and transmission delay) conforming to the policy defined by the user. The locations from where the monitoring/management operation is performed are stated separately.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Business services must be provided continuously and flawlessly

regardless of the running status (on/off) of the traffic management functions.

5.9.4.3. Fault control

Fault control provides methods to control network faults.

Functional Requirements 1 Basic Capability to monitor if a node/link is down in network devices, as well as to

monitor node status using ICMP-echo. 2 Basic Provision of automatic notification and filtering of the events to be monitored. 3 Additional Provision of automatic classification (filtering) for the events to be monitored. 4 Basic Capability of a forced remote-controlled shutdown of the link of connection

ports incorporated in central/local node switches.

177

5 Basic Capability of centralized control (e.g. powering On/Off, restart) of network devices located in external hubs (this requirement applies to the network devices capable of remote powering On/Off and restart).

6 Basic Capability to remotely control network devices even in the case of network failure (assuming that communication to those network devices is still available).

7 Basic Capability of historical management of failures, including search function using a keyword.

Non-functional Requirements (description provided only when relevant requirements given) Extendability Additional Data saving functions must be compatible with various types of

databases and OSs. Availability Basic Provision of multiple notification methods (e.g. alarm light, mail,

etc.). These monitoring methods must operate concurrently to guarantee secure notification to the management server.

Availability Additional Capability of monitoring and archiving the management of Syslog output from the network devices.

5.9.4.4. Others Functional Requirements 1 Additional Capability to record an operations log performed in relation to network

management, and the log information must be browsable.

5.9.5. Functional/ non-functional requirements for storage management 5.9.5.1. Storage configuration management

Storage configuration management provides functions to display/notify information regarding

storage devices such as the attributes, logical disk configuration, and connection status.

Functional Requirements 1 Basic Provision of configuration information gathering functions applicable to storage

devices. 2 Basic Provision of an automatic detection function of connected storage devices. 3 Basic Provision of a function to create a map of the connected storage devices. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic The servers and client PCs connected to the storage management

server/storage must remain operative without interruption even while the storage is down.

Security Basic Access authority to the gathered storage configuration information must be assigned only to qualified operators.

5.9.5.2. Performance management

Performance management provides functions to monitor and display the performance status in real

time, detecting symptoms, and preventing performance degradation.

178

Functional Requirements 1 Basic Capability to gather and monitor storage devices’ performance information such

as Read/Write frequency, data transfer time, average response time, and disk usage rate.

2 Basic Capability to gather and monitor performance information between the server and storage (SAN switch performance, etc.).

3 Basic Provision of a function to monitor the threshold assigned to performance information for storage devices and server-storage operations, and to automatically notify the person in charge.

4 Basic Provision of a graphic display and file output function for performance information. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Failure in performance management functions shall not hinder

continuous operation of storage devices. 5.9.5.3. Resource (capacity) management

Resource (capacity) management provides functions to display and notify the usage status (used

and free space) in each disk and logical group.

Functional Requirements 1 Basic Capability to gather and save the resource (capacity) information of each

server connected to the storage (capability to grasp the amount of used and free space in each device, volume and server is required).

2 Basic Provision of a function to monitor the disk usage threshold and to automatically notify the person in charge.

3 Basic Provision of a graphic display and file output function. 4 Additional Capability to grasp current disk usage information (used and free space) for

each folder and user. 5 Basic Provision of a function to calculate billing data for each section based on its

usage. 6 Basic Capability to accommodate additions of new disks. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Resource (capacity) management shall not have an effect on the

performance of storage devices. 5.9.5.4. Fault control

Fault control provides functions to monitor and display the status of storage devices, and to issue

messages when failure occurs.

Functional Requirements 1 Basic Provision of a function to provide automatic notification of the occurrence of

monitored events. 2 Basic Provision of a filtering function, which enables automatic classification of the

monitored events.

179

3 Additional Capability to remotely operate the storage devices in the event of a storage failure (centralized control of powering On/Off and restart).

4 Basic Capability to gather information such as the operation/console log, event log, and configuration.

5 Basic Capability to forcefully shutdown connection port links in SAN switches from a remote location. This functionality is required, for example, to perform stepwise disconnection prior to starting maintenance operations.

Non-functional Requirements (description provided only when relevant requirements given) Extendability Basic Compatibility with various types of databases and OSs. Availability Basic Provision of multiple notification methods (e.g. alarm light, mail, etc.).

These monitoring methods must operate concurrently to guarantee secure notification to the management server.

5.9.5.5. Backup management

Backup management provides controlling methods against data destruction that may be caused by

disasters or storage failures (including human errors).

Functional Requirements 1 Basic Provision of functions that enable performance of backup operations without the

use of the LAN or servers (*). 2 Basic Provision of functions to support remote backup and disaster recovery operations

among the hubs. (*) LAN-free backup: a method to backup data by way of SAN, and not by way of LAN.

Server-less backup: a backup method that does not use the LAN, and does not put load on the

server.

Non-functional Requirements (description provided only when relevant requirements given) Security Basic Authority to make a reference to the backup media must be strictly

limited only to the authorized operators. 5.9.5.6. Others Functional Requirements 1 Basic Capability to record an operations log performed to the storage, and the


5.9.6. Functional and Non-Functional Requirements for service desk 5.9.6.1. Service desk management

Service desk management provides functions that enable it to work as the one-stop center for

accepting and managing trouble notifications and various usage inquiries regarding the information

system.

Functional Requirements 1 Basic Capability to manage inquiries that arrive via mails and through the GUI.

180

2 Basic Capability to automatically notify the operator in charge of inquiries, and to register them for storage in database.

3 Basic Capability to attach a file, as auxiliary information, to trouble tickets, problem sheets, and modification management forms.

4 Basic Capability to browse and search past inquiries through the use of a GUI. 5 Basic Provision of an escalation function. 6 Basic Capability to automatically register failure information that was detected by other

management functions through a well coordinated linkage between them. 7 Basic Capability to integrate all information system related application contacts to the

service desk. Non-functional Requirements (description provided only when relevant requirements given) Extendability Additional Provision of an interface that enables coordinated operation with

server monitoring and network monitoring functions. Availability Basic No software restriction shall be placed on the maximum number of

management-related inquiries (extendability must be incorporated).

5.9.6.2. Others Functional Requirements 1 Basic Capability to record an operations log performed to the service desk, and the


181

5.9.7. Functional and Non-Functional Requirements for Security 5.9.7.1. Virus protection function

Virus protection provides function to detect malicious or infected programs to protect servers and

terminals (PCs) from becoming infected with those harmful agents.

Functional Requirements 1 Basic Provision of anti-virus/vaccine software that is compatible with the proposed

OS. 2 Basic Capability of automatic shutdown of PCs following the completion of a virus

scan (if the user plans to shutdown the PC after the virus-scan), or automatic re-execution of the virus scan at the subsequent restart of the PC.

3 Basic Capability of automatically updating the virus definition pattern file, which involves scheduled access to the server of the pattern file provider through the Internet.

4 Additional Capability to execute an update of the virus definition pattern file without the need to restart the system.

5 Basic Capability to detect infected/malicious programs in real time, and to isolate the malicious program or cleanse viruses.

6 Basic Provision of functions that enable centralized management of pattern files in a server, and to distribute them to terminals.

Non-functional Requirements (description provided only when relevant requirements given) Availability Additional Abnormality in vaccine software must not cause the stoppage of

servers and terminals (PC). Availability Basic Stoppage of the distribution server that distributes virus definition

patterns and other information shall not bring the detection function to a stop.

Availability Basic Latest pattern files for virus-checking shall be distributed. Security Basic Provision of protective measures against inadvertent distribution

of spurious virus definition pattern files. Security Basic Inability of the end users to stop the running vaccine software, or

uninstall it. Performance Additional Virus scan and pattern file distribution shall not cause excessive

delay in other normal operation programs. Extendability Basic Provision of scalability to cope with the increased variety of

objects to be distributed (i.e. pattern files and other related files). - The content of this section corresponds to the following items in the Standards for Information

Security Measures for the Central Government Computer Systems: 2.1.1.4, 2.1.2

- The content of this section corresponds to the following segments in the physical configuration

model: S0, S1

182

5.9.7.2. Internet Content Filtering Function

The Internet contents filtering function provides methods to block access to harmful information on

the Web (Internet)

Functional Requirements 1 Basic Introduction of a function to block access from the targeted internal network

to a set of specified Internet URLs. 2 Basic Capability to automatically update the banned URL database by means of

accessing database provider’s servers, such as PICS, via the Internet. 3 Basic Capability to specify the interval to check if there are any updates in the

banned URL database. 4 Basic Capability to allow access authority to URLs only to the specified users. 5 Basic Capability to monitor accesses to the banned URLs. 6 Basic Provision of enough banned URL data within and outside of the country. 7 Basic Capability to classify the banned and allowed URLs into detailed categories. 8 Basic Capability to apply a particular filtering policy on a unit-by-unit, or

user-by-user basis. 9 Basic Capability of centralized user management in coordination with the directory

service. 10 Basic Capability to synchronize multiple servers, even in a load-balancing

environment consisting of a number of servers, by setting and applying a single rule.

11 Basic Provision of flexible rule settings, including such rules as “Browsing allowed & transmission prohibited” and “Filtering after checking its contents.”

12 Basic Capability of category-by-category and user-by-user graphic display access situation.

13 Basic Capability to extract required information (e.g. user name, group name, blocking situation, etc) from the access log.

14 Basic Capability to apply filtering functions to the cache of a search engine and translation functions provided by a translation site. Block log and POST log must be browsable from the management screen or by using report software.

15 Additional Provision of a virus detection capability by analyzing Web contents. 16 Additional Provision of an ICAP client function, or its equivalent within the chassis. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Abnormality in contents filtering functions shall not cause the

stoppage of servers and terminals (PC). Availability Basic Stoppage of the distribution server that distributes pattern files for

contents filtering shall not bring the detection function to a stop. Availability Basic Failures in content filtering functions shall not place any obstacles in

the flawless continuation of network communication, and this must not require user intervention (setting modifications, etc).

Security Basic Provision of a method to check the source of pattern file distribution (e.g. server certificate), enabling confirmation of the legitimacy of the pattern file.

183

Security Basic Inability of the end users to stop the running contents filter, or uninstall it.

Performance Basic Running of the contents filter and distribution of pattern files shall not cause excessive delay in other normal system operations.

Extendability Basic Provision of scalability to cope with the increased number of terminals to be checked by the contents filter.

Related technologies Contents control standard

PICS (Platform for Internet Content Selection) Technical specifications for implementing selective reception of Web contents in accordance with the levels defines by the user. This standard was established by W3C. (Standard) http://www.w3.org/PICS/

- The content of this section corresponds to the following items in the Standards for Information

Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.2.3.2


model: S1

5.9.7.3. Anti-Spam Mail Function Anti-spam mail function provides methods to block spam mails (i.e. the mails that are sent

unilaterally irrespective of the receiver’s will).

Functional Requirements 1 Additional Provision of a personal firewall function that blocks transmission of spam

mails from the client PCs. 2 Basic Provision of appropriate measures to protect the mail addresses that are laid

on public view (e.g. on Web site). Protective measures are required – for example, the use of separate server – because the open addresses are more vulnerable to external menaces in terms of information security than those used by office members.

3 Basic Capability to monitor spam mail reception. 4 Basic Capability to block spam mails based on the source IP addresses. 5 Basic Capability to block spam mails from known senders. 6 Basic Capability to use a white list for message forwarding without blocking. 7 Basic Capability to block spam mails that contain URLs of fraudulent/malicious

Web sites. 8 Basic Capability to block spam mails using a spam fingerprinting technique, or

using other rule sets capable of maintaining higher level of security. 9 Basic Provision of handling a setting capability against mail judged as spam –

isolation, distribution with a tag, destruction, etc. 10 Basic Capability to statistically check the status of spam mail traffic. 11 Additional Provision of a spam mail suppression measure either as an appliance or as

software. 12 Additional Provision of a domain control measure on the delivery side - OP25B, DKIM,

SPF etc. - to block spam mail transmission to the Internet.

184

Non-functional Requirements (description provided only when relevant requirements given) Availability Additional Abnormality in anti-spam functions shall not cause the stoppage

of servers or terminals (PC). Availability Basic Stoppage of the distribution server that delivers anti-spam mail

measures (e.g. pattern file) shall not cause a halt in anti-spam mail functions.

Availability Basic Provision of measures to avoid adverse effects on normal operations (mail traffic, etc.) even in the case of functional failures and stoppage of the anti-spam mail server.

Security Basic Provision of protective measures against inadvertent distribution of spurious anti-spam pattern files.

Security Basic Inability of the end users to stop the running anti-spam functions, or uninstall them.

Performance Basic Checking of spam mails and distribution of pattern files shall not cause excessive delay in other normal operation programs.

Extendability Basic Provision of scalability to cope with the increased variety of objects to be distributed (anti-spam mail pattern files, etc.).

Performance Additional Enough capacity to handle reception processing of a large number of spam-mails.


Security Measures for the Central Government Computer Systems: 2.2.3.1


model: S0, S1, S2, S3, and S5.

5.9.7.4 Firewall Function The firewall provides methods to secure the safety of a particular network by controlling

communication between the network and other external networks.

Functional Requirements 1 Basic Installation of devices with firewall capabilities in the connection points linking the

Internet, internal network, and the utilized system, which allow only particular types of communication traffic.

2 Basic Provision of a packet filtering function, which makes a go/no-go decision of traffic based on IP address and port number.

3 Basic Compatibility with both IPv4 and IPv6 protocols. 4 Basic Capability given to the administrator to configure audit information – including the

address information whose communication traffic was blocked by the firewall. The configuration and verification procedure of the audit information must allow a remote access.

5 Basic Provision of a state-full inspection function, which makes a go/no-go decision on packet traffic based on the state of the communication flow.

6 Basic Provision of the TCP’s network address port translation (NAPT) function. 7 Basic Provision of a network address translation (NAT) function. 8 Basic Provision of a passing control function using a timer targeted at a combination of

IP address and port number (this function also enables the system to monitor UDP communication).

185

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of a multi-device redundant configuration that enables

continued operation even in a case of failure and stoppage of one firewall function.

Performance Basic Capability to continue normal processing even when the system receives a large number of packets.

Security Basic Provision of a function to deny the access of suspicious packets in coordination with IDS.


Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.1.1.3, 2.2.4.1


model: S1

5.9.7.5. Intrusion Detection/ Protection Function Intrusion detection provides functions to monitor communication traffic on the network, and to

detect symptoms of fraudulent access.

Functional Requirements 1 Basic Provision of the capability to analyze the packets that pass through the

network using network type IDS (Instruction Detection System), which enables detection of attacks non-blockable by the firewall.

2 Basic Compatibility with both IPv4 and IPv6 protocols. 3 Basic Capability of automatically updating the pattern file, which involves scheduled

access to the server of the pattern file provider through the Internet. 4 Basic Provision of an anti-intrusion processing function: this function, at the

detection of an intrusion event, blocks the fraudulent access to the targeted segment/host in coordination with the device/software involved (such as a firewall), and outputs the related log as well as issuing an alarm to the monitoring equipment.

5 Basic Provision of an anti-intrusion mechanism that blocks the intrusion of fraudulent packets using a firewall and IPS functions working in coordination with IDS.

6 Basic Provision of an anti-intrusion mechanism against signature-type and anomaly-type intrusions, which involves distribution of highly reliable pattern files on an as-needed basis.

7 Additional Provision of a function to block attacks to applications (SQL injection, cross-site scripting, etc.).

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Implementation of pass-through (by-pass) circuits to avoid breaks in the

network even in the case of equipment failure (this requirement applies to in-line installation).

Availability Basic Buildup of log shall not result in functional stoppage. Security Basic Capability of the network type IDS to operate in stealth-mode. - The content of this section corresponds to the following items in the Standards for Information

186

Security Measures for the Central Government Computer Systems: 1.5.1.1, 2.1.1.4, 2.2.4.2


model: S1

5.9.7.6. Network Connection Monitoring Function A network connection monitoring function provides methods to defend a particular network against

a menacing terminal (PC) by controlling the connection between them.

Functional Requirements 1 Basic Provision of a quarantine function to protect the network: the function performs a

security inspection before a terminal (or other device) is connected to the network, and in case of failure it tries, in cooperation with other network devices, to isolate the failed terminal from the network.

2 Basic Introduction of a mechanism to detect the connection of an unauthorized terminal or other device to the network, in which case the terminal (or other device) is indicated in the specified area on the monitor screen, or a message is displayed.

3 Basic Provision of a function to isolate a terminal that failed security inspection from the network (quarantine), and only permits the use of the server exclusively utilized for security update purposes.

4 Basic Capability to implement a quarantine network by utilizing software (or other techniques) to test security compatibility of terminals.

5 Basic Provision of functions to avoid unauthorized connection of terminals (authentication function by means of IP/MAC address, or that in compliance with IEEE802.1x, etc.).

6 Basic Capability to issue warnings to the administrator regarding the following events/situations: application situation of security patches on the OS, settings of OS firewall, settings of screen saver and log-in password, introduction status of anti-virus software, pattern update status of anti-virus software, real-time scan settings of anti-virus software, checking status of arbitrarily introduced software, and occurrence and isolation status of the terminal that failed quarantine inspection.

7 Basic Provision of a function to analyze and summarize information regarding the number of connected terminals and the security status for each of them during a designated period, and output a report in text format.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of redundancy in network connection monitoring functions,

which guarantees continued operation even when the network devices (e.g. server) with network monitoring capability fail.

Availability Basic Capability to isolate/stop the network connection monitoring function with ease if any trouble occurs in it. That is, such a situation shall not take place in which no PC – with connection authority given by the network connection monitoring function – is connected to the network.

Extendability Basic Capability to connect more than one terminal. Related technologies

187

IEEE802.1x Authentication

Institute of Electrical and Electronic Engineers 802 シリーズ A standard that stipulates the user authentication method at access points: defined by IEEE (Institute of Electrical and Electronics Engineers) LAN standardization committee (802 committee). (Specifications) http://www.ieee802.org/1/pages/802.1x.html




model: S0, S1, and S6

5.9.7.7. Anti-Virus Gateway The anti-virus gateway provides network protection functions against viruses, worms, and spyware

that can intrude by way of e-mail (SMTP, POP3, IMAP), file transfer (FTP), and Web (HTTP) traffic,

and also provides file scanning functions on attached files, whereby the execution of these functions

should not compromise overall performance of the network.

Functional Requirements 1 Basic Capability to automatically update virus protection by downloading the latest

pattern files. 2 Basic Provision of a function to update the anti-virus pattern file immediately after

the release of a new version, either by the provider’s initiative (“push” update) or administrator’s initiative (“pull” update).

3 Additional Capability to connect to the virus checking port using a bridge: the port (except for the administration port) does not require IP address assignment.

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Distribution of the new pattern file against the new breed of viruses within

24 hours after its detection. - The content of this section corresponds to the following items in the Standards for Information

Security Measures for the Central Government Computer Systems: 2.1.2.2, 2.4.3


model: S1, S2

5.9.7.8. VPN Encryption Function VPN (IPSecVPN, SSL-VPN, etc.) provides functions to encrypt communication traffic.

Functional Requirements 1 Basic The code language used must comply with those stated in the “Code Usage

Policy for Procurement on Information System for Cabinet Office and Ministries” (Board of Managers, Liaison Conference for the Ministries and Agencies Concerning Administration Information System (Inter-ministerial Meeting of Government Information Systems Division-Directors), Feb. 28, 2003)

2 Basic Capability to use multiple encryption keys, which should be used selectively for every group and for every person/party located on the other side of information link.

188

3 Basic Capability to perform encrypted communication without the need of encoding/decoding operations.

Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of the above described procedures shall not cause

significant delays in normal business operations. Related technologies Encryption Standard

AES(Advanced Encryption Standard) The U.S. Government’s next generation standard for encryption methods, adopted by the National Information System for Science and Technology (NIST). The new standard was established in March 2001 (FIPS PUB197) to replace DES (established in 1977) due to the concerns about insufficient security. (FIPS PUB197) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

Encryption Standard

3DES(Triple - Data Encryption Standard) An encryption method developed by IBM. A higher level of security has been achieved by the triple application of DES (a secret key cryptosystem developed by IBM).

Electronic Certificate

X.509 Certificate. A standard for open key certificate established by ITU-T (one of X500

directory series included in ISO/IEC international standards). The latest version published in 1997 (X.509v3) added an extension area in

the certificate for arbitrary functional enhancement. X.509v3 was revised in 2000 to bring higher clarity to the quick method of expired information notification to the user and attribute certificate definitions.


Security Measures for the Central Government Computer Systems: 2.1.1.6,2.2.4.1,2.2.4.2,2.2.4.3


model: S0

5.9.7.9. HTTPS Encryption Function The HTTPS encryption function represents the mechanism to combine TLS encryption protocol to

enhance security of HTTP communication.

Functional Requirements 1 Basic HTTP encryption is applied in the HTTP servers made public on the Internet where

the need to prevent tampering and tapping of user-server communication is considered important. In such environment, the HTTP server is required to rigorously restrict the range of the users authorized to access browsing the site, and for uploading data through HTTP traffic.

2 Basic The code language used must comply with those stated in the “Code Usage Policy for Procurement on Information System for Cabinet Office and Ministries” (Board of Managers, Liaison Conference for the Ministries and Agencies Concerning Administration Information System (Inter-ministerial Meeting of Government Information Systems Division-Directors), Feb. 28, 2003)

189

3 Basic Capability for use with several different Web browsers. 4 Basic Capability to apply the SSL server and client authentication technique when data

of special importance is processed (e.g. uploading). 5 Basic Authentication history and HTTP communication log after authentication shall be

recorded and stored for a specified period. 6 Basic As an alternative to the management method of the communication log stated in

the previous item, the trail management function may be used. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of above described procedures shall not cause significant

delays in normal business operations. Performance Basic In case an attempt is due to incorporate TSL in an HTTP server that

suffers heavily concentrated access, an introduction of a dedicated TSL server shall be considered.

Availability Basic In case a dedicated TLS server is already in place, stoppage of the server (due to failure, hazard, etc.) shall not affect operations of HTTP servers.

Related technologies Security Protocol

TLS (Transport Layer Security) A protocol that provides encryption functions for communication requiring security. It is implemented as a wrapper for TCP communication, thus it is independent of the upper level protocols. (TSL1.1/RFC4346)http://tools.ietf.org/html/rfc4346




model: S0, S1

5.9.7.10. File Encryption Function This function provides methods to encrypt files.

Functional Requirements 1 Basic Encryption functions shall be applied to terminals both within and outside the

ministries. 2 Basic Capability to encrypt a variety of document files including those created by word

processing and spreadsheet software. 3 Basic The code language used must comply with those stated in the “Code Usage

Policy for Procurement on Information System for Cabinet Office and Ministries” (Board of Managers, Liaison Conference for the Ministries and Agencies Concerning Administration Information System (Inter-ministerial Meeting of Government Information Systems Division-Directors), Feb. 28, 2003)

4 Basic Capability to encrypt shared information on the server on a department/project basis, and to block access from third parties by imposing access controls.

5 Basic Provision of simple operations for encrypting and decoding. 6 Basic Capability of automatic encryption of hard disk contents.

190

7 Basic Provision of simple and easy file encryption methods in preparation for storage in external media.

8 Basic Provision of a function to block taking information out of the ministries without encryption – for example, by disconnecting external media (USB memory, MO, FD, external HDD, etc.) out of the terminals installed within the ministry.

9 Basic Capability of automatic data encryption to be performed when the data is transferred for storage to the external devices (e.g. USB memory, MO, FD, external HDD, etc.) connected to the terminals installed in the ministry.

10 Basic Capability to decode encrypted files that were transferred from the devices within the ministry to those in places out of the ministry without relying on a specially-installed encryption software installed on the latter (password entry for authentication may be a required step).

Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of the above described procedures shall not cause

significant delays in normal business operations. Backup Basic Provision of a fail-safe mechanism that enables decoding of an

encrypted file even if the terminal in which the encryption were performed fails – for example, through the use of a backed-up decoding key.





5.9.7.11. Trail Management Function Trail management provides log management functions for controlling system/network users (and

programs). These include functions for login/logout management.

Functional Requirements 1 Basic Provision of functions to gather and store log information regarding the operations

performed in client PCs and servers - mail delivery, Web access, file operation, printing, etc.

2 Basic Capability to define the target information assets prior to the start of log gathering. 3 Basic Capability to gather such trail information as the name of accessed information

assets, user name that accessed it, types of manipulation performed on it, and date and time of the access event.

4 Basic Capability to automatically output the log for centralized management. 5 Basic Provision of a function to perform statistical analysis of the gathered trail

information, and to output the results (e.g. in graphic format). 6 Basic Provision of functions to perform log information gathering, long-term storage of it,

and backing it up, as well as the ability to browse it on an as-needed basis. 7 Basic Provision of a function to output the results of log gathering and summarized

information either in CSV or PDF format. 8 Basic Provision of a function to output the compiled summary of log information in

graphical format.

191

Non-functional Requirements (description provided only when relevant requirements given) Security Basic Provision of a function to protect the gathered log information against

any attempt of tampering. Security Basic Provision of appropriate measures – access control, encryption,

anti-tampering and tampering detection etc. - to protect trail logs against fraudulent use by third parties.

Extendability Basic Capability to handle OS logs (normal/error log of the system and applications) in the same fashion as above.

Performance Basic Execution of log gathering operations shall not cause significant delays in log output functions.

Backup Basic Provisions of appropriate measures (e.g. making a backup) to protect the trail log against file corruption and deletion.





5.9.8. Functional/Non-Functional Requirements for Job Management

Job management provides functions to maintain scheduled execution of business operations,

which include defining the procedural flow of routine tasks and triggering jobs on/at a given day/time

or at a specified event.

Functional Requirements 1 Basic Capability to define a system operation calendar. 2 Basic Capability to schedule the series of programmed job execution in accordance

with the system operation calendar, and to execute them automatically. 3 Basic Capability of centralized management of job operation controls. 4 Basic Capability to record the situation under which the jobs are performed and

record the execution history as log information. 5 Basic Capability to monitor job execution status. 6 Additional Capability to start job execution triggered by such events as a timer, file

reception, and file modification. 7 Basic Capability to manage a day by [48]-hour system. 8 Additional Capability of blanket definition/modification of a large number of jobs. Non-functional Requirements (description provided only when relevant requirements given) Security Additional Capability to restrict the range of available functions (definition,

execution, reference, etc.) depending on the authority given to a user.

Backup Basic Capability to backup the calendar definitions and job definitions.

192

5.9.9. Compatibility with virtualization Functional Requirements (compatibility with virtual environment) 1 Basic Capability to deploy an equivalent set of software to achieve the same level of

performance in a virtual environment as in the physical server environment. The virtual environment consists of such elements as a virtual guest server, virtual storage, and a virtual network realized through the use of virtualization mechanisms.

193

5.10. EIP

5.10.1. Definition EIP represents the “Enterprise Information Portal” that provides functions conducive to perform

effective IT-system based business operations, including the function to control information and

applications centrally for delivery to Web browsers running on the terminals. It delivers an assortment

of views on a screen linked to contents and applications appropriately assigned to the user depending

on his/her role in the portal site.

EIP Functions & Services Function & Service Definition Portal Site function Functions to create an integrated view as a Web page (portal site)

comprising of multiple applications – business applications, groupware applications, information contents (documents, images, animations, etc.) – capable of transmitting/receiving information to/from other Web browsers.

Personalize function A function to identify each portal site user and his/her role, and create a combination of contents and applications most suited to him/her, enabling delivery of it in a unified screen or view.

Application integration function

A mechanism to achieve on-portal site integration of the job-related roles of a portal site user and applications, thus enabling close linkage among them. The target applications include such business packages as groupware, business intelligence (BI), customer relationship management (CRM), and enterprise resource planning (ERP), as well as XML Web service applications.

Management An EIP related management function. It includes user management, contents management, auditing, other various management functions and backup.

5.10.2. Portal Site Function Functional Requirements 1 Basic Capability to perform user authentication/authorization on a portal site basis, and

the capability to perform these tasks in coordination with other directory services external to the server.

2 Basic Customization: allowance to freely change the combination of information contents and applications incorporated in the portal site, and to rearrange the screen layout.

3 Basic Search: a function to search, by entering a keyword to a search field on the portal site screen or a search application, the objective through the information contents and application data accumulated on the portal site, and report the search result information on the site’s screen.

4 Basic The portal site shall have a capability to respond to accesses from the Web browser installed on such devices as PC, PDA, and mobile phones.

194

Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of system configuration that has multiplexed portal sites

over a plural of server hardware systems, which ensures uninterrupted system operation even in the case of failure in one server utilizing other servers.

Load balancing

Basic Provision of system configuration with its portal site servers multiplexed over a set of plural server hardware systems, which enables to balance the load of access request to the site.

Performance Basic Provision of enough performance capacity that enables to process the amount of user access requests arriving at the portal site simultaneously.

5.10.3. Personalize function Functional Requirements 1 Basic Customize function: customizing capability to combine the required contents

information and applications, and to define/edit the screen layout depending on the user’s role in business operation.

2 Basic Personalize function: capability to change the set of information (selection of views and applications) in accordance with the attribute information of the logged on user.

5.10.4. Application integration function Functional Requirements 1 Basic Portlet collaboration: capability to link/integrate portlets – those within the

user’s server, as well as remote portlets that are openly released as Web services – to facilitate operating applications and contents placed on other servers.

2 Basic External connection: capability to link business systems, business applications, and databases that are connected to the network and operating within and outside of the common infrastructure.

3 Basic Web service collaboration: capability to perform linkage/integration operations on the screen of the portal site in coordination with the applications provided as a Web service.

Related technologies Directory service protocol LDAP (Lightweight Directory Access Protocol)

195

4 Basic Provision of functions to integrate the following types of groupware applications on the portal site screen. 1) Scheduling function 2) Meeting room, bulletin board 3) Electric mail 4) Workflow of routine tasks (attendance management, expense calculations, etc.) 5) Database searching 6) Document management

5 Additional Application collaboration: provision of a function to perform integration/linkage operations on the screen of the portal site in coordination with application package products (business intelligence (BI), customer relationship management (CRM), and enterprise resource planning (ERP)).

5.10.5. Management Functional Requirements 1 Basic User management: capability to manage (register/edit/delete) the user ID

and personal information of the users that have access authority to the portal site.

2 Basic Audit: capability to browse the access history (log) to the contents and applications within the portal site. The access history shall include such information as: date and time, information to identify the computer accessed, and the access result (success/failure).

3 Additional Single sign-on: Provision of a function to authenticate and authorize the user automatically, to access desired contents/applications with a single action (i.e. entry of user ID and password) done by the user when he/she tries to login to the portal site. This involves contents and application management in association with the user ID and password for user authentication and authorization.

Non-Functional Requirements (description provided only when relevant requirements given) Backup Additional Provision of a system configuration that enables backing up the

information contents and management data contained in the portal site.

Related technologies Web service related protocols SOAP

WSDL

196

5.11. Open Web Server

5.11.1. Definition The Open Web Server distributes information content through the Internet, and its primary use is

as a tool to disclose information to the general public as well as to enterprises. Because it operates

24 hours a day and 7 days a week embracing a variety of access from unspecified clients, it is under

constant threat from all sorts of possible malicious attacks (data tampering, denial of service,

information tapping, unauthorized promotion/denial of access authority, etc.). Therefore, measures

must be adopted to protect assets from those attacks, and to prevent security events/accidents from

occurring. These measures are implemented in a high-security segment with firewall isolation, or

DMZ (DeMilitarized Zone), which lies in between the external network (the Internet) and internal

network.

In light of possible IPv4 address depletion problem, previous considerations must be due for proper

coexistence and parallel usage of IPv4 and IPv6. This involves careful implementation of

operation/management/monitoring/maintenance methods, at the design stage as well as in the

purchase of equipment, and security measures for running various devices used on open Web server

devices.

Mail server

Communication within the Cabinet Office and Ministries

Internet

General user (citizens, enterprises)

Load balancer (load balancing

equipment)

DMZ

External f irewall

CMS equipmentInternal Proxy

serverInternal DNS server

Internal f irewall

Intranet

Mobile access server

Open DNS server

DMZ

Open Web server

External Proxy server

Figure 5.11-1 Open Web Server Configuration

197

Functions and services provided by the Open Web Server Function & Service Definition WWW service Refers to the contents distribution services utilizing HTTP

protocol - documents, images, and other data - conducive to information disclosure to the general public and enterprises.

FTP service Refers to the services utilizing FTP protocol that enables file transfer (upload and download) between the terminals located outside the ministries and the open Web server. The services shall be mainly used for distributing/uploading large size files, or frequently updated files.

Content management system (CMS)

The Content Management System (CMS) provides services such as production and management of Web-based digital content – released/distributed from the WWW services running on the open Web server – and performs distribution/review/maintenance services for the open Web server. CMS shall include functions that assume due considerations for compatibility with the internal control and accessibility.

-Assumed users/usages-Site (information distribution)

managerAllocation and authority settings of information

distribution

-Assumed users/usages-Server manager

Server management/audit-Assumed users/usages-

Internet connection usersWeb site browsing

File upload/download

WWW service

Operating system

Access log

Open Web server

Web browser

Operation management tool/audit toolGUI/CUI

WAF（Web Application Firewall）

FTP service

Load balancer (load balancing equipment)

FTP client

Figure 5.11-2 Schematic Overview of Open Web Server

198

5.11.2. WWW Service Functional requirements 1 Basic This function returns contents stored in the Web server responding to

requests from users (e.g. Web browser clients). It shall include such additional capabilities as: running server-side script language (SSI, etc.) embedded in the content to convert and send data (HTML, etc.), and running external programs on the server that dynamically format and send data (HTML, XML, images, etc.).

2 Basic User authentication/authorization: provision of a function to identify the user, when an access is made to an open site, and gives authentication accordingly – i.e. allows access to, and usage of the site only for those who already have been authorized, and denies access to others. It also shall be able to set the access range and operation limit for each user within the open Web site, and to grant authorization accordingly. Additionally, the authentication/authorization procedures shall be capable of performing in coordination with external directory services.

3 Basic WAF (Web application firewall): Provision of the capability to detect improper data indicative of malicious attacks (such as SQL injection and cross-site scripting) and block these accesses, which requires rigorous inspection of transmitted/received information to/from the applications and Web pages on the open Web site.

4 Additional Server certificate and path encryption: Provision of a function to install a server certificate (server’s open key and server information), and to encrypt transfer data using SSL protocol. The encryption method shall have encryption strength compatible with those code languages listed in the e-Government recommendations.

5 Basic File format management for delivery: Capability to define a set of file formats for use in file delivery from a Web site, and inhibit those that are not included in that set from being used in file transfer.

6 Basic Allocation of delivery file: Capability given to the Web administrator to allocate contents and set access authority for delivering information through the intra-net and open Web site, and execute quick check/test on the latest update information of the contents.

7 Basic Access log record: Capability to record an access log for the accumulation of access history files (who, when, what, and the last access to the information, etc.). The log information shall be recorded in a way that allows selection/specification of type and order of information to meet the requirements of HTTP communication, and should be capable of outputting in either W3C extended log file format or NCSA common log file format.

8 Additional Audit: Capability to compile an auditing report from the stored stock of access logs in different perspectives (for each audit event, for different time windows, for each user,…).

199

9 Additional Efficiency measurement: Provision of the capability to measure the work load on a WWW site (number of concurrent connections, average request frequency, etc.), processing efficiency (HTTP process throughput, response time, etc.), and resource usage status (CPU utilization ratio, etc.).

10 Basic Session management: Provision of a function to issue a session ID needed for the Web application to perform safe session management, and to maintain the session information.

11 Basic Management interface: Provision of GUI (Graphical User Interface) or CUI (Character-based User Interface) tools to help perform various management operations (add/edit/delete a user account, setting of site authority, setting of file types for delivery, auditing, performance monitoring, etc.) from the management terminal installed in the internal network. Provision of a set of API‘s (Application Program Interface), used to invoke management tasks for programs, is also required.

200

Non-functional Requirements (description provided only when relevant requirements are given) Performance Basic Provision of sufficient processing capacity - in terms of the number

of concurrent connections, SPECweb value, etc. - to meet the client’s (mainly Web browser) requirements.

Availability Basic Provision of a system configuration (clustering, etc.) that enables continued processing of subsequent request even after a failure in server hardware or middleware.

Upgradability of processing performance

Basic Capability to secure sufficient processing capacity – through increasing/decreasing server resources, and additional installation or removal of servers – to meet the changing load requirements (number of concurrent connections, increasing/decreasing number of accesses) without needing to stop services.

Upgradability of SSL performance

Basic Provision of a system configuration that enables the addition of performance enhancement mechanisms for SSL protocol (for higher encryption and decoding performance, e.g. SSL accelerator).

Regular delivery of security patch information to middleware and OS

Basic Delivery of vulnerability and security patch information to the server administrator regularly (for example, once a month). This service shall be included in the information delivery target software provided by the information security service vendor, and may require affiliation to some kind of information delivery service.

Application of security patch to middleware and OS

Basic Capability to perform the following procedures: application, test and verification, and situation-dependent cancelling (deletion) of security patches to the operating system and middleware distributed by Web page.

Service delivery time zone

Basic Capability of service delivery on a “24 hours a day / 7 days a week” basis.

Backup, restoration

Basic Capability to backup data on the open Web site (distributed contents and server configuration information) without needing to stop Web site operations, and to restore the site quickly using the backup data.

Remote management

Basic Provision of a system configuration that enables the performing of management tasks targeted at an open Web site from the administrator terminal implemented in the internal network.

Load balancing Basic Provision of a load balancing function (a device) implemented on the front side of the open Web server, and the capability to realize a load-balanceable configuration using it.

201

Related technology Web server's client-to-client (Web browser)communication protocol

HTTP (Hyper Text Transfer Protocol)

Web page description language HTML (Hyper Text Markup Language) This markup language has been standardized as HTML 4.01specifications (W3C recommendation, 24 Dec.1999).

CSS (Cascading Style Sheets) This style sheet has been standardized as CSS2.1 specifications (W3C recommendation, 9 Sep. 2009).

Technology to run external program on the server

CGI (Common Gateway Interface) CGI has been standardized as RFC3875.

Java Servlet ASP.NET (Active Server Pages for .NET)

Server-side script language SSI (Server Side Include) PHP (Hypertext Preprocessor) JSP (Java Server Pages)

Unit for Web processing efficiency measurement

SPECweb

Authentication scheme Basic Authorization Digest Authorization

Directory service protocol LDAP (Lightweight Directory Access Protocol) Path encryption protocol SSL(Secure Socket Layer) Standard for sending/receiving various types of files as e-mail, or using HTML protocol

MIME(Multipurpose Internet Mail Extension)

Log file format W3C extended log file format NCSA common log file format

Monitoring, Control Mechanism/Protocol

SNMP (Simple Network Management Protocol) WBEM (Web-Based Enterprise Management)

202

5.11.3. FTP Service Functional requirements 1 Basic Capability to provide server-side file transmission/reception services for file

transfer practice between the client PC and the open Web server. 2 Basic User authentication/authorization: Provision of a mechanism to identify the

user, and authorize/deny the user the ability to perform specified operations and access to the targeted files and folders based on the authority given to him/her. These authentication/authorization procedures shall be capable of performing in liaison with the OS’s access control functions and external directory services.

3 Basic Transmission/reception data encryption: The encryption method shall have the encryption strength compatible with those methods listed in the e-Government recommendations.

4 Basic User separation: Capability to separate the area (folder) for uploading/downloading on an user-by-user basis, and isolate it from those used by other users. Capability to create a user folder in accordance with the structure specified, and to define the folder capacity and maximum file size allowed for transfer on a user-by-user basis.

5 Basic Access log record: Capability to record and accumulate operation history as a series of log files (who, when, what, and the types of operation). The log information shall be recorded in the way that allows for the selection/specification of the type and order of information to meet the requirements of FTP communication, and should be capable of outputting in either W3C extended log file format or NCSA common log file format.

6 Basic Audit: Capability to compile an report serviceable for auditing from the stored stock of usage status logs in different perspectives (for each audit event, for different time windows, for each access user,…).

7 Basic Client access: Capability to access an FTP site from a client PC utilizing a Web browser or CUI (Character-based User Interface).

8 Additional Efficiency measurement: Provision of a capability to measure processing requests (number of concurrent connections, etc.), processing efficiency (transfer rate, etc.), and resource usage status (CPU utilization ratio, waiting status of I/O queue, etc.).

9 Basic Management interface: Provision of methods to perform various management operations - add/edit/delete a user account, setting of site authority, setting of file types for delivery, auditing, performance monitoring, etc. - from the management terminal located on the internal network. If the management method involves the use of a GUI (Graphical User Interface) or CUI (Character-based User Interface), a set of APIs ((Application Program Interface) shall be provided for the programs to access management tasks.

203

Non-functional Requirements (description provided only when relevant requirements are given) Performance Basic Provision of sufficient performance capacity to the process

uploading/downloading load of files (number of concurrent connections, data transfer capability, etc.).

Data storage capacity

Basic Provision of sufficient disk area capacity for the secure storage of uploaded/downloaded files.

Availability Basic Provision of a system configuration that allows for continuous normal processing of subsequent requests by surviving servers even after a failure in a single server hardware, OS, and middleware.

Expansibility of disk area

Basic Capability to expand free space for storage of uploaded/downloaded files within a given period of time (this may be required when capacity shortage is imminent).

Upgradability of processing performance

Basic Capability to secure sufficient processing capacity – through increasing/decreasing server resources, and additional installation or removal of servers – to meet the changing load requirements (number of concurrent connections, increasing/decreasing number of data transfer requests) without needing to stop services.

Regular delivery of security patch information to middleware and OS

Basic Delivery of vulnerability and security patch information to the server administrator regularly (for example, once a month). This service shall be included in the information delivery target software provided by the information security service vendor, and may require affiliation to some kind of information delivery service.

Application of security patch to middleware and OS

Basic Capability to perform the following procedures: application, test and verification, and situation-dependent cancelling (deletion) of security patches to the operating system and FTP service middleware.

Service delivery time zone

Basic Capability of delivery on a “24 hours a day / 7 days a week” basis.

Backup, restoration

Basic Capability to backup data on the file storage area of an FTP site without needing to stop services, and to restore the site quickly using backup data.

Remote management

Basic Provision of a system configuration that enables the performing of management tasks targeted at an open FTP site from the administrator terminal implemented in the internal network.

Load balancing Additional Provision of a system configuration that enables balancing of file transfer load among the servers: i.e. capability to construct an FTP site by combining multiple servers and allocating a larger load to the server with the minimum track record in terms of the volume of data communication.

204

Related technology File transfer protocol FTP (File Transfer Protocol) Directory service protocol LDAP (Lightweight Directory Access Protocol) Data encryption protocol in file transfer

FTPS (File Transfer Protocol over SSL/TLS) SFTP (Secure File Transfer Protocol)

Log file format W3C extended log file format NCSA common log file format

Monitoring, control mechanism/protocol

SNMP (Simple Network Management Protocol) WBEM (Web-Based Enterprise Management)

205

5.11.4. Content Management System (CMS) Functional requirements 1 Additional Capability to utilize/include content from existing Web sites in an content

production effort. 2 Additional Capability to search and list various contents (text, images, etc.) for

browsing/referencing to facilitate content production. 3 Additional Capability to easily produce and control contents, that have standardized and

unified page design for controlled accessibility throughout the site, by utilizing templates (such as Web page prototypes).

4 Basic Capability to update contents by editing HTML files. 5 Additional Capability to handle various data formats (PDF, Flash, text, Microsoft Office

documents, etc.) for content files. 6 Additional Provision of an authority management function (including authentication and

authorization) to assign to specified users or to user groups, the authority to operate on contents. The authentication and authorization functions shall operate in conjunction with other directory services.

7 Basic Capability to register pre-release content files on the Web page, enabling the ability to preview the expected image after release.

8 Additional Provision of a function to automatically carry forward the approval and release process for new content, or a workflow that promotes this process.

9 Additional Provision of a function to automatically release a new content on the open Web server on the scheduled day (the content and release schedule must be defined in advance).

10 Additional Capability to perform such operations as: reference to revision history of content, review older images of content, and rewind the display back to one of the older versions.

11 Additional Capability to browse past actions done by the persons in charge of production/maintenance/presentation of content (who, when, and which operation).

12 Additional Capability to deliver update information for a Web page using one of the update information distribution technologies (RSS feed, ATOM feed, etc.).

Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Capability to continue content delivery using WWW services

even in the event of CMS stoppage. Backup, restoration

Additional Capability to save backup copies of Web contents even while they are under production or in the process of being delivered. A function shall be provided to rewind the Web content to an older state by restoring from the backup.

Related technology Web accessibility criteria JIS X 8341-3

W3C WCAG (Web Content Accessibility Guidelines) 1.0/2.0 Directory service protocol LDAP (Lightweight Directory Access Protocol)

206

5.12. Groupware, File Server, and Mail Server

5.12.1. Definition of groupware, file server, and mail Server

The groupware, file server, and mail server are accepted as productivity enhancing mechanisms

for organizations as they realize sharing and exchange information among the information system

users. These mechanisms provide such facilities as electronic mail, electronic bulletin board,

electronic conference room, scheduling, conference room booking, and file sharing. The objective of

these facilities is to achieve smoother communication among the users, and thus support information

sharing for well-informed policy planning.

Figure 5.12-1 Functions and services provided by groupware, file server, and mail server

The groupware, file server, and mail server typically provide the following six functions/services.

1) Groupware

2) Electronic mail

3) File sharing

4) Instant messaging

5) Full-text search

6) Web conference

207

Functions and services provided by groupware, file server, and mail server

Function & Service Definition Groupware Groupware provides facilities for information sharing among

users, and thus contributes to achieving smoother communication. The users can exchange their opinions and information using the electronic bulletin board and electronic conference. Such functions as user schedule management, facility management (e.g. conference room), and To-Do list contribute to enhance routine task efficiency for the users. The groupware also provides functions for managing attribute information (e.g. user ID assigned to each user, and the group he/she belongs), allowing it to be used as an employee directory.

Electronic mail Electronic mail provides the users with the means to send/receive an e-mail within the ministry or with external organizations. Standardized protocol for sending and receiving mails is employed, and communication requests from the terminals shall be compatible with SMTP (for transmission) and POP, IMAP (for reception). In light of the need to exchange highly confidential e-mails, this function shall be compatible with encryption and electronic signature. To avoid virus infection via e-mail communication, it shall perform anti-virus functions by checking attached files. Note that the e-mail communication may be provided as a function of groupware.

File sharing Refers to the practice of shared use of storage resources among the terminals, making cross-user information sharing easier and quicker. This mechanism includes the shared use of storage areas under the control of file server, enabling file sharing according to the user’s affiliation and authority. Rigorous access control shall be implemented in the file sharing mechanism, and access history shall be recorded in the audit log.

Instant messaging Refers to the provision of a real-time message exchange function, whereby the usage status of the users is checked in advance. This function shall not only be able to identify if the user is on-line or off-line, it provides further on-line status information (i.e. enabled/disabled to respond, at/away-from-desk, at conference, etc.), enabling to select the contact method most suited to the situation (telephone/e-mail, instant messaging).

Full-text search Refers to the functions to search for a given string among the document database provided by groupware and the stock of document files stored on the file server. The user shall be able to use combined criteria – single of multiple keyword, and logical conditions connecting them (AND, OR, etc.) – and only

208

the allowed range of the search results shall be presented to the user depending on his authority level.

Web conference Refers to the functions that allow a plurality of users on the network to have a conference, sharing a common screen and using voice/video communication. It also provides functions to share office documents, and shared use of a virtual whiteboard to which the conference participants are able to write sentences and figures. A Web interface is also provided for booking and managing a Web conference.

209

5.12.2. Functional/Non-Functional Requirements and Standard Technology of Groupware Functional requirements 1 Basic Capability of the user to register/modify/delete the documents posted to

electronic bulletin board. 2 Basic Capability to add a link to the posed document (link to a file, table, image,

document, etc.). 3 Basic Capability to classify the posted documents based on the information

displayed on the document list screen – for each author, for each category, etc. Capability to perform search among the posted documents based on “keywords or other information.”

4 Basic Capability given to the system administrator to define the users with authority to access the bulletin board, and restrict the range of their usage authority.

5 Basic Capability given to the system administrator to delete a document from electronic bulletin board if the document is considered inadequate for public view.

6 Basic Provision of functions to support electronic conferences, where multiple users can post/exchange their opinions on a specific theme.

7 Basic Provision of functions to create multiple electronic conference rooms for each discussion theme, and users’ opinion (posting) shall be recorded as electronic data.

8 Additional Capability to display the series of postings on a specific theme in a hierarchical structure for easy viewing as a single thread.

9 Basic Capability of schedule management on a user-by-user basis. Capability to define and manage the range of users whose schedules will be put on view for others.

10 Basic Capability to browse schedules of multiple of users that belong to the same organization/group, and to search their vacant times.

11 Basic Capability to register repetitive schedules (weekly, monthly, …), with an authority to accept/reject the request for schedule registration.

12 Additional Capability to identify an overlapped portion of a schedule (if any) by means of a symbol or marking.

13 Basic Capability given to the user to refer to the booking status of facilities (e.g. conference room).

14 Basic Capability given to the administrator to manage registration/update/deletion of facilities. The administrator shall be able to assign access authority on facility-by-facility basis.

15 Basic When a user tries to reserve a conference room, he/she shall be able to search for a vacant time zone for the room. The user shall also be able to search for an available room at a specified time window.

16 Basic In synchronization with the booking of a conference room, a notification message shall be sent to those involved by e-mail or other means.

17 Basic Capability to manage To-Do lists created by users. 18 Basic Capability to manage the progress status of tasks (work) registered in the

To-Do list, which necessitates the capability to assign the start date, terminal date, and priority information for each task.

210

19 Basic Provision of an electronic telephone directory function as well as the directory for the centralized management of the users. Search capability - based on such information as the name, affiliation, telephone number, mail address, etc. - shall be provided as well.

20 Basic Authentication of a user, when he/she tries to use groupware, shall be performed using the user ID and password assigned to each user.

21 Basic Provision of a graphical user interface (GUI) for easy access for users. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced

availability, by employing such technologies as redundant servers, clustered software, and replication.

Security Basic Capability to exercise rigorous control on each of the functions provided by groupware - e.g. electronic bulletin board, electronic conference room, schedule, facility booking, To-Do list, and electronic telephone directory.

Additional Capability to encrypt communication to ensure security. Performance Basic The system design shall assume {approximately 50 thousand}

users, and the system configuration shall provide sufficient processing capacity to meet the stated performance requirements.

Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Capability to save backup copies of contents created by the user (posting, schedule, booking, tasks, etc.) along with the configuration information.

Related technology Directory service protocol

LDAP (Lightweight Directory Access Protocol) is a standard protocol used for connection with the directory service. LDAP V3 has been established.

Directory exchange format

LDIF (LDAP Data Interchange Format) defines the file formats used to exchange LDAP account information.

Supplementary note: Groupware, in the broad sense of the term, may include such functions as

electronic mail, instant messaging, and Web conferencing. An appropriate specification description

shall be adopted in view of the purchase range.

211

5.12.3. Functional/Non-Functional Requirements and Standard Technology of Electronic Mail Functional requirements 1 Basic Provision of a web mailing function, and the capability to create, transmit,

and receive mails from electronic mail clients. Requests from electronic mail clients shall conform with SMTP (transmission) and POP, IMAP (reception). Web mail shall conform with HTTP/HTTPS.

2 Basic Mail format shall support an HTML format as well as a simple text format. 3 Basic Functions to sort the mails – based on such criteria as destination and

content - shall be provided. The folders used to sort the mail shall be allowed to have a hierarchical structure, enabling easy search by specifying conditions.

4 Basic Provision of an automatic sorting function to given folders based on such information as the sender and the keyword included in the subject. The user shall be able to assign multiple addresses and keywords for sorting mail.

5 Basic The address book shall provide functions compatible with Japanese names and Japanese organization names.

6 Basic Capability to encrypt the body text of a mail and attached files for exchange of

e-mails with a high level of confidentiality. Provision of functions for sender

authentication, and to give/check an electronic signature. The encryption

method and electronic signature shall be compatible with S/MIME. 7 Additional Capability to send a notice of absence to the sender if the receiver is absent. 8 Basic Electronic mail clients shall have the capability to read and create a mail

even when the network is offline. 9 Additional Provision of the mechanism given to the electronic mail clients to avoid

erroneous transfer and diverted use of the mail (through copy & paste and printing).

10 Basic Capability to restrict the size of mail boxes provided to the users. 11 Basic Provision of functions to link with groupware’s schedule management and

facility booking functions (e.g. automatic mail transmission to members when a schedule is registered).

12 Additional Provision of an option to confirm if the mail has been read. 13 Additional Capability to perform a virus check of the files attached to a mail on the mail

server using anti-virus software. For encrypted mails – as it is difficult to for check viruses on the mail server – methods shall be provided to run virus checking on other locations (e.g. terminal).

14 Additional Capability to save archived mails for auditing: this is a measure to avoid unauthorized use of mails and information leaks.

15 Additional Provision of settings that prevent external leakage of ministerial physical information to the outside world (e.g. the IP address of ministry mail server may be leaked by being attached to a mail header).

212

16 Additional The request to send from electronic mail clients shall be authenticated and compatible with SMTP over SSL/TLS, and the request to receive shall be compatible with POP over SSL/TLS, or IMAP over SSL/TLS.

Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced

availability by employing such technologies as redundant servers, clustered software, and replication.

Security Additional Capability to verify electronic mails using sender domain authentication to detect malicious mails (avoidance of tampering and spoofing of electronic mails).

Additional Provision of mechanisms to prevent erroneous mail transmission: for example, placement of a wait before mail delivery and cancels sending if an error in the destination description is found.

Additional Provision of a mechanism to send only the mails authorized by the approver: this applies when handling highly confidential mails.

Performance Basic The system design shall assume {approximately 50 thousand} users. Performance specifications shall be made clear in advance, for creation of the system with sufficient processing capacity.

Additional The size of the mail box per user shall be at least {100MB}. Extendability Additional In view of a possible increase in the number of users, the system

configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Capability to store backups of mails transmitted and received by the user, as well as the setting information.

Related technology Mail transmission protocol

SMTP (Simple Mail Transfer Protocol) is a standard protocol used to send an electronic mail. It is used when a user sends an electronic mail to the mail server, and the electronic mail is transferred between mail servers.

Mail reception protocol

POP3 (Post Office Protocol) is a protocol used to receive a mail from the server where electronic mails are stored. It is used when a user tries to receive an electronic mail from the mail server. The mails are stored and managed on a terminal. IMAP4 (Internet Message Access Protocol) is a protocol used to receive a mail from the server where electronic mails are stored. It is used when a user tries to receive an electronic mail from the mail server. The mails are stored and managed on the mail server.

Mail encryption method

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard method used to encrypt an electronic mail, and to create an electronic signature. It is utilized by the user to encrypt an electronic mail and create an electronic signature.

Supplementary note: In terms of the effective use of electronic mails, the configuration of the

mechanism to be procured may differ from case to case: for example, intra-ministerial mail exchange

and external communication – with external organizations, and mail exchange via the Internet – may

213

require different configurations (e.g. implementation of a mail gateway). Therefore, the procurement

planning requires clear specifications regarding the range of the mail exchange (within the ministry,

with external organizations, or via the Internet).

(Example)

[In this procurement, the scope of mail exchange is intended only for intra-ministerial

communications.]

[In this procurement, the scope of mail exchange includes, not only within the ministry, but also

extra-ministerial mail traffic with other ministries and local governments via the Kasumigaseki WAN

and the LGWAN.]

[In this procurement, the scope of mail exchange includes traffic with private sectors via the Internet,

as well as within the ministry and with other ministries.]

214

5.12.4. Functional/Non-Functional Requirements and Standard Technology of File Sharing Functional requirements 1 Basic Provision of file sharing functions among the users. 2 Basic OS standard file management software and Web browser shall be given an

access capability to shared resources. 3 Basic Capability to control access by setting graded access privileges to the users

depending on the user’s authority. The access control shall have the authority to manage creation, reference, modification, and deletion of files and folders.

4 Basic Capability to record an access log to the shared resources, and output information for the analysis of unauthorized accesses.

5 Basic Capability to encrypt data to be stored on the file server. 6 Basic Capability to create a backup on a regular basis: required for easy

restoration in case of data loss by user’s inadvertent operation. 7 Basic Capability to limit available disk capacity for each user, and for each shared

drive (management of the used space of disks). 8 Additional Capability to perform a full-text search on all the files stored in the file server. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of system configuration that provides enhanced


Additional Adoption of RAID technology in storage devices as an insurance policy against disk failures.

Security Basic Provision of a mechanism to protect the data stored on file servers against information leak and tampering caused by unauthorized accesses.

Additional Capability to encrypt communication to ensure security.

Performance Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.

Additional Capability to process accesses from {300 terminals} simultaneously.

Additional The file server shall have an effective capacity equal to, or larger than {100 TB}.

Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.

Backup Basic Capability to save backup copies of data on the shared disks, along with the configuration information.

215

Related technology File sharing protocol

CIFS (Common Internet File System) is a standard protocol used to share files on a TCP/IP network.

216

5.12.5. Functional/Non-Functional Requirements and Standard Technology of Instant Messaging Functional requirements 1 Basic Provision of a real-time message exchange mechanism, whereby the usage

status of the users on the terminal are checked in advance. 2 Basic Capability to manage users by grouping: a contact list (persons on the end of

line) specific to each user shall be compiled for message exchange. 3 Basic Capability to display if the persons on the contact list are present or absent by

online/offline identification. 4 Basic The status indicators used to show that the person is on-line shall be

user-selectable: “ready to respond,” “unable to respond,” “absent from the desk,” and “at conference,” etc.

5 Basic Capability to display user’s attribute information (telephone number, mail address, etc) as well as his presence/absence status.

6 Basic Capability to save the message exchange history (sorted on person-by-person basis on the other end of the line).

7 Basic Capability to exchange messages among three or more users, as well as conduct one-to-one communication.

8 Basic Capability to automatically change, even while in the “on-line” state, the status indicator to “absent from desk” if the user does not operate the terminal longer than a given period of time.

9 Basic This function shall be able to exchange files using the same mechanism as the message exchange, without the need to attach the file to a mail.

10 Basic Authentication of a user, when trying to use instant messaging, shall be performed using the user ID and password assigned to each user.

11 Basic Provision of a graphical user interface (GUI) for easy access for the users. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of system configuration that provides enhanced


Security Additional Capability to encrypt communication to ensure security. Performance Basic System design shall assume that it provides services to

{approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.

Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.

Backup Basic Capability to save backup copies of data (contact lists, etc.) along with the configuration information.

217

5.12.6. Functional/Non-Functional Requirements and Standard Technology of Full-Text Search Functional requirements 1 Basic Capability to search for contents within the Cabinet Office and Ministries that

contain the keyword entered by the user. The user shall be able to specify a combined search criteria – single or multiple keywords, and logical conditions connecting them (AND, OR, etc.).

2 Basic Capability to restrict the scope of a user’s search: a user shall be allowed to search only the contents within the Cabinet Office and Ministries on which he/she has the access authority.

3 Basic The targets of search shall include: documents created by office applications installed on the server (word processors, spread sheets, presentation tools, and others), document database for groupware (postings on electronic bulletin board, etc.), and XML/HTL files on Web sites.

4 Basic Capability to limit or select the scope of target information – e.g. only the data stored on the file server.

5 Basic Capability to perform synonym search (search using a word similar to the keyword given). Data shall be provided for synonym search, and the dictionary shall be maintained by the administrator.

6 Basic Capability to display the search result information as a list, and the user can select an information item from the list for display and then save the relevant information.

7 Additional Capability to collect data that may be used as target information for searching, by accessing the file servers, groupware, and Web site within the Cabinet Office and Ministries on a regular basis.

8 Additional Capability to extract texts for analysis from the collected resources such as text/HTML/XML files and documents created by office applications.

9 Additional Capability to compile a search information index based on the results of analysis, which can accelerate searching.



Security Basic Capability to restrict the scope of a user’s search: a user shall be allowed to search only the contents on which he/she has access authority.


Additional Provision of a tolerance against the attacks from the users that threaten security (e.g. SQL injection).

Performance Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.

218

Extendability Additional In view of possible the increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.

Backup Basic Capability to save backup copies of data (index, etc.) along with the configuration information.

219

5.12.7. Functional/Non-Functional Requirements and Standard Technology for Web conference Functional requirements 1 Basic Capability given to multiple of participants on the network to have a Web

conference sharing a common screen on the browser. 2 Additional Capability to have voice conversations and video conferences through the

use of microphones, speakers, and Web cameras available on the terminal. 3 Basic Capability to confirm, on the screen, the list of the users participating in the

Web conference. 4 Basic Capability given to all participants to share the terminal screen designated by

the presenter. 5 Basic The mode of screen sharing shall allow selections depending on the

presenter’s convenience – full-screen sharing and partial screen sharing (i.e. only the screen of a specific application is shared).

6 Basic Provision of a virtual whiteboard to which any of the participants can freely write characters and figures: it is shared by the participants to help develop a discussion.

7 Basic Provision of a mechanism to book Web conferences from the browser, and send an electronic notification mail to the user who will chair the conference.

8 Basic Provision of a function to define a password required to log on to the conference. The user shall be able to define it when booking the Web conference, as well as the conference name, date and time, and the number of participants.

9 Basic Capability to book a series of repetitive Web conferences at one time, on an “every day,” “every week,” “every month,” and “every year” basis.

10 Basic Provision of a function to display the lists of Web conferences for easy reference: on-going Web conferences, those that have already closed, and those reserved.

11 Basic Capability, given to the user who will chair a conference, to see the list of his Web conferences and detailed information thereof.



Security Basic Capability to define different password for each Web conference, enabling only the users who received the password notification in advance to participate in the conference.


Performance Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with

220

sufficient capacity.

Additional The system shall assume that {approximately 500 users} will participate in a Web conference simultaneously.

Extendability Additional In view of the possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.

Backup Basic Capability to save backup copies of information related to the Web conference (configuration information and others).

Related technology Distributed file system protocol

WebDAV (Web-based Distributed Authoring and Versioning) – a file management protocol (an extended version of HTTP) for use in a Web-based distributed file system. IETF RFC 2518.

221

5.13. Integrated Account Management, Authentication, Authorization (Access Control)

5.13.1. Definition of Integrated Account Management, Authentication, Authorization (Access Control)

Integrated Account Management, Authentication, and Authorization (Access Control) provides a

mechanism to manage information system users in an integrated and uniform fashion. It confirms the

identity of a user (to authenticate him with his ID), and controls his/her access to resources according

to the level of authority given to him/her.

Figure 5.13-1 Functions and services provided by Integrated Account Management,

Authentication, Authorization (Access Control)

Integrated Account Management, Authentication, and Authorization (Access Control) typically

provides the following five functions/services.

1) Integrated account management

222

2) Directory linkage

3) Web single sign-on

4) Desktop single sign-on

5) OS access control

These functions and services constitute a mechanism to manage account information in an

integrated fashion, and realize a single sign-on environment that contributes to the enhanced

convenience for users. The integrated directory information may further find its applications in the

electronic telephone directory within the organization, a shared address book for the mail system, and

a destination address search for instant messaging.

Functions and services provided by Integrated Account Management, Authentication, Authorization (Access Control) Function & Service Definition Integrated account management

Refers to the provision of functions to manage user authentication information (user ID, password) and attribute information (group, affiliation) in an integrated fashion. The account information, under integrated control, is provided – automatically or manually - to the related systems and directories based on the pre-defined policies (provisioning function). It also provides a workflow function that supports various management tasks (i.e. tasks related to account management).

Directory linkage In an environment where account information is stored in multiple of directories in different formats (RDB, LDAP, CSV file), a Directory Linkage realizes coordination among these directories by providing connector functions (used for connection with various directories and databases) and through attribute conversion (data conversion/mapping).

Web single sign-on Refers to the provision of methods to manage the authentication process of multiple Web applications and access control in an integrated fashion, thus realizes single sign-on. The user has to only log in to the Web once with a single sign-on: this enables the user to utilize all the accessible Web applications without the need to log in to each, one by one. It also provides functions such as: access history log to Web applications, generation of re-authentication request when a time-out occurs.

Desktop single sign-on Refers to the functions that enable the user to log in to various applications – the OS running on the terminal, groupware, Web applications, and C/S type applications – by performing a single log in procedure (i.e. single sign-on). The user only has to log in to the desktop once through a single sign-on: this enables the user to utilize all the accessible applications that run on the terminal without the need to log in to each, one by one.

223

OS access control Refer to the functions to execute access control procedures over the OS resources (files, network, user, etc.) in accordance with the pre-defined access control policies. The access control policies are managed in an integrated fashion, and are applied collectively to each of the systems to be managed. It also collects and stores access history information - when, who, to what resource, and success/failure – as an audit log. The access control policies may be applied, as well as to the ordinary users, to those with privileges (so called administrator users) in accordance with this type of work.

224

5.13.2. Functional/Non-Functional Requirements and Standard Technology of Integrated Account Management Functional requirements 1 Basic Provision of a function to register/modify/delete account information in an

integrated fashion. 2 Basic Capability to automate the life cycle management of account information by

utilizing pre-defined policies to register/modify/delete account information. 3 Basic Provision of a mechanism to automatically provide the changes in one

system (user registration, attribute etc.) to the systems in destination address (provisioning function), whereby the changes are provided based on the defined policies.

4 Basic Capability to restrict the scope of available user IDs based on given restrictions (e.g. naming rules, period of validity, etc.). In terms of passwords, this function shall also place restrictions on the length of the string, types of characters, and period of validity.

5 Basic Provision of a mechanism to apply proposed changes in account information (registration, modification, deletion, etc.) to various OSs and directories after obtaining approvals through the workflow.

6 Basic Capability to place usage control on a user’s ID: suspension (deactivation) and resumption (activation).

7 Basic The user shall be authorized to change or reset his own password (self-care).

8 Basic Essential operations – addition, modification, deletion in account information and policy – shall be recorded in the audit log.

9 Additional Capability to display the content of audit logs in an easy-to-read report format.



Security Basic Provision of a mechanism to allow access to account information only to authorized administrators.

Basic Capability to protect account information by setting appropriate levels of access authority according to the roles of the administrator and his/her scope of management objectives.

Basic Capability to identify a user ID that has been out of use for a long time, and invalidate/delete it.

Additional Capability to encrypt communications.

Performance Basic The system will manage [approximately 50 thousand] accounts, and in the period of personnel revisions, will have to process a large number of user attribute modifications in a short period of time. The system configuration shall have sufficient processing capacity in view of the stated performance requirements.

225

Extendability Additional As the targeted system expands and the user population grows, the number of accounts is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Capability to save backup copies of account information and policies.

Related technology Directory service access protocol

LDAP (Lightweight Directory Access Protocol) – a standard protocol used to connect to directory services. LDAP V3 has been established.

Directory service interchange format

LDIF (LDAP Data Interchange Format) – a file format used to exchange LDAP’s account information.

Provisioning information exchange language

SPML (Service Provisioning Markup Language) – a standard protocol used for ID provisioning. SPML V2 has been established.


Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4


model: S1 - S6

226

5.13.3. Functional/Non-Functional Requirements and Standard Technology of Directory Linkage Functional requirements 1 Basic Provision of a function to coordinate multiple directories for synchronizing the

account information in these directories. 2 Basic Provision of a connector (data communication) function. This function shall

enable the delivering of account information to dissimilar distributed directories (RDB, LDAP, CSV file, etc.).

3 Basic Provision of a matching engine function (data conversion/matching). This function shall be able to perform data type conversion/matching at the time of account information delivery, so that the account information becomes compatible with the destination directory environment.

4 Basic Provision of tools (GUI, SDK, etc.) used to configure data conversion/mapping operations.

5 Basic Capability to incorporate logical operations freely while data is being processed – for example, combining and processing data obtained from different directories.

6 Basic Provision of a mechanism to synchronize the passwords stored in an integrated directory.

7 Basic Provision of a mechanism to check the validity of account information stored in a directory (discrepancies, addition of unauthorized account, etc.).



Security Additional Capability to encrypt communications. Performance Basic The system will manage [approximately 50 thousand] accounts,

and in the period of personnel revisions, will have to process a large number of user attribute modifications in a short period of time. The system configuration shall have sufficient processing capacity in view of the stated performance requirements.

Extendability Additional As the targeted system expands and the user population grows, the number of accounts is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Capability to save backup copies of management data (matching rules, etc.).


LDAP (Lightweight Directory Access Protocol) – a standard protocol used to connect to directory services. LDAP V3 has been established.

Database connection API

JDBC (Java Database Connectivity) – a set of APIs used by Java programs to access RDB. Use of these APIs is assumed in case the directory is RDB.

227




model: S1 - S6

228

5.13.4. Functional/Non-Functional Requirements and Standard Technology of Web Single Sign-on Functional requirements 1 Basic Provision of two control functions targeted at Web applications:

authentication using the specified authentication schemes (user ID, password, etc.), and a URL-based access control function.

2 Basic Capability given to the user that, once the user logs in to the system, he/she can utilize all the accessible Web applications without the need to log in to each, one by one (single sign-on).

3 Basic Centralized management of access control policies, enabling application to multiple authentication proxies and agents simultaneously.

4 Basic Provision of a mechanism to transfer the account information of the logged-in users (user ID, affiliation, etc.) to Web applications.

5 Basic Capability to lock (disable) an account automatically if it failed log-in procedures repeatedly more than the specified number of times.

6 Basic Capability to create and accumulate audit logs from account authentication history.

7 Additional Capability to combine the authentication mechanism with other powerful methods such as token authentication (one-time password), IC card authentication, and biometric authentication.



Security Basic Intensive application of access control on the audit log records to prevent information from tampering.


Performance Basic The system assumes {approximately 50 thousand} accounts. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.

Extendability Additional In view of a possible increase in the number of Web applications and users, the system configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Capability to save backup copies of settings information (of access control policies, etc.) and audit logs.


LDAP (Lightweight Directory Access Protocol) – a standard protocol used to connect to directory services.



229


model: S1 - S6

230

5.13.5. Functional/Non-Functional Requirements and Standard Technology of Desktop Single Sign-on Functional requirements 1 Basic Provision of an agent running on the terminal whose function is to perform,

by executing user authentication steps in place of the user, to automatically log in to various applications – Web applications, groupware, C/S type applications – thus, realizing a single sign-on.

2 Basic The user shall be able to utilize all available applications on the terminal by only performing a log on to the desktop one time, saving the time and effort of logging in to each application. A single sign-on shall be realized through the adoption of applications that run in conjunction with the log-on authentication on desktop OS, or through the action of an agent that automatically enters authentication information, which matches the information (user ID, password) pre-registered to the relevant application.

3 Basic The system administrator shall be able to manage all the single sign-on applications in an integrated fashion, along with the automatically entered user IDs and passwords. Terminal settings shall also be managed in an integrated fashion.

4 Additional In view of the possibility that the user has lost the log in password for the desktop agent for single sign-on, the system shall provide a function to cope with this situation (e.g. password reminder function).

5 Additional Capability to combine the authentication mechanism with other powerful methods such as token authentication (one-time password), IC card authentication, and biometric authentication.



Security Basic The user ID and password (both are automatically entered) shall be maintained after encryption.


Extendability Additional In view of a possible increase in the number of applications and users, the system configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Setting information of the agent shall be backed up.




model: S1 - S6

231

5.13.6. Functional/Non-Functional Requirements and Standard Technology of OS Access Control

This section describes only the aspects of access control - functional and non-functional

requirements - directly linked to the OS. With the advancement of Internet technologies in recent

years, several mechanisms for access control and authority management, that are not limited in their

scope to one OS, have been standardized (e.g. RBAC, XACML) as a part of identity management.

These OS-independent schemes distribute information regarding access control to resources in

accordance with the pre-defined access control policies. The access control policies are managed in

an integrated fashion, and provide functions for auditing (creation/modification/deletion) and life cycle

management. Access control allows both role-based and rule-based definitions, and enables

incorporation of independent logic.

Functional requirements 1 Basic Capability to monitor accesses to OS resources (files, network, users, etc.),

and allow only those accesses permitted by the pre-defined access control policy.

2 Basic Capability to apply access control – access to system operations, files, and programs - even to those account with OS administrator authority.

3 Basic Capability to manage the access control policies in an integrated fashion, and apply them to multiple targeted servers.

4 Basic Capability to detect and block tampering attempts to critical data and programs.

5 Basic Capability to give notice to the monitoring console at the time when a policy violation is detected (e.g. unauthorized access).

6 Additional Audit log that records accesses to OS resources (files, network, users, etc.) shall include such information as: date and time, user name, resource name, details of access and results.

7 Additional Capability to analyze a policy violation event, such as an unauthorized access, if such an instance is detected. The analysis shall be based on the information recorded in the audit log (date and time of unauthorized access, user name, resource name, details of access and its results, etc.).

8 Basic Provision of a mechanism to collect audit logs gathered by the managed servers, and manage and store them in an integrated fashion.



Security Basic Intensive application of access control on the audit log records to prevent information tampering.


232


Extendability Additional In view of a possible increase in the number of systems and users, the system configuration shall assume enough flexibility to allow future upgrades of process performance.

Backup Basic Setting information (e.g. access control policy) and audit log shall be backed up.

Related technology Access control

RBAC (Role Based Access Control) – a role-based approach to implement access control. The administrator achieves proper authority allocation by managing the role assignment of users or groups (UA: User Role Assignment) and permission assignment to the roles (PA: Permission Role Assignment).

Access control description language

XACML (eXtensible Access Control Markup Language) – a set of specifications to define a XML-based access control description language. It enables complex conditional settings to the resources. International standard: ITU-T Recommendation X.1142




model: S1 - S6

233

5.14. Integrated Directory

5.14.1. Definition of Integrated Directory

The integrated directory provides master database functions that cover the collected account

information separately maintained in each ministry. It maintains the master account information data

in coordination with the data stored in the human resource/payroll account information system and

GIMA (Government Identity Management for Authentication) - an inter-ministerial common system.

The account information stored in the integrated directory is distributed to each relevant directory

within the Cabinet Office and Ministries via the integrated account management functions and

directory linkage functions.

Figure 14-1 Relation between the Integrated Directory and GIMA (Government Identity

Management for Authentication)

234

Functions and Services Provided by Integrated Directory Functions and Services

Definition

Integrated directory The integrated directory provides master database functions that control the collection of account information constructed by the Cabinet Office and Ministries. It provides a common platform to unify the management of account information used for running Web applications and groupware, as well as to enable the staff member search of the staff member directory. As it stores the master data for account information to be saved in a variety of directories, it needs to be updated for the latest organization/personnel information, in close coordination with the human resource/payroll account system and GIMA (Government Identity Management for Authentication, when personnel shuffling is implemented. [Reference] Human resources/payroll account systems have two variants: those constructed by the initiative of the Cabinet Office or each Ministry, and those constructed through common agreement among these organizations based on the Business System Optimization Plan. Currently, the former individual systems are in the process of shifting into the latter common system. Therefore, depending on the transition status in each ministry, the system to be linked with the integrated directory should be selected accordingly. The Government Identity Management for Authentication (GIMA) manages account information required to utilize the business applications used within the Cabinet Office and in common with Ministries, as well as those used in each ministry independently, and also provides functions for authentication, authorization, and acquisition of audit logs. ■Functions provided by Government Identity Management for Authentication (GIMA) 1) Management and provision of account information 2) Principal authentication and authorization function 3) Recording and provision of access trail information (log information of 1) and 2) above)

235

The Government Identity Management for Authentication (GIMA) performs an on-line acquisition of personnel information from the human resources/payroll account system to streamline account information related to administrative tasks in business applications. In the Cabinet Office and Ministries where they already have the mechanism for the unified management of account information within the organization, they shall utilize the established mechanisms as a user authentication platform within the cabinet office and ministries that delivers the equivalent functionality of GIMA. Linkage specifications documents for effective data linkage with GIMA are provided: they should be consulted as the need arises.

236

5.14.2. Functional /Non-Functional Requirements of Integrated Directory Functional requirements (use of a password is assumed as authentication information) 1 Basic Realization of a mechanism to manage account information in an

integrated fashion in close linkage with the integrated account management function and directory linkage function.

2 Basic Provision of a repository (data storage) function used to store and manage account information in an integrated fashion. The repository shall have the capacity to store the following information items for the user.

- Identifier : ID (user ID, etc.) for user identification - Credential : Data used for authentication (password,

etc.) - Common Profile : Data about the user (affiliation,

government post, etc.) 3 Additional The repository shall have the capacity to store the following

information items for the user. - Application Profile : Data used by applications

4 Additional Capability to take data linkage with the human resources/payroll management systems in each ministry independently.

5 Basic Provision of a function to import/export account information. 6 Basic Provision of an interface for data linkage with external systems. 7 Basic Capability to record operations performed on account information in

an audit log. 8 Additional Capability to display the content of an audit log in an easy-to-read

report format. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional

Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication.

Security Basic Provision of a mechanism to allow access to account information only to authorized administrators.

Basic Capability to protect account information by setting appropriate levels of access authority according to the roles of the administrator and his/her scope of management objectives.

Basic Intensive application of access control on the acquired audit log records to prevent information from tampering.

Additional

Capability to encrypt communications.

Performance Basic The system will manage “approximately 50 thousand” accounts, and in a period of personnel changes, is required to update a large number of user attribute modifications in a short period of time. The performance requirements shall be

237

defined clearly in advance to achieve a configuration with sufficient processing capacity.

Extendability Additional

As the targeted system expands and the user population grows, the number of user IDs is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades.

Backup Basic Data of account information stored in the repository shall be backed up.

Related technologies Directory service access protocol

LDAP: LDAP (Lightweight Directory Access Protocol) is a standard protocol used for connection with the directory service. LDAP V3 has been established.

Directory service data exchange format

LDIF: LDIF (LDAP Data Interchange Format) defines the file formats used to exchange LDAP account information.

Database access technology

JDBC: JDBC (Java Database Connectivity) represents a set of APIs used by Java programs to access RDB. Use of these APIs is assumed in the case where the directory is RDB.




model: S1 - S6

238

5.15. WAN, Ministerial LAN, DNS/DHCP/Proxy, Remote Access

The IPv4 global address, required for connections to the Internet, has now almost depleted its

inventory available for new assignments (IPv6 will be used for newly assigned global addresses).

Therefore, new installation of servers with IPv4 global address, and construction of a new DMZ

will be ruled out in advance under normal conditions. In addition, as IPv6 does not hold

compatibility with IPv4, the networks and servers using IPv6 defy simple connection with those

using IPv4. To cope with the problem of new address assignment and connection, some

measures will be needed to achieve coexistence and combined use of both the IPv6

environment and the existing IPv4 environment.

To accomplish flawless coexistence and combined use of IPv4 and IPv6, careful

considerations should be exercised in advance on the equipment (server, PC, etc.) at the design

and procurement stages, as well as on the operational practices such as the content of

operation/management/monitoring/maintenance and security measures.

This section mainly provides description from the viewpoint of IPv4 requirements. When

planning to introduce IPv6, due considerations should be exercised at both the design and

implementation stages.

5.15.1. LAN

LAN is an infrastructure network through which a variety of services are provided within

Cabinet Office and Ministries as shown in the figure below.

LAN LAN

WAN

Remote access

XX Ministry XX Ministry

Sw

itchS

witch

Sw

itchS

witch

Router, etc.

Router, etc.

Figure 5.15-1 Positioning of LAN in the network

239

Definitions of the functions and services provided by LAN are as follows.

Functions and Services

Definition

Layer-3 switch Layer-3 switches shall be deployed in the locations where multiple of networks (segments) are linked together. This switch assumes the role of the core switch (center switch) of the LAN within the Cabinet Office and Ministries.

Layer-2 switch Layer-2 switches shall be deployed in the locations where network devices within the same network (a segment) are linked together. This switch assumes the role of the floor switch (edge switch, access switch) of the LAN within the Cabinet Office and Ministries.

Secure wireless LAN

Wireless LAN refers to the LAN system that transmits/receives data through wireless communication. The secure wireless LAN is a variant of this characterized by an enhanced level of security.

5.15.1.1. Layer-3 Switch

Functional requirements 1 Basic Capability to communicate using DIX Ethernet Ver.2 frame. Or, if

the system uses IEEE802.3 frame, capability to communicate using IEEE802.3 frame.

2 Basic Provision of a routing function (Static, RIPv1/v2, OSPFv2/v3, etc.)

3 Basic Provision of multicast routing functions (PIM-SM/DM, IGMP, etc.) are required if services are to be provided utilizing multicast within the Cabinet Office and Ministries.

4 Basic Provision of functions to enable access control for packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list function, filtering function, etc.

5 Basic Provision of a priority control function (QoS, etc.) that enables identification of packets – those transmitted/received by a specific system provided within the Cabinet Office and Ministries - and to prioritize them for relaying.

6 Basic Provision of VLAN functions compatible with IEEE802.1Q. 7 Basic Provision of link aggregation functions compatible with

IEEE802.3ad. 8 Basic Provision of spanning tree protocol functions compatible with

IEEE802.1D, IEEE802.1w, or IEEE802.1s.

240

9 Basic Provision of network authentication functions (IEEE802.1X authentication, Web authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries.

10 Basic Provision of correct cables (category 5, etc.) that fit the ports. 11 Additional Provision of a IEEE802.3af compatible power receiving

capability (POE) is required if the layer-3 switch is to be connected, or planned to be connected, for a power supply from a secure wireless LAN using the IEEE802.3af scheme.

Non-functional requirements Performance

Basic Provision of the required number of the correct types of ports for connections with the servers and network devices within the Cabinet Office and Ministries (e.g. 10/100BASE-TX, 10/100/1000BASE-T, 1000BASE-SX, 1000BASE-LX, 10GBASE-SR, 10GBASE-LR, etc.)

Basic Provision of a sufficient performance capacity (backplane performance, switching performance, etc.) to meet the required service throughput provided for the Cabinet Office and Ministries.

Reliability Basic Provision of functions (e.g. VRRP and others) required to enable, in case of trouble, redundant operation of the network, utilizing a hot standby system. This scheme includes sharing the same default gateway address by two or more layer-3 switches

Basic Provision of backup ports in preparation for physical port failures – the number of them should not be so large that they adversely affect normal system operation.

Basic Provision of a dual power supply, and measures to enhance the reliability of power supply (such as the use of UPS)

Security Basic Provision of an identity authentication function that enables selective endowment of administrative authority

Basic Provision of functions required to enable the administrator to define settings (e.g. ACL), and to monitor (audit) the system through the review of modification records

Operational maintenance

Basic Provision of a console port that can be used to track modifications of setting information and check operational status.

Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remote maintenance from the operation management terminal.

Basic Provision of functions (FTP, TFIP, etc.) that enable saving of a backup copy of configuration definition information.

241

Basic Provision of functions (SNMP, RMON, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries.

Basic Provision of a function (NTP or SNTP) that enables the system to maintain the time settings of the layer-3 switch in a normal state at all times.

Basic Provision of a function (port mirroring, etc.) that enables traffic analysis over the layer-3 switch.

Basic Provision of a function to transfer logs (Syslog and others) to the server.

Basic Mountability in a 19-inch rack.

Related technologies Routing protocol RIP (Routing Information Protocol) is a routing protocol used to

perform path exchanges dynamically with layer-3 switches or routers. RIPv1:RFC1058, RIPv2:RFC2453 OSPF (Open Shortest Path First) is a routing protocol used to perform path exchanges dynamically with layer-3 switches or routers. With improvements in some of the problems inherent in RIP, routing protocol has become applicable to large scale networks. OSPFv2/v3: RFC2328/RFC2740

File transfer protocol

FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350

Multicast protocol

PIM-SM (Protocol Independent Multicast- Sparse Mode) is a routing protocol to create the path information required to relay multicasting packets. RFC2362 PIM- DM (Protocol Independent Multicast- Dense Mode) is a routing protocol to create the path information required to relay multicasting packets. IGMP (Internet Group Management Protocol) is a protocol to control the multicast group configured to receive multicasting packets. IGMPv1: RFC1112, IGMPv2: RFC2236, IGMPv3:RFC3376

Network time protocol

NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through time synchronization with external servers. NTPv3:RFC1305 SNTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through its capability to synchronize with external servers. RFC1361

Network SNMP (Simple Network Management Protocol) is a protocol

242

management protocol

used to monitor/control network devices through networks based on a MIB (Management Information Base). The devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. RMON (Remote network Monitoring) is an MIB (Management Information Base) used to monitor the communication status – traffic situation, errors, etc.- of the network devices installed in remote locations. RFC1757. Generally, four groups of MIB (Ethernet Statistic, Ethernet History, Alarm, Event) are implemented in the devices. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist.

Communication protocol

TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854

Encrypted communication protocol

SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH.

router redundancy protocol

VRRP (Virtual Router Redundancy Protocol) is a protocol that enables redundant configurations in the system consisting of layer-3 switches and routers. RFC2338

Log message transfer protocol

Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network.

Link aggregation protocol

Link Aggregation is a protocol that enables enhancement for path redundancy and secures wide bandwidth through logical aggregation of a plurality of physical ports into one. IEEE802.3ad

Virtual network VLAN (Virtual LAN) is a function that enables division of one switch into a plurality of networks. VLAN includes such schemes as Port LAN, Tag VLAN, and Protocol VLAN. IEEE802.1Q

Loop-free protocol

STP (Spanning Tree Protocol) is a protocol that enables construction of redundant configurations in layer-2. STP includes such variants as RSTP and MSTP. IEEE802.1D, IEEE802.1w, IEEE802.1s

Ethernet communication standard

Standard specifications for Ethernet ports implemented in network devices. 10BASE-T: IEEE802.3, 100BASE-TX: IEEE802.3u, 1000BASE-T: IEEE802.3ab, 1000BASE-SX, 1000BASE-LX: IEEE802.3z, 10GBASE-SR, 10GBASE-LR: IEEE802.3ae

243

Electricity Supply Standard

POE (Power Over Ethernet) is a method to supply power to network devices - wireless LAN access points, IP telephones, etc. – utilizing LAN cables. IEEE802.3af

Authentication standard

IEEE802.1X

5.15.1.2. Layer-2 switch

Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX

Ethernet Ver2 frame. 2 Additional Provision of functions to enable access control for packets that

are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list function, filtering function, etc.

3 Basic Provision of a priority control function (QoS, etc.) that enables identification of packets – those transmitted/received by a specific system within the Cabinet Office and Ministries - and to prioritize them for relaying.

4 Basic Provision of VLAN function compatible with IEEE802.1Q. 5 Basic Provision of a link aggregation function compatible with

IEEE802.3ad. 6 Basic Provision of spanning tree protocol functions compatible with

IEEE802.1D, IEEE802.1w, or IEEE802.1s. 7 Basic Provision of a network authentication function (IEEE802.1X

authentication, Web authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries.

8 Additional Provision of a IEEE802.3af compatible power receiving capability (POE) is required if the switch is to be connected, or planned to be connected, to a secure wireless LAN (this requirement shall apply when power is received from a switch using the IEEE802.3af scheme).

9 Basic Provision of correct cables (category 5, etc.) that fit with the ports.

244


Basic Provision of the required number of correct types of ports for connections with the servers and network devices within the Cabinet Office and Ministries (e.g. 10/100BASE-TX, 10/100/1000BASE-T, 1000BASE-SX, 1000BASE-LX, 10GBASE-SR, 10GBASE-LR, etc.)

Basic Provision of a sufficient performance capacity (backplane performance, switching performance, etc.) to meet the required service throughput provided for the Cabinet Office and Ministries.

Reliability Basic Provision of backup ports in preparation for physical port failures – the number of them should not be so large so that they adversely affect normal system operation.

Security Basic Provision of an identity authentication function that enables selective endowment of administrative authority.

Basic Provision of functions required to enable the administrator to define settings (e.g. ACL), and to monitor (audit) the system through the review of modification records.



Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remotely controlled maintenance from the operation management terminal.

Basic Provision of functions (FTP, TFIP, etc.) that enable saving of a backup copy of configuration definition information.

Basic Provision of functions (SNMP, RMON, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries.

Basic Provision of a function (NTP, SNTP, etc.) that enables the system to maintain the time settings of the layer-2 switch in a normal state at all times.

Basic Provision of a function (port mirroring, etc.) that enables traffic analysis over the layer-2 switch.



245

Related technologies File transfer protocol


Network time protocol

NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in in a normal state through time synchronization with external servers. NTPv3:RFC1305 SNTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through its capability to synchronize with external servers. RFC1361

Network management protocol

SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). The devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. RMON (Remote network Monitoring) is a MIB (Management Information Base) used to monitor the communication status – traffic situation, errors, etc.- of the network devices installed in remote locations. RFC1757. Generally, four groups of MIB (Ethernet Statistic, Ethernet History, Alarm, Event) are implemented in the devices. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist.







Link aggregation protocol

Link Aggregation is a protocol that enables enhancement of path redundancy and the securing of wide bandwidth through logical aggregation of a plurality of physical ports into one. IEEE802.3ad

Virtual network VLAN (Virtual LAN) is a function that enables division of one switch into a plurality of networks. VLAN includes such schemes as Port LAN, Tag VLAN, and Protocol VLAN. IEEE802.1Q

246

Loop free protocol

STP (Spanning Tree Protocol) is a protocol that enables construction of redundant configurations in layer-2 routers. STP includes such variants as RSTP and MSTP. IEEE802.1D, IEEE802.1w, IEEE802.1s



Authentication standard

IEEE802.1X

247

5.15.1.3. Secure Wireless LAN

If the system plans to introduce a secure wireless LAN, due deliberation should be exercised on its

security strength.

Functional requirements 1 Basic Communication capability using TCP/IP, UDP/IP shall be provided. 2 Basic Both the access point (AP) and client shall support IEEE802.11g,

IEEE802.11a (W52,W53,W56) as the transmission scheme. 3 Additional Both the AP and the client shall support IEEE802.11n as the

transmission scheme. 4 Basic Both the AP and client shall support IEEE802.11n as the

transmission scheme. Note, however, that the clients are allowed to use a supplicant. The encryption method shall have encryption strength compatible with those method listed in the e-Government recommendations.

5 Basic Both the AP and client shall support WPA2, IEEE802.1x (EAP-FAST/TLS/TTLS/PEAP, etc.) as the authentication scheme. Note, however, the clients are allowed to use a supplicant. They shall support, when in a connected state, authentication using the MAC address of the terminal.

6 Basic The AP shall support ESS-ID stealth function. 7 Basic In the system where VoWLAN is implemented, the capability to limit

the number of terminals connected to an AP is required. 8 Basic The system shall support both AC source and IEEE802.3af scheme

to receive electric power or a power injector with the matching capacity may be used instead (in which case, matching shall be made with the switch’s power supplying capacity).

9 Additional Provision of a DHCP function, or DHCP relay function.

Non-functional requirements Reliability Basic Capability to do maintenance of the AP settings from remote

terminals via the network. Security Basic Capability to perform wireless access point setting and

identity authentication for audit record administrator. Basic Capability to acquire security-related audit logs – start/end

of access point usage, access logs, and others. Operational maintenance

Basic Capability to manage the AP using SNMP. Basic Link capability with the Syslog server.

248

Related technologies Wireless LAN standard

IEEE802.11a (W52,W53,W56), IEEE802.11b/g,n

Wireless LAN authentication method

WPA (Wi-Fi Protected Access) is a standard used for wireless LAN authentication. IEEE802.11i WPA2 (Wi-Fi Protected Access 2) is a standard used for wireless LAN authentication. This is a new version of the WPA standard, published in 2002, compatible with the upgraded AES encryption. IEEE802.11i

Encryption standard

AES (Advanced Encryption Standard) is a symmetric-key cryptography scheme standardized as the new U.S. encryption method. FIPS PUB 197 PEAP (Protected Extensible Authentication Protocol) is one of extended variants of PPP (Point to Point Protocol) with an added feature for authentication functions, which is characterized by two-way authentication between the server and clients. IEEE802.1x

Security protocol

TLS (Transport Layer Security) is characterized by combined security technologies – public- and private-key cryptography, digital certificates, hush functions, etc. - and is capable of preventing tapping and tampering of data and spoofing. IEEE802.1x TTLS (Tunneled Transport Layer Security) is a variant of TLS (Transport Layer Security, a EPA authentication protocol utilized in PPP authentication schemes), and performs authentication using the user name/password protected by a key encryption method. IEEE802.1x. EAP-FAST is a generally available EAP (Extensible Authentication Protocol) pursuant to IEEE 802.1x, and implements tunneling through authentication process using a symmetrical key algorithm. It is compatible both with IEEE 802.1x and EEE 802.11i.

Avoidance of wireless LAN detection

ESS-ID stealth is a function to conceal a part of the “beacon signal” train (i.e. transmission of ESS-ID, network identification, at a regular interval to external world). IEEE 802.11



DHCP DHCP (Dynamic Host Configuration Protocol) is a protocol used to automatically assign a computer with the information, such as an IP address, required to establish temporary connection to the Internet. RFC2131, RFC2132


SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). The devices generally

249

support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3.



250

5.15.2. WAN

It represents a communication scheme in which a set of computers installed in remote locations –

home ministry and its regional offices, and other ministries – exchange data through telephone lines

and other dedicated lines.

Sw

itchS

witch

Sw

itchS

witch

Router, etc.

Router, etc.

LAN LAN

WAN

Remote access


Figure 5.15-2 Positioning of WAN in the network

Definitions of the functions and services provided by a WAN are as follows.


Definition

Router A router is a piece of equipment that relays the data flowing within a network to other networks.

Line service (Inter-hub network)

Line service (inter-hub service) represents a “Wide Area Network.” It represents a communication scheme in which a set of computers installed in remote locations – home ministry and its regional offices, and other ministries – exchange data through telephone lines and other dedicated lines. Representative examples of WAN include IP-VPN – a carrier network that is shared among user enterprises, and a virtual LAN is constructed on it - and wide-area Ethernet.

Line service (Internet connection)

Line service (Internet connection) represents a set of computer networks mutually interconnected using the Internet Protocol technology. It realizes data communication with the computers on the

Internet via telephone lines, dedicated lines, and Internet service providers (ISP).

251

5.15.2.1. Router and other devices

Functional requirements 1 Basic Capability to communicate using DIX Ethernet Ver.2 frame, or if

the system uses the IEEE802.3 frame, the capability to communicate using IEEE802.3 frame.

2 Basic Provision of a routing function (Static, RIPv1/v2, etc.). Additional Provision of a routing function (OSPFv2/v3, BGP, etc.).

3 Basic In cases where the system has network connections in locations exterior to the Cabinet Office and Ministries, or it uses internet VPN connections: Router: The router shall support IPsec (main mode/aggressive mode).

Additional In other cases than above: The device shall support IPsec (main mode/aggressive mode).

4 Basic The routers In the system that have network connections and internet VPN connections in locations exterior to the Cabinet Office and Ministries: If the list of encryption methods included in the e-Government recommendations have been released, a router with encryption strength matching with those listed shall be applied to the IPsec encryption algorithm for mutual connection among the hubs.

Additional In other cases than above: If the list of encryption methods included in the e-Government recommendations have been released, a router with encryption strength matching with those listed shall be able to apply.

5 Basic Router: The router shall have a shaping function.

Additional SW: The SW shall have a shaping function.

6 Basic Provision of a priority control function (QoS, etc.) that enables identification of the packets – those transmitted/received by a specific system provided within the Cabinet Office and Ministries - and to prioritize them for relaying.

7 Additional In cases where the router is connected to a network with overlapping network addresses, provision of an NAT, NAPT function is required.

8 Basic Provision of functions to enable access control of packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list functions, filtering functions, etc.

9 Basic Provision of correct cables (category 5, etc.) that fit with the ports.

252


Basic Provision of the required number of correct types of ports for connection with the servers and network devices within the Cabinet Office and Ministries.

Basic Provision of sufficient performance capacity to meet the required service throughput provided for the Cabinet Office and Ministries.

Reliability Basic Capability to configure redundancy on the CPU block or redundant network configuration shall be achieved through the use of OSPF/VRRP and other methods, and by installing two or more routers.

Additional Provision of a dual power supply, and measures to enhance the reliability of power supply (such as the use of UPS).

Additional Provision of backup ports in preparation for physical port failures – the number of them should not be so large that they adversely affect normal system operation.




Basic Provision of functions (FTP, TFIP, etc.) that enable saving a backup copy of configuration definition information.

Basic Provision of functions (SNMP, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries.

Basic Provision of a functions (NTP or SNTP) that enables the system to maintain the time settings of the router in a normal state at all times.


Basic Mountability in a 19-inch rack. This requirement may be dropped if the router/device is so small that rack mounting is not necessary.

Related technologies Routing protocol RIP (Routing Information Protocol) is a routing protocol used to

perform path exchanges dynamically with the layer-3 switches or routers. RIPv1: RFC1058, RIPv2: RFC2453

253

OSPF (Open Shortest Path First) is a routing protocol used to perform path exchanges dynamically with the layer-3 switches or routers. With improvements in some of the problems inherent in RIP, routing protocol has become applicable to large scale networks. OSPFv2/v3: RFC2328/RFC2740


FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. FC1350

Time synchronization protocol

NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state through time synchronization with external servers. NTPv3:RFC1305 NTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state through its capability to synchronize with external servers. RFC1361


SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). Devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist.






Syslog is a protocol for transferring log messages of the network devices on the IP network to external servers.

Ethernet communication standard

Standard specifications for Ethernet ports of network devices.. 10BASE-T: IEEE802.3, 100BASE-TX: IEEE802.3u, 1000BASE-T: IEEE802.3ab, 1000BASE-SX, 1000BASE-LX: IEEE802.3z, 10GBASE-SR, 10GBASE-LR: EEE802.3ae

254

Encrypted communication standard

IPsec is the standard for the use of encrypted communication. RFC2401(Security Architecture for the Internet Protocol), RFC2406(IP Encapsulating Security Payload [ESP])

Key exchange standard

IKE is the standard used for key exchange. RFC2407 (The Internet IP Security Domain of Interpretation for ISAKMP), RFC2408 (Internet Security Association and Key Management Protocol (ISAKMP)), RFC2409 (The Internet Key Exchange (IKE))

Network address conversion standard

NAT and NAPT are the standards for address conversion. FC1631 (The IP Network Address Translator (NAT))

5.15.2.2. Line Service (inter-hub network)

Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet

Ver2 frame. 2 Basic Support of the following schemes as the access method (access line) to

the backbone: exclusive line, ATM, Ethernet, xDLS, and FTTH. 3 Basic Provision of [QoS (priority control) or other functions] to reduce the

effect caused by inter-system traffic to a minimum. 4 Basic Secured isolation of the line services from the external world, ensuring

a complete shut out of access from external networks. 5 Basic Capability to provide router monitoring as a part of the services. 6 Basic Capability to provide a remote access function as a part of the services.

255

Non-functional requirements Performance Basic Capability to allocate sufficient throughput (bandwidth)

needed to render services delivered within the Cabinet Office and Ministries.

Reliability Basic Provision of a network capable of constructing optimum (such as redundant) configuration to cope with unexpected system stops (circuit failure, router failure, etc.)

Basic The main line and backup line shall use different regional lines – each of which provided by different telecommunication carriers – to upgrade fault tolerance. The backbone shall also be a multi-carrier-capable (i.e. capability to construct a multi-carrier redundant configuration). Switching between the main line and backup line shall be performed automatically.


Basic Provision of a contact for inquiries in case of troubles that may occur in the backbone line, regional lines (access lines), and terminal devices.

Basic Capability to monitor, do maintenance, and respond to troubles on the line (notification of trouble occurrence, tracking down and separation of the cause of the failure, failure reporting, etc.)

Basic Capability of on-site troubleshooting, in terms of device repair and replacement.

Basic On-request provision of traffic data for each line after the introduction of the system.

256

5.15.2.3. Line Service (Internet connection)

Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet

Ver2 frame. 2 Basic The provider’s backbone switch shall have the capability of IPv6

connection. 3 Basic The access line to the Internet (the communication line from the

Internet connection point to the ISP) shall support an exclusive line, ATM, Ethernet, and FTTH.

4 Basic The ISP backbone shall have the capability to connect directly, or by way of a transit carrier, to a domestic/overseas major IX and overseas major ISP. Sufficient bandwidth – wider than that given to the access line - shall be secured to the ISP backbone.

5 Basic Provision capability of the required number of global IP addresses. 6 Basic Provision capability of a DNS server as a part of the internet connection

services.

Non-functional requirements Performance Basic Capability to allocate sufficient throughput (bandwidth)

needed to render services delivered within the Cabinet Office and Ministries.

Reliability Basic Provision of a network capable of constructing optimum (such as redundant) configuration to cope with unexpected system stops (circuit failure, router failure, etc.).

Basic The main line and backup line shall use different regional lines – each of which provided by different telecommunication carriers – to upgrade fault tolerance. Switching between the main line and backup line shall be performed automatically.

Basic Capability to, when needs arise, to achieve a redundant configuration using path exchange protocol (dynamic routing protocol: BGP).


Basic Provision of a contact for inquiries in case of troubles that may occur in the ISP access line and terminal devices.

Basic Capability to monitor, do maintenance, and respond to troubles on the line (notification of trouble occurrence, tracking down and separation of the cause of the failure, failure reporting, etc.)

Basic Capability of on-site troubleshooting, in terms of device repair and replacement.

Related technologies Path exchange BGP (Boarder Gateway Protocol) is a routing protocol used to

257

protocol perform path exchanges dynamically with the layer-3 switches or routers. RFC4271

258

5.15.3. Remote Access

Remote access represents a mode of connection from the external networks to the internal network

(or computers) via telephone line, dedicated line, or the Internet.

XX Ministry

Sw

itchS

witch

Router/FW

Remote access device

Internet

Figure 5.15-3 Remote access device configuration in a network

Functions, services, and definitions of remote access are as follows.


Definition

Remote access device

Refers to the devices that terminate accesses from the external networks to the internal network (or computers) via telephone line, dedicated line, or the Internet.

5.15.3.1. Remote access device

Functional requirements 1 Basic Capability to communicate using the IEEE802.3 frame and DIX

Ethernet Ver2 frame. 2 Basic Provision of an authentication function to prevent connection from an

unauthorized terminal. 3 Basic Linkage capability with the authentication server. 4 Basic Provision of an encrypted communication function using SSL or IPsec

to secure a sufficient level of security. If the list of encryption methods included in the e-Government recommendations has been released, a device with the encryption strength matching with those listed shall be applied.

5 Basic Definition capability of the maximum number of simultaneously accessible users.

259

6 Basic Web applications shall be operational while the remote access devices are being connected using SSL and other schemes.

7 Basic Capability to configure settings for each user/group, and the provision of easy procedures for security policy settings and maintenance.

Non-functional requirements Performance Basic Provision of a response capability to the requests from

clients located within the range of service delivery (reconnection of disconnected communication, etc.).

Reliability Basic Capability to achieve a redundant configuration of devices. Operational maintenance

Basic Capability of being operated by way of Web-browser and CLI.

Basic Provision of maintenance functions from remote locations using [TELNET, FTP, SSH, etc.]

Basic Provision of functions [SNMP, etc.] required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries.


Related technologies Encrypted communication standard

IPsec is the standard for the use of encrypted communication. RFC2401 (Security Architecture for the Internet Protocol), RFC2406(IP Encapsulating Security Payload [ESP])




FTP (File Transfer Protocol) is a protocol to transfer files. RFC959


SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819


SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). Devices generally support one or more of the three versions: SNMPv1, SNMPv2c, SNMPv3.

260

5.15.4. DNS/DHCP/Proxy

DNS is a function to manage relations between IP addresses and domain names, or host names.

DHCP is a function to distribute the IP addresses and subnet masks to be used to the clients, and

notify the IP addresses of the servers (gateway server, DNS server, etc.) to be used to the clients.

Proxy is a function to communicate with the external networks, in place of the computers located in

the internal network and are incapable to perform direct communication with the external networks.


Sw

itchS

witch

Sw

itchS

witch

Router, etc.

Router, etc.

DNS/DHCP/Proxy serverDNS/DHCP/Proxy server

Figure 5.15-4 DNS/DHCP/Proxy server configuration in a network

The definitions of DNS/DHCP/Proxy are as follows.


Definition

DNS server A DNS server manages relations between IP addresses and domain names, or host names.

DHCP server A DHCP server distributes the IP addresses and subnet masks to be used by the clients, and notifies the IP addresses of the servers (gateway server, DNS server, etc.) to be used to the clients.

Proxy server A Proxy server communicates with the external networks, in place of the computers located on the internal network and are incapable of performing direct communication with external networks.

261

5.15.4.1. DNS Server

Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic Provision of a name (address) resolution function for IP addresses,

domain names, and host names associated with the use of DNS protocol.

3 Basic The name resolution function shall be compatible both with forward and reverse lookup.

4 Basic Provision of linking capability with the upper, or lower DNS server.


clients located within the range of service delivery. Reliability Basic The server shall have a dual configuration (main and sub),

or the hardware shall be capable of a redundant configuration.


Basic Capability to clear the cache. Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor

mounting.

Related technologies Domain name system

DNS (Domain Name System) manages correspondence between the IP address and other items such as a host name on the Internet and a domain name used in e-mail. RFC1034, RFC1035

5.15.4.2. DHCP Server

Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic Capability to provide the IP addresses required for the use of DHCP

protocol. or Capability to provide IP addresses through the use of DHCP protocol.

3 Basic Capability to specify the range of IP addresses to be allocated.


clients located within the range of service delivery. Reliability Basic Capability to achieve a redundant configuration of devices. Operational maintenance

Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor

262

mounting.

Related technologies DHCP DHCP (Dynamic Host Configuration Protocol) is the protocol

used to assign a computer with the information, such as an IP address, required to establish a temporary connection to the Internet..RFC2131, RFC2132

263

5.15.4.3. Proxy Server

Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic The Proxy server shall be able to relay access to the Internet and Web

within the ministry. 3 Basic Provision of an HTTP request relaying function compatible with

HTTP1.1. 4 Basic Provision of a caching function of HTML contents.


Basic Provision of a response capability to the requests from clients located within the range of service delivery.

Basic Capability to change the cache size allocation, or provision of sufficient amount of cache area for business operations.

Reliability Basic Capability to achieve a redundant configuration of devices. Operational maintenance

Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor

mounting.

Related technologies Proxy server A Proxy server is situated in an interface between the Internet

and the internal network of an enterprise or other entities, and provides an internet connection as a “proxy” for the computers within the internal computers that are not capable of direct connection.

Hypertext transfer protocol

HTTP (Hyper Text Transfer Protocol) 1.1. RFC2068

Web page description language

HTML (HyperText Markup Language) is a markup language used to describe a Web page.

264

5.15.5. VoIP VoIP is a platform on which various telephone services within the Cabinet Office and Ministries are

provided utilizing the IP network as shown in the diagram below.

IDCLAN

XX Ministry

WAN Sw

itchS

witch

Sw

itchS

witch

Router, etc.

Router, etc.

LANOperational VoIP server, VoIP gateway

Standby VoIP server, VoIP gateway

IPtelephone

Figure 5.15-5 VoIP server/gateway configuration in a network

Functions, services, and definitions of VoIP are as follows.


Definition

VoIP server, VoIP gateway

A combination of VoIP servers and/or VoIP gateways are arranged to work with a layer-3 switch bundling a plurality of networks (segments) within the Cabinet Office and Ministries. VoIP server and/or VoIP gateway assumes a role to provide various types of telephone services within the Cabinet Office and Ministries.

5.15.5.1.VoIP Server, VoIP Gateway Functional requirements 1 Basic Provision of an extension interconnection function within the Cabinet

Office and Ministries, and an external connection function with the general public networks and IP public networks.

2 Basic Provision of call hold, call redirection, and call pickup functions. 3 Basic Provision of a function to define the call notification number (transmitted

when an external call is made) for each extension number. 4 Basic Provision of a function to connect with mobile terminals (wireless LAN

telephone terminal, PHS, etc.). 5 Basic Provision of optimum path selection (ARS, etc.) to reduce the cost of

external calls.

265

6 Basic Provision of a function to gather external calling charge (deemed charge) information for each extension number and department within the Cabinet Office and Ministries, and output reports thereof.

7 Basic Provision of network authentication functions for IP telephone transceivers (IEEE802.1x authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries.

8 Basic The control protocol used in the IP telephone transceivers shall conform to SIP (IETF RFC3261).


Basic Provision of enough capacity to connect the required number of IP telephone transceivers used within the Cabinet Office and Ministries. The maximum expandable capacity shall be taken into consideration in view of the future proliferation of IP telephone transceivers.

Basic Provision of enough processing capacity (HCS, BHCA, etc.) for handling telephone services rendered within the Cabinet Office and Ministries.

Reliability Basic The VoIP server shall have an allowance for a redundant configuration.

Basic Capability to switch, at the time of VoIP server failure, to the backup VoIP server within the given period of time, so as to avoid affecting business operations.

Basic Switching to the backup VoIP server, triggered by VoIP server failure, shall not interrupt currently running calls.


Basic Provision of a log that can be used to track modifications of setting information and check operational status.


Basic Provision of functions (FTP, TFIP, etc.) that enable saving a backup copy of configuration definition information.

Basic The VoIP server shall have the capability to monitor, in coordination with the operation management server, the processes running on the VoIP server.


Basic Mountability in a 19-inch rack, or compatibility with floor mounting.

Related technologies Protocols for IP telephone and others

SIP (Session Initiation Protocol) is a control protocol for IP telephone and others. IETF RFC3261

Authentication IEEE802.1X

266

standard File transfer protocol




267

5.16. Workflow, BAM

5.16.1. Definition of workflow and BAM

Workflow describes a series of work patterns - each of which have high chances of repetition -

found in a part or the whole of a business process, which enables a smooth handover of business

activities (document, information, tasks, etc.) from one person in charge to the next, following the

established steps of business practices. A workflow is often represented as a business flow chart or

other presentation tools, after careful examination of each work’s content and sequence.

The software specifically designed to define, create, and operate the workflow on an IT system is

called a workflow management system. The system enables such practices as execution controls

(automatic allocation and ordering of work for each person in charge), management and transfer of

information/data associated with the workflow, and monitoring of situation progress.

The use of a workflow management system enables efficient processing and is expected to speed

up business operations. This is achieved through the creation of electronic data from a variety of work

papers (application form, request for approval, payment bill for transportation, request for vacation,

notification of residence removal, etc.) that have traditionally required moving through a series of

approval steps by the persons in charge, dispersed throughout the sections within the ministry. This

processing is done by implementing such practices as parallel circulation of documents and requests

for final decision making from a business trip destination utilizing a hand-held PC.

BAM (Business Activity Monitoring) represents a suite of technologies and processes that monitors

the implementation status and past record of business processes in real time, and issues an alert

when an irregular value or some other sign of degradation is detected. The administrator and persons

in charge can utilize this information, as a trigger for the call to next action, leading to decisions being

made and swift handling of the problem. BAM also monitors the selected business processes directly

related to the organization’s KPI (Key Performance Indicators), and display a visualized summary of

execution state and KPI on the dashboard screen.

The alert information reported from monitoring enables quicker response to the chances of

problems taking place in business processes, leading to upgraded efficiency. This is the objective of

BAM. Monitoring data thus measured and accumulated will also provide useful information for the

review and redesign of business processes.

268

5.17. Common Elements in Domains

5.17.1. Definition The common elements in domains represent an assembly of requirements common to a plurality of

technical domains such as communication protocol, data formats, and character codes. This section

defines only the related technologies, and does not provide functional, and non-functional

requirements. Functional and non-functional requirements are designated in the sections that

describe the related technologies.

Related technologies Communication protocol

IP: IETF RFC 791 TCP: IETF RFC 793 UDP: IETF RFC 968 HTTP 1.1: IETF RFC 2616 HTTP over TLS: IETF RFC 2818 TLS: IETF RFC 4243 FTP: IETF RFC 959 FTPS: IETF RFC 2229 SSH: IETF RFC 4250, 4251, 4252, 4253, 4254, 4255, 4256

Universal Multiple-octet Coded Character Set

Unicode: ISO/IEC 10646

Graphic format JPEG: ISO/IEC 15444-1, -2, -3 PNG: ISO/IEC 15948

269

6. Procurement of services

This Chapter organizes “services” to be procured in information system procurement in accordance

with procurement specifications issued by ministries and explains the method of creating

specifications. Please refer to Chapter 5 for procurement of “goods” which is not covered by this

Chapter.

This Chapter classifies services related to information systems by information system phase.

Figure 6-1 Classification of procurement of services

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


270

Table 6-1 Explanation of services

Service Service operation 6.1 Support for master plan

formulation Planning the systematization initiative and creating a systematization plan

6.2 Support for procurement Supporting service for ministerial procurements: e.g. implementation of requirements definition, deciding on procurement policies/procedures, creation of procurement specifications, request for comments, evaluation of contractors, and project management.


Service operations concerning information system integration: e.g. design, development, migration, operation, operation/maintenance, design of information systems.

6.4 Operation Service operations concerning information systems (“6.5 Helpdesk” may be considered as part of the operations of 6.4; however, it is separately described in this Chapter)

6.5 Helpdesk Service operations concerning helpdesk to respond to inquiries from users on system operation

6.6 Maintenance Service operations of information system maintenance: e.g. correction of information system faults, modification of system/software products after delivery and adaptation to changed environments


Service operations generated incidental to procurement of devices(*excluding maintenance): e.g. installation, configuration of devices necessary for information systems (including ready-made software, such as OS which is inseparable from hardware)


Service operations such as installation and configuration of various equipment in facilities (data center) prepared by the procurers, and operation monitoring of relevant systems (and incidental operations)

6.9 Network procurement Services related to construction of local networks, such as LAN and WAN (Wide Area Network), and service operations incidental to service procurement, such as WAN service and internet service.

6.10 Cloud service Service operations using cloud system services 6.11 Cloud construction Service operations to construct cloud systems 6.12 Security This section describes security cautions in procurement

of services and security approaches during construction of information systems

6.13 Other (to be created) Service operations not included in 6.1 – 6.12, such as procurement of business package software.

271

6.1.Support for master plan formulation

6.1.1. Definition of procurement area “Support for master plan formulation” refers to support provided by contractors to procurers in

formulating master plans concerning system integration/operations.

If reforms are being considered in the business process/system/organization for the formulation of

master plans, such considerations shall be conducted during this process.

Figure 6.1-1 Items corresponding to the areas of procurement of services

6.2 （等）


6.2 - 1 調達支援

（等）

6.4 運用 6.3





6.12 Security


Planning phase



6.2.2 Support for procurement (requirements definition, etc.) 6.1 Support

for master plan formulation

6.4 Operation


6.5 Helpdesk

6.6 Maintenance


272

6.1.2 Services to be listed in specifications 6.1.2.1. Typical service operations The following table shows services to be included in specifications. The corresponding

SLCP-20071 activities are also given. For actual procurement, correspondence to SLCP activities

should be examined so as not to omit necessary information. To write specifications, a draft of

procurement specifications should be prepared by selecting appropriate items while coordinating with

the corresponding Program Management Office (PMO).

Service operations Outline of service operations SLCP-2007

activity

Chapter/section corresponding to

Basic Guidelines for Procurement2 (and

its title) 1. Systematization initiative

Extracting issues on existing systems(* for existing systems) Study on demand for systematization Study on technological trends Formulating systematization initiative, etc.

1.4.2 Systematization initiative

－

2. Systematization plan

Considering system outline Formulation of schedule of design/development/migration/ operation Implementation of rough estimates Formulating systematization plan , etc.

1.4.3 Systemization plan

－

1 Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 2 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf

273

6.1.2.2. Explanations and examples of descriptions in specifications concerning services 1. Systematization initiative

Item Description Outline of services Prior to system integration, systemization initiative shall be

formulated by conducting studies on demand for systematization

and studies on technological trends, etc. If there is an existing

system, issues in the system shall be identified.

Suggested input

(Prepared by the

procurer)

Requirements definition document and design document for

existing systems (*for existing system)

Demands from procurers for systematization

Set of relevant materials in cases where there are materials

concerning the previous optimization plan

Product

(Prepared by the

contractor)

Systematization initiative document

Matters to be described

in specifications

Requirements for systematization initiative shall be described

[1. Basic requirements to be listed] ・ Study of demand for systematization

・ Study of technological trends

・ Formulation of systematization initiative, etc.

[2. Requirements to be added depending on type/characteristics of project] ●For existing systems

・ Identify issues on existing systems

Example/explanation of

a description in

specifications

[1. Basic requirements to be listed] (1)Studies on demand for systematization

A study of demand for systematization shall be conducted by

interviewing persons concerned.

(2) Study of technological trends

Applicability shall be examined and issues involved in

application shall be organized through the study of trends of

the most advanced technologies both in Japan and overseas.

(3)Formulation a systematization initiative

A systematization initiative document shall be formulated to

clarify the entire structure of new system, system integration

policies, estimated costs, outline of suggested effects, etc.

[2. Requirements to be added depending on type/characteristics of project]

274

●For existing systems

(1) Identifying issues on existing systems

Problems in existing system shall be identified through

interviews with users and organizing issues to be resolved.

Notes on characteristics

of projects/information

systems

－

Notes on security In the case of information systems that deal with critical

information, security policies shall be included in the

systematization initiative

275

2. Systematization plan

Item Description Outline of service

operations

Upon giving shape to the future image of the system and making

rough estimates, design/development/operation schedule shall be

formulated based on the systematization initiative document and

estimates. These descriptions shall be compiled into a

systematization plan.

Suggested input

(Prepared by the

procurer)

Requirements definition document and design document of existing

systems (*for existing systems)

Demand from procurer for systematization

Product

(Prepared by the

contractor)

Systematization plan

Optimization plan (*for systems subject to optimization)

Matters to be

described in

specifications

Enter requirements for systematization plans

[1. Basic requirements to be listed] ・ System outline shall be examined.

・ Design/development/operation schedule shall be formulated.

・ Rough estimates shall be made.

・ Systemization plans shall be prepared.

[2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization

・Optimization plan shall be prepared.

Example/explanation

of a description in

specifications

[1. Basic requirements to be listed] (1) Consideration of system overview

System function diagram shall be created upon defining and

organizing basic requirements for functions to be mounted on the

system.

Hardware diagram, software diagram, network diagram shall be

created upon considering rough system configuration.

(2)Formulation of design/development/operation schedule

Overall schedule for system development/operation shall be

formulated upon considering the period required for system

integration.

(3) Implementation of rough estimates

Rough estimates of costs required for system integration shall be

made.

(4) Formulation of systematization plan

276

The following documents shall be created: a systematization plan

that includes a future image of the system,

design/development/operation schedule, and the result of rough

estimates. A systematization plan shall define the framework and

roles of procurers and contractors, constraints and prerequisites and

standard management guidelines to be observed.

[2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization

(1) Formulation of optimization plans

An “optimization plan Shall be created, which defines overview of

target business/system, details of implementation of optimization,

optimization process table, existing and future systems, and list of

index of optimization effect/service index, based on the Guidelines

for Business/System Optimization Plan.

Notes on

characteristics of

projects/information

systems

Optimization plans for systems subject to business/system

optimization shall be created, as defined in the Guidelines for

Business/System Optimization Plan.

Notes on security In cases of information systems that deal with critical information,

systemization plans shall include considerations for security.

277

6.1.3. Deliverable product and timing of delivery The table below lists typical deliverable products and timing of delivery. The official name of each

product and its delivery deadline needs to be entered in accordance with the actual situation.

Service Deliverable product Delivery deadline

1.Systematization initiative Systematization initiative At the completion of the project

2. Systematization plan Systematization plan

Optimization plan

At the completion of the project

6.1.4. Suggested input

The following table shows input and timing to be presented to a procurer (proposer) in advance.

The official name of each product and its delivery deadline need to be entered in accordance with the

actual situation.

Service Input Timing for presenting input

1. Systematization

initiative

Requirements definition

document and design document

of existing system, etc.

At the time of tender publishing

Demand from the procurer for

systematization


2. Systematization plan Concept of systematization At the time of tender publishing


document and design document

of existing system, etc.


Demand from procurer for

systematization


6.1.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related

procurement and the relevant procurement should be clarified in accordance with the scope of

separated orders and the ministerial policies and presented at the time of tender publishing.

When considering procurement, services to be realized in the entire procurement should be

identified. A clear division of roles and services should be specified and a table of the division of roles

should be compiled so that the concerned parties can agree that there are no omissions/errors in

services/roles in the breakout procurement.

278

6.2. Support for procurement

6.2.1. Definition of procurement area Support for procurement refers to support for operations of procurers at the time of

design/development. This document covers two services: namely, “6.2.2 Support for procurement in

requirements definition phase” and “6.2.3 Support for procurement in design/development phase,

such as project management.”

Figure 6.2-1 Classification of services in support for procurement

Service classification Applicable service operations

6.2.2 Support for procurement in

requirements definition phase

The contractor shall provide support for operations, such as

implementation of requirements and procurement of goods and

services (support for determining procurement

policies/procurement method, support for creation of

procurement specifications, and support for request for

comments and evaluation of contractors).

6.2.3 Support for procurement following

design/development, such as project

management

The contractor shall provide support for service operations, such

as project management concerning system development and

procurement of goods and services (support for determining

procurement policies/procurement method, support for creation

of procurement specifications, and support for request for

comments and evaluation of contractors).


Basic design

Detailed design

Development /test /migration

Operation /maintenance

Support for requirements definition Support for

procurement following basic design (creation of specifications, creation of assessment criteria, etc.)

Support for project management (formulation of project plan, progress management, issue management, change management, quality management, risk management, etc.)

Support for procurement (creation of specifications, creation of assessment criteria, etc.)

Support for other operations (product management, operation of conferences, etc.)

Major services

By TRM classification

6.2.2 Support for procurement in the requirements definition phase

6.2.3 Support of procurement following design/development, such as project management

279

6.2.2. Support for procurement in the requirements definition phase 6.2.2.1. Definition of procurement area “Support for procurement in requirements definition phase” refers to support operations in

requirements definition phase, such as support for requirements definition and support for creation of

procurement specifications for system design/development based on the definition (See Figure 6.2-1

and Figure 6.2-2). Please refer to 6.2.3 for procurement support operations concerning projects

following the design/development operations (system integration operations), since it is not included

in this section.

Figure 6.2-2 Scope of the applicable services in the process of information system

6.2 （等）


6.1 全体計画策定支援

6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


280

6.2.2.2. Services to be included in specifications 6.2.2.2.1. Typical services The following table shows services to be included in the specifications. Corresponding SLCP-20073

activities are also given. For actual procurement, the correspondence to SLCP activities should be

checked so as not to omit necessary information.. Items corresponding to the Basic Guidelines on

Procurement (BGP)4 are also listed. To write specifications, a draft of procurement specifications

should be prepared by selecting appropriate items while coordinating with the corresponding

Program Management Office (PMO).

Service operations Outline of service operations Activities of SLCP-2007

Chapter and section of

specifications corresponding to

BGP (and its title)

1. Confirmation/evaluation/ improvement/estimation of effects of the optimization plan

Support for confirmation/ evaluation/improvement/ estimation of effects of the optimization plan

1.4.3 Systematization plan

3.Infromation system requirements 4.Requirements for scale/performance 5. Requirements for reliability, etc. 6.Requreiments for information security 7.Information operation environment 8. Requirements definition for tests 9. Requirements definition for migration 10. Requirements definition for operation 11. Requirements definition for maintenance

2. Support for requirements definition

Support for the following requirements definition ・ Definition of schedule ・ Requirements definition for

business/functions ・ Requirements definition for system

architecture ・ Requirements definition for

information/data ・ Requirements definition for user

interfaces ・ Requirements definition for external

interfaces ・ Requirements definition for networks ・ Requirements definition for software ・ Requirements definition for

hardware ・ Requirements definition for

information security ・ Requirements definition for

design/development ・ Requirements definition for tests ・ Requirements definition for

migration ・ Requirements definition for

operation/maintenance

1.5.2.4 Definition of function requirements 1.5.2.5 Definition of non-function requirements 1.6.2 Definition of system requirements 1.5.2.6 Requirements definition concerning schedule

3.Estimation of system cost Construction of system/estimation of operation cost based on requirements definition implemented in Section 2.

1.5.2.5 Definition of non-function requirements

4.Support for procurement operations

Support for procurement-related operations, such as the creation of a procurement plan, creation of procurement specifications, response to request for comments and evaluations from contractors, etc.

1.1.2 Preparation of presentation request 1.1.3 Preparation and renewal of contract

3 Software Life Cycle Processes-Japan Common Frame-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 4 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

281

6.2.2.2.2. Explanation on services and examples of descriptions in specifications 1. Confirmation/evaluation/improvement/estimation of effects of optimization plans

Item Description Outline of Service

operations

To confirm and evaluate the optimization plan, and make

improvements as necessary.

To provide support for estimation of optimization effects.

Suggested input

(Prepared by the

procurer)

・ Optimization plan

Product

(Prepared by the

contractor)

・ Report on the optimation plan in terms of the confirmation/evaluation/improvement/estimation of effects

Matters to be

described in

specifications

[1. Basic requirements to be listed] ・ Confirmation/evaluation/improvement proposals for optimization

plans

・ Estimation of the effects at the time of implementing the plan

Example/explanation

of a description in

specifications

○The contractor shall make proposals for

confirmation/evaluation/improvement proposals of an optimization

plan.

The contractor shall make confirmation/evaluation and improvement

proposals to check if an optimization plan presented by the Ministry is

in conformity with “the Basic Guidelines for Government Procurement

Related to Information Systems,” “Business/System Optimization

Guidelines” and the “Information Network (Common System)

Optimization Plan of the Ministry of ___.”

○The contractor shall make estimation of effects at the time of

implementing the plan, shall confirm details estimated in the

optimization plan with respect to the effects of the realization of the

plan, such as a reduction of costs and/or a reduction of operation

processing time, and shall make revisions when necessary.

Notes on

characteristics of a

project/information

system

This operation becomes necessary only when an optimization plan is

created in “6.1 Support for formulating master plan”

Notes on security －

282

2. Support for requirements definition


operations

Support for requirements definition concerning system and business

procurement.

Suggested input

(Prepared by the

procurer)

・ Systemization plan

・ Optimization plan (* when there is an optimization plan)

・ Requirements definition document/design document of existing system, etc. (* when there is an optimization plan)

・ Other information to be provided as needed by contractor

Product

(Prepared by the

contractor)

・ Requirements definition document

Matters to be

described in

specifications

[1. Basic requirements to be listed]

Support for requirements definition with respect to the following

items:

・ Definition of schedule

・ Requirements definition for business/functions

・ Requirements definition for system architecture

・ Requirements definition for information/data

・ Requirements definition for user interfaces

・ Requirements definition for external interfaces

・ Requirements definition for networks

・ Requirements definition for software

・ Requirements definition for hardware

・ Requirements definition for information security

・ Requirements definition for design/development

・ Requirements definition for tests

・ Requirements definition for migration

・ Requirements definition for operation/maintenance

Example/explanation

of a description in

specifications

○Implementation of requirements definition

The following requirements shall be defined and requirements

definition documents shall be compiled, based on the “Draft

Optimization Plan” prepared by the Ministry, guidelines separately

presented by the Ministry and consultation with the Ministry.

A) Definition of schedule

B) Requirements definition for business/functions

C) Requirements definition for system architecture

D) Requirements definition for information/data

E) Requirements definition for user interfaces

283

Item Description F) Requirements definition for external interfaces

G) Requirements definition for networks

H) Requirements definition for software

I) Requirements definition for hardware

J) Requirements definition for information security

K) Requirements definition for design/development

L) Requirements definition for tests

M) Requirements definition for migration

N) Requirements definition for operation/maintenance

Notes on

characteristics of


systems

If organizational change happens, its effects shall be discussed in the

requirements definition.

Notes on security Procurers and creators of specifications shall define information

security requirements in conformity with the “Standards for

Information Security Measures for the Central Government Computer

Systems” and the information security policies of ministries. The

definition of the following requirements shall be specifically clarified

since they are required to be stated in specifications by the “Basic

Guidelines for Government Procurement Related to Information

Systems”:

(1) Definition of authority, and

(2) Definition of security measures

284

3. Estimation of system cost


operations

To estimate the cost for system integration/operation from the results

of requirements definition

Suggested input

(Prepared by the

procurer)

・ Requirements definition document (for product stated in Section 2)

Product

(Prepared by the

contractor)

・ Estimated cost of system integration (draft)

・ Estimated cost of operations (draft)

Matters to be

described in

specifications

[1. Basic requirements to be listed]

・ Cost estimation and creation of cost estimation document

Example/explanation

of a description in

specifications

○Cost estimation and creation of estimated cost document

・ The contractor shall estimate the cost of defined functions and services, system integration and operation expenditure based on

the requirement definition document, and shall compile an

estimated cost document.

・ Approval of a relevant officer shall be obtained with respect to calculation items, calculation method and calculation type.

Notes on

characteristics of


systems

－


285

4. Support for procurement operations

Item Description Outline of Service operations

Support for operations related to the procurement of design/development, such creation of a procurement plan, creation of procurement specifications, request for comments, and evaluations of contractors, etc.

Suggested input (Prepared by the procurer)

・ Optimization plan (* if there is an optimization plan) ・ Requirements definition document (for product listed in Section

2) Product (Prepared by the contractor)

・ Procurement plan document (draft) ・ Procurement specifications (draft) ・ Outline for creating bid materials (draft) ・ Evaluation procedures (draft) ・ List of evaluation items (draft) ・ Evaluation criteria document (draft) ・ Table of scores (draft) ・ Table of responses to request for comments ・ Explanations on bid announcement (draft) ・ Budget justification materials needed after bid announcement

(draft) Matters to be described in specifications

[1. Basic requirements to be listed] ・ Support for formulating procurement method/procedures ・ Support for creating materials related to procurement

procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc.

・ Support for request for comments ・ Support for evaluation of bidders [2. Requirements to be added depending on type/characteristics of project] (Project falling under the category of a specific information system) (project with an estimated price of design/development exceeding ¥0.5 billion) ・ Support for creating a procurement plan document (draft) ・ Support for responding to remarks from a government-level

Project Management Office and ministerial-level Project Management Offices.

Example/explanation of a description in specifications

[1. Basic requirements to be listed] ○Support for creating procurement method/procedures ・ The contractor shall examine and propose the best procurement

method in accordance with the scale and characteristics of the project.

○Support for creating materials concerning procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc. ・ The contractor shall support the creation of procurement

specifications (draft) and outlines for creating bid materials (draft), shall support the procurement of design/development contractors, based on the requirements definition document. Procurement specifications (draft) shall be created from a fair and

286

Item Description neutral perspective, without making assumptions on specific technology or devices/tools.

・ The contractor shall support the creation of materials (evaluation procedures/list of evaluation items/certificate of confirmation, etc.) necessary for selection of contractors in accordance with the procurement method.

○Support for response to request for comments ・ The contractor shall provide support for creating responses to the

opinions and inquiries received, when comments are requested, ・ The contractor shall present the revision and finalization of

procurement specifications (draft) when necessary, based on the results of request for comments.

○Support for evaluation on bidders ・ The contractor shall provide support for technical review and

present evaluation reports for the Ministry. The contractor shall examine whether every item of proposals and certificates of confirmation presented by bidders are meeting requirements, and compile items with unclear descriptions or not meeting requirements into a list and present the list to the Ministry.

[2. Requirements to be added depending on type/characteristics of project] ●Projects under the category of specific information systems ○The contractor shall provide support for creating a procurement plan (draft). The contractor shall create a procurement plan document (draft) based on the “Basic Guidelines for Government Procurement Related to Information Systems.” ○The contractor shall provide support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. The contractor shall provide support for creating materials and shall give explanations on created products when remarks or inquiries are made by a government-level Project Management Office and ministerial-level Project Management Offices.

Notes on characteristics of projects/information systems

The “Basic Guidelines for Government Procurement Related to Information Systems” requires creation of a procurement plan in the cases of specific information systems (projects with estimated price of design/development exceeding ¥0.5 billion).


287

6.2.2.3. Deliverable product and timing of delivery The following table shows the deliverable product and delivery timing. The official names and

delivery timing of each product should be listed in accordance with the actual situation.

Service operations Deliverable product Delivery timing

1.

Confirmation/evaluation/

improvement proposal

for optimization plan

and estimation of effects

Report on confirmation

evaluation/improvement proposals for

optimization plans and estimation of effects

After conclusion of contract

(example of a 6-month project:

around 1.5 months after the

conclusion of contract)

2.Support for

requirements definition

Requirements definition document After conclusion of contract

(example of a 6-month project:

around 2.5 months after the

conclusion of contract)

3.Estimation of system

cost

Estimation of cost of system integration

Estimation of operation cost

After implementation of


4.Support for

procurement

operations

Procurement plan document (draft)

Procurement specifications (draft)

Outline for creating bid materials (draft)

Evaluation procedures (draft)

List of evaluation items (draft)

Evaluation criteria document (draft)

Table of scores (draft)

Table of responses to request for

comments

Explanations on bid announcement (draft)

Budget justification materials needed after

bid announcement (draft)

Date designated by

ministries/agencies

288

6.2.2.4. Suggested input The following table shows the input and timing to be presented to procurers (or proposers) in

advance. The official names and delivery timing of each input should be listed in accordance with the

actual situation.

Service operations Input Timing to present input

1. Confirmation/evaluation/

improvement proposal for

optimization plan and estimation of

effects

Optimization plan At the time of formulation for the

optimization plan

2.Support for requirements

definition

Systematization plan

Optimization plan

(reflecting Section 1)

At the time of release of

specifications

Date designated by

ministries/agencies

3.Estimation of system cost Requirements definition document

(product in Section 2)

After implementation of


4.Support for procurement

operations

Optimization plan

Requirements definition document

(product stated in Section 2)

After operations of requirements

definition

(*A set of support operations, such as requirements specifications for next-term infrastructure

information system of the Ministry of ___, 2010)

Figure 6.2-3 Example of table of overall schedule

Fiscal Year 2010

Dec

embe

r

July

Aug

ust

Sept

embe

r

Oct

ober

Nov

embe

r

Mar

ch

Janu

ary

Febr

uary

Confirmation/evaluation/improvement proposal for optimization plan and estimation of effects

Creation of next-term system procurement plan Specifications for request for comment, etc. (Creation of rough

draft) (Creation of final draft

Estimation of system cost based on the draft of specifications for request for comment (requirements definition)

(Creation of draft) (Creation of estimation)

Creation of draft of WBS items related to support for technical review, etc.

(Reference)

Revision of optimization plan (Draft creation) (Intra-ministerial coordination/approval

procedure)

Next-term system requirements specifications (Intra-ministerial

coordination/coordination with MIC)

(Creation of specification)

289

6.2.3. Support for procurement following design/development, such as project management. 6.2.3.1. Definition of procurement area “Support for procurement following design/development, such as project management” in this

section refers to procurement support operations, etc., such as project management after the

design/development phase. (See Figure 6.2-1 and Figure 6.2-4).

Figure 6.2-4 Scope of applicable services in the process of information system


6.2 - 1 調達支援


6.4 運用

6.3 ハードウェア更改 6.3




6.12 Security

Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance



290

6.2.3.2. Services to be stated in specifications 6.2.3.2.1. Typical services The following table shows services to be included in specifications. The corresponding


shall be examined so as not to omit necessary information. Items corresponding to the Basic

Guidelines on Procurement (BGP)64 are also listed. To write specifications, a draft of procurement

specifications shall be prepared by selecting appropriate items while coordinating with the

corresponding Program Management Office (PMO).

Outline of service operations

Activities of SLCP-2007 Outline of service operations

Activities of SLCP-2007


specifications corresponding to BGP (and its

title) 1.Project management Creation of a project plan, progress

management, issue management, change management, quality management, risk management

1.2.4 Planning 1.2.5 Implementation and management

―


Support for procurement related operations, such as creation of a procurement plan document, creation of procurement specifications, response to request for comments, evaluation of contractors, etc.

3.Support for other operations

Product management, Operation of conferences

5 Software Life Cycle Processes-Japan Common Fram-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 6 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

291

6.2.3.2.2. Explanation on services and examples of descriptions in specifications 1. Project management


operations

Formulate project plans and define the method of project

management, etc.

Implement various types of management, such as progress

management, issue management, change management, quality

management, and risk management

Suggested input

(Prepared by the

procurer)

・ Systematization initiative

・ Systematization plan

・ Optimization plan


Product

(Prepared by the

contractor)

・ Project management plan

・ Report on project management

Matters to be

described in

specifications

[1. Basic requirements to be listed] ・ Formulation of project plan

・ Progress management

・ Issue management

・ Change management

・ Quality management

・ Risk management

[2. Requirements to be added depending on type/characteristics of project] ・ Progress management by EVM

Example/explanation

of description of

specifications

[1. Basic requirements to be listed] ○Formulation of project plan

A project plan shall be formulated, which prescribes the promotional

method of project management operations and index for

management, etc.

When doing so, roles of project participants, contact list of concerned

parties, and conferences, etc. shall be clarified in the project plan.

○Progress management

Instructions shall be given to system developers to present WBS and

other necessary materials that are needed for progress

management. Requirements for the relevant documents shall be

presented to contractors.

The progress of work of the development contractor shall be

periodically checked, and if there is a delay in schedule, support for

292

measures for recovery from the delay shall be provided upon

identifying the causes and impacts, etc.

○Issue management

Issues that may influence the progress of the project shall be

appropriately managed, and the division of roles shall be considered

to resolve the issues and support shall be given for managing

resolution deadlines and for consideration of solutions.

○Change management

Importance/target/implementation period of various specifications

shall be examined and managed at the time of change in system

specifications.

○Quality management

Details of product and materials presented by the development

contractor shall be confirmed and inquiries shall be made to indicate

defects, etc., for the purpose of improving the quality of product, etc.

○Risk management

Possible risks shall be identified, which may influence the progress of

a project and measures for risk reduction/aversion or resolution shall

be presented. [2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization

○Progress management by EVM

Quantitative progress management by EVM (Earned Value

Management) shall be performed and reported, based on the WBS

consulted and agreed between the procurer and the operation

contractor for system development.

Notes on

characteristics of


systems

－


293

2. Support for procurement

Item Description Outline of service operations

Support for operations related to the procurement of design/development, such as creation of a procurement plan, creation of procurement specifications, response to request for comments, and evaluation of contractors, etc.


・ Optimization plan (* only when there is one) ・ Requirements definition document

Product (Prepared by the contractor)

・ Procurement plan document (draft) ・ Procurement specifications (draft) ・ Outline for creating bid materials (draft) ・ Evaluation procedures (draft) ・ List of evaluation items (draft) ・ Evaluation criteria document (draft) ・ Table of scores (draft) ・ Table of responses to request for comments ・ Explanations on bid announcement( draft) ・ Budget justification materials needed after bid announcement

(draft) Matters to be described in specifications

[1. Basic requirements to be listed] ・ Support for procurement methods/procedures ・ Creation of materials concerning procurement procedures, such

as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc.

・ Support for response to request for comments ・ Support for evaluation of bidders [2. Requirements to be added depending on type/characteristics of project] (Projects falling under the category of specific information system) ・ Creation of procurement plan (draft) ・ Support for responding to remarks made by a government-level

Project Management Office and ministerial-level Project Management Offices.


[1. Basic requirements to be listed] ○Support for procurement methods/procedures ・ The contractor shall examine and propose the best procurement

procedures based on the size and characteristics of the project ○The contractor shall create materials related to procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures and list of evaluation items, etc. ・ The contractor shall create procurement specifications (draft) and

outline for creating bid materials (draft), based on the requirements definition, for the procurement of design/development contractor. Procurement specifications (draft) shall be created from a fair and neutral perspective, without making assumptions on specific technology or devices/tools.

294

Item Description ・ The contractor shall create materials (evaluation procedures/list

of evaluation items/certificate of confirmation, etc.) necessary for the selection of contractors in accordance with the method of procurement.

○Support for response to request for comments ・ The contractor shall support responses to opinions and inquiries

received, when comments are requested, ・ The contractor shall provide support for the revision and

finalization of procurement specifications (draft) when necessary, based on the results of request for comments.

○Support for evaluation of bidders ・ The contractor shall provide support for technical review and

report evaluation results to the Ministry. The contractor shall also examine whether every item of proposals and certificates of confirmation presented by bidders is meeting requirements, and shall compile items with unclear descriptions or not meeting requirements into a list and present the list to the Ministry.

[2. Requirements to be added depending on type/characteristics of project] ●Projects falling under the category of specific information systems ○The contractor shall create a procurement plan document (draft) based on guidelines and the “Basic Guidelines for Government Procurement Related to Information Systems.” ○The contractor shall provide support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. ・The contractor shall provide support for the creation of materials and shall give explanations on the created products when remarks or inquiries are made by a government-level Project Management Office and ministerial-level Project Management Offices.


The “Basic Guidelines for Government Procurement Related to Information Systems” requires the creation of a procurement plan document in cases of a specific information system (project with estimated price of design/development exceeding ¥0.5 billion).


295

3. Support for other operations


operations

Support for operations of the procurer, such as product management

and conference operations, etc.

Suggested input

(Prepared by the

procurer)

－

Product

(Prepared by the

contractor)

・ Product management plan (draft) (*)

・ Communication management plan (draft) (*)

・ Conference minutes (draft) (*) Not necessary if it is defined in the project management plan

Matters to be

described in

specifications

[1. Basic requirements to be listed] ・ Product management

・ Operation of conferences

Example/explanation

of a description in

specifications

[1. Basic requirements to be listed] ○Product management

・ The contractor shall support acceptance by the procurers by confirming that the deliverable products of the development

contractor is complete and its quality is satisfactory.

・ The contractor shall support version management of delivered products.

○ Operation of conferences

・ The contractor shall support in project defining conferences and shall clarify participants and operating body, etc.

・ With respect to conferences operated by contractors of the business in question, the contractor shall create and present the

minutes (draft) within __ business days after the relevant

conference.

・ With respect to conferences hosted by procurers, the contractor shall provide support for creation of conference materials when

necessary.

Notes on

characteristics of


systems

－


296

6.2.3.3. Deliverable product and timing of delivery The table below lists typical deliverable products and timing of delivery. The official name of each

product and its delivery deadline should be entered in accordance with the actual situation.


1.Project management Project plan Report on project management

Project plan: within one month after conclusion of a contract Report on project management: monthly


Procurement plan (draft) Procurement specifications (draft) Outline for creating bid materials (draft) Evaluation procedures (draft) List of evaluation items (draft) Evaluation criteria document (draft) Table of scores (draft) Table of responses to request for comments Explanations on bid announcement (draft) Budget justification materials needed after bid announcement (draft)

Date designated by ministries/agencies


Minutes Within __ business days after conference

6.2.3.4. Suggested input The following table shows input and timing to be presented to procurers (proposers) in advance.


actual situation.


1.Project management －－ 2.Support for procurement

Optimization plan Requirements definition document

After implementation of requirements definition


－－

6.2.3.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related





should be compiled so that the concerned parties can agree that there are no omissions/ errors in


297

6.3. System Integration (Design/Development)

This Chapter covers services related to construction of information systems, including design,

development, migration and operational design.

Table 6.3-1 Items corresponding to the classification of procurement of services

6.3.1. Definition of procurement areas Services in system integration (design/development) are classified into four groups in accordance

with the situation in which information systems are developed: namely, new development, system

renewal, hardware renewal, and function addition.

The definition of each group is described below.

Service Definition New development Referring to a system development project to develop a new information

system for services in which no information system currently exists.

System renewal Referring to a system development project due to changes in laws and

operations, such as full-fledged application renewal and system

integration.

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


298

Hardware

renewal

Referring to a system development project for application migration due

to hardware renewal.

Function addition Referring to a function addition project at a subsystem level, design of

existing system and a system improvement projects outside the contract

to be executed by the development contractor/maintenance contractor.

Please refer to “6.3.3 Application maintenance” for additions lower than

subsystem level.

6.3.2 Services to be included in specifications 6.3.2.1. Typical service operations The following table shows services to be included in specifications. The corresponding SLCP-20077

activities are also given. For actual procurement, correspondence to SLCP activities should be

examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on

Procurement (BGP)8 are also listed. To write specifications, a draft of procurement specifications

should be prepared by selecting appropriate items while coordinating with the corresponding



Chapter and section of specifications corresponding to

BGP 1.Preparation for development environment

Securing devices (hardware, development tools, etc.), and work site for development

1.6.1 Preparation for process initiation

Chapter II (5.1) Description of work Chapter XII (2) Method of development

2.Creation of the development plan

Creating design/development plans (schedule, framework, division of roles, work details, development environment, development tools, product, etc.)



3.Basic design Function design (business function, etc.,), data design (conceptual model/logical model), screen design, form design, system architecture design, external interface design and information security design, which are based on the requirements definition. * The above is partially applied to function addition.

1.6.2 Definition of system requirements 1.6.3 System architecture design 1.6.4 Definition of software requirements 1.6.5 Software architecture design


4.Detailed design Program design (list of development programs and definition of specifications, etc.), data design (physical model), screen design, form

1.6.6 Detailed software design


7 Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 8 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf

299

Service operations Outline of service operations Activities of SLCP-2007 Chapter and section

of specifications corresponding to

BGP design, system architecture design, external interface design and information security design, which are based on the basic design

5.Unit test,, integration test, system test, connectivity test with other systems

Creating source code based on detailed design Creating test plans and gaining approval from the relevant sections Preparing for test devices/tools Implementing tests and response to detected faults Creating test result report

1.6.7 Creation of software code and test 1.6.8 Software integration 1.6.9 Software qualification test 1.6.10 System integration 1.6.11 System qualification test

Chapter II (5.1) Description of work Chapter VIII Definition of test requirements Chapter XII (2) Development method

6.Acceptence test support

Support for acceptance tests carried out by procurer, such as creation of drafts of acceptance test procedures, implementation of investigation on and countermeasures against faults and implementation of operation tests

1.6.13 Software acceptance support

Chapter II(5.1) Description of work Chapter XII(2) Development method

7.Migration Migrating data necessary for operations and inputting initial data Migration form development to the live environment

1.8.5Migration Chapter II (5.1) Description of work Chapter IX (1) Requirements concerning migration Chapter XII (2) Development method

8.User education Creating education plans and system usage manuals Implementing training for government officials


Chapter II (5.1) Description of work Chapter IX (2) Requirements concerning education

9.Transfer to operation/maintenance contractors

Operation design Transfer to operation /maintenance contractors

1.7.1 Preparation for process initiation 1.8.1 Preparation for process initiation

Chapter II (5) Description of operations/ Deliverable product

10.Project management Implementing project management for design/development operations, including progress management, document management, information security management, issue/problem management, change management and configuration management

3.1.2 Planning 3.1.4 Implementation and management

Chapter II (5.1) Description of work Chapter XII (2) Development method

11.Acceptance Delivering necessary products, and making corrections if deemed necessary

1.2.7 Delivery and completion

Chapter II (5) Description of work/deliverable product

300

6.3.2.2. Explanation on services and examples of descriptions in specifications Many services mentioned in the preceding section are common to all service types, whether it is new

development, system renewal, hardware renewal, or function addition. Therefore, items in this

section are applied to all service types unless otherwise stated, and a specific service type is

indicated when necessary.

1. Preparation for development environment


operations

Securing of necessary development devices and work site

Suggested input

(Prepared by

procurer)

Outline of new system infrastructure (scheduled)

Operating environment

Operating conditions

Requirements definition document

Product

(Prepared by

contractor)

－

Matters to be stated in

specifications

[1. Basic requirements to be listed] ・ Construction of system design and development environment

(work site, devices and expendables)

・ Management of development environment

Example/explanation

of descriptions in

specifications

Examples of descriptions in specifications ・ System design and development devices shall be prepared and

borne by the contractor.

・ Sufficient security measures for development environment (devices/work site, etc.) shall be taken.

Notes on

characteristics of


systems

If development environment cannot be prepared on site, there is

room for considering creating a development repository.

Notes on security Security measures for development environments

・ When a contractor prepares development environment (devices, work site, etc.), it shall take sufficient information security

measures for the environments.

301

2. Creation of development plan


Creation of design/development plan

Suggested input (Prepared by procurer)

・ Requirements definition document ・ List of major operations ・ Relationship between contractor and related contractors ・ Outline of operations of concerned contractors ・ Operation schedule ・ Table of division of roles ・ Document standards of the government

Product (Prepared by contractor)

・ Project plan ・ Design/development plan

Matters to be stated in specifications

[1. Basic requirements to be listed] ・ Contractor shall create a design/development plan in

accordance with the central government’s standards, such as optimization guidelines, and shall finalize the plan upon coordination with ministries.

・ The project plan shall be created, including WBS (Work Breakdown Structure), critical path and milestones.

[2. Requirements to be listed when necessary] ・ The contractor shall define documentation standards and

development rules, and implementation of reviews to confirm that the development is being conducted accordingly.

Example/explanation of descriptions in specifications

Examples of descriptions in specifications ○Project plan Contractor shall create a project plan. The following operations shall be implemented when creating the project plan. ・ Prior to the creation, necessary operations for the full-fledged

operation of this system shall be organized and WBS documents shall be compiled. Details of operations and deliverable product, commencement and completion conditions shall be clarified by each task. Tasks shall be detailed as much as possible before the commencement so that actual progress and actual cost (AC) can be measured.

・ A dependence relationship of tasks and critical paths (group of tasks that cannot be delayed to avoid delay of the completion of project as a whole) shall be clarified and dates of commencement and completion and interim milestones for each task shall be established.

○Design/development plan ・ Prior to systematization, a document defining work the schedule

related to the product, description of operations, personnel in charge, review plan, check-points, conditions for commencement/completion, and work process of the project shall be complied into a “Project Plan,” which shall be approved

302

by the Ministry upon consultation. Actual design/development operations shall be implemented based on the relevant “Project Plan.”

○Schedule ・ Creation of a schedule including an overall schedule and major

milestones. ○Project framework ・ Entry of the necessary information of the project participants,

such as the leaders and personnel in charge of each organization, and contact list, etc.

・ Clarification of assignments of management responsibility in the entire project and details of management.

○Division of roles ・ Clarification of roles of each project participant so that each can

be aware of its own roles in the entire project. Notes on characteristics of projects/information systems

Some ministries require submission of documents separately. It is desirable to conform to procurement policies/guidelines stipulated by each ministry. In the case of considering the possibility of additional projects or correction projects, it is necessary to mention in the specifications that creation of estimates and calculation of the necessary number of processes may become necessary. Two types of documents describing tasks and schedules may be prepared: one for external use and another for internal management use. It is desirable to create the one for internal management use which contains the status of progress in the WBS. It is desirable to define the tasks of any responsible persons other than a contractor, such as compete relevant ministries, in addition to the tasks of the contractor. When defining the tasks of responsible persons other than a contractor, coordination becomes necessary. Thus, consultation with relevant ministries is necessary when making a rough draft.


303

3. Basic design


operations

Function design, data design, screen design, form design, system

architecture design, external interface design, information security

design, which are based on requirements definition.

Suggested input

(Prepared by

procurer)


・ Basic design document for existing systems (excluding new development)

・ Security policies prescribed by each ministry

・ Standards for Information Security Measures for the Central Government Computer Systems

Product

(Prepared by

contractor)

・ Basic design document (Function design document, data design document, screen design document, form design document,

system architecture design document and external interface

design document may be separately published)


specifications

[1. Basic requirements to be listed] ・ Items in the basic design document.

・ Design environment and work site are prepared by a contractor at the responsibility and expense of the contractor.

・ Response when there are changes in design due to a law amendment.

・ Cooperation with other contractors concerning the system to be procured.

・ Design of test environment and maintenance environment.

[2. Requirements to be listed when necessary] ・ When developing a design mainly for a generic package, it is

necessary to describe the process of the project and a fit and

gap analysis to see if there are any gaps between the processes

described in the requirements definition document and those of

the package (excluding function addition).

Example/explanation

of descriptions in

specifications

Examples of descriptions in specifications ○ Items in the basic design document.

・ Function design (design for business function, exception handling design and operational function, etc.).

・ Data design (design of conceptual model and logical model using E-R diagram).

・ Screen sign.

・ Form design.

304

・ System architecture design (technical design basis for software configuration and hardware configuration, etc.)

・ External interface design

・ Information security design

○Common requirements for design

・ Design of a live environment where this system runs, in addition to test environment and maintenance environment.

・ Design of environment (hardware and middleware for design and design tools, etc.) and work site, etc. shall be prepared by a

constructor at the responsibity and expense of the constructor.

・ Management based on the Guidelines for Management of Configuration/Change stipulated in the project plan.

・ Work shall be implemented in cooperation with a process management contractor, project partners of this system and

contractors concerning other system, which are to be procured

separately.

○Design mainly for generic packages

・ Since this system will be developed under the premise of using generic packaged software, it is necessary to carry out a fit/gap

analysis to determine the degree of fitness between the

business requirements in the specifications and the introduced

generic packaged software.

Notes on

characteristics of


systems

Depending on a project, one contractor may carry out both the

requirements definition and design/development. Please refer to

“6.2.1 Requirements definition” for descriptions concerning the

requirements definition.

Notes on security Information security design

・ Information security design in conformity with the Standards for Information Security Measures for the Central Government

Computer Systems and information security policies of each

ministry.

305

4. Detailed design


Program design, data design, screen design, form design, system architecture design, external interface design and information security design, which are based on the basic design.


・ Detailed design of the existing system and program source (excluding new development)


・ Detailed design documents (Program design documents, detailed design documents, detailed screen design documents, detailed form design documents, detailed system architecture design documents and detailed external interface design documents are often published separately.)


[1. Basic requirements to be listed] ・ Output items of detailed design [2. Requirements to be listed when necessary] ・ Cooperation for related contractors


Examples of descriptions in specifications ○ Output items of detailed design ・ Program design (the list of programs to be developed, of

specifications, etc.) ・ Data design (physical model) ・ Screen/form design (design based on development tools to be

used) ・ System architecture design (design based on the

software/hardware to be used) ・ Information security design (design based on the

software/hardware to be used) ○Related contractors ・ Design materials shall be presented to related contractors and

questions and inquiries shall be answered when necessary. Notes on characteristics of projects/information systems

－

Notes on security Information security design ・ Information security design shall be carried out in conformity with

the Standards for Information Security Measures for the Central Government Computer Systems and information security policies of each ministry.

306

5. Unite test, integration test, system test, and connectivity test with other systems


operations

Creation of source code based on detailed design

Creation of test plans and gaining approval from relevant section

Preparation for test devices and tools

Implementation of each test and response to detected faults

Creation of test results report

Suggested input

(Prepared by

procurer)

－

Product

(Prepared by

contractor)

The following data and documents are related to unit tests,

integration tests and system tests:

・ Test data

・ Test plan

・ Test procedures (test specifications)

・ Test result/quality assessment report


specifications

[1. Basic requirements to be listed] ・ Creation of test plans

・ Creation of test procedures

・ Creation of test data

・ Outline of unit tests, integration tests and system tests

・ Handling of fault correction and investigation of causes

・ Creation of test results/quality assessment report

Example/explanation

of descriptions in

specifications

Examples of descriptions in specifications ○Creation of test plans

The contractor shall submit test plans describing test policies, test

procedures and the reason for tests for each test: unit test,

integration test and system test.

Below are the items to be listed in the test plan

(1) Framework of implementation and roles of contractors

(2) Detailed tasks and test schedule

(3) Test environment (lines and equipment structure in test, and test

coverage)

(4) Test tools

(5) Test data

(6) Assessment criteria

○Creation of test procedures

307

Preparing test procedures by organizing a series of test cases (input

and output and test criteria), test scenario and test data and

procedures.

○Creation of test data

(a) A contractor shall basically prepare the test data

(b) Describe types of test data in the test plan by each test

process

○Outline of unit test, integration test, and system test

(1) Unit test

To test if a program can properly work by the unit of the developed

module.

(2) Integration test

The contractor shall verify the integrity of the software through tests

in which the system is integrated in a stepwise manner to see

programs or modules can function in the entire system.

(3) System test

(a) To see if this system is constructed as required.

(b) To confirm that this system is deliverable.

(c) To implement tests upon setting up assessment criteria to

confirm that the software complies with specifications and is

usable in the live environment.

(d) Performance and stress tests are to confirm that the system

works properly by putting it under stress similar to that of the

live environment.

(e) To confirm the following items:

(i) Functionality

・ Both normal and abnormal system functions can operate according to the specifications.

・ Business coordination processing with other systems can function normally.

・ Meeting information security requirements. (ii) Reliability

・ Meeting reliability requirements.

・ Appropriate recovery processing at the time of failure. (iii) Operability

・ The system operates in accordance with the requirements and instruction and is easy to use.

308

(iv) Performance

・ Appropriate online processing, response time of batch processing and through-put.

・ The system works normally under limiting conditions (data volume, processing volume).

○Handling of fault correction, investigation of causes

・ When a correction is made, confirm that the relevant correction will not negatively affect other programs

In addition to investigating the causes, such as mistakes in

programing or design defect, investigation and analysis shall be

performed with respect to the personnel in charge (for instance, if

faults occur often in modules or components designed/developed

by a specific staff member, investigation shall be focused on other

modules and components designed/developed by the relevant

staff member.)

○Test results/quality assessment report

Report the number of test cases in proportion to program size,

total number of detected faults, rate of detected faults in proportion

to program size, number of completed tests/number of planned

tests and actual number of faults/ estimated faults.

Notes on

characteristics of


systems

－

Notes on security Security measures for test environment

・ If the test environment (devices, work site, test data, etc.) is prepared by a contractor, sufficient security measures shall be

taken for the environment.

309

6. Acceptance test support


Support for acceptance tests conducted by a procurer, including creation of acceptance test procedures, implementation of investigation and contingency measures at the time of the occurrence of faults, and implementation of operation tests.


－


・ Acceptance test procedures ・ Report on acceptance tests


[1. Basic requirements to be listed] ・ Creation of acceptance test procedures ・ Securing support staff for acceptance tests ・ Creation of the environment for an acceptance test ・ Preparation of acceptance test data ・ Analysis of faults and presentation of countermeasures ・ Implementation of program modification in line with the

countermeasures prescribed by ministries Example/explanation of descriptions in specifications

Examples of descriptions in specifications ○Creation of acceptance test procedures ・ To create acceptance test procedures including specific

procedures taken by acceptance testers and its results. It should be easy to understand for any person who is not familiar with system operations.

○Securing support staff for acceptance test ・ Acceptance test is led by the Ministry: however, support staff

shall be employed when required. ○Creation of the environment for an acceptance test ・ Prepare an environment for an acceptance test as close to the

actual live environment as possible. ○Preparation of acceptance test data ・ Prepare test data necessary for acceptance test ○Analysis of faults and presentation of countermeasures ・ Analyze faults detected in acceptance tests and gain the

approval of the Ministry on countermeasures ○Implementation of program correction in line with the countermeasures prescribed by ministries ・ Correction based on the approved countermeasures


It is desirable to conduct a preliminary acceptance test at a selected site in the case of a large scale project in which the system is installed at many locations.


310

7. Migration


Creation of various plans and procedures related to migration operations System migration rehearsal the under live environment and migration to the live environment


・ Input target data ・ Diagram of migration operations


・ Migration plan ・ Migration procedures ・ Migration rehearsal specifications/quality assessment report ・ Migration program ・ Migration data ・ Report on migration results


[1. Basic requirements to be listed] New development ・ The contractor shall help the procurer determine the

specifications of migration data and coordinate with concerned parties. The contractor shall develop migration tools and programs when required

・ Data entry from paper-medium materials and data extraction/migration operations from the existing system

The following shall be entered only for migration from the development environment to the live environment in the case of new development, and are compulsory in cases of other service types. ・ Creation of migration plan ・ Creation of migration procedures ・ Creation of migration rehearsal specifications ・ Implementation of migration rehearsal under the live

environment ・ Creation of migration rehearsal results/quality assessment report ・ Implementation of migration to the live environment ・ Creation of migration result report


Examples of descriptions in specifications ○New development ・ The contractor shall confirm in advance contents and formats of

data and implement migration operations upon confirming with responsible officers of the Ministry of ___ with respect to the method of migration (how to handle white space, sections without data and difference in data format, etc.). The contractor shall develop migration tools and/or programs to carry out migration, on as needed basis.

・ Migration operations include creation and registration of master data necessary for use of this system and conversion and installation of past data. Thus, migration framework shall be developed upon clarifying the roles of ministries related to the division of work necessary for migration. Migration operations

311

shall be carried out in accordance with the following procedures: (1) Organize migration target data upon consultation with the

supervising section, (2) Determine data format for migration to this system and

create tools to integrate the data into this system from that format when necessary,

(3) Create migration data by newly inputting data in accordance with the data format or converging the existing data,

(4) Integrate data into this system using a migration tool, etc., (5) Examine if migrated data is correctly integrated, and (6) Correct data and reconfirm that the data are properly

corrected. ○Migration ・ Contractor shall implement various operations for migration,

such as design/development of migration programs to the database of this system, migration operations and validation confirmation of migrated data, when necessary, presuming that existing data is provided.

・ Data shall be migrated into the live environment after installation in accordance with migration plan. At the time of migrating data, a preliminary rehearsal shall be carried out in accordance with migration plan.

Explanation ・ Migration plan

This document shall describe interested parties and roles, detailed schedule for migration, migration environments, migration methods and methods of preparing migration tools, etc.

・ Migration procedures This document shall describe the following in connection with migration to the production environment: detailed operations, verification methods, verification criteria, contingency plans and time schedules, etc.

・ Migration rehearsal specifications This document shall describe the following in connection with the migration rehearsal: detailed operations, verification methods, verification criteria, contingency plans and time schedules, etc.


It is important to clarify tasks to identify which party is responsible for what tasks, as it is often the case that a number of concerned parties cooperate in the migration process; for instance, specifications for migration data extraction are defined by the design/development contractor and data extraction is done by the operation contractor


312

8. User education


operations

Creation of an education plan and operation manual

Holding training for ministry officers

Suggested input

(Prepared by

procurer)

・ Target, venue and period of educational training

・ Operation manual (existing) (excluding new development)

Product

(Prepared by

contractor)

・ Education plan

・ Training text

・ Operation manual


specifications

[1. Basic requirements to be listed] ・ Creation of an operation manual

・ Requirements for holding training for system users (size and period, etc.)

[2. Requirements to be listed when necessary] When a system is large in terms of the number of users and

locations, the following operations are stated to offer an effective

educational environment.

・ Creation of an education plan

・ Provision for an e-Learning function

Example/explanation

of descriptions in

specifications

・ Examples of descriptions in specifications ○Creation of the operation manual

・ Create operation manual containing the method of operation of devices and usage of this system.

○Requirements for holding training for system users (size and period)

・ Implement group training of this system for system users. Create self-learning materials and compile a training guidebook,

including methods of education and training and usage of

teaching materials.

・ Create a training text upon consultation with the Ministry. When creating the text, care must be taken in the method of

explanation and wordings, so that users can acquire the

operation skills of this system in a short period of time. The

contractor shall also give care to make the text understandable

so that users can sufficiently understand by reading it through.

○Creation of the education plan

・ Create the education plan, including education and training

313

environment and the method of education and training, etc.

・ The contractor shall provide an e-Learning function so that learners can easily understand how to use this system in training

conducted by trainees of the central training; and take necessary

measures, such as providing videos of the central training as an

additional training material, when necessary. When distributing

teaching materials, the contractor shall prepare the necessary

number of copies.

Notes on

characteristics of


systems

－

Notes on security User education

・ Education on information security shall be offered to system users.

314

9. Transfer to operation/maintenance contractors


operations

Operation design

Transfer to operation management contractor and maintenance

contractor

Suggested input

(Prepared by

procurer)

(Excluding new development)

・ Operation design (existing system)

・ Operation manual (existing system)

Product

(Prepared by

contractor)

・ Operational design

・ Operation manual

・ Table of maintenance framework (draft)

・ Transfer plan

・ Transfer report


specifications

[1. Basic requirements to be listed] ・ Operation design for operational systems and applications to be

developed

・ Creation of operation manuals

・ Creation of transfer plans and transfer reports

・ Transfer to operation contractor and maintenance contractor prior to the full-fledged operation of a new system

・ Answering to questions and handle requests for amendments regarding operation manuals during the term of the contract

Example/explanation

of descriptions in

specifications

Examples of descriptions in specifications ○Operation design

・ Carry out operation design for operational systems and applications to be developed. Identifying operation works as

“works necessary for safe and stable operations of business and

applications,” the system shall be designed by defining

necessary work requirements in a systematic and

comprehensive manner.

○Operation manual

・ Create an operation manual for the operation of this system

○Transfer plan

Contractor shall create a transfer plan, including transfer

framework/roles in transfer, detailed tasks and schedules, methods of

transfer, assessment methods/criteria for transfer results.

315

The contractor shall handover in accordance with the transfer plan.

After completing transfer, the contractor shall write transfer reports.

○Transfer to maintenance contractor

Operations of software maintenance contractor concerning System ,

which is to be separately procured, will commence from Month,

Fiscal Year N, contractor shall consult with relevant officer and

implement content transfer of this Transfer software at the

responsibility and expense of the contractor by the end of Month,

Year, after selecting a maintenance contractor.

○Transfer to operation contractor

・ In order to contribute to the smooth implementation of operation works of the operation contractor after the start of full-fledged

operations in Fiscal Year N, contractor shall develop, create and

provide necessary documents for the operations of this system,

which is followed by the provision of necessary training for the

operation contractor by establishing a training period.

Notes on

characteristics of


systems

Operation tools and procedure manual shall be provided when

necessary.


316

10. Project management


operations

Implement project management for design/development operations,

such as progress management, document management, information

and security management, issue/problem management, change

management, configuration management, etc.

Suggested input

(Prepared by

procurer)

－

Product

(Prepared by

contractor)

・ Materials for progress management

・ Table of task management


specifications

[1. Basic requirements to be listed] ・ Progress management

・ Document management

・ Issue/problem management

・ Configuration management

・ Change management

・ Information security management

Example/explanation

of descriptions in

specifications

Explanation ○Progress management

・ Based on progress management materials, the status of progress shall be quantitatively analyzed and operation statuses

shall be reported. Conference/information transmission plans by

each operation process shall be created, and periodical reviews

shall be implemented. When a delay occurs, operation

modification plans, such as addition of workers and revision of

the framework, shall be presented.

○Document management

・ When a contractor makes a correction/renewal of the result of the basic design, it must follow the guidelines for standard

management for the “Plan of Design/Development Phase”

(essentials for document management, essentials for change

management), prepared by the Ministry of XXX.

○Issue/problem management

・ To manage operational issues in a unified manner, establish a

317

process of issue awareness, consideration of countermeasures,

solution and reporting.

○Configuration management

・ To maintain consistency in the development of this software and establish traceability of changes in the project environment.

○Change management

・ When changes to matters listed in the procurement specifications and requirements definition document are

necessary, approval from the relevant ministry shall be gained at

an early stage, after confirmation of the location of change,

description, reason, affected area and the magnitude of

influence, etc.

○Information security management

・ Accident and fault in security systems shall be prevented in advance in each operational stage. Any damage shall be

minimized when it occurs.

Notes on

characteristics of


systems

This section describes project management services for the

design/development contractor.

Please refer to “6.2.3 Project management” for project management

services concerning the entire information system procurement.

Carry out EVM progress management in the case of a large-scale

project.

When EVM is conducted by the procurement support service

contractor (process management), the procurement specifications for

the design/development need to include the information to be

reported for progress management.

Notes on security Information security management

・ Accident and fault in security system shall be prevented in advance in each operation stage. Any damage shall be

minimized when it occurs, after promptly reporting to procurer.

318

11. Acceptance


operations

Make necessary product delivery and carry out repair if deemed

necessary

Suggested input

(Prepared by

procurer)

－

Product

(Prepared by

contractor)

・ Report of project completion

・ Each document

・ Set of programs, including source code, implementation module, etc.


specifications

[1. Basic requirements to be listed] ・ Report of project completion

・ Delivery based on the requirements listed as “deliverable product” in the specifications

・ Making corrections if the deliverables are deemed to need correction

Example/explanation

of descriptions in

specifications

Examples of descriptions in specifications ・ Deliver deliverable product based on the requirements described

in the specifications

・ When the Ministry decides that all or part of the deliverables need corrections, the contractor shall take back the deliverables

immediately, conduct the necessary changes, and provide the

deliverables to which the corrections have been made by the

designated date and time.

Notes on

characteristics of


systems

－


319

6.3.3. Timing of delivery of deliverable product The following table shows the deliverable product and delivery timing information. It is necessary to

list the official name and delivery timing of each product in accordance with the actual situation. The

delivery timing shall be set in expectation of an inspection and correction period.

Service operations Deliverable product Delivery timing

1.Preparation for development environment

－

2.Creation of development plan Project plan Design/development plan

Within two weeks after receipt of order (ARO)

3.Basic design Basic design At the completion of basic design

4.Detailed design Detailed design At the completion of detailed design

5.Unit test, integration test, system test, connectivity test with other system

The following data and documents concerning unit test, integration test, and system test: Test data Test plan Test essentials (test specifications) Test result/quality assessment report

Two weeks prior to each test Two weeks prior to each test Two weeks prior to each test At the completion of each test

6.Acceptance test support Draft of acceptance test procedures Report of acceptance test

Two weeks prior to the test At the completion of the test

7.Migration Migration plan Migration procedures Migration rehearsal specifications Migration rehearsal result/quality assessment report Migration program Migration data Migration result report

Prior to migration Prior to migration Prior to migration At the completion of the project At the completion of the project At the completion of the project At the completion of the project

8.User education Education plan Training text Operation manual


9. Transfer to operation and maintenance contractors

Operational design Operation manual Table of maintenance framework (draft) Transfer plan Transfer report


10.Project management Progress management material Table of issue management

On as needed basis On as needed basis

11.Acceptance Project completion report Each document Set of programs, such as source code, implementation module


320

6.3.4.Suggested input The following table shows the input and timing to be presented to procurers (or proposers) in

advance. It is necessary to list the official name and delivery timing of each input in accordance with

the actual situation.


1.Preparation for development environment

Outline of new system infrastructure (tentative) Operation environment Operating conditions Requirements definition document

To be included in procurement specifications and appendices at the time of tender publishing

2.Creation of development plan

Requirements definition document List of major operations Relations between procurer and concerned contractors Outline of operations of concerned contractors Operation schedule Tale of division of roles Document standards in ministries


3.Basic design Requirements definition document Basic design document for existing system (excluding new development) Security guidelines stipulated by each ministry Standards for Information Security Measures for the Central Government Computer Systems


4.Detailed design Detailed design for existing system, program source (excluding new development)

At the time of commencement of detailed design

5.Unit test, integration test, system test, connectivity test with other system

－－

6.Ascceptance test support －－ 7.Migration Input target data

Diagram of migration installation operations


8.User education Target, venue and period of education (existing) Operation manual (excluding new development)


9.Transfer to operation/maintenance contractors

(Excluding new development) Operational design (existing system) Operation manual (existing system)


10.Project management －－ 11.Acceptance －－

321

6.3.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related






services/roles in the breakout procurement

Except for new development, it is necessary to refer to the involvement of concerned contractors,

such as the existing contractors of operation and maintenance.

The table of division of roles shown below is cited from the Application Manual of the Basic

Guidelines for Government Procurement Related to Information Systems and describes the main

operations and the operational roles of each concerned contractor in a typical separated procurement

project.

Example of the table of division of roles

Main operations Procurement section

Supporter of process

management

Common infrastructure

contractor

Individual function

contractor

Hardware delivery

contractor, etc.

Operation contractor

Software maintenance

contractor Project management/promotion

Formulation of project plan (revision)

Creation of project scope ◎ ◆ □

Establishment of project framework ◎ ◆ □

Creation of method of operating conferences ◎ ◆ □

Setting up schedule and major milestone ◎ ◆ □

Setting up common WBS ◎ ◆ □

Creation of standard management essentials ◎ ◆ □

Creation of project standards ◎ ◆ □

Project promotion (implementation of project management)

Document management ◎□ ◆□ ○□ □ □ □ □ Guidelines for information security measures ◎□ ◆□ ○□ □ □ □ □ Progress management

Progress management for common infrastructure system

◎ ◆ ○□ △

Progress management for individual function system

◎ ◆ △ □

Progress management in integrated operations

◎ ◆ ○□ △ △ △ △

Quality management

Quality management for common infrastructure system

◎ ◆ ○□ △

Quality management for individual function system

◎ ◆ △ □

Quality management in integrated operations ◎ ◆ ○□ △ △ △ △ Issue/problem management

Issue/problem management for common infrastructure system

◎□ ◆ ○□ △

Issue/problem management for individual function system

◎□ ◆ △ □

Issue/problem management in integrated

operations ◎ ◆□ ○□ △

△ △ △

Change management ◎□ ◆□ ○□ □ □ □ □ Configuration management ◎ ◆ ○□ □ □ □ □ Creation of procurement plan and implementation of

procurement

Example ◎：Approval or confirmation ◆：Support for verification ○：Request for cooperation and coordination □：Implementation △：Support Blank：Participation on as needed basis

322

Main operations Procurement section

Supporter of process

management

Common infrastructure

contractor

Individual function

contractor

Hardware delivery

contractor, etc.


Software maintenance

contractor Revision of procurement plan ◎□ □ △

Creating of procurement specifications and implementation of procurement

Procurement of production control support service

◎□

Procurement of common infrastructure service ◎□ ◆□

Procurement of individual function service ◎□ ◆□ □△

Procurement of hardware, etc. ◎□ ◆□ △ △

Procurement of operation service ◎□ ◆□ △ △

Procurement of software maintenance service ◎□ ◆□ △ △

Design/development operations

Organizing basic items ◎ ◆ □

Design/development operation for common infrastructure system

◎ ◆ □

△

Design/development operations for individual function system

◎ ◆ △ □

Implementation of integrated operations ◎ ◆ ○□ □ □ □ □ Promotion of works implemented in cooperation of all participants

Integration test ◎ ◆ ○□ □ △ System test ◎ ◆ ○□ □ △ □

Acceptance test ◎□ ◆□ △ △ △ △ △ Creation of various manuals

・Operation manual ◎ ◆ ○□ □ △ △ △ ・User manual ◎ ◆ ○□ □ △ △

Training ◎ ◆ ○□ □ △ △

Construction and operation of test environment ◎ ◆ ○□ □ □ △ △

Construction of live operation environment ◎ ◆ ○□ □ □ △ △

Operations concerning migration ◎ ◆ ○□ □ △ △ △

Creation of Service Level Agreement (SLA) ◎ ◆ ○□ △ △ □ △

Transfer to operation contractor ◎ ◆ ○□ □ △ □

Transfer to software maintenance contractor ◎ ◆ ○□ □ □

・・・・・・

323

6.4. Operation

6.4.1. Definition of procurement area The term “Operation” in this Section refers to service procurement to carry out operation services

for information systems. The Helpdesk may be considered as part of the procurement of operation

services (in some cases, the helpdesk is handled independently), but this Section (6.4 Operation)

does not include specifics regarding helpdesk services.

If concomitant procurement of helpdesk operations is necessary at the time of the procurement of

operation services, it is desirable to create specifications referring to the Section “6.5 Helpdesk,” in

addition to this Section.


6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


324

6.4.2. Services to be listed in specifications 6.4.2.1 Typical service operations

The following table shows services to be included in specifications. The corresponding SLCP-2007

activities are also given. For actual procurement, correspondence to SLCP activities should be

examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on

Procurement (BGP) are also listed. To write specifications, a draft for procurement specifications

should be prepared by selecting the appropriate items while - coordinating with the corresponding




specifications

corresponding to BGP

(and its title)

1.Formulation of

operation plan

Formulation of implementation

plan of operation and creation of

operation plan.

Receiving approval from

competent officers.

1.7.1.1

Creation of operation process

plan

10.Requirements

definition of operation

2.Transfer for

operation

Receiving explanations and

documents from system

developers, operators of existing

systems (in the case of existing

systems), installer, etc.

1.7.1.2

Transfer of assets for operation

9.Requirements definition

of migration

(1) Requirements

concerning migration

3.Construction of

operation

environment

Procurement and installation of

utensils to be prepared by the

contractor required for system

operation

3.3.3 Construction of

environment

10.Requirements


4.Education for

operators

Training for system operators. In

the case of transfer, receiving

training/education from the

existing operator. Implementation

of contingency/security training.

1.7.2.4 Training for system

operation

9. Requirements

definition of migration

(2) Requirements

concerning education

5.System

operation

Implementation of operation

services necessary for system

operation.

・System operation monitoring

・Server device monitoring

・Network monitoring

・Job monitoring

1.7.4.1 System operation

1.7.4.2

Monitoring operation and

collection of operation data,

identifying problems, recording

and finding solutions,

improvement of operation

10.Requirements


325

・Log monitoring

・Resource distribution

・Backup and restore

・Media management,

expendables management

・Incident management

・Problem management

・Change management

・Release management

・Configuration management

・Capacity management

・IT service continuity

management

・Availability management

・Response to inquiries

environment

1.7.4.3 Identifying and

improving problems

1.7.4.4 Improvement of

operation environment

6.Service level

operation

Report, improvement at a service

level

1.7.7 Assessment of system

operation

10. Requirements


7.Holding

operation

conferences

Business report at regular

conferences. Consideration for

issues and resolutions when

necessary (monthly, weekly,

annual, immediate reporting, to

ministries)

1.2.6 Review and assessment 10. Requirements


326

6.4.2.2. Explanation on services and examples of descriptions in specifications 1. Operation plan


To receive approval from the officer of a competent authority after formulating operation implementation plans and creating operation plans.


Overall schedule Operation overview Operation design document Organizational chart (business entities related to the relevant system and the procurer) Role-sharing table (business entities related to the relevant system and the procurer) Outline of system subject to operation Configuration information on system subject to operation Requirements of details for operation tasks and volume of work, etc.


Operation plan document Organizational chart, etc. (Some ministries require separate submission of installation plans and organizational chart, etc. It is then desirable to comply with procurement policies/guidelines issued by each ministry/agency)

Matters to be described in specifications

To formulate an operation implementation plan, which includes the following items, after coordination with design/development entities and the current operator. [1. Basic requirements to be listed] ・Tasks to be implemented ・Role-sharing table, chain of instruction and command system in implementation framework ・Designation of work hours and work place, etc. and constraints ・Requirements for personnel in charge (skill/ experience/qualification) ・Notification of personnel in charge, compliance with rules when changed, etc. [2. Requirements to be added depending on type/characteristics of project] ・Plan of relevant tasks when contingency tasks are generated, such as construction of operation environments, etc.

Example/explanation on a description in specifications

Examples of descriptions in specifications ○Implementation framework, etc. (1) The contractor shall create an operation plan document (including schedule, implementation framework, etc.) within seven days after a successful bid, and submit it to the supervising section and receive approval. (2) Prior to implementation of the operation, the contractor prepares

327

implementation framework assigning at least two operation support personnel who are engaged in relevant tasks and at least two assistants who assist the operation support personnel, and provide relevant officials with an organizational chart, which includes affiliation/title/name/contact number of the operation support personnel and their assistants. (3) Operation support personnel and assistants shall be stationed at ___ Section and carry out the relevant tasks. (4) When operation support personnel and assistants are to be changed due to circumstances of the contractor, the contractor shall consult with personnel in charge by at least two weeks prior to the change. (5) When changing operation support personnel or assistants, the contractor shall create a transfer document and carry out sufficient transfer and training so as to avoid any disruption to business.

Notes on characteristics of project/information system

(1) There are cases where a design/development contractor formulates operation plans. In such cases, it is necessary to finalize the plan after coordinating with the design/development contractor. (2) If coordination with the existing operator and cooperation/ coordination with the existing operation plan, such as continuity and additional procurement, are needed, a statement to that effect shall be included. (3) When the work place is more than one or re-commissioning is necessary, a statement to that effect shall be included and roles to be shared and a responsibility matrix shall be clarified.

Notes on security (1) When personal information is included in organizational charts, etc., such documents shall be treated in conformity to the degree of significance pursuant to regulations.

328

2. Transfer for operation


Personnel in charge of the operation of the contractor shall take part in training/education provided by the existing operator or the contractor in charge of system integration (design/development). The contractor shall offer security training to personnel in charge of the operation after commencement of operation, when necessary. When terminating operations due to a change in entity contractor, transfer of business and necessary training shall be conducted for personnel who will take over the operations.


A transfer plan document from predecessors (system constructor in the case of new system integration; hereinafter the same shall apply) Transfer materials from predecessors


○ When receiving a transfer of operation Report on implementation of operation transfer ○When conducting transfer Transfer plan (draft) and transfer materials (to successor)


Below are the requirements for the contractor when receiving a transfer of business and conducting transfers. [1. Basic requirements to be listed] ・Requirements for transfer from predecessors ・Formulation of transfer plan to successor and creation of transfer materials ・Response to other concerned entities, such as coordination, explanation and training, etc.


Examples of descriptions in specifications ○When receiving transfer of operation (Coordination with concerned contractors and creation of a transfer plan) (1) The contractor of the relevant procurement shall consult with concerned contractors in order to collect the necessary information for the execution of the operation tasks of the operation system and shall create a “transfer plan” in consideration for “operation procedures” issued by the Ministry of ___. (Response to training, etc.) (1) The contractor of the relevant procurement shall receive training for personnel in charge of system operations, read thoroughly the user manual for system operators and develop operation framework before the commencement of operation tests. ○When conducting transfer (1) Operators after Fiscal Year ___ will be separately procured. Thus, if the successor after Fiscal Year ___ (hereinafter referred to as “next winning bidder”) is different from the current winning bidder, the current one shall steadily carry out the transfer to the next winning bidder for smooth operation tasks, under the burden and

329

responsibility of the current winning bidder within contract period of service. The following points shall be observed during transfer. (a) Reporting to the authority concerned in advance on personnel in charge of transfer and details of transfer, etc. and to receive approval before transfer. (b) Creating “Statement of Transfer” which includes an outline of tasks implemented during the contract period, and carry out the transfer to the next winning bidder using the said “Statement of Transfer” after receiving approval from the authority concerned. Details and progress of project tasks, which will not be completed by March 31, ____, shall be appended separately in the “Statement of Transfer.” (c) Based on the transfer plan, approval of the authority concerned shall be gained with respect to the result of the transfer. If approval is not gained, operations shall be carried out by extending the contract period so as not to interfere with operations under the responsibility and burden of the winning bidder.


(1) If there are several stakeholders requiring coordination during the preparation for operations, the contractor needs to clarify contractors which receive coordination and explanations. (2) When the contract period of the current operator is expired at the time of selection of the next winning bidder, a hands-on transfer from the current to the next winning bidder cannot be conducted. Thus, operation transfer shall be substituted by handing over of operation-related documents and materials from the procurer.


330

3. Construction of operation environment


Procurement/installation of utensils necessary for system operation to be prepared by the contractor


List of utensils to be prepared (when utensils to be prepared by the contractor in charge of the operation have been defined)


Task report (environment construction)


When utensils are to be prepared by the operator, a statement to that effect shall be included. If necessary utensils, etc. have been determined, their models shall be listed. [1. Basic requirements to be listed] ・Selection of appropriate utensils/software in accordance with requirements specifications ・Necessary on-site studies ・Results of on-site studies and output, such as diagrams, etc. are to be designed and created ・Implementation of on-site studies and timing of submission of outputs ・Constraints on implementation of on-site studies ・Installation space and electricity capacity for on-site installation ・Availability of internet lines and monitoring lines connection for on-site connection, etc.


Examples of descriptions in specifications ○Selection of appropriate utensils/software in accordance with requirements specifications (1) Utensils deemed to be necessary shall be prepared by the contractor on its burden. Examples for such utensils include desks, chairs, shelves, copiers, fax machines, hardware and software necessary for information management, telephone lines, and internet lines, etc. When installing internet lines, it is prohibited to connect to the intra-ministerial LAN. (a) The contractor shall file applications for delivery and installation of utensils (b) The contractor shall conduct preliminary studies for the delivery/installation of utensils (c) The contractor shall prepare components necessary for delivery/installation (d) The contractor shall remove and dispose the packaging of utensils, tools used for delivery and other unnecessary materials as soon as installation is completed. Considering the impact on the environment, efforts shall be made to minimize waste materials as

331

much as possible. (e) The contractor shall basically carry out delivery/installation within business hours on weekdays. Details shall be separately instructed by the Ministry of ___.


(1) It is necessary to clarify the roles to be shared by preparation/installation contractors of utensils to be procured, etc.


332

4. Education of operational workers


Operation staff shall receive education from the current operator or system constructor (design/development).


Operational procedures manual


Operational procedures manual (revised version) Work report (staff education)


The following are the details of education to be offered to the system operators: [1. Basic requirements to be listed] ・Compulsory training ・Details of education/training to be implemented [2. Requirements to be added depending on type/characteristics of project] ・Periodical training for operation staff after the commencement of operation, such as security training, etc.


Main tasks to be listed in specifications ○Compulsory training (1) Training for personnel in charge of system operation The relevant contractor shall implement training for personnel in charge of system operation on setting methods and operation methods that will be necessary for system operation, before the commencement of operation of each system. The relevant contractor shall participate in such training and acquire the necessary skills (the rest omitted.)


(1) If the contract period of the predecessor has expired when successor is selected, a hands-on transfer from the predecessor to the successor will not be carried out; thus, it is necessary to substitute staff education with the transfer of operation-related documents and materials from the procurer.


333

5. System operation


To carry out necessary operations, using an operation outline, operation procedures manual and operation tools that have been handed down from the design/development entity or from the existing operator.


Operation design document Operation outline Operation procedures manual Documents for application/management concerning tasks (change/release) Security policies issued by ministries/agencies, etc.


Operation report Work report (operational tasks) Operation procedures manual (additions and revisions made), etc.


To carry out operations necessary for system operation. To extract tasks necessary for the contractor from the operation requirements for the relevant information system and to extract the roles of the procurer and to list them in the specifications. To indicate the timing of implementation of each task. When implementing each task, security policies of each ministry/agency are expected to be observed. ・System operation monitoring ・Server device monitoring ・Network monitoring ・Job monitoring ・Lob monitoring ・Distribution of materials ・Backup and restore ・Media management, expendables management ・Incident management ・Problem management ・Change management ・Release management ・Configuration management ・Capacity management ・IT services continuity management ・Availability management ・Response to inquiries (*Details of services of helpdesk are described in 6.5 Helpdesk), etc.


Examples of descriptions in specifications ○ Actual operations

334

The relevant contractor shall carry out the following items in accordance with the regulations stipulated in the operation procedures manual: (A) Monitoring of operation of each system (1) The relevant contractor shall monitor the online status and batch processing. (2) At the time of regular maintenance/scheduled shutdown, each system shall be shut down and started up again. (B) Server device monitoring (1) The relevant contractor shall monitor operations of server devices installed in the iCD and the Ministry concerned, etc. (2) At the time of regular maintenance/scheduled shutdowns, each system shall be shut down and started up again. (C) Network monitoring (1) The relevant contractor shall monitor the operational status of LAN/WAN networks in the Ministry of ___, as well as networks constructed in the iCD and each center (the Ministry concerned and local branches). (D) Job monitoring (1) The relevant contractor shall monitor the job execution of each system. (2) The relevant contractor shall confirm that batch processing has been properly carried out. (3) The relevant contractor shall carry out a batch job that requires manual startup in accordance with the startup instructions. (4) In cases of abnormal processing, the relevant contractor shall re-run, analyze the failure/recover from failure in accordance with the operation procedures manual, or contact the personnel in charge. (E) Log management (1) The relevant contractor shall manage the log of each system. (2)The relevant contractor shall collect log data on unauthorized use, detection of unauthorized intrusions, information leakage, availability/reliability/confidentiality, hardware breakdown, software breakdown, etc. and shall offer cooperation when an officer of the Ministry of ___ performs a log analysis. (F) Distribution of resources (1) Program files, etc. are automatically distributed to servers and clients’ network computers. If it becomes necessary to distribute

335

resources manually due to extraordinary distribution or failure of automatic distribution, etc., the relevant contractor shall do so in accordance with instructions. (G) Backup and restore (1) An automatic backup system is in place. If a restore (reinstating data) becomes necessary for temporal backup operations or recovery, the relevant contractor shall perform the restore in accordance with instructions. (H) Media management and expendables management (1)The relevant contractor shall store media and keep records for information on the media/date of storage, in accordance with the prescribed method of storage. (I) Incident management (1) To uniformly manage incidents detected by the service desk or system monitoring (system failure, device breakdown, generation of error/warning messages, etc.). (2) To implement responses and solutions, if there are any applicable events through searching for incidents in the past. (3)To upgrade the incident to problem management, considering urgency, priority and the scope of impact, if there are no applicable events through searching for incidents in the past. (J) Problem management ・Separation of failure (1) To uniformly manage incidents those have been upgraded from incident management as problems. (2) To separate problems in accordance with the boundary of responsibility among concerned business entities. (3) To convene an extraordinary conference by instructing concerned parties to carry out investigations, on an as needed basis. ・Investigation of/recovery from failure (1) Following the separation of failure, to instruct the concerned contractor in charge of the relevant failure to identify the root cause and to carry out recovery tasks. (2) To supervise the work until recovery and to confirm recovery. (3) To organize a series of responses to failure. (4) To take temporary measures if the problem cannot be fundamentally solved in the short term. To formulate and request the concerned business entity to formulate a permanent solution. (K) Change Management

336

(1) To receive and uniformly manage requests for change presented by a supervising officer from the Ministry of ___ or problem management. (2)To clarify impacts and risks that may be generated by the change and to formulate a change plan in accordance with the request for change. To confirm the change plan with the supervising officer from the Ministry of ___. (3)To judge propriety of the release after a verification test if a program modification is required, following the confirmation of the change plan.

(L) Release management (1) To receive and uniformly manage requests for the release of new hardware, new software and new versions of software those are listed in the activities of change management. (2)To formulate release plans and to implement release. Upon consultation with supervision officer from the Ministry of ___, to implement renewal of a pattern file for antivirus measures and patch application for operating system and middleware, etc. (3)When related business entities are in operation, such as a change in hardware devices, etc., the relevant contractor shall observe the work and confirm the result of the work. (M) Configuration management (1)To record and sort information on the network/hardware/ software/facility which comprises a system, and keep it in the most recent and complete form at all times. (N) Service delivery To respond to plans and improvement on mid- and long-term system operations management: specifically, to carry out the following tasks: (1) Capacity management To monitor, measure, collect data and record performance of resources and report these matters in order to prevent problems such as degradation of performance or lack of resources. (2) To make efforts to maintain appropriate processing capacity, number of servers and network bandwidth, keeping an eye on the trends of usage.

(O) IT service continuity management (1) To implement backups and store backup data in preparation for large scale disasters or data loss. To provide support for discussions on recovery plans and alternative means to be prepared by supervising ministries and related business

337

entities. (P) Availability management (1)To support strengthening quality and security for the stable supply of services.


(1) Please also refer to 6.5 Helpdesk if it is necessary to set up a helpdesk serving as an information resource in response to inquiries from users.


338

6. Service level management


To report to ministries on the service level of operations in accordance with the concluded Service Level Agreement (SLA).


Service level items/definition document Service Level Agreement (SLA)


Service level report


To manage and report concluded service level items and to improve non-attained items. [1. Basic requirements to be listed] ・Status report and assessment on service level items


Examples of descriptions in specifications ○ Service level items (1) Service level management To report on attainments of service level, based on the concluded “Service Level Evaluation Items and Requirement Standards” and “Evaluation Method for Service Level.” To make specific proposals as a “Service Improvement Plan,” when service level is unattained. ○ Examples of descriptions concerning the conclusion of a Service Level Agreement (SLA) When implementing the relevant tasks, a Service Level Agreement (SLA) shall be concluded between the concerned authority and the winning bidder. Service level evaluation items and required standards will be decided upon during consultation between the concerned authority and the winning bidder after the concluding of an SLA, based on the following requirements: It is necessary to make specific proposals as a basis for the consultation with respect to the “Service Level Evaluation Items and Required Standards,” “Service Level Evaluation Method” and “Service Improvement Plan for Unattained Items.” 1. Normal operation (1) No occurrence of an event that cannot ensure completeness of business data concerning ___ business (such as data falsification). Events attributable to the winning bidder are counted in the number of occurrences, excluding events attributable to other business contractors or events where business has not been affected by implementing recovery measures. (2)Availability of each system is at least 99.9%. However, this is not applied to the period of system shutdown caused by reasons not attributable to the winning bidder.

339

(3) Annual service availability of the support service office (proportion of cases in which appropriate responses have been taken to the total number of inquiries: for example, recording the frequency of inappropriate responses due to inadequate design of management framework or response manual, etc.) is at least 99.9%. 2. Quality of services (1) When implementing the relevant tasks, to make efforts to gain understanding of ___business and the function of ___system, while seeking coordination with the contractors in charge of system development/maintenance, at the expense of the winning bidder. (2) Winning bidder, at their own expense, shall make efforts to understand the product, while seeking coordination with the business entities which deliver hardware and software products to be installed. (3) The winning bidder shall make efforts to understand the entire network configuration, including the next system and peripheral systems, and be aware that the relevant system should work in association with peripheral systems. (4) The winning bidder shall take responsive measures, at their expense and responsibility, in cases where the winning bidder has failed to provide the transfer operations and normal operations at the time of implementation of the relevant business, or exerted influence or troubles to the system of ___ business data. (5) The relevant authority will lend documents necessary for the execution of the relevant operations of a winning bidder, on an as needed basis. Documents lent out shall be returned to the authority when requested or after expiration of the execution period. <<omission>> (9)The winning bidder shall address problems while reporting the situation to and seeking advice from the relevant authority whenever necessary for operations. (10) In the event of violating the provisions stated above, submissions of a report shall be requested and an SLA point may be added.


○ Matters to be noted at the time of concluding a Service Level Agreement (SLA) (1) Since operation procurement is in the purchase of services, it is necessary to conclude Service Level Agreement (SLA) as an evaluation index. Non-availability of systems may often be caused by procured hardware/software, and not always attributable to the operation. Shortening of non-available time due to activation of backup operations at the time of system failure may be different depending on architecture. It is therefore necessary to set and evaluate service level values as an index for evaluation of operations with due considerations to these facts. (2)It is also desirable to evaluate the quality of operation report and monitoring. (3) There is an approach of imposing a penalty in accordance with

340

the attainment of service level items. Based on the concept of a contingency fee as part of the “amount of payment (winning bid) = basic rate + contingency fee,” the amount of payment shall be determined in accordance with the attainment of service level items agreed between the procurer and winning bidder. In general, in cases where winning bidder infringes conditions agreed with the procurer, winning bidder’s liability for the damage may be seen as an obligation under socially accepted conventions; however, the most important wish of the procurer is the provision of high quality services from the winning bidder, and the concept of reward should be determined for that purpose. It is not meant to impose unfairly severe conditions on winning bidder. Example of condition (1) The ratio of the basic rate of a contingency fee shall be 9:1. Example of condition (2) The proportion of contingency fee shall be as follows: (2-1) 10% (full amount): Prescribed conditions attained in all service level requirements (2-2) 5%: Unattained prescribed conditions account for less than 5% of total conditions.

(2-3) 2%: Unattained prescribe conditions account for more than 5% and less than 10%. (2-4) 0%: Unattained prescribed conditions account for more than 10% of total conditions.


341

7. Holding an operation conference


To hold operation conferences to report business performance to the competent office of ministries. To discuss issues and solutions when necessary (monthly, weekly, annual, extraordinary briefing session, etc.).


Date of operation for conference (draft)


Daily report Weekly report Monthly report Report on an extraordinary conference Operation report Minutes of an operation conference


The following are the list of necessary reviews and their timing and method, such as periodical conferences, dates of conferences, reports to be submitted and details of the reports, etc. [1. Basic requirements to be listed] ・Name of the conference ・Participants ・Name of the report to be submitted ・Details of the report


Examples of descriptions in specifications ○Holding of operation conference The relevant contractor shall hold the following conferences and create reports for each conference. When necessary, the relevant contractor may apply for the participation of related business entities upon confirming with competent an officer of the Ministry of ___. (1) Daily operation conference ・Participant: Relevant contractor ・Date of conference: Open days of government offices and when working on holidays for inspection, etc. ・Name of the report: Daily report ・Details of the report -Occurrence of incidents and failures on the preceding day and its response (number of occurrences/devices/completion) -Response of the helpdesk on the preceding day (number of inquiries) -Operation status of systems on the preceding day (start and closing time of service, details/time/personnel in charge/confirmer of operations) - Schedule of operations work on the relevant day, etc.

342

(2) Weekly operation conference ・Participants: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: Weekly ・Name of the report: Weekly report ・Description: Details of the report - Weekly occurrence of incidents and failures and its responses (Number of occurrences/devices/completion, progress) - Weekly responses of the helpdesk (total number of inquiries, tendency, distribution) - Outline of system operations for the week - Schedule and plan of operations on the following week, etc. (3) Monthly conference ・Participant: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: Monthly ・Name of the report: Monthly report ・Details of the report: - Monthly occurrence of incidents and failures and its responses (Number of occurrences/devices/completion, progress) - Monthly responses of the helpdesk (total number of inquiries, tendency, distribution) -Outline of system operations of the month (status of problems, changes) - Attainment of service level for the month - Results of performance monitoring for the month - Usage of resources for the month - Security status for the month (number of detected unauthorized accesses, number of detected viruses, number of detected falsifications, number of detected unauthorized e-mails, changes in the number of users, number of account locks, new information on vulnerability) - Schedule and plan of operations on the relevant month, etc. (4) Briefing session on inventory status of configuration management ・Participants: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: semiannually ・Name of the report: Configuration management inventory table ・Details of the report: Result of system configuration results, such as server devices and software, etc. (5) Extraordinary conference ・Participant: Competent officers of the Ministry of ___ and relevant contractors

343

・Date of conference: On an as needed basis (in cases where an emergency event occurs) ・Name of the report: Extraordinary conference report ・Details of the report: Report, confirmation, analysis and

consideration for the event or problem. Notes on characteristics of project/information system

－


344

6.4.3. Deliverable product and timing of submission The table below lists deliverable products and timing of delivery. The official name of each product

and its delivery deadline need to be entered in accordance with the actual situation. Service Deliverable product Delivery deadline 1.Creation of operation plan

Operation plan document Organizational chart

Within the designated date after the conclusion of an agreement. If changed, on an as needed basis

2.Business transfer for operation

○Transferee Operation transfer

implementation report

○Transferor

Transfer plan (Draft), Transfer

materials

(to transferee)

Within one week after the completion of a transfer

Prior to transfer

3.Construction of operation environment

Task report (Environmental construction)

Prior to installation of devices At the time of environmental construction

At the completion of environmental construction

work 4.Education of operation staff

Operation procedures manual (Revised version) Task report (Staff education)

After training

After training 5.system operation Operation report

Task report (Operational tasks)

Operation procedures manual

(Revised)

Daily, weekly, monthly, annually On an as needed basis

Submission after revision 6.Service level management

Service level report Designated date

7.Holding of operation conference

Daily report Weekly report

Monthly report

Report on an extraordinary

conference

Operation report

Conference minutes

Daily Weekly

Monthly

On an as needed basis

Designated date, at the time of final delivery

Within designated days following the conference

345

6.4.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.


actual situation. Service Input Timing for presenting input 1.Creation of operation plan

Overall schedule Operation outline Operation design document Organizational chart (related business entities and contractors of the relevant systems, the procurers) Role-sharing table (related business entities and contractors of the relevant systems, the procurers) Outline of system subject to operation Configuration information of system subject to operation Details of relevant operations /requirements, such as volume of work

At the time of tender publishing/during the tender period During the tender period At the time of tender publishing

2.Transfer for operation Transfer plan from the predecessor (system constructor in the case of new system integration; hereinafter the same shall apply) Transfer materials from the predecessor

After conclusion of an agreement

3.Construction of operation environment

Utensils subject to preparation, etc. At the time of tender publishing

4.Education of operation staff

Operation procedures manual Disclosed to expected bidders during the tender period. Lent to contractors after conclusion of an agreement. After conclusion of an agreement

5.System operation Operation design document Operation outline Operation procedures manual Documents on the application/management of tasks (change/release) Security policies prescribed by ministries

Disclosed to expected bidders during the tender period. Lent to contractors after conclusion of an agreement.

6.Service level management

Service level items/Definition document Service Level Agreement

At the time of tender publishing At the time of conclusion of an agreement

7.Holding of operation conference

Schedule of operation conference (draft)


346

Item number Service level item Details of regulation Unit

1 Period of operation service provision

Period of implementing operation services Period

2

Method of reporting operation service provision status/ Time interval

Method of reporting operation status and operation plan/time interval

Time

3 Batch processing time Time spent on batch processing Time

4 Frequency of monitoring physical resources

Frequency of monitoring physical resources, such as performance

Time/day

5 Failure notification process/duration until notification

Presence or non-presence of communication process at the time of an occurrence of operation failure and duration until notification

Presence/non-presence Time

6 Acquisition of backup Details/methods/frequency the of acquisition of backup

Presence/non-presence

7 Backup time Time necessary for backup Time

8 Storing period of backup data

Storing period of backup media Time

9 Backup recovery time Time spent from system shutdown to data recovery

Time

10 Acquisition of log Details/methods/frequency of acquisition of logs that can be provided to users

Presence/non-presence

11 Storing period of log Storing period of media storing logs Period 12 Failure recovery System recovery/support system for failure Presence/non-presence

13 Developing operation environment/removal time

Time necessary for developing environments for implementation of operation services/time for removing operation environment

Time

14

Staff education time Time spent on various education programs for operation staff At the time of commencement of business, regular training, etc.

Time

15 Report Regular report Item

Table 6.4-2 Examples of service level items

347

6.4.5. Division of roles In this Section, examples of roles divided among the relevant contractor, authorities and contractors

of other operations are described.

In separated/breakout procurement, the division of roles among procured services, related


separated orders and the ministerial policies and presented at the time of a bid announcement.



should be compiled so that concerned parties can agree that there are no omissions/errors in


○: Main personnel in charge, △: Support, advice

Tasks Supervisory

section Operator Succeeding

operator *1

Related business entity

*2 1.Creation of operation plan △ ○ △ 2.Transfer for operation ○ △ 3.Construction of operation environment ○ △

4.Education of operation staff ○ △ 5.System operation ○ △ 6.Service level management △ ○ △ 7.Holding of operation conferences △ ○ △

*1 Succeeding operator: Transferee of operation or business entity conducting operation transfer

*2 Related business entity: Business entity working in corporation with operators, including

maintenance (hardware, software) business entities, iDC business entities, and helpdesk business

entities.

348

6.5. Helpdesk

6.5.1. Definition of procurement area Procurement of helpdesks refers to the procurement of services to construct and operate helpdesk

environments enabling appropriate responses to users’ inquiries in the operation of information

systems (primary response, secondary escalation, data registration, FAQ management, etc.).

In procurement of helpdesk services, helpdesk contractors that manage overall operation services

should be procured separately. There are two cases: one in which the helpdesk is procured

independently and the other in which the operation contractor provides helpdesk services

comprehensively as part of their operation services. This Chapter applies to helpdesk services of the

latter case, and it is necessary to refer to “6.4 Operation” for other operation services.

Independent procurement of a helpdesk is for a large-scale system in most cases. In most of

small-scale system projects, it is procured as part of operations.

In the classification of procurement of services, it is one of the procurement areas in

operation/maintenance phase as shown in the figure below.


6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


349

6.5.2 Services to be listed in specifications 6.5.2.1 Typical service operations

The following table shows services to be included in the specifications. The corresponding


should be examined so as not to omit necessary information. Items corresponding to the Basic

Guidelines on Procurement (BGP)10 are also listed. To write specifications, a draft for procurement

specifications should be prepared by selecting appropriate items while coordinating with the



Chapter and section of specifications

corresponding to BGP (and its title)

1.Creation of operation plan

To create an implementation plan, installation plan and business operation plan for helpdesk operations and submit them as plan documents to the supervisory section of ministries for approval. To implement periodical reviews or revision of plans if necessary for the progress of works.

1.7.1.1 Creation of operation process plans

Chapter X Requirements definition of operation (and outline shall be listed in Chapter II (5) Work description/Deliverable product)


To receive explanations and necessary documents from general managers and helpdesk operators from the previous fiscal year. To create transfer plans and materials to be handed to transferees. To implement transfer.

1.7.1.2 Transfer of assets for operation

3.Development of working environment

To prepare telephone, fax, PBX, CTI, servers and software and wiring that are necessary for helpdesk operations.

－


To conclude SLA and report service levels in preparation for helpdesk operations.

1.7.1.9 Setting operation assessment criteria

5.Helpdesk operation Primary reception, primary response, escalation. To record and analyze details of inquiries. To extract and renew matters posted on FAQ. Remote control of user’s terminal server, etc.

1.7.6.1 Business operation 1.7.6.2 User support

Chapter X Requirements definition of operation (and outline shall be listed in Chapter II (5) Work description/Deliverable product)

6.Survey on user Survey and report on system －

9 Software Life Cycle Processes-Japan Common Fram-2007 (SLCP-JCF 2007), Information-technology Promotion

Agency, Japan (in Japanese) 10 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of

Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

350




satisfaction users’ satisfaction 7.Helpdesk operation conference

To report on operation of helpdesk operations at regular conferences. To create conference minutes. To discuss issues and solutions when necessary (monthly, weekly, annually, extraordinary briefing session, etc.). To create and submit a helpdesk operations manual and other reports.

1.2.6 Review and assessment 1.7.1.5 Establishment of procedures for system operation 2.1 Documentation process

351

6.5.2.1. Explanation on services and examples of descriptions in specifications 1. Creation of operation plan


To create implementation plans, installation plans and business operation plans for helpdesk operations and submit them as plan documents to competent sections of ministries for approval. To implement periodical reviews or revision of plans if necessary for the progress of works.


・Expected installation and rough estimates of the number of users ・Statement of Work ・Overall schedule (draft) ・Organizational chart (draft) ・Operational framework (draft)


・Implementation plan ・Helpdesk environmental construction diagram ・Installation plan ・Operation plan, outline of operation implementation (Some ministries require separate submission of documents, such as installation plans and organizational charts, etc. Procurement policies/guidelines issued by each ministry should be followed.)


To state the following requirements in specifications, which will be necessary for the judgment of validity of plans by ministries Other materials requiring submission in advance as project plan documents shall be listed as requirements. [1.Basic requirements to be listed] ・Formulation of business implementation plans ・Formulation of installation plans ・Formulation of business operation plans ・Operation management [2. Requirements to be added depending on type/characteristics of project] ・In the case of separate procurement for operations, it is necessary to clarify the consistency with the operation plan of the operator.


Examples of descriptions in specifications ○Formulation of business implementation plans The contractor shall, in advance, create a helpdesk business operation plan as a part of formulation the of business implementation plan (hereinafter referred to as the “business implementation plan document”) and gain approval of the supervisory department of the Ministry of ___. The following are the details of the business implementation plan (1) Overall schedule

352

Item Description (2) Product (3) Procedures for revision of plan and procedures for change management ○Formulation of installation plan The contractor shall, following the formulation of a business implementation plan, create a helpdesk business installation plan, which describes work plans during the installation period, (hereinafter referred to as the “implementation plan document”) and obtain approval from the supervisory department of the Ministry of ___. The following are the details of the installation plan. (1) Installation schedule (2) Environment development plan for helpdesk operations (3) Education plan for helpdesk staff (4) Implementation framework (5) Conferences (6)Staffing plan (during installation period) ○Formulation of business operation plan (1) Formulation of business operation plan The contractor shall, prior to the commencement of the relevant service, create a helpdesk business operation plan, which describes helpdesk operations after the start of the service, (hereinafter referred to as the “business operation plan document”) and obtain approval from the supervisory department of the Ministry of ___. The following are the details of creating a business operation plan. (i) Helpdesk business operation plan (ii) Implementation framework (iii) Conferences (iv) Staffing plan (during the period of service provision) (v) Procedures for revision of plans and procedures for change management (2) Formulation of the outline of business operation implementation The contractor shall, prior to the commencement of the relevant service, create an outline of helpdesk business implementation, which describes helpdesk operations after the start of the service, (hereinafter referred to as the “business operation implementation outline”), based on the “Outline of Operation and Maintenance of Information Operation Center Related to ___ operations) (Day__ Month__ Year__) (hereinafter referred to as the “Operation/Maintenance Management Outline”) and obtain approval from the supervisory department of the Ministry of ___. For the formulation of the business operation implementation outline, the contractor shall seek coordination with the general manager and

353

Item Description personnel in charge of operation services. Flow, communication means and details of escalation shall also be reflected on the business operation implementation outline upon consultation with the manager and personnel in charge of operation services. The following are the business operation implementation outlines to be created. If the prepared business operation implementation outline is not sufficient, a decision shall be made upon consultation with supervisory department of the Ministry of ___ after contract is made. (i) Outline of document management (ii) Outline of service index management (iii) Outline of issue/problem management (iv) Outline of communications management ○Operation management The contractor shall carry out operation management of the relevant business, based on the business implementation plan, installation plan and business operation plan, mentioned above.


When a helpdesk is procured together with an operation, it is necessary to add the details of a formulating service operations plan prescribed in 6.4 Operation, in addition to the relevant matters listed here.

Notes on security Compliance with the outline of implementing information security measures

354

2. Business transfer for operations


To receive explanations and documents from the general manager and former helpdesk operator, etc. To create transfer plans and materials for transferee and implement the transfer.


・Transfer plan from predecessors (system constructor, in the case of new system integration; hereinafter the same shall apply). ・Training on transfer materials, business details, operational tasks, and security etc. from predecessors.

Product (Prepared by The contractor)

・Transfer plan to successors ・Transfer materials to successors ・Report on transfer


[1. Basic requirements to be listed] ・Transfer requirements from predecessors ・Creation of transfer plan and transfer materials to the successors [2. Requirements to be added depending on type/characteristics of project] ・To state requirements for data transfer in cases where data, such as data on FAQ, are to be transferred.


Examples of descriptions in specifications ○Transfer from predecessors The contractor shall receive necessary matters for the tasks of relevant operations, such as know-how in helpdesk operations from the integrated operation monitoring (under transition) company. The contractor shall hand over data related to the relevant systems. The contractor shall create transfer plans and report the completion of transfer. (1) Transfer works from predecessors (i) Predecessors shall create a “transfer plan” in accordance with the instructions of the integrated operational monitoring contractor (under transition). Predecessors shall also create a “report on completion of transfer” when the transfer work has been completed. The overall schedule shall be listed in the “preparation and transfer of the integrated operational monitoring.” (ii) The contractor shall receive the transfer from the integrated operational monitoring (under transition) contractor and prepare the environment, while the integrated operational monitoring (under transition) contractor implements the actual integrated operational monitoring work. The contractor must not cause delays in operational work of the integrated operational monitoring (under transition) contractor.

355

Item Description (iii) The contractor shall initiate the transfer. The transfer shall be carried out in consideration to the following matters.

(a) To proactively acquire system configuration and operation details from the design document and documents related to operation, etc.

(b) When making inquiries to the integrated operational monitoring (under transition) contractor, such inquiries shall be made upon gaining the full understanding of the design document and documents related to operations, etc.

(c)Upon consulting with the integrated operational monitoring (under transition) contractor, the method of making questions and inquiries shall be selected so as not to interfere with the operations of the integrated operational monitoring (under transition) contractor.

(iv) Data transfer The contractor shall receive all the following data concerning the relevant system from the integrated operational monitoring (under transition) contractor. The contractor shall make efforts to understand the transferred data. ・Business data ・Operation related data (indent management data, FAQ data of the helpdesk, configuration management data, etc.) ・All the data filed in the library management system (design documents, procedures manuals, definition files, etc.) ・All data in the registry (Backup tape registry, iCD visitor registry, etc.) ・Other data (paper data, data stored in external media, etc.) ○Transfer to successors Training on business details, operational tasks and security, etc. shall be carried out promptly after the conclusion of an agreement with the successor. Transfer work is planned under the assumption of actual operation. (1) The contractor shall carry out the transfer to the successors with respect to the tasks and operation results, before termination of the contract. (2) The contractor shall enable successors to receive system maintenance and expansions without depending on specific product/technology, when implementing the transfer. (3) The contractor shall formulate transfer plans, create transfer materials, and obtain approval from the office of ____. (4) The contractor shall follow the instructions of the office of ___ with respect to transfer period and deadlines, etc. (5) The contractor shall answer questions from the successors when

356

Item Description there is an omission in transfer materials, etc. even after the termination of the contract.


In the case of new development, it is desirable to receive the transfer from the design/development business entity. It is also desirable to receive the transfer from the supervisory section if it is difficult to carry out transfer from predecessors.


357

3. Development of work environments

Item Description Outline of services To prepare telephone, fax, PBX, CTI, servers and software and

wiring, which are necessary for helpdesk operations.


・Constraints on wiring ・Details of system reform and system improvements that are needed for the revision of the helpdesk operations manual


・Helpdesk educational materials ・Helpdesk manual ・Telephone lines for the helpdesk ・Telephone line installation diagram for the helpdesk ・Telephone lines for an Interactive Voice Response (IVR) server ・Telephone line installation diagram for the IVR server


[1. Basic requirements to be listed] ・Construction of the helpdesk environment ・Wiring [2. Requirements to be added depending on type/characteristics of project] ・Organizing helpdesk tasks ・Creation of the helpdesk manual ・Education for helpdesk staff ・Report on the helpdesk installation status ・Revision of the manual due to organizational changes and system improvements.


Examples of descriptions in specifications [1. Basic requirements to be listed] ・Construction of the helpdesk environment (preparing telephone, fax, PBS, CIT, servers and software) (1) Preparation of utensils necessary for operations (i) The contractor shall prepare utensils deemed necessary for operations at its own expense. Utensils include desks, chairs, shelves, media storage cabinets, copiers, fax machines, hardware and software for information management, internet connections, and telephone lines, etc. When installing an internet line, it is prohibited to connect to the intra-ministerial LAN. (ii) When the contractor concludes that the number of helpdesk terminals and operation management terminals is not enough, the contractor shall prepare the similar terminals as those prepared by Bureau of ___, on an as needed basis. (iii) The contractor shall file an application for delivery and installation

358

Item Description of utensils. (iv) The contractor shall conduct a preliminary study for delivery and installation of utensils. (v) The contractor shall prepare the necessary components for delivery and installation. (vi) The contractor shall remove and dispose of the packaging of utensils and tools used for delivery and other unnecessary materials as soon as installation is completed. Considering the impact on environment, efforts shall be made to minimize waste materials as much as possible. (vii) The contractor shall basically carry out delivery/installation within business hours on weekdays. Details shall be separately instructed by the Bureau of ___. (2)Construction of the helpdesk environment The contractor shall construct the helpdesk installation place and environment. When implementing remote monitoring, the contractor shall develop an environment which enables remote monitoring. The contractor shall also prepare lines connecting with the office of ___. ○Requirements concerning wiring (1) The contractor shall perform an on-site study on wiring: specifically, confirmation of pathway of optical fiber and LAN cables, etc. (under the floor, on the floor, vertical pipeline, in-ceiling piping, etc.) is required. (2) The contractor shall gain the approval of the Bureau of XXX for a wiring pathway. (3) The contractor shall carry out wiring operations. (4) The place of operations in the data center should not be wired. The contractor shall secure communication means in other places at its own expense. [2. Requirements to be added depending on type/characteristics of project] ○Organizing helpdesk operations As a preparation for helpdesk operations, the contractor shall implement the following operations. The contractor shall also be responsible for any other necessary operations. (1) Preparation for access to FAQ information In ___ system, FAQ information will be disclosed via the Kasumigaseki WAN to system users. Since the contractor cannot refer to this FAQ information, it shall prepare its own environment for reference for helpdesk operators, etc. by receiving initial FAQ

359

Item Description information from the supervisory department of the Ministry of ___. Refer to “Response to FAQ information for system users” for details of operations concerning FAQ information. (2) Creation of an operations manual The contractor shall, by the commencement of the relevant business, create a helpdesk operations manual concerning the duties of telephone operators and operation procedures of the helpdesk system(note) (hereinafter referred to as the “operations manual”), based on the business operation plan and the business operation implementation outline. (Note) It refers to the environment in which the contractor in charge of operation services and the one in charge of the helpdesk confirm the operations of ___ system, allowing the operation of the same business applications with ___ system by registering pseudo data. ○Education for helpdesk staff In order to make smooth implementation of the relevant operation, the contractor shall, at its responsibility, provide education necessary for helpdesk staff, including operators, before the commencement of service. When providing education for helpdesk staff, the contractor shall make effective use of FAQ contents and simulations (mock environment) and create educational materials, such as education manuals, thus providing efficient and effective education within the contractor’s capacity. The following are details of education for helpdesk staff and support of the Ministry of ___. (1) Education The contractor shall carry out efficient and effective education with respect to the following educational contents: (i) Details of the overall operations of ___. (ii) Function and operations of the ___ system (iii) Details of the operation implementation outline (iv) Details of the operations manual (v) Information security measures (vi) Other necessary education

○Report on helpdesk installation status Status of helpdesk installation operations shall be reported to the supervisory department of the Ministry of ___ on the occasions of the following conferences. The contractor shall convene meetings when necessary to confirm the installation status, in an attempt to grasp the situation.

360

Item Description In the event of an emergency or a serious problem that may disrupt the commencement of a relevant service, the contractor shall immediately report to the supervisory department of the Ministry of ___ ○ Responses through organizational changes and improvements of ___ system, etc. When the revision of documents, including the business operation plan document, business operation implementation outline, and manuals, etc., becomes necessary along with organizational changes and/or system improvements, the contractor shall promptly revise the relevant documents upon consultation with the supervisory department of the Ministry of ___. When necessary, the contractor shall receive information from the design/development contractor with respect to the details of improvements in the ___ system necessary for the revision. Efforts shall also be made not to interfere with the execution of the relevant operation through information sharing and thorough education and information provision to employees engaged in operations.


－

Notes on security Helpdesk staff education To provide helpdesk staff with education concerning information security measures to be taken during helpdesk operations.

361



To conclude a SLA necessary for helpdesk operations and provide report on the service level.


・Service level items/definition document


・Service Level Agreement (SLA) ・Service level report


*When a helpdesk is procured together with an operation, it is necessary to add the details of service works for the formulating plan prescribed in 6.4 Operation. “6.5.4 Suggested input” lists service level items in the examples of specifications for independent procurement of helpdesk operations. [1. Basic requirements to be listed] ・Service level items (operation ratio, abandon rate, backlog rate, call back rate, target response time, response time adherence rate, target support time, support time adherence rate, etc.) ・Creation of an SLA ・Support when the service level has not been achieved

Example/explanation on description in specifications

Examples of descriptions in specifications ○Service level items Requirements for the relevant category are as follows: (1) Index for service level By assessing the status of achievement of each item of service level in the following table on a monthly basis, the contractor shall report its three months’ result to the Ministry of ___. The degree of achievement of service level during the relevant period shall be confirmed based on the consultation between the contractor and the Ministry of___, by adding some elements, such as an improvement plan, to the monthly status of service level achievement reported by the contractor every month. Table: Index of the degree of service level achievement Achievement level Conditions A: Achieved designated conditions in every service level item B: The number of unachieved service level items accounts for less

than 5% of the total number of service level items in the preceding three months

C: The number of unachieved service level items accounts for more than 5% and less than 10% of the total number of service level items in the preceding three months

D: The number of unachieved service level items accounts for more

362

Item Description than 10% of the total number of service level items in the preceding three months

(2) Measures for improving the service level achievement rate When unachieved service level items are attributable to the contractor, the contractor shall make efforts to improve the achievement rate through the following measures: (i) Free response When the SLA has not been consummated for reasons attributable to the contractor, the contractor shall consider and implement its own improvement measures (revision of procedure, installation of framework/tools, tests/inspections, etc.,) and the necessary operations shall be provided for free at the expense of the contractor. (ii) Revision of organization/appointment of full time chief supervisor In the cases of “achievement level C” or lower, the contractor shall not make the chief supervisor (manager of assistant manager) be engaged in other works than those cited in the relevant agreement. (3) Measures for the cases in which the achievement of service level continues to be difficult When the quality of service is extremely abysmal for reasons attributable to the contractor and prospect of improvement is low, the reward may be reduced. ○ Creation of an SLA and conclusion of a Service Level Agreement. The contractor, based on the definition of service level, shall create a service level agreement (SLA) (draft) clarifying the items of service level to be provided, to the supervisory department of the Ministry of ___ and their index before one month of the commencement of services and conclude the Service Level Agreement (hereinafter referred to as “SLA”) with the supervisory department of the Ministry of ___. The contractor shall comply with the concluded SLA. ○ Response when service level has not been achieved. SLA shall prescribe responses to the cases where the service level has not been achieved, which includes revision of service index and review of the contents of agreement, etc.


－

Notes on security

－

363

5. Helpdesk operations

Item Description Outline of services Primary reception, primary response, escalation

Recording and analysis of inquiries Extraction and renewal of matters to be posted on the FAQ Remote control or users’ terminal, etc.


－


・FAQ information ・Report on availability status ・Information on history of inquiries and responses ・Daily report ・Weekly report ・Monthly report


[1. Basic requirements to be listed] ・Primary reception, primary response, escalation －Reception time －Unitary support －Escalation －Primary response －Inquiries handled at the helpdesk ・Recording and analysis of inquiries, extraction and renewal data posted on the FAQ: ・Requirements for completion of inquiries


Examples of descriptions in specifications ○Primary reception, primary response, escalation (1) In principle, operator services shall be available between 9:00 and 18:00 excluding holidays (days stipulated in Article 1 of the Act on Holidays of Administrative Organs). Inquiries by fax and telephone calls shall be accepted 24 hours a day. If operator services are to be shortened or closed for several days, the contractor shall notify the Ministry of ___ to that effect in advance, and the restricted time zone mentioned above can be lifted only when the Ministry of ___ has approved of it. (2) Inquiries from officers of the Ministry of ___ by fax, telephone calls or e-mail shall be handled in a unified manner. (3) Decisions shall be made on whether an inquiry can be answered at the helpdesk. If it is solvable at the helpdesk, a primary response shall be made. If not, the inquiry shall be shifted to the secondary level. (4) Prepare responses to inquires that are deemed to be solvable at

364

Item Description the helpdesk and provide answers to users. (5) Inquiries to be handled at the helpdesk shall be as follows: ・Breakdown of a network computer and/or printer of a client ・Matters related to functions of the business system ・Operating procedures of software and/or devices ・Other matters related to the overall system, etc. ○ Recording and analysis of inquiries, extraction and renewal of data posted on the FAQ (1) To record user information and details of inquires with respect to all the inquires in the helpdesk system (2) To record details of answers in the helpdesk system after the answers have been made. (3) To select and post frequently asked questions and answers in the FAQ


－


365

6. Survey on user satisfaction


Implementation of survey on system user satisfaction and report of the results

Suggested input (Prepared by the procurer

Questionnaire survey


Report on the survey on user satisfaction


[1. Basic requirements to be listed] ・Implementation of a user satisfaction survey ・Target group and method of questionnaire survey ・Report on survey results ・Operational improvement of helpdesk upon consultation with competent officers


Examples of descriptions in specifications ○Implementation of a satisfaction survey for system users, report on its results and implementation of operational improvement programs The contractor shall conduct the user satisfaction survey and report its results. Based on the survey results, the contractor shall implement improvements in helpdesk operations, based upon discussions between the supervisory department of the Ministry ___and the contractor.


－


366

7. Helpdesk operation conference


To report on helpdesk operations at regular conferences, etc. To discuss issues and solutions when necessary (monthly, weekly, annually, special briefing session, etc.). To create and submit reports on conferences.


・List of deliverable products ・Implementation schedule (draft) [Dates of operation conferences (draft)]


・Monthly report ・Minutes


To select written documents to be reported and submitted and indicated to that effect. Review and approval process shall be conducted at an appropriate timing. [1. Basic requirements to be listed] ・Creation and review of reports ・Outline, frequency and participants of conferences that require reporting and approval processes.


Examples of descriptions in specifications ○Creation and review of reports The contractor shall report to the supervisory department of the Ministry of ___ with respect to the status of helpdesk operations in the following conferences. The contractor shall make efforts to understand the status by holding conferences to confirm availability status, on an as needs basis, and prepare reports. In the event of an emergency or serious problem that may interfere with the relevant business, a report shall be made immediately for the consideration of countermeasures, without waiting for a regular conference. ○Outline, frequency and participants of conferences that require reporting and approval processes The contractor shall participate in the following conferences that are held by the entire operation center. Operational briefing sessions and annual assessment conferences shall be held at a venue (scheduled to be in Tokyo) designated by the supervisory department of the Ministry of ____. The venue of individual coordination conference shall be coordinated among concerned parties, when necessary. Details of conferences shall be determined after the conclusion of an agreement, based upon

367

Item Description consultation with the supervisory department of the Ministry of ___. (i) Conference on installation reports To report on the progress of developing the helpdesk environment and staff education, etc., during the period of helpdesk installation. Frequency: Every other week Participant ・Secretariat of ___ system ・General manager ・Helpdesk management contractor (ii) Operation briefing session To report to the Secretariat of ___ system on the operational status and service level index. Frequency: Once a month Participant ・Secretariat of ___ system ・General manager ・Operation service contractor ・Helpdesk management contractor ・Application maintenance service contractor ・Hardware maintenance service contractor (iii) Annual assessment conference To report on the performance of services and responses from the preceding year and make assessments of the validity of the service level index. Frequency: Once a year Participant ・Secretariat of ___ system ・General manager ・Operation service contractor ・Helpdesk management contractor ・Application maintenance service contractor ・Hardware maintenance service contractor (iv) Individual coordination conference To be held whenever coordination is separately needed. Frequency: On an as needed basis Participant: To be arranged on an as needed basis


－


368

6.5.3. Deliverable products and timing of delivery The table below lists typical deliverable products and the timing of delivery. The official name of

each product and its delivery deadline need to be entered in accordance with the actual situation.


1.Creation of operation plan

Implementation plan document Helpdesk environmental construction diagram Establishment plan document Operation plan document, outline of operation implementation

Within two weeks after the conclusion of an agreement Within two weeks after the conclusion of an agreement Within one month after the conclusion of an agreement Before commencement of service


Transfer plan document to successors Transfer materials to successors

One month prior to transfer

3.Development of operation environment

Helpdesk education materials Helpdesk operations manual Telephone lines for the helpdesk Installation diagram of telephone lines the for helpdesk Telephone lines for IVR server Installation diagram of telephone lines for IVR server

Before commencement of service


SLA Service level report

Before commencement of service Monthly

5.Helpdesk operations

FAQ information Report on operation status Information on inquires/responses

Monthly Information on inquires/responses: at the time of the completion of a task

6.Survey on user satisfaction

Report on the results of the survey on user satisfaction

By designated date

7.Helpdesk operation conference

Monthly report Report on completion Minutes

Monthly By designated date

369

6.5.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.

the official name of each product and its delivery deadline need to be entered in accordance with the

actual situation.


1.Creation of operation plan Planned establishment and estimated number of users Table of division of roles Overall schedule Organizational chart Operational framework

To be listed in specifications and appendix at the time of tender publishing


Transfer documents from predecessors (system constructor in the case of new system integration) Transfer materials, operational procedures, operational tasks, and training on security, etc. from predecessors


3.Development of work environment

Restrictions on installation of lines Details of organizational changes and system modifications required for changes in helpdesk manuals


4.Service level management Service level items/definition document


5.Helpdesk operations －－ 6.Survey on user satisfaction －－ 7.Helpdesk operations conference

List of deliverable products To be listed in specifications and appendix at the time of tender publishing

370

Examples of service level items Number. Service level item Regulations Unit

1

Open hours of helpdesk (response to failures)

Open hours of the helpdesk dealing with faults From hour to hour

2

Open hours of helpdesk (regular inquiries)

Open hours of the helpdesk for regular inquiries

3 Average response time Time spent on resolving problems Hour(s)

4 Primary response time Time spent by operator from receiving failure report to providing primary response

Hour(s)

5 Number of inquiries to helpdesk

Average number of inquiries per day Case/day

6

Call busy rate Call abandonment rate

Call busy rate: Calls failed to be connected Call abandonment rate: Calls failed to be answered

%

7 Rate of problems solved at helpdesk (time)

Percentage of problems solved (closed) within the designated period of time

%

8 Hour/times of helpdesk escalations

Percentage of time spent and frequency until escalation %・number of times

9 Helpdesk backlog rate Percentage of unsolved problems at the end of the day %

10 Helpdesk call back rate Percentage of call backs for inquiries once completely answered or fixed

%

11

Service hours for the application of use related to service desk information system

Application for intranet/internet use (application for the use of common ID management system (LDAP)), application for e-mail use and application for mobile use, etc.

From hour to hour

12 Date of service desk application process Time (days) to process various applications for use

Day

13 Report Regular report Item

14 To make reception status available on the website, enabling understanding of the inquiry status, in cases of changes in the business system

Item

371

6.5.5. Division of roles In this Section, examples of roles divided among helpdesk operators, authorities and contractors of

other services are described.





identified. A clear division of roles and services should be specified, and a table of division of roles

should be complied so that concerned parties can agree that there are no omissions/errors in the

services/roles in breakout procurement.

Example of the table of division of roles

○: Main operator, △: Support, advice

Task Supervisory section

System constructor

HW maintenance contractor

SW maintenance contractor

AP maintenance contractor


iDC contractor

Helpdesk contractor

Creation of operation plan ○ △ －－－ △ △ ○

Business transfer for operation

○ ○ △ △ △ △ △ ○

Development of work environment

△ －－－－ △ △ ○

Service level management ○ －－－－ △ － ○

Helpdesk operations △ － △ △ △ △ △ ○

Survey on user satisfaction ○ －－－－－－ ○

Helpdesk operations conference (report)

○ － △ △ △ ○ △ ○

Helpdesk operations conference (assessment)

○ － ○ ○ ○ ○ ○ ○

* System constructor applies only in the cases where new system integration and transfer for

operations are to be carried out.

372

6.6. Maintenance

Maintenance operations are services to repair errors that occurred after the start of information

system operations and to respond to requests for minor modification of functions in the system.

Services in this phase include regular maintenance (regular inspection) carried out to prevent faults

and problems, emergency maintenance in the event of a problem or fault, and support for system

users and the supervisory sections, etc.

Since the details of services in this phase are formulated in the preceding phase of

“design/development,” the product of maintenance design is the input in this phase.

Details of four services implemented in maintenance are shown in Table 6.6.1.

Classification of detailed services Definition

6.6.1. Hardware maintenance HW maintenance, (server, storage, common network computer, office printer, network function: router, switch, etc.) (including software installed in hardware)

6.6.2. Software maintenance Maintenance of commercial OS, commercial middleware, and commercial application software(excluding OS, middleware, business software of OSS)

6.6.3. Application maintenance Maintenance of business application software, excluding commercial OS and commercial package software (including OS, middleware and business software of OSS)

6.6.4. System infrastructure maintenance Maintenance of “EIP,” “open webservers, “groupware, fileserver, mail server,” “integrated account management, authentication, authorization (access control),” “integrated directory,” “WAN, intra-ministerial LAN, DNS/DHCP/Proxy, remote access,” and “network lines,” which are listed in “Chapter V: Description of Technical Domain” of technology reference model.

Table 6.6.1 Classification of detailed services and definition of maintenance

373

6.6.1. Hardware maintenance 6.6.1.1. Definition of procurement areas

Hardware maintenance is the maintenance service for hardware (server, network computer, printer,

storage, office printer, network functions: router and switch, etc.).

In service procurement concerning hardware maintenance, goods (provision of devices),

installation/coordination of devices, and development of environment may be procured under the

same agreement. However, this section exclusively describes services concerning hardware

maintenance.

Table 6.6.1-1 Items corresponding to the areas of procurement of services

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


374

6.6.1.2. Services to be listed in specifications 6.6.1.2.1. Typical service operations




Guidelines on Procurement (BGP) are also listed. To write specifications, a draft of procurement

specifications should be prepared by selecting the appropriate items while coordinating with the





1.Formulation of hardware maintenance plan

Formulation of the hardware maintenance plan (maintenance work plan, work framework, etc.)

1.8.1.2 Creation of plan and procedures

Chapter VI (2) Requirements for hardware maintenance (and outline shall be listed in Chapter II (5) Work description/ deliverable product）


Concluding an SLA and recording work status in relation to service the level management index, when ensuring the quality (level) of service is necessary.

－

3.Regular maintenance/regular inspection

Preventative inspection and changing of expendables to be carried out once or more times per year, pursuant to the requirements for maintenance, etc.

1.8.2.1 Problem report or analysis of request for modification

4.Fault support On-site support for hardware faults 1.8.3.1 Analysis and decision on modification part 1.8.3.2 Implementation of modification

5.Support for version upgrade

Providing release information, such as firmware, etc., and upgrading work

1.8.3.2 Implementation of modification

6. Technical support Technical support based on requests made by the supervisory section or operation support contractor, etc.

1.7.6.2 User support 1.8.2.2 Replay or inspection of problems

375

6.6.1.2.2. Explanation on services and examples of descriptions in specifications 1. Formulation of hardware maintenance plans


To formulate hardware maintenance plans (including maintenance work plans and organizational charts listing emergency and non-emergency contact numbers, etc.)


・Maintenance outline ・Maintenance procedures ・Maintenance plan (draft) ・SLA (draft) ・Statement of Work (concerned business entities and the procurer of the relevant system)


・Hardware maintenance plan documents (including progress chart, emergency/non-emergency contact list, maintenance organizational chart, etc.)


To indicate requirements for the formulation of a maintenance plan [1. Basic requirements to be listed] ・Maintenance time ・Details to be included in the plan (work schedule, emergency contact list, list of maintenance centers, etc.) ・Deadline for submission of the plan ・Roles of concerned parties in maintenance work (refer to 6.6.1.5 for an example of division of roles) [2. Requirements to be added depending on type/characteristics of project] ・Compliance with the SLA


Examples of descriptions in specifications [1. Basic requirements to be listed] (i) Hours of on-site maintenance work shall be from 9:00 to 18:00 excluding days public offices are closed (including holidays and national holidays). However, if hardware failure may cause serious impact on business, maintenance and inspections involving system shutdown shall be available outside of the above hours. (ii) The contractor shall create a maintenance plan for regular inspections, hardware maintenance work and a maintenance organizational chart for emergency/non-emergency cases, which shall be submitted and approved by the supervisory section within 14 days of receiving the order． (iii) When formulating a maintenance work plan, the contractor shall be fully careful not to interfere with business by (for example) avoiding system shutdowns (service suspension). The contractor shall be

376

Item Description prepared to work on holidays if the maintenance work may influence business, based upon consultation with the supervisory section with respect to the dates of work. The contractor shall create a maintenance plan by arranging workdays and time tables in consideration for minimizing system shutdown time/maintenance time, while coordinating the work schedule of regular inspections/regular maintenance with operation/maintenance-related companies. (iv) The contractor shall establish a helpdesk to be able to respond quickly to inquiries during regular service hours in the event of fault of devices as well as when requests are made from the supervisory section, and gain approval from the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on devices covered by maintenance. [2. Requirements to be added depending on type/characteristics of project] (v) The contractor shall conclude an SLA, based on specifications and proposals submitted at the time of procurement by the contractor. The contractor shall also create a maintenance plan giving due consideration to the maintenance framework for preventive maintenance and trouble-shooting that are necessary for attaining the index for service level management.


－


377



To manage service level by setting a service level index and target values when it is necessary to ensure the quality (level) of services associated with hardware maintenance.


・SLA (Draft) (including service level management index)


・SLA (including service level management index) ・Service level management plan ・Service level report


To be specifically stated in service level management index and the SLA. Such documents as the service level management index and SLA are drafted by the contractor and shall state to the effect that an agreement (contract) will be concluded upon consultation between the two parties and may change after consultation. If strict compliance with an SLA is demanded, the documents shall mention periodical reviews on the performance of the service index as well as the improvement process or penalties for cases of non-compliance. Since service level management is not a compulsory requirement, full discussions shall be conducted on whether an SLA needs to be applied to a given procurement project. [2. Requirements to be added depending on type/characteristics of project] ・Service level management index (draft) ・Implementation of consultation prior to concluding an SLA ・Concept of surcharge and penalty ・Measurement of performance of the service level management index and periodical reviews on SLA attainment ・Requirements in the case of non-compliance with the SLA (approaches to responses and improvements for free)

378

Item Description Example/explanation on a description in specifications

Examples of descriptions in specifications [1. Basic requirements to be listed] (i) In the relevant procurement, a Service Level Agreement (SLA) shall be concluded upon consultation with the contractor for the purpose of verifying that the quality of maintenance provided by the contractor is kept high. The contractor shall formulate the draft of the service level agreement contributing to maintenance and improvement of service level, based on the draft of service level management index described in the relevant specifications, and shall present the draft in the form of a proposal.

No Service level management index

Specifics Index value

1 Mean Time To Repair (MTTR)

Mean Time To Repair is the monthly average time that a device took to recover from any failure, during service operation. Time of occurrence of failure is the time when a failure has been detected or recognized by notice. Recovery from failure is the state in which causes of failure of the device has been removed, normal operation has been observed and the device is available for use.

Within 6 hours

(ii) Based on the Service Level Agreement concluded with the supervisory section, the contractor shall measure the implementation status by the service level management index every month, and report the attainment status at the service level briefing sessions to be held every three months. [2. Requirements to be added depending on type/characteristics of project] (iii) Consultation between the contractor and the supervisory section shall be held based on the report of service level attainment status

379

Item Description submitted by the contractor, to determine the degree of attainment of the SLA during the relevant period. When non-attained SLA items accounts for less than 90%, the contractor shall make an improvement proposal at its own expense and implement countermeasures upon gaining approval of the supervisory section.


Service level management is not a compulsory requirement, but is the requirement to be set when the quality of maintenance service is emphasized. One should be careful because setting a service level index and objectives and adding excess requirements may raise commission fees.


Degree of attainment

Percentage of payment

Conditions

A 100%(full) Attained prescribed conditions in all SAL

items.

B 97% Percentage of non-attained SLA items

accounts for less than 5% of total SLA items.

C 94% Percentage of non-attained SLA items

accounts for more than 5% and less than 10% of total SLA items.

D 90% Percentage of non-attained SLA items

accounts for more than 10% of total SLA items.

380

3. Regular maintenance/regular inspection


To implement regular inspections more than once per year and carry out expendable changes and device adjustments, based on the maintenance outline, etc.


Maintenance outline Maintenance procedures


・Report on regular maintenance


[1. Basic requirements to be listed] ・Number and frequency of regular maintenance ・Details of maintenance work (cleaning, inspection, diagnosis by test programs, confirmation of operation following the maintenance work) ・Devices subject to regular maintenance ・Restrictions on work hours ・Creation of maintenance reports and reports on completion of regular maintenance ・Response at the time of fault detection


Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall carry out maintenance/inspections once a year, based on the “maintenance plan,” “maintenance outline,” and “maintenance procedures,” etc. (ii) The contractor shall give due consideration to the impact on business associated with the relevant system shutdown. If a regular inspection causes system shutdown, the contractor shall consult with the supervisory section in advance, and gain approval. (iii) Every time the contractor implements maintenance work based on the “maintenance plan,” the contractor shall create a “post-maintenance report” and gain approval of the work result from the supervisory section. (iv) The contractor shall formulate response plans against detected failures/troubles as a result of maintenance/inspections, and gain the approval of the supervisory section. In the cases where countermeasures have been taken during a regular inspection, a “post-maintenance report” may serve as a substitute.


－

Notes on security

381

4. Fault support


To receive hardware fault notices and carry out on-site support for fault recovery.


・Maintenance outline ・Maintenance procedures ・Fault separation procedures


・Fault report


[1. Basic requirements to be listed] ・Definition of the date/time of support service when a hardware fault occurs ・Creation of a fault repair work report [2. Requirements to be added depending on type/characteristics of project] ・To erase data completely at the time of disposal/change of a hard disk due to physical breakdown. ・Devices applicable for send-back maintenance services, the hardware maintenance contractor shall prepare an alternate device in advance, and carry out the replacement promptly when a fault occurs.

Example/explanation on description in specifications

Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall dispatch maintenance staff in response to fault notifications of devices or requests made from the supervisory section. However, in the event of an emergency, maintenance work shall be carried out outside maintenance hours upon consultation with the supervisory section. (ii) The contractor shall promptly carry out procurement, replacement and repair of parts and make efforts for early recovery of devices. (iii) When re-installation and data recovery are necessary due to hard disk change, the contractor shall request the application maintenance contractor and system maintenance contractor to carry out the work through the supervisory section. [2. Requirements to be added depending on type/characteristics of project] (iv) When external memory media, such as hard disks and /or tape media, are broken, which are then taken away from the installation site, data stored in the external memory media shall be completely erased or physically destroyed and taken away from the venue upon gaining approval from the supervisory section. (v) When the relevant device is subject to send-back service alone, the contractor shall, in advance, prepare an alternative device, and promptly replace the relevant device when a fault occurs.

Notes on Since fault support shall be carried out in cooperation among the

382

Item Description characteristics of project/information system

operation contractor, software maintenance contractor, application maintenance contractor, system infrastructure maintenance contractor and related system contractor, etc., it is necessary to clarity the roles with the concerned parties and the scope of responsibility of each contractor.


383

5. Support for version upgrade


To acquire release information on firmware, etc., and provide the information to the supervisory section. To carry out the upgrading of firmware, etc., upon consultation with the supervisory section.


・Maintenance outline ・Maintenance procedures


・Task report


[1. Basic requirements to be listed] ・Report and provision of patch updates ・Time spent from release to report of patch updates ・Type of submitted files, etc. ・Change operations, such as environment settings associated with firmware renewal, etc.


Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall acquire information on firmware updates for devices from manufactures/agents of the relevant devices, and report to the supervisory section within seven days after the disclosure of the update information. (ii) The contractor shall apply the update information to the relevant devices, when such information is deemed to be necessary, upon gaining approval from the supervisory section within one month after the approval of ministries. (iii) Upon approval of the supervisory section, the version upgrade of firmware, etc. shall be carried out with due consideration to work schedule and time so as not to cause an impact on system operations. When configuration change is necessary along with a firmware upgrade, such change shall be carried out at the time of the upgrading work.


－

Notes on security Renewal of firmware, configuration change, etc. The latest information for firmware related to security and hardware stability, such as BIOS, shall be constantly obtained and the hardware maintenance contractor shall be requested to implement renewal work whenever necessary.

384

6. Technical support


To implement technical support in response to requests made by the supervisory section or operator.


Maintenance procedures Maintenance outline Affiliation/number (expected) of the source of inquiry


・Technical support implementation report


[1. Basic requirements to be listed] Time of receiving request for support Response to technical inquiries Support for separating trouble [2. Requirements to be added depending on type/characteristics of project] Deadline of response to inquiry Submit implementation result report to the supervisory section and operation support company


Examples of descriptions in specifications [1. Basic requirements to be listed] The contractor shall promptly answer and give advice to inquiries made by the supervisory section or the operator. The contractor shall dispatch maintenance staff to the site in response to an escalation notice from the supervisory section/operator, and provide support for solutions in cooperation with concerned parties (such as the supervisory section, operator, or other maintenance companies, etc.). The contractor shall carry out a hardware log analysis, confirmation/provision of hardware configuration information when necessary, to solve problems. When the cause of the problem is stemmed in the hardware, the contractor shall promptly offer recovery service. Inquiries are accepted, in principle, from 9:00 to 18:00 on days excluding the holidays of public offices (days stipulated in Article 1, paragraph 1 of the Act on Holidays of Administrative Organs (law no. 91, 1988). The contractor shall report to the supervisory section on work results immediately after the problem has been solved or recovery work has been completed. [2. Requirements to be added depending on type/characteristics of project] The contractor shall report on response and analysis results within two days after receiving an inquiry [excluding the holidays of public offices

385

Item Description (days stipulated in Article 1, paragraph 1 of the Act on Holidays of Administrative Organs (law no. 91, 1988))]. When response cannot be presented within the deadline, the contractor shall inform the source of inquiry about progress and the expected date of response. The contractor shall provide the supervisory section and operation support company with a work report immediately after the completion of support work.


When a comprehensive inquiry reception desk, such as an integrated helpdesk, is established, specifications shall be added to enable escalation from the reception desk.


386

6.6.1.3. Deliverable products and timing of submission The table below lists typical deliverable products and the timing of delivery with respect to hardware

maintenance services. The official name of each product and its delivery deadline need to be entered

in accordance with the actual situation.



Hardware maintenance plan Maintenance outline/ maintenance procedures (revised version)

Within 14 business days after conclusion of the agreement

2.Service level management SLA Service level management plan

Within 14 business days after conclusion of the agreement

Report on the results of service level management

On the designated date, every time service level is measured

3.Regular maintenance/ regular inspection

Regular maintenance reports Within seven days after completion of work

4.Fault support Fault report Within seven days after completion of work

5.Support for version upgrade Work report Within seven days after completion of work

6.Technical support Inquiry management table Designated date Work plan (for request for support) Fourteen days prior to implementation of

work Report on the implementation of support work

Within seven days after completion of work

6.6.1.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.

The official name of each product and its delivery deadline should be entered in accordance with the

actual situation.



Maintenance plan (draft) Service level items/definition SLA Statement of Work (SOW)

Included in procurement specifications or as attachment


During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor


Service level items / definition SLA


3.Regular maintenance/ regular inspection



4.Fault support Maintenance outline Maintenance procedures


5.Support for version upgrade



6.Technical support Maintenance outline Maintenance procedures


387

6.6.1.5. Division of roles Examples of roles divided among the hardware maintenance contractor, authorities and contractors

of other works are described below.






should be compiled so that concerned parties can agree that there are no omissions/errors in the



Tasks Supervisory section





iDC contractor

Helpdesk contractor

Planning and procurement of operation maintenance plan for hardware, packaged software, and network, etc.

○ △ △ △ △ －

On-site support for hardware － ○ －－ △ △ －

Provision of packaged software in batches and implementation of off-site support

－－ ○ － △ △ －

On-site support for networks －－－－ ○ △ －

Daily system operation －－－－ ○ △ －

System and network monitoring －－－－ ○ △ －

Security monitoring －－－－ ○ △ －

Handling inquiries from users ○ －－－－－ ○ Response to inquiries from the supervisory section and escalation from the joint Helpdesk

－ ○ ○ ○ ○ ○ ○

Primary separation in the event of problems △ △ △ △ ○ △ －

Secondary response to the problem (hardware fault) △ ○ △ △ △ △ －

Secondary response to the problem (software/application software fault)

△ △ △ ○ △ △ －

Secondary response to the problem (iDC equipment fault)

△ △ △ △ △ ○ －

System recovery process in the event of faults △ △ － ○ ○ －－

Maintenance of application software △ －－ ○ －－－

Collection, analysis, report, suggestions concerning operation management information

△ △ － △ ○ △ －

Expendables management －－－－ ○ －－

Table 6.6.1.5.1 Table of Division of Roles for Operation/Maintenance Contractor (example)

388

6.6.2. Software maintenance 6.6.2.1. Definition of procurement area Software maintenance includes the maintenance services for products, including commercial OSs,

middleware and application software, etc.; any software other than commercial products, such as

newly developed software or open software (OSS), is not included in this category.

Software maintenance is often procured together with hardware maintenance; however, this section

exclusively deals with the services related to software maintenance.

Figure 6.6.2-1 Items corresponding to the areas of procurement of services

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


389

6.6.2.2. Services to be listed in specifications 6.6.2.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding



Guidelines on Procurement (BGP) are also listed. to write specifications, a draft for procurement




Chapter and section of specifications corresponding

to BGP 1.Formulation of

software maintenance plan

Formulation of software maintenance plan containing details of maintenance services for various products and emergency/non-emergency contact list, etc.

1.8.1.2 Creating of plan and procedures

Chapter XI (1) Requirements for software maintenance (and the abstract shall be included in Chapter II (5) Details of work/deliverable products)

2. Provision of correction (patch) file and version upgrade program

Provision of release information on correction (patch) file, etc., and correction file

1.8.1.2 Creation of plan and procedures 1.8.3.1 Analyzing and deciding on the parts to be corrected 1.8.3.3 Implementation of correction of purchased package

3.Technical support Provision of technical support (off-site support) for software products covered by maintenance

1.7.6.2 User support

390

6.6.2.2.2. Explanations and examples of descriptions in specifications concerning services 1. Formulation of software maintenance plan


To formulate software maintenance plans (details of maintenance services of products and emergency/non-emergency framework, etc.) and gain the approval of the supervisory section


・Maintenance outline ・List of software products covered by maintenance


・Maintenance plan (including progress chart, emergency/non-emergency contact list, and maintenance organizational chart, etc.)


To indicate requirements for the formulation of maintenance plans [1. Basic requirements to be listed] ・Required framework and products of the contractor ・Support service hours (Open hours for inquiry desk)


Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall create and deliver a maintenance plan, based on the “relevant procurement specifications,” as well as “maintenance design” and “maintenance procedures” (issued separately), etc., and receive the approval of the supervisory section. (ii) The contractor shall establish a helpdesk to be able to respond quickly to inquiries during regular service hours in the event of software faults as well as in response to requests from the supervisory section, and gain approval from the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on software products covered by maintenance.


Unlike other type of maintenance, software maintenance characteristically does not provide on-site work, but provides off-site support only. The contractor should consider an extension of inquiry service hours for software maintenance in the core system.


391

2. Provision of correction (patch) files and version upgrade program


To provide correction (patch) files and version upgrade programs of software products covered by maintenance, as well as release information on the said programs.


・List of software products covered by maintenance


・Maintenance status report


[1. Basic requirements to be listed] To promptly provide correction program and version upgrade information The subcontracting agreement shall be concluded with a software copyright holder when necessary to give the procurer the applied right to the correction (patch) file and version upgrade program.

Examples of a descriptions in specifications

Examples of descriptions in specifications (i) When version upgrade programs responding to the function enhancement of software products covered by maintenance and minor version upgrade programs to respond to the correction of faults are released, the contractor shall immediately notify the supervisory section. The contractor shall also provide a license for version upgrade and minor version upgrade programs that have been released during the maintenance period. (ii) For the provision of the said program and license, the contractor shall conclude a contract and carry out coordination with the license provider of the relevant software product, when necessary, and this shall be the responsibility of the contractor.


The right to upgrade some software products, in the case of major version upgrades, etc., may not be exercised due to the license regulations of the relevant software product.

Notes on security The contractor should inform the application maintenance contractor or the mainboard maintenance contractor about information pertaining to software bugs, patch and version upgrades, etc., immediately after such information becomes available and instruct the application maintenance contractor or the mainboard maintenance contractor to a conduct preliminary assessment of the possibility of patch application. In order to make early decisions on the possibility of patch application, there is a way to include the application maintenance contractor and the mainboard maintenance contractor in the list of recipients of information on software version upgrades provided by the software maintenance contractor.

392



Response to technical inquiries concerning software products covered by maintenance


・List of software products covered by maintenance


・Solutions to inquiries


[1. Basic requirements to be listed] ・Establishment of software technical support desk

Examples of a descriptions in specifications

An example of a description in specifications ・ To establish a support desk for inquiries about software products covered by maintenance and to provide support for the relevant software


Unlike other types of maintenance, software maintenance does not provide on-site work, but often provides off-site support through phone calls, emails or websites, etc. The contractor should consider an extension of inquiry service hours for software maintenance in the core system.


393

6.6.2.3. Deliverable products and timing of submission The table below lists deliverable products and timing of delivery with respect to software maintenance

services. The official name of each product and its delivery deadline need to be entered in

accordance with the actual situation.


1.Formulation of maintenance plan

Maintenance plan Within two weeks after conclusion of the agreement

2. Provision of correction (patch) files and version upgrade programs

Correction (patch) file and version upgrade program

At the time of patch release or update program release

3.Technical support Solution to inquiry At the time of inquiry (on an as needed basis)

394



actual situation.



List of software products covered by maintenance

Included in procurement specifications or as an attachment at the time of tender publishing

2.Provision of correction (patch) files and version upgrade programs

List of software products covered by maintenance


3.Technical support List of software products covered by maintenance


395



separated orders and the ministerial policies and present at the time of tender publishing.











iDC contractor

Helpdesk contractor

Plan and procurement of operation maintenance plans for hardware, packaged software and networks, etc.

○ △ △ △ △ －



－－ ○ － △ △ －






－ ○ ○ ○ ○ ○ ○

Primary separation in the event of a problem △ △ △ △ ○ △ －



△ △ △ ○ △ △ －


△ △ △ △ △ ○ －

System recovery process in the event of a fault △ △ － ○ ○ －－



△ △ － △ ○ △ －


Table 6.6.2.5.1 Table of Division of Roles for Operation/Maintenance Contractor (example)

396

6.6.3. Application maintenance 6.6.3.1. Definition of procurement area Application maintenance is the maintenance services for operational applications developed from

scratch and customized packaged software (the customized part or the entire packaged software

including customized part).

This Section includes OSS (OS, middleware, business software) to which there is no fixed-style of

maintenance service or maintenance services that have not been provided by distributors, etc.

Figure 6.6.3-1 Items corresponding to the areas of procurement of services

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


397




Guidelines on Procurement (BGP) are also listed. To write specifications, a draft for procurement






1. Transfer from designers/developers

Transfer from designers/developers

Chapter XI (1) Requirements for software maintenance (and the abstract shall be included in Chapter II (5) Details of work/deliverable products)

2. Formulation of application maintenance plan

Formulation of application maintenance plan (including maintenance work plan and organizational charts with non-emergency/emergency contact lists, etc.)

1.8.1.2 Creation of plan and procedures


Conclusion of SLA Report on the compliance status of the service level management index

－

4.Fault support On-site support for system failure

1.8.2.1 Problem report or analysis of request for modification 1.8.2.2 Replay or inspection of problems

5.Program modification

Partial modification and function addition for programs, development for bug fixes, tests, release in production environments, system impact analysis before patch applications, preliminary evaluations, and patch applications in operational environments

1.6.6 Detailed software design 1.6.7 Creation of software code and test 1.6.8 Software integration 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance

6.Technical support Implementation of technical support in response to requests made by the supervisory section and operators

1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance

398

6.6.3.2.2.Explanation on services and examples of descriptions in specifications 1. Transfer from designers/developers Item Description Outline of Service operations

Transfer from design/development contractor

Suggested input [Products related to operation and maintenance created by the design/development contractor] ・ Maintenance plan (draft) ・ Maintenance design ・ Maintenance procedures ・ Maintenance tools ・ Transfer implementation plan

(Prepared by procurer)

・ Transfer implementation report ・ Maintenance plan ・ Organizational charts


[1. Basic requirements to be listed] ・ Creation of a transfer implementation report ・ Implementation of the transfer from the design/development

contractor before the full operation of the new system or the commencement of the contract period.

・ To make inquiries and requests for modification to the transferors, if questions arise about materials created by the transferors, such as maintenance plans/maintenance procedures, etc.

・ Creation of maintenance procedures based on the documents for the formulation of maintenance procedures


○Transfer from designers/developers, etc. ・ The contractor shall consult with the relevant officer immediately

after the completion of a contract, and shall receive transfer of the details and maintenance work for the software covered by the maintenance contract from designers/developers.

・ The contractor shall develop a maintenance framework and a maintenance plan, based on the transfer concerning maintenance.

Notes on characteristics of a project/information system

－


399

2. Formulation of application maintenance plan


To formulate application maintenance plans (including maintenance work plans and organizational charts with non-emergency/emergency contact lists, etc.)


・Maintenance outline ・Maintenance procedures ・Service level management index (draft) ・Table of the division of roles (contractors involved in the relevant systems and the procurers)


・Implementation plan, etc.


To specify requirements for the formulation of maintenance plans [1. Basic requirements to be listed] ・Details of work to be included in the plan (organization, progress management, quality management, issue management, change management and configuration management, etc.) and division of the roles of the contractor (application maintenance contractor) [2. Requirements to be added depending on type/characteristics of project] ・<In the case of a multiple-year contract> Requirements concerning a revision of the work plan in each fiscal year (for example, a change in the plan in accordance with the attainment status of requirements, such as SLA, etc.) ・<In the case of application maintenance that requires specific skills or experience> Requirements for the framework of the contractor, such as qualifications and experience required for workers, etc.


Examples of descriptions in specifications (1) The contractor shall create and deliver a maintenance plan, based on the “relevant procurement specifications,” as well as the “maintenance design” and “maintenance procedures” (issued separately), etc., and receive the approval of the supervisory section. (2) The maintenance work plan shall give sufficient consideration not to interfere with business, such as avoidance of system (service) shutdowns. Any work that may have an impact on business may be done on holidays, etc. through schedule coordination. (3) The contractor shall establish a framework that enables a rapid maintenance response during regular maintenance hours in preparation for faults of devices covered by the maintenance contract and/or response to requests made from the supervisory section, and shall gain the understanding of the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on the application software products covered by the maintenance and

400

Item Description the entire system covered by that maintenance, including the relevant application systems.


Specific requirements for key personnel should be described in detail in the case of a project requiring specific experience and skills: for instance, experience in maintenance/experience in design/development of the relevant system or other similar systems. With respect to maintenance work and fault support, clarification should be made regarding the division of roles and the scope of responsibility of the operator, hardware maintenance contractor, application maintenance contractor, concerned companies of related systems, and other concerned companies. With respect to the configuration management of the entire system, clarification should be made regarding the division of roles, the scope of responsibility and the procedures of configuration management of the operators in charge of the configuration management of the entire system.


401



To conclude an SLA, measure performance concerning the service level management index, and review of non-attained SLA tasks, etc. At the time of procurement, a full discussion should be held to decide whether the application of an SLA is necessary because the service level management does not need to be applied to all projects.


・Service level management index (draft) ・Service level management plan


・Service level report


[1. Basic requirements to be listed] None [2. Requirements to be added depending on type/characteristics of project] To include requirements for the SLA to be concluded between the procurer and the contractor and state to the effect that both parties may discuss issues about the service level management index. When demanding strict compliance with an SLA, periodical reviews and task requirements for non-compliance should be described. ・Implementation of discussions on service level management index between ministries and the maintenance contractor ・Definition and explanatory notes on SLA items ・Concept of the amount of payment and penalty ・Implementation of periodical reviews on SLA compliance ・Responsive requirements for non-compliance to SLA (free response and approaches to improvements)


Example of a description in specifications [2. Requirements to be added depending on type/characteristics of project] (1) In this procurement, the contractor shall conclude the Service Level Agreement (SLA) upon consultation with the procurer, shall formulate the SLA plan that will contribute to the maintenance and improvement of service level, based on the service level management index described in this specifications document, in order to ensure that the quality of maintenance provided by the contractor is kept high, and shall present it in the form of a written proposal.


Explanation

1 Modification of application software

Whether response had been completed within a month after an application defect had been detected

402

Item Description 2 Security

maintenance Whether the preliminary evaluation and application to the operational environment have been completed within a month after the release of patches, such as the operating system (OS) of the system equipped with the application software covered by the maintenance contract and middleware, etc.

(2) The contractor shall measure the performance status of each service level management index on a monthly basis, based on the SLA concluded with the supervisory section, and shall report the attainment status at the service level briefing session to be held every three months. (3) Based on the report on the service level attainment status from the contractor, the contractor and the supervisory section shall hold discussions to assess the attainment level of the SLA during the relevant period. The payment of the fee for the commissioned business shall be determined in accordance with the attainment level of the SLA. If the unattained SLA items accounts for less than 90%, the contractor shall make a proposal for improvements under its own responsibility, and implement the measures upon receiving approval from the supervisory section. Attainment Level


Conditions

A 100% (full amount)

Attained prescribed conditions in all SLA items

B 97% The number of unattained SLA items

accounts for less than 5% of all SLA items.

C 94% The number of unattained SLA items

accounts for more than 5% and less than 10% of all SLA items.

D 90% The number of unattained SLA items

accounts for more than 10% of all SLA items.


In the case of a multiple-year application maintenance project, more frequent assessment on the service level attainment shall be conducted, for example on a quarterly basis. Incessant efforts should be made for quality improvements, including reorganization in the cases where its attainment is insufficient.


403

4. Fault support


To conduct on-site support for the escalation from the supervisory section or operator.


・Maintenance designs ・Maintenance procedures ・Operation manual for hardware/software and attached documents


・Fault report


In some cases, time spent on the investigation of causes, time spent until fault support and the success rate of cause investigation shall be included as service level management indexes. [1. Basic requirements to be listed] ・Implication of fault support ・Response time of fault support


Examples of descriptions in specifications [1. Basic requirements to be listed] (1) Based on the primary separation by the operator, the contractor shall analyze fault causes on application software covered by the maintenance contract, consider solutions or countermeasures against problems and implement the countermeasures upon consultation with the supervisory section. (2) If the operator cannot identify the cause of a fault in the primary separation, the contractor shall provide support for the identification of the cause and temporary recovery in cooperation with the hardware maintenance contractor, software maintenance contractor and operation contractor, in accordance with the instructions from the supervisory section. (3) Response hours of fault support shall be 9:00 to 18:00 on weekdays (excluding holidays and national holidays). However, response outside of working hours shall be considered upon consultation with the supervisory section.


－


404

5. Program modification


Partial modification of a program, function addition, development for bug fixing, tests, releases into the production environment, patch applications, analysis of the impact of patch applications on the system


Procedures (maintenance procedures, operation procedures) Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) Source code, etc. Project standards Test standards Coding regulations Change requirements for applications covered by the maintenance contract


[Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) [Revised version] Source code, etc. Program files Test specifications (specifications for unit tests, integration tests, system tests, acceptance tests) Report on test results Release plans Release procedures Report on the results of release work


[1. Basic requirements to be listed] ・Modification of application software in response to problems detected after the commencement of operation ・Patch applicability assessment for the maintenance of application software generated after the commencement of operation ・Partial and slight improvement of application software and function addition associated with system change, etc. (including incidental tasks, such as revision of design documents, program modification, tests and, migration) [2. Requirements to be added depending on type/characteristics of project] ・Modification of application software in order to respond to performance problems originating in the application software

405

Item Description Example/explanation of a description in specifications

Example of a description in specifications [1. Basic requirements to be listed] (1) The contractor shall implement modification of defects in application software covered by the maintenance contract based on the incident management document issued by the supervisory section or operations management contractor, in accordance with the design/development process of this system. However, this shall not apply to the warranty period of the designers/developers. (2) The contractor shall implement light function addition/modification described in the appendix of the specifications, in accordance with the design/development process of this system. (3) When a patch file is released for an operating system (OS) and middleware used for the system in which application software covered by the maintenance contract is installed, the contractor shall implement a preliminary evaluation of the application within one month after the release of the relevant patch file. The preliminary evaluation shall be carried out under the maintenance environment controlled by the supervisory section and the result of the preliminary evaluation and path application procedures shall be promptly presented to the supervisory section in written form. [2. Requirements to be added depending on type/characteristics of project] (4) Application of patch files, such as an evaluated operating system (OS) and middleware, into the operation environment shall be promptly carried out in accordance with the design/development process of the relevant system, upon consultation with the supervisory section.


Defects of applications may take a long time to be corrected after the need for correction was found due to various reasons (difficulty in finding causes, wide range of correction needs, impact on other systems, etc.). Therefore, there is an option to specify in the specifications that a service requirement is limited to “formulate an application modification plan upon consultation with relevant personnel when application defects are found,” instead of including the implementation of modifications as a requirement. The implementer of a “patch application for evaluated software” is different depending on the application subject. For instance, application of evaluated patch files for servers (for example, departmental file server) not equipped with PCs or business systems shall be carried out by the operator. On the other hand, the service for servers equipped with the business system shall be carried out by the application maintenance contractor.


406



・To implement technical support in response to requests made by the supervisory section or operator.


・Design documents and maintenance procedures of systems covered by the maintenance contract


・Report on the implementation of support tasks


[1. Basic requirements to be listed] ・Response to inquiries ・Support for separating problems ・Dispatch of engineers when necessary (on-site support ) [2. Requirements to be added depending on type/characteristics of project] ・Preliminary evaluation/impact analysis of patch application in OS/middleware, etc. ・Application of evaluated patch, etc.


Example of a description in specifications (1) The contractor shall implement additions/changes to the system in which is running the application software covered by the maintenance contract, such as revision of the system environment in which addition and change have become necessary after the commencement of operation, additions/changes of parameter, etc., revision/change of data base definitions, and the addition/change of exceptional characters/system codes, etc.


Information provision and application of patches To immediately provide ministries with information pertaining to technical problems involved in the information system, security vulnerabilities (security holes), software bugs, patches and version upgrades, etc. To provide services, such as verification of patch applications and patch application tasks, and technical advice on software when requested by ministries


407

6.6.3.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to application




1. Transfer from design/development contractor

Transfer implementation report Within one week after the completion of transfer

2. Formulation of maintenance plan

Implementation plan Within two weeks after the conclusion of contract


SLA Service level management plan

Within 14 business days after the conclusion of contract


On the designated date, every time service level is measured

4.Fault support Fault report Fault support Within one week after the completion of fault support

5.Program modification Work implementation plan Fourteen days prior to the commencement of work

[Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.)

[Revised version] Source code, etc. Program files Test specifications (various specifications, including unit test, integration test, system test, acceptance test) Report on test results Release plan Release procedures Report on release results

On an as needed basis (within 14 days after the completion of the release or at the time of collating)

6.Technical support Report on support work implementation

Within one week after the completion of work

408



actual situation. Service Input Timing of presenting input

1. Transfer from design/development contractors

Maintenance plan (draft), maintenance design, maintenance procedures, maintenance tools, transfer implementation plan (draft)

At the time of transfer from the designers/developers


Maintenance plan (draft) SLA (draft) Service level management index (draft) Table of the division of roles (SOW) (Statement of Work)

Included in procurement specifications or as an attachment

Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.)

During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor


SLA (draft) Service level management index (draft)


4.Fault support Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code


5.Program modification Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code


6.Technical support Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code Information indicating the volume of maintenance work


409








○: Main personnel in charge, △: Support, advice






iDC contractor

Helpdesk contractor

Planning and procurement of operation maintenance plan for hardware, packaged software and network, etc.

○ △ △ △ △ －



－－ ○ － △ △ －






－ ○ ○ ○ ○ ○ ○




△ △ △ ○ △ △ －


△ △ △ △ △ ○ －



Collection, analysis, reporting, suggestions concerning operation management information

△ △ － △ ○ △ －


Table 6.6.3.5.1 Division of roles among operation and maintenance contractor (example)

410

6.6.4. Maintenance of system infrastructure 6.6.4.1. Definition of procurement areas Maintenance of system infrastructure is the maintenance services for technologies included in

“Chapter V: Explanations on Technical Domain” of the technical reference model, such as “EIP,”

“open web server,” “groupware, file server, mail server,” “integrated account

management/authentication/authorization (access control),” “integrated directory,” “WAN/ministerial

LAN, DNS/DHCP/Proxy, remote access,” and “network lines.”

There are cases where procurement of these maintenance services is made under the same contract

as the installation of devices, introduction of setup devices and development of the environment.

However, this section describes only the services related to maintenance.

Figure 6.6.4-1 Items corresponding to the classification of procurement of services

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


411



should be examined so as not to omit necessary information. To write specification, a draft for

procurement specifications should be prepared by selecting appropriate items, while coordinating

with the corresponding Program Management Office (PMO).

[Maintenance of system infrastructure]

Service operations Outline of service operations SLCP-2007 activity

Chapter/section corresponding to

Basic Guidelines for Procurement

1. Transfer from designers/developers

Transfer from designers/developers

1.8.1.1 Transfer from development process

Chapter XI Requirements for maintenance (however, not applicable to either (1) or (2))


Formulation of maintenance plans for system infrastructure (including a maintenance work plan and organizational charts with non-emergency/emergency contact lists, etc.)

1.8.1 Preparation for process initiation (maintenance process)


Concluding SLA, recording SLA index and improving non-attained SLA items

－

4.Fault support Provision of fault support in cooperation with the hardware maintenance contractor, software maintenance contractor and operator to resolve a system fault which cannot be solved by the operator

1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance

5.Updating basic software Software maintenance tasks necessary for the sustainable provision of services

1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance

6.Technical support Each task of system engineers necessary for system operation

1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance

412

6.6.4.2.2. Explanations and examples of descriptions in specifications concerning services 1. Transfer from designers/developers


Transfer from design/development contractor


[Products related to operation/maintenance created by the design/development contractor] ・ Maintenance plan (draft) ・ Maintenance design ・ Maintenance procedures ・ Maintenance tools ・ Transfer implementation plan


・ Transfer implementation report ・ Maintenance plan ・ Organizational chart


[1. Basic requirements to be listed] ・ Creation of the transfer implementation report ・ Implementing transfer from the design/development contractor

prior to the full operation of the new system ・ Making inquiries and requests for modification to the

designers/developers, if questions arise about maintenance plans/maintenance procedures, etc. Creating maintenance procedures, based on the documents concerning the creation of maintenance procedures


○Transfer to the maintenance contractor ・ The contractor shall consult with the relevant officer immediately

after the conclusion of the contract and shall receive the transfer of details of the system infrastructure covered by the maintenance contract and the maintenance works from the designers/developers by the end of (M/FY) at the contractor’s expense and responsibility.

・ Based on the transfer of materials concerning maintenance, the contractor shall develop a maintenance framework and create a maintenance plan.


－


413

2. Formulation of maintenance plans for system infrastructure Item Description Outline of service operations

Submit the maintenance plan for system infrastructure (including a maintenance work plan and an organizational chart with a non-emergency/emergency contact list, etc.) to the supervisory section and gain the approval of the supervisory section


[1.Input to be basically presented] ・Maintenance outlines ・Maintenance procedures ・Table of division of roles (companies related to the relevant system and the procurer) [2. Additional input necessary for presentation due to the type/characteristics of projects] ・Service level management index (draft)


・Maintenance plan for system infrastructure


To state required items concerning the formulation of the maintenance plan [1. Basic requirements to be listed] To create and deliver the “maintenance plan” and gain the approval of the procurer in advance ・Detailed definition of the procedures of business implementation ・Formulation of the plan for organization, division of roles and communications methods


Example of a description in specifications (1) The contractor shall create/deliver a maintenance plan for regular maintenance and system maintenance works, based on “these procurement specifications” and the separately issued “maintenance design” and “maintenance procedures,” and gain the approval of the supervisory section. (2) The maintenance work plan shall give sufficient consideration not to interfere with business, such as the avoidance of system (service) shutdowns. Any work that may have impact on business may be done on holidays, etc. through schedule coordination. (3) The contractor shall establish a framework that enables a rapid maintenance response during regular maintenance hours in preparation for a device fault covered by the maintenance contract and/or response to requests made from the supervisory section, and shall gain the understanding of the supervisory section.


The division of roles among concerned business entities should be clearly specified, such as operators and business entities of related systems as well as the scope of responsibility of each business entity.


414



Concluding an SLA, reporting service level and implementation of approaches to improvements, etc. Careful discussions shall be held to decide whether the application of an SLA is necessary because service level management does not need to be applied to all projects.


・Service level management index (draft) ・SLA (draft)


・SLA ・Maintenance report ・Service level report


[1. Basic requirements to be listed] None [2. Requirements to be added depending on type/characteristics of project] To include requirements for SLA to be concluded between the procurer and the contractor and state to the effect that both parties may discuss issues about the service level management index. When demanding strict compliance with the SLA, periodical reviews and task requirements for non-compliance shall be specified. ・Implementation of discussions on the service level management index between ministries and the maintenance contractor ・Definition and explanatory notes on SLA items, such as frequency of version upgrades and fault support hours ・ Implementing periodical reviews on the results of compliance with the SLA ・Requirements for responses in the event of non-compliance with the SAL (for free response and approaches to improvements)

415


Examples of descriptions in specifications [2. Requirements to be added depending on type/characteristics of project] (1) In this procurement, the contractor shall conclude the Service Level Agreement (SLA) upon consultation with the procurer, shall formulate an SLA plan that will contribute to the maintenance and improvement of service level, based on the service level management index described in this specifications document, in order to ensure that the quality of maintenance provided by the contractor is kept high, and shall present it in the form of a written proposal.


Explanation

1 Modification of application software

Whether countermeasures have been completed within a month after the application defect had been detected

2 Security maintenance Whether the preliminary evaluation and application to the operational environment have been completed within a month after the release of patches, such as an operating system (OS) equipped with application software covered by maintenance contract and middleware, etc.

(2) The contractor shall measure the performance status of each service level management index on a monthly basis, based on the SLA concluded with the supervisory section and shall report the attainment status at the service level briefing session to be held every three months. (3) Based on the report on the service level attainment status from the contractor, the contractor and the supervisory section shall hold discussions to assess the attainment level of the SLA during the relevant period. The payment of the fee for the commissioned business shall be determined in accordance with the attainment level of the SLA. If the unattained SLA items accounts for less than 90%, the contractor shall make a proposal for improvements under its responsibility, and implement the measures upon receiving approval from the supervisory section.

416

Item Description


－


Attainment level


Conditions

A 100%(full amount)

Attained prescribed conditions in all SLA items

B 97% The number of unattained SLA items

accounts for less than 5% of all SLA items.

C 94% The number of unattained SLA items

accounts for more than 5% and less than 10% of all SLA items.

D 90% The number of unattained SLA items

accounts for more than 10% of all SLA items.

417

4. Fault support


To conduct on-site support for the escalation cases from the supervisory section or operator.


・Maintenance designs ・Maintenance procedures ・Operation manual for hardware/software and attached documents


・Fault report


In some cases, time spent on cause investigation, time spent until fault support and success rate of cause investigation shall be included as service level management indexes. [1. Basic requirements to be listed] ・Implication of fault support ・Response time of fault support


Examples of descriptions in specifications [1. Basic requirements to be listed] (1) Based on the primary separation done by the operator, the contractor shall analyze fault causes on application software covered by the maintenance contract, consider solutions or countermeasures against problems and implement the countermeasures upon consultation with the supervisory section. (2) If the cause of a fault cannot be identified in the primary separation by the operator, the contractor shall provide support for the identification of the cause and temporary recovery in cooperation with the hardware maintenance contractor, software maintenance contractor and operator, in accordance with the instructions issued by the supervisory section. (3) Response hours of fault support shall be 9:00 to 18:00 on weekdays (excluding holidays and national holidays). However, response outside of working hours shall be considered upon consultation with the supervisory section.


If system continuity at the time of system failure is possible due to redundancy in the system, immediate countermeasures do not need to be carried out upon consultation with the relevant officer, which may be included in the maintenance specifications.


418

5. Updating system infrastructure software


To update system infrastructure software and perform patch applications for function improvements and countermeasures against defects and vulnerabilities of the system infrastructure software etc.


Procedures (maintenance procedures, operation procedures) Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.), Source code, etc.


[Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.), [Revised version] Source code, etc., Program files, Testing specifications, Report on test results, Release plan, Release procedures, Report on the results of the release, etc.


[1. Basic requirements to be listed] ・Implementation of preliminary evaluation in a maintenance environment ・Operation verification of related systems/software ・Revision of design/procedures documents, etc. ・Implementation of configuration management


Example of a description in specifications [1. Basic requirements to be listed] (1) The contractor shall update system infrastructure software based on defect information, vulnerability information and incidence management slips presented by the supervisory section concerning the system infrastructure and its software covered by maintenance contract. Before implementing the update operations, the contractor shall perform preliminary evaluations in a maintenance environment and gain approval from the supervisory section. (2) At the time of update verification, the contractor shall carry out the operation verification for systems/software that will operate on the system infrastructure or in coordination with the system infrastructure. (3) When implementing update operations, the contractor shall use the revised design/procedures, in accordance with the configuration management process of this project.

Notes on characteristics of

419

Item Description project/information system Notes on security Provision of information and application of security patches

Information pertaining to technical problems, security holes, software bugs, patches, and version upgrades of the information system shall be immediately reported to ministries. The contractor shall also carry out such works as application verification work, patch application, and provision of technical advice on software, in response to requests from ministries.

420



・Preliminary evaluation associated with patch application, patch application to operational environments, slight changes not requiring source code change, impact analysis associated with the modification of external systems and networks, etc.


・Design documents for systems covered by the maintenance contract and maintenance procedures


[Revised version] Source code, etc., program files, test specifications, test results, release plans, release procedures, reports on the results of release works


[1. Basic requirements to be listed] ・Slight changes not requiring source code changes ・Impact analysis associated with the modification of external systems and networks, etc. (1) EIP ・Database maintenance, such as deletion/creation of database tables, data import, etc. ・Maintenance of fonts of exceptional characters (2) Open web server ・Replacing the certificate when the server-certificate has been expired ・Review of server security settings based on information of vulnerability, etc. (3) Groupware, file servers, mail servers ・Registration, renewal, deletion of user accounts (4) Management, authentication, authorization (access control) ・Registration, renewal, deletion of user accounts (5) Integrated directory ・Registration, renewal, deletion of user accounts (6) WAN/ministerial LAN, DNS/DHCP/Proxy, remote access ・Registration, renewal, deletion on DNS servers


Example of a description in specifications [1. Basic requirements to be listed] When security patches and updates concerning the OS and middleware, on which the system infrastructure software covered by maintenance contract is operated become available, the contractor shall consider the necessity of its application. When the application is deemed to be necessary, the contract shall conduct a preliminary evaluation under the maintenance environment to ascertain that patch application will not cause defects, and then carry out the application to the operation environment upon reporting to the supervisory section.

421

Item Description [2. Requirements to be added depending on type/characteristics of project] [Matters associated with EIP] The contractor shall register the applications requested by the supervisory section so that the application can be integrated into the portal. The contractor shall implement maintenance works on data to be registered in the EIP. [Matters associated with open web servers] ・ Carrying out regular reviews on security settings so as to keep

the security level of the open web server high, by occasionally checking on vulnerability information, etc.

[Matters associated with groupware, file servers, mail servers] ・ Appropriately carrying out authority settings for groupware, file

servers and mail servers associated with the hiring, leaving and changing of employees, etc.

[Maters associated with integrated account management, authentication, and authorization (access control)] ・ Appropriately carrying out the addition, change, and deletion of

user accounts associated with the hiring, leaving and changing of employees, etc.

[Matters associated with the integration directory] ・ Solidly carrying out integration directory settings associated with

the addition, change, and deletion of ministerial systems [Matters associated with WAN/ministerial LAN, DNS/SHCP/Proxy, remote access] ・ Carrying out changes in settings of the WAN/ministerial LAN,

DNS/DHCP/Proxy, etc. associated with the addition, renewal or abolition of ministerial systems.



422

6.6.4.3. Deliverable products and timing of submission The table below lists typical deliverable products and their timing of delivery with respect to maintenance services for system infrastructure. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation.

Service Deliverable product Delivery deadline 1. Transfer from

design/development contractor

Transfer report Within one week after the completion of transfer


Maintenance implementation plan

Within two weeks from the conclusion of a contract

3.Service level management SLA Service level management plan

Within 14 business days after the conclusion of a contract


On the designated date at every measurement of the service level

4.Fault support Maintenance report Service level report (*Fault support, in the cases where fault support is included in the SLA)

Maintenance report: Monthly Service level report: At the time of collating or quarterly

5. Updating system infrastructure software

Work implementation plan At least 14 business days before the implementation of work

[Revised version] Procedures (Maintenance procedures, Operation procedures). [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) [Revised version] Source code, etc., program files, test specifications, report of test results, release plan, release procedures, report on results on release works

On an as needs basis (within 14 days after the completion of the release or at the time of collating)

6.Technical support Work implementation plan At least 14 business days before the implementation of work

[Revised version] Sources code, etc., program files, test specifications (specifications of various tests, such as unit test, integration test, system test and acceptance test) report on test results, release plan, release procedures, report on results of release work

Within seven business days after the implementation of work

423



actual situation. Service Input Timing for presenting input

1. Transfer from design/ development contractor

Maintenance plan (draft), Maintenance design, Maintenance procedures, Maintenance tools, Transfer implementation plan (draft)

At the time of implementation of transfer from designers/developers


Maintenance plan (draft) SLA (draft) Service level management index (draft) Statement of work


Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.)

During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor agreement.


SLA (draft) Service level management index (draft)


4.Fault support Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, definition of system environment, etc.) Source code

During tender period: Disclosed to bidders After conclusion of agreement: Lent to contractor

5.Update of system infrastructure software

Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, definition of system environment, etc.) Source code


6.Technical support Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) Information indicating the volume of maintenance work Source code, etc.


424














iDC contractor

Helpdesk contractor

Plan and procurement of operation maintenance plan for hardware, packaged software and network, etc.

○ △ △ △ △ －



－－ ○ － △ △ －





Handling inquiries from users ○ －－－－－ ○

Response to inquiries from the supervisory section and escalation from the joint Helpdesk

－ ○ ○ ○ ○ ○ ○


Secondary response to problem (hardware fault) △ ○ △ △ △ △ －

Secondary solutions in the event of problems (software/application software fault)

△ △ △ ○ △ △ －


△ △ △ △ △ ○ －




△ △ － △ ○ △ －


Table 6.6.4.5.1 Division of roles among operation and maintenance contractor (example)

425

6.7. Tasks incidental to procurement of devices

6.7.1. Definition of procurement area The term “tasks incidental to procurement of devices” refers to services incidental to devices

(including ready-made software for OSs inseparable from hardware) that are necessary to implement

information systems (see Figure 6.7.1.).

There are cases where procurement of the subsequent maintenance services is made under the

same contract in addition to the installation of devices such as deployment and setting, and

arrangement of the environment. However, this section describes only the services related to

installation.

Figure 6.7-1 Items corresponding to the classification of procurement of services

6.7.2. Services to be listed in specifications 6.7.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding



11 Software Life Cycle Processes-Japan Common Frame-2007 (SLCP-JCF 2007), Information-technology Promotion

Agency, Japan (in Japanese)

6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation

6.3 System construction (design/development)

6.5 Helpdesk

6.6 Maintenance


426

Guidelines on Procurement (BGP)12 are also listed. To write specifications, a draft of procurement






1.Master plan formulation Formulation of work details, schedule, process, implementation framework (division of roles), Creation of implementation plan Progress management, reviews to the persons in charge

1.2.4: Planning 1.2.5: Implementation and management 1.2.6: Review and assessment

Chapter XII Framework and method of work (1)Framework of work (3) Introduction

2.Prior explanation/coordination with concerned parties

Prior explanation to and coordination with concerned contractors and ministries

3.2.2: Environment construction process

Chapter XII Framework and method of work (3)Introduction

3.On-site investigation/design

On-site investigation of the site where devices are to be installed Creation of on-site investigation report and working drawing Creation of on-site work plan Creation and submission of diagrams such as device installation layout, rack layout, network diagram (if network is included), and design documents such as security design and network design documents

3.2.2 Environment construction process 3.2.1 Preparation for process initiation(environment development process)

Chapter XII Framework and method of work (3)Introduction

4.Device installation Work on power source and ventilation Emplacement/installation of devices

3.2.2 Environment construction process

Chapter XII Work framework and method (3)Introduction

5.Device setup Network installation in accordance with the design document (if a network is included), Installation and setting up of software, and connection with other systems

1.6.12 Software installation process

Chapter XII Work framework and method (3)Introduction

6.Operation verification/test

Carrying out verification tests on installed hardware, software and the network (if a network is included) Support for tests performed by system development contractors

2.4.1 Preparation for process initiation 2.4.2 Validation, 2.5.1 Preparation for process initiation 2.5.2 Confirmation of validity

Chapter VIII Definition of requirements for tests

7.Migration Migration of data, system, and business from the existing system or support for that work

1.8.5 Migration Chapter IX Definition of requirements for migration (1) Migration-related

requirements 8.Information provision to Provision of information to 1.6.13 Chapter IX

12 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of

Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf

427




operation/maintenance contractors

operation/maintenance contractors, such as setting information for devices and software, and operation procedures

Software acceptance support

Definition of requirements for migration (2) Education-related

requirements

9. Information provision and training to users

Training of system operation procedures for end users and persons in charge of the system (if end users use the system)


Chapter IX Definition of requirements for migration (2) Education-related requirements

10. Acceptance Preparation/delivery of a set of the necessary deliverables Support for acceptance tests by ministries

1.2.7 Delivery and completion

Chapter XII Framework and method of work (3) Introduction

428

6.7.2.2. Explanations and examples of descriptions in specifications concerning services 1. Master plan formulation


Deliberation of the overall structure, including work details, schedule, work site, and roles, and formulation of the master plan


・ Overall schedule ・ Table of division of roles


・ Master plan


[1. Basic requirements to be listed] ・ Tasks to be included in the plan ・ Roles of persons in charge ・ Organizational structure ・ Designation and constraints concerning working hours, locations,

etc. [2. Requirements to be added depending on type/characteristics of project] ・ Required qualifications for workers ・ Requirements for the contractors, such as job experience ・ Detailed rules regarding work hours/locations ・ If conditions differ among locations, such as work days and hours,

work plans for locations shall be submitted accordingly. Example/explanation of a description in specifications

○Creation of an implementation plan The contractor shall create an “implementation plan” that includes work descriptions, a framework and a schedule of work, etc., prior to the installation of devices. (1) Creation of an implementation plan

・ The “implementation plan” shall include all the operations listed in the “Table __. Division of roles in installation work.”

・ If coordination is necessary for the cooperation with external parties in creating the “implementation plan,” the contractor shall consult with the relevant Ministry. In addition, the contractor shall provide support for the necessary coordination.

(2) Working hours The emplacement and installation should be within business hours on weekdays.


・ Some ministries require separate submission of introduction plans and organization charts. The specifications should state that such matters shall be done in accordance with the procurement policies/guidelines of the ministry.

・ When a project requires specific experience or skills, detailed requirements for the personnel in charge shall be stated.

・ In case that the installation is carried out at many places, the

429

specifications should state that the contractor shall submit a list of persons in charge at each location, contact information and the like, and a general guideline for operation carried out on site.


430

2. Prior explanation/coordination for concerned parties


To give prior explanation to concerned contractors and ministries and discuss matters to be coordinated beforehand.


・ Contact information of sites and concerned contractors ・ List of sites where the system is to be deployed ・ List of devices to be installed


・ Documents for prior coordination/explanation and minutes (drafts in case of support)


[1. Basic requirements to be listed] ・ Prior coordination shall be carried out. ・ Matters needs to be coordinated beforehand (the statements

should be described in concrete terms.) ・ Concerned parties to participate in prior coordination (the

expected number of participants shall be given.) [2. Requirements to be added depending on type/characteristics of project] ・ The contractor shall convene or participate in conferences such

as a meeting for prior explanation, if required. ・ Participants and subjects of explanations of conferences such as

a meeting for prior explanation shall be described. Example/explanation of a description in specifications

○ Prerequisite operation prior to delivery (A) The contractor shall take part in on-site explanatory meeting prior

to delivery to give details of deliverable devices, delivery schedule, and other necessary explanations.

(B) The contractor shall identify matters to be consulted with persons in charge on site, such as installation locations of existing products and preparation of power supplies, etc.

(C) The contractor shall conduct prior coordination on the matters mentioned in the previous clause.


In case that terminals and the like are deployed at many places, there will be different contractors involved in the work at each workplace. Therefore, the procurer needs to mention concerned parties, for which coordination is needed, in the specifications. In case that devices procured in the previous fiscal year (reusable products) are to be used, the procurer should state that the contractor should cooperate with other contractors, such as those have deployed the terminals in the previous fiscal year, persons in charge on site and so forth.


431

3. On-site investigation/design


To implement on-site investigation at places where devices are to be deployed and to make working drawings after writing a report on on-site investigation


・ Security policies issued by the ministry ・ Standards for Information Security Measures for the Central

Government Computer Systems ・ Design documents concerning the existing system, such as working

diagrams, layout diagrams for device installation, rack installation diagrams, and wiring diagrams


・ On-site investigation plan ・ Report on on-site investigation ・ Design documents, such as working diagrams, layout diagrams for

device installation, rack installation diagrams, and wiring diagrams Matters to be described in specifications

[1. Basic requirements to be listed] ・ Selection of appropriate devices/software based on the

requirements in the specifications ・ Necessary on-site investigations ・ Results of on-site investigations, design ・ Outputs, such as diagrams to be created ・ Implementation of on-site investigations and timing of the

submission of outputs ・ Constraints on the implementation of on-site investigations [2. Requirements to be added depending on type/characteristics of project] ・ Definition of security requirements in conformity with the standard

security policies of the central government, etc. ・ “Definition of security requirements/design” shall be included in the

requirements if a design should be tailored. Example/explanation of a description in specifications

Example of a description in specifications (1) As for the location of installation, “layout diagram for device

installation” and a “rack installation diagram” should be created- after conducting studies, etc.

(2) On-site investigations necessary for the installation of a power source and LAN cables shall be conducted. The on-site and other studies shall be conducted in accordance with the “system switching work plan” presented by the relevant authority to the relevant site.


If connecting to systems operated by other ministries is necessary, the contractor shall state to the effect that the network design will be formulated upon coordination with the relevant bureau of said ministries. In that case, the concerned parties shall be clearly specified for the coordination..

Notes on security Security design The contractor shall create a security design following the Standards for Information Security Measures for the Central Government Computer Systems and information security policies issued by each ministry. The contractor shall also take information security measures based on the security design.

432

4. Device installation work


To implement work on power source/ventilation work and emplacement/installation of devices


・ Working diagram, layout diagram for device installation, rack installation diagram, wiring diagram, and various other design documents concerning the existing system

・ Materials concerning power source usage Product (Prepared by the contractor)

・ Change documents concerning the result of works, including the working diagram, layout diagram for device installation, rack installation diagram, wiring diagram, and various other design documents


Requirements for emplacement and installation work shall be included. Conditions for emplacement and installation and requirements for necessary tasks shall be stated. A statement on the advisability and timing of system shutdown as prerequisites shall also be necessary. Responsibility boundary and necessity for curing of the emplacement and displacement may also be stated separately as prerequisites for work. [1. Basic requirements to be listed] ・ Works to be carried out in the installation of devices. ・ Prerequisites for installation [2. Requirements to be added depending on type/characteristics of project] ・ Specific conditions for the installation of devices ・ Working conditions ・ Physical connections of the network, such as LAN, etc.


Example of a description in specifications 1. Details of device installation The contractor shall carry out the following works for the installation of devices. (1) Emplacement/installation

A. Emplacement/installation work of procured devices B. Application for the emplacement/installation work of devices C. Necessary studies prior to the emplacement/installation of

devices D. Arranging components necessary for the

emplacement/installation E. Removal and disposal of the containers of devices, packing

and protective materials used for emplacement, and other materials that have become unnecessary after the completion of installation

F. Handling of damage caused by emplacement G. Appropriate anti-seismic work


In the case of a large-scale separated procurement project, the responsibility demarcation for installation/connection of devices, etc. may become unclear. Thus, the responsibility should be clarified in advance by, for example, creating a table of the division of roles.


433

5. Device setup


To implement network settings, software installation and settings, and of device settings and other tasks necessary for the connection with other systems based on the prescribed design documents., thus making the device ready for use.


・ Requirements for hardware, requirements for software, requirements for networks and requirements for operation and maintenance


・ Definition of environment


Requirements for settings and coordination work shall be specified to make installed devices usable. For the description, specifications shall include the necessary requirements for each project by clarifying the roles shared between the contractor of the relevant project and the contractors of other procurement projects. [1. Basic requirements to be listed] ・ Hardware settings ・ Software installation (Personnel in charge of

design/installation/setting for each piece of software should be clarified by, for example, creating a table of the division of roles)

・ Settings [2. Requirements to be added depending on type/characteristics of project] ・ Network settings ・ Connection with networks ・ Other necessary associated work, such as backup, etc.


Example of a description in specifications Device setup

(A) The contractor shall carry out hardware settings, software installation and settings, and network settings of deliverable devices in this procurement

(B) The contractor shall apply update programs with regard to software installed on the devices for this system and firmwares for the network devices. However, the propriety of the application shall be discussed before implementation.

(C) The contractor shall carry out network settings, various environmental settings, such as disk allocation, security settings, and install all deliverable software products, upon due coordination with the modification contractor.


In the case of a large-scale separated procurement project, the responsibility demarcation for the installation/connection of devices, etc. may become unclear. Thus, the responsibility should be clarified in advance by, for example, creating a table of the division of roles (see 6.7.5).

434

Notes on security Security settings/adjustment To carry out environment settings and adjustment work necessary for this system, using the procedures for the existing system, the installation procedures and the prepared security design documents.

Updating of virus definition file Virus software/virus definition files shall be updated to the newest version.

435

6. Operation verification/test


To perform operation verification tests on installed hardware, software and the network and provide support for tests performed by system developers.


・ List of items subject to operation verification ・ Information necessary to perform tests, such as coordination

policies with other functions


・ Test specifications ・ Report on test results (Operation test report)


To list inspections to be implemented as operation verification for installed devices and software and their requirements and targets. Documents to be presented by the procurer shall be specified, as well as any documents to be reported in response to the test results. [1. Basic requirements to be listed] ・ Subjects of the operation verification/test ・ Implementation and validation of the operation verification/test ・ Response to generated problems ・ Cooperation with concerned parties ・ Report on the operation verification/test [2. Requirements to be added depending on type/characteristics of project] ・ Tests to be performed (and details of support) and application in

case that the project requires integration with the existing system ・ To specifically clarify the division of roles with the operation

contractor, etc. Example/explanation of a description in specifications

Example of a description in specifications ○Operation/connection verification test

・ The contractor shall perform an operation verification test and connection verification test for devices of this system to verify the compliance with the specifications

・ The contractor shall perform system test of the relevant system in cooperation with the renewal contractor, after the introduction of devices for this system and the renewal of ___system separately procured by the relevant ministry. When defects attributable to this procurement are found in system test, the contractor shall analyze the cause and carry out the change in environment settings, and other necessary tasks until the system works properly.


Since items subject to operation verification and its details are different depending on the scale and system subject to connection, test requirements should be clarified in advance. When testing, cooperation with the application construction contractor may at times become necessary. Thus, the division of roles should be clarified beforehand.

436


437

7. Migration


To carry out migration of data, systems, and operations, etc. from the existing system (in the case of renewal that is not associated with the application change, etc.) or support for migration work carried out by the design/development contractor.


・ Outline of the types/volume and location of migrated data ・ Migration plan


・ Migration design ・ Report on the results of migration data validation


When the contractor carries out data migration, conditions for data transfer, etc. shall be described. When a system developer carries out data migration, service requirements for migration support shall be described. [1. Basic requirements to be listed] ・ Items subject to migration ・ Details of migration work ・ Details of support for migration work ・ Prerequisites for migration work ・ Conditions for migration work (possible working hours, possible

period of implementation, migration method, etc.) Example/explanation of a description in specifications

Example of a description in specifications ○Requirements for data migration The contractor shall implement migration work of data held in the existing system (A) The following make up the outline of the migration data. The

details will be presented by the Ministry after the conclusion of the contract.

(The rest is omitted.) (B) Following the migration, data verification shall be performed to

ensure the integrity of the migrated data and the results shall be reported as the “report on the results of migration data verification.”


The implementation body of migration shall be clearly decided in advance. When the contractor provides migration support, the scope of its support shall be clarified as much as possible.


438

8. Information provision to operation/maintenance contractors


To setup devices or software and provide information on procedures to a contractor which assumes operation and maintenance work. To provide information pertaining to device and software settings and operation procedures to a contractor in charge of operation and maintenance work.


・ Specifications for device management information exchange file


・ Device management information ・ Setting information ・ Manual


To select information to be handed over from device installation contractor to operation/maintenance contractor and to specify the procedures for information transfer. [1. Basic requirements to be listed] ・ Information to be transferred ・ Transfer procedures


○Information to be handed over Information on device management and setting information necessary for operation, monitoring and configuration management of the relevant system shall be put in a written document, which is then presented to the operation/maintenance contractor. An operation manual shall also be developed. ○Transfer procedures Prior to the installation of deliverable devices in the procurement, an explanation of operation procedures shall be given to the operation/maintenance contractor. After the installation of devices, the transfer to the operation/maintenance contractor shall be implemented. Suggestions for sure and effective ways to complete transfer procedures and other necessary matters should be presented.


All the information necessary for the operation/maintenance contractor should be handed over.


439



To implement system operation training for persons in charge of the system and other employees


・ Possible dates and locations of training ・ Number of expected trainees ・ Suggested training schedule (draft)


・ Training schedule ・ procedure documents ・ Textbook(s)


When the contractor provides persons in charge of the system and other employees with operation training, the trainees and method of training shall be specified. [1. Basic requirements to be listed] ・ Details of training ・ Method of implementation ・ Trainees ・ Textbook(s)


Example of a description in specifications ○Support for training, etc. After the verification test, training shall be provided for key personnel in regards to operation procedures, etc. of devices necessary for the operation of the relevant system. When using the relevant system, training for __(number) employees in charge of ___ is scheduled. The contractor shall create a textbook, assuming the IT proficiency level of expected trainees to be __. The textbook shall be made understandable using diagrams and charts, and be made available upon obtaining the approval of the persons in charge. A training schedule shall be prepared, considering the period until the commencement of the operation of the relevant system. Make-up days for cancelled classes shall be included in the training schedule.


The fact that users have differences in IT competency should be taken into account depending on the systems, whether it is for persons in charge of the system and other employees. Since users may express their dissatisfaction in the final phase (training scene), review by the users should be planned in each phase (when creating a screen image, when the system is nearly completed, etc.).


440

10. Acceptance


To prepare and deliver a necessary set of deliverables and handle the acceptance tests required by ministries.


・ List of deliverable products


・ A set of documents designated as deliverable products


To state that deliverables shall be ready for acceptance upon meeting the requirements for deliverable data, deliverable products and acceptance tests set forth by ministries. [1. Basic requirements to be listed] ・ Submission and approval of deliverable products ・ Response to and approval of acceptance tests [2. Requirements to be added depending on type/characteristics of project] ・ Setup of the items of the acceptance test


Example of a description in specifications ○Submission and approval of deliverable products The contractor shall prepare a set of documents necessary for acceptance and obtain approval. ○Meeting the requirements for, and approval of acceptance tests The contractor shall meet necessary requirements in accordance with the instructions of the relevant ministry with respect to acceptance test in preparation for the actual acceptance.


Reviews should be set up on an appropriate timing to prevent rejections at the time of acceptance.


441

6.7.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to deliverable

products. The official name of each product and its delivery deadline need to be listed in accordance

with the actual situation.


1. Master plan formulation Implementation plan Prior to the commencement of introduction work

2. Prior explanation /coordination with concerned parties

Materials for preliminary coordination/information session and minutes (draft in the case of support)

Prior to each work on an as needed basis

3. On-site investigation/design On-site investigation plan Prior to the commencement of on-site investigation

On-site investigation report Working diagram Layout diagram for device installation Rack installation diagram Wiring diagram Other design documents

Prior to the commencement of work at the introduction site

4. Device installation work Change documents for working documents for hardware and a set of software, layout diagram for device installation, rack installation diagram, wiring diagram, and other design documents

Until the date designated in the specifications

5. Device setup Environment definition After the setup of devices

6. Operation verification/test Test specifications Prior to the commencement of operation verification/test

Report on test results

After the implementation of operation verification/test

7. Migration Migration design Prior to the implementation of migration

Report on the results of migration data validation

After the implementation of migration

8. Provision of information/training for operator/maintenance contractor

Device management information Setting information Manual

Until the completion of the introduction work


Training schedule A range of procedure documents Textbook(s)

－

10. Acceptance A set of designated deliverable products

Date of acceptance

442

6.7.4. Suggested input The following table shows input and timing to be presented to the contractor (proposer) in advance.

The official name of each deliverable and its delivery deadline need to be listed in accordance with

the actual situation.


1. Master plan formulation Overall schedule Table of the division of roles


2. Prior explanation/coordination with concerned parties

Contact list for each center and concerned companies List of locations to which devices are introduced List of devices to be introduced


3. On-site investigation/design

Security guidelines prescribed by each ministry

Disclosed on the website, or during tender period

Working diagram Layout diagram for device installation Rack installation diagram Wiring diagram Other design documents (The above applies to the existing system)

During tender period

4. Device installation work

5. Device setup Requirements for hardware, requirements for software, requirements for networks, requirements for operation/maintenance

After the conclusion of a contract

6. Operation verification/test List of items to be verified Information necessary for the implementation of tests, such as coordination policies with other sets of devices


7. Migration Outline of type, volume and location of migration data Migration plan

After the completion of a contract

8. Provision of information/training for operator/maintenance contractor

Specifications for device management information exchange file



Possible dates/locations of training Included in procurement specifications or as an attachment at the time of tender publishing

10. Acceptance List of deliverable products Included in procurement specifications or as an attachment at the time of tender publishing

443

6.7.5. Division of roles




When considering procurement, services to be realized in the entire procurement should be identified.

A clear division of roles and services should be specified and a table of the division of roles should be

compiled so that the concerned parties can agree that there are no omissions/errors in services/roles

in the breakout procurement.

Example of the table of division of roles Main task ◎: Accountability

○: Responsibility for implementation

△: Confirmation

Ministry

Operator

Contractor

Developer

1. Master plan formulation ◎ ○ 2. Prior explanation/coordination with concerned parties

◎ ○

3. Onsite investigation/design ◎ ○ 4. Device installation work ◎ ○ 5. Device setup ◎ ○ 6. Operation verification/test ◎ ○ 7. Migration ◎ ○ 8. Information provision to operator/maintenance contractors

△ ◎ ○


◎ ○

10. Acceptance ◎ △ ○ △

444

6.8. Tasks incidental to procurement of iDC equipment

6.8.1. Definition of procurement area “Tasks incidental to procurement of iDC equipment” refers to the installation of various devices

prepared by the contractor in the facility to make them usable via the network environment, such as

cables and lines, and to the implementation of system operation monitoring and incidental services.

It corresponds to the one defined as operation technology in the procurement area and the main

tasks are planning, operation and maintenance, etc. Please refer to “5.3 iDC/Equipment” for

requirements/specifications for the functions/services of iDC equipment.

This section excludes services to procure equipment necessary for the operation of information

system devices (racks and cooling systems, etc.) since they are included in the procurement of

devices.


6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


445

6.8.2. Services to be listed in specifications 6.8.2.1 Typical service operations





specifications should be prepared by selecting appropriate items while coordinating them with the



Service items corresponding to

Guidelines for Information Disclosure concerning Data Center Security and Reliability

(1st ed.) by MIC

Chapter/section corresponding to Basic Guidelines for Procurement

(and its title)

1.Work plan Creation of implementation plan Scope of procurement Work flow Schedule, etc.

2.3.1 Preparation for initiation of quality assurance process

62.-68.Access control (requirements for building)

Chapter II (4) / (5) Chapter IV Chapter V Chapter VI

2.Implementation of work Work at the Data Center Cable lines-related work (when necessary)

3.2.2 Construction of environment

－ Chapter X, Chapter XI, Chapter XII Chapter V (5) 3.Preparation for initiation

of operation /maintenance

Creation of system operation Monitoring procedures Procedures for monitoring potential attacks Procedures for security diagnosis Formats of reports Formats of management registers Service requirements for SLA

3.2.1 (Environmental improvement) Preparation for process initiation

99. SLA

4.Operatation/ maintenance (daily)

Daily tasks (operations management, and maintenance management) Creation of daily report

1.7.4.1 System operation 1.7.4.2 Operation monitoring and collection of operation data, identification, recording and resolution of problems, improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 1.8.2 Comprehension and correction/analysis of problems 1.8.3 Correction

60. 24hours×7days/weekly monitoring 105.-109. Service notice/report 110.-112.Support service

5. Operation/ maintenance (weekly)

Weekly tasks (database backup, etc.)

Creation of weekly report 6. Operation/ maintenance (monthly)

Monthly tasks (security diagnosis, etc.) Creation of monthly report

7. Operation/ maintenance (irregularly)

The following services with respect to the work generated irregularly Details of work Creation of report

69.-70.Media storage

13 Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 14 The “Basic Guidelines for Government Procurement Related to Information Systems,” March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

446

6.8.2.2. Explanations and examples of descriptions in specifications concerning services 1. Work plan


To create an implementation plan for introduction work (adjustment of the Data Center equipment, cabling/wiring, device installation, etc.)


Establishment of the Data Center and a list of devices subject to operations management Requirements for the installation site System integration schedule


Implementation plan


To specify requirements for creating an implementation plan [1. Basic requirements to be listed] ・ Scope of procurement ・ Implementation framework ・ Work schedule, etc.


Examples of descriptions in specifications ○ Scope of procurement

The objective of the information systematization is to introduce professional services by installing server devices in the information system of the Ministry of ___, which includes power sources, ventilation system, anti-seismic measures and the prevention of physical intrusion, etc. for the safe operation of devices in the Ministry of ___. The scope of the procurement in this project shall be limited to the preparation for power equipment associated with device installation, anchoring devices for anti-seismic purposes, physical security measures for devices, and operations at the installation site, and shall exclude the following requirements.

(i) Procurement of goods such as server devices used by the Ministry of ___ and the incidental setup work

(ii) Monitoring of the information system on which the server devices used by the Ministry of ___ are operated.

○Implementation framework The following are the requirements in this section:

(i) The contractor shall establish an implementation framework to carry out this project.

(ii) Details of the implementation framework shall be clearly specified in terms of the roles of each team, division of work, and timing of team formation, etc.

(iii) The personnel in charge of the relevant services shall have qualifications related to project management or have equivalent knowledge, such as a Project Management

447

Professional (PMP). Qualification/knowledge necessary for the position shall be pursuant to the Basic Guidelines for Government Procurement Related to Information Systems of MIC.

(iv) The contractor shall formulate a schedule/organizational plan based on the necessary volume of work by selecting necessary items from work requirements stipulated in this specifications document, create the Work Breakdown Structure (WBS) and clarify the orders and dependency of work flows. The WBS is a table showing the entire project being divided into tasks.

○Work schedule (Schedule of implementation for commissioned work)

(i) Date M/D/Y: Completion of preparation for the Data Center (scheduled for installing devices)

(ii) Date M/D/Y: Commencement of test operations (iii) Date M/D/Y: Commencement of production operations (iv) Date M/D/Y: Completion of the relevant contract


(i) Since the scope of procurement is different in each system, there may be cases where internet connection and exclusive lines are not necessary.

(ii) The column of “example/explanation of a description in

specifications” does not include monitoring after the commencement of operations; however, there may be cases where only the work for the installation and commencement is procured.

(iii) In cases where multiple services are procured, when listing the

overall requirements (skills of staff, etc.), it is not desirable that the same description appears a number of times. Thus, the contractor shall consider how to describe them in the most effective way.

With respect to the consignment schedule, the scheduled date of device installation should be included in the presented system integration schedule, in view of the facility preparation at the Data Center.


448

2. Implementation of work


To carry out work at the Data Center (preparation for equipment, installation of devices). To carry out wiring-related work, etc. when necessary.


List of devices, network diagram (Details of device information to be installed, details of the types of cables/lines to be wired in the iDC and server/provider)

Products (Prepared by the contractor)

Report on the completion of work


To list requirements for the implementation of work [1. Basic requirements to be listed] ・ Preparation/coordination for the equipment in the Data Center ・ Support for device installation (cable connection, etc.) [2. Requirements to be added depending on type/characteristics of project] ・ Requirements for the implementation of wiring-related work


Example of a description in specifications ○Preparation/coordination for the equipment in the Data Center (1) Function composition

Among requirements listed in Chapter III, the procurement in this project applies to the “conditions for location, conditions for facility, conditions for machine rooms, conditions for power sources /ventilation, conditions for security, and conditions for operations” in the “iDC/equipment.” Other items shall be procured under a separate contract.

(2) Scale requirements The following is the number of devices requested by the Ministry of ___.

Information system devices, such as server, etc.: __ units Network devices, such as router and switch, etc.: __ units Racks: __ units

An operation room for the operators[ ___ persons (or __m2)] shall also be procured (the operation room and network wiring with the server shall be included in the scope of procurement)

Computer terminal desks: __ units Lockable cabinets: __ units

(3) Procurement work (i) Installation layout design(including rack installation)

A layout of the installation site for the information system devices to be installed in the Data Center shall be designed. When renting racks owned by the Data Center, a rack installation diagram shall be created based on the presented list of devices.

(ii) Power source connection design

449

With respect to the power source connection, the contractor shall create a “power/line connection diagram,” indicating the allocation and breaker, etc. When redundancy of power sources is necessary, the contractor shall consider the redundancy including a distribution board by, for example, supplying the distribution board in a separate system.

(iii) Equipment preparation The contractor shall prepare equipment based on the results of the “layout/power connection design,” such as anchoring devices for anti-seismic purposes/power source preparation work associated with rack installation.

(4) Requirements for implementation of work (i) The contractor shall manage the project management using the

WBS-based management method. (ii) The contractor shall propose a progress management method to the

relevant official of the Ministry of ___, with due consideration to the details of the work. The contractor shall also promote and manage the work in accordance with the progress management method verified by the relevant official of the Ministry of ___.

(iii) The contractor shall hold regular progress report sessions to give a briefing on the work status (plan, performance and the gap between them).

(iv) Consultation with the relevant official of the Ministry of ___ shall be conducted in Japanese and information materials and deliverable documents shall be written in Japanese.

(v) When changing the implementation framework, the contractor shall file a report to that effect to the relevant official of the Ministry of ___ and obtain confirmation.

○Support for device installation (cable connection, etc.)

(i) On-site presence when carrying in devices To secure a carrying-in route leading to the device installation site in the server room

(ii) Support for power source connection To give power connection instructions to and manage the installation contractor with respect to the connection of the distribution board to the power distribution unit (PDU) and the connection of the rack power distribution unit to the power cables of the devices.

(iii) Support for installation and connection of cables To prepare protective ducts/trays associated with the installation of LAN cables, fiber cables, and lines for external connections, etc.

○Requirements for implementation of wiring-related work (basic requirements)

(i) The contractor shall provide line-terminating devices. Routers and switches shall be brought in and installed by a hardware contractor which is separately procured.

450

(ii) Piping and power source work with respect to wiring into the administrative building ___ shall fall under the scope of the procurement.

(iii) The date of commencement of the use of the lines shall be on M/D/Y. Notes on characteristics of project/information system

(i) The installation work may change depending on whether the lines have already installed or not. With respect to the descriptions, in addition to specifying requirements for the work as described above, there is an option of having the contractor define the work items, instead of describing the elements, except for technical requirements. (ii) In the power connection design, devices requiring redundancy of power sources should be specified in the list of devices and instructions should be given to make sure that power will be supplied from a different distribution board. (iii) With respect to the installation of cables, there may be a risk of communications interruption due to mutual interference in an environment where a number of power cables and communication-related cables are run together. Thus, preparation for piping and trays to prevent interference should be requested. (iv) With respect to the piping and power source work in relation to wiring in the administrative building ____, the decision shall be made whether it is included in the scope of procurement depending on the condition of the installation site in the building (location under the contract, etc.).


451

3. Preparation for initiation of operation/maintenance


To create a procedure manual for system operation monitoring to be carried out by the operation contractor


List of system operation monitoring items


Procedures for system operation monitoring Report formats Communication flow chart


To connect a newly constructed/extended network with an existing network and to specify requirements for the implementation of migration or support work and items necessary for planning, etc.

[1. Basic requirements to be listed] ・ Creation of a procedure manual for system operation monitoring ・ Creation of report items/formats ・ Creation of management registers ・ Services related to Service Level Agreement (SLA)


Example of a description in specifications ○Creation of an operation manual

The contractor shall create an “operation manual” in cooperation with the system development/device delivery contractors and system operation support contractor. The following is the breakdown of the “operation manual.”

(i) Procedures for operation of monitoring environment The contractor shall specify a method of operating the system

operation monitoring environment and each monitoring procedure for the items listed in the list of monitoring items (node monitoring, process monitoring, etc.). The document shall cover the entire environment related to monitoring, such as monitoring screen and incidental devices (warning lights, etc.)

A method of response shall also be specified, such as reporting at the time of a detection of abnormality and a method of changing settings, such as monitoring items.

○Creation of reporting items/formats

The contractor shall decide on the details of reporting to the Ministry of ___ in cooperation with the Ministry of ___ with respect to the result of work, such as system operation monitoring/monitoring of attacks, and to create report formats. The contractor shall also create a request form for emergency work, in the same manner of cooperation.

(i) Decision on reporting items The contractor shall decide on reporting items (date, name of server,

452

event, etc.), reporting timing (daily, monthly, etc.), method of reporting (printed matter, electric data, such as email, etc.) and the recipient of report, based on the system operation monitoring items.

(ii) Creation of formats The contractor shall create a request form for emergency work and a form for reporting the items determined in (1). The report format to be created is roughly described as follows, which shall be further detailed depending on monitoring items: (a) Request for and report on emergency work, (b) System operation daily report, (c) System operation weekly report, (d) Attack status report (monthly), (e) Incident (abnormality)report, (f) System operation monthly report, and (g) Security diagnosis report (monthly).

○Creation of management register

The contractor shall create management registers concerning the matters to be installed, operated and managed in the iDC, in cooperation with the Ministry of ___.

(i) Management register (a) Hardware configuration management register (b) Network supply management register (c) Document management register (d) Backup media management register (e) Communication flow chart (f) Policies for measures against large-scale disaster/communication

structure ○ Services related to SLA

The contractor shall evaluate the status of achievement of SLA items on a monthly basis, and to report three-month results at the “service level briefing session” held every three months.


(i) When there is no existing network or ministerial system accommodated in the Data Center, cooperation with other contractors in charge of the existing network or system is deemed to be unnecessary for the creation of plans. However, the above examples are cited since there are existing systems in many procurement projects. (ii) The operation manual assumes the use of the equipment possessed by the iDC contractor for internet connection and firewall, etc. as a precondition. However, when the equipment is prepared separately by a related contractor, such as a network contractor, the items shall be defined in accordance with the consigned items. (iii) Response policies of the iDC contractor and a communication flow with the relevant official of the Ministry of ___ in the event of a large-scale

453

disaster shall be clarified. (iv) The frequency of Service Level Management (SLM) (evaluation items, reporting and review cycle, etc. regarding SLA) shall be determined with consideration to the level of importance of the system, although it is specified to be every three months in the “example/explanation of a description in specifications.” This is because the necessary costs for SLM may grow significantly if the number of items and frequencies is increased.

Notes on security

454

4. Operation/maintenance (daily)


Operations and maintenance tasks to be implemented and reported on a daily basis


Operation manual Procedures for monitoring security status


System operation daily report Incident (abnormality) report (only when an incident occurs)

Points to be described in specifications

To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be described] ・Daily tasks

(Equipment maintenance management, monitoring of system operation status, maintenance management, matters related to reporting)

・Creation of a system operation daily report Example/explanation of a description in specifications

Example of a description in specifications ○Daily tasks (i) Equipment maintenance management

The contractor shall monitor power source/ventilation equipment, disaster detection devices (smoke sensor, etc.), and surveillance cameras, etc. that have been provided as iDC equipment. The contractor shall conduct maintenance management of security devices for the access to the room and access control of visitors.

(ii) Operation status management The contractor shall monitor the items stipulated in “3. Preparation for initiation of operation/maintenance” in accordance with the operation manual (Examples of monitoring items)

Live monitoring of the system Process monitoring Event/message monitoring Capacity monitoring (The rest are omitted.)

(iii) Maintenance management The contractor shall carry out visual confirmation of lamps [LED (status display lamp), indicator display and device status display, etc.] by regular patrolling and monitoring the status of devices.

(iv) Matters related to reporting The contractor shall carry out reporting based on the prescribed communication/response method if defects are detected or

455

concerns outside the scope of the procedures are noticed during the daily operations.

○Creation of a system operation daily report To record the status of the above mentioned (i) and (ii) in the system operation daily report.


(i) When the daily report is deemed unnecessary due to the importance of the system accommodated in the Data Center, etc., this section may not be required. However, reporting on monthly basis is regarded as mandatory.

Notes on security Security monitoring The contractor shall report the security monitoring status (careful investigation of the firewall logs, monitoring of unauthorized access, etc.) and the monitoring results shall be periodically reported to the relevant official of the ministries.

456

5. Operation/maintenance (weekly)


Operations and maintenance tasks to be implemented and reported on a weekly basis

Weekly tasks (database backup, etc.) Creation of weekly report


Operation manual


System operation weekly report

Points to be described in specifications

To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be listed] ・Weekly tasks ・Creation of a system operation weekly report


Example of a description in specifications ○Weekly tasks

The contractor shall confirm the success of all the database backup jobs implemented on a weekly basis, and implement tape cleaning and media exchange. The contractor shall carry out reporting based on the prescribed communication and response method if defects are detected or concerns outside the scope of the procedures are noticed during the weekly operations.

○Creation of system operation weekly report

The contractor shall create a system operation weekly report with respect to the implementation status of the weekly tasks mentioned above.


(i) When a weekly report is deemed unnecessary due to the importance of the system accommodated in the Data Center, etc., this section may not be required. However, reporting on monthly basis is regarded as mandatory.


457

6. Operation/maintenance (monthly)


Operations and maintenance tasks to be implemented and reported on a monthly basis

Monthly tasks (security diagnostics, etc.) Creation of a monthly report


Operation manual Procedures for security diagnosis


System operation monthly report Report on security diagnosis


To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be described] ・Monthly tasks ・Creation of a monthly report


Examples of descriptions in specifications ○Monthly tasks (security diagnosis)

The contractor shall perform security diagnosis once a month, based on the security diagnosis procedures created in “3. Preparation for initiation of operation/maintenance.” The contractor shall organize diagnosis results (explanations on vulnerability, impact and response procedures) and create and submit a “security diagnosis report.”

○Creation of a system operation monthly report

The contractor shall create a security diagnosis report about the results of monthly operations mentioned above. The contractor shall organize the system operation/maintenance implementation status and indecent status of the relevant month and create a system operation monthly report.


(i) It is assumed that the SLA items shall, in principle, be specified; however, the SLA performance need not be reported if SLA is not specified, depending on the importance of the system, etc.

Notes on security Security diagnosis and reporting The contractor shall carry out periodical diagnosis on vulnerability and report its result (situation, impact, response method) to the relevant official of the ministry.

458

7. Operation/ maintenance (irregularly)


Operations and maintenance tasks to be implemented and reported on an irregular basis


Operation manual Request for and report on emergency work (section of request)


Request for and report on emergency work (section of report) Other reports on work results (no fixed format, etc.)


To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be listed] ・Details of work ・Creation of a report


Examples of descriptions in specifications ○Details of work

(1) Maintenance management (i) Regular maintenance

The contractor shall implement the reception and on-site presence of SE/CE for the regular maintenance of operations of installed devices, etc., necessary tasks prior to and after the work (server shutdown, restart), and confirmation of the completion of the maintenance work, etc.

(ii) Response to defects The contractor shall implement reporting for lap status confirmation/monitoring status and log data collection, at the time of occurrence of a defect, etc.

(2) Storage management The contractor shall implement the system change and system full backups after the maintenance / alteration work.

(3) Expendables management (i) Hardware management

The contractor shall perform acceptance operations/ renewal of management register in response to hardware addition/change

(ii) Media management The contractor shall receive new media from the concerned contractor, change to the new media, and renew the management register when replacement becomes necessary due to damage/degradation of the media

(4) Other (i) The contractor shall implement the reception of visitors to

the Data Center (leading visitors into the server room),

459

implement reception of other business operators, such as relevant officials of the ministry and the developer (guiding them to the place where racks are installed, etc.).

(ii) Sending and receiving of goods (consumables, etc.) The contractor shall handle the reception of goods sent from the relevant administrative officials, related contractors, and the external business operators concerning the system, or the shipment of goods.

(iii) Audit management The constructor shall implement audit acceptance/ response to inquiry slips when iDC becomes subject to various audits, including those of external organizations

(iv) Removal of devices When removing installed devices and racks or moving the Data Center, the contractor shall implement removal work in cooperation with concerned contractors, such as device procurement vendors; such work includes the removal of devices, unfastening of the fixed racks, retracting of the power cables and transfer of operation procedures.

(5) Response to references, etc. The contractor shall implement a lamp status confirmation, hardware installation status and response to inquiries/requests for information provision concerning iDC equipment/operation, such as inquiries about the Data Center equipment.

(6) Creation of report The contractor shall create a “request for and report on irregular work” with respect to the work result in accordance with the document of “request for and report on irregular work.” When other tasks are implemented, a report (no fixed format) shall be created on the result of the work.


(i) There may be cases where any kind of irregular tasks are to be carried out due to an unexpected event or extraordinary request from the ministry. Such tasks should be appropriately carried out in line with the operation/maintenance items, but may not be specified if it is deemed to be implementable within the scope of the regular work due to the characteristics of the system operation. (ii) When a regular audit is mandatory with respect to the audit management, the details and frequency of the audit shall be presented.


460

6.8.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware


in accordance with the actual situation. Service Deliverable product Delivery deadline

1.Work plan Implementation plan By five days prior to the commencement of work after the conclusion of the contract

2.Implementation of work Report on completion of work Within five days after the completion of work

3.Preparation for initiation of operation/maintenance

System operation monitoring procedures Communications-related documents Communication flow chart

At the time of formulating pre-operation documents (by the commencement of operation training)

4.Operation/maintenance (daily)

System operation daily report Incident (abnormality) report (only in the event of incident)

Every day after the commencement of operation

5.Operation/maintenance (weekly)

System operation weekly report Every week after the commencement of operation

6.Operation/maintenance (monthly)

System operation monthly report Security diagnosis report

Every month after the commencement of operation

7.Operation/maintenance (irregularly)

Request for and report on irregular work (section of request)

Within five days after the completion of work

6.8.4. Suggested input

The following table shows input and timing to be presented to the procurer (proposer) in advance.


actual situation. Service Input Timing for presenting input

1.Work plan

Establishment of Date Center and list of devices subject to operations management


Requirements for the of installation site


System integration schedule Included in procurement specifications or as an attachment at the time of tender publishing

2.Implementation of work List of devices and network diagram


3.Preparation for initiation of operation/maintenance

List of monitoring items of system operation


4.Operation/maintenance (daily)

Operation manual Security status monitoring procedures

―

5.Operation/maintenance (weekly)

Operation manual ―

6.Operation/maintenance (monthly)

Operation manual Security diagnosis procedures ―

7.Operation/maintenance (irregularly)

Request for and report on irregular work (section of report) ―

The following show the examples of suggested service level settings in iDC equipment. Items and

values should be used as a reference and should be determined in accordance with the importance

of individual projects and systems. The contractor should clearly prescribe the level of the quality of

services to be provided by setting the SLA, which is the result of consensus between the procurer

(the Ministry of ___) and the provider (iDC contractor), and carry out maintenance and management

461

of the service level in accordance with the SLM. The SLA has two approaches: guaranteed-goal

oriented approach and effort-oriented approach, either of which should be applied to each item.

Examples of service level settings for iCD equipment are listed below. Items and values should be

used as a reference and should be determined in accordance with the importance of individual

projects and systems.

Item

number Classification Service level

items Details of regulations Unit Example of service level settings

1-1 Availability Service hours Hours in which iDC equipment is provided

Time Defining service hours (set by the type of service) Examples of the service type:

・Power supply ・Operation service ・Operation monitoring

Examples of time setting ・24 hours×7 days/week

(Excluding planned shutdown plan/ regular maintenance)

・9:00-17:00 Notice of a service shutdown (when a shutdown occurs during service hours, time of planned shutdown shall be set by the provider on an individual case basis, and a prior announcement of the planned shutdown shall be stipulated.)

1-2

Service availability

Availability (power supply) － weld time／service time

Availability To manage continuity of power supply to installed devices. At least 99.8% availability, etc. However, if redundant power source is installed, a judgment basis for supply disruption should be defined.

1-3 Availability (installation environment) － provision time within management range/ service time

Availability By setting server room management temperature and humidity (24ºC±4ºC), the temperature and humidity shall be controlled within the range. The operations shall be carried out within the management range. Example of the setting: To be controlled between an upper limit and a lower limit at a 99.5% level of confidence.

1-4 Availability (network) － network operating time／scheduled network operating time (service time)

Availability To define availability concerning the network procured as iDC equipment. At least 99.9% availability, etc.

1-5 Availability － monitoring service provision time／scheduled monitoring service provision time (service time)

Availability To define system availability concerning various monitoring environments procured as iDC environment. At least 99.5% availability, etc.

2-1 Reliability Number of operator staff

Number of staff engaged in the relevant system

Staff number

To define the number of staff when constructing operation system exclusive for the system to be procured

2-1 Accuracy Error rate per operator (operation other than procedures)

Error rate (%)

To define the number of operation errors and typographical errors, etc. with respect to the details of the statement of operation procedures. Setting the parameter should be careful when defining the error rate, instead of defining the frequency.

2-3 Operator staff Number of training sessions for operator

Number of training sessions

To define the number of training sessions for operators about ISO-related matters and security policies: for example, 8 hours every 6 months.

462

Item

number Classification Service level items Details of regulations Unit Example of service level settings

2-4 Reliability Defect notification process/ notification time

Setting a communication process at the time of occurrence of a defect (recipient of notification/method/path) and time spent on notification to prescribed recipients based on the communication process ・Method of notification － phone call, e-mail, website ・Example of recipient of notification － procurer receiving the provision of services －Owner of services (in cases where services are outsourced)

Presence or absence

Time

・To contact designated emergency contact persons by e-mail/phone call and post notification on the website ・To set notification time suitable for the recipient of notification ・Settings suitable for the service level within/outside of business hours To implement the SLA settings taking the three points above into account. The following are the possible cases: Case 1 Notification of defect within business hours to procurers who receive service provision or service owner by phone call or e-mail (e.g. within one minute in the case of automatic notification system. within five minutes in the case of person to person contact) Case 2 Notification of defect outside of business hours to procurers who receive service provision or service owner by phone call or e-mail (e.g. within one minute in the case of automatic notification system. within 10 minutes in the case of person to person contact) Case 3 Defect occurrence report on the website for the procurers who receive service provision and target posting time (posting the time of occurrence, and expected time of recovery on the website within 30 minutes after the defect occurrence)

2-5 Defect monitoring interval

Collection of defect incidents/interval of aggregation (Frequency of confirmation of operation status of devices)

Time There are cases where settings are different between within and outside of business hours. Within one minute (core business) Fifteen minutes (other than the above)

463

6.8.5. Division of roles This section introduces an example of the division of roles between the hardware maintenance

contractor, ministries and procurement contractors of other operations.








(Specification for “A set of Data Center Borrowings, etc.” Ministry of xx, April 2010)

○Division of roles with other contractors, etc.

(1) Technical support and information provision, etc.

A. Information provision for understanding of progress

When being indicated or a request is made for information provision for understanding of

progress, the contractor shall take appropriate response in line with consultation with the

Ministry of ___.

B. Advice on the appropriate use of deliverable products

The contractor shall give answers and advice on inquires on appropriate and effective use of

deliverable products in this procurement.

C. Support for approaches to system audit

When system audit on the deliverable products in this procurement is to be carried out, the

contractor shall proactively offer technical support and information.

(2) Coordination with concerned parties

A. Coordination with concerned companies

The contractor shall gain approval of the Ministry of ___ about requests to or coordination

with the contractors of design, development and test, migration and operation

commencement of this system (hereinafter referred to as “system integration companies),

the contractor of operation monitoring management of this system (hereinafter referred to as

“operation contractor”), and the contractors of other procurement projects associated with

this system (___ subsystem server maintenance contractor) and any other hardware

maintenance contractors, hereinafter referred to as “the concerned contractors”) prior to the

implementation.

B. Coordination with external concerned parties

The contractor shall consult with the Ministry of ___ with respect to requests to or

coordination with companies on other systems involved with this system (operators of the

existing systems, etc., hereinafter referred to as “external concerned companies”). The

464

contractor shall also make necessary adjustments and coordination.

(3) Division of roles

The following are the examples of a division of roles in installation work (1. Work plan – 3.

Preparation for initiation of operation /maintenance) and product operation (4. Operation/

maintenance (daily) – 6. Operation Maintenance (irregularly), removal work (7. Removal work).

A. Installation work

○: Main operator in charge, △: Support, advice Work item Supervisory

section Maintenance contractor

Operator Network contractor

iDC contractor

System integration contractor

Device procurement contractor

Development/presentation of input information ○ △ △ △ △

Creation of WBS concerning iDC equipment ○

Regular briefing session △ ○ Creation of layout of server room installation ○

Creation of rack installation diagram (*1) ○

Creation of power connection diagram ○

Anti-seismic rack anchoring work (standard rack preparation (*1))

○

Power source preparation work ○

Device emplacement work ○ Presence at the emplacement site (instruction of installation locations)

○

Preparation for equipment related to cables (*2) ○

Device installation ○ Cable connection work ○ ○ Support for connection work (instruction on connection targets, FA under-floor work, etc.)

○

Preparation for operation monitoring environment (*3) ○

Creation of operation monitoring procedures (*3) ○

Operation acceptance training △ ○

Guidance on acceptance training ○ ○

*1: Division of roles when using racks provided by the iDC contractor is described.

In cases where a device procurement contractor is supposed to prepare racks, the procurement

contractor must create and prepare the racks.

*2: “Equipment related to cables” refers to preparation for rosette for metallic cables, protection duct

for optical lines, and protection duct (or tray) for LAN cable, etc.

*3: “Preparation for operation monitoring environment” refers to the division of work in the case of

using an operation monitoring environment for the iDC. When the monitoring environment is to be

constructed by the related contractor, such as system by a development vendor, etc., the division

of work should be further detailed separately.

465

B. Operation work

○: Main operator in charge, △: Support, advice Work item Supervisory

section Maintenance contractor

Operator Helpdesk contractor

Network contractor

iDC contractor

Device procurement contractor

Development/presentation of input information ○ △ △ △ △

Operations (daily, weekly, monthly, irregularly) *On-site work

△ ○

Operations ○ △ Creation of a report ○ Defect detection/ report △ △ △ △ ○ Implementation of countermeasures against defect

○ ○ ○ ○

Handling of visitors, such as maintenance vendor ○

Media management ○ Maintenance management of equipment (power sources/ventilation, etc.)

○

Server room monitoring *Surveillance cameras,,

access control devices, etc.

○

Reporting abnormality in the server room △ ○

Inquiries from users ○

466

6.9. Network procurement

6.9.1. Definition of procurement area Services of network procurement refer to (1) services related to network construction for LAN

and WAN, etc.(services associated with network construction) or (2) services related to the procurement of such services as a wide area network or internet connection, etc., including WAN (services associated with communication service procurement).

In terms of procurement pattern from the viewpoint of the technical domain, both network

construction and network service procurement correspond to the category defined as WAN design /

construction and ministerial LAN design/construction, covering such services as planning, design,

work, operation and maintenance, etc. On the other hand, in the actual procurement, network

procurement is often carried out concomitantly with server and software procurement of groupware

and file sharing applications; however, this section does not deal with procurement of applications.


6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


467

6.9.2. Services associated with network construction 6.9.2.1. Services to be listed in specifications 6.9.2.1.1. Typical service operations The following table shows services to be included in the specifications. The corresponding




specifications should be prepared by selecting appropriate items while coordinating them with the


(1) Services for conducting network procurement associated with construction (construction of

ministerial LAN and WAN construction and connection, etc.)



BGP 1.Design/development plan

To create a draft plan equivalent to the “Plan of design/development phase” in the Guidelines for Business/System Optimization” To create design/development implementation framework and roles, detailed work and schedule


Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII Chapter XIII

2.Design/development Network design, development, work, and unit test (excluding hardware procurement for network devices)

1.6.1 Preparation for process initiation 1.6.3System architecture design 3.2.2Environment construction

3.Migration plan Planning of work necessary for migration of the existing users to the newly constructed network

1.7.3.2 Documentation and validation of migration plan 1.7.3.3 Notification of the migration plan to all the concerned parties

Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII (2). (4) Chapter XIII

4.Suppor for test and migration judgment

Implementation of tests before handing the system over to the user to verify that the new network will operate as designed

1.6.13 Software acceptance test 1.7.1.8 Formulation of an operation test plan 1.7.2 Operation test

5.Migration Implementation of migration

1.7.3.5 Notification of migration to all the concerned parties 1.7.3.6 Review for migration assessment

6.Operation/maintenance plan

Institutionalization for operation/ maintenance, operation design and organization of documents

1.7.1.3 Establishment of problem management procedures 1.7.1.4 Preliminary coordination for system operation and establishment of work procedures

Chapter II (4), (5) Chapter V (5) Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI

15 Software Life Cycle Process-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 16 The “Basic Guidelines for Government Procurement Related to Information Systems,” March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf

468



BGP 1.7.1.8 Establishment of work procedures for business operation 1.8.1.2 Creation of a plan and procedures

Chapter XII (3). (4) Chapter XIII

7.Operation/maintenance work

Implementation of operation/maintenance and reporting of operation status in response to the result of the operation/ maintenance plan

1.7.4 System operation 1.7.4.1 System operation 1.7.4.2 Operation monitoring and collection of operation data, identification, recording and resolution of problems, improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 1.8.2 Problem identification and modification analysis

469

6.9.2.1.2. Explanations and examples of descriptions in specifications concerning services 1. Design/development plan


To support creation of a document equivalent to the “plan for design /development phase” in the Guidelines for Business/System Optimization


・ Development schedule ・ Views of ministries through interviews, etc. ・ Ministerial security policies ・ User organizations (centers) in which the systems are deployed.


・ Documents pertaining to support for the formulation of a design development plan


To specify the items to be conducted by the contractor with respect to the support of creating a plan for the design/development phase [1.Requirements to be described] ○Support for creating a plan for the design/development phase [2. Requirements to be added depending on type/characteristics of project]


Specifications of procurement requirements to be basically described ○Support for creating a plan for the design/development phase The contractor shall provide support for creating a plan for the design /development phase to be formulated by the Ministry of ___. ・Organizations using the introduced system

User organizations that will introduce the system in this procurement shall be those designated in the “Band and Period of Use of the Organizations Using the Network Connections” ・Boundary of responsibility concerning this procurement

The scope of responsibility in this procurement covers the network devices installed by the contractor in the user organizations and centers.


The plan for the design/development phase designated as a deliverable product in this service is equivalent to the “plan for the design/development phase” in the optimization guideline. Although the optimization guideline does not require a creation of the relevant product at the time of expansion, the relevant product should still be created in the case of a large-scale expansion due to the necessity of reaching consensus among concerned parties.

There may be cases where further detailing of definition requirements is outsourced at the design phase. Please see “6.2.2. Support for the definition of requirements phase” for the details.

Notes on security Information security measures in accordance with the importance and risks involved in the information assets shall be specifically defined pursuant to the information security policies of each ministry based on the Standards for Information Security Measures for the Central Government Computer Systems.

470

2. Design/development


In charge of design, architecture, construction, unit tests of the network


・ Basic requirements for input data references, implementation framework and project management policies, communications with key personnel, boundary of responsibility with concerned parties, etc. that are necessary for design/development.

・ User organizations (centers) in which the system are deployed ・ Existing environment (network diagram, etc.) ・ Network information of superior organizations to be connected (if

necessary) ・ Physical prerequisites of the locations where devices are to be installed ・ Technical requirements necessary for network design/development ・ Definition of service level items (if necessary)

Product(Prepared by the contractor)

・ Implementation plan for design/development ・ Basic design

・Physical design ・Logical design ・Reliability design ・Line design/external connection design ・Security design

・ Detailed design ・ Work diagram and device installation diagram ・ Connection specifications ・ Setting document


To specify matters to be carried out by the contractor with respect to network design/construction [1.Basic requirements to be listed] ○Details of an implementation plan for design/development ○Requirements to be met by the design/development contractor (skills,

etc.) (if necessary) ○Details of designs (basic design, detailed design, connection design)

－To include items to be discussed (detailed setting items. LAN/WAN connection design items, items to be coordinated with individual systems, etc.)

○Details of development －To include notes and requirements for implementing development

work －To include requirements for performing tests

[2. Requirements to be added depending on type/characteristics of project] ○If there are matters to be coordinated with LAN/WAN connection design or

individual systems, etc., the details of procurement of such work shall be specified.

○If removal/disposal of existing equipment and devices is necessary, requirements for such work shall be included.

471


Example of descriptions of basic requirements to be specified ○Details of implementation plan for design/development (1) The contractor shall create an implementation plan for

design/development which includes an implementation framework of design/development and roles, detailed definition of work and schedule, development environment, development method and development tools, etc., while seeking coordination with the Ministry of ___.

(2) The contractor shall carry out design/development work in line with the implementation plan for design/development and shall report the results.

○Requirements to be met by design/construction contractor The manager of design/construction work in this procurement shall meet the following requirements. 《Note: The following describes the requirements for experience in services equivalent to the relevant service, a list of qualifications for an individual or person having a capacity equivalent to the qualifications, and the qualification requirements for an organization. If only persons with qualifications can work due to legal reasons, participation of a qualified person is mandatory whether or not such description is given. Specific details are omitted.》 ○Details of designing (1) Basic design

The contractor shall describe the logical configuration and physical configuration, etc. in the basic design after determining specific network services and devices following the final confirmation of requirements for this procurement. Equipment in the center necessary for operation/ maintenance shall also be designed. When designing, the contents shall be consistent throughout the entire network to avoid inconsistency with the existing network which will continue to be used. The following are matters described in the basic design. (Details are omitted.)

A. Equipment design (designation of target range) B. Design of IP address (domain design) C. Routing design D. Physical configuration design (designation of target range) E. Logical configuration design (network topology, etc.) F. Line configuration design (backbone line, interchange circuit, access

line) G. Design based on the security policy (encryption, FW, IDS/IPS,

quarantine) H. Encryption design (encryption specifications, encryption method,

encryption algorithm) I. Bandwidth reservation design (bandwidth control specifications,

bandwidth control method)

472

Item Description J. Quarantine system design (quarantine specifications, quarantine

method) (2) Detailed design

The details of setting and setting policies and reasons shall be described in the detailed design with respect to major setting items of devices operated in the relevant network based on the basic design. The following are matters implemented in the detailed design. Items related to server, etc. which is operated together with the network are also described here. (Please also refer to “6.7 Tasks incidental to procurement of devices.”) (Details are omitted.)

A. Parameter design for network monitoring (network monitoring parameters, server monitoring parameters)

B. Parameter design for network devices (setting values for routers, switches, etc.)

C. Detailed design for server devices (configuration of server (redundancy configuration, etc.), storage configuration, software functions (OS, middleware, etc.) and parameter design

D. Parameter design for security services (quarantine, etc.) (3) Connection design

Physical configuration and setting conditions, etc. shall be clarified in the connection design for the connection with concerned departments, equipment and concerned systems. The following are items to be determined in the connection design. (Details are omitted.) i) Information center

A. A method of acceptance for provided services of the existing network operated by the existing operation and maintenance contractor, which will continue to be used.

B. Interface specifications C. IP address (domain, etc.) D. Routing design E. Security policy design (filtering conditions) F. Encryption design (encryption range): introduction of encryption with

appropriate level of strength based on the government’s guidelines G. Equipment specifications concerning installation and operation

ii) ___ System A. The method of the provision of services B. Interface specifications C. IP address (domain, etc.) D. Routing design (allocation of communication paths to the

business-oriented network and the information-oriented network) E. Quarantine system design (presence or absence of the quarantine

application, scope of quarantine, information on devices subject to quarantine)

F. Firewall/IDS/IPS design G. Equipment specifications concerning the network connection of this

473

Item Description system

○Details of development

The contractor shall carry out specific construction work based on the applicable design contents. The contractor shall also compile these contents into the products concerning design/construction.

The following are matters implemented in the development work. (Details are omitted.) (1) Items of construction work

A. Line installation B. Device emplacement/fitting C. Equipment adjustment (unit test) D. Device setting/construction

(2) Line installation, device emplacement/fitting The contractor shall carry out line installation, device emplacement,

installation and operation verification at the user organization’s location to which the network is connected. The contractor shall provide support for inquires about verification tests conducted by the user after the completion of migration.

Examples of requirements to be added depending on type / characteristics of project ○ Examples of listing LAN/WAN connection design and adjustment with individual systems, etc. (1) Existing system user organizations There will be in principle no installation work in the existing system user organization since the speed of the existing line will be increased (instead of installing a new line). (2) Newly connected system user organizations 《Note: Prerequisites and conditions for design and construction shall be specified with respect to the following items, etc.》・Securing of site, securing of power source equipment ・Implementation of preparation, installation, securing of power source, and installation of cables running in conduits and devices, etc. ・Coordination with the managers of user organizations and management companies of the relevant LAN ・Prerequisites

The following are the physical prerequisites for the installation of devices in each user organization. In the case of user organizations, etc. which cannot adopt the following conditions, the contractor shall carry out the installation upon coordination with the relevant personnel and user organization in accordance with the actual situation of the user organization, etc.

(1) Power source conditions -omitted (2) Ventilation conditions -omitted

474

Item Description (3) Installation conditions -omitted

・Specifications of network requirements (Details are omitted.) The area shall be divided into the WAN environment and the center connection environment and detailed requirements for specifications shall be presented based on the network configuration described here (with configuration diagram).

(1) WAN environment ・ Communications protocol and routing method ・ Bandwidth reservation ・ Security requirements

The contractor shall take measures in line with the “information security policies of the Ministry of ___.” (2) Center connection environment (an environment that connects the new and existing centers via WAN cables, such as wide area Ethernet) ・ Communications protocol and routing system ・ Security requirements If there are matters to be cooperated specifically with the existing operation and maintenance contractor, etc. (method of sharing security information, test methods, emergency measures, etc.), such cooperation shall be described.

○Examples of requirements for removal and disposal of devices (1). Removal and displacement work (details are omitted.)

Details of work shall be presented. ・ Removal of unnecessary devices ・ Removal of related cables and lines ・ Clarification of objects not to be removed ・ Concept of bearing expenditures necessary for removal,

displacement and disposal (including protective materials, equipment and vehicles, etc.)

・ Creation of a work schedule concerning the dates and frequency of removal/displacement

・ Implementation of necessary protective work (2). Data deletion

A. The contractor shall carry out coordination, etc. concerning data deletion upon gaining approval of the relevant official.

B. Data shall be completely deleted so as not to be restored by a third party by using data restoration software, etc., once unnecessary devices have been removed and displaced.

C. The contractor shall, at its expense and responsibility, prepare places and devices necessary for the data deletion. The contractor shall take strict security measures to prevent information leakage from the unnecessary devices throughout the process, from the removal and displacement of the unnecessary devices to the deletion of data. However, this does not apply if the work is carried out within the

475

Item Description Ministry.

D. Following the completion of data deletion, the contractor shall submit certification of data deletion to the relevant official.

(3). Disposal (Details are omitted.) The contractor shall present the details of work and methods.

A. The contractor shall observe disposal-related laws and regulations. The work may be re-entrusted (only with notification and approval of the relevant ministry in advance).

B. The contractor shall submit the certificate of the completion of disposal after the completion of disposal.

C. In the case data deletion work, except for cases of destroying unnecessary devices, if the device is re-commissioned, an approval of the relevant official shall be obtained in advance.

D. The Ministry is entitled to carry out inspections of the work. E. The devices may be re-used as used devices. However, an approval

shall be obtained in advance. Notes on characteristics of a project/information system

・ Requirements for a connection with an existing system under given operating conditions shall be appropriately detailed.If there is an existing system to be connected, requirements shall be appropriately specified because it will be in given environmental conditions.

・ If there is an existing network operator, the details of cooperation and conditions shall be appropriately stipulated.

・ The examples of descriptions assume a off-site implementation of data deletion work. However, on-site data deletion should be considered since taking data out of the premise is highly risky under current circumstances.

・ If it is necessary for the proposer to understand the detailed requirements, such as technical requirements and constraints, such statements shall also be included. －User organizations (centers) in which the systems are deployed, or

the existing environment －Boundary of responsibility for the procurement －Physical prerequisites in the location where devices, etc. are to be

installed. Notes on security In light of the importance of security, the following requirements / conditions

(if any) shall be specified. Information security requirements (measures) The contractor shall take comprehensive security measures, observe

security policies and security guidelines issued by the Ministry in order to carry out comprehensive measures recognized as security measures by the market. For operations, the contractor shall maintain the security level. With respect to the security measures to be taken by the entire network, cooperation and coordination shall be taken with the existing operator/maintenance controctor

Disposal of devices Except for when destroying unnecessary devices, data shall be

476

Item Description completely deleted so as not to be restored by a third party by using data restoration software, etc., once disposal devices have been removed and displaced.

Security design The contractor shall either carry out design work, such as security

policy design (encryption, FW, IDS/IPS, quarantine) and encription design (encryption specifications, encription method, encription algorithm), etc. or follow the regulations presented together with the specificaitons.

Security inpsection A vulnerability of network devices to be introduced may be identified

and disclosed by a third organization, etc. Problems (if any) shall be appropriately addressed.

477

3. Migration plan


To formulate a plan of work necessary for the migration to a newly constructed network.


・ Migration conditions (constraints, etc.) ・ Expected migration work flow


(1) Migration implementation plan ・Migration schedule ・Communication method during migration ・Migration criteria, etc.

(2) Migration procedures Matters to be described in specifications

The contractor shall specify requirements for the implementation of or support for migration work through the connection of a newly constructed or extended network to the existing network, as well as items necessary for planning, etc. [1. Basic requirements to be listed]

○Policies and requirements for migration ○Details of the formulation of a migration plan


Example /explanation of a description in specifications

Examples of basic items ○Policies/requirement for migration (Details are omitted.)

A. Flexible plan B. Ensuring stable operation and business continuity F. Prompt support for an application connection test, etc. conducted by the

user. The procurer shall make requests for the support from the existing operation/maintenance contractor, if necessary.

B. Formulation of migration procedures for the manager of the individual system and migration procedures for the manager of the user organization

C. Scope of approval from the relevant official and confirmation from the existing operation/maintenance contractor, upon consultation with concerned parties

○Details of the formulation of a migration plan The contractor shall formulate a migration plan with respect to the following items in order to solidly implement migration in a planned manner.

A. Migration implementation framework and roles of migration-related companies and contractor

B. Detailed work and schedule for migration C. Migration environment D. Migration method

478

Item Description Notes on characteristics of a project/information system

In cases of a large-scale separate procurement project, the responsibility demarcation may become unclear. Thus, the responsibilities should be clarified in advance by, for example, creating a table of the division of roles. In cases of a large-scale network covering a multiple number of center’s equipment, the installation and connection of termination units may be conducted simultaneously with the migration following the unit and system tests for the equipment of each center. In that case, it may become closer to reality if the items of “line installation, device emplacement/fitting work” in the previous section in the design/construction are included as part of the migration services in this section and the next section.


479

4. Support for test and migration judgment


To implement a set of tests before submitting the system to the user in order to confirm that the new network will operate as designed.


・Implementation requirements for tests ・Outline of acceptance test (performed by the procurer) ・Migration criteria (or criteria for the acceptance test)


・Test procedures ・Test plan ・Report on test results


Provision of services covering from planning to implementation of tests is requested. For details of the test, major test items (draft) to be implemented shall be specified. [1.Basic requirements to be listed] ○Creation of a test plan ○Implementation of test (stating the details of implementation) ○Implementation of progress/issue management ○Report on results ○Support for acceptance test [2. Requirements to be added depending on type/characteristics of project] ○Support for the judgment on switching to a new system and discussion on the possibility of full-fledged operation


Examples of basic requirements to be described ○Creation of a test plan

The contractor shall create a test implementation plan describing the test framework, detailed tasks and schedule, test environment, test tools and acceptance criteria, etc.

○Implementation of test (description of the implementation details) The contractor shall carry out tests on the new system with respect to the following contents and verify that the system will operate as designed. (Details of tests are omitted.) ・Inter-center test ・Connection test with the business system ・Information security verification test ・Comprehensive test ・Support for operation test (acceptance test, user test)

○Implementation of progress/issue management The contractor shall present management/reporting rules with respect to the progress of tests based on the test plan and operation tasks before the commencement of the tests and gain approval of the Ministry of ___. Consequently, the contractor shall conduct management/reporting in compliance with these rules. ○Report on results The contractor shall compile the test results into a “report on test results” and gain approval from the Ministry of___.

480

Item Description ○Support for acceptance test After the completion of the comprehensive test, etc. conducted by the contractor, etc., the Ministry of ___ shall carry out an acceptance test in order to verify that the new system conforms to requirements. The contractor shall provide support for creating an implementation plan for the acceptance test and acceptance test specifications formulated by the Ministry of ___, as well as support for implementing the acceptance test. ・Other (1) If the use of the data, etc. of the existing system is deemed necessary for

the tests, the contractor shall make a request to that effect to the Ministry of ___. The Ministry of ___ provides the data, etc. only when it is concluded that there is good reason to do so. The contractor shall handle the provided data, etc. with care.

(2) The contractor shall prepare necessary devices and communication lines, etc. for the tests.

Cases where support for migration judgment is defined as service requirement ○Support for migration judgment Migration judgment is a final decision made by the new network side and related individual system’s side as to whether or not to make a conversion to the new network. To that end, the contractor shall implement the following work based on the instructions of the relevant official, in cooperation with the existing operation/maintenance contractor.

A. The contractor shall provide support for the creation of migration criteria that include work status, matters of concern, and verification items for the xx system, etc.

B. Based on the migration criteria, the contractor shall hold a “migration judgment conference” attended by the relevant official, the existing operation and maintenance contractor, the relevant contractor, the PMO, and personnel in charge of the management of individual systems, with an aim to reach a consensus on the finalization of the “migration criteria” and on a conversion to a new network of the xx system.

Notes on characteristics of a project/ information system

3. Refer to design / development

Notes on security The contractor shall thoroughly implement tests for information security. A vulnerability of the network devices to be installed may be identified and disclosed by a third organization, etc. Problems (if any) shall be appropriately addressed.

481

5. Migration Item Description

Outline of service operations

To carry out migration


・Division of roles between the procurer and the contractor


・Report on migration results


Migration policies, requirements and implementing items shall be described. [1. Basic requirements to be listed]

○Policies for migration implementation ○Details of migration work


Example / explanation of a description in specifications

Examples of specifications of migration work associated with inter-organization network connections, such as centers and introducing organizations ○Policies on migration implementation

A. If the work is suspended due to a failure, etc. during the migration, an initial report shall be made to the concerned parties that may be influenced. The procedures shall be in line with the reporting procedures formulated in the plan.

B. When a problem in the existing system occurs through the connection to the network, the concerned parties shall cooperate in the investigation of the cause. If dispatch of staff to the user organization, etc., is deemed necessary, the arrangement and coordination shall be made with the user organization.

C. In the cases where it is expected that migration/installation may have an impact on the individual systems under operation, etc., the relevant official and manager of the individual systems shall be informed in advance.

D. After the completion of migration/installation, the contractor shall inform the key personnel of the user organization about the completion of work, as well as inform the relevant official and the existing operation/maintenance contractor.

E. Expected main business flow is as described in the reference document. If change in the business flow is deemed necessary for the purpose of efficiency, etc., approval of the relevant official shall be obtained.

○Details of migration work Notes on characteristics of a project/information system

・ In cases of extension of the existing line, the contractor shall consider including such tasks as reporting to the existing operation/maintenance contractor, etc. since use in combination with the existing system is important.

・ The details of the description shall be arranged in accordance with the actual situation, such as the scale of the procured network and the presence or absence of the existing system.

482

Item Description Notes on security

－

6. Operation / maintenance plan


To carry out establishment of the framework, operation design and documents for operation/maintenance. (The network-related maintenance does not generally require specific knowledge and experience; rather, it is deemed more effective to integrate the network maintenance into the operation.)


・Period of introduction/ operation, etc., loan period and payment period ・Configuration management items ・ Configuration management document format ・Security policies concerning network operation ・Operation/ maintenance security manual


・Outline of operation / maintenance ・Operation design ・Operation manual ・Manual for key personnel of the user organization and the manager of individual systems ・Configuration management system or manual ・ Service Level Agreement (SLA) ・ Service level management plan


To list items and service requirements for the preparation of initiation of operation/maintenance [1. Basic requirements to be listed] ○ Requirements to be met by the operation/maintenance contractor ○ Basic requirements for operation/maintenance ○Implementation of operation/maintenance design

－Operation design －Creation of configuration management (host name, IP address,

etc.) and a manual for personnel in charge of maintenance －Formulation of a service level management plan

○Framework and division of roles in operation/maintenance [2. Requirements to be added depending on type/characteristics of project] ○Transfer from the existing operator

483

Item Description Example / explanation of a description in specifications

Examples of descriptions of basic items ○Requirements to be met by the operation/maintenance contractor

The following requirements shall be met by the manager of operation/maintenance work in this procurement. (5). Security manager

Personnel in charge of security management in this procurement shall meet the following requirements.

A. A person with experience in planning and implementing measures to maintain information security and evaluating the results.

○Basic requirements for operation/maintenance (1) Establishment of a stable and efficient system operation/ maintenance infrastructure

A. Since the operation/maintenance of the overall network is implemented by the existing operation/maintenance contractor, the contractor shall follow the instructions given by the relevant official or the procurement office and act in accordance with the advice of the existing operation/maintenance contractor which assumes the role of an administrator of operation / maintenance.

(Details are omitted.) (2) Provision of high quality user support

A. The offices providing user support for the relevant procurement will be consolidated into one contact point which is managed by the existing operation/maintenance contractor to facilitate the convenience of the users. The contractor shall act accordingly.

(The rest is omitted.) (3) Monitoring and continuous improvement of the quality of services

A. Upon coordination with the existing operation / maintenance company, the contractor shall monitor the values of service level items, evaluate the results and report to the relevant official.

(The rest is omitted.) (4)Implementation of security management in operation/maintenance work

A. The contractor shall observe the security policy of the Ministry of ___ and institute a framework to enable the verification of the compliance with the policy

B. The contractor shall implement training/operation based on the security operation manual.

C. The contractor shall institute a framework to enable reporting to the relevant official and take the necessary measures in cooperation with the existing operation/maintenance contractor in the case of an occurrence of a security event.

484

Item Description ○Implementation of operation/ maintenance design

The contractor shall create the following documents (by implementing operation/maintenance design). (1). Operation/maintenance outline

A document equivalent to the “operation/maintenance outline” in the optimization guidelines

(2). Basic design for operation A product stipulating the operation framework for the network and operation procedures

(3). Operation manual A product stipulating work procedures for key personnel in charge of network operations at the time of using devices and defect occurrence.

(5). A manual for the responsible personnel of the user organization and manager of individual systems

A product describing settings necessary for the use of the network, operation method and application method for the responsible personnel of the user organization and manager of individual systems

(6). Configuration management A product concerning network devices and settings that comprise the network.

(9). SLA and service level management plan A document equivalent to the “Service Level Agreement (SLA)” in the optimization guidelines and the service level management plan

○Framework and division of roles in operation/maintenance

To specify the expected framework and division of major roles in the operation/ maintenance work

Requirements to be added depending on type/characteristics of the project ○Transfer from the existing operator


SLA should be concluded for critical systems.

Notes on security ―

485

7. Operation / maintenance


To carry out operations in response to the results of the preparation for initiation of operation/ maintenance


(Documents pertaining to operation/ maintenance created in the preparation for initiation of operation / maintenance)


Report on the network operation ・ Operation status

・ Incident status ・ Operating performance ・ Expendables status

・ Operation/ maintenance status ・ SLA conformity status, etc.


The contractor shall describe services concerning network operations and the implementation requirements, etc. [1.Basic requirements to be listed] ○Configuration management/change management ○Maintenance ○Monitoring ○Defect handling [2. Requirements to be added depending on type/ characteristics of project] ○Requirements in cases where there is an operation / maintenance contractor for the related network system The following examples are based on this assumption.


Examples of basic items of operation/maintenance and examples of descriptions in cases where there is an existing operation/ maintenance contractor ○Configuration management/change management Configuration management/change management refers to a series of tasks for maintaining and managing the configuration information to the latest version through changes and relocations of connection settings of the user organizations to which the network is connected. If the implementation tasks need to be entrusted to the existing operation/maintenance contractor, the contractor shall file the application with details of the work to the procurer. (1). Target The target of “configuration management/change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and that of new centers, as well as devices newly installed by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2). Job description (Details are omitted)

A. Review of configuration management/change management

486

Item Description procedures

B. Application for change in network connection (processing of ministerial administrative procedures)

C. Coordination for the schedule of change, work details and requested items and creation of an implementation plan

D. Preparation for changes according to the type of lines and device changes, when the changes are deemed necessary

E. On-site study through coordination with the applicant if necessary

F. Network connectivity test G. Handing over the network environment H. When a problem occurs after the transfer of the environment, an

investigation of the cause shall be carried out cooperatively I. The period between the update of configuration management

information and the maintenance management of the latest configuration shall be less than seven days.

○Maintenance

The maintenance work refers to a series of maintenance / inspection work performed when necessary, in order to maintain the network configuration devices. (1). Target The target of “configuration management/ change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and to those of new centers, as well as devices installed newly by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2) Job description (Details are omitted.)

A. Review of a service implementation plan B. Necessary coordination for the work schedule, work details and

requests, C. Network connectivity test D. Handover of the network environment E. Recording/management of maintenance/inspection F. Notification of operation shutdown for maintenance

○Monitoring

Since the monitoring needs to be carried out covering the entire network, including the portion in this procurement, from the security viewpoint, the existing operation/maintenance contractor shall monitor the network in a comprehensive manner; such monitoring tasks include the centers constructed in this procurement and user organizations which carry out line speed up or to which a new line is connected. However, the contractor shall carry out monitoring of

487

Item Description backbone lines provided by the contractor under this procurement.

A. The contractor shall establish a communication flow so as to be able to promptly receive defect information on lines from the line provider and take appropriate measures based on this procurement.

B. When coordination for settings and thresholds is required, an approval shall be obtained from the relevant official and the concerned parties. The contractor shall also respond to the request for change in settings from the user and carry out such setting adjustment.

○Handling of defect

Handling of defects is a series of work related to the recovery of line and devices, etc., which comprise the network. The contractor shall implement the following operations. (1). Target The target of “configuration management / change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and to those of new centers, as well as devices installed newly by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2). Job description (Details are omitted.)

A. Cooperation with the existing operation/maintenance contractor B. Tasks implemented by the contractor

Notes on characteristics of a project / information system

The contractor shall present the requirements for the configuration management, including the management of the existing assets. When commissioning the helpdesk operations in a comprehensive manner to the existing operation/maintenance contractor, the contractor shall be required to provide cooperation so that the existing operation/maintenance contractor can carry out the helpdesk operations smoothly.

Notes on security Handling of incidents To establish a communication flow to enable rapid reception of

defect information and security incident information concerning the network.

Security diagnosis and reporting Continuous all-time monitoring of the traffic status of lines. In

cases of abnormal traffic, etc., the contractor shall conduct an investigation of the cause immediately and report to the relevant official via the existing operation/maintenance contractor.

Security inspection The contractor shall take appropriate measures promptly when a

vulnerability improvement for the introduced network devices is pointed out.

488

6.9.2.2. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware




1. Design/development plan Documents concerning the support for formulating design/development plan

By the commencement of design/development

2. Design/development Design/development implementation plan At the time of formulating design documents Basic design

Detailed design Work diagram and device installation diagram Connection specifications Settings

3. Migration plan Migration implementation plan At the time of formulating the migration plan Migration procedures

4.Support for test and migration judgment

Testing procedures At the time of formulating the test plan Test plan

Report on the test results After the completion of connection test

5.Migration Report on the migration results After the completion of migration

6. Operation/ maintenance plan

Outline of operation/maintenance At the time of formulating documents for the operation/maintenance plan

Operation design

Operation manual Manual for key personnel of user organizations and managers of individual systems Configuration management system or manual SLA, Service level management plan

7.Operation/maintenance Report on network operations Monthly after the commencement of operation

489



actual situation.


1.Design/development plan

Development schedule At the time of tender publishing

Views of ministries

2. Design/development Basic requirements At the time of tender publishing

User organizations (centers)

Existing environment (network diagram, etc.)

Outlined in the specifications, Details after the conclusion of the contract

Physical prerequisites for device installation

At the time of tender publishing. After the conclusion of the contract for some contents

Technical requirements for network design/development


Definition of service level items (when necessary)

3. Migration plan Migration conditions At the time of tender publishing Expected migration flow

4. Support for test and migration judgment

Requirements for testing At the time of tender publishing

Outline of acceptance test

Migration criteria

5.Migration Division of roles between the procurer and the contractor


6. Operation/ maintenance plan

Period of introduction/operation, etc., loan period, payment period


Configuration management items Configuration management document format

After the conclusion of the contract

7. Operation/maintenance

(Documents concerning operation/ maintenance created in the preparation for the initiation of operation/maintenance)


490

Examples of the definition of the service level items: All the items and setting values presented here

are just examples and nothing more, and the actual procurement should be based on sufficient

discussions and consent.

1) Service level items (excerpt)

Network devices are regarded as a service level item since they have a wide area of

influence at the time of an occurrence of a defect and are highly important.

The following shows that the target and the evaluation unit (separately stipulated) is set

by a service.

A. Network devices that are components of the internet connection

B. Network devices that are components of the internal connection

Service level item Description Setting value

Availability

The proportion of actual operating time

(operating hours) to expected operating time

More than 99.9%

Mean Time to

Repair (MTTR)

The average monthly time spent on recovery of

devices from the time of an occurrence of a

defect during the service operation hours

Within one hour

Mean Time

between Failures

(MTBF)

The average time elapsed from one failure of a

device to the next.

More than 2920 hours

(four months)

Service level items concerning initial response to defect/inquiry

Service level item Description Setting value

Lead time from the

occurrence of a

defect/inquiry to the initial

response

Time spent from the occurrence of

the defect /inquiry during the

helpdesk operation hours to reporting

on understanding of the status and

initial response, etc. to the relevant

official and the concerned users.

With 15 minutes

(2) Provisions concerning SLA compliance

The objective of Service Level Management (SLA) is to achieve, maintain and improve

the service level that is required for the operations in cooperation between the relevant

official and the contractor. Thus, in the cases where the target value set in the SLA has not

been achieved, the contractor should attain the service level by making further efforts for

improvements in cooperation with the relevant official.

In the case of a service that provides infrastructures having a great impact on the

information system whose users are the general public, is the people on the social

infrastructure, and on the entire system, a fine shall be imposed if the service level target

has not been achieved, considering its significance. (Penalty and incentive based on the

491

SLM settings and the SLM implementation).

(3) Concept of penalties and incentives

A. Ninety percent of the bid price will be considered as a basic fee award and the rest

10 percent as a contingency bonus in accordance with the status of the SLA

compliance. The evaluation shall be conducted based on the monthly report on the

SLA achievement, and the monthly award shall be paid by adding the amount in

accordance with the “degree of attainment” to the basic fee award.

B. With respect to the service level items, the status of achievement of service level

setting values for each service and device shall be evaluated every month.

According to the number of unattained items of the service level setting value, the

“degree of attainment” of a given month shall be evaluated on a 4-point rating scale.

(4) SLA evaluation period

The compliance to the SLA shall be measured from the date of commencement of

operations. However, the fluctuation of the amount of pay shall commence on the third

month after the start of the service.

(5) Measures for the cases where the service level target value continues to be unattained

A. Damage claim

If the cause of extremely low SLA compliance rate without expectation of

improvements is attributable to the contractor, a damage clam may be separately

filed, which shall not exceed the ceiling price set forth in the contract. The following

are the criteria for the period and frequency of the extremely low SLA compliance.

a. The status of “Grade D” continues for “more than three consecutive months,”

“more than four times a year” or “total of 12 times during the operation.”

b. The status of “Grade C” continues for “more than five consecutive months,”

“more than six times a year” or “total of 18 times during the operation.”

c. In cases where damage occurs exceeding the amount of the contingency

bonus, which is 10% of the bid price, due to discontinuity of business caused

by defect, etc.

B. Deprivation of eligibility for bidding

In cases falling under the situation A above, the contractor shall be considered as

having no capacity to provide the quality of service level required by the Ministry,

and may potentially be subject to deprivation of eligibility for bidding for a certain

period of time, rescission of the contract, imposition of a penalty, including

suspension of eligibility for bidding at the time of the next contract renewal.

492

6.9.2.4. Division of roles The following are the examples of the division of roles between the user and the network operator in

the operation and maintenance in cases where the procurement is carried out in combination with the

existing network. System Major roles Remarks

User

Individual system manager

・ The responsible personnel of each system serving as a liaison for the coordination with the operating body

・ Responsible for attendance at work and support in the separation of a defect and investigation of the cause

Allocated to each system

Person in charge of the user organization

・ The responsible personnel of the user organization serving as a liaison for the coordination with the operating body

・ Responsible for the environment development for the user organization, attendance at work, support for defects, etc.

Allocated to each user organization

Consolidated netw

ork operating body

Contractor ・ To cooperate in creating an operation/maintenance plan (developing implementation procedures manual, etc.)

・ To carry out configuration management/change management, maintenance, defect response and regular reporting in line with the operation / maintenance plan

・ To carry out monitoring, evaluation, analysis and improvement of monitoring items for the quality of services

・ To provide information to the existing operation/maintenance contractor in order to report the implementation status to the operating body (the relevant official)

Assignment regarding the scope of the contract

Existing operation/ maintenance contractor

・ To control and manage operation/ maintenance ・ To formulate an operation/ management plan

(implementation procedures, manual development, scheduling, etc.)

・ To carry out configuration management/change management, maintenance, monitoring, defect response, helpdesk operations, and regular reporting, in line with the operation/maintenance plan.

・ To carry out monitoring, evaluation, analysis and improvement of monitoring items for the quality of services

・ To report the implementation status to the operating body (relevant official)

Relevant official (including the process management support contractor)

・To make decisions and give final approval in operation/ maintenance as the operating body

About two persons (excluding the process management support contractor)

493

Examples of the division of roles between the existing network operation contractor and the

contractor in the operation and maintenance in cases where the procurement is carried out in

combination with the existing network

No. Item Description

Services of the

existing operation/

maintenance

contractor

Services of the

contractor

(section of the scope of

the order received)

1 Operation

control

Control and management of the

overall operations for operation/

maintenance

○ ×

2

Configuration

management/

change

management

Response to applications

concerning network and

configuration/change

management

○ ○

3 Maintenance

Maintenance for devices that

constitute the network when

necessary

○ ○

4 Monitoring

Monitoring the operation status of

lines and devices that constitute

the network

○ △

(Monitoring of backbone lines only)

5 Helpdesk

operations

Response to inquiries and

provision of information about the

network

○ ×

6 Defect

response

Repair and recovery of defects in

lines and devices that constitute

the network

○ ○

7

Reporting on

operation/mana

gement

implementation

status

Regular reporting to the network

operating body of the overall

status, SLA achievement status,

and quality monitoring in

operation/monitoring work

○ ○

8 Security

management

Security maintenance of the

network ○

△ (Response to security

incident)

494

6.9.3. Services concerning procurement of communications services 6.9.3.1. Services to be listed in specifications 6.9.3.1.1. Typical service operations

Service

operations Outline of service operations Activities of SLCP-2007

Chapter and section

of specifications

corresponding to

BGP

1.Preparation for installation

Creation of schedule Coordination with ministries on the implementation procedures Preparation for preliminary study, etc.

3.2.1 Preparation for initiation of process (environment development)

Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter X Chapter XI 2.Installation Work necessary for service

provision, etc. 2.2 Construction of environment 2.3.1 Preparation of initiation of quality assurance process

3.Operations management/ maintenance

Operation/maintenance for sustainable service provision

1.7.7 Evaluation of system operation 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification

Chapter V (5) Chapter X Chapter XI Chapter XII

4.Reporting Regular reporting associated with network service operation

1.7.4.1System operation 1.7.4.2 Operation monitoring and collection of operation data Detecting, recording and solving problems, Improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation

495

6.9.3.1.2. Explanations and examples of descriptions in specifications concerning services 1. Preparation for installation


To carry out preparation work, such as creation of schedule, coordination with ministries on the implementation procedures and preliminary study, etc.


・Outline of schedule ・Function specifications ・List of centers to which the system is introduced ・ Plan views indicating scheduled locations of device installation

(ODU, distribution board, etc.) and scheduled locations of piping and wiring routes of power source lines/communications cables.


・Detailed installation schedule ・Report on on-site studies in the building


To specify items of preparation for communication service introduction to be carried out by the contractor [1. Basic requirements to be listed] ○The contractor shall determine the installation schedule and implement coordination with ministries.

－Basic requirements and notes for the installation shall also be specified.

○Implementation of a preliminary study ○Period and location of provision [2. Requirements to be added depending on type/ characteristics of project] ○Function specifications for the network service to be procured shall be specified.


Examples of procurement specifications in cases of service procurement ○The contractor shall determine the installation schedule and implement coordination with ministries. ・ The outline of the schedule shall follow the “draft of installation

schedule,” and the detailed installation schedule shall be fixed within 10 days after the successful bid upon consultation with the relevant official. However, dates are subject to change upon consultation between the Ministry and the contractor in the case of unavoidable circumstances. The contractor shall make necessary coordination with the ___ system vendor.

○Implementation of a preliminary study ・ The contractor shall carry out on-site studies (specifically,

confirmation of following matters: installation method and routes of the cables in the building, presence or absence of documents to be submitted, presence of absence of the specific building management contractor, and necessity of work on the building, such as piping work) in the building of each center of the Ministry and submit a report on the studies in writing with elevation views and plan views of the studied locations to the relevant official.

496

Item Description The contractor shall make a request to the relevant official at this point of time for the submission of documents, if there are any documents to be submitted by the Ministry.

・ Estimates shall be separately submitted if the study finds it necessary to carry out incidental work on the installation, such as piping work in the building, etc.

Examples of function specifications of network services to be procured ○Function specifications (1) Internet connection service (Details are omitted.)

The contractor shall provide the internet connection that meets the following specifications as an internet service provider (hereinafter referred to as “ISP”) (i) Bandwidth (ii) Interface at the time of transfer to the Ministry (iii) Requirements as ISP (v) Proxy application for domains (viii) Allocation for IP addresses (xi) Secondary DNS service, etc. (xii) Conditions for an access line between the interchange point of

the contractor and the Ministry, etc. (xv) Conditions for fees, such as a communication fee in cases of

changes in service bandwidth and line types of the internet connection service.

(2) WAN cable (wide area Ethernet service) All of the following requirements shall be met for the provision of a network of the wide area Ethernet service covering all centers of the head office and local branch offices of the Ministry of ___. Please refer to the “list of locations and bandwidth of each center” for the location and connection bandwidths of centers. (Details of requirements are omitted.)

(3) Connection to ___ system (Details are omitted.) ○Period and location of provision (1) Period of provision Date: From M/D/Y to M/D/Y

(2) Location of provision Internet connection service: Within the computer center of the

Ministry of ___ Wide area Ethernet service: Refer to the “list of locations and

bandwidth of each center” Notes on characteristics of a project/information system

In cases where there are existing LAN and WAN services, or where other related systems are procured at the same time, the contractor shall specify matters to be specially coordinated in the implementation of installation work.


497

2. Installation


To carry out the work necessary for the provision of services


－


・ Report on the results of installation ・ Work diagram [diagrams indicating the locations of devices

(ODU, distribution boards, etc.) and locations of the cable routes] Matters to be described in specifications

The contractor shall specify matters to be carried out by the contractor with respect to the installation of the communication services [1. Basic requirements to be listed] ○Details of installation and notes ○Items requiring coordination, etc. [2. Requirements to be added depending on type/ characteristics of project]


Examples of procurement specifications in cases of procurement of internet connection services and wide area Ethernet services ○Details of introduction work and notes ・ In cases where defects occur in ___ system, internet

connection services or WAN of the Ministry of ___ and such defects are attributable to the contractor in relation to the relevant work, the contractor, at its expense, shall provide alternative functions.

・ The contractor shall create a table of the operation flow and a defect response manual by the day of commencement of the communication services and gain the approval of the relevant official. If there is light work that can be carried out by the relevant official for a prompt recovery from the defect, the details of such work shall be described in the manual.

・ The contractor shall establish a framework to enable the relevant official to check on the performance of the contract at all times

・ In cases where the provision of internet connection services and wide area Ethernet services is not ready by the scheduled date of commencement, which is attributable to the contractor, the contractor shall either continue using the existing WAN cable or internet connection under the current contract with the Ministry or present an alternative plan, and take measures upon gaining approval of the relevant official. All the costs necessary for the measures shall be borne by the contractor.

○Items requiring coordination, etc. ・ The contractor, when starting work at the centers of the

498

Item Description Ministry, shall take statutory procedures (if necessary) to the government offices and inform the relevant official about the completion of the procedures.

・ Compensation for damages to the third party during work, such as damages to buildings and roads, land devastation, etc. shall all be borne by the contractor.

・ When entering the centers of the Ministry to carry out work, the contractor shall submit written documents indicating the details and scope of the work, the number of workmen, work schedule, and vehicles to be used for work to the relevant official two weeks in advance of the start of the work and obtain approval.


In cases where there are existing LAN and WAN services, or where other related systems are procured at the same time, the contractor shall specify matters to be specially coordinated in the implementation of installation.


499

3. Operation management/maintenance


To carry out operation management/maintenance for sustainable service provision


Service level items (when the conclusion of an SLA is required) Operation requirements

Product (Prepared by the contractor) －


The contractor shall describe matters to be carried out by the contractor associated with operation management/maintenance of communications services [1.Basic requirements to be listed] ○Details of operations management/maintenance ○Notes in operation [2. Requirements to be added depending on type/ characteristics of project]


Examples of procurement specifications in cases of service procurement ○Details of operations management/maintenance

・ The contractor shall establish a framework of network monitoring and defect response on a 24-hour, seven-days-a-week basis. In view of early detection and rapid recovery from defects, monitoring and defect response services for the internet connection and wide area Ethernet shall be consolidated into one contact point.

・ In cases where the system suspension continues for more than five minutes, in principle, after the detection of a defect, the contractor shall notify the relevant official immediately. The contractor shall also report the status to the relevant official every 30 minutes, in principle, until the system is recovered, except if instructed otherwise by the relevant official.

・ In preparation for the occurrence of a defect, the contractor shall establish a framework enabling defect repair and recovery on a 24-hour, seven-days-a week basis. When a defect is detected, the contractor shall exert efforts for rapid recovery to comply with the SLA.

・ When a defect occurs, the contractor shall, at its expense, take appropriate measures to prevent recurrence.

○Notes on operation work ・ When conducting scheduled work and regular maintenance,

the contractor shall make efforts to avoid network shutdown as much as possible. If the shutdown is deemed necessary during scheduled work and regular maintenance, the contractor shall notify and gain approval of relevant official at least two weeks prior to the shutdown.

500

Item Description ・ If it is obvious that a continuation of system operation will result

in a defect, and thus an emergency shutdown is required, the contractor shall decide on the response upon consultation with the relevant official.


The contractor shall consider making a particular request for consolidation of monitoring and defect response services, depending on the status of the system.


501

4. Reporting


To carry out regular reporting associated with the network service operations


－


・Operation report ・Report on SLA achievement status

Matters be described in specifications

The contractor shall describe matters to be carried out by the contractor with respect to the report on communications service operations [1. Basic requirements to be listed] ○Details of report [2. Requirements to be added depending on type/ characteristics of project]


Examples of procurement specifications in cases of service procurement ○Details of report ・ The contractor shall provide the internet connection services in

Web forms or CSV forms, which allows mail attachment so as to enable only the relevant officer to confirm the traffic information of the previous month at the beginning of each month. With respect to wide area Ethernet services, the contractor shall prepare a framework which enables only the relevant official to confirm the traffic information of each line in a graphic form on a daily, weekly, and monthly basis on a website.

・ The contractor shall hold a briefing session every month, in principle, in which the personnel with a thorough knowledge of internet connection services and wide area Ethernet services of the Ministry informs the relevant officer about the achievement status of the service level items and defect responses for the previous month. When some SLA items are unachieved, the cause shall be analyzed and reported to the relevant official, and measures to improve services shall be discussed on an as needed basis.


If reporting on the reliability of the connection with related systems is deemed necessary, such matters shall be entered in the specifications


502

6.9.3.2. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware



Service Deliverable product Delivery deadline 1. Preparation for

installation

Detailed introduction schedule Within 10 days after successful bid

Report on on-site study of the building After the implementation of the on-site

study on preparation for introduction

2.Installation Report on the results of introduction At the time of completion of introduction

3.Operation

management/maintenance

― ―

4.Report Operation report On a monthly or as needed basis after the

commencement of operations Report on SLA achievement status

6.9.3.3.Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.


actual situation.

Service Input Timing for presenting input 1.Preparation for

installation

Outline of schedule Included in procurement specifications or as an attachment

at the time of tender publishing

Function specifications Included in procurement specifications or as an attachment


List of introduction centers Included in procurement specifications or as an attachment


2.Installation ― ―

3. Operation

management/

maintenance

Service level item Included in procurement specifications or as an attachment


4.Report ― ―

503

Examples of descriptions of service level items:

5. SLA

(1) The network covering from the Ministry to the Internet eXchange (IX) and the network

comprising the WAN of the Ministry of ___ shall have high reliability and the availability

of the backbone and the monthly availability of every access line provided shall be over

99.9%, respectively.

(2) The definition of the availability is shown below.

In the internet connection service, “availability” refers to the network availability which

covers from the Ministry to ___.

In the wide area Ethernet service, “availability” refers to the network availability of the

backbone of the wide area Ethernet service and the availability of the access line

network in each center to which the WAN of the Ministry of ___ is connected.

The defined availability is the percentage of time of actual operation to the agreed

service time in a month and is calculated in the following way. The scheduled

operating time is, in principle, the time obtained by multiplying the days of a given

month by 24 (hours) and the total down time refers to the accumulated time per month

of experiencing performance problems in receiving or sending data.

Availability (%) = (Scheduled operating time – total downtime) ÷ scheduled operating time × 100

(3) The time of occurrence of a defect refers to either the time when the contractor has

detected the defect or the time when the relevant official of the Ministry (hereinafter

referred to “the relevant official”) has informed the contractor about the defect,

whichever happens first.

(4) The period of a system shutdown which is not attributed to the contractor or due to

scheduled work or regular maintenance shall not be considered as downtime in the

availability calculations.

(5) If it is obvious that a continuation of a system operation will result in a defect and thus

an emergency shutdown is required, the period of time of emergency shutdown shall

be considered as downtime in availability calculations.

(6) Other items related to the SLA shall, in principle, be in compliance with the SLA

stipulated in the service agreement of the contractor. The contractor shall submit the

SLA stipulated in the service agreement at the time of making proposals.

(7) If the business continuity is ensured by line redundancy, etc. even when the lines are

down, such a period shall not be considered as downtime in availability calculations.

504

6.10. Cloud service

Please refer to “4.8 Standpoints of Cloud Users” for this section

505

6.11. Cloud construction

Please refer to “4.9 Standpoints of Cloud Integration” for this section

506

6.12. Security

6.12.1.Definition of procurement area Unlike other sections in this Chapter, the security section refers to the indispensable security

features (security notes) in the procurement of each service.

The security notes provide the essentials to be implemented in the procurement of information

systems, as well as security matters in each service of the procurement area.

This section also includes the use of “the security by design (SBD) as a measure to ensure

information security of e-Government from the stages of planning and design” and “system design for

the risk factor reference model (RM) analysis,” which are specific security approaches to be used in

information system integration.


6.2 （等）


6.2 - 1 調達支援


6.4 運用 6.3





6.12 Security


Planning phase





6.4 Operation


6.5 Helpdesk

6.6 Maintenance


507

6.12.2. Notes on security to be commonly listed in specifications 6.12.2.1. Notes on security commonly applied to the procurement of information systems

Basically, security notes to be followed uniformly by each service domain means the compliance

with laws and regulations and the conformity to standards, policies and guidelines, etc. The

contractor should give careful consideration to the contents listed in 1-5 when performing each work

task. All the constraints as requirements for bidding should be listed comprehensively. Standards,

policies and guidelines, etc. to be conformed to should be disclosed to the bidders during the tender.

Notes Outline of notes Points of description

1. Conformity to the “Standards for Information Security Measures for the Central Government Computer Systems”

The contractor shall conform to the “Standards for Information Security Measures for the Central Government Computer Systems” (Decision by the Information Security Policy Council)

The contractor shall indicate the conformity to the standards mentioned in the left column in the section of the “security requirements,” in cases where specifications are created in pursuant to the Basic Guidelines for Government Procurement Related to Information Systems

2. Conformity to security policies issued by each ministry

The contractor shall conform to the information security policies issued by each ministry in pursuant to the above-mentioned “Standards for Information Security Measures for the Central Government Computer Systems” (Decision by the Information Security Policy Council)

The contractor shall indicate the conformity to the standards mentioned in the left column in the section of the “security requirements,” in cases where specifications are created in pursuant to the Basic Guidelines for Government Procurement Related to Information Systems. If the policies mentioned in the left column are disclosed after the conclusion of confidentiality agreement, such matters shall also be mentioned.

3. Compliance with laws and regulations, etc.

The contractor shall comply with laws and regulations concerning the relevant procurement projects, including the Act concerning Protection of Personal Information, the Penal Code, the Copyright Act, and the Unauthorized Computer Access Law, etc.

The contractor shall list laws and regulations concerning the relevant information systems and operations and indicate the conformity to such laws and regulations.

4. Conformity to other guidelines

If there are any guidelines to be followed and handled by the contractor, besides the items from 1 to 3, the contractor shall conform to the relevant guidelines.

The contractor shall identify the guidelines to be conformed to, besides the items from 1 to 3, in accordance with the details of the information system. The specifications shall state the conformity to the guidelines and proposals to realize the guidelines are required.

5. Application of security policies to reconsigned party

If a part of the service is reconsigned upon gaining approval from the relevant ministry, the reconsigned party shall conform to the regulations in the same manner as the contractor.

If there is an option of reconsigning a part of the service, a statement shall be included to the effect that the reconsigned party shall observe the regulations in the same manner as the contractor.

508

6.12.2.2. Standards/guidelines used as a reference “Standards for Information Security Measures for the Central Government Computer Systems” (4th

ed.) (Revision FY 2009) (May 11, 2010 - Decision by the Information Security Policy Council)

http://www.nisc.go.jp/active/general/pdf/K303-091.pdf

6.12.3. Use of the security by design (SBD) as a measure to ensure information security of e-Government from the stages of planning and design

The National Information Security Center, in response to the request from the Information Security

Policy Council, has established and hosted the “committee for the security by design (SBD) as a

measure to ensure information security of e-Government from the stages of planning and design

(hereinafter referred to as the “SBD committee”)” comprising experts and vendors with experience

and knowledge. The SBD committee formulated the “Manual for the Formulation of Requirements for

Information Systems in Government” (hereinafter referred to as “the Manual”) with an aim to reduce

inconvenience to both procurers and suppliers of information systems due to vague procurement

specifications, allowing the integrated implementation of appropriate security measures.

The Manual covers the entire procurement of information systems to be newly constructed or

revised by government organizations and expects that the government’s administrative officials in

charge of procurement of information systems in particular, will be able to formulate security

requirements using the Manual at their responsibility and enter relevant requirements in the

procurement specifications. It is also expected that information system suppliers will have access to

information (information on formulation process, etc.) in the Manual which will help them understand

the security requirements described in the procurement specifications.

At the time of the induction of requirements, it is expected to ensure appropriate security measures

meeting needs by describing significant and effective requirements in the procurement specifications

in a prioritized and emphasized manner, based on the measures for information protection in

information systems and the measures against security breaches.

6.12.3.1. Preparation for the induction of security requirements (creation of system schematic diagram and detailing of requirements)

Firstly, the Manual provides explanation on the induction procedures of operation requirements and

system requirements necessary for security requirements. In these procedures, the personnel in

charge of procurement examines operations related to the information system to be procured,

endorses an operating entity, information and environment for each operation, and creates a system

schematic diagram. Then, the personnel in charge select operation and system requirements, upon

ensuring a certain level of quality or higher, through answering standardized questions based on the

created system schematic diagram.


509

Procedure Outline 1. Examining the objectives and operations

The relevant personnel shall coordinate objectives and operations (operation flow, related documents, etc.) of the information system to be procured through internal discussions.

2. Examining entities related to operations

The relevant personnel shall examine the entities (personnel, organizations and information systems, etc.) of each operation

3. Examining information to be handled

The relevant personnel shall examine the entities and information to be handled by each operation and its flow.

4. Deciding the target of information systematization

The relevant personnel shall clarify the target range of the systematization and examine the relationship if a given system operates in combination with other systems.

5. Deciding the environment used in operations of information systematization

The relevant personnel shall decide on the environment (terminals and lines, etc.) in which the operating entity uses the relevant system.

6. Creation of a system schematic diagram

The relevant personnel shall create a system schematic diagram based on the results of the above and in line with certain rules for description.

7. Detailing requirements by standardized questions

The relevant personnel shall detail the requirements for the target system from three perspectives: namely, “entity,” “information,” and “user environment/method” by answering standardized questions, based on the system schematic diagram.

Individuals

[User environment]- Network computer/ cellular phone

[User registration]- Personal information 1- Personal information 2

[Browsing opinions and comments]- Public information 1- Personal information 3

Open website system of the Ministry

[Storage]- Personal information 1- Personal information 2- Business information 1- Business information 2

Persons on business trip/subscribers

[User environment]- Cellular phone, mobile PC

[Legend]

Name of the entity

[Name of the behavior]- Information- Information

[Name of the behavior]- Information- Information

User environment /method

Name of the entity

Internet[Information registration on the website]- Business information 1- Business information 2

[Website browsing]- Business information 1- Personal information 3

[Input]- Public information 3- Personal information 3- Business information 3

[Output]- Business information 1- Business information 2

Cooperation system with external sources

[Input on the website]- Configuration information

Exclusive network

Government information network

[Notification via email]- Warning information[Downloading on the website]- System data

System administrator

Employees of the Ministry(Agency)

headquarters

Employees of the branch offices, etc.

[Information registration on the website]- Public information 1- Business information 1

[Website browsing]- Personal information 1- Personal information 3

[Information registration on the website]- Public information 2- Business information 2

[Website browsing]- Public information 2

Figure 6.12.2 System schematic diagram

6.12.3.2. Decision on requirements for measures

Next, this section provides explanation on the examination of the direction of measures (policy of

measures) based on the decision criteria (criteria for making decisions on the requirements for

desirable measures to be implemented with priority) as procedures for the induction of security

requirements using the operation results described above (information examined), as well as being

based on the method of deciding the requirements for specific measures conforming to the relevant

policy of measures.

510

Procedure Outline

1. Examination of policy of measures

The relevant personnel shall examine the direction of measures (policy of measures to be implemented with priority) by applying decision criteria to the requirements selected through the system schematic diagram and standardized questions.

2. Decision on the requirements for measures

The relevant personnel shall make a decision on specific requirements for measures that comply with the predetermined policy of measures, while giving consideration to costs, etc.

3. Feedback on the procurement specifications

The relevant personnel shall provide feedback for the above results on the procurement specifications

6.12.3.3. Other The “Manual for the Formulation of Requirements for Information System in Government” (the

Manual) lists the requirements obtained through the above-mentioned process. Although it is not

directly applied to the actual requirements for measures, it includes the task of describing, in the

specifications, the information (e.g. scale of the entity, etc.) deemed useful for the bidding company’s

proposal (discussion).

The Appendix of the Manual includes explanation on the requirements for measures (method of

entering the requirements for measures, assumed threats and examples of implementation, etc.),

correspondence between the compliance items of the Government’s Standards and requirements for

measures in the Manual, and reference documents for the implementation of tasks.

As described above, the use of the Manual is important for assisting the personnel in charge of

procurement (person engaged in administrative affairs) to make a decision on appropriate security

measures for the information system to be procured. It is also expected that the supplier of the

information system will have access to this information (information on the formulation process, etc.)

that helps them to understand the security requirements listed in the procurement specifications.

511

6.12.4. Use of the risk factor reference model (RM) analysis for system design, etc. 6.12.4.1. The relations between “existing standards” and “RM design requirements” and the basics of usage Each item in the “requirements for measures for RM design to avoid ultimate impact on

organizational operations” analyzed with the RM can be considered as specific requirements for

design measures corresponding to the security management measures in the existing standards, etc.

Thus, application to the function requirements/test requirements at the time of contracting will

secure the compliance under the contract with the existing standards, etc.

Since the “requirements for measures for RM design to avoid ultimate impact on organizational

operations” are the design measures derived from the definition of a “cyber attack threat model

(attack scenario),” it is expected to be used as a test scenario at the time of contract. This allows

focus on the confirmation of quality and vulnerability of the functions necessary for the avoidance of

an ultimate impact on organizational operations, leading to improvements in cost performance.

Existing standards, etc.

Requirements for measures for RM design to avoid ultimate impact on organizational operations

Def inition of cyber attack threat model (attack scenario)

Corresponding items

Function requirements/test requirements (specif ications) at the time of placing an order

Contract compliance

Figure 6.12.-3 Relations between the existing standards and requirements for measures for

RM design

A serious issue in the requirement definition and creation of security measures for information

systems is that discussions with concerned parties, such as the customers and contractors, etc.,

must take place at a level of high expertise in the realm of security, which is a non-functional

requirement.

Thus, RM provides a framework where both customer and contractor are able to discuss security

measures for information systems with common standards, with an aim of reaching consensus on the

necessity of implementation of specific measures and the confirmation of design functions based on

the shared awareness of the issues among concerned parties in each stage, which is then intended

512

to improve the precision of the cost estimates and requirements.

The following table shows the process in each stage of the system procurement as a premise for

the discussion on RM.

Expansion to basic system design, production, test, etc., based on the results analyzed during the order placement process

Process Details of implementation Basics of using RM

1.Presentation of system function requirements and other requirements (customer)

2. Realistic and specif ic system conf iguration (contractor candidate)

3. Identif ication of threats and information sharing (customer & contractor candidate)

Def inition of cyber attack threat model (attack scenario)

4. Comprehension of impact on operations and understanding of ef fects of design measures (customer & contractor candidate)

5. Discussion on items of measures for system (customer & contractor candidate)

6. Identif ication of function requirements/test requirements (specif ications) at the time of placing an order

Establishment of operation requirements for the entire system

Establishment of function configuration requirements for the entire system

Understanding of the impact of cyber attack threat model (attack scenario) on system functions

Discussions on the possibility of preventing the impact of cyber attack threat model (attack scenario) on system functions

List of function requirements/test requirements determined in the above

Use of RM cyber attack threat model (attack scenario)

Requesting the contractor candidate for explanation

Use of the following:- Cyber attack threat model (attack

scenario)- Requirements for measures for RM

design to prevent ultimate impact on organizational operations

○At the time of placing an order

○At the time of the system production

7. Expansion to system design/test The contractor shall implement the following:- Design based on the requirements for

measures for RM design- Correction and test on related vulnerabilities

based on the attack scenario

Standard operation procedures as a premise for the discussion on RM are as follows.

The following image shows a standard communication flow between the customer who demands

Objectives of the risk factor reference model

The risk factor reference model was developed to enable the customer and

the contractor for the information system to examine and consider security

measures to be incorporated in the system based on actual threats. This

model aims to design security measures necessary for the information

system under the shared understanding of customers and contractors of the

public and private information system integration.

513

a system using the risk factor reference model and the system vendor who proposes a specific

system and receives an order. Such a communication flow can be incorporated into a part of a

bigger flow implemented, usually at the time of designing a relatively large-scale system, regardless

of whether it is public or private.

Figure 6.12-4 Standard operation procedures of RM

In addition, the following show cases of the use of this model for the response to incidents as an

application of RM.

The risk factor reference model has prepared patterns of target threat and patterns of system

topology to produce a threat catalogue. This allows an understanding of how each target threat

behaves in the system and where problematic phenomena occur. Therefore, when an existing

system is attacked, this can be used for identifying where in the system the problem has occurred and

provide considerations for taking temporary measures for the system, such as bypass measures for

the attacked site, etc.

○Assessment of impact on the system at the time of obtaining attack information

It is used for consideration of impact on the system, the presence or absence of bypass design,

impact on the organizational activities, establishment of temporary measures and planning of

measures in case of cyber attack.

514

Catalog of serious threats

Schematic diagram for patterns

Behavior diagramAttack specifications

Topology basic diagram

Effective design measures

Cases

Organizational issues

At the time of occurrence of cyber attack

Basic diagram (internet connection type)

RM

Basic reference model

Identif ication of reference parts from the basic system configuration

RM users

Impact on own organization and what is the phenomenon on the system (what happens)?

Refer to the “attack specifications and effective design measures” and identify the relevant system applicable to the attack on the server. Consider the impact on organizational activities.If the part “as long as this line of communication is blocked, the system at least is protected” is covered, the system will not fall under the status of “attainment of objective of the attack (the worst case scenario).”

Various arrangements/discussions and decisions on provisional measures (including the number of processes)

Result of trace analysis

Consideration for the provisional measures, etc.

Other, use of usable confirmation tool, etc.■MyJNY version checker■MyJYN security settings checker

Figure 6.12-5 Example of the use of obtained attach information for impact assessment

6.12.4.2. Concept of inducing requirements for RM design measures The risk factor reference model is considered to be a major security measure. Behind this lies the

fact that the effectiveness of the design method to allocate security products within the information

system has significantly declined due to the emergence of new methods of cyber attacks, such as a

targeted attack. In order to resolve this situation, RM has been developed as a method for evaluating

the impact on operations and clarifying necessary measures and costs, based on the reality of the

current cyber threats.

515

Man

agem

ent m

easu

rers

ThreatRiskProblem

Ground for countermeasures?

System design/management measurers

?

RM

ThreatRiskProblem

Ground for countermeasures? System design/management

measurers(Priority response to necessary parts in accordance with the awareness of the issue – increased effectiveness)

(Full-f ledged approach to the specifically described awareness of the issue)

(Can the full-f ledged implementation of management measurers cover present threats?)

Necessary costs

Necessary costs

Clarif ication of the issues and measures

Possible feedback to management measures (particularly to CND section)

Ground for countermeasures Implementation with variation

(increased cost performance)

Implementation reference

Guideline (policy level)

CND: Computer Network Defense Figure 6.12-6 Cost performance of RM

The following shows each analysis component (1-4) of the risk factor reference model (RM). The RM

analyzes cyber threats to the information system in organizations. When requiring the implementation

of RM in specifications, the mission impact of cyber attacks and investment effects should be fully

considered.

Analysis process (1): To define attack patterns as a threat model which specifically analyzes and

interprets the reality of current cyber threats and develop specific attack scenarios

Since threats of today have become diversified, advanced and complex, it is difficult to analyze

(1) To define attack patterns as a threat model which specifically analyzes and

interprets the reality of current cyber threats and develop specific attack scenarios

(2) To design an information system design model as a model in accordance with

each characteristic of the system

(3) To analyze the impact and the effects of design measures by tracing attack pattern

scenarios on the information system design model (attack simulation)

(4) To compile the results of attack tracing (attack simulation) as “system design

measures”

516

the impacts and plan measures if handled individually, and it is impossible to determine the

measures at the contract stage or design stage. Thus, the risk factor reference model has

classified the threats into six patterns by analyzing behavior of actually observed threats, which has

then been compiled into a “Catalogue of Critical Threats,” and the results of the analysis of the

catalogue are organized as attack patterns.

Reflecting “the characteristics of the infrastructure used for Distributed Denial of Service (DDoS) attacks against smart meters” found in DDoS cases in South Korea

Creation of attack bots using exising services, such as iDC, etc.

Case of browsing gumblar infected sites from the intranet

Automatic falsif ication cases caused by an infected web administrator terminal on the relevant intranet

Cases where the intrasites are infected with a Gumblar virus

Solution to the spread of infection from the use of FTP infrastructure

Variation 2: Spam mail directing to unauthorized URL

Pattern 1: Malware infection through browsing of f icial website

Variation 2: " Browsing websites infected with a **.ru:8080 virus"

Variation 1: “Browsing websites infected with a gumblar virus "

Pattern 2: Targeted email attack (information thef t)

Variation 1: File attached email ab

Pattern 4: 「Malware infection through media (information thef t)

Variation 3: " Browsing websites infected with SQL injection "

Pattern 3: Redirection by falsif ied official websites

Variation 2: “SQL injection"

Variation 1: “gumblar.x virus"

Variation 4: " Redirected f rom the search engines "

Variation 1: " Conf icker (worms) spreading via USB "

Clarif icaiton of the reality of threats and specif ication of measures Individual incidents havinng great organizational impact are grouped in any of the patterns and incidents that can be covered with the same measures are grouped in the same category.

Model called operation the “Aurora” attack

Pattern 5: Multiple DDoS attack (attack inf rastructure)

Reference: Existing threats (attacks still observed today)

Pattern 6: Regular DDoS attack

Variation 1: " DDoS attacks on SSL connection "DDoS attacks on SSL connection by BotnetImpact on the internet business settlement

Figure 6.12-7 Attack patterns covered by RM

517

The outline of each attack pattern is described below.

“Pattern 1: Malware infection through browsing official websites (information theft)”

This attack redirects the website to malware distribution sites to steal authentication information,

etc. and setup a backdoor when users browse falsified official websites. Infrastructure used for the

attacks expands through the use of the stolen authentication information.

This corresponds to the cases where the system gets infected when the system user browses the

falsified official site.

Figure 6.12-8 Pattern 1: Malware infection through browsing official websites (information

theft)

518

Pattern 2: Targeted email attack (information theft)

Instead of indiscreetly targeting a large number of users, this type of attack targets individuals in

specific organizations or firms by using a false title, text or sender name, and sends emails with

attached malware.

Once an email is opened, the malware is activated and the system is infected with bot and

organizational information is stolen. Since emails are sent to specific organizations, it is called a

“targeted attack.”

Figure 6.12-9 Pattern 2: Targeted email attack (information theft)

519

Pattern 3: Redirection by falsified official websites

This attack falsifies official websites with a purpose to redirect the site browser to a malware

distribution site.

This corresponds to the cases where website in the system is falsified (link insertion) and

redirected to the malware distribution site for the external browsers.

Figure 6.12-10 Pattern 3: Redirection by falsified official websites

520

Pattern 4 Malware infection through media (information theft)

A virus slipped into the media port, such as a USB port, etc., during the production development

process, etc. enters into the system through the media port. Once entered, the virus updates the

malware onto the infrastructure used for attacks. At the same time, the infection expands through

network infection of the core system and media ports.

Since the attack causes both network failure and server failure, an effective prevention is the

cooperation between the management organizations of both network and server and the security

department in addition to the preparation for separation procedures, etc.

The malware entered into the system sets up a backdoor in the system to scan system information.

Figure 6.12-11 Pattern 4: Malware infection through media (information theft)

521

Pattern 5: Multiple DDoS attacks (attack infrastructure)

A PC infected with malware carries out DDoS attacks on the web server and downloads

instructions and other malware from the malicious server, then sends out mass spam mails and

destroys files in the malware-infected PC.

The multiple-type DDoS is a new type of attack with respect to the infrastructure used for attacks;

for example, the existing VPN network, which has been traditionally constructed as a package of

safety assurance, is used and malware with dispersed functions exercise the attack functions in

conjunction with each other. Since it is difficult to analyze protection information, it will become a

threat that will be hard to address in the future if it is used in various types of attacks.

Figure 6.12-12 Pattern 5: Multiple DDoS attacks (attack infrastructure)

522

Pattern 6 Regular DDoS attack

DDoS attacks on net-business disable sales settlement. With regard to the response to this impact

on business, a comprehensive assessment should be made for countermeasures, while taking into

account the business impact and cost for measures.

In the case of the DDoS that causes a line overload (line bandwidth DoS), protective measures

from the website side, and thus, response coordination with the line side is necessary, and should be

included in the contents of the contract. In this case, cost performance should also be taken into

account.

In the case of a processing load DoS attack, the system will be protected by setting up DoS

mitigation functions on the website side. Attack analysis information is required for the setup. Thus,

an organizational line needs to be secured. In the case of a DoS attack against SSL servers, access

to SSL connections will be lost.

Figure 6.12-13 Pattern 6: Regular DDoS attack

The following “basic model of strategic attacks” and “basis for the definition of cyber attack threat

model (information theft attack scenario)” are the compilation of selected cases commonly found in

the behavior patterns from 1 to 4 in relation to the ultimate impact on organizational operations.

First stage: Initial intrusion into the system

First stage: Initial intrusion into the system

Launch of initial malware into the system occurs through various methods. There are many types of

malware. Malware without a vulnerability patch (zero-day vulnerability) and malware to which

anti-virus pattern files are not applied are also used often. Since these malware are launched through

official connections (HTTP&SMTP), the conventional measures in the first stage (such as FW,

523

anti-virus pattern, and vulnerability patch, etc.) are not infallible.

Second stage: Connection to a malware download server and launch of malware attacks

Malware update themselves through the connection with an external malware download server

and receive attack instructions, etc. Since the connections in this case are normal communications

using HTTP, SSL, etc., detection and blocking by FW, IDS, etc. do not work. The attacks in the

second stage are often undetected because they are difficult to find.

Third stage: Continuous information theft and attack instructions

In the third stage, “information theft,” the ultimate objective of the attack, is carried out based on

the remote attack instructions and the information is transmitted to an external source. Since the

attacks are carried out through normal communications using HTTP, SSL, etc., detection and

blocking by FW, IDS, etc. do not work. The attacks in the third stage are often undetected because

they are difficult to find.

The ultimate threat (challenge) to organizations lies in this third of stage attacks.

As long as the intrusion of the main attack force and its attacks (objective theft) are blocked, the ultimate impact on the organization (system) can be avoided, even if the attack strategies cannot be covered by a vulnerability patch or measures for AV patterns.

Blocking communications in the DL server in the 2nd

and 3rd stages

It is recommended first to stop attacks in the 2nd and 3rd stages and avoid the ultimate impact, followed by extermination of viruses and measures against vulnerabilities.

・Presence of objective/intent/infrastructure used for attacksPreparation stage

First stage ・Initial intrusion into the system (various methods)

(1) Initial malware attached to email for targeted attack(2) DL server redirection by website falsification(3) Initial malware through media(4) Slipping away by abusing a digital certificate(5) Embedding of a redirector exploiting website vulnerabilities

Exploiting vulnerabilities

Second stage

・Connection to DL server and launch of offensive malware

(1) Downloading of malware(2) Sending attack instructions, etc.

Launch of preemptive forces

Invasion of main attack forces

Formulation of operation plan

Pursuit evasion by the attack infrastructure (who and where?)

Analysis and tracking of strategic attack patterns

Selection of characteristics for design measures by tracking down the attack patterns (behavior) and monitoring pattern changes

★ Prevention of organizational impact by blocking the second and third stages

★ Annihilation of threats upon obstructing the attack objective

★ Grasping the entire picture of strategic attack patterns and pattern monitoring

In RM, the target is set to organizations

(1) Planning of attacks through multiple schemes

Use of attack infrastructure

In pursuit of achieving the ultimate goal of attack (thef t)

Third stage ・Continuation of information theft and attack instructions

This is the ultimate threat (challenge) to an organization.

(1) Uploading stolen information

Goal-matching concept

Limitations of the zero vulnerability campaign, etc.

Shifting the axis to measures for impact prevention

It is necessary to re-define threats and re-analyze design concepts and organizational operation concepts in order to avoid mission impact

Basic patterns of strategic attacks Measures for system design management

Figure 6.12-14 Common basic model of cyber attacks

Analysis process (2): “To design an information system design model as a system model in

accordance with each characteristic of the system”

524

In order to analyze the behavior of threats (viruses, etc.) when the information system is attacked,

typical configuration cases of information system are grouped into four “system topology models”

Each system topology model is not necessarily used individually; instead, it is assumed to be used

in combination of several models: for example, a combination of “intranet model” and “iDC model.”

A. Intranet model B. Closed model C. iDC model D. SaaS model

The following is an example of the intranet model

No Model name Outline and characteristics of the system topology model

1 Intranet model ・ Information system configuration most commonly used in public and private information systems

・ Operations are carried out by separating the DMZ (DeMilitarized Zone) in which external web server is installed

to the intranet from the in-house system area which does not

allow direct access from external sources.

・ The intranet model includes a system topology that operates by only installing the DMZ area (such as external public

server, etc.) in the iDC.

・ In many small offices (such as a local office, branch office and sub-branch office) the internet is accessed directly

through the in-house system of each premise without going

through a DMZ. Such configuration is included in the intranet

model.

2 Closed model ・ A configuration found relatively often in the medical information system and the FA system of the manufacturing

industry. The information system is complete within the

premise, which is not connected to the external internet.

Since there is no internet connection, no cyber attacks are

made via network; however, the damage is likely to spread if

virus-contaminated USB memories or CDs are taken in

because patterns are not updated or updating of anti-virus

software is delayed.

3 iDC model ・ Use of iDC exhibits a variety of forms. The iDC model in this section assumes the cases where operations covering the

operation systems are conducted on the iDC.

・ Only the cases where the entire DMZ (such as web server for external sources) is installed in the iDC can be handled by

the intranet model. The cases where a part of business is

conducted by the iDC and the rest of the business is

conducted on the in-house internet can be handled in

525

No Model name Outline and characteristics of the system topology model

combination between internet model and iDC model.

・ This model is different from the intranet model in a sense that there is an impact of sharing switches and servers with iDC

users and an impact of administration terminal access from

the iDC to the systems of several iDC users.

4 SaaS model ・ In SaaS, only subscribed users can use services via the internet, and no system resource management is carried out,

such as in a server or DB, etc.

・ A security measure for SaaS that can be carried out by the user is the access control alone, and the rest of the security

measures are entrusted to a SaaS provider. This is the

difference from the system operations that use the iDC.

Analysis process (3): “To analyze the impact and effects of design measures by tracing attack pattern

scenarios on the information system design model (attack simulation)”

Technical methods have been studied as to the best practices to inhibit threats. These methods include

evaluating the effectiveness of security measures installed on the topology by performing a “threat trace”

(attack simulation), which allows the analysis of influential behavior on each “system topology” of the

“behavior patterns (attack sequence and attack specifications)” that have been created using the “behavior

model.” The “threat trace” has been conducted in accordance with the actual attacks that have occurred.

Analysis process (4): “To compile the results of an attack trace” (attack simulation) into the “system

design measures”

Design measures found to be highly effective by the “threat trace” (attack simulation) were

compiled into the “system design measures” according to each behavior pattern.

From the analyses above, the current attack models have common attack specifications with

respect to the ultimate impact on organizational operations, with some exceptions. It is then clear that

they do not depend on system topology forms and attack behavior patterns. This is thought to be

because attack targets have been gradually immerging into one pattern.

Thus, “common attack scenarios and design measures” have been generalized and organized

as below.

○Definition of cyber attack threat model (attack scenario)

○Requirements for RM design measures (collection of requirements for specifications) for the

aversion of the ultimate impact on organizational operations

526

6.12.4.3. Definition of cyber attack threat model (attack scenario) The conventional design measures have been based on the attack story focusing on the first stage

but are now facing limitations in terms of the number of measures and effectiveness.

Meanwhile, the main objective of the common cyber attack threat model (attack scenario) in recent

cyber attacks is information theft through a process from the first to third stage, and the second and

third stages, which involves external access, have a particularly large impact on the organization

(business).

Thus, besides the conventional measures, the attack threats corresponding to the ultimate impact

on organizations are identified as being the second and third stage attack patterns, which are directly

connected to attack objectives, and are based on the various cyber attack cases of today. Then, the

following two cases have been set as attack models commonly found in various attack patterns.

○ “Information theft attack (including falsification of redirection link embedment on the site)”

○ “Service interruption/ suspension attack”

Attack objectives|+---01_Information theft| +---Pattern 1: Malware infection through browsing official website| | +---Variation 1: Browsing websites infected with a gumblar virus| | +---Variation 2: Browsing websites infected with a **.ru:8080 virus| | +---Variation 3: Browsing websites infected with SQL injection | | +---Variation 4: Redirected from the search engines| +---Pattern 2: Targeted email attack (information theft)| | +---Variation 1: File attached email ab| | +---Variation 2: Spam mail directing to unauthorized URL| +---Pattern 3: Redirection by falsified official websites| | +---Variation 1: gumblar.x virus| | +---Variation 2: SQL injection| +---Pattern 4: Malware infection through media (information theft)| +---Variation 1: Conficker (worms) spreading via USB |+---02_ Disruption/suspension of services | +---Pattern 5: Multiple DDoS attack (attack infrastructure)| +---Pattern 6: Regular DDoS attack| +---Variation 1: DDoS attacks on SSL connection|+---Existing threats (attacks still observed today)

Considering the above, the cyber attack threat model (attack scenario) is defined below. It is

assumed that this scenario will also be used as “test requirements.”

527

Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)

First stage process

“Initial intrusion

into system”

Method 1 (1) When the user browses the falsified official website, authentication information

in the general PC is redirected to a malware distribution site by exploiting the vulnerability of software in the general PC.

Method 2

(1) An attacker attaches malicious spoofed emails to the general PC within the intranet.

(2) Malware gets activated when the user opens a file attached to the spoofed mail on the general PC. Consequently, the second stage of the process will follow.

Method 3

(1) The website is falsified from an external source through a separately acquired ftp ID/PW.

(2) Redirection embedment (falsification) is conducted on the website to redirect the user to a malware distribution server.

Method 4

(1) Malware filtered into digital memory media, such as USB memory, enters into general PCs through the media port.

(2) Malware infection spreads from the initially infected PC to other general PCs through the network infection, exploiting memory media, file sharing programs and vulnerabilities.

(3) Malware filtered into the general PC gets activated by exploiting vulnerabilities. Consequently, the second stage of the process will follow.

Note: In the case of file migration operation between open and closed systems through USB, etc., the same attack scenario as the open system is applied to the closed system.


Second stage process

“Connection to

malware download server

and launch of offensive malware”

Method 1

(1) Function update of the malware and other malware will be downloaded by communicating with an external server (command & malware distribution server)

Note: An official site (on the attack infrastructure) that has been taken over is used as an external server.

Note: External server is constantly changing. Thus, blocking a specific address is ineffective.

Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with external server.

Method 2

(1) When the user browses the falsified official website, authentication information in the general PC is redirected to the malware distribution site by exploiting vulnerability in the software on the general PC, then malware will be downloaded.


Third stage process

“Continuation of information theft

and attack instructions”

Method 1

(1) Attack instructions, etc., are sent from the external server (command & malware distribution server) to malware.

Note: Attack instructions, etc., have many specific instructions and it is difficult to clarity or explain the behavior.


Note: The external server is constantly changing therefore blocking a specific address is ineffective.

Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with the external server.

Method 2

(1) Downloaded malware steals authentication information, etc., which is then sent to the external server.


Note: The external server is consistently changing and blocking a specific address is ineffective

Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with external server.

528

Attack scenario of “service disruption/suspension”

Attack process

Method 1

Note: The assumption is that the analysis of attack sources, etc. is difficult because of the flexibility in changing DDoS attack specifications from the official PC, etc., using multiple attack infrastructures. (1) Transmission of a large number of spam mails and destruction of files in the

infected PC, in addition to DDoS attacks (the same as an information theft attack scenario, except for DDoS attack)

Method 2

(2) DDoS attacks by using DDoS tools. Details of attacks are as follows: ・ Searching for simple FTP PW settings (FTP brute force attack) and

falsification of agitation sites. ・ Searching for SQL injection vulnerable sites and falsification of agitation

sites. ・ DDoS attacks by using overseas proxy sites (unable to use country-specific

IP filter). ・ DDoS attacks by using a number of false IPs (unable to use IP filter). ・ Combination of bandwidth-DDoS and load-DDoS attacks.

6.12.4.4. Requirements for RM design measures to avoid ultimate impact on organizational operations Conventionally, the system has been designed based on the concept of “perimeter defense”

against attack methods in the first stage; however, the effectiveness of these measures has become

increasingly limited that attacks on the first stage are often successful.

Thus, examinations were conducted on the “requirements for design measures (including

non-functional requirements) to avoid the ultimate impact on organizational operations” with

emphasis on the measures for second and third stages having large impact on organizational

operations, besides design measures against attack methods in the first stage in the common cyber

attack threat model (attack scenario).

In the information theft attacks, requirements for design measures against common attacks can be

devised since the attack methods in the second and third stages are common. There emerged

threats in the closed system believed to be equivalent to the closed-system threats via media, such

as USB. Since this type of attack technology may be used frequently in the future, requirements are

defined as common design measures regardless of system topology.

Also, the background and objectives of DDoS attacks vary and there are various attack methods

accordingly; however, the type of attack communications is the same from the viewpoint of the

defending system.

Considering the above, the following show the definitions of “requirements for design measures to

avoid the ultimate impact (including non-functional requirements, such as operations management,

etc.)” and “operation conditions as prerequisites for system design” in accordance with the two types

of attack scenarios.

529

Function

requirements item Details of function

requirements Reasons and background for requirements Example of setting

1

Introduction of authentication of dual- element authentication/one-time password

Use of dual-element authentication by combining ftp ID/PW for updating websites and one time password (OTP), etc.

Enhancement of authentication in the case of leakage of ftp ID/PW for website management - Response to Gumblar attacks, etc.

- One-time password OTP)

2 Settings for “LAN for management”

Server management settings for the in-house network, which is not available to external sources (backside LAN)

If the client’s PC infected with malware is used as the terminal for server management, the ftp ID/PW of the site administrator may fall into the hands of the attacker. Embedment of Java Script on the web page can be prevented by limiting the web server for update to a LAN for management (backside LAN) - Response to Gumblar attacks, etc.

- Network topology design

3

Access control of the web server administration terminal

Setting for prohibiting the access to other than designated sites, such as software update for the web server administration terminal

Since the client’s PC may be infected with malware through access to official websites, the infection rate will decline if the access to the administration terminal is controlled, thus reducing the possibility of the theft of critical data, such as the FTP account of the administrator.

- Settings for administration terminal - System proxy settings

4 Checking proxy authentication information

Design of authentication access by authentication proxy at the time of accessing external websites using a general PC

It has been confirmed that authentication information is not often used when a malware transmits information stolen by a unique method of communication to malicious sites. - There is no way of protection if the offensive malware has already been authenticated.

- Authentication proxy

5 Communication control via system proxy

Design of external access via general PC system proxy settings when accessing external websites. Use of firewall, etc. to block external communications that do not go through the proxy using specific port communications (global IP).

When a malware transmits stolen information to malicious sites (theft), it has been confirmed that it often uses an independent communications method using the 80443 port. Many of these communications do not use a system proxy. The malware that uses a global IP for connection trials to an external host can be blocked by FW reel - Ineffective for the malware that uses system proxy settings

- System proxy settings - Setting FW rules

6 Header check of HTTP,SSL connections

Detection/blocking of the contents of HTTP,SSL headers, etc. (GET, POST command)

Many of the following cases uses 80/tcp and 443/tcp: When a malware sends stolen information to the external malicious sites, When downloading new attack code, and When receiving command from C&C server. It has also been confirmed that headers for HTTP connections (method) are deviated from the standard RFC protocol, which is normally used.

7

Use of an Intrusion Detection System (IDS) function (detection of malware download)

Detection of the download of malware and update from external malicious server by using IDS, IPS (In/Out)

IDS (IPS) cannot detect unauthorized communications with unregistered signatures. In order to increase the effectiveness of IDS, timely update of independent signatures for the detection of connections which are different from the usual patters in cooperation with the SOC (Security Operation Center). - However, it depends on the operation capacity of the SOC because it is not an authenticated signature.

- IDS, IPS (including SOC operations)

530

8 Introduction of unknown-virus detection software

Detection of behavior when a malware is exploiting vulnerabilities, including zero day vulnerability

Fight against the unknown virus and unknown vulnerability by detecting an act of attacks from the behavior of vulnerability to a virus on the PC. Products that can detect and protect damage caused by “zero day attacks” have been produced by several companies. - There is a possibility of design/usage consideration as a supplement to existing anti-virus software, upon sufficient evaluation on protective functions and the number of management processes, etc.

- Detection of vulnerability

9 Routing settings, such as router, etc.

VLAN and routing settings limiting to the necessary scope of access by router and SW

In order to minimize the impact on the system, the scope of the attack impact is separated in the network topology design. - Cases of conficker and stuxnet worms, etc.

- Network topology design - Router, VLAN settings for SW

10

Detection of infection activity by monitoring network volume overload

Detection of network infection behavior by volume monitoring, such as file SV, load on SW and log, etc. Settings for abnormal load detection functions on the network and system monitor management functions

Spread of malware network infections within the system can be detected by the network traffic malfunction. Thus, it is effective to monitor the data volume for detection at each site and temporarily blocking connections to routers, etc., in cooperation with the network control department.

Network monitoring function, operation

Requirements for design measures against “service disruption/suspension attacks” (including non-functional requirements for operations management, etc.) Function

requirements item Details of function

requirements Reasons and background for requirements Setting example

1 DDoS mitigation function

Response to DDoS attacks which increase the processing load by setting DDoS mitigation functions, such as FW, balancer, etc. To examine the introduction of DDoS mitigation devices

FW and balancer have DDoS mitigation functions to reduce the impact of DDoS attacks, which increase the processing load, by resetting the device functions in accordance with the DDoS attack instructions. In order to further increase the effect of the measures, consideration should be given to the introduction of the exclusive DDoS device that gives alert to anti-DDoS devices and carries out bandwidth control and access control when detecting communications that have been deviated from the known regular communication traffic patterns. - Cooperation with analyzing organizations for DDoS attack methods, communication details, etc.

- Setting DDoS mitigation functions of FW and balancer - DDoS mitigation device

2 Use of anti-DDoS services of an ISP

Consideration for concluding contracts with ISPs to respond to DDoS attacks that increase load on bandwidth

Even if a DDoS attack has been detected, an individual protection is difficult against a large-scale attack. An ISP provides anti-DDoS measures using a strong backbone. The use of such products should also be considered, when necessary.

- Use of anti-DDoS services

Operation conditions as prerequisites of system design

1

Framework for response to damage as a prerequisite for design

It has become clear from the analysis of attack behavior and attack patterns of recent cyber threats that cyber attacks have advanced. Thus, it is becoming difficult for an individual system department of the user organization to analyze the details of attacks and to take proper recovery measures. A prerequisite for attack response is to clarify the response and division of roles by incorporating the communication and cooperation framework with security vendor or system integrator SIer at the time of designing operation framework.

2

“Preparation for initial response operation procedures” such as blocking infectious communication ports, etc.

“Preparation for initial response operation procedures” to suppress the spread of infections within the system through a containment by blocking or temporary separation of infected communication ports at router sites. *A difference in response speed occurs depending on the preparation of procedures and operations management. *Closing procedures for infected ports of the router and SW *Comprehensive understanding of network failure and server failure and preliminary study on the section to be separated. *Detection procedures by volume monitoring, such as file-SV and load on SW and log, etc.

531

6.12.5. Descriptions concerning security in service in each procurement area

Requirements for security services to be described by each procurement area are included in the

services of the TRM of each procurement area. Security notes and the outline of services described

in each procurement area are shown below. For actual procurement, a check should be carried out to

see whether consideration has been given to the notes listed below.

●6.2. Support for procurement

Notes Outline of notes Corresponding items in TRM

Definition of information security requirements

The customer and the compiler of specifications shall define the information security requirements in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry. Since the following requirements are particularly required for entry in the Basic Guidelines for Government Procurement Related to Information Systems, they shall be clearly and specifically defined. (1) Definition of authority management (2) Definition of security measures The term “authority management” refers to the management of information pertaining to entity authentication (including identification code and entity authentication information) and approval information pertaining to access control

6.2. Support for procurement 2. Support for definition of requirements

532

●6.3. System integration (design/development) *Applied commonly to 6.3-1~6.3-4

Service item Outline of service Items corresponding to TRM Security measures for development environment

The contractor shall take sufficient information security measures for the environment for development (device, workplace, etc.) when such an environment is prepared by the contractor.

Preparation for development environment

Information security design

The contractor shall carry out information security design in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry.

Basic plan Detailed plan

Security measures for test environment

The contractor shall take sufficient security measures for the test environment (devices, workplace, test data, etc.) when such an environment is prepared by the contractor.

Unit test, system test, comprehensive test

User training The contractor shall provide information security training for system users.

User training

Information security management

The contractor shall prevent an occurrence of a security-related incident or fault, etc. during each work process. The contractor shall also report to the customer immediately after the occurrence of an incident and minimize the damage as much as possible.

Project management

533

●6.4.Operation

Notes Outline of notes Items corresponding to TRM Handling of operation framework

If a document contains personal information, such as an organizational chart, etc., the document shall be handled in accordance with the importance stipulated in the regulations.


534

●6.5. Helpdesk

Service item Outline of service Items corresponding to TRM Creating of an outline of implementing information security measures

An outline for implementing information security measures shall be created in the helpdesk operation plan, which shall be finalized upon consultation with ministries.


Training for helpdesk staff

The contractor shall provide helpdesk staff with training on information security measures to be implemented in helpdesk services.

Development of work environment

●6.6.1. Hardware maintenance

Service item Outline of service Items corresponding to TRM Revision of firmware, configuration change, etc.

The contractor shall obtain the most recent information on firmware related to the stability of security and hardware, such as BIOS, and require the hardware maintenance company to implement updates whenever necessary.

Support for version upgrade

●6.6.2. Software maintenance

Service item Outline of service Items corresponding to TRM Provision of information on security patches

The contractor should provide application maintenance company or system infrastructure maintenance company with information on software bugs, patches and version upgrades, etc. as soon as such information becomes available and should also instruct the application maintenance company or system infrastructure maintenance company to conduct preliminary patch applications. In order to determine the propriety of the immediate patch application, there is a way to add the application maintenance company and the system infrastructure company to the list of recipients of information provided by the software maintenance company, such as information on software version upgrades, etc.

Provision of modification (patch) files, version upgrade programs

535

●6.6.4. System infrastructure maintenance

Service item Outline of service Items corresponding to TRM Information provision and application of security patches

The contractor shall immediately report to the ministries on information pertaining to technical issues of information systems, security vulnerability (security holes), software bugs, patches and version upgrades, etc. In response to the request from the ministries, the contractor shall carry out patch application possibility verification work, patch application work and technical advice for software.

Updating system infrastructure software

●6.7. Tasks incidental to device procurement

Notes Outline Items corresponding to TRM Security design The contractor shall create a security

design in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry and implement information security measures accordingly.

On-site study/design

Security settings/adjustments

The contractor shall carry out environmental settings and various adjustment work necessary for this system, using the procedures concerning the existing system, introduction method, and the created security design.

Device setup

Updating virus definition file

The contractor shall update the virus software and virus definition files to keep them in the most recent status at all times.

Device setup

●6.8. Tasks incidental to procurement of iDC equipment

Notes Outline Items corresponding to TRM Security monitoring The contractor shall make regular reports

to the relevant official of the ministry about the status of security monitoring (scrutinizing of firewall logs and monitoring of unauthorized accesses, etc.), as well as the monitoring results.

Operation/maintenance (daily)

Security diagnosis and reporting

The contractor shall carry out a regular diagnosis on vulnerability (status, impact and response methods) and report the results to the relevant official of the ministry.

Operation/maintenance (monthly)

536

●6.9. Network procurement

Notes Outline of notes Items corresponding to TRM Definition of information security

The contractor shall specifically define the information security measures in accordance with the importance and risks of information assets in pursuant to the information security policies of the ministries based on the “Standards for Information Security Measures for the Central Government Computer Systems.”

Design/development plan

Requirements for information security (measures)

The contractor shall follow the security policies and security guidelines of the ministry in order to carry out an overall security measure program that has been acknowledged in the market. The contractor shall maintain the security level for operations. The contractor shall cooperate and coordinate with the existing operation and maintenance company for the security measures to be taken on the entire network.

Design/development

Disposal of devices The contractor shall delete data completely after the removal and displacement of unnecessary devices to prevent a third party from recovering the data using date recovery software, etc., except for the cases of destroying the devices.

Design/development

Security design The contractor shall either implement the security policy design (encryption, FW, IDS/IPS, quarantine) and encryption design (specifications for encryption, encryption method, encryption algorithm) or follow the rules presented as equivalent to the specifications.

Design/development

Security inspection Vulnerability of network devices to be introduced may be verified at times and disclosed by third organizations, etc. If there is a problem, the contractor shall take appropriate measures.

Design/development

537

Security test The contractor shall surely implement tests on information security. Vulnerability of network devices to be introduced may be verified at times and disclosed by third organizations, etc. If there is a problem, the contractor shall take appropriate measures.

Support for test and migration judgment

Handling of incidents The contractor shall establish a communication framework to promptly receive information on network faults and security incidents.

Operation/maintenance

Security diagnosis and reporting

The contractor shall constantly monitor the traffic status of lines. If there is abnormal traffic, etc., the contractor shall carry out a causal investigation and report to the relevant official via the existing operation and maintenance company.


Security inspection The contractor shall take measures promptly when a necessity for improving an introduced network device’s vulnerability has been pointed out.


6.12.6. Procurement of services specialized on security

(To be created)

538

6.13. Other

(To be created)

539

7. Recommended Technology Standard

This chapter describes the examples of technology standards that should be given priority in

information system procurement by the government, as well as in the guidelines for selecting them.

The following two documents are the main source of reference information in drawing up the

guidelines for selecting recommended technology standards.

• Framework for Interoperability Relating to Information Systems (Jun. 2007) http://www.meti.go.jp/press/20070629014/siryou.pdf

• The first issue of TRM: Report on the results of validity examination (Feb. 2004) http://www.ipa.go.jp/software/optimize/pdf/technicalveri.pdf

The technology standards have been selected from the viewpoint of implementing separated

procurement as indicated in the procurement guidelines, and the scope of the technology standards

is not intended to be all-inclusive for the technologies to be procured.

7.1. Requirements for technology standards in conformity with the “Framework for Interoperability Relating to Information Systems”

The following is an excerpt from the “Framework for Interoperability Relating to Information

Systems”:

In view toward procuring higher quality information systems - which involves the need for

expanded options for information system construction in governmental/public organizations,

and a fair and transparent procurement environment with proper price settings – promotion of

the following measures are needed to be set forward in the new development and

refurbishment of information systems: withdrawing from dependency on the vendor’s

proprietary technologies, and further pursuit toward openness in the government information

systems.

In the “Basic Guidelines for government procurement related to information systems,” the

government indicates that, regarding the design and development processes, separated

procurement should be the basic procurement policy for the basic infrastructure system and

in each of the functional systems. These individual functional systems, realized by means of

separated procurement in conformity with the basic guidelines, are integrated through the

intermediary of the common infrastructure. The individual functional systems, as a functional

unit, as well as an integrated whole of functional units, must realize all the functions required

http://www.meti.go.jp/press/20070629014/siryou.pdf

http://www.ipa.go.jp/software/optimize/pdf/technicalveri.pdf

540

in the business processes, where information exchange with other individual functional

systems, as well as with the common infrastructure, should be necessary. This translates into

the requirement of interoperability among individual functional systems, and between each of

them and the common infrastructure.

As separated procurement should become the basic policy in the future, as describes above, it

entails the need to select technology standards with priority placed on “interoperability” while

promoting the move toward “separated procurement” and “open architecture.” In addition, selection of

an “open standard” should be the overriding challenge because fair and equitable procurement is the

major premise in government procurement.

7.1.1. Definition of “Opening” and “Open Standard” In the “Basic Guidelines for government procurement related to information systems,” the term

“Opening” is defined as follows.

Lowering of dependency on specific vendor’s proprietary technologies - in terms of

procurement, maintenance and operation - through the breakdown of the information systems

into individual procurements and exchangeable/standardized components, thus enabling an

expansion of the range of business entities eligible to participate in procurement, maintenance,

and operation services.

The “open standard” here represents the technology standards that meet, in principle, all the

following items.

• The technological specifications have to be agreed upon through an open participatory process, and provide disclosure specifically to the level that allows concrete implementation.

• Adoptable by any party.

• Many examples of the technology standard have been launched onto the market.

7.1.2. Requirement to ensure validity as a standard technology In the “Framework for Interoperability Relating to Information Systems,” the following requirements

are placed on the technologies referenced in the TRM, with a view toward standardizing

specifications – an essential element to secure validity as a standard technology.

• The technology is one with standard specifications defined under the initiative for standardizing organizations and other parties, or one in the process of standardizing.

• Management of intellectual property rights (IRP) has to be defined clearly in the standard in a way that allows any party to implement the specifications freely without the possibility of being

541

charged unduly.

From the viewpoint of technological requirements, the following items are to be examined for the

selection of technological standards.

• Track record of successful connections of standards-compliant implementations, or perspective of achieving such connections (verification of connectivity) – a requirement to

ensure interoperability among information systems.

• Track record of successful porting of an application from one standard-compliant implementation to another implementation compliant to the same specifications, or a

perspective of achieving such a porting (verification of portability) – a requirement to ensure

portability of information systems.

• Provision of functions and features that enables continuous expansion and maintenance, including upgrade feasibility and independence from a specific platform (verification of

continuity into the future) – a requirement to ensure usability in the future.

• Applicability of the technology to such business processes as front-office, middle-office, and back-office tasks performed in the ministries, as the TRM assumes these tasks as its

objectives (verification of affinity for the current system).

7.1.3. Guidelines required to establish technology standards In the “Framework for Interoperability Relating to Information Systems,” the guidelines to be

followed by the information system designers and the persons in charge of procurement are provided.

Basically, these guidelines should also be applied to the selection procedures of technology

standards. The guidelines are listed below.

• To expand the range of bidders in the tendering process of separated procurement, restrictions on physical computers and platforms on which the separated functional units operate should

be reduced to a minimum.

• To ensure interoperability among technology components as well as component-by-component exchangeability among them, the technology components deployed in the upper layer must

consist of standardized components – in terms of functions and interfaces provided by the

lower layer technology components - that employ solely the functions and interfaces

compatible with the requirements of an open standard.

• In cases where a functional component based separated procurement and expanded range of options are desired, restrictions on the platform on which the functional components operate

should be reduced to a minimum. Therefore - within the bounds of what the non-functional

requirements permit in terms of performance, security and stability – the service infrastructure

used to invoke external functions should be selected based on the criteria that it can maintain

platform-independence.

• As the data format for data capable of long-term accumulation and exchanged/repeated

542

utilization among a plurality of users, an open and standardized data format should be adopted.

In case more than one open standard is eligible, XML-based standards with a lower

dependence on platforms and specific technologies should be preferentially adopted. In case

more than one XML-based open standard exists, the priority should be given to those with a

plurality of products and vendors that support the standard, especially with future expectations,

from the view of marketability, of wider support from an expanding range of products and

vendors.

• In cases where a functional component based separated procurement and expanded range of options are desired, restrictions on the platform on which the functional components operate

should be reduced to a minimum. In line with this, the format used to exchange messages

among the functional components should also be platform-independent within the bounds of

what the service infrastructure selected for external function invocation permits.

• XML should be used as the message format for exchange among the functional components, as it has lower dependence on platforms and allows description of the message’s logical

structure as a schema. The XML schema must adopt an open standard on a priority basis, and

should be extended as needed. The adopted schema must be made open if interoperability

with external systems is required.

• In conformity with the provisions stipulated in the “Agreement on Government Procurement (GPA)” (Chapter 6-2), international standards and Japanese Industrial Standards should have

priority as the standards to be referenced to by the procurement specifications. In case no

relevant international standards nor Japanese Industrial Standards exist, the next option to

make of reference should be one of some other open standards.

7.2. Items for technology standard evaluation cited in “TRM 1st issue: The Report on the Results of Validity Examination”

In the selection process of important technologies in the 1st issue of the TRM (2004), the following

items were put forward as evaluation criteria.

• The following fact must be included as one of the evaluation items: the technology to be evaluated has been standardized (or is in the process of being standardized) by a

standardizing organization as a set of standard specifications.

• Importance must be placed on the fact that the set of standardized specifications has a wide implementation base, and meets the conditions for widespread use, i.e. the management of

intellectual property rights is clearly defined in the standardization processes in a way that

allows any party to implement it freely without the possibility of being charged unduly.

Therefore, the management status of the intellectual property rights must also be taken into

consideration for the selection of a standard.

• To ensure interoperability among information systems, a track record of successful

543

connections among the standards-compliant implementations, or the perspective of achieving

such connections, must be an item of technological evaluation.

• To ensure portability of the information system, a track record of successful porting of an application from one standards-compliant implementation to another, compliant to the same

specifications, or the perspective of achieving such a porting, must be an item of technological

evaluation.

• One of the technical evaluation items must be the provision of functions and features that enables continuous expansion and maintenance to ensure usability in the future, including for

example, expansion feasibility (scalability) and independence from a specific platform.

• One of the technical evaluation items must be the applicability of the technology to such business processes as the front-office, middle-office, and back-office tasks performed in the

ministries, as the TRM assumes these tasks as its objectives.

• One of the technical evaluation item must be practicality, as well as the potential for the future development of the target technology, as it must be introduced in actual systems and

continuously utilized.

7.3. Guidelines for the Selection of Recommended Technology Standards

7.3.1. Criteria and items of evaluation

In the selection process of the recommended technology standards, which should be derived

based on the “Framework for Interoperability Relating to Information Systems” and the first issue of

the TRM “The report on the results of validity examination,” the candidates must be evaluated in

accordance with the six – as mutually independent as possible - criteria: openness, equitability,

compatibility with business requirements, interoperability, potential for development, and government

regulation.

The evaluation should be quantitative to the maximum possible extent. An appropriate weight

assignment to each of the criterion is also required in view of the particular circumstances of the

objects to be procured and the organizations (the Cabinet Office and Ministries) that perform

procurement. Each of the evaluation criteria is described below.

7.3.1.1. Openness

Openness generally refers to the circumstances where any interested party is able to acquire

information without being hindered by special conditions or barriers, and is also able to grasp the

situations surrounding the standard specifications (e.g. the issue under discussion and the progress

of deliberation) to a satisfactory extent. It implies, as a consequence, the considerations incorporated

in the scheme that the standard specifications, and the organizations that establishes them, should

not endow special interests – from a technical point of view - to particular vendors and groups.

As the scope , or openness, covered by this evaluation criterion is wide, classification is made into

544

the following seven categories: “Openness of participation to the standardizing

organization/committee,” “Openness of decision making processes (including maintenance/support

systems) ,” “Openness of released technical specifications,” “Openness of IPR policy,” “Openness of

data format,” “Vendor independency,” and “Platform independency.” Specific criteria are shown for

each evaluation category.

a) Openness of participation to the standardizing organization/committee

The agency that institutes the standard must be a standardizing organization independent from

specific interest groups. The standardizing organization must not be one whose intention is to provide

benefits to particular parties. Any party, including interested parties - as long as it meets a given set of

conditions - must be allowed to participate in standardizing organizations and deliberative committees.

The set of conditions described above must not contain items that restrict professional affiliation,

expression of thought or opinion, or with a vested interest of the participants.

b) Openness of decision making processes (including maintenance/support systems)

A clear and easy-to-understand decision making process must be provided that enables open

deliberation, including acceptance of requests for content modification of the standard specifications.

Furthermore, a well-organized system must be in place to maintain/support the standard

specifications, whereby parties independent from particular interest groups will take responsibility for

carrying out these tasks.

c) Openness of the released technical specifications

The standard specifications must be released openly in their entirety, enabling all people to gain

access to them on an equal footing.

d) Openness of IPR policy

The conditions regarding IPR policy must be clearly declared.

e) Openness of data format

The data format must be exchangeable, in terms of “convertibility,” with other applications. It must

not depend neither on specific platforms nor on specific applications (from the point of view of the

“Independence of data formats”). In case a plurality of open data format standards exist, from the

viewpoint of the “proactive adoption of a standard capable of data attribute description,” a standard

that comes with a data attribute description capability, or with a standardized schema format must be

preferentially adopted. In particular, in cases where interoperability with external systems is required,

the adopted scheme must be put on open view from the viewpoint of the “disclosure of the schemes.”

f) Vendor independency

The standard specifications must not depend on the products or proprietary technologies of a

545

particular vendor.

g) Platform independency

The standard specifications must be independent from a particular platform to ensure the

information system is compliant to the standard to be utilized into the future, and enables continued

expansion and maintenance. An open standard (schema) must be preferentially adopted, for example,

an industry standard (XML schema) should be given priority.

7.3.1.2. Equity This is an evaluation criterion in terms of the provision of equity in various processes performed by

the standardization organizations and the practices of the standards themselves. The objective of this

evaluation criterion is to eliminate discriminatory conditions or barriers incorporated in the

standardizing processes and the content of the standard itself, and to avoid providing any interested

party with an advantage over others, or conversely, to handicap any party. Equity is often confused

with openness, but the “Evaluation criteria of standards” clearly distinguishes them. The evaluation

items related to this are as follows:

a) Equity of the standardization process

More than one steps must be placed through the process starting from early proposals to the final

approval as a standard, and consensus must be achieved in every one of them in terms of the level of

maturity of the proposed drafts and the contents of deliberation.

b) Consensus based decision making

In the deliberation processes, every effort must be made to reach a unanimous agreement.

c) Equity of decision making

In the decision making process, all participating persons and organizations must be allowed to

execute their own will.

d) Equity of the IPR policy in place

The IPR policy, which has an impact on the utilization of standard specification, must be equitable

and rational to all the users and allow implementation without the possibility of undue charging (e.g.

royalty-free).

e) Equitable maintenance/support system

Any maintenance/support operations of the standard specifications must not provide special

advantages to particular vendors or applications.

546

7.3.1.3. Compatibility with business requirements These evaluation items provide criteria to measure to what extent the standard specifications meet

the needs of the development objectives, functional requirements, and user needs. Specific

evaluation items are as follows:

a) Relevancy to standard specifications

The standard specifications must provide useful and practical measures to solve specific problems.

b) Relevancy to the standardizing organization

The organization that defines the standard specifications must establish specifications that are both

useful and practical for solving specific problems.

c) Conformity with functional requirements

The standard specifications must include technologies conducive to meeting specific requirements.

d) Definiteness of users and objectives

The standard specification must provide clear indications as to “who should use the standard to

solve what type of problem.”

e) Provision of guidelines for applying the standards

Guidelines must be provided to unify application methods of the standard specifications (e.g.

profiles, guidelines), especially in cases where the definitions of the specification allow for a scope of

selection.

7.3.1.4. Interoperability Interoperability designates a set of evaluation criteria that enables such characteristics among the

standard-compliant products and services as: data exchange, replacement by other products,

version-to-version compatibility, and connectivity with other systems, thus preventing various aspects

of the implemented systems to be locked in by a specific vendor. Specific evaluation criteria in this

regard are as follows:

a) Warranty of portability

Track record of successful porting, or a promise of porting, of an application from one

standard-compliant implementation to a dissimilar implementation compliant to the same standard is

required.

b) Standard-to-standard/specification-to-specification interoperability

To realize mutual utilization among standard specifications – i.e. in cases where a plurality of

standard specifications with mutually equivalent functionalities are given – the compatibility among

547

the standards must be guaranteed for the user to select the most suitable one.

c) Version-to-version compatibility

To ensure affinity with the existing standards, the technology must be applicable to existing systems.

This requires upward compatibility to the related standards.

d) System-to-system interoperability

To promote affinity with other systems, the standard must provide a scheme to facilitate linkage with

other systems (including upward applications).

7.3.1.5. Potential for future development Criteria to measure indirect effects gained by adopting a standard specification – e.g. the results

obtained by selecting a standard specification, the impact caused by the selection, and the promise of

future development of the standard. Specific evaluation items classified into this category are as

follows:

a) Ease of extension

To ensure utilization into the future as well as continuous extension and maintenance, the standard

specification must be equipped with the inherent features that will allow easy applications in other

fields other than those originally intended.

b) Scalability

The stipulations provided by the standard specification must be capable of meeting objectives that

are upgraded in size and number.

c) Future potential of technology

The technology – even if it is the most sophisticated at the moment - must be capable of embracing

further improvements in the future.

d) Permeation of the standard specification

A sufficient number of standard compatible products/implementations must be in place from a

plurality of independent vendors, so that the user can have multiple options. In case a plurality of

open standards (e.g. XML) exist, priority for selection must be given to those with a promise of

achieving support from larger number of products and vendors.

e) Maturity of technology

The contents of the specifications must be disclosed openly in a concrete manner to the level that

allows implementation. It is desirable that the standard specification will be in use in a stable form

over a long period of time, with necessary modifications when needed basis as defects are detected.

548

7.3.1.6. Government regulation The Japanese government’s policy imposes a set of requirements on industrial sectors in general.

In particular, adherence to these requirements is sought after in government procurements, making

these an integral part of the evaluation items for selecting a standard specification. Some of the

specific evaluation items are shown below:

a) Accessibility

The evaluation items must be compatible with the accessibility requirements stipulated by the

government.

b) Security

The evaluation items must meet the security criteria stipulated by the government.

c) Green IT

The evaluation items must make an effort to achieve environmental objectives.

d) Privacy

The evaluation items must comply with the “Basic Policy on the Protection of Personal Information”

enacted by the government.

7.3.2. Classification and evaluation criteria of standards

As the target areas of the standards cover a broad array of information technologies, it is

considered inefficient to apply the same evaluation criterion on standards with different scopes of

application. Therefore, the information technology-related standards are broadly classified into the

following nine categories, for each of which a set of category-specific evaluation criteria are defined in

addition to the common criteria. Note, however, that certain standards with very wide applicable areas

may belong to a plurality of categories.

7.3.2.1. Meta-data definition A specification to define syntactic notations and their meanings used in the data definition.

7.3.2.2. Data definition A specification to define binary data formats and data description methods for a text format. The

specification may contain a description of the algorithm used to create the defined data format. Some

definition methods utilize one of the existing meta-data definition specifications, and some may define

their own in their data definition specifications. In the latter case, the data definition includes attributes

for meta-data definition.

549

7.3.2.3. Definition A specification to define the data format – e.g. term definitions, correspondence tables, and code

tables.

7.3.2.4. Algorithm definition A specification to define notations – in terms of syntax and semantics – used to realize an algorithm.

The notation for algorithm definition may use a meta-data definition (e.g. BNF). The specification may

contain a data definition method that is itself manipulated by the algorithm, in which case a set of

attributes for data definition is included.

7.3.2.5. Presentation A specification to define the conversion rules required to achieve user-machine communication – to

present a computer’s internal data to the users, and transmit user instructions to the computer – and

the guidelines describing the rules’ usage.

7.3.2.6. API Specifications to define an interface used to provide services to other programs. The API standard

specification is designed to enhance the freedom of combination among programs. It defines the

following information, as a language binding, required by the caller program to invoke others:

prerequisites for calling, calling name, functions provided, information required to hand over at the

time of invocation, and actions to be taken when the task is normally processed, but abnormally

ended.

7.3.2.7. Protocol The specifications to define the following interactive procedures performed in coordination among a

plurality of programs to achieve a function: calling sequence to accomplish a definite lump of

functionality, the effect to be obtained in a call, and the data format used by each program to

exchange information. The specifications of upper layer protocols are often determined based on the

functions provided by those used in lower layers. API definitions are required to use the protocol of a

program.

7.3.2.8. Algorithm The specifications to determine the mode of processing. Those that determine the encryption

method, data compression method, and others.

7.3.2.9. Process The specifications that define activity processes for an organization, a person, and other entities, or

those that define the methods used to perform an audit on conformity of the process with given rules.

550

These include the rules used to examine if the products are compliant with standards.

7.4. Recommended Technology Standard

This section describes some examples of technology standards that should be given preference in

an information system procurement by the government. Note that the technology standards cited in

this section are for illustrative purpose only: they may be extended or modified in the future as

investigations proceed in accordance with the selection guidelines for recommended technology

standards.

[TRM_STD] ISO/IEC 10646 Recommended standard:

ISO/IEC 10646:2003 Information technology - Universal Multiple - Octet Coded Character Set

(UCS)

ISO/IEC 10646:2003/Amd 1:2005 Glagolitic, Coptic, Georgian and other characters

ISO/IEC 10646:2003/Amd 2:2006 N'Ko, Phags-pa, Phoenician and other characters

JIS X0221:2007 Universal Coded Character Set (UCS)

Remarks (noteworthy reasons for recommendation, etc.):

Characters from around the world have been extensively collected and coded to constitute

ISO/IEC 10646. The standard was instituted by ISO/IEC JTC1, and has been implemented in the

majority of OSs and internet applications with well-established interoperability.

[TRM_STD] TCP/IP Recommended standard:

IETF FC 791: Internet Protocol

IETF RFC 793: Transmission Control Protocol


TCP/IP (Transmission Control Protocol/Internet Protocol) is the standard protocol used in the

Internet and intranets. IP takes care of the 3rd layer (network layer) of the OSI Reference Model,

and TCP the 4th layer (transport layer). TCP/IP has been implemented in all Internet systems,

including Webs, as a basic protocol, and its interoperability is well established. Continuity into the

future is also guaranteed as it will continue to be the protocol of the Internet, as long as the Internet

as we know it exists.

[TRM_STD] HTTP Recommended standard:

IETF RFC 2616 HyperText Transfer Protocol - HTTP/1.1

551

JIS TS X 0085:2004 HyperText Transfer Protocol - HTTP/1.1


HTTP is a request-response protocol connecting the servers and clients. Text data of XML and

other formats is exchanged using this protocol. HTTP is the base protocol for Web systems and

implemented in all of them, meaning that interoperability is well proven. The data type to be

transmitted can be specified using MIME types, providing flexibility as well as ease of expandability.

As long as the Web as we know it continues to exist, continuity of the protocol into the future is also

guaranteed.

[TRM_STD] SQL

Recommended standard:

ISO/IEC 9075-1:2003

Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework)

ISO/IEC 9075-2:2003

Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation)

ISO/IEC 9075-3:2003

Information technology - Database languages - SQL - Part 3: Call-Level Interface (SQL/CLI)

ISO/IEC 9075-4:2003

Information technology - Database languages - SQL - Part 4: Persistent Stored Modules

(SQL/PSM)

ISO/IEC 9075-9:2003

Information technology - Database languages - SQL - Part 9: Management of External Data

(SQL/MED)

ISO/IEC 9075-10:2003

Information technology - Database languages - SQL - Part 10: Object Language Bindings

(SQL/OLB)

ISO/IEC 9075-11:2003

Information technology - Database languages - SQL - Part 11: Information and Definition

Schemas (SQL/Schemata)

ISO/IEC 9075-13:2003

Information technology - Database languages - SQL - Part 13: SQL Routines and Types Using

the Java TM Programming Language (SQL/JRT)

ISO/IEC 9075-14:2006

Information technology - Database languages - SQL - Part 14: XML-Related Specifications

(SQL/XML)


SQL is a query language used to define and manipulate data on a relational database. The SQL

552

is a ISO/IEC JTC1 standard, and implemented in all relational database products. Continuity into

the future, as a base language for relational database manipulation, is ensured as long as relational

databases remain in use.

[TRM_STD] LDAP (Lightweight Directory Access Protocol) Recommended standard:

IETF RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol


LDAP is a protocol used to access directory databases, which take control of various

network-related information (user name, machine name, etc). LDAP has a wide spread use in many

implementations provided by various vendors, thus its interoperability is well established.

[TRM_STD] XML (eXtensible Markup Language) Recommended standard:

W3C eXtensible Markup Language (XML) 1.0

JIS X 4159:2002 eXtensible Markup Language (XML) 1.0


XML is a general-purpose data description language used to express structured data in text

format. As XML uses solely texts for description, it can maintain lower dependence on platforms

and proprietary technologies (see the explanation in 6.1.3 “Guidelines assigned to technology

standards”). XML’s ability to clearly define the logical structure of the message as a schema

enables it to be used in all areas, as well as providing ease of expansibility and interoperability. Its

use in variety of fields is well underway – including the methods to express document contents and

the inner structure of applications – and has secured continuity into the future. It also meets the

portability requirements, as it has a verified track record of XML data exchanges among the

XML-based middleware and applications developed on a plurality of dissimilar platforms.

[TRM_STD] XML Schema Recommended standard:

W3C XML Schema Part 1: Structures Second Edition

W3C XML Schema Part 2: Datatypes Second Edition


W3C’s XML Schema (Part1, Part2) is a schema description language used to define a set of tags

for each specific application and specification. The schema defines the elements, attributes, and

hierarchic structure among the elements, and almost all varieties of industry standard XML use

W3C XML Schema. Nearly all of the tools and applications are compatible with the W3C XML

553

Schema, exemplifying well verified interoperability. As an XML structure defining language, W3C

XML Schema allows easy re-definition of information structures as well as easy extension.

[TRM_STD] WSDL (Web Services Description Language) Recommended standard:

W3C Web Services Description Language (WSDL) 1.1


WSDL is a language to define the framework – locations of Web service, message format for

information exchange with the Web service and applications - used to describe the functionality of

Web services and the interface to access these services. Many services that provide WSDL and the

tools for generating it are already in place – e.g. The WS-I Basic Profile defines the profile that

guarantees the interoperability of WSDL. It uses XML as the description format, which provides

independence from a particular OS along with an ease of extensibility. Continuity into the future is

also apparent – e.g. SOA utilizes this language.

[TRM_STD] WS-I Basic Profile Recommended standard:

ISO/IEC PRF 29361

Information technology - Web Services Interoperability - WS-I Basic Profile Version 1.1


WS-I Basic Profile is a profile that shows the guidelines for utilizing various functions provided by

Web-related service standards (SOAP, WSDL, etc). The profile has an effect of enhancing the

interoperability of Web services among products. As exemplified by the effort to incorporate new

standards into the profile in line with the developments in Web service related standards, WS-I

Basic Profile is prepared for continuity into the future.

[TRM_STD] SOAP Recommended standard:

W3C Simple Object Access Protocol (SOAP) 1.1


SOAP represents a basic protocol used for invoking Web services. Connections (message

exchange, etc) using SOAP have been experimented with in a variety of industrial sectors, and

many products supporting this protocol are already in place. DOPG (now-defunct Distributed Object

Promotion Group) confirmed product-to-product connectivity using SOAP, and the interoperability of

this scheme at the practical level has been verified. It employs XML as the description format to

gain independence from particular OSs and to achieve easily extendable specifications, giving

554

promise for continued utilization into the future.

[TRM_STD] X.509 Recommended standard:

ISO/IEC 9594-8: 2001

Information technology - Open Systems Interconnection - The Directory: Public-key and attribute

certificate frameworks

JIS X5731-8: 2003 Open Systems Interconnection - The Directory: Part 8 “Framework for

certification”


X.509 represents a set of specifications that defines the standard format for public-key

certificates, the algorithm used in pass/fail checking of certificates, and other items. X.509-based

electronic certificates have been used globally in electronic certification processes for

e-Governments. Many private-sector certification organizations have also adopted this standard. In

coordination with each other, these organizations constitute PKI, providing a well-verified

interoperability. X.509 - as a international standard defined by ITU-T - is currently undergoing

incremental upgrade/modification, and has continuity into the future.

555

Appendix 1 Case Examples of Procurement

1. Common to all government organizations A database of information system-related government procurement cases:

Covers procurement cases processed by the administrative bodies in the government

http://cyoutatujirei.e-gov.go.jp/

2. Procurement specifications (drafts) prepared by government offices and ministries Cabinet office: Information system-related government procurement

<Integrated information system used for Public Interest Corporation Commission>, <Business

operations/systems required for executing economic/financial policy-related services>, and others.

http://www.cao.go.jp/others/kichou/it/gyouseijouhou.html

National Personnel Authority: National Personal Authority-related government procurement information

<Announcement of general competitive bidding>, <Request for comments> and others

http://www.jinji.go.jp/tyoutatu/index14.4.1.htm

Financial Services Agency: Procurement information

http://www.fsa.go.jp/common/choutatu/index.html

National Police Agency: Government procurement information of information systems

http://www.npa.go.jp/chotatu/seifu_choutatsu/seifu_choutatsu.html

Ministry of Internal Affairs and Communications: Provision of procurement information within the ministry, accounting section of the minister’s

secretariat, government procurement information/planning competition, public offering, etc.

http://www.soumu.go.jp/menu_sinsei/cyoutatsu/cyoutatsu.html

Procurement information of the Statistical Bureau, Director-General for Policy Planning (Statistical

Standards) & Statistical Research and Training Institute, bid invitation

http://www.stat.go.jp/info/chotatsu/mokuji.htm

http://cyoutatujirei.e-gov.go.jp/


http://www.jinji.go.jp/tyoutatu/index14.4.1.htm


http://www.npa.go.jp/chotatu/seifu_choutatsu/seifu_choutatsu.html

http://www.soumu.go.jp/menu_sinsei/cyoutatsu/cyoutatsu.html

http://www.stat.go.jp/info/chotatsu/mokuji.htm

556

Design and development of the sharing system for government statistics

http://www.stat.go.jp/info/guide/public/05/kaihatsu.htm

Ministry of Foreign Affairs: Procurement information of the Ministry of Foreign Affairs

http://www.e-procurement.mofa.go.jp/kokuji/SyuruiSentaku.html

Ministry of Finance: Government procurement information (all ministries)

http://www.mof.go.jp/jouhou/tyoutatu/seihutyoutatu.htm

Procurement information for Tokyo Customs

http://www.customs.go.jp/kyotsu/chotatsu/tokyo.htm

Ministry of Health, Labour and Welfare: Publication of procurement information relating to information systems

http://www.mhlw.go.jp/sinsei/chotatu/chotatu/index.html

Ministry of Agriculture, Forestry and Fisheries: Bidding information (information regarding the government procurement of information systems)

http://www.maff.go.jp/j/supply/index.html

Ministry of Economy, Trade and Industry: List of bidding information (all ministries)

http://www.meti.go.jp/information_2/publicoffer/00_bid_news_list.html

Others: Ministry of Economy, Trade and Industry CIO/CTO training, 5. Request for proposal templates

(included in procurement support document)

http://www.meti.go.jp/policy/it_policy/CIO/index.html

Preparations manual for making outsourcing specifications of system developments in the Ministry of

Economy, Trade and Industry (plan): request for comment (Jul. 28, 2003)

http://www.meti.go.jp/feedback/data/i30728aj.html

http://www.stat.go.jp/info/guide/public/05/kaihatsu.htm

http://www.e-procurement.mofa.go.jp/kokuji/SyuruiSentaku.html


http://www.customs.go.jp/kyotsu/chotatsu/tokyo.htm

http://www.mhlw.go.jp/sinsei/chotatu/chotatu/index.html

http://www.maff.go.jp/j/supply/index.html

http://www.meti.go.jp/information_2/publicoffer/00_bid_news_list.html

http://www.meti.go.jp/policy/it_policy/CIO/index.html

http://www.meti.go.jp/feedback/data/i30728aj.html

557

3. Procurement plan documents from the offices and ministries National Personnel Authority: Procurement plan documents relating to the design/upgrade of

personnel/payroll systems

http://www.jinji.go.jp/tyoutatu/systemtyoutatujyoho.htm

Cabinet office: Explanations on government procurement relating to the promotion of e-Government

and information systems


National Police Agency: Information on government procurement of information systems,

procurement plan documents

http://www.npa.go.jp/chotatu/seifu_choutatsu/keikakusyo/keikakusyo.html

Financial Services Agency: Procurement information


Ministry of Internal Affairs and Communications: Information system procurement plan documents

http://www.soumu.go.jp/menu_sinsei/cyoutatsu/joho_system.html

Ministry of Foreign Affairs: Public announcement of procurement plan documents created based on

the Basic Guidelines for government procurement related to information systems

http://www.mofa.go.jp/mofaj/annai/shocho/chotatsu/keikakusho/index.html

Ministry of Finance: Public announcement of information system procurement plan documents


Tokyo Customs: System procurement plan documents

http://www.customs.go.jp/kyotsu/chotatsu/sonota/s_tokyo.html

Ministry of Education, Culture, Sports, Science and Technology: Information system-related

government procurement plan documents

http://www-gpo3.mext.go.jp/kanpo/keikakuidx.htm

Ministry of Health, Labour and Welfare: Procurement plan documents

http://www.mhlw.go.jp/sinsei/chotatu/chotatu/keikakusho.html

Ministry of Agriculture, Forestry and Fisheries: Procurement plan documents

http://www.maff.go.jp/j/supply/nyusatu/system/index.html

http://www.jinji.go.jp/tyoutatu/systemtyoutatujyoho.htm


http://www.npa.go.jp/chotatu/seifu_choutatsu/keikakusyo/keikakusyo.html


http://www.soumu.go.jp/menu_sinsei/cyoutatsu/joho_system.html

http://www.mofa.go.jp/mofaj/annai/shocho/chotatsu/keikakusho/index.html


http://www.customs.go.jp/kyotsu/chotatsu/sonota/s_tokyo.html

http://www-gpo3.mext.go.jp/kanpo/keikakuidx.htm

http://www.mhlw.go.jp/sinsei/chotatu/chotatu/keikakusho.html

http://www.maff.go.jp/j/supply/nyusatu/system/index.html

558

Ministry of Economy, Trade and Industry: System procurement plan documents

http://www.meti.go.jp/information/publicoffer/sysplan.html

Japan Patent Office: Explanation on the procurement plan documents for the Japan Patent Office’s

basic infrastructure system

http://www.jpo.go.jp/cgi/link.cgi?url=/koubo/choutatu/keikakushyo/kiban_system.htm

Ministry of Land, Infrastructure, Transport and Tourism: Public announcement of information system

procurement plan (based on the basic guidelines for government procurement)

http://www.mlit.go.jp/chotatsu/chotatsushishin/chotatsushishin.html

Japan Meteorological Agency: Procurement plan documents

http://www.data.jma.go.jp/chouta/data/H20/H20jouhousystem/jouhousystem.html

4. Reference Cases of Total Evaluation National Personnel Authority: Evaluation procedure manual for the leasing and maintenance of the

equipment and software used in personnel/payroll-related business information systems

http://www.jinji.go.jp/tyoutatu/090727_nyusatu.htm

Cabinet office: Documents attached/appended to the business statistics system, procurement

specifications, and other requests for proposals (Part 3, Dec. 2008)

http://www.cao.go.jp/kanbou/gyouseijouhou.html

http://www.meti.go.jp/information/publicoffer/sysplan.html

http://www.jpo.go.jp/cgi/link.cgi?url=/koubo/choutatu/keikakushyo/kiban_system.htm

http://www.mlit.go.jp/chotatsu/chotatsushishin/chotatsushishin.html

http://www.data.jma.go.jp/chouta/data/H20/H20jouhousystem/jouhousystem.html

http://www.jinji.go.jp/tyoutatu/090727_nyusatu.htm

http://www.cao.go.jp/kanbou/gyouseijouhou.html

559

Appendix 2 Case Examples: Service Procurement Specifications

The following is a list of case examples that are used as a reference for the sections of Chapter 6 “Procurement

of services.” The titles are tentative translations.

“TRM documents” in the table designates the full set of procurement specifications defined in the following

document (see “References” section): Information-technology Promotion Agency: “Factual Evaluation of

Technical Reference Model”(a survey report, Jul. 2009).

Ministry and agency names are abbreviated as follows:

CO: Cabinet Office

MOFA: Ministry of Foreign Affairs

FSA: Financial Service Agency

JCG: Japan Coast Guard

JMA: Japan Meteorological Agency

MAFF: Ministry of Agriculture, Forestry and Fisheries

METI: Ministry of Economy, Trade and Industry

MHLW Ministry of Health, Labour, and Welfare

MIC: Ministry of Internal Affairs and Communications

MOJ: Ministry of Justice

MOF: Ministry of Finance

MOE: Ministry of the Environment

MLIT: Ministry of Land, Infrastructure, Transport and Tourism

NPA: National Personnel Authority

1. Supports for Overall Planning

2. Support tasks for procurement 1) Requirement Definition

Ministry/ Agency

Procurement Specification Created in

METI FY2010: Tasks to support the creation of system requirements for the next generation basic information infrastructure of the Ministry of Economy, Trade and Industry

2010

560

2) Project Management Ministry/ Agency


MHLW Support tasks (process management, etc.) for the construction of an electronic processing system used to handle worker’s compensation receipts

2009

MOJ Procurement specifications: procurement of supporting tasks for total project management of the online registration/deposition application system

2009

NPA Supporting tasks relating to the project management of the design/upgrade of the personnel/payroll business information system: Full set of documents

2009

MIC Outsourcing contracts of the project management supporting tasks for the design/development/operation processes in the integrated wireless station monitoring system

2010

MAFF Supporting task specifications for the forestry insurance business system construction project (FY2010) 2010

3. System Construction (design and development) 1) New Development

Ministry/ Agency


TRM Documents

1) Procurement specifications for administrative information delivery services (with application of TRM) 2008

TRM Documents

2) Procurement specifications for groupware and other items used in the personnel information system (with application of TRM)

2008

TRM Documents

4)-1 Procurement specifications for the operational management system (with application of TRM) 2008

MHLW Tender specification for the complete set of tasks for the development of software used in online replacement charging of medical receipts

2009

MHLW Procurement specifications (plan) for the complete set of design/development tasks relating to the workman’s compensation electronic processing system

2009

MHLW Requirements specification for the complete set of tasks involved in the development of the Japan Pension Service ‘s indirect business system

2009

CO Total information system used for Public Interest Corporation Commission 2007

561

2) System Revision Ministry/ Agency


MOFA Specifications for the complete set of development tasks associated with the business/system optimization plan of overseas bookkeeping systems

2008

MHLW System revisions within the ministry used for processing general applications and notifications 2008 MOF Procurement specifications (plan) for the complete set of tasks associated with the development of the national

treasury electronic processing system 2009

MOJ Procurement specifications plan associated with the revision of the registration information delivery system 2009 MOJ Specifications related to the design/development/testing of the next generation immigration information system

(optimization of business procedures and system for immigration management), and revision of the integrated data management system

2010

MOE Procurement specifications (plan) of the tasks (design, etc.) relating to the reconstruction of the Ministry of the Environment electronic application/notification system – scheduled from FY2010 to FY2011

2009

JMA Construction, leasing, maintenance, and installation/coordination of the sediment disaster warning information preparation system

2010

MIC Request for proposals for the contracting of design and development tasks for the next generation consumer price statistical survey system

2010

MIC Request for proposals for contracting of the design and development tasks for the statistical survey system shared by ministries

H18

MAFF Procurement specifications for design and development of the perishable goods logistics information data communication system

2008

MHLW Tender specification for the complete set of tasks for the development of software used in online replacement charging of medical receipts

2009


2009

MHLW Requirements specification for the complete set of tasks involved in the development of Japan Pension Service ‘s indirect business system

2009

TRM Documents


3) Hardware Revision Ministry/ Agency


MOFA Ministry of Foreign Affairs: specifications of clerical support system for information disclosure 2008 MOFA Procurement specifications for the completed set of tasks involved in the passport application image filing system 2008 MOJ Procurement specifications for the tasks associated with the hardware upgrade of the map information system –

data migration, system switching, and others 2010

MLIT Business application migration tasks associated with the establishment of the one-stop service system for car-ownership protocol

2008

CO Total information system used for Public Interest Corporation Commission 2007 MHLW Tender specification for the complete set of tasks for the development of software used in online replacement

charging of medical receipts 2009


2009

TRM Documents


562

4) Addition of Functions Ministry/ Agency


MOFA Full set of task specifications associated with the revision of the region/nations-based ODA grant target figure system

2008

MOFA Procurement specifications associated with the application development and data migration for the international treaties and agreements search system

2008

METI Next generation statistics system maintenance associated with the migration to STATS (addition of a data validation function)

2009

METI Full set of tasks associated with the function creation (tools, etc.) and database migration to the research and statistics system of the Ministry of Economy, Trade and Industry

2009

MHLW Development tasks for the groups of functions (employment insurance protocol and grant funding) required for the implementation of the “Employment stabilization administrative system” (provisional title)

2008

MOF Request for proposals: revision of tasks (e.g. review of sample extraction) used in the network system that performs business corporation statistics survey and others

2010

MOF Program upgrading specifications for Custom Intelligent Database System (CIS) 2008 MOF Full set of specifications for the design/development tasks associated with the inclusions of new tasks and system

optimization of the fiscal loan funding electronic processing system 2007

MOJ Procurement specifications for application function expansion of the next generation registration information system

2008

MOJ Service procurement specifications for performance enhancement of the Ministry of Justice’s total reception/notification system

2008

MOJ Procurement specifications for the tasks required to link the map information system with the new on-line application system

2009

JCG Business system for utilization of Vessel tracking information in coast guard operations 2008 MLIT Air traffic control information processing system: manufacturing and adjustment of the complete control support

system 2010

MLIT Identification information system for vehicle registration: design and development 2009 NPA Design and upgrade tasks for functional enhancement of the personnel/payroll business information system 2009 NPA Full set of specifications for upgrading the personnel/payroll business information system: centralization,

adaptation to the requirements from ministries and other offices, and conformity with institutional reform 2008

NPA Full set of design and upgrading tasks for notification, application, and other functions incorporated in the personnel/payroll business information system

2009

NPA Design and upgrading of the personnel/payroll business information system 2008 MIC Contract of tasks (design, development, construction and others) required to expand functions in the validation

environment within the government authentication infrastructure – tasks associated with the migration to the new encryption algorithm

2009

MIC Contracts for design and development of the supervising system database management functions in the Telecommunications Bureau

2010

MIC Contracts for design and development required for expanding the backbone functions for the supervising system in the Telecommunications Bureau

2010

MIC Contracts of development tasks for information processing tasks used in the supervising system of the Telecommunications Bureau

2010

CO Equipment replacement, functional expansion, maintenance, and operation tasks for the total disaster prevention system

2009

MAFF Specifications for the renovation project of the forest insurance business system, and preparatory tasks to enter it into operation

2009

563

4. Operation Ministry/ Agency


TRM Documents

5) Procurement specifications for operation (with application of TRM) 2008

MOFA Full set of procurement specifications for operation and maintenance of the Contents Management System (CMS) used in IT publicity tasks of the Ministry of Foreign Affairs

2009

MOFA Full set of operational tasks of the Secretariat business system 2009 METI Operational management of the server network in the METI infrastructure information system 2008 METI Support tasks for operational management of the statistics information system 2008 MHLW Full set of operational tasks relating to system/work optimization of the supervision, health and safety, and

worker’s accident compensation insurance delivery 2008

MHLW Total operational supervision tasks for the employment security administrative system (tentative name) (scheduled to enter into operation in 2011)

2009

MOF Operation and maintenance of the budget compilation support system 2009 MOJ Procurement specifications for the operation and maintenance of the next generation registration system for the

assignment of accounts receivables, and support tasks of the public records bureaus 2008

FSA Request for procurement proposal related to the operation of the EDINET system – electronic system for disclosure of asset securities reports and other documents

2008

NPA Procurement specifications of help desk support tasks relating to the personnel/payroll business information system

2009

MIC Contract of operations relating to optimization of tasks and systems of the sharing system infrastructure (contract of additional operational tasks required to cope with the hardware and software expansion in the sharing system infrastructure)

2009

MIC Contract of operation and other tasks of the e-Government utilization support center 2007 MAFF Operation support tasks for the information management system of the General Food Policy Bureau 2007

5. Help Desk Ministry/ Agency


MHLW Full set of operational tasks relating to the system/work optimization of the supervision, health and safety, and worker’s accident compensation insurance delivery

2008

MHLW Total operational supervision tasks for the employment security administrative system (tentative name) (scheduled to enter into operation in 2011)

2009

MOF Operation and maintenance of the budget compilation support system 2009 NPA Procurement specifications of the help desk support tasks relating to the personnel/payroll business information

system 2009

TRM Documents

5) Procurement specifications for operation (with application of TRM) 2008

564

6. Maintenance 1) Hardware maintenance

Ministry/ Agency


MOFA Procurement specifications for leasing and maintenance tasks of the full set (hardware) of the document preparation/editing system

2008

MHLW “Full set of tasks relating to optimizing the business system – introduction of a LAN to hub locations and maintenance – used for the supervision, health and safety, and worker’s accident compensation insurance delivery”

2008

JMA Hardware leasing, maintenance, and installation/adjustment of the volcano monitoring information center 2009 MAFF Maintenance tasks specifications for the national forestry resources database server and others:

h220226_siyou_2 2009

TRM Documents


TRM Documents

4)-2 Procurement specifications for HW (with application of TRM) 2008

2) Software maintenance Ministry/ Agency


NPA Leasing and maintenance of hardware and software used in the personnel/payroll business information system (2nd phase)

2009

TRM Documents


3) Application maintenance Ministry/ Agency


METI Full set of maintenance tasks for the industrial statistics system (maintenance of operational environment) 2009 MHLW Full set of system revision tasks within the ministry used for processing general applications and notifications 2008 MOF Full set of service contract for revision, operation, and maintenance of the fiscal loan resources electronic

processing system 2007

MOJ Procurement specifications: procurement of business application maintenance tasks for the new registration system installed in 2010

2009

JMA Construction, leasing, maintenance, and installation/coordination of the sediment disaster warning information preparation system

2010

FSA Procurement specifications (plan) for additional design and development for improved operation of EDINET (electronic system for disclosure of asset securities reports and other documents)

2008

MAFF Procurement specifications: revision tasks of the field crop statistical research and data collection program 2009 MHLW Specification of the full set of tasks for the maintenance of applications used in the next generation labor insurance

and collection system 2009

NPA Leasing and maintenance of hardware and software used in the personnel/payroll business information system (2nd phase)

2009

TRM Documents


565

4) System infrastructure maintenance

Ministry/ Agency


MHLW Procurement specifications for the provision (design/development, connection, total test and operation) of the integrated network for the Ministry of Health, Labour and Welfare, scheduled to be expanded starting FY2009

2009

MHLW Procurement specifications for the “Full set of tasks relating to optimizing the business system – introduction of a LAN to hub locations and its operation and maintenance – used for the supervision, health and safety, and worker’s accident compensation insurance delivery”

2008

TRM Documents

3) Network procurement specifications (with application of TRM) 2008

7. Tasks associated with instrument procurement Ministry/ Agency


TRM Documents

4)-2 Procurement specifications for HW (with application of TRM) 2008

MOFA Full set of procurement specifications for the electronic notification system server and other items used for the procedures to reside in Japan

2008

MOFA Procurement specifications: Leasing and maintenance of the full set of instruments used in electronic bidding and bid opening system

2009

METI Full set of secondary leasing equipment used in the statistical analysis system of the Ministry of Economy, Trade and Industry

2010

METI Equipment used in the general purpose electronic application system of the Ministry of Economy, Trade and Industry

2008

MHLW Procurement specifications for the full set of servers and terminal equipment (introduced in FY2009) used in contact/reception function group of the Employment stabilization administrative system (provisional title)

2008

MHLW Procurement specifications for the full set of sub-system servers and other equipment used for employment placement tasks of the Employment stabilization administrative system (provisional title)

2009

MOF Procurement specifications for the provisions (hardware and others) used in the fiscal loan funding electronic processing system

2009

MIC Leasing of equipment and software used for business/system optimization of the sharing system infrastructure 2008 MIC Leasing procurement specifications for the business/system optimization of users authentication (office staff

inclusive) 2008

MOJ Specification for the procurement of terminal equipment and other items used in the next generation registration information system

2008

MOJ Procurement specifications: procurement of terminal equipment and other items used in the new (FY2010) registration information system

2009

8. Tasks associated with the procurement of iDC equipment Ministry/ Agency


TRM Documents

7) IDC procurement specifications (with application of TRM) 2008

MOFA Leasing of the data center and a full set of associated items 2010 MHLW Employment stabilization administrative system (provisional title) data center and a full set of associated items 2008 MOJ Procurement of ancillary facilities required for operation of the new registration information system 2009 MIC Leasing procurement of facility and equipment used for business/system optimization of the sharing system

infrastructure 2008

566

9. Network procurement Ministry/ Agency


TRM Documents

3) Network procurement specifications (with application of TRM) 2008

TRM Documents

6) WAN procurement specifications (with application of TRM) 2008

MOFA Full set of procurement specifications for the construction and operation of the open LAN basic business system to be incorporated in the Ministry of Foreign Affairs information network (sharing system)

2008

METI Ministry of Economy, Trade and Industry’s network services 2008 MHLW Procurements related to the renovation of the Ministry of Health, Labour and Welfare's network system 2009 MHLW Procurement specifications for the provision (design/development, connection, total test and operation) of the

integrated network of the Ministry of Health, Labour and Welfare, scheduled to be expanded starting FY2009 2009

MOJ Procurement of the new registration information system communication services (FY2010) 2009

567

Appendix 3 Table: Guidelines on the transition of encryption algorithms

Concerns over the degraded security of the encryption algorithms now prevailing in government

organizations (SHA-1 and RSA1024) have currently been pointed out, producing a demand to make

the shift to an encryption algorithm with higher level of security.

The move requires coordinated and integrated actions in the government from the viewpoint of

securing interoperability among the information systems. To this purpose, the 17th meeting of the

Committee on Information Security Policies (22, Apr. 2008) decided the transition guidelines (see

appendix: “Transition guidelines of the encryption algorithms (SHA-1, RSA1024) currently employed

in the government information systems”).

Improvements and upgrading of the information systems are now underway in conformity with the

transition guidelines – especially relating to the two encryption algorithms (SHA-1, RSA1024) now

prevailing in the government organizations – aiming at completion by the early part of 2014. Along

with this, stop-gap measures (a contingency plan) against rapid degradation of security are now

under consideration.

Note that the need for measures to be established in the offices and ministries toward transition of

encryption systems and implementation of the contingency plan, in line with the above described

transition guidelines, is also explicitly stated in “Standards for Information Security Measures for the

Central Government Computer Systems” (decisions made by the Committee on Information Security

Policies), which defines the whole-governmental standard of the measures to be implemented for

upgrading information security.

In terms of the transition of encryption algorithm, constant gathering of the latest information and

review are highly desired as an abrupt change of situation can not be ruled out.

568

１現状と課題１現状と課題

２暗号の移行指針の概要２暗号の移行指針の概要

①電子政府システムでは，電子署名等のために暗号が使用されており，SHA-1及びRSA1024と呼ばれる暗号方式を広く使用．

②しかし，このSHA-1及びRSA1024は，安全性の低下が指摘されており，より安全な暗号方式への移行が必要．

③より安全な暗号方式への移行にあたっては，情報システムの相互運用性確保や政府全体の情報セキュリティの向上のため，政府統一

的な移行指針を策定することが必要．

①電子政府システムでは，電子署名等のために暗号が使用されており，SHA-1及びRSA1024と呼ばれる暗号方式を広く使用．

②しかし，このSHA-1及びRSA1024は，安全性の低下が指摘されており，より安全な暗号方式への移行が必要．

③より安全な暗号方式への移行にあたっては，情報システムの相互運用性確保や政府全体の情報セキュリティの向上のため，政府統一

的な移行指針を策定することが必要．

①技術的な対応①技術的な対応

【上記以外の情報システム】

○ 現実的な脅威となる攻撃手法が示された時点で，速やかに別の暗号方式

に変更する等の対応措置を可能とする．

○ 新たな暗号方式は，より安全なものを各府省庁において判断し決定する．

②制度的な対応○ 各府省庁において次を実施

・システムの移行時期を踏まえ，必要な対応の取りまとめ・移行手順書の整備

②制度的な対応○ 各府省庁において次を実施

・システムの移行時期を踏まえ，必要な対応の取りまとめ・移行手順書の整備

③スケジュール○ 内閣官房，総務省，法務省，経済産業省等

新たな暗号方式へ切り替える時期等を2008年度中に検討．

○ 内閣官房，総務省等

相互接続の技術要件，緊急避難対応等について2008年度中に検討．

○ 各府省庁

2010年から2013年までの間に，各情報システムの対応を完了．

○ 内閣官房，総務省，経済産業省

安全性の状況を監視し，必要な情報を速やかに各府省庁に提供．

③スケジュール○ 内閣官房，総務省，法務省，経済産業省等

新たな暗号方式へ切り替える時期等を2008年度中に検討．

○ 内閣官房，総務省等

相互接続の技術要件，緊急避難対応等について2008年度中に検討．

○ 各府省庁

2010年から2013年までの間に，各情報システムの対応を完了．

○ 内閣官房，総務省，経済産業省

安全性の状況を監視し，必要な情報を速やかに各府省庁に提供．

【政府認証基盤とそれに依存する各府省庁の情報システム】

○ 相互運用性確保のため，新旧暗号方式の双方に対応し，

適切な時期に暗号方式を切り替える運用を可能に．

○ 新たな暗号方式として，SHA-256及びRSA2048を採用．

○ 移行完了前に安全性低下の影響が発生する場合に備え，

緊急避難的な対応も想定．

Figure Appendix 3-1 Guidelines Overview of Encryption Method Migration

1. Current Status and Challenges

(1) The e-Government system uses code languages for the implementation of cryptographic processing such as electronic signature. For this purpose, encryption methods called SHA-1 and RSA1024 are widely used. (2) Degradation of security has been pointed out for the encryption methods, producing the need for migration to a safer encryption method (3) The migration process to a safer encryption method requires establishment of unified guidelines by the government to ensure interoperability of the information systems and upgraded government-wide information security

2. Guidelines Overview of Encryption Method Migration

(1) Technical aspects [Governmental authentication framework, and the information systems of ministries and offices that depend on it] ○ To ensure interoperability, the migration process must maintain compatibility with both old and new encryption methods and be capable of switching them at an appropriate time. ○ Adaptation of SHA-256 and RSA2048 as the new encryption methods ○ In view of the concerns of temporal lowering of security prior to the completion of migration, a contingency plan for ensuring security must be provided.

[Other information systems] ○ In view of the possibility of an eminent emergence of an attacking method that threatens security, optional measures must be provided to quickly switch to different encryption methods. ○ Each ministry and office must consider and make decisions on the new encryption method for higher levels of security.

(2) Institutional aspects ○ The following measures must be implemented in each ministry and office - Summarizing and sorting out necessary measures based on the system migration schedule

(3) Schedule ○ Cabinet Secretariat, Ministry of Internal Affairs and Communications, Ministry of Economy, Trade and Industry, and other ministries and offices

Switching schedule to the new encryption method must be studied by the end of FY2008. ○ Cabinet Secretariat, Ministry of Internal Affairs and Communications, and other ministries and offices

Technical requirements for mutual connections, contingency plans and additional measures must be studied by the end of FY2008. ○ Each ministry and office

Each information system must be preparing for the system migration during the period of 2010 to 2013. ○ Cabinet Secretariat, Ministry of Internal Affairs and Communications, Ministry of Economy, Trade and Industry

These offices must always place a check on the state of security, and provide necessary information to the ministries and offices without delay.

569

政府機関における技術仕様等の各種検討の開始

政府機関における技術仕様等の各種検討の開始

新たな暗号方式のみの使用

複数の暗号方式が混在

政府機関の情報システムが対応開始

政府機関の情報システムが対応開始

政府機関の情報システムが対応完了

政府機関の情報システムが対応完了

新たな暗号方式への移行開始（従来の方式の新規使用停止）

新たな暗号方式への移行開始（従来の方式の新規使用停止）

新たな方式への移行完了（従来の方式の消滅）

新たな方式への移行完了（従来の方式の消滅）

従来の暗号方式のみの使用

暗号の安全性を監視

新たな暗号方式への移行完了以前に安全性低下による支障

が発生した場合は，官民連携した緊急避難的な対応を実施

▽2010年度 ▽2013年度 ▽（X-day） ▽（Y-day）▽2008年度

（X,Y-day）：関係機関との調整を図りながら，2008年度中に時期を検討

地方公共団体，民間認証局等の対応状況を所管省庁等を通じて把握

政

府

機

関

地方公共団体

民間等

（参考）

米国では期限を決めて対応する

方法を採用し，2010年末以降，政

府機関において，SHA-1の新規使

用を停止する方針．

しかし，SHA-1が2010年に危殆化

するかどうかは専門家の間でも意

見がわかれる．

このため本指針は，暗号の安全性

低下の状況を監視しながら対応す

る方法とし，政府が暗号の安全性

を監視し，安全性低下が早まった

場合は，緊急避難的な対応を実施

（コンテンジェンシープランの発動）

．

（参考）

米国では期限を決めて対応する

方法を採用し，2010年末以降，政

府機関において，SHA-1の新規使

用を停止する方針．

しかし，SHA-1が2010年に危殆化

するかどうかは専門家の間でも意

見がわかれる．

このため本指針は，暗号の安全性

低下の状況を監視しながら対応す

る方法とし，政府が暗号の安全性

を監視し，安全性低下が早まった

場合は，緊急避難的な対応を実施

（コンテンジェンシープランの発動）

．

Figure Appendix 3-2 Migration Schedule up to Completion in Conformity with the Migration

Guideline

Gov

ernm

ent O

rgan

izat

ions

FY2008 FY2010 FY2013

Start of various studies – technical specifications, etc. – in government organizations

Start of system modification in the information systems of government organizations

Completion of system modification in the information systems of government organizations

Start of encryption method migration (novel use of the conventional method is banned)

Completion of migration processes (deletion of the conventional method)

(Reference) The USA has adopted a policy to limit the time: new use of SHA-1 after the end of 2010 will be banned in the government organizations. However, experts have divided opinions if SHA-1 will become too vulnerable in 2010. This guideline applies a policy to keep a watch on the security situations of encryption methods, and take appropriate measures accordingly. In case the security monitoring indicates an earlier-than-expected degradation of security, emergency measures will be put into effect (invocation of the contingency plan)

Exclusive use of conventional encryption methods

Mixed use of conventional and new

methods

Exclusive use of new encryption methods

Security level monitoring of encryption

If secured communication is threatened because of degraded security prior to the migration to the new methods, emergency measures will be brought into effect in coordination between private and public sectors.

Priv

ate

sect

ors

and

loca

l pub

lic

orga

niza

tions

Progress of migration processes in local public organizations and private sector certificate authorities should be monitored through the information provided by the presiding ministries and offices.

(X, Y-day): Timing of system migration must be studied during FY2008, with careful coordination among ministries and offices

570

Appendix 4 References

Following titles are tentative translations.

■Guidelines for Optimizing Operation and Systems (Mar. 2006) e-Government’s unified contact: On promotion of e-Government

http://www.e-gov.go.jp/doc/scheme.html

■Basic Guidelines for Government Procurement Relating to Information Systems (Mar. 2007) Ministry of Internal Affairs and Communications Home Page

http://www.soumu.go.jp/s-news/2007/070301_5.html

■ “Basic Guidelines for Government Procurement Relating to Information Systems: Practical Manual” (2nd edition)

Ministry of Internal Affairs and Communications Home Page

http://www.soumu.go.jp/menu_news/s-news/2007/070919_2.html

■ Framework for Interoperability Relating to Information Systems (Jun. 2007) Ministry of Economy, Trade and Industry Home Page

http://www.meti.go.jp/press/20070629014/20070629014.html

■ Ministry of Economy, Trade and Industry: Knowledge Portable Reference Model (TRM) (Mar. 2005)

Ministry of Economy, Trade and Industry Home Page: EA portal

http://www.meti.go.jp/policy/it_policy/ea/data/report/index10.html

■ “Information Disclosure Policies on Security and Reliability of ASP and SaaS” (Nov. 2007) Ministry of Internal Affairs and Communications Home Page


■ Guidelines for Information Disclosure Relating to Safety and Reliability of Data Centers (1st edition) (Feb. 2009)


http://www.soumu.go.jp/main_content/000010165.pdf

http://www.e-gov.go.jp/doc/scheme.html

http://www.soumu.go.jp/s-news/2007/070301_5.html


http://www.meti.go.jp/press/20070629014/20070629014.html

http://www.meti.go.jp/policy/it_policy/ea/data/report/index10.html


http://www.soumu.go.jp/main_content/000010165.pdf

571

■ “Guidelines relating to safety management of medical information: for ASP/SaaS Business Operators” (Jul. 2009)


http://www.soumu.go.jp/menu_news/s-news/02ryutsu02_000010.html

■ “Service Organization Control Reports (formerly SAS 70 reports)” http://www.aicpa.org/InterestAreas/AccountingAndAuditing/Resources/SOC/Pages/SORHome.aspx

■ 18th Report of the Auditing Standard Committee (Japanese Institute of Certified Public Accountants) “Control Risk Evaluation in Commissioned Businesses,” (normally referred to as

“No.18 Audit”)

■ National Information Security Center: major released document “Standards for Information Security Measures for the Central Government Computer Systems (4th

edition)” (revised in 2009)


Practical Guide for the “Standards for Information Security Measures for the Central Government

Computer Systems (4th edition)” (revised in 2009)

http://www.nisc.go.jp/active/general/pdf/K303-091C.pdf

Note: The latest version of the Standards for Information Security Measures for the Central

Government Computer Systems was released in Apr. 21, 2011.

- Unified Rules to Guarantee Information Security Measures for the Central Government Computer

Systems (Apr. 21, 2011)

http://www.nisc.go.jp/active/general/pdf/kihan.pdf

- Guidelines for Establishment and Operation of Management Standards and Technical Standards for

Information Security Measures for the Central Government Computer Systems (Apr. 21, 2011)

http://www.nisc.go.jp/active/general/pdf/unyou.pdf

- Management Standards for Information Security Measures for the Central Government Computer



- Technical Standards for Information Security Measures for the Central Government Computer



http://www.soumu.go.jp/menu_news/s-news/02ryutsu02_000010.html

http://www.aicpa.org/InterestAreas/AccountingAndAuditing/Resources/SOC/Pages/SORHome.aspx

http://www.nisc.go.jp/active/general/pdf/kihan.pdf

http://www.nisc.go.jp/active/general/pdf/unyou.pdf



572

- “Management Standards for Information Security Measures for the Central Government Computer

Systems”: Practical Guide


- “Technical Standards for Information Security Measures for the Central Government Computer Systems”:

Practical Guide


- Report of the working group on the risk requirements reference model (Mar. 2010)

http://www.nisc.go.jp/inquiry/pdf/2-1_RM-model_Open.pdf

- Manual for establishing security requirements applied to the control of information systems in

governmental organizations (Mar.30, 2011)

http://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

■ Guidelines for risk evaluation and electronic signature/authentication in online procedures Decisions made in the 41st liaison conference of chief information officers (CIO) from the Cabinet

Office and Ministries (Aug. 2010)

http://www.kantei.go.jp/jp/singi/it2/cio/dai41/41gijisidai.html

■ E-Government Usability Guidelines Decisions made in the 37th liaison conference of chief information officers (CIO) from the Cabinet

Office and Ministries (Jul. 2009)


■ Information-technology Promotion Agency: “Factual Evaluation of the Technical Reference Model” (a survey report, Jul. 2009)

Information-technology Promotion Agency Home Page: List of achievements of the project for

promotion of open software utilization (2008)

http://www.ipa.go.jp/software/open/ossc/2008seika.html

- Research report:

http://www.ipa.go.jp/software/open/ossc/download/trm20_report.pdf

- Executive summary:

http://www.ipa.go.jp/software/open/ossc/download/trm20_report_summary.pdf

- Executive summary, supplementary documentation:

http://www.ipa.go.jp/software/open/ossc/download/trm20_report_summary_appended.pdf

- Full set of procurement specifications:

http://www.ipa.go.jp/software/open/ossc/download/trm20_specific_procurement.zip



http://www.nisc.go.jp/inquiry/pdf/2-1_RM-model_Open.pdf

http://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf



http://www.ipa.go.jp/software/open/ossc/2008seika.html

http://www.ipa.go.jp/software/open/ossc/download/trm20_report.pdf

http://www.ipa.go.jp/software/open/ossc/download/trm20_report_summary.pdf

http://www.ipa.go.jp/software/open/ossc/download/trm20_report_summary_appended.pdf

http://www.ipa.go.jp/software/open/ossc/download/trm20_specific_procurement.zip

573

- Full set of total (functional) evaluation criteria:

http://www.ipa.go.jp/software/open/ossc/download/trm20_assessment_1.zip

- Full set of total (general) evaluation criteria:


- Full set of request for proposals:

http://www.ipa.go.jp/software/open/ossc/download/trm20_rfp.zip

■ Information-technology Promotion Agency, SEC BOOKS: “SLCP-2007 (2nd ed.),” Dec. 2009 http://sec.ipa.go.jp/press/20090930_b.html



http://www.ipa.go.jp/software/open/ossc/download/trm20_rfp.zip

http://sec.ipa.go.jp/press/20090930_b.html