Download Technical Reference Model for the Government Procurement

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.
1
Contents
1.
2.
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
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
2
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
3
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
separation-of-procurement-policy
recommended
information
in
the
“Basic
systems
Guidelines
following
for
the
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.
4
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,
5
•
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.
6
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.
7
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;
8
[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
9
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
10
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
11
Break-Down -Structure of the IT-Technologies
Top Level
Second Level
Technologies
Specific Items
Functions
Hardware
PC /
Platform
In-Office-shared Thin Client
Personal Computer
Printers
In-Office-shared Printer
Server
Server Hardware
Storage
Disk Storage
Server Hardware
Tape Storage
Network
Switch
LAN
Secure Wireless LAN
WAN
Router
Remote Access
Private Line Service
Business
PC / Office
Operation
Printer
Common Operation Environment
OS Kernel
Peripheral Support
Platform
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
Application
Web Server
Platform
Execution
AP Server
Environment
Data
Meta Data Registry
Management
DB Server
File Sharing
Integrated Directory
Data Exchange
EAI
/ Linkage
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.
12
(H/W)
Shared PC,
Shred-inOffice
Printer
Hardware
Platform
EAI
(Web
Service)
(Server OS)
(H/W)
Server
(Protocol)
(H/W)
Storage
DNS, DHCP, Proxy
Authentication,
Integrated
Account
Management,
Integrated
Directory
(H/W)
WAN, Ministry’s
Internal LAN
Remote Access
Common Technologies to All Domains
(Client
OS)
File
Legacy
Server Integration
SOARelated
Functions
(SOA)
(Network Service)
(GeneralPurpose
Middleware)
BI/
DWH/
ETL
Maintenance Environment
(Base
S/W)
EIP Groupeware, Workflow,
Mail Server
BAM
System Operation Management
Application
Platform
Public
Web
Server
Security
(Shared
S/W)
(Dedecated
Middleware)
Base
Applications
Job-Operation
Platform
(Common
Business
System)
(Individual Business System)
Approval
Individual Business
Applications
iDC Facility
Colors indicate
where the
technology in the
box is used.
Mainly used in client
environments: PCs
or printers
Mainly used in server
environments:
servers or storages
Same as
described
at the left
Technologies common
Network
to the entire IT sphere:
related
independent of
technologies 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.
13
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.
14
Planning
phase
Requirements
definition
要件定義
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
Operation/maintenance
運用・保守フェーズ
phase
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.7 Tasks incidental to
procurement of devices
6.6 Maintenance
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 2.2-3: Classification of procurement of services
15
Figure 2.2-4 Descriptions of the Services
Service
6.1 Support for master plan
formulation
6.2 Support for procurement
6.3 System integration
(design/development)
6.4 Operation
6.5 Help desk
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
6.8 Tasks incidental to
procurement of iDC equipment
6.9 Network procurement
6.10 Cloud service
6.11 Cloud construction
6.12 Security
6.13 Other (to be created)
Service operation
Planning the systematization initiative and
systematization plan creation
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.
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)
Service operations concerning help desk to respond to
inquiries from users on system operationuse
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)
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.
Service operations using cloud system services
Service operations to construct cloud systems
This section describes security cautions in procurement
of services and security approaches during
construction of information systems
Service operations not included in 6.1 – 6.12, such as
procurement of business package software.
16
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.
17
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.
(Client
OS)
Hardware
Platform
(H/W)
PC, Inofficeshared
Printer
Data
Utilization
Application
Platform
Data
Management
Data
Exchange
/ Linkage
(Server OS)
(H/W)
Server
SOARelated
Functions
Web
Service
(Protocol)
(H/W)
Storage
(H/W)
Network
Common Technologies to All Domains
Job-Operation
Platform
Business /
Process
Management
Network Service
Application
Platform
Inf ormation
Access /
Collaboration
System Operation Management
Office
Applications
Security
Base
Applications
Development / Maintenance Environment
Individual Business Applications
iDC Facility
Colors indicate
where the
technology in the
box is used.
Mainly used in client
environments: PCs
or printers
Mainly used in server
environments:
servers or storages
Same as
described
at the left
Technologies common
Network
to the entire IT sphere:
related
independent of
technologies specific environments
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.
18
(H/W)
Shared PC,
Shred-inOffice
Printer
EAI
(Web
Service)
(Server OS)
(H/W)
Server
(Protocol)
(H/W)
Storage
DNS, DHCP, Proxy
Authentication,
Integrated
Account
Management,
Integrated
Directory
(H/W)
WAN, Ministry’s
Internal LAN
Remote Access
iDC Facility
Colors indicate
where the
technology in the
box is used.
Mainly used in client
environments: PCs
or printers
Mainly used in server
environments:
servers or storages
Same as
described
at the left
Technologies common
Network
to the entire IT sphere:
related
independent of
technologies specific environments
Figure 3-2: Technology Domains mapped on TRM Framework
19
Common Technologies to All Domains
(Client
OS)
File
Legacy
Server Integration
SOARelated
Functions
(SOA)
(Network Service)
Hardware
Platform
(GeneralPurpose
Middleware)
BI/
DWH/
ETL
Maintenance Environment
(Base
S/W)
EIP Groupeware, Workflow,
Mail Server
BAM
System Operation Management
Application
Platform
Public
Web
Server
Security
(Shared
S/W)
(Dedecated
Middleware)
Base
Applications
Job-Operation
Platform
(Common
Business
System)
(Individual Business System)
Approval
Individual Business
Applications
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
PC /
Personal Computer
Platform
In-Office-shared
Thin Client
Printers
In-Office-shared Printer
Server
Server Hardware
Storage
Disk Storage
Server Hardware
Tape Storage
Network
LAN
Switch
Secure Wireless LAN
WAN
Router
Remote Access
Private Line Service
Business
PC / Office
Operation
Printer
Common Operation Environment
OS Kernel
Peripheral Support
Platform
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
Application
Web Server
Platform
Execution
AP Server
Environment
Data
Meta Data Registry
Management
DB Server
File Sharing
Integrated Directory
Data Exchange
EAI
/ Linkage
Data Adapter
Legacy-System Integration
Web Service
ESB (Enterprise Service Bus)
20
Web Service Protocol
Base Technology
Security Service
High-Reliability Messaging
Service
Transaction Service
Base
Information
Mashup Portal
Application
Access /
EIP
Portal Sites
Collaboration
Personalize
Application Integration
Contents Management System
Groupware
E-mail
Instant Message
Full Text Search
Web Conference
Screen Sharing Service
Business /
Business Process Management
Process
Business Activity Monitoring
Management
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
Management
Function
Service Repository / Registry
Office
Office Application
Image Processing
Application
Word Processing
Presentation
Spread Sheet
Facsimile
Image Publishing
21
Document Processing
Calculation
System
System
System Operation Management
Availability / Performance
Operation
Operation
Management
Management
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
Common
Coded Character Set
Technology to
Technology to
Graphic Format
All Domains
All Domains
CD-ROM Format
DVD Format
Character Symbol
Tagset / Markup-language
Definition
Data Element Standard
Video Format
Compaction / Archiving
Magnetic Tape
Business Information
Geographic Information
22
Character Set / Data
Representation
Locale / Native Language
Support
Programming Language
Modeling Support
Accessibility
Network
Network
Communication Protocol
Service
Service
Time Service
Development /
Development /
Development Environment
Maintenance
Maintenance
Development Tool
Environment
Environment
Configuration / Version
Management Tool
Project Management Tool
Test Tool
Video Processing
Voice Information Processing
CAD (Computer Aided Design)
Expert System
E-learning
Product /
Service
specific
Technology
Product /
Kiosk
Service specific
Mobile Device
Technology
Product Information
Mobile / Wireless
IC Card
Media Distribution Service
Geographic Information Service
Document Management Service
TRM
Supporting
Technology
IT Service Management
TRM Supporting
Technology
Software Lifecycle Management
Internal Control Framework
23
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.).
Functional Configuration Model
: Technology Domains
Application
Individual
Business
System
Common
Platform
System
Workflow / BAM
Common
Business
System
Legacy
System
Integration
Function for SOA
System
Operation
Management /
Security
BI/DWH/ETL
EIP
Public Web Server
Groupware /
File Server
Maintenance
Environment
EAI
Server
Storage
iDC
Facility
Integrated Account
Management /
Authentication /
Permission
Integrated Directory
Network
Remote Access
Shared PC
In-office-shared Printer
WAN /
Ministry’s Internal LAN
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:
24
Application
Technology Domain
Definition
Individual
•
Job-operations defined in the Job-operation Manual
Job-operations
•
Individual business applications of job-operation
Legacy System
•
Mechanism existing in the application layer to make a linkage
between the job-operations realized on legacy systems and
Integration
those on the common platform system
•
Note that EAI, etc. are excluded.
Common Platform System
Technology Domain
Definition
Common Job-operation
•
Common job-operations defined in the Job-Operation Manual
available on the common platform system.
Workflow / BAM
BI /DWH / ETL
•
The services commonly available to individual job-operations.
•
A versatile mechanism to manage or monitor job-processes
•
Note that web-service-based BPM is excluded.
•
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
•
The entire mechanism for managing operations or preserving
security of the common platform system and applications.
Management / security
•
Note that mechanisms required to be implemented in the
individual applications are excluded.
Maintenance
•
The mechanism for implementing the environments required
for the maintenance of the common platform system and
Environment
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
25
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
Technology Domain
Definition
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.
26
Authentication /
•
access-control.
Permission
Integrated Directory
Unique IDs are allocated to all users for authentication and
•
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
•
A main body of network services, including physical
communication lines and DNS / DHCP / Proxy.
LAN
•
Desired to have basic security features.
Shared PC /
•
PCs or Printers shared in offices.
In-Office-Shared Printer
•
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,
network-connection environment.
27
as
well
as
a
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.
Structure of Items of Service Procurement
Application
Design and Development
of Individual Business
System (including physical design
of DB)
Common
Platform
System
Design and
Implementation of
Workflow / BAM
Design and
Implementation of BI /
DWH / ETL
Network
(Design and Implementation of
ESB, BPM, Service Repository
and Web Service)
Design and
Implementation of
Maintenance
Environment
Design,
Implementation,
Deployment and
Installation of Server
Design,
Implementation,
Deployment
and Installation
of Storage
Remote Access
physical design of DB)
Design and
Implementation of SOA
Design and
Implementation of EAI
/ External Linkage
(Configuration Design / High
Reliability Design / Performance
Design / Integration and
Virtualization Design / Physical
Design of DB)
Design and
Development of
Common Business
System (including
Design and
Implementation of
Legacy-system
Integration
iDC
facility
Design of
Operations and
Development of
Management
Tools
(including the
following functions:
Monitoring, Backup, Trouble
Administration,
Recovery
Operations,
Configuration
Management,
Resource
Management,
Resource Planning)
Security Design
and
Construction
(Configuration Design,
High Reliability Design,
Functional Design,
Integration /
Virtualization Design)
Design and Implementation
of Shared PCs
Design and Implementation
of Printers shared in Of f ices
(including network
security and
personal
information
protection)
Design and
Implementation of EIP
Design and
Implementation of a
Public Web Server
Design and
Implementation of
Groupware
Design and
Implementation of a File
Server
Integrated Account
Management /
Authentication /
Permission
Design and
Implementation of an
Integrated Directory
Design and Implementation
of a WAN
Design and Construction of
a Ministry’s Internal LAN
Figure 4.1-2 Structure of Items of Service Procurement in Relation to Technology Domains
28
Structure of Items of Procurement of Goods
Application
(Software Products working as a functional
element or an engine in individual business
system)
Software Products
used as an element
or an engine of
common business
system
Products for
Remote
Access
(Dedicated Terminals or Printers)
(AP Server, Development Tools)
Common
Platform
System
Workflow Products
Products for SOA
BAM Products
(including ESB, BPM,
Service Repository, Webservice Products)
Products of BDI /
DWH / ETL
Maintenance
Environment
Products for EAI
Software Products for EIP
System
Operation
Management
Software
Products
Software Products for
Public Web Servers
Security
Software
Products
Groupware Products
File Server Products
Mail Server Products
(including Development Tools and
automatic-test tools)
Server Product
Network
(Server, Router, Switch, Highreliability Product, Integration /
Virtualization Product, Web
Server, AP server, DBMS,
OS)
Products for Remote
Access
Storage
Products
iDC
facility
(including storage
devices, highreliability products,
products for
integration or
virtualization)
Software for Integrated
Account Management /
Authentication /
Permission
Software Products for
Directory Management
Communication-line
subscription f or WAN
Shared PC (PC, COE Management
Software, OA Software Products,
Security Software Products, OS)
Shared Printers in Offices (Hardware
and Software Products for Management
Equipments f or Ministry’s
Internal LAN
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
・
Optional (rarely required)
・
Required in case of the procurement of dedicated tools for
systems
to
legacy
linkage. Generally the function is included in job-operation
systems, EAI, or external linkages.
29
Common Platform System
Technology Domain
Necessity of Technology Domain
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
・
Mandatory
Security
・
Note that the functional coverage should be determined
carefully.
Maintenance
・
Mandatory
Environment
・
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.
30
Network
Technology Domain
Necessity of Technology Domain
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
・
Optional (highly required)
File-server
・
In some cases, a groupware, or a file-server is procured
independently.
Integrated Account
・
Optional (fairly required)
Management,
・
In some cases, those functions are included in procurement
Authentication, and
such as common job-operation systems or individual
Permission
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.
・
Mandatory
Shared PC and
・
Optional (highly required)
In-office-shared Printer
・
In some cases, those are procured independently.
Remote Access
・
Optional (fairly required)
・
The purchase decision depends on specific requirements of
WAN and Ministry’s
Internal LAN
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
31
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.
32
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.
33
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.
34
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).
35
Figure 4.2-2: Physical Configuration Model of Common Infrastructure
36
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 4.3-1: Categorization of Procurement of Service
37
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.
Attributes of Service
Service Items
Design
■New Development
■System Renewal
■Hardware Renewal
■Sub-system-level
Functional Augmentation
Development / Test / System Migration
<Design / Development in System Integration>
New Development
System Renewal
Hardware Renewal
Functional Augmentation
■Modification
(Correction, Functional Augmentation,
Bug-fixing)
(Design
Correction)
Maintenance
(Scheduled Maintenance / Inspection)
Including Defect-warranty work
<Maintenance>
Application Maintenance
Including Defect-warranty work
<Maintenance>
■Procurement of Application
Maintenance requiring no development
work
Application Maintenance
■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
38
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.4 Operation
6.6 Maintenance
6.3 System construction
6.7 機器調達付帯作業
6.8 Tasks
incidental
to
procurement
of iDC
equipment
6.7 Tasks incidental to
procurement of devices
6.3 System construction
6.8
iDC設
備調
達付
帯作
業
6.9 Network
procurement
6.9 Network
procurement
Figure4.3-3 Mapping of Services on the Functional Configuration Model for Procurement of Service
39
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
40
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;
41
• 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
42
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,
43
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.
44
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.
45
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.
46
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.
47
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
48
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.
Application
Virtual Layer
OS, Middleware
Virtual Layer (*1)
Hardware
(Server, Storage, Network and others)
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,
49
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.
Application
Application
Guest OS
Guest OS
Virtual Machine
Virtual Machine
Host-type VMM
Application
Application
Management
Tool
Guest OS
Guest OS
Management
OS
Virtual Machine
Virtual Machine
Virtual Machine
Application
Host OS
Hypervisor-type VMM
Hardware
Hardware
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.
50
Desktop
AP
Desktop
AP
Desktop
AP
Terminal Service
Desktop
AP
Desktop
AP
Desktop
AP
Desktop
AP
Desktop
AP
Desktop
AP
Client
OS
Client
OS
Client
OS
Client
OS
Client
OS
Client
OS
Virtual
Machine
Virtual
Machine
Virtual
Machine
Server OS
Blade
Hardware
Server-based-computing
Blade
Hardware
Blade
Hardware
Blade-PC
Hypervisor
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.
51
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.
52
SaaS
PaaS
IaaS
Public Cloud
Community Cloud
Private Cloud
On-premise
Commercial
Service Providing
Web-mail Related
Functions
Commercial
Service Providing
CRM Related
Functions, etc.
Government
Common Platform
Ministry Cloud
(Common Joboperation)
Business
Application
Commercial
Service Providing
Business
Application
Environments
Government
Common Platform
Commercial
Service providing
Infrastructures
Government
Common Platform
Local Government
Cloud (Local
Government ASP)
Infrastructure
Ministry Cloud
Local Government
Cloud (Shared
Service-Center)
Ministry Cloud
Local Government
Cloud (Shared
Service-Center)
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:
53
- 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
54
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
55
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:
56
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
57
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.
58
- 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
59
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
60
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.”
61
- 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.
62
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
63
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
64
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.
65
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.
66
・ 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.
67
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.”
68
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.
69
2000
2004~
2006~
Coordination
(Botnet)
Unauthorized
Intrusion / Defacing
2009~
Multi-staged Attack
(based on Botnet)
Exploiting Authorized
Services as Cyberattack Base
Exploiting Authorized
Sites/Services
Explosion of Virus Sub-species
Sequential Malware (Multi-staged Attack)
Using Zero-Day Vulnerability
Virus Production Using Tools
Targeting Information Systems
Single-attack to Single-vulnerability
Victimizing PCs and Defacing Homepages
Coordination among
Attackers
Single Separated
Attacker
Destruction of PC, Defacing of HP
Building Attack-Bases
Tactical Attack
Multi-Intension Attack(Information Deception)
Changes in Aspects of Damages
(Impact on Job-Operations)
Object: PC or Server
Information Deception, etc.
Impact on e-Market Business or Settlement
Business, etc.
Deception of Account Collection Inf ormation,
etc: Impact on Supply-chain Risk Management
Target: Information Systems (of
Organizations or Businesses)
Countermeasures using Security Products (Available on
Market)
Design Methodology based on Security Products
？
Unchanged
Design
Methodology
Age of Less-Visible Full Aspect and Points of Threat
Inf ormation Protection by Established Inf ormation-Operation
Structure (Inf ormation Collaboration)
Design Policy: Avoiding deep-level intrusions even allowing
shallow-level ones
Embedding Protection Mechanisms in System Designs or
Network Topology Designs
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,
70
(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.
Judgment of Organizational Measures (Assessment
of Influence on Organizational Operations)
Internet Security
Communication-Carrier (ISP), Service
Investigations of
Public Security
Crime-Prevention,
Criminal Investigations
Inf ormation Integrity
Communication
Integrity
National Security
Protection of Critical
Infrastructures
Legal Compliance
Academic Research
Audit
Business Organizational Technical
Challenge Challenge
Challenge
Protection of Intellectual Property of
Private Businesses, etc.
Safety of Manufacturing Line and Cost
What are your organizational objectives?
Efficiency
What is your role?
What influence is predicted to what extent? Security Rating
Who attacks and for what?
Management of System Design (including
security functions)
Intelligence
Standards, Guidelines, etc.
Economy
Compliance and Information-management
Business Continuity
Management
Judgment
Products and Solutions
Security Business
Incidence Report (CSIRT)
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.
71
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
72
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
73
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.
CND (Cyber-Attack Protection)
IA (Information
Assurance)
Target Field of
Cyber-Attacks
Target Field of
Information Assurance
Type 3: Information Management
Functions
Type 4: Factors in management,
etc. (human, facility, rules, etc.)
Type 1: Attack Issues
Protection from
state-of-the-art
attacks
What should be
protected:
Type 2: Information theft issues
“Information leakage by
cyber-attack (theft)”
Organizational
Capability
Business
Trustworthiness
Threats and risks emerge
in the organization
Threats and risks come from
outside of organizations
CND (Cyber-attack defense) and IA (Information assurance) have different
objectives (different operations)
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.
74
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 Protection
Analysis of Threats of Attack
(2) Categorization of
System/design Model
(1) Analysis of Attack Patterns and
Formulation of Attack Scenario
Impact / Risk Analysis
(3) Attack Trace (Simulated
Desktop Attack)
a. Intranet Model
b. Closed Area Model
Classification of Severe Threat models and
Analysis of Attack Specifications
Analysis of Inf luence of Attack and
Ef f ectiveness of Measures Taking Jobmission Impact into Consideration
c. iDC Model
d. SaaS Model
Classification of object Systems of Protection
into the Four Categories shown above
Analysis of Measures
(4) Formulate System-Design Measures from
Trace of Simulated Attack
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
75
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.
Basic Model of Tactical Attack
Philosophy of Measures by Design
★第２、３段階の阻止により組織インパ
★Avoiding
the mission-impact by blocking
クトを回避
the
second / third attack
Preliminary Stage: Object / Motivation / Attack Base
The ultimate impact on organizations
(systems) is avoidable by preventing the
invasion of main attack units and attackobjectives (information theft) even for attack
tactics on which vulnerability-patch or AV
pattern measures is not effective.
Formulation of Attack Plan
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 Malware
etc.
Abuse of
vulnerability
Blocking the communication with DL servers
executed in the second / third stage.
★Blocking the attainment of the final attack
objective, and then destroying the threats
Dropping Initial Attack Unit
Avoid the ultimate damage by blocking the
attacks in the second / third stage, and then
clean viruses and execute anti-vulnerability
measures.
Second Stage: Induction to DL Servers and Drop of
Attack Malware
Dropping Main Attack Unit
Use of attackbases
Identification and Trace of Attack Pattern
Third Stage: Information Theft by Deception and
Handing-over to Attack Commander
★Figuring-out of the Entire Tactical Attack
★戦術的攻撃バターンの全体像の把握
Pattern and Watching for the Appearance of
とパターン監視
Tactical
Patterns
Execution of Attack on Final Destination
Extract the characteristics of the attacks,
which will be the keys to measures by design,
by tracing attack patterns (behaviors)
The Ultimate Threat to Organizations
Figure 4.10-5 Common Basic Models of Cyber-attack assumed in the RM
76
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.
77
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.
78
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
79
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.
80
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.
81
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
82
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
Refers to the following: an approach to utilizing a
(BI)
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,
83
Transform / Load
(Functions for data
extraction, process and
saving)
Data Mart
OLAP — Online
Analytical Processing
(Tools for data
collection or analysis)
ODS — Operational
Data Sore (temporal
data saving system)
Data Mining
Information dashboard
Reporting tool
(Reporting service)
Spreadsheet
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.
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.
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.
Refers to a collection of job-operation data, extracted and
temporarily stored for auxiliary purposes such as search etc.
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.
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.
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.
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.
84
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
ISO / IEC 11179ISO
Meta-Data
JIS X4181-3 (JIS X4181-1, JIS X4181-2) — JIS standards
Registry
fully-compatible with the international standard, ISO / IEC 11179)
85
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.
Related Technologies
Interfaces for
SQL
DB Access
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.].
86
4
5
Basic
Capability of exception-handling, for such cases as error events in
various types of data-flows.
Additional Capability of setting / executing [various types of operations of data
or flow-controls, etc].
Related Technology
Interfaces for
SQL
DB Access
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
SQL
DB Access
87
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.
88
6
7
8
9
10
11
12
13
Basic Capability of providing any dimension or cell with functions of [slicing,
dicing, or drilling, etc] with the equal performance.
Basic Uniformity of structure and operations in every dimension.
Basic Capability of executing dynamic matrix-processing.
Basic Accessibility by multiple-users simultaneously.
Basic No functional limitations of software in cross-dimension processing.
Basic Capability of flexible reporting.
Basic No limitations on the number of dimensions or members
Basic Capability of individually executing each processing [slicing, dicing, or
drilling, etc] without the help of menus.
Related Technology
Interfaces for
SQL
DB Access
Query
MDX (Multi-Dimensional Expressions) — used in obtaining or
Language
manipulating multi-dimensional data.
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
Related Technology
Interfaces for
SQL
DB Access
89
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.
90
7
Additional Functions for data-access or output through [reporting tools or
spreadsheets, etc].
Related Technology
Interfaces for
SQL
DB Access
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.
91
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
92
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.”
93
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
Definition
Service
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
94
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
Additional Employment of meta-data definitions in an industry
Definition
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.
Development Additional Functions of EAI middleware products preparing GUI
Environment
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.
95
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
Refers to a requirement for facility-structures such as
Requirement
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
Preservation of redundancy such as duplexing of power /
Requirement
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.
96
Security Requirement
Operation 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.”
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.
97
3
4
5
6
7
8
9
10
11
12
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.
Basic
Buildings with more than {2} doorways for ensuring more than one
evacuation route available.
Basic
Capacity for installing more than {2} provider-independent
telecommunication lines running on different routes.
Basic
Structure of machine rooms protecting the rooms from being viewed
from outsides, such as a windowless structure.
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.
Basic
Machine-room with ceiling height of more than {2,400} millimeters,
excluding the height of a free-access floor.
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.
Basic
Machine-rooms compartmented against fire.
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.
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 Basic Certification of compliance with the international standards of
Requirement
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.
98
4
Basic
5
Basic
6
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.
Capability of providing the power supply systems (functions) specified in
the procurement specifications of racks or equipment separately
purchased.
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 /
Basic Certification of compliance with “Information Security
Certification of
Management System (ISMS) Compliance Evaluation System
Security
(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.
99
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.
Management
Mashup Portal
Service Intermediation,
Security / Policy
Management
Providing Mashup
Service as the FrontGateway
Business Activity
Management
Application Monitoring,
Management of SLA
and KPI
Development
Environment
Providing IDE or
ApplicationDevelopment
Framework
Business Process Management
Organizing Business Processes Compatible
with Standards, Workflow Management
Enterprise Service Bus
Messaging, Connection, Information Delivery
Adapters
Web Services Protocol
Service
Repository /
Registry
Centralized
Management of
Information on
SOA Services
Providing Connections to
Web Services, Legacy
Infrastructure
Systems, Data Bases, ERPs,
Security, HighReliability Message, banckback-end Systems,
Custom-Application &
Transaction
Service, or JCA
Web Service
ERP / Legacy Application
Business Intelligence
Custom Application / Service
Figure 5.4-1 Major Components in SOA
Functions and Services of SOA
Function / Service
Definition
Business Process
Supports the execution of business processes through defining
Management
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.
100
Mashup Portal
Business Activity
Monitoring
Works as a front gate way and provides the mash-up services.
Monitors job-operations and processes, associates SLA or KPI (Key
Performance Indicators) with the actual business processes, and
visualizes them.
Development
Provides IDE for the development of SOA services and a framework
Environment
for the development of applications.
Service Repository /
Enables the life-cycle management of services through registering,
Registry
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.
101
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
102
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
A Service component, selective and usable with others: it enables a
Component
web service to enhance its function to realize the integrity and
confidentiality of a message.
High-Reliable
Service components, selective and usable with others: They enable
Messaging Service
a web service to enhance its function to improve message-reliability
Component
in the communications with applications distributed on networks.
Transaction Service
Service component, selective and usable with others: it enables a
Component
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
Technology standard used as a basis of SOA or Web service
Standard
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
103
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
X Query: Query language of XML data
Language
XML
XSLT: language for specifying transformation scheme of XML data
Transformation
Language
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
104
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
105
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 WSDL (Web Service Description Language): a specification of description of
Description
web-service interfaces in XML language
Language
Industry
Industry standards used in business fields, such as XBRL (eXtensible
Standard
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
106
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 SOAP (Simple Object Access Protocol): XML-based protocol for calling data
Communication or services existing on other computers
Protocol
Web
Service WSDL (Web Service Description Language): specifications for describing
Description
web-service interfaces in XML format
Language
Web
Service WS-I Basic Profile: a guideline for the enhancement of the interoperability of
Interoperability
SOAP-message-exchange or WSDL descriptions. The V1.1 agreed in WS-I
Profile
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 WS-Security: technology base for realizing the security of web-services, by
Security
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
107
Secure
Communication
Protocol
technologies.
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
XML (eXtensible Markup Language): a markup language for describing
Description
structured data or documents
Language
XML
Schema W3C XML Schema: a schema language for defining structures or data-types
Language
of XML documents
108
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.
Maintenance Environment
Software Engineering Environment
Software Test Environment
Firewall (or Router)
Test LAN
Development LAN
Development Tool
(Maintenance Tool)
Test Tool (
for unit-test or functional test)
PCs f or Developmentwork in Maintenance
Test Tool (for Stress Test)
Version Management
(Configuration Management Tool)
Build Tool
Conf iguration Management
Server
Test Environment
(f or Acceptance Test)
Firewall (or Router)
Inter network (Bridge) LAN
PCs f or LAN System Operator
Job-Operation (actual) Servers
Job-Operation (actual) LAN
Figure 5.5-1 Schematic Diagram of Maintenance Environment
109
Test Tool (for Vulnerability Test)
Staging Environment
The following table describes the definition of functions or services in the maintenance environment.
Function / Service
Maintenance Process
Definition
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 Refers to a tool for managing versions of application programs or
Management Tool
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)
Refers to an internal LAN used for connecting the development LAN
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
Refers to an environment for verification work such as builds,
Acceptance Test)
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
system
deterioration
or
purpose
of
preventing
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.
110
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
Refers to a mechanism for executing the management and operations of IT
Management
services matching the level of customer-requirements, and continuously
improving the service quality.
ISO / IEC 20000, JIS Q 20000, ITIL v. 3
Software
Refers to a series of modification-work of codes and documents of software
Maintenance
for resolving malfunctions, or satisfying requests for improvement or
requests for compatibility to new environments.
ISO / IEC 14764, JIS X 0161
Software
Refers to a framework on which the parties involved in software
Lifecycle
development define the details of various works to prevent mutual
Process
misunderstanding among them.
(SLCP)
ISO / IEC 12207, JIS X 0160, Common Frame 2007
Information
Refers to a management method of establishing, implementing, operating,
Security
monitoring, reviewing, and improving / maintaining information security in
Management
accordance with polices for avoiding business risks.
ISO / IEC 27002, JIS Q 27002
Software
Refers to activities for improving software or its development / maintenance
Engineering
work, through using theories, methods, and software development or
maintenance expertise.
SWEBOK2004 (ISO / IEC TR 19759)
111
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 C# JIS X 3015 2006, ISO / IEC 232702006
Language
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 Apache Struts (1.2.x, 1.3.x.), Apache Struts2 (2.0.x.): Application
Framework
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
112
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
derived
from
predictions
of
performance-requirements
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
113
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
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 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
114
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
115
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
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 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.
116
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.
117
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 /
Basic The authority and responsibility of the auditor shall be clearly
Responsibility
defined in documented rules or contract agreements.
118
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).
119
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
120
process is increased.
Refers to LANs or network equipment for communication between
servers on the common platform system
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.
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.
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.
Server LAN
Web Server
DB Server
AP Server
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.
DB Server
Server LAN
Legacy
Integration
Storage
Individual JobOperation
Web Server
Technology
Domain
Channel Region
the Internet
Remote PC
AP Server
Bac k
(Indiv idual)
Serv er
ERP
Server
Workflow
Server
Application Software Region
Legacy
System
System
Linkage
Common JobOperation
Pers onnel and
Pay ment
Sy s tem
Doc ument
Management
Sy s tem
Budget
Implementation
Management
Sy s tem (SEABIS)
EAI External
Linkage
Operation
Management
Server
Process Region
Communication Equipment
Load
Balancer
Load
Balancer
Authentic ation
Serv er
Minis try
Web
Serv er
Public Web
Server
Portal
Server
Mail
Server
Directory
Server
Web-Service-Related Function
Job-Operation PC
Workflow
BAM
Minis try
Mail
Serv er
Dev elopment
Serv er
Communication Equipment
Server
Hardware
Applic ation-Core
Serv ic e
Information (Data)
Region
Tec hnic al Support
Maintenance
Environment
DB
Server
DWH
Server
Data
Exchange
Server
SOA-Related Functions
(ESB, BPM, UDDI / Service
Directory, Service Management)
Application Platform Region
Operation
Management
Security
Server / Storage
(AP Server, Web
Server, DB Server,
etc)
Server
Legacy
System
Common
Element Region
Figure 5.6-1: Allocation of "Server" Services or Functions in the Infrastructure Configuration Model
121
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.
122
Non-functional Requirement (write only when individually required)
Install Space
Basic
The following shall be included in the server chassis, when it
(Chassis)
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}.
Performance of
Processors
Processor
Instruction-set
Architecture
Expandability of
Processor
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.
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.
Basic
Executable instruction-set architecture already made public,
allowing third parties to develop application. [x86, x64, IA64,
POWER, or SPARC, etc.]
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
123
Backup
Basic
Memory Capacity
Basic
Memory
Expandability
Basic
Memory
Availability
Basic
Additional
Expandability of
I / F transmission
capacity
Additional
I / F Availability
Additional
I / F Maintainability Additional
Capacity of
Internal / External
Disk Drive
Availability of
Internal or
External Disk
Drive
Expandability of
Disk Area
Capacity of Power
Basic
performance by means of scaling-out, the expandability on the
side of servers is unnecessary.
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.
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.
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.
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
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
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.
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
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
Disk area capacity more than {100MB}, where the capacity
means “physical capacity.”
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
Basic
Capability of expanding the data area up to {200 GB}
maximum
Basic
Capability of supplying sufficient power to keep the server
124
Supply
Maintainability of
Power Supply
Availability of
Power Supply
Additional
Additional
Availability of
Power
Additional
Duplexing of
Power Lines
Additional
Fault-tolerance
Capability of
Uninterruptable
Power Supply
System
Maintainability of
Uninterruptable
Power Supply
System (UPS)
Battery
Additional
Redundancy of
Hardware Module
Additional
Procurement
Lead-Time
Basic
Addition of
Hardware
Components
Additional
Maintainability of
OS / Middleware
Additional
Additional
running
Capability of allowing power supplies to be replaced without
stopping the server.
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
• 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}
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
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.
• 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
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.
Time required for the addition of servers or implementation of
new servers (Procurement Lead-Time) is less than {eight
weeks} in normal situations.
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.
The following features are for maintenance:
• Down time of the system service required for the application
125
H/W
Maintenance Term
Green
Procurement
International
Energy Star
(Green IT)
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.
Basic
Term of support for the failures of hardware composing the
server longer than {five} years.
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”
Additional Compatibility with the International Energy Star Program
Related Technology
Protocols for Monitoring and
Control / Standard Interface
Specifications for Server
Management
Network Interface, or
Peripheral Interface
EIA
“Basic Policy for the
Promotion of Procurement of
Eco-friendly Goods”
SPEC
SNMP (Simple Network Management Protocol)
CIM (Common Interface Model)
Serial ATA, PCI, RS-232C, Ethernet (IEEE 802.3), Fiber
Channel, SCSI2, SCSI3, iSCSI, FC-AL, FC-SW, and Infiniband
Electronic Industries Alliance
http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19b
p.pdf
SPEC (Standard Performance Evaluation Corporation)
SPECint, SPECfp
Kernel API Standard
POSIX API Standard (ISO / IEC 9945-1)
Linux Standard Base
Operating System Command / POSIX Command Standard (ISO / IEC 9945-2.1993
Utility Standard
Information Technology, IEEE Std. 1003.2)
Specifications of Battery
JEMA (Japan Electrical Manufacturers' Association)
Failure Notification / UPS
http://www.jema-net.or.jp/Japanese/standard/ups/
Abnormality Notification
Criteria, etc. for Decisions of
Criteria, etc. for Decisions of Manufacturers, etc. on
Manufacturers, etc. on
Improvement of Performance of Electronic Computer,
126
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
Additional Redundancy ensured by full-duplex internal-configuration of
Router / Switch
routers or switches or duplexing devices
Maintainability of
Additional Capability of completing the update of routing information or
Router
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
Basic
Capability of managing routers / switches via the network. In
Maintenance
addition, operations required in a problem situation, such as
Activity of Router /
deactivation of ports or re-writing of routing information are
Switch Operators
executable via a different network reserved for maintenance.
Maximum Down
Additional Down-time of the LAN in the common platform system — the
Time
monthly longest time-span while the LAN is not available —
is {one hour} or less.
127
Average Response
Time
Availability of
Routing Function
Availability
(Duplexing LAN)
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 %}.
Additional Capability of redundantly configuring paths in the data-link /
network layer
Additional LANs have redundant configurations.
Related Technology
Communication Protocols
LAN Standard
Virtual LAN (VLAN)
Monitoring / Control Protocols
Green Procurement
TCP/IP
Ethernet
IEEE 802.1Q
SNMP(Simple Network Management Protocol)
“Basic Policy for the Promotion of Procurement of
Eco-friendly Goods”
http://www.jkiss.or.jp/green/siryo2.pdf
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.
128
9
10
11
Additional Capability of managing configuration information of servers through PCs
placed in remote sites
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
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
Basic Capability of enhancing processing efficiency by means of
Expandability
balancing the load on more than one server for
multiplex-processing
Server
Basic Capability of executing enhancement-work — addition or
Expandability
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}
Related Technology
Mark-up Language
Directory Service
Dynamic
Web-page
Generation
HTML
LDAP
JSP (Java Server Pages)
Java Servlet
ASP.NET
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
129
4
5
6
7
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)
Basic Capability of encrypting or decrypting data that is managed and maintained in a
database; and choosing encryption scheme
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
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
Basic
Capability of improving processing efficiency of database
Processing Power
access by load balancing on more than one server by
multiplexing processes, or by adding computational resources
inside the database server
Database
Basic
Means for recovering the database-system and the data
Fault-Tolerance
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}
130
Related Technology
DB Query Language
Directory Service
Data Encryption Technology
SQL92
SQL99
SQL2003
XQuery
Xpath
LDAP
DES
AES
RC4
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
131
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 Basic Capability of improving processing efficiency by distributing
(Load Balancing)
processes to more than one server
Function
Multiplexing
Basic Capability of improving the overall efficiency by creating and
Threads
executing more than one thread in the server
(Mulithread
Processing)
Reliability of
Basic Capability of, in a situation where the processing requests to the
Request under
AP server are increasing (Heavy Load), queuing requests in wait
System Overload
on the AP server for preventing the loss of requests
Server Expansion
Basic Configuration that ensures server expansion, and execution of the
and Dynamic
expansion while the system is running — without interrupting the
Re-configuration
system
AP Server
Basic Capability of monitoring the services and functions for confirming
Availability
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
Component Program
Execution Infrastructure
Database Access
Technology
Distributed Transaction
Technology
Directory Service
Technology
Basic SOAP
WSDL
Basic J2EE
.NET
Basic OLE DB
ODBC
JDBC
ADO.NET
Basic Java Transaction API (JTA)
COM+
Basic LDAP
132
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
133
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.]
134
9
10
11
12
Basic
Function for assisting adjustment work such as access-performance tuning
inside the storage, or optimization or expansion of configuration
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.
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
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
Basic
Capability of accepting data-accesses continuously in a
Array Device
situation of a failure in disk drives through RAID technology,
etc.; and automatically recovering data-redundancy.
Maintainability of
Additional Capability of adding or replacing disk-drives without
Array Drive
interrupting the operation of the storage
Configuration
Additional Capability of enabling the operating systems, which use the
Change of Logical
storage, to modify the configuration of the logical disk-volume,
Disk Volume
and add or replace logical disk-volume, without interrupting
the system operation
Availability of I / O Additional Interfaces [TCP/IP, FC, FCIP, FCoE, SCSI, iSCSI, SAS, or
Interfaces
Infiniband, etc.] of storage should have redundant
configurations.
Bandwidth of
Basic
Employment of maximum data-transmission capacity between
Storage Data
server and storage of {100 Mbytes / sec} or more
Expandability of
Additional Capability of expanding data-transmission capacity by binding
Channel / Host
more than one interface of the same type, for a case where
Interface
the required data-transmission capacity is unattainable
Transmission
Basic
Data-transmission capacity of I / O channels or host interfaces
Capacity of
{100 m bytes / sec} or more.
Channel / Host
Interface
Data Capacity
Basic
Sufficient capacity to store {2 TB} of data handled in the
common platform system
Data Volume
Basic
Capability of allocating an area of {1 GB} or more per user at
Allocatable to
maximum when users request allocation of memory-areas in
User
NAS or file servers, etc.
Modification of
Basic
Capability of enabling operation systems, which use the
Volume of Data
storage, to dynamically enlarge the allocated memory volume
Allocation
of the server where the operating system is installed
135
Back-up
Availability of
Power
Multiplexing of
Power Line
Fault Tolerance of
Uninterruptable
Power Supply
System (UPS)
Maintainability of
Batteries in
Uninterruptable
Power Supply
System
Procurement
Lead Time
HW Redundancy
System
Performance
Value
Expansion of
Storage Capacity
Term of HW
Maintenance
Green
Procurement
(Green IT)
Additional Capability, as a feature of the storage device, of making a
copy of a volume, independently of the operating system.
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
Additional Configuration of two-power-line-electricity-acceptance for
holding power to keep the storage alive even during inspection
/ construction works
Additional Capability of continuing the supply of power in the case of
UPS failure by bypassing the UPS circuit; or by a configuration
enabling
the
of
two-power-line-electricity-acceptance
equivalent effect to that of USP-by-passing; and notifying the
system administrator of the failure.
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
Basic
Time required for addition of storages or implementation of
new storages (procurement lead-time) less than {eight weeks}
in normal situations.
Additional Hardware components composing a storage unit shall have
redundant configurations, except for an emergency stop
switch, back-boards, or a chassis, etc.
Basic
I / O performance value of the storage operations {larger than
10,000 SOC-1 bench mark} or equivalent.
Basic
Basic
Basic
Capability of allowing post-installation expansion of storage
capacity up-to {5 TB} in total
Term of warranty for failures of storage hardware is longer
than {five years}.
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”).
136
Related Technology
Technologies for Reliability
Improvement of Disk Drive
Storage Interface
RAID, and Grid Storage
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
http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19bp.
Promotion of Procurement
pdf
of Eco-friendly Goods
Battery Alarm Specifications JEMA (Japan Electronic Manufacturing Industry)
/ UPS Alarm Specification
Refer to http://www.jema-net.or.jp/Japanese/standard/ups/
Criteria, etc. for Decisions of Criteria, etc. for Decisions of Manufacturers, etc. on
Manufactures, etc. on
Improvement of Performance of Magnetic Disk-Drive,
Improvement of
Announcement No. 195, Ministry of International Trade and
Performance of Magnetic
Industry, March 31 1999, Final (Complete) Amendment,
Disk-Drive
Announcement No. 51, Ministry of Economy, Trade and Industry,
March 29 2006
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 Basic Maximum data-transfer volume between server and tape-storage
Tape Storage
{80 M bytes / sec} or more
Channel Transfer
Basic Data transfer capacity of I / O channel / host interface {100 M
Capacity
bytes / sec} or more.
Equipment
Basic Time required for the addition of storages or implementation of
Lead-Time
new storage procurement lead-time) shorter than {eight weeks} in
normal situations..
Data-store
Basic Maximum volume of data storable in the tape-storage {10 TB} or
Capacity
more.
137
Related Technology
Storage Interface
Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS,
Infiniband
Monitoring / Control Protocol SNMP (Simple Network Management Protocol)
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
138
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
Basic
Term of warranty for hardware components (maintenance
Hardware
term) is longer than {five years}.
Maintenance
Contract
139
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
Green
Basic
Compatibility with the basic polices of the “Act on Promotion of
Procurement
Procurement of Eco-Friendly Goods and Services by the State
(Green IT)
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”
140
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
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 {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
Additional Operability for more than {two} hours measured according to
Capacity
JEITA Battery Operation Hour Measurement Method
141
Green
Procurement
(Green IT)
Basic
Basic
Drive
Mouse
Key-Board
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”
Compatibility with the International Energy Star Program (Ver.
5.0), notified to the government lead office, and registered
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
Additional Employment of a USB connectable two-button optical mouse
with scrolling feature and 400-count resolution or finer
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
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 {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
Additional Operability of more than {two} hours measured according to
Capacity
JEITA Battery Operation Hour Measurement Method
142
Green
Procurement
(Green IT)
Drive
Mouse
Key-Board
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”
Basic
Procurement of products compatible with the International
Energy Star Program (Ver. 5.0), notified to the government lead
office, and registered
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
Additional Employment of a USB connectable two-button optical mouse
with scrolling feature and 400-count resolution or finer
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
USB 2.0
Connection
Display
Analog RGB (D-Sub 15 pins), DVI-D, HDMI, Display Port
Connection
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
143
3
help
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
144
Mail Client
Viewing Video
Web Page Creation
Creation of Electric Printed
Document
Command-line Environment
Japanese Character Input
(Kana-Kanji Conversion)
Reception of Software
Collection of Inventory
Information
Encryption
Protection against Information
Leakage
on tables
To send or receive electronic mails
To view video files
To edit HTML and post on a web site
To create an electronic printed document through
virtual printers using the application print function
To
execute
file-manipulation
or
configuration-modification using command-lines or
batch-processing
Conversion of Japanese characters entered by the
alphabet-entry-method or kana-entry-method, to
kanjis
Function for receiving software or corrections
delivered from the software management server
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
To encrypt the system, files, or passwords, etc.
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
ISO/IEC 26300 Open Document Format (ODF)
Creation,
ISO/IEC 29500 Office Open XML Format (OOXML)
Presentation,
Spreadsheet
Still Image
JPEG, GIF, PNG
Video
MPEG-1, MPEG-2, MPEG-4/H.264, SMPTE VC-1
Printed
Adobe Portable Document Format Version 1.7 (PDF)
Document
ECMA-388 XML Paper Specification (XPS)
Document
ZIP
Compression
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
145
4
5
6
7
8
9
10
11
12
13
14
15
Basic Capability of collecting information on free space in physical memory
devices
Basic Capability of collecting information on free space in virtual memory
devices
Basic Capability of collecting information on the number of processes in the
active state simultaneously
Basic Capability of collecting the utilization of CPU and usage rate of virtual
memory devices for each process
Basic Capability of collecting input / output information on network interface
cards
Basic Capability of recording and monitoring system events
Basic Capability of monitoring the statuses of services (daemon processes)
active on the OS
Basic Capability of preserving data for a term sufficient for internal control
audits
Basic Capability of allowing usage in multi-user mode (ordinary users and
administrators, etc.)
Basic Capability of browsing device information [CPU, memory, physical disks,
logical disks, MAC address, and external devices, etc.]
Basic Capability of browsing information on installed software
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
146
4
5
6
7
Basic
Basic
Basic
Basic
Capability of controlling automatic data-downloading
Capability of controlling pop-up windows
Capability of controlling access to the URLs of phishing sites
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.
147
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
148
12
13
14
15
16
17
18
19
20
21
22
Basic Capability of using encrypted mailboxes or address books
Basic Capability of accepting and responding to a mail requesting a read
receipt
Basic Function for reading an HTML mail in text or rich-text format
Basic Capability of displaying an HTML mail without help help of browsers
Basic Function for filtering out SPAM mails
Basic Capability for allowing a user to easily know whether a mail has an
attachment or not
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.
Basic Capability of sorting mails in order of title, date, or sender, etc.
Basic Capability of exporting a mail message in a text format or in other
commonly used format
Basic Capability of exporting or importing an address-book in CSV format or
another commonly used format such as vCARD
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.
149
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
150
3
4
5
Basic Capability of encrypting folder by folder, in collaboration with the
authentication authority
Basic Capability of executing encryption / decryption by a simple operation
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
151
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
Basic
Capability of printing {30 pages in monochrome, or 30 pages in
Speed
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
Basic
Capability of printing with a resolution equivalent to {1200} dpi or
Resolution
finer
Printing
Basic
Employment of laser printing, LED printing, ink-jet printing or
152
Method
Maximum
Basic
Power
Consumption
Size
Basic
Weight
Power
Basic
Basic
Tray
Capacity
Interface
Basic
Basic
Basic
Security
Additional
Additional
Additional
Additional
Management
Additional
Additional
Additional
Additional
Green
Procurement
(Green IT)
Basic
Basic
Additional
sublimation / thermal transfer printing
Less than {2.0 K} W
Size, excluding attachments, smaller than {1,200} mm wide x
{1,000} mm deep, and {1,500} mm high
Weight, excluding attachments, of lighter than {300} kg
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)
Capability of using an auto sheet-feeder and feeding {500} sheets
or more
Employment of an interface of standard parallel or USB
connection, or both
Employment of interfaces (10BASE-T, 100BASE-TX, or
1000BASE-T, etc.) for connecting to information systems
Capability of restricting the taking-out of printed sheets
Capability of restricting the receipt of data (printing) using IP
addresses
Capability of authentication for access to setting information
Capability of deleting print-data saved in the equipment in order to
prevent the data from being re-used
Capability of confirming or modifying settings remotely
Function for the realization of an integrated management method
including status-monitoring or settings, or page-count
management or monitoring of multiple devices
Capability of restricting available functions by user groups
[color-printing]
Capability of installing driver programs through a single install
program
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”).
Product compatible with the International Energy Star Program,
notified to the government lead office, and registered
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.
153
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
Basic
Capability of printing {10 pages in monochrome, or 10 pages in
Speed
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
Basic
Capability of printing with a resolution equivalent to {1200} dpi or
Resolution
finer
Printing
Basic
Employment of laser printing, LED printing, ink-jet printing or
Method
sublimation / thermal transfer printing
Maximum
Basic
Less than {30} w for a portable type, or {450} w for a stationary
Power
type
Consumption
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
Basic
Capability of using an auto sheet-feeder and feeding {30} sheets
Capacity
or more
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
154
Management
Additional
Additional
Green
Procurement
(Green IT)
Basic
Basic
Additional
Function for the realization of an integrated management method
including status-monitoring or settings, or page-count
management or monitoring of multiple devices
Capability of installing driver programs through a single install
program
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”).
Product compatible with the International Star Program, notified to
the government lead office, and registered
Eco-mark certified product
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)
155
Printing
Speed
Sheet Size
Color
Printing
Resolution
Printing
Method
Maximum
Power
Consumption
Size
Weight
Power
Tray
Capacity
Copy
Function
Automatic
Document
Feeder
Fax
Functions
Scanning
Function
Basic
Capability of printing {30 pages in monochrome, or 30 pages in
color} or more A4 pages per minute
Basic
Capability of printing a sheet up-to the {A3, A4} size
Selectable Capability of {multi-color / color} printing
Basic
Capability of printing with a resolution equivalent to {1200} dpi or
finer
Basic
Employment of laser printing, LED printing, ink-jet printing or
sublimation / thermal transfer printing
Basic
Less than {2.0 K} W
Basic
Size, excluding attachments, smaller than {1,200} mm wide x
{1,000} mm deep, and {1,500} mm high
Basic
Weight, excluding attachments, lighter than {300} kg
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)
Basic
Capability of using an auto sheet-feeder and feeding {500} sheets
or more
Selectable Capability of selecting color / monochrome copying
Basic
Basic
Basic
Basic
Basic
Basic
Basic
Basic
Interface
Basic
Basic
Security
Additional
Additional
Additional
Additional
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
Capability of registering or managing the fax-destination phone
numbers
Capability of attaching scanned-data files to an e-mail
Capability of storing scanned-data files into private folders or
shared folders on the network
Capability of viewing, loading or deleting the tentatively saved
data by operations on terminals through the network
Capability of selecting color-scan, or monochrome-scan
Capability of scanning with a pre-defined resolution [200dpi,
400dpi, or 600dpi, etc.]
Capability of selecting a format for saving scanned data (PDF,
XPS, JPEG, or TIFF, etc.)
Employment of an interface of standard parallel or USB
connection, or both
Employment of interfaces (10BASE-T, 100BASE-TX, or
1000BASE-T, etc.) for connecting to information systems
Capability of restricting the taking-out of printed sheets
Capability of restricting the receipt of data (printing) using IP
addresses
Capability of authentication of access to setting information
Capability of deleting [copy, fax, scan, or print, etc.] data saved in
the device, in order to prevent the data from being re-used
156
Management
Additional
Additional
Additional
Additional
Green
Procurement
(Green IT)
Basic
Basic
Additional
Capability of confirming or modifying settings remotely
Function for realization of an integrated management method
including status-monitoring or setting, or page-count management
or monitoring of multiple devices
Capability of restricting available functions [copy, fax, scan, or
print data, etc.] by user groups
Capability of installing driver-programs through a single install
program
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”).
Product compatible with the International Energy Star Program,
notified to the government lead office, and registered
Eco-mark certified product
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
157
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
Management
server
Incident
Help desk
Client PC
management
Connection
control
Security
Network devices
Various data
Agent
Agent
Agent
Agent
Anti-virus
software
Anti-virus
software
Anti-virus
software
Anti-virus
software
Client PC
Figure 5.9-1
Schematic Overview of Operation Management (Client PC system)
158
Management
screen
Internet protocol response
time measurement server
Management
server
Agent
Incident
Symbols
Help desk
Availability/performance
management
Response time
measurement
Network management
Storage management
Viability monitoring
Server management
Network devices
Various data
SAN storage
Agent
SAN
Agent
Agent
Agent
Web server
AP server
DBMS
OS
OS
OS
OS
Objects of management (Web server, AP server, DBMS, etc.)
Figure 5.9-2
Schematic Overview of Operation Management (Server system)
Internet
content/spam
filter
Spam mail
filter
Mail
server
Intrusion
detection/
protection
Anti-virus
gateway
Contents
filer server
Anti-virus
gateway
server
Server room
DMZ
IDS/IPS
FW
VPN
Internal
segment
Proxy
server
Encryption (VPN)
Trail
management
Business
server
アクセスログ
Access
log
Log
collection
server
Operation/
management
segment
Internet
Virus pattern
distribution server
Floor
segment
Floor
segment
Encryption (file)
Virus protection
f unction (of fice PC)
Measures against
information take-out
Office room
Figure 5.9-3
Schematic Overview of Security System
159
External
hub
The functions and services provided by the operation management and security are defined as
follows.
Function and
service
Performance
management
Client PC
management
Server
management
Network
management
Storage
management
Service desk
Definition
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 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 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 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 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 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
160
Security
Job
management
control and configuration management capabilities, these functions can be
utilized for resolving problems when they occur.
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 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.
161
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).
162
3
Basic
4
5
6
7
8
9
Basic
Basic
Basic
Basic
Basic
Basic
10 Basic
11 Basic
12 Basic
Capability to gather operation data for each CPU core (in case of a multi-core
CPU system).
Capability to gather utilization information of physical hard disks.
Capability to gather I/O performance information of physical hard disks.
Capability to gather free space information of physical memory.
Capability to gather free space information of virtual memory.
Capability to get the number of concurrently running processes.
Capability to gather information of CPU and virtual memory utilization on a
process-by-process basis.
Capability to gather I/O information of a network interface card.
Capability to monitor event log.
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
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.6. AP Server Performance Management
This function provides methods for gathering information regarding performance of AP servers.
Functional Requirements
163
1
2
3
4
Basic
Basic
Basic
Basic
Capability to gather access number information.
Capability to obtain the number of garbage collections that have taken place.
Capability to obtain the execution time required by a garbage collection.
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
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.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
164
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).
Related technologies
Hyper Text
HTTP(Hyper Text Transfer Protocol)
Transfer
A protocol used for transmission and reception of data between Web servers
Protocol
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.
Dynamic Host
Configuration
Protocol
Domain Name
System
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.
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.
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).
165
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
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).
166
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
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.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
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).
167
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
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).
Related technologies
Remote
RPC (Remote Procedure Call)
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.
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.
168
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.
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.
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.
169
11 Basic
12 Basic
13 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.
Capability to detect, after resource distribution, the client PC where normal
distribution failed, enabling a retry of distribution.
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.
170
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.
171
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.
172
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.
173
4
5
Additional Capability to handle setup operations using major installer formats.
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.
174
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).
175
Security
Basic Capability to assign the authority of accessing the gathered
configuration information of monitored devices only to qualified
persons.
Related technologies
Network
SNMP (Simple Network Management Protocol)
management In a TCP/IP network, this protocol is used to monitor/control the networked
protocol
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.
176
5 Basic
6 Basic
7 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).
Capability to remotely control network devices even in the case of network
failure (assuming that communication to those network devices is still
available).
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.
177
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.
178
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
information must be browsable.
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.
179
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
inquiries
(extendability
must
be
management-related
incorporated).
5.9.6.2. Others
Functional Requirements
1 Basic Capability to record an operations log performed to the service desk, and the
information must be browsable.
180
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
181
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.
182
Security
Performance
Extendability
Basic Inability of the end users to stop the running contents filter, or uninstall
it.
Basic Running of the contents filter and distribution of pattern files shall not
cause excessive delay in other normal system operations.
Basic Provision of scalability to cope with the increased number of terminals
to be checked by the contents filter.
Related technologies
Contents
PICS (Platform for Internet Content Selection)
control
Technical specifications for implementing selective reception of Web contents
standard
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
- The content of this section corresponds to the following segments in the physical configuration
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.
183
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.
- The content of this section corresponds to the following items in the Standards for Information
Security Measures for the Central Government Computer Systems: 2.2.3.1
- The content of this section corresponds to the following segments in the physical configuration
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).
184
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.
- 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.1.1.3, 2.2.4.1
- The content of this section corresponds to the following segments in the physical configuration
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
185
Security Measures for the Central Government Computer Systems: 1.5.1.1, 2.1.1.4, 2.2.4.2
- The content of this section corresponds to the following segments in the physical configuration
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.
Basic
Provision of a function to analyze and summarize information regarding the
7
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
186
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
- The content of this section corresponds to the following items in the Standards for Information
IEEE802.1x
Authentication
Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.1.2.3, 2.2.4.1
- The content of this section corresponds to the following segments in the physical configuration
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
- The content of this section corresponds to the following segments in the physical configuration
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.
187
3 Basic
Capability to perform encrypted
encoding/decoding operations.
communication
without
the
need
of
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
AES(Advanced Encryption Standard)
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
3DES(Triple - Data Encryption Standard)
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
X.509 Certificate.
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.
- 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.6,2.2.4.1,2.2.4.2,2.2.4.3
- The content of this section corresponds to the following segments in the physical configuration
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)
188
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
TLS (Transport Layer Security)
Protocol
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
- The content of this section corresponds to the following items in the Standards for Information
Security Measures for the Central Government Computer Systems: 1.3.1.1,1.3.1.2,1.3.1.3,2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
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.
189
7
Basic
8
Basic
9
Basic
10 Basic
Provision of simple and easy file encryption methods in preparation for storage in
external media.
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.
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.
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.
- 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.6,2.2.4.1,2.2.4.2,2.2.4.3
- The content of this section corresponds to the following segments in the physical configuration
model: S0, S3, and S6
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.
190
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.
- The content of this section corresponds to the following items in the Standards for Information
Security Measures for the Central Government Computer Systems: 1.3.1.1, 1.3.1.2, 1.3.1.3, 2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
model: S0, S1, and S2
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.
191
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.
192
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 A mechanism to achieve on-portal site integration of the job-related
function
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.
193
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
Basic Provision of system configuration with its portal site servers
balancing
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.
Related technologies
Directory service protocol
LDAP (Lightweight Directory Access Protocol)
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.
194
4
5
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
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)).
Related technologies
Web service related protocols
SOAP
WSDL
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.
195
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.
General user
(citizens,
enterprises)
Internet
Communication within the Cabinet
Office and Ministries
Mobile access
server
Mail server
External Proxy
server
Open DNS
server
External f irewall
DMZ
Load balancer
(load balancing
equipment)
Open Web
server
Internal f irewall
DMZ
Intranet
Internal Proxy
server
Internal DNS
server
Figure 5.11-1
CMS equipment
Open Web Server Configuration
196
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 The Content Management System (CMS) provides services
system (CMS)
such as production and management of Web-based digital
content – released/distributed from the WWW services running
and
performs
on
the
open
Web
server
–
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/usagesServer manager
Server management/
audit
-Assumed users/usagesInternet connection users
Web site browsing
File upload/download
-Assumed users/usagesSite (information distribution)
manager
Allocation and authority
settings of information
distribution
Operation management tool/
audit tool
GUI/CUI
Web browser
FTP client
Load balancer (load balancing equipment)
WAF（Web Application Firewall）
FTP service
WWW service
Access log
Operating system
Open Web server
Figure 5.11-2
Schematic Overview of Open Web Server
197
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,…).
198
9
10
11
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.).
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.
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.
199
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
Basic Capability to secure sufficient processing capacity – through
processing
increasing/decreasing server resources, and additional installation
performance
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
Basic Provision of a system configuration that enables the addition of
SSL performance
performance enhancement mechanisms for SSL protocol (for
higher encryption and decoding performance, e.g. SSL
accelerator).
Regular delivery of Basic Delivery of vulnerability and security patch information to the
security patch
server administrator regularly (for example, once a month). This
information to
service shall be included in the information delivery target
middleware and
software provided by the information security service vendor, and
OS
may require affiliation to some kind of information delivery service.
Application of
Basic Capability to perform the following procedures: application, test
security patch to
and verification, and situation-dependent cancelling (deletion) of
middleware and
security patches to the operating system and middleware
OS
distributed by Web page.
Service delivery
Basic Capability of service delivery on a “24 hours a day / 7 days a
time zone
week” basis.
Backup,
Basic Capability to backup data on the open Web site (distributed
restoration
contents and server configuration information) without needing to
stop Web site operations, and to restore the site quickly using the
backup data.
Remote
Basic Provision of a system configuration that enables the performing of
management
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.
200
Related technology
Web server's client-to-client (Web
browser)communication protocol
Web page description language
Technology to run external program
on the server
Server-side script language
Unit for Web processing efficiency
measurement
Authentication scheme
Directory service protocol
Path encryption protocol
Standard for sending/receiving
various types of files as e-mail, or
using HTML protocol
Log file format
Monitoring, Control
Mechanism/Protocol
HTTP (Hyper Text Transfer Protocol)
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).
CGI (Common Gateway Interface)
CGI has been standardized as RFC3875.
Java Servlet
ASP.NET (Active Server Pages for .NET)
SSI (Server Side Include)
PHP (Hypertext Preprocessor)
JSP (Java Server Pages)
SPECweb
Basic Authorization
Digest Authorization
LDAP (Lightweight Directory Access Protocol)
SSL(Secure Socket Layer)
MIME(Multipurpose Internet Mail Extension)
W3C extended log file format
NCSA common log file format
SNMP (Simple Network Management Protocol)
WBEM (Web-Based Enterprise Management)
201
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.
202
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
Basic
Provision of sufficient disk area capacity for the secure
capacity
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
Basic
Capability to expand free space for storage of
disk area
uploaded/downloaded files within a given period of time (this
may be required when capacity shortage is imminent).
Upgradability of
Basic
Capability to secure sufficient processing capacity – through
processing
increasing/decreasing server resources, and additional
performance
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
Basic
Delivery of vulnerability and security patch information to the
of security patch
server administrator regularly (for example, once a month).
information to
This service shall be included in the information delivery target
middleware and
software provided by the information security service vendor,
OS
and may require affiliation to some kind of information delivery
service.
Application of
Basic
Capability to perform the following procedures: application,
security patch to
test and verification, and situation-dependent cancelling
middleware and
(deletion) of security patches to the operating system and FTP
OS
service middleware.
Service delivery
Basic
Capability of delivery on a “24 hours a day / 7 days a week”
time zone
basis.
Backup,
Basic
Capability to backup data on the file storage area of an FTP
restoration
site without needing to stop services, and to restore the site
quickly using backup data.
Remote
Basic
Provision of a system configuration that enables the
management
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.
203
Related technology
File transfer protocol
Directory service protocol
Data encryption protocol in file
transfer
Log file format
Monitoring, control
mechanism/protocol
FTP (File Transfer Protocol)
LDAP (Lightweight Directory Access Protocol)
FTPS (File Transfer Protocol over SSL/TLS)
SFTP (Secure File Transfer Protocol)
W3C extended log file format
NCSA common log file format
SNMP (Simple Network Management Protocol)
WBEM (Web-Based Enterprise Management)
204
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,
Additional Capability to save backup copies of Web contents even while
restoration
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
Directory service protocol
JIS X 8341-3
W3C WCAG (Web Content Accessibility Guidelines) 1.0/2.0
LDAP (Lightweight Directory Access Protocol)
205
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
206
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
207
Web conference
the allowed range of the search results shall be presented to
the user depending on his authority level.
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.
208
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.
209
19
Basic
20
Basic
21
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.
Authentication of a user, when he/she tries to use groupware, shall be
performed using the user ID and password assigned to each user.
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
LDAP (Lightweight Directory Access Protocol) is a standard protocol used for
service
connection with the directory service. LDAP V3 has been established.
protocol
Directory
LDIF (LDAP Data Interchange Format) defines the file formats used to
exchange
exchange LDAP account information.
format
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.
210
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
9
Additional
10
11
Basic
Basic
12
13
Additional
Additional
14
Additional
15
Additional
Electronic mail clients shall have the capability to read and create a mail
even when the network is offline.
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).
Capability to restrict the size of mail boxes provided to the users.
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).
Provision of an option to confirm if the mail has been read.
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).
Capability to save archived mails for auditing: this is a measure to avoid
unauthorized use of mails and information leaks.
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).
211
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
SMTP (Simple Mail Transfer Protocol) is a standard protocol used to send an
transmission electronic mail. It is used when a user sends an electronic mail to the mail
protocol
server, and the electronic mail is transferred between mail servers.
Mail
POP3 (Post Office Protocol) is a protocol used to receive a mail from the server
reception
where electronic mails are stored. It is used when a user tries to receive an
protocol
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
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard method
encryption
used to encrypt an electronic mail, and to create an electronic signature. It is
method
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
212
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.]
213
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
availability by employing such technologies as redundant servers,
clustered software, and replication.
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
Extendability
Backup
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}.
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.
Basic
Capability to save backup copies of data on the shared disks, along
with the configuration information.
214
Related technology
File sharing
CIFS (Common Internet File System) is a standard protocol used to share files
protocol
on a TCP/IP network.
215
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
availability by employing such technologies as redundant servers,
clustered software, and replication.
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.
216
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.
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 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 Capability to encrypt communication to ensure security.
Performance
Additional Provision of a tolerance against the attacks from the users that
threaten security (e.g. SQL injection).
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.
217
Extendability
Backup
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.
Basic
Capability to save backup copies of data (index, etc.) along with the
configuration information.
218
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.
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 define different password for each Web conference,
enabling only the users who received the password notification in
advance to participate in the conference.
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
219
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
WebDAV (Web-based Distributed Authoring and Versioning) – a file
file system
management protocol (an extended version of HTTP) for use in a Web-based
protocol
distributed file system. IETF RFC 2518.
220
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
221
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
Refers to the provision of functions to manage user authentication
management
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.
222
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.
223
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.
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
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.
224
Extendability
Backup
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.
Basic
Capability to save backup copies of account information and
policies.
Related technology
Directory
LDAP (Lightweight Directory Access Protocol) – a standard protocol used to
service access
connect to directory services. LDAP V3 has been established.
protocol
Directory
LDIF (LDAP Data Interchange Format) – a file format used to exchange
service
LDAP’s account information.
interchange
format
Provisioning
SPML (Service Provisioning Markup Language) – a standard protocol used
information
for ID provisioning. SPML V2 has been established.
exchange
language
- 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.1 - 2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
225
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.).
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 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.).
Related technology
Directory
LDAP (Lightweight Directory Access Protocol) – a standard protocol used to
service access
connect to directory services. LDAP V3 has been established.
protocol
Database
JDBC (Java Database Connectivity) – a set of APIs used by Java programs
connection API
to access RDB. Use of these APIs is assumed in case the directory is RDB.
226
- 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.1 - 2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
227
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.
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
Intensive application of access control on the audit log records to
prevent information from tampering.
Additional Capability to encrypt communications.
Performance
Extendability
Backup
Basic
The system assumes {approximately 50 thousand} accounts. The
performance requirements shall be defined clearly in advance to
achieve a configuration with sufficient capacity.
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.
Basic
Capability to save backup copies of settings information (of access
control policies, etc.) and audit logs.
Related technology
Directory
LDAP (Lightweight Directory Access Protocol) – a standard protocol used to
service access
connect to directory services.
protocol
- 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.1 - 2.1.1.4
228
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
229
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.
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
The user ID and password (both are automatically entered) shall be
maintained after encryption.
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 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.
- 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.1 - 2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
230
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.
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
Intensive application of access control on the audit log records to
prevent information tampering.
Additional Capability to encrypt communications.
231
Performance
Extendability
Backup
Basic
The system assumes {approximately 50 thousand} accounts. The
performance requirements shall be defined clearly in advance to
achieve a configuration with sufficient capacity.
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.
Basic
Setting information (e.g. access control policy) and audit log shall
be backed up.
Related technology
Access
RBAC (Role Based Access Control) – a role-based approach to implement
control
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
XACML (eXtensible Access Control Markup Language) – a set of specifications
control
to define a XML-based access control description language. It enables complex
description
conditional settings to the resources.
language
International standard: ITU-T Recommendation X.1142
- 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.1 - 2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
232
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)
233
Functions and Services Provided by Integrated Directory
Functions and
Definition
Services
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)
234
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.
235
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
236
Extendability
Backup
defined clearly in advance to achieve a configuration with
sufficient processing capacity.
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.
Basic
Data of account information stored in the repository shall be
backed up.
Related technologies
Directory
LDAP: LDAP (Lightweight Directory Access Protocol) is a standard
service
protocol used for connection with the directory service. LDAP V3 has
access
been established.
protocol
Directory
LDIF: LDIF (LDAP Data Interchange Format) defines the file formats
service data
used to exchange LDAP account information.
exchange
format
Database
JDBC: JDBC (Java Database Connectivity) represents a set of APIs
access
used by Java programs to access RDB. Use of these APIs is assumed
technology
in the case where the directory is RDB.
- 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.1 - 2.1.1.4
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
237
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.
XX Ministry
XX Ministry
LAN
LAN
Remote access
Switch
Switch
Figure 5.15-1
Router, etc.
Switch
Router, etc.
Switch
WAN
Positioning of LAN in the network
238
Definitions of the functions and services provided by LAN are as follows.
Functions and
Services
Layer-3 switch
Layer-2 switch
Secure
wireless LAN
Definition
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 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.
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
5
Basic
6
7
Basic
Basic
8
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.
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.
Provision of VLAN functions compatible with IEEE802.1Q.
Provision of link aggregation functions compatible with
IEEE802.3ad.
Provision of spanning tree protocol functions compatible with
IEEE802.1D, IEEE802.1w, or IEEE802.1s.
239
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
11
Basic
Provision of correct cables (category 5, etc.) that fit the ports.
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
Basic Provision of a console port that can be used to track
maintenance
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.
240
Basic
Basic
Basic
Basic
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.
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.
Provision of a function (port mirroring, etc.) that enables
traffic analysis over the layer-3 switch.
Provision of a function to transfer logs (Syslog and others) to
the server.
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
FTP (File Transfer Protocol) is a protocol to transfer files.
protocol
RFC959
TFTP (Trivial File Transfer Protocol) is a protocol to transfer
files. RFC1350
Multicast
PIM-SM (Protocol Independent Multicast- Sparse Mode) is a
protocol
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
NTP (Network Time Protocol) is a protocol used to secure the
protocol
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
241
management
protocol
Communication
protocol
Encrypted
communication
protocol
router
redundancy
protocol
Log message
transfer protocol
Link aggregation
protocol
Virtual network
Loop-free
protocol
Ethernet
communication
standard
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.
TELNET is a protocol that provides general purpose
bidirectional communication and virtual terminals. RFC854
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.
VRRP (Virtual Router Redundancy Protocol) is a protocol that
enables redundant configurations in the system consisting of
layer-3 switches and routers. RFC2338
Syslog is a protocol for transferring log messages of the network
devices to external servers via the IP network.
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
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
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
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
242
Electricity
Supply Standard
Authentication
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
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.
243
Non-functional requirements
Performance 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.
Operational
Basic Provision of a console port that can be used to track
maintenance
modifications of setting information and check operational
status.
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.
Basic Provision of a function to transfer logs (Syslog and others) to
the server.
Basic Mountability in a 19-inch rack.
244
Related technologies
File transfer
FTP (File Transfer Protocol) is a protocol to transfer files. RFC959
protocol
TFTP (Trivial File Transfer Protocol) is a protocol to transfer files.
RFC1350
Network time
NTP (Network Time Protocol) is a protocol used to secure the
protocol
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
SNMP (Simple Network Management Protocol) is a protocol used to
management
monitor/control network devices through networks based on MIB
protocol
(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.
Communication TELNET is a protocol that provides general purpose bidirectional
protocol
communication and virtual terminals. RFC854
Encrypted
SSH (Secure Shell) is a protocol that provides encrypted
communication communication and virtual terminals. This is the program used, for
protocol
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.
Log message
Syslog is a protocol for transferring log messages of the network
transfer
devices to external servers via the IP network.
protocol
Link
Link Aggregation is a protocol that enables enhancement of path
aggregation
redundancy and the securing of wide bandwidth through logical
protocol
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
245
Loop free
protocol
Electricity
Supply
Standard
Authentication
standard
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
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
IEEE802.1X
246
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
Basic Capability to manage the AP using SNMP.
maintenance Basic Link capability with the Syslog server.
247
Related technologies
Wireless LAN
IEEE802.11a (W52,W53,W56), IEEE802.11b/g,n
standard
Wireless LAN
WPA (Wi-Fi Protected Access) is a standard used for wireless
authentication
LAN authentication. IEEE802.11i
method
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
AES (Advanced Encryption Standard) is a symmetric-key
standard
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
TLS (Transport Layer Security) is characterized by combined
protocol
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
ESS-ID stealth is a function to conceal a part of the “beacon
wireless LAN
signal” train (i.e. transmission of ESS-ID, network identification, at
detection
a regular interval to external world).
IEEE 802.11
Electricity
POE (Power Over Ethernet) is a method to supply power to
Supply
network devices - wireless LAN access points, IP telephones, etc.
Standard
– utilizing LAN cables. IEEE802.3af
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
Network
SNMP (Simple Network Management Protocol) is a protocol used
management
to monitor/control network devices through networks based on
protocol
MIB (Management Information Base). The devices generally
248
Log message
transfer
protocol
support one or more of the following three versions: SNMPv1,
SNMPv2c, SNMPv3.
Syslog is a protocol for transferring log messages of the network
devices to external servers via the IP network.
249
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.
XX Ministry
XX Ministry
LAN
LAN
Remote access
Switch
Switch
Figure 5.15-2
Router, etc.
Switch
Router, etc.
Switch
WAN
Positioning of WAN in the network
Definitions of the functions and services provided by a WAN are as follows.
Functions and
Services
Router
Line service
(Inter-hub network)
Line service
(Internet connection)
Definition
A router is a piece of equipment that relays the data
flowing within a network to other networks.
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) 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).
250
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.).
3
4
5
6
7
8
9
Additional Provision of a routing function (OSPFv2/v3, BGP, etc.).
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).
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.
Basic
Router:
The router shall have a shaping function.
Additional SW:
The SW shall have a shaping function.
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.
Additional In cases where the router is connected to a network with
overlapping network addresses, provision of an NAT, NAPT
function is required.
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.
Basic
Provision of correct cables (category 5, etc.) that fit with the ports.
251
Non-functional requirements
Performance
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.
Operational
Basic
Provision of a console port that can be used to track
maintenance
modifications of setting information and check
operational status.
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 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
Provision of a function to transfer logs (Syslog and
others) to the server.
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
252
File transfer
protocol
Time
synchronization
protocol
Network
management
protocol
Communication
protocol
Encrypted
communication
protocol
Log message
transfer protocol
Ethernet
communication
standard
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
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.
TELNET is a protocol that provides general purpose
bidirectional communication and virtual terminals. RFC854
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.
Syslog is a protocol for transferring log messages of the network
devices on the IP network to external servers.
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
253
Encrypted
communication
standard
Key exchange
standard
Network address
conversion
standard
IPsec is the standard for the use of encrypted communication.
RFC2401(Security Architecture for the Internet Protocol),
RFC2406(IP Encapsulating Security Payload [ESP])
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))
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.
254
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.
Operational
Basic Provision of a contact for inquiries in case of troubles that
maintenance
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.
255
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).
Operational
Basic Provision of a contact for inquiries in case of troubles that
maintenance
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
256
protocol
perform path exchanges dynamically with the layer-3 switches or
routers. RFC4271
257
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
Remote access device
Switch
Router/FW
Switch
Figure 5.15-3
Internet
Remote access device configuration in a network
Functions, services, and definitions of remote access are as follows.
Functions and
Definition
Services
Remote access Refers to the devices that terminate accesses from the external
device
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.
258
6
Basic
7
Basic
Web applications shall be operational while the remote access devices
are being connected using SSL and other schemes.
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
Basic Capability of being operated by way of Web-browser and
maintenance
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.
Basic Mountability in a 19-inch rack.
Related technologies
Encrypted
IPsec is the standard for the use of encrypted communication.
communication RFC2401 (Security Architecture for the Internet Protocol),
standard
RFC2406(IP Encapsulating Security Payload [ESP])
Communication
protocol
File transfer
protocol
Encrypted
communication
protocol
Network
management
protocol
TELNET is a protocol that provides general purpose bidirectional
communication and virtual terminals. RFC854
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.
259
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.
XX Ministry
XX Ministry
DNS/DHCP/Proxy server
DNS/DHCP/Proxy server
Switch
Switch
Router, etc.
Switch
Router, etc.
Switch
Figure 5.15-4
DNS/DHCP/Proxy server configuration in a network
The definitions of DNS/DHCP/Proxy are as follows.
Functions and
Services
DNS server
DHCP server
Proxy server
Definition
A DNS server manages relations between IP addresses and
domain names, or host names.
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.
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.
260
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.
Non-functional requirements
Performance Basic Provision of a response capability to the requests from
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.
Operational
Basic Capability to clear the cache.
maintenance Basic Capability of being maintained from remote devices.
Basic Mountability in a 19-inch rack, or compatibility with floor
mounting.
Related technologies
Domain name
DNS (Domain Name System) manages correspondence between
system
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.
Non-functional requirements
Performance Basic Provision of a response capability to the requests from
clients located within the range of service delivery.
Reliability
Basic Capability to achieve a redundant configuration of devices.
Operational
Basic Capability of being maintained from remote devices.
maintenance Basic Mountability in a 19-inch rack, or compatibility with floor
261
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
262
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.
Non-functional requirements
Performance 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
Basic Capability of being maintained from remote devices.
maintenance 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
HTTP (Hyper Text Transfer Protocol) 1.1. RFC2068
transfer protocol
Web page
HTML (HyperText Markup Language) is a markup language used
description
to describe a Web page.
language
263
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.
IDC
XX Ministry
LAN
LAN
Operational VoIP server, VoIP gateway
IP
telephone
Switch
Switch
Switch
Router, etc.
Router, etc.
Switch
WAN
Standby VoIP server, VoIP gateway
Figure 5.15-5
VoIP server/gateway configuration in a network
Functions, services, and definitions of VoIP are as follows.
Functions and
Services
VoIP server,
VoIP gateway
Definition
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.
264
6
Basic
7
Basic
8
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.
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.
The control protocol used in the IP telephone transceivers shall
conform to SIP (IETF RFC3261).
Non-functional requirements
Performance 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.
Operational
Basic Provision of a log that can be used to track modifications of
maintenance
setting information and check operational status.
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 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 Provision of a function to transfer logs (Syslog and others) to
the server.
Basic Mountability in a 19-inch rack, or compatibility with floor
mounting.
Related technologies
Protocols for IP SIP (Session Initiation Protocol) is a control protocol for IP
telephone and
telephone and others. IETF RFC3261
others
Authentication
IEEE802.1X
265
standard
File transfer
protocol
Log message
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
Syslog is a protocol for transferring log messages of the network
devices to external servers via the IP network.
266
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.
267
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
Universal
Multiple-octet Coded
Character Set
Graphic format
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
Unicode: ISO/IEC 10646
JPEG: ISO/IEC 15444-1, -2, -3
PNG: ISO/IEC 15948
268
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6-1 Classification of procurement of services
269
Table 6-1 Explanation of services
Service
6.1 Support for master plan
formulation
6.2 Support for procurement
6.3 System integration
(design/development)
6.4 Operation
6.5 Helpdesk
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
6.8 Tasks incidental to
procurement of iDC equipment
6.9 Network procurement
6.10 Cloud service
6.11 Cloud construction
6.12 Security
6.13 Other (to be created)
Service operation
Planning the systematization initiative and creating a
systematization plan
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.
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)
Service operations concerning helpdesk to respond to
inquiries from users on system operation
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)
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.
Service operations using cloud system services
Service operations to construct cloud systems
This section describes security cautions in procurement
of services and security approaches during
construction of information systems
Service operations not included in 6.1 – 6.12, such as
procurement of business package software.
270
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
for master
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.1-1 Items corresponding to the areas of procurement of services
271
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-2007 1 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
1.
Systematization
initiative
2.
Systematization
plan
SLCP-2007
activity
Outline of service operations
Extracting issues on existing systems(* for
existing systems)
Study on demand for systematization
Study on technological trends
Formulating systematization initiative, etc.
Considering system outline
Formulation of schedule of
design/development/migration/
operation
Implementation of rough estimates
Formulating systematization plan , etc.
1
1.4.2
Systematization
initiative
1.4.3
Systemization
plan
Chapter/section
corresponding to
Basic Guidelines for
2
Procurement (and
its title)
－
－
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
272
6.1.2.2. Explanations and examples of descriptions in specifications concerning services
1. Systematization initiative
Item
Outline of services
Description
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
Requirements definition document and design document for
(Prepared by the
existing systems (*for existing system)
procurer)
Demands from procurers for systematization
Set of relevant materials in cases where there are materials
concerning the previous optimization plan
Product
Systematization initiative document
(Prepared by the
contractor)
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
[1. Basic requirements to be listed]
a description in
(1)Studies on demand for systematization
specifications
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]
273
●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
systematization initiative
274
shall
be
included
in
the
2. Systematization plan
Item
Description
Outline of service
Upon giving shape to the future image of the system and making
operations
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
Requirements definition document and design document of existing
(Prepared by the
systems (*for existing systems)
procurer)
Demand from procurer for systematization
Product
Systematization plan
(Prepared by the
Optimization plan (*for systems subject to optimization)
contractor)
Matters to be
Enter requirements for systematization plans
described in
[1. Basic requirements to be listed]
specifications
・ 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
[1. Basic requirements to be listed]
of a description in
(1) Consideration of system overview
specifications
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
275
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
Optimization plans for systems subject to business/system
characteristics of
optimization shall be created, as defined in the Guidelines for
projects/information
Business/System Optimization Plan.
systems
Notes on security
In cases of information systems that deal with critical information,
systemization plans shall include considerations for security.
276
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
At the completion of the project
Optimization plan
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
Requirements definition
At the time of tender publishing
initiative
document and design document
of existing system, etc.
Demand from the procurer for
At the time of tender publishing
systematization
2. Systematization plan
Concept of systematization
At the time of tender publishing
Requirements definition
At the time of tender publishing
document and design document
of existing system, etc.
Demand from procurer for
At the time of tender publishing
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.
277
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.”
Basic
design
Requirements
definition
Detailed
design
Development
/test
/migration
Operation
/maintenance
 Support for
Major
services
 Support for project management
requirements
(formulation of project plan, progress management, issue management, change
definition
management, quality management, risk management, etc.)
Support for

procurement
following basic
 Support for procurement
(creation of specifications, creation of assessment criteria, etc.)
design (creation of
specifications,
creation of
 Support for other operations
assessment criteria, (product management, operation of conferences, etc.)
etc.)
6.2.2 Support for
By TRM
classification procurement in the
6.2.3 Support of procurement following design/development, such as
project management
requirements
definition phase
Figure 6.2-1 Classification of services in support for procurement
Service classification
6.2.2 Support for procurement in
requirements definition phase
Applicable service operations
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
The contractor shall provide support for service operations, such
design/development, such as project
as project management concerning system development and
management
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).
278
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
(requirements
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.2-2 Scope of the applicable services in the process of information system
279
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-2007 3
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
1. Confirmation/evaluation/
improvement/estimation of
effects of the optimization plan
2. Support for requirements
definition
3.Estimation of system cost
4.Support for procurement
operations
Outline of service operations
Support for confirmation/
evaluation/improvement/
estimation of effects of the optimization
plan
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
Construction of system/estimation of
operation cost based on requirements
definition implemented in Section 2.
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.
3
Activities of
SLCP-2007
Chapter and
section of
specifications
corresponding to
BGP (and its
title)
1.4.3
Systematization plan
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
1.5.2.5
Definition of
non-function
requirements
1.1.2
Preparation of
presentation request
1.1.3
Preparation and
renewal of contract
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
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
280
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
To confirm and evaluate the optimization plan, and make
operations
improvements as necessary.
To provide support for estimation of optimization effects.
Suggested input
・ Optimization plan
(Prepared by the
procurer)
Product
(Prepared by the
・ Report on the optimation plan in terms of the
confirmation/evaluation/improvement/estimation of effects
contractor)
Matters to be
[1. Basic requirements to be listed]
described in
・ Confirmation/evaluation/improvement proposals for optimization
specifications
plans
・ Estimation of the effects at the time of implementing the plan
Example/explanation
○The contractor shall make proposals for
of a description in
confirmation/evaluation/improvement proposals of an optimization
specifications
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
This operation becomes necessary only when an optimization plan is
project/information
created in “6.1 Support for formulating master plan”
system
Notes on security
－
281
2. Support for requirements definition
Item
Description
Outline of Service
Support for requirements definition concerning system and business
operations
procurement.
Suggested input
・ Systemization plan
(Prepared by the
・ Optimization plan (* when there is an optimization plan)
procurer)
・ 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
・ Requirements definition document
(Prepared by the
contractor)
Matters to be
[1. Basic requirements to be listed]
described in
Support for requirements definition with respect to the following
specifications
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
○Implementation of requirements definition
of a description in
The following requirements shall be defined and requirements
specifications
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
282
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
If organizational change happens, its effects shall be discussed in the
projects/information
requirements definition.
systems
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
283
3. Estimation of system cost
Item
Description
Outline of Service
To estimate the cost for system integration/operation from the results
operations
of requirements definition
Suggested input
・ Requirements definition document
(Prepared by the
(for product stated in Section 2)
procurer)
Product
・ Estimated cost of system integration (draft)
(Prepared by the
・ Estimated cost of operations (draft)
contractor)
Matters to be
[1. Basic requirements to be listed]
described in
・ Cost estimation and creation of cost estimation document
specifications
Example/explanation
○Cost estimation and creation of estimated cost document
of a description in
・ The contractor shall estimate the cost of defined functions and
specifications
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
－
projects/information
systems
Notes on security
－
284
4. Support for procurement operations
Item
Outline of Service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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.
・ Optimization plan (* if there is an optimization plan)
・ Requirements definition document (for product listed in Section
2)
・ 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)
[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.
[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
285
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).
Notes on security
－
286
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.
Report on confirmation
After conclusion of contract
Confirmation/evaluation/
evaluation/improvement proposals for
(example of a 6-month project:
improvement proposal
optimization plans and estimation of effects
around 1.5 months after the
for optimization plan
conclusion of contract)
and estimation of effects
2.Support for
Requirements definition document
requirements definition
After conclusion of contract
(example of a 6-month project:
around 2.5 months after the
conclusion of contract)
3.Estimation of system
Estimation of cost of system integration
After implementation of
cost
Estimation of operation cost
requirements definition
4.Support for
Procurement plan document (draft)
Date designated by
procurement
Procurement specifications (draft)
ministries/agencies
operations
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)
287
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
1. Confirmation/evaluation/
Timing to present input
Optimization plan
At the time of formulation for the
improvement proposal for
optimization plan
optimization plan and estimation of
effects
2.Support for requirements
Systematization plan
At the time of release of
definition
Optimization plan
specifications
(reflecting Section 1)
Date designated by
ministries/agencies
3.Estimation of system cost
4.Support for procurement
operations
Requirements definition document
After implementation of
(product in Section 2)
requirements definition
Optimization plan
After operations of requirements
Requirements definition document
definition
(product stated in Section 2)
(*A set of support operations, such as requirements specifications for next-term infrastructure
information system of the Ministry of ___, 2010)
Confirmation/evaluation/improvement proposal for
optimization plan and estimation of effects
Creation of next-term system procurement plan
Specifications for request for comment, etc.
Estimation of system cost based on the draft of
specifications for request for comment
(requirements definition)
(Creation of rough
draft)
(Creation of
final draft
(Creation of
draft)
(Creation of estimation)
Creation of draft of WBS items related to support
for technical review, etc.
(Reference)
Revision of optimization plan
Next-term system requirements
specifications
(Draft creation)
(Intra-ministerial coordination/approval
procedure)
(Creation of
specification)
(Intra-ministerial
coordination/coordination with MIC)
Figure 6.2-3 Example of table of overall schedule
288
March
February
January
December
November
October
September
August
July
Fiscal Year 2010
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).
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.4 運用
6.4 Operation
6.2.3 Support for
procurement
(Project management, etc.)
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.2-4 Scope of applicable services in the process of information system
289
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
SLCP-2007 53 activities are also given. For actual procurement, correspondence to SLCP activities
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
1.Project management
2.Support for
procurement
3.Support for other
operations
Activities of SLCP-2007
Outline of service operations
Activities of
SLCP-2007
Creation of a project plan, progress
management, issue management,
change management, quality
management, risk 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.
Product management, Operation of
conferences
1.2.4 Planning
1.2.5
Implementation and
management
5
Chapter and
section of
specifications
corresponding
to BGP (and its
title)
―
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
290
6.2.3.2.2. Explanation on services and examples of descriptions in specifications
1. Project management
Item
Description
Outline of service
Formulate project plans and define the method of project
operations
management, etc.
Implement various types of management, such as progress
management, issue management, change management, quality
management, and risk management
Suggested input
・ Systematization initiative
(Prepared by the
・ Systematization plan
procurer)
・ Optimization plan
・ Requirements definition document
Product
・ Project management plan
(Prepared by the
・ Report on project management
contractor)
Matters to be
[1. Basic requirements to be listed]
described in
・ Formulation of project plan
specifications
・ 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
[1. Basic requirements to be listed]
of description of
○Formulation of project plan
specifications
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
291
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
－
projects/information
systems
Notes on security
－
292
2. Support for procurement
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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
・
・
・
・
・
・
・
・
・
・
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)
[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.
293
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.
Notes on
characteristics of
projects/information
systems
[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).
Notes on security
－
294
3. Support for other operations
Item
Description
Outline of service
Support for operations of the procurer, such as product management
operations
and conference operations, etc.
Suggested input
－
(Prepared by the
procurer)
Product
・ Product management plan (draft) (*)
(Prepared by the
・ Communication management plan (draft) (*)
contractor)
・ Conference minutes (draft)
(*) Not necessary if it is defined in the project management plan
Matters to be
[1. Basic requirements to be listed]
described in
・ Product management
specifications
・ Operation of conferences
Example/explanation
[1. Basic requirements to be listed]
of a description in
○Product management
specifications
・ 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
－
projects/information
systems
Notes on security
－
295
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.
Service
1.Project management
Deliverable product
Delivery deadline
Project plan
Project plan: within one month
Report on project management
after conclusion of a contract
Report on project management:
monthly
2.Support for
Procurement plan (draft)
Date designated by
procurement
Procurement specifications (draft)
ministries/agencies
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)
3.Support for other
Minutes
Within __ business days after
operations
conference
6.2.3.4. Suggested input
The following table shows input and timing to be presented to procurers (proposers) in advance.
The official name of each product and its delivery deadline need to be entered in accordance with the
actual situation.
Service operations
Input
Timing to present input
1.Project management
－
－
2.Support for procurement
Optimization plan
After implementation of
Requirements definition document
requirements definition
－
－
3.Support for other
operations
6.2.3.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.
296
6.3. System Integration (Design/Development)
This Chapter covers services related to construction of information systems, including design,
development, migration and operational design.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
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.
297
Hardware
Referring to a system development project for application migration due
renewal
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
Program Management Office (PMO).
Service operations
Outline of service operations
Activities of SLCP-2007
1.Preparation for
development
environment
Securing devices (hardware,
development tools, etc.), and
work site for development
1.6.1
Preparation for process
initiation
2.Creation of the
development plan
Creating design/development
plans (schedule, framework,
division of roles, work details,
development environment,
development tools, product,
etc.)
1.6.1
Preparation for process
initiation
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.
4.Detailed design
Program design (list of
development programs and
definition of specifications,
etc.), data design (physical
model), screen design, form
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
1.6.6
Detailed software design
7
Chapter and section
of specifications
corresponding to
BGP
Chapter II (5.1)
Description of work
Chapter XII (2)
Method of
development
Chapter II (5.1)
Description of work
Chapter XII (2)
Method of
development
Chapter II (5.1)
Description of work
Chapter XII (2)
Method of
development
Chapter II (5.1)
Description of work
Chapter XII (2)
Method of
development
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
298
Service operations
Outline of service operations
5.Unit test,, integration
test, system test,
connectivity test with
other systems
design, system architecture
design, external interface
design and information security
design, which are based on the
basic design
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
6.Acceptence test
support
7.Migration
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
Migrating data necessary for
operations and inputting initial
data
Migration form development to
the live environment
Activities of SLCP-2007
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
1.6.13
Software acceptance
support
Chapter II (5.1)
Description of work
Chapter VIII
Definition of test
requirements
Chapter XII (2)
Development method
1.8.5Migration
Chapter II (5.1)
Description of work
Chapter IX (1)
Requirements
concerning migration
Chapter XII (2)
Development method
Chapter II (5.1)
Description of work
Chapter IX (2)
Requirements
concerning education
Chapter II (5)
Description of
operations/
Deliverable product
8.User education
Creating education plans and
system usage manuals
Implementing training for
government officials
1.6.13
Software acceptance
support
9.Transfer to
operation/maintenance
contractors
Operation design
Transfer to operation
/maintenance contractors
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
Delivering necessary products,
and making corrections if
deemed necessary
1.7.1
Preparation for process
initiation
1.8.1
Preparation for process
initiation
3.1.2
Planning
3.1.4
Implementation and
management
11.Acceptance
Chapter and section
of specifications
corresponding to
BGP
1.2.7
Delivery and completion
299
Chapter II(5.1)
Description of work
Chapter XII(2)
Development method
Chapter II (5.1)
Description of work
Chapter XII (2)
Development method
Chapter II (5)
Description of
work/deliverable
product
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
Item
Outline of service
Description
Securing of necessary development devices and work site
operations
Suggested input
Outline of new system infrastructure (scheduled)
(Prepared by
Operating environment
procurer)
Operating conditions
Requirements definition document
－
Product
(Prepared by
contractor)
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ Construction of system design and development environment
(work site, devices and expendables)
・ Management of development environment
Example/explanation
Examples of descriptions in specifications
of descriptions in
・ System design and development devices shall be prepared and
specifications
borne by the contractor.
・ Sufficient security measures for development environment
(devices/work site, etc.) shall be taken.
Notes on
If development environment cannot be prepared on site, there is
characteristics of
room for considering creating a development repository.
projects/information
systems
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.
300
2. Creation of development plan
Item
Outline of service
operations
Suggested input
(Prepared by
procurer)
Product
(Prepared by
contractor)
Matters to be stated in
specifications
Example/explanation
of descriptions in
specifications
Description
Creation of design/development plan
・
・
・
・
・
・
・
・
・
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
Project plan
Design/development plan
[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.
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
301
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.
Notes on
characteristics of
projects/information
systems
Notes on security
○Division of roles
・ Clarification of roles of each project participant so that each can
be aware of its own roles in the entire project.
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.
－
302
3. Basic design
Item
Description
Outline of service
Function design, data design, screen design, form design, system
operations
architecture design, external interface design, information security
design, which are based on requirements definition.
Suggested input
・ Requirements definition document
(Prepared by
・ Basic design document for existing systems (excluding new
procurer)
development)
・ Security policies prescribed by each ministry
・ Standards for Information Security Measures for the Central
Government Computer Systems
Product
・ Basic design document (Function design document, data design
(Prepared by
document, screen design document, form design document,
contractor)
system architecture design document and external interface
design document may be separately published)
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ 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
Examples of descriptions in specifications
of descriptions in
○ Items in the basic design document.
specifications
・ 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.
303
・ 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
Depending on a project, one contractor may carry out both the
characteristics of
requirements definition and design/development. Please refer to
projects/information
“6.2.1 Requirements definition” for descriptions concerning the
systems
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.
304
4. Detailed design
Item
Outline of service
operations
Suggested input
(Prepared by
procurer)
Product
(Prepared by
contractor)
Matters to be stated in
specifications
Example/explanation
of descriptions in
specifications
Notes on
characteristics of
projects/information
systems
Notes on security
Description
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.
－
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.
305
5. Unite test, integration test, system test, and connectivity test with other systems
Item
Description
Outline of service
Creation of source code based on detailed design
operations
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
The following data and documents are related to unit tests,
(Prepared by
integration tests and system tests:
contractor)
・ Test data
・ Test plan
・ Test procedures (test specifications)
・ Test result/quality assessment report
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ 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
Examples of descriptions in specifications
of descriptions in
○Creation of test plans
specifications
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
306
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.
307
(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
projects/information
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.
308
6. Acceptance test support
Item
Outline of service
operations
Description
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.
Suggested input
(Prepared by
procurer)
Product
(Prepared by
contractor)
Matters to be stated in
specifications
Example/explanation
of descriptions in
specifications
Notes on
characteristics of
projects/information
systems
Notes on security
－
・ 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
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.
－
309
7. Migration
Item
Outline of service
operations
Suggested input
(Prepared by
procurer)
Description
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
Matters to be stated in
specifications
・ 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
Example/explanation
of descriptions in
specifications
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
Product
(Prepared by
contractor)
310
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.
Notes on
characteristics of
projects/information
systems
Notes on security
○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
－
311
8. User education
Item
Description
Outline of service
Creation of an education plan and operation manual
operations
Holding training for ministry officers
Suggested input
・ Target, venue and period of educational training
(Prepared by
・ Operation manual (existing) (excluding new development)
procurer)
Product
・ Education plan
(Prepared by
・ Training text
contractor)
・ Operation manual
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ 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
・ Examples of descriptions in specifications
of descriptions in
○Creation of the operation manual
specifications
・ 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
312
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
projects/information
systems
Notes on security
User education
・ Education on information security shall be offered to system
users.
313
9. Transfer to operation/maintenance contractors
Item
Description
Outline of service
Operation design
operations
Transfer to operation management contractor and maintenance
contractor
Suggested input
(Excluding new development)
(Prepared by
・ Operation design (existing system)
procurer)
・ Operation manual (existing system)
Product
・ Operational design
(Prepared by
・ Operation manual
contractor)
・ Table of maintenance framework (draft)
・ Transfer plan
・ Transfer report
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ 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
Examples of descriptions in specifications
of descriptions in
○Operation design
specifications
・ 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.
314
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
Operation tools and procedure manual shall be provided when
characteristics of
necessary.
projects/information
systems
－
Notes on security
315
10. Project management
Item
Description
Outline of service
Implement project management for design/development operations,
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
・ Materials for progress management
(Prepared by
・ Table of task management
contractor)
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ Progress management
・ Document management
・ Issue/problem management
・ Configuration management
・ Change management
・ Information security management
Example/explanation
Explanation
of descriptions in
○Progress management
specifications
・ 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
316
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
This section describes project management services for the
characteristics of
design/development contractor.
projects/information
Please refer to “6.2.3 Project management” for project management
systems
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.
317
11. Acceptance
Item
Description
Outline of service
Make necessary product delivery and carry out repair if deemed
operations
necessary
Suggested input
－
(Prepared by
procurer)
Product
・ Report of project completion
(Prepared by
・ Each document
contractor)
・ Set of programs, including source code, implementation module,
etc.
Matters to be stated in
[1. Basic requirements to be listed]
specifications
・ 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
Examples of descriptions in specifications
of descriptions in
・ Deliver deliverable product based on the requirements described
specifications
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
－
projects/information
systems
－
Notes on security
318
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
1.Preparation for development
environment
2.Creation of development plan
Deliverable product
3.Basic design
Project plan
Design/development plan
Basic design
4.Detailed design
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
6.Acceptance test support
Draft of acceptance test procedures
Report of acceptance test
7.Migration
Migration plan
Migration procedures
Migration rehearsal specifications
Migration rehearsal result/quality
assessment report
Migration program
Migration data
Migration result report
8.User education
9. Transfer to operation and
maintenance contractors
10.Project management
11.Acceptance
Delivery timing
－
Education plan
Training text
Operation manual
Operational design
Operation manual
Table of maintenance framework
(draft)
Transfer plan
Transfer report
Progress management material
Table of issue management
Project completion report
Each document
Set of programs, such as source
code, implementation module
319
Within two weeks after
receipt of order (ARO)
At the completion of
basic design
At the completion of
detailed design
Two weeks prior to each
test
Two weeks prior to each
test
Two weeks prior to each
test
At the completion of each
test
Two weeks prior to the
test
At the completion of the
test
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
At the completion of the
project
At the completion of the
project
On as needed basis
On as needed basis
At the completion of the
project
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.
Service operations
1.Preparation for
development
environment
2.Creation of
development plan
3.Basic design
4.Detailed design
5.Unit test, integration
test, system test,
connectivity test with
other system
6.Ascceptance test
support
7.Migration
8.User education
9.Transfer to
operation/maintenance
contractors
10.Project management
11.Acceptance
Input
Outline of new system infrastructure
(tentative)
Operation environment
Operating conditions
Requirements definition document
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
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
Detailed design for existing system,
program source (excluding new
development)
Timing to present input
To be included in procurement
specifications and appendices at the
time of tender publishing
To be included in procurement
specifications and appendices at the
time of tender publishing
To be included in procurement
specifications and appendices at the
time of tender publishing
At the time of commencement of
detailed design
－
－
－
－
Input target data
Diagram of migration installation
operations
Target, venue and period of education
(existing)
Operation manual (excluding new
development)
(Excluding new development)
Operational design (existing system)
Operation manual (existing system)
To be included in procurement
specifications and appendices at the
time of tender publishing
To be included in procurement
specifications and appendices at the
time of tender publishing
To be included in procurement
specifications and appendices at the
time of tender publishing
－
－
－
－
320
6.3.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
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
Procurement
section
Supporter of
process
management
Common
infrastructure
contractor
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
◎
◆
□
◎
◆
□
Document management
◎□
◆□
○□
□
□
□
□
Guidelines for information security measures
◎□
◆□
○□
□
□
□
□
◎
◆
○□
△
◎
◆
△
□
◎
◆
○□
△
△
△
△
◎
◆
○□
△
◎
◆
△
□
◎
◆
○□
△
△
△
△
◎□
◆
○□
△
◎□
◆
△
□
◎
◆□
○□
△
△
△
△
◎□
◆□
○□
□
□
□
□
◎
◆
○□
□
□
□
□
Main operations
Individual
function
contractor
Hardware
delivery
contractor, etc.
Operation
contractor
Software
maintenance
contractor
Project management/promotion
Example
◎：Approval or confirmation
◆：Support for verification
○：Request for cooperation and coordination
□：Implementation
△：Support
Blank：Participation on as needed basis
Formulation of project plan (revision)
Creation of project standards
Project promotion (implementation of project
management)
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
321
Main operations
Revision of procurement plan
Procurement
section
Supporter of
process
management
Common
infrastructure
contractor
◎□
□
△
Individual
function
contractor
Hardware
delivery
contractor, etc.
Operation
contractor
Software
maintenance
contractor
□
□
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
◎□
◆□
△
△
◎
◆
□
◎
◆
◎
◆
△
□
◎
◆
○□
□
□
Integration test
◎
◆
○□
□
△
System test
◎
◆
○□
□
△
□
◎□
◆□
△
△
△
△
△
・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
◎
◆
○□
□
△
□
◎
◆
○□
□
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
Acceptance test
Creation of various manuals
Transfer to software maintenance contractor
・・・・・・
322
□
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.4-1 Items corresponding to the areas of procurement of services
323
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
Program Management Office (PMO).
Chapter and section of
specifications
Service operations
Outline of service operations
Activities of SLCP-2007
corresponding to BGP
(and its title)
1.Formulation of
Formulation of implementation
1.7.1.1
10.Requirements
operation plan
plan of operation and creation of
Creation of operation process
definition of operation
operation plan.
plan
Receiving approval from
competent officers.
2.Transfer for
Receiving explanations and
1.7.1.2
9.Requirements definition
operation
documents from system
Transfer of assets for operation
of migration
developers, operators of existing
(1) Requirements
systems (in the case of existing
concerning migration
systems), installer, etc.
3.Construction of
Procurement and installation of
3.3.3 Construction of
10.Requirements
operation
utensils to be prepared by the
environment
definition of operation
environment
contractor required for system
operation
4.Education for
Training for system operators. In
1.7.2.4 Training for system
9. Requirements
operators
the case of transfer, receiving
operation
definition of migration
training/education from the
(2) Requirements
existing operator. Implementation
concerning education
of contingency/security training.
5.System
Implementation of operation
1.7.4.1 System operation
10.Requirements
operation
services necessary for system
1.7.4.2
definition of operation
operation.
Monitoring operation and
・System operation monitoring
collection of operation data,
・Server device monitoring
identifying problems, recording
・Network monitoring
and finding solutions,
・Job monitoring
improvement of operation
324
・Log monitoring
environment
・Resource distribution
1.7.4.3 Identifying and
・Backup and restore
improving problems
・Media management,
1.7.4.4 Improvement of
expendables management
operation environment
・Incident management
・Problem management
・Change management
・Release management
・Configuration management
・Capacity management
・IT service continuity
management
・Availability management
・Response to inquiries
6.Service level
Report, improvement at a service
1.7.7 Assessment of system
10. Requirements
operation
level
operation
definition of operation
7.Holding
Business report at regular
1.2.6 Review and assessment
10. Requirements
operation
conferences. Consideration for
conferences
issues and resolutions when
definition of operation
necessary (monthly, weekly,
annual, immediate reporting, to
ministries)
325
6.4.2.2. Explanation on services and examples of descriptions in specifications
1. Operation plan
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
on a description in
specifications
Description
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)
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.
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
326
Notes on
characteristics of
project/information
system
Notes on security
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.
(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.
(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.
327
2. Transfer for operation
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
on a description in
specifications
Description
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
328
Notes on
characteristics of
project/information
system
Notes on security
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.
－
329
3. Construction of operation environment
Item
Outline of service
operations
Description
Procurement/installation of utensils necessary for system operation
to be prepared by the contractor
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
List of utensils to be prepared (when utensils to be prepared by the
contractor in charge of the operation have been defined)
Example/explanation
on a description in
specifications
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
330
Notes on
characteristics of
project/information
system
Notes on security
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.
－
331
4. Education of operational workers
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
on a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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.
－
332
5. System operation
Item
Description
Outline of service
To carry out necessary operations, using an operation outline,
operations
operation procedures manual and operation tools that have been
handed down from the design/development entity or from the existing
operator.
Suggested input
Operation design document
(Prepared by the
Operation outline
procurer)
Operation procedures manual
Documents for application/management concerning tasks
(change/release)
Security policies issued by ministries/agencies, etc.
Product
Operation report
(Prepared by the
Work report (operational tasks)
contractor)
Operation procedures manual (additions and revisions made), etc.
Matters to be
To carry out operations necessary for system operation. To extract
described in
tasks necessary for the contractor from the operation requirements
specifications
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.
Example/explanation
Examples of descriptions in specifications
on a description in
specifications
○ Actual operations
333
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
334
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
335
(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
336
entities.
(P) Availability management
(1)To support strengthening quality and security for the stable supply
of services.
Notes on
(1) Please also refer to 6.5 Helpdesk if it is necessary to set up a
characteristics of
helpdesk serving as an information resource in response to
project/information
inquiries from users.
system
Notes on security
－
337
6. Service level management
Item
Outline of service
operations
Description
To report to ministries on the service level of operations in
accordance with the concluded Service Level Agreement (SLA).
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Service level items/definition document
Service Level Agreement (SLA)
Example/explanation
on a description in
specifications
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.
338
Notes on
characteristics of
project/information
system
(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
339
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.
Notes on security
－
340
7. Holding an operation conference
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
on a description in
specifications
Description
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.
341
(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
342
・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
Notes on security
－
－
343
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
1.Creation of operation
plan
Deliverable product
Operation plan document
Organizational chart
Delivery deadline
Within the designated date after the conclusion of an
agreement.
If changed, on an as needed basis
2.Business transfer for
operation
○Transferee
Within one week after the completion of a transfer
Operation transfer
implementation report
Prior to transfer
○Transferor
Transfer plan (Draft), Transfer
materials
(to transferee)
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)
5.system operation
After training
After training
Operation report
Daily, weekly, monthly, annually
Task report (Operational tasks)
On an as needed basis
Operation procedures manual
6.Service level
management
7.Holding of operation
conference
(Revised)
Submission after revision
Service level report
Designated date
Daily report
Daily
Weekly report
Weekly
Monthly report
Monthly
Report on an extraordinary
On an as needed basis
conference
Operation report
Designated date, at the time of final delivery
Within designated days following the conference
Conference minutes
344
6.4.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.
Service
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
conference
Input
Overall schedule
Timing for presenting input
At the time of tender publishing/during the
tender period
During the tender period
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
Transfer plan from the predecessor
(system constructor in the case of
new system integration; hereinafter
the same shall apply)
Transfer materials from the
predecessor
Utensils subject to preparation, etc.
At the time of tender publishing
Operation procedures manual
Disclosed to expected bidders during the
tender period.
Lent to contractors after conclusion of an
agreement.
After conclusion of an agreement
Disclosed to expected bidders during the
tender period.
Lent to contractors after conclusion of an
agreement.
Operation design document
Operation outline
Operation procedures manual
Documents on the
application/management of tasks
(change/release)
Security policies prescribed by
ministries
Service level items/Definition
document
Service Level Agreement
Schedule of operation conference
(draft)
After conclusion of an agreement
At the time of tender publishing
At the time of tender publishing
At the time of conclusion of an agreement
At the time of tender publishing
345
Item
number
1
2
3
4
5
6
7
8
9
10
11
12
13
Service level item
Details of regulation
Unit
Period of operation
service provision
Method of reporting
operation service
provision status/ Time
interval
Batch processing time
Frequency of monitoring
physical resources
Failure notification
process/duration until
notification
Acquisition of backup
Period of implementing operation services
Period
Method of reporting operation status and
operation plan/time interval
Time
Time spent on batch processing
Frequency of monitoring physical resources,
such as performance
Presence or non-presence of communication
process at the time of an occurrence of
operation failure and duration until notification
Details/methods/frequency the of acquisition
of backup
Time necessary for backup
Storing period of backup media
Time
Time/day
Time spent from system shutdown to data
recovery
Details/methods/frequency of acquisition of
logs that can be provided to users
Storing period of media storing logs
System recovery/support system for failure
Time necessary for developing environments
for implementation of operation services/time
for removing operation environment
Time spent on various education programs for
operation staff
At the time of commencement of business,
regular training, etc.
Regular report
Time
Backup time
Storing period of backup
data
Backup recovery time
Acquisition of log
Storing period of log
Failure recovery
Developing operation
environment/removal
time
Staff education time
14
15
Report
Table 6.4-2 Examples of service level items
346
Presence/non-presence
Time
Presence/non-presence
Time
Time
Presence/non-presence
Period
Presence/non-presence
Time
Time
Item
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
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 a bid announcement.
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 concerned parties can agree that there are no omissions/errors in
services/roles in the breakout procurement.
○: Main personnel in charge, △: Support, advice
Supervisory
Tasks
1.Creation of operation plan
2.Transfer for operation
Operator
section
△
○
○
Succeeding
operator
Related
business entity
*1
*2
△
△
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.
347
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.5-1 Items corresponding to the areas of procurement of services
348
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
SLCP-20079 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)10 are also listed. To write specifications, a draft for procurement
specifications should be prepared by selecting appropriate items while coordinating with the
corresponding Program Management Office (PMO).
Service operations
1.Creation of
operation plan
2.Business transfer
for operation
3.Development of
working environment
4.Service level
management
5.Helpdesk operation
6.Survey on user
Activities of
SLCP-2007
Outline of service operations
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.
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.
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.
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.
Survey and report on system
1.7.1.1
Creation of operation
process plans
Chapter and section of
specifications
corresponding to BGP
(and its title)
Chapter X Requirements
definition of operation (and
outline shall be listed in
Chapter II (5) Work
description/Deliverable
product)
1.7.1.2
Transfer of assets for
operation
－
1.7.1.9
Setting operation
assessment criteria
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)
－
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
349
Service operations
Activities of
SLCP-2007
Outline of service operations
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
350
Chapter and section of
specifications
corresponding to BGP
(and its title)
6.5.2.1. Explanation on services and examples of descriptions in specifications
1. Creation of operation plan
Item
Description
Outline of service
To create implementation plans, installation plans and business
operations
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.
Suggested input
・Expected installation and rough estimates of the number of users
(Prepared by the
・Statement of Work
procurer)
・Overall schedule (draft)
・Organizational chart (draft)
・Operational framework (draft)
Product
・Implementation plan
(Prepared by the
・Helpdesk environmental construction diagram
contractor)
・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.)
Matters to be
To state the following requirements in specifications, which will be
described in
necessary for the judgment of validity of plans by ministries
specifications
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.
Example/explanation
Examples of descriptions in specifications
on a description 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
351
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
352
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.
Notes on
When a helpdesk is procured together with an operation, it is
characteristics of
necessary to add the details of a formulating service operations plan
project/information
prescribed in 6.4 Operation, in addition to the relevant matters listed
system
here.
Notes on security
Compliance with the outline of implementing information security
measures
353
2. Business transfer for operations
Item
Description
Outline of service
To receive explanations and documents from the general manager
operations
and former helpdesk operator, etc.
To create transfer plans and materials for transferee and implement
the transfer.
Suggested input
・Transfer plan from predecessors (system constructor, in the case of
(Prepared by the
new system integration; hereinafter the same shall apply).
procurer)
・Training on transfer materials, business details, operational tasks,
and security etc. from predecessors.
Product
・Transfer plan to successors
(Prepared by The
・Transfer materials to successors
contractor)
・Report on transfer
Matters to be
[1. Basic requirements to be listed]
described in
・Transfer requirements from predecessors
specifications
・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.
Example/explanation
Examples of descriptions in specifications
on a description 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.
354
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
355
Item
Description
there is an omission in transfer materials, etc. even after the
termination of the contract.
Notes on
In the case of new development, it is desirable to receive the transfer
characteristics of
from the design/development business entity. It is also desirable to
project/information
receive the transfer from the supervisory section if it is difficult to carry
system
out transfer from predecessors.
Notes on security
－
356
3. Development of work environments
Item
Outline of services
Description
To prepare telephone, fax, PBX, CTI, servers and software and
wiring, which are necessary for helpdesk operations.
Suggested input
・Constraints on wiring
(Prepared by the
・Details of system reform and system improvements that are needed
procurer)
for the revision of the helpdesk operations manual
Product
・Helpdesk educational materials
(Prepared by the
・Helpdesk manual
contractor)
・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
Matters to be
[1. Basic requirements to be listed]
described in
・Construction of the helpdesk environment
specifications
・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.
Example/explanation
Examples of descriptions in specifications
on a description in
[1. Basic requirements to be listed]
specifications
・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
357
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
358
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.
359
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
characteristics of
project/information
－
system
Notes on security
Helpdesk staff education
To provide helpdesk staff with education concerning information
security measures to be taken during helpdesk operations.
360
4. Service level management
Item
Outline of service
operations
Description
To conclude a SLA necessary for helpdesk operations and provide
report on the service level.
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・Service level items/definition document
Example/explanation
on description in
specifications
Examples of descriptions in specifications
・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
○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
361
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
characteristics of
project/information
system
Notes on security
－
－
362
5. Helpdesk operations
Item
Outline of services
Description
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.
Suggested input
(Prepared by the
－
procurer)
Product
・FAQ information
(Prepared by the
・Report on availability status
contractor)
・Information on history of inquiries and responses
・Daily report
・Weekly report
・Monthly report
Matters to be
[1. Basic requirements to be listed]
described in
・Primary reception, primary response, escalation
specifications
－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
Example/explanation
Examples of descriptions in specifications
on a description 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
363
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
Notes on
characteristics of
project/information
－
system
Notes on security
－
364
6. Survey on user satisfaction
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
on a description in
specifications
Description
Implementation of survey on system user satisfaction and report of
the results
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.
Notes on
characteristics of
project/information
system
Notes on security
－
－
365
7. Helpdesk operation conference
Item
Description
Outline of service
To report on helpdesk operations at regular conferences, etc. To
operations
discuss issues and solutions when necessary (monthly, weekly,
annually, special briefing session, etc.).
To create and submit reports on conferences.
Suggested input
・List of deliverable products
(Prepared by the
・Implementation schedule (draft) [Dates of operation conferences
procurer)
(draft)]
Product
・Monthly report
(Prepared by the
・Minutes
contractor)
Matters to be
To select written documents to be reported and submitted and
described in
indicated to that effect. Review and approval process shall be
specifications
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.
Example/explanation
Examples of descriptions in specifications
on a description 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
366
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
Notes on
characteristics of
project/information
－
system
Notes on security
－
367
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.
Service
1.Creation of
operation plan
Delivery deadline
Deliverable product
Implementation plan document
Within two weeks after the
conclusion of an agreement
Helpdesk environmental construction
diagram
Within two weeks after the
conclusion of an agreement
Establishment plan document
Within one month after the
conclusion of an agreement
Before commencement of service
Operation plan document, outline of
operation implementation
2.Business transfer
for operation
Transfer plan document to successors
3.Development of
operation
environment
Helpdesk education materials
One month prior to transfer
Transfer materials to successors
Before commencement of service
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
4.Service level
management
SLA
Service level report
Monthly
5.Helpdesk
operations
FAQ information
Monthly
Report on operation status
Information on inquires/responses:
at the time of the completion of a
task
Before commencement of service
Information on inquires/responses
6.Survey on user
satisfaction
Report on the results of the survey on user
satisfaction
By designated date
7.Helpdesk
operation
conference
Monthly report
Monthly
Report on completion
By designated date
Minutes
368
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.
Service
1.Creation of operation plan
Input
Timing for presenting input
Planned establishment and
estimated number of users
To be listed in specifications and
appendix at the time of tender
publishing
Table of division of roles
Overall schedule
Organizational chart
Operational framework
2.Business transfer for
operation
Transfer documents from
predecessors (system constructor in
the case of new system integration)
To be listed in specifications and
appendix at the time of tender
publishing
Transfer materials, operational
procedures, operational tasks, and
training on security, etc. from
predecessors
3.Development of work
environment
Restrictions on installation of lines
4.Service level management
Service level items/definition
document
Details of organizational changes
and system modifications required
for changes in helpdesk manuals
To be listed in specifications and
appendix at the time of tender
publishing
To be listed in specifications and
appendix at the time of tender
publishing
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
369
Examples of service level items
Number.
Service level item
Regulations
Unit
Open hours of helpdesk
(response to failures)
Open hours of the helpdesk dealing with faults
Open hours of helpdesk
(regular inquiries)
Open hours of the helpdesk for regular inquiries
Average response time
Primary response time
Time spent on resolving problems
Time spent by operator from receiving failure report to
providing primary response
Average number of inquiries per day
Hour(s)
Hour(s)
Call busy rate
Call abandonment rate
Call busy rate:
Calls failed to be connected
Call abandonment rate:
Calls failed to be answered
%
Percentage of problems solved (closed) within the
designated period of time
%
7
Rate of problems solved
at helpdesk (time)
Percentage of time spent and frequency until escalation
8
Hour/times of helpdesk
escalations
%・number of
times
Helpdesk backlog rate
Percentage of unsolved problems at the end of the day
%
Helpdesk call back rate
%
Service hours for the
application of use related
to service desk
information system
Percentage of call backs for inquiries once completely
answered or fixed
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.
12
Date of service desk
application process
Time (days) to process various applications for use
13
Report
1
2
3
4
5
Number of inquiries to
helpdesk
6
From hour to
hour
Case/day
9
10
11
14
From hour to
hour
Day
Regular report
To make reception status available on the website,
enabling understanding of the inquiry status, in cases of
changes in the business system
370
Item
Item
6.5.5. Division of roles
In this Section, examples of roles divided among helpdesk operators, authorities and contractors of
other services are described.
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 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
HW
maintenance
contractor
SW
maintenance
contractor
AP
maintenance
contractor
△
－
－
－
○
△
△
△
－
－
－
－
○
－
－
－
－
△
－
○
－
△
－
△
－
△
○
－
△
○
－
○
Supervisory
section
Task
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
Operation
contractor
iDC
contractor
Helpdesk
contractor
△
△
○
△
○
△
△
○
△
△
－
○
○
－
－
△
－
○
△
△
○
△
○
○
○
○
○
○
△
* System constructor applies only in the cases where new system integration and transfer for
operations are to be carried out.
371
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
6.6.3. Application maintenance
6.6.4. System infrastructure maintenance
Maintenance of commercial OS, commercial
middleware, and commercial application
software(excluding OS, middleware, business
software of OSS)
Maintenance of business application software,
excluding commercial OS and commercial package
software (including OS, middleware and business
software of OSS)
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
372
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Table 6.6.1-1 Items corresponding to the areas of procurement of services
373
6.6.1.2. Services to be listed in specifications
6.6.1.2.1. Typical service operations
The following table shows services to be included in the 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 of procurement
specifications should be prepared by selecting the appropriate items while coordinating with the
corresponding Program Management Office (PMO).
Service operations
Outline of service operations
1.Formulation of
hardware maintenance
plan
2.Service level
management
Formulation of the hardware
maintenance plan (maintenance
work plan, work framework, etc.)
Concluding an SLA and recording
work status in relation to service
the level management index, when
ensuring the quality (level) of
service is necessary.
Preventative inspection and
changing of expendables to be
carried out once or more times per
year, pursuant to the requirements
for maintenance, etc.
On-site support for hardware faults
3.Regular
maintenance/regular
inspection
4.Fault support
Activities of SLCP-2007
1.8.1.2
Creation of plan and
procedures
－
1.8.2.1
Problem report or
analysis of request for
modification
5.Support for version
upgrade
Providing release information, such
as firmware, etc., and upgrading
work
1.8.3.1
Analysis and decision on
modification part
1.8.3.2
Implementation of
modification
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
374
Chapter and section of
specifications
corresponding to BGP
(and its title)
Chapter VI (2)
Requirements for
hardware maintenance
(and outline shall be
listed in Chapter II (5)
Work description/
deliverable product）
6.6.1.2.2. Explanation on services and examples of descriptions in specifications
1. Formulation of hardware maintenance plans
Item
Description
Outline of service
To formulate hardware maintenance plans (including maintenance
operations
work plans and organizational charts listing emergency and
non-emergency contact numbers, etc.)
Suggested input
・Maintenance outline
(Prepared by the
・Maintenance procedures
procurer)
・Maintenance plan (draft)
・SLA (draft)
・Statement of Work (concerned business entities and the procurer of
the relevant system)
Product
・Hardware maintenance plan documents (including progress chart,
(Prepared by the
emergency/non-emergency contact list, maintenance organizational
contractor)
chart, etc.)
Matters to be
To indicate requirements for the formulation of a maintenance plan
described in
specifications
[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
Example/explanation
Examples of descriptions in specifications
on a description 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
375
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.
Notes on
characteristics of
project/information
－
system
Notes on security
－
376
2. Service level management
Item
Description
Outline of service
To manage service level by setting a service level index and target
operations
values when it is necessary to ensure the quality (level) of services
associated with hardware maintenance.
Suggested input
(Prepared by the
・SLA (Draft)
(including service level management index)
procurer)
Product
(Prepared by the
contractor)
・SLA
(including service level management index)
・Service level management plan
・Service level report
Matters to be
To be specifically stated in service level management index and the SLA.
described in
Such documents as the service level management index and SLA are
specifications
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)
377
Item
Example/explanation
Description
Examples of descriptions in specifications
on a description 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
Specifics
management index
1
Index
value
Mean Time To Repair
Mean Time To Repair is
Within
(MTTR)
the monthly average
6 hours
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.
(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
378
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.
Degree
Percentage
of
of
attainment
payment
A
100%(full)
Conditions
Attained prescribed conditions in all SAL
items.
97%
Percentage of non-attained SLA items
accounts for less than 5% of total SLA
B
items.
94%
C
Percentage of non-attained SLA items
accounts for more than 5% and less than
10% of total SLA items.
90%
D
Percentage of non-attained SLA items
accounts for more than 10% of total SLA
items.
Notes on
Service level management is not a compulsory requirement, but is the
characteristics of
requirement to be set when the quality of maintenance service is
project/information
emphasized.
system
One should be careful because setting a service level index and
objectives and adding excess requirements may raise commission fees.
Notes on security
－
379
3. Regular maintenance/regular inspection
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Description
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
Example/explanation Examples of descriptions in specifications
[1. Basic requirements to be listed]
on a description in
(i) The contractor shall carry out maintenance/inspections once a
specifications
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
characteristics of
－
project/information
system
Notes on security
380
4. Fault support
Item
Outline of service
operations
Description
To receive hardware fault notices and carry out on-site support for
fault recovery.
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・Maintenance outline
・Maintenance procedures
・Fault separation procedures
・Fault report
Example/explanation
on description in
specifications
Notes on
[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.
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.
Since fault support shall be carried out in cooperation among the
381
Item
characteristics of
project/information
system
Description
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.
Notes on security
－
382
5. Support for version upgrade
Item
Description
Outline of service
To acquire release information on firmware, etc., and provide the
operations
information to the supervisory section. To carry out the upgrading of
firmware, etc., upon consultation with the supervisory section.
Suggested input
・Maintenance outline
(Prepared by the
・Maintenance procedures
procurer)
Product
・Task report
(Prepared by the
contractor)
Matters to be
[1. Basic requirements to be listed]
described in
・Report and provision of patch updates
specifications
・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.
Example/explanation
Examples of descriptions in specifications
on a description 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
characteristics of
project/information
－
system
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.
383
6. Technical support
Item
Description
Outline of service
To implement technical support in response to requests made by the
operations
supervisory section or operator.
Suggested input
Maintenance procedures
(Prepared by the
Maintenance outline
procurer)
Affiliation/number (expected) of the source of inquiry
Product
・Technical support implementation report
(Prepared by the
contractor)
Matters to be
[1. Basic requirements to be listed]
described in
Time of receiving request for support
specifications
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
Example/explanation
Examples of descriptions in specifications
on a description 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
384
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.
Notes on
When a comprehensive inquiry reception desk, such as an integrated
characteristics of
helpdesk, is established, specifications shall be added to enable
project/information
escalation from the reception desk.
system
Notes on security
－
385
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.
Service
1.Formulation of hardware
maintenance plan
2.Service level management
3.Regular maintenance/ regular
inspection
4.Fault support
Deliverable product
Hardware maintenance plan
Maintenance outline/ maintenance
procedures (revised version)
SLA
Service level management plan
Report on the results of service level
management
Regular maintenance reports
Fault report
5.Support for version upgrade
Work report
6.Technical support
Inquiry management table
Work plan (for request for support)
Report on the implementation of
support work
Delivery deadline
Within 14 business days after conclusion
of the agreement
Within 14 business days after conclusion
of the agreement
On the designated date, every time
service level is measured
Within seven days after completion of
work
Within seven days after completion of
work
Within seven days after completion of
work
Designated date
Fourteen days prior to implementation of
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.
Service
1.Formulation of
hardware
maintenance plan
Input
Maintenance plan (draft)
Service level items/definition
SLA
Statement of Work (SOW)
Maintenance outline
Maintenance procedures
2.Service level
management
3.Regular
maintenance/ regular
inspection
4.Fault support
Service level items / definition
SLA
Maintenance outline
Maintenance procedures
5.Support for version
upgrade
Maintenance outline
Maintenance procedures
6.Technical support
Maintenance outline
Maintenance procedures
Maintenance outline
Maintenance procedures
Timing for presenting input
Included in procurement specifications or as
attachment
During tender period: Disclosed to bidders
After conclusion of the agreement: Lent to the
contractor
Included in procurement specifications or as
attachment
During tender period: Disclosed to bidders
After conclusion of the agreement: Lent to the
contractor
During tender period: Disclosed to bidders
After conclusion of the agreement: Lent to the
contractor
During tender period: Disclosed to bidders
After conclusion of the agreement: Lent to the
contractor
During tender period: Disclosed to bidders
After conclusion of the agreement: Lent to the
contractor
386
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.
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 division of roles
should be compiled so that concerned parties can agree that there are no omissions/errors in the
services/roles in breakout procurement.
○: Main operator, △: Support, advice
Supervisory
section
Tasks
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
○
HW
maintenance
contractor
△
SW
maintenan
ce
contractor
AP
maintenance
contractor
Operation
contractor
iDC
contractor
△
△
△
－
△
△
－
△
－
○
－
－
－
－
○
－
－
△
○
Helpdesk
contractor
△
－
△
－
－
－
－
－
－
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)
387
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.6.2-1
Items corresponding to the areas of procurement of services
388
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
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 appropriate items while coordinating with the
corresponding Program Management Office (PMO).
Service operations
1.Formulation of
software
maintenance plan
2. Provision of
correction (patch)
file and version
upgrade program
3.Technical support
Outline of service
operations
Formulation of software
maintenance plan
containing details of
maintenance services for
various products and
emergency/non-emergency
contact list, etc.
Provision of release
information on correction
(patch) file, etc., and
correction file
Provision of technical
support (off-site support)
for software products
covered by maintenance
Activities of SLCP-2007
1.8.1.2
Creating of plan and
procedures
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
1.7.6.2 User support
389
Chapter and section of
specifications corresponding
to BGP
Chapter XI (1) Requirements
for software maintenance (and
the abstract shall be included in
Chapter II (5) Details of
work/deliverable products)
6.6.2.2.2. Explanations and examples of descriptions in specifications concerning
services
1. Formulation of software maintenance plan
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared
by the contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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.
－
390
2. Provision of correction (patch) files and version upgrade program
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Examples of a
descriptions in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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 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.
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.
391
3. Technical support
Item
Outline of service
operations
Description
Response to technical inquiries concerning software products
covered by maintenance
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Examples of a
descriptions in
specifications
・List of software products covered by maintenance
Notes on
characteristics of
project/information
system
Notes on security
・Solutions to inquiries
[1. Basic requirements to be listed]
・Establishment of software technical support desk
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.
－
392
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.
Service
1.Formulation of
maintenance plan
2. Provision of correction
(patch) files and version
upgrade programs
3.Technical support
Deliverable product
Maintenance plan
Correction (patch) file
and version upgrade
program
Solution to inquiry
Delivery deadline
Within two weeks after conclusion
of the agreement
At the time of patch release or
update program release
At the time of inquiry (on an as
needed basis)
393
6.6.2.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.
Service
Input
1.Formulation of
List of software products covered by
maintenance plan
maintenance
2.Provision of correction
List of software products covered by
(patch) files and version
maintenance
upgrade programs
3.Technical support
List of software products covered by
maintenance
394
Timing for presenting input
Included in procurement
specifications or as an
attachment at the time of
tender publishing
Included in procurement
specifications or as an
attachment at the time of
tender publishing
Included in procurement
specifications or as an
attachment at the time of
tender publishing
6.6.2.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 present 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 division of roles
should be compiled so that concerned parties can agree that there are no omissions/errors in the
services/roles in breakout procurement.
○: Main operator, △: Support, advice
Tasks
Plan and procurement of
operation maintenance plans
for hardware, packaged
software and networks, etc.
On-site support for hardware
Provision of packaged
software in batches and
implementation of off-site
support
On-site support for networks
Supervisory
section
○
HW
maintenance
contractor
△
SW
maintenance
contractor
AP
maintenance
contractor
Operatio
n
contract
or
iDC
contractor
Helpdesk
contractor
△
△
△
－
△
△
－
△
－
○
－
－
－
－
○
－
－
△
○
△
－
△
－
－
－
－
－
－
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 a problem
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 a fault
Maintenance of application
software
Collection, analysis, report,
suggestions concerning
operation management
information
Expendables management
－
○
－
○
○
○
○
○
○
△
△
△
○
△
△
△
－
○
△
△
－
△
△
△
○
△
△
－
△
△
△
△
○
－
△
△
○
－
－
△
－
－
○
－
－
－
△
△
－
△
○
△
－
△
－
△
－
△
－
－
○
－
○
－
－
Table 6.6.2.5.1 Table of Division of Roles for Operation/Maintenance Contractor (example)
395
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.6.3-1
Items corresponding to the areas of procurement of services
396
6.6.3.2. Services to be listed in specifications
6.6.3.2.1. Typical service operations
The following table shows services to be included in the 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 appropriate items while coordinating with the
corresponding Program Management Office (PMO).
Service operations
Outline of service
operations
1. Transfer from
designers/developers
Transfer from
designers/developers
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.)
Conclusion of SLA
Report on the compliance
status of the service level
management index
On-site support for system
failure
3.Service level
management
4.Fault support
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
6.Technical support
Implementation of technical
support in response to
requests made by the
supervisory section and
operators
Activities of SLCP-2007
1.8.1.2
Creation of plan and
procedures
－
1.8.2.1
Problem report or analysis of
request for modification
1.8.2.2
Replay or inspection of
problems
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
1.8.3
Implementation of
modification
1.8.4
Maintenance review and
acceptance
397
Chapter and section of
specifications
corresponding to BGP
(and its title)
Chapter XI (1)
Requirements for software
maintenance (and the
abstract shall be included
in Chapter II (5) Details of
work/deliverable products)
6.6.3.2.2.Explanation on services and examples of descriptions in specifications
1. Transfer from designers/developers
Item
Outline of Service
operations
Description
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
・ 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.
(Prepared by
procurer)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Notes on security
－
－
398
2. Formulation of application maintenance plan
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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
399
Item
Notes on
characteristics of a
project/information
system
Notes on security
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.
－
400
3. Service level management
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Description
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/explanation Example of a description in specifications
of a description in
[2. Requirements to be added depending on type/characteristics of
specifications
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.
No Service level
Explanation
management index
1
Modification of
Whether response had been
application
completed within a month after an
software
application defect had been detected
401
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 Percentage
Conditions
Level
of payment
100% (full
Attained prescribed conditions in all
A
amount)
SLA items
The number of unattained SLA items
97%
accounts for less than 5% of all SLA
B
items.
The number of unattained SLA items
94%
accounts for more than 5% and less
C
than 10% of all SLA items.
The number of unattained SLA items
90%
accounts for more than 10% of all SLA
D
items.
Notes on
characteristics of a
project/information
system
Notes on security
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.
－
402
4. Fault support
Item
Outline of service
operations
Description
To conduct on-site support for the escalation from the supervisory
section or operator.
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・Maintenance designs
・Maintenance procedures
・Operation manual for hardware/software and attached documents
・Fault report
Example/explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Notes on security
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.
－
－
403
5. Program modification
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Description
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
404
Item
Example/explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Description
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.
Notes on security
－
405
6. Technical support
Item
Outline of service
operations
Description
・To implement technical support in response to requests made by the
supervisory section or operator.
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・Design documents and maintenance procedures of systems
covered by the maintenance contract
Example/explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Notes on security
・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
－
406
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
maintenance services. The official name of each product and its delivery deadline need to be entered
in accordance with the actual situation.
Service
1. Transfer from
design/development
contractor
2. Formulation of
maintenance plan
3.Service level
management
Deliverable product
Transfer implementation report
Delivery deadline
Within one week after the completion
of transfer
Implementation plan
Within two weeks after the conclusion
of contract
Within 14 business days after the
conclusion of contract
SLA
Service level management plan
4.Fault support
Report on the results of service level
management
Fault report
On the designated date, every time
service level is measured
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
On an as needed basis (within 14
days after the completion of the
release or at the time of collating)
[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
6.Technical support
Report on support work
implementation
Within one week after the completion
of work
407
6.6.3.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.
Service
1. Transfer from
design/development
contractors
2. Formulation of
maintenance plan
3.Service level
management
4.Fault support
5.Program modification
6.Technical support
Input
Maintenance plan (draft), maintenance
design, maintenance procedures,
maintenance tools, transfer
implementation plan (draft)
Maintenance plan (draft)
SLA (draft)
Service level management index (draft)
Table of the division of roles
(SOW) (Statement of Work)
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.)
SLA (draft)
Service level management index (draft)
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
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
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
408
Timing of presenting input
At the time of transfer from the
designers/developers
Included in procurement specifications or as
an attachment
During tender period: Disclosed to bidders
After conclusion of an agreement: Lent to
contractor
Included in procurement specifications or as
an attachment
During tender period: Disclosed to bidders
After conclusion of an agreement: Lent to
contractor
During tender period: Disclosed to bidders
After conclusion of an agreement: Lent to
contractor
During tender period: Disclosed to bidders
After conclusion of an agreement: Lent to
contractor
6.6.3.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 division of roles
should be compiled so that concerned parties can agree that there are no omissions/errors in the
services/roles in breakout procurement.
○: Main personnel in charge, △: Support, advice
Supervisory
section
Tasks
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
○
HW
maintenance
contractor
△
SW
maintenance
contractor
AP
maintenance
contractor
iDC
contractor
Helpdesk
contractor
△
△
△
－
△
△
－
△
－
△
－
○
－
－
－
－
○
－
－
Operation
contractor
△
○
△
－
△
－
－
－
－
－
－
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 a fault
Maintenance of application
software
Collection, analysis,
reporting, suggestions
concerning operation
management information
Expendables management
○
－
－
－
－
－
○
－
○
○
○
○
○
○
△
△
△
○
△
△
△
－
○
△
△
－
△
△
△
○
△
△
－
△
△
△
△
○
－
△
△
○
－
－
△
－
－
○
－
－
－
△
△
－
△
○
△
－
△
－
△
－
△
－
－
○
－
○
－
Table 6.6.3.5.1 Division of roles among operation and maintenance contractor (example)
409
－
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.6.4-1
Items corresponding to the classification of procurement of services
410
6.6.4.2. Services to be listed in specifications
6.6.4.2.1. Typical service operations
The following table shows services to be included in the 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. 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
1. Transfer from
designers/developers
Transfer from
designers/developers
1.8.1.1 Transfer from
development process
2.Formulation of
maintenance plan
Formulation of maintenance
plans for system
infrastructure (including a
maintenance work plan and
organizational charts with
non-emergency/emergency
contact lists, etc.)
Concluding SLA, recording
SLA index and improving
non-attained SLA items
1.8.1
Preparation for process
initiation (maintenance
process)
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
5.Updating basic software
Software maintenance tasks
necessary for the sustainable
provision of services
6.Technical support
Each task of system
engineers necessary for
system operation
1.8.2
Problem identification
and modification analysis
1.8.3
Implementation of
modification
1.8.4
Maintenance review and
acceptance
1.8.2
Problem identification
and modification analysis
1.8.3 Implementation of
modification
1.8.4
Maintenance review and
acceptance
1.8.3
Implementation of
modification
1.8.4
Maintenance review and
acceptance
3.Service level
management
－
411
Chapter/section
corresponding to
Basic Guidelines for
Procurement
Chapter XI Requirements for
maintenance (however, not
applicable to either (1) or (2))
6.6.4.2.2. Explanations and examples of descriptions in specifications concerning
services
1. Transfer from designers/developers
Item
Outline of service
operations
Description
Transfer from design/development contractor
Suggested input
(Prepared by the
procurer)
[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.
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
－
－
412
2. Formulation of maintenance plans for system infrastructure
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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.
－
413
3. Service level management
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Description
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)
414
Item
Example/explanation
of a description in
specifications
Description
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.
No
1
2
Service level
management index
Modification of
application software
Security maintenance
Explanation
Whether countermeasures have
been completed within a month
after the application defect had
been detected
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.
415
Item
Description
Attainment
level
A
Percentage
of payment
100%(full
amount)
97%
B
94%
C
90%
D
Notes on
characteristics of
project/information
system
Notes on security
Conditions
Attained prescribed conditions in all
SLA items
The number of unattained SLA items
accounts for less than 5% of all SLA
items.
The number of unattained SLA items
accounts for more than 5% and less
than 10% of all SLA items.
The number of unattained SLA items
accounts for more than 10% of all SLA
items.
－
－
416
4. Fault support
Item
Outline of service
operations
Description
To conduct on-site support for the escalation cases from the
supervisory section or operator.
Suggested input
(Prepared by the
procurer)
・Maintenance designs
・Maintenance procedures
・Operation manual for hardware/software and attached documents
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・Fault report
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
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.
－
417
5. Updating system infrastructure software
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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
418
Item
project/information
system
Notes on security
Description
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.
419
6. Technical support
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
・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.
420
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.
Notes on
characteristics of
project/information
system
Notes on security
－
421
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
1. Transfer from
design/development
contractor
2. Formulation of maintenance
plan
Deliverable product
Transfer report
Delivery deadline
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
Report on the results of service
level management
Maintenance report
Service level report (*Fault
support, in the cases where fault
support is included in the SLA)
Within 14 business days after the
conclusion of a contract
On the designated date at every
measurement of the service level
Maintenance report: Monthly
Service level report: At the time
of collating or quarterly
Work implementation plan
At least 14 business days before
the implementation of work
On an as needs basis (within 14
days after the completion of the
release or at the time of collating)
4.Fault support
5. Updating system
infrastructure software
[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
6.Technical support
Work implementation plan
[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
422
At least 14 business days before
the implementation of work
Within seven business days after
the implementation of work
6.6.4.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.
Service
1. Transfer from design/
development contractor
2. Formulation of
maintenance plan
3.Service level
management
4.Fault support
5.Update of system
infrastructure software
6.Technical support
Input
Maintenance plan (draft),
Maintenance design,
Maintenance procedures,
Maintenance tools,
Transfer implementation plan (draft)
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.)
SLA (draft)
Service level management index (draft)
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
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
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.
423
Timing for presenting input
At the time of implementation of
transfer from designers/developers
Included in procurement
specifications or as an attachment
During tender period: Disclosed to
bidders
After conclusion of an agreement:
Lent to contractor agreement.
Included in procurement
specifications or as attachment
During tender period: Disclosed to
bidders
After conclusion of agreement: Lent
to contractor
During tender period: Disclosed to
bidders
After conclusion of an agreement:
Lent to contractor
During tender period: Disclosed to
bidders
After conclusion of an agreement:
Lent to contractor
6.6.4.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 division of roles
should be compiled so that concerned parties can agree that there are no omissions/errors in the
services/roles in breakout procurement.
○: Main operator, △: Support, advice
Supervisory
section
Tasks
Plan 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
problem (hardware fault)
Secondary solutions in
the event of problems
(software/application
software fault)
Secondary response to
the problem (iDC
equipment fault)
System recovery process
in the event of a fault
Maintenance of
application software
Collection, analysis,
report, suggestions
concerning operation
management information
Expendables
management
HW
maintenance
contractor
○
△
－
○
－
SW
maintenance
contractor
AP
maintenance
contractor
Operation
contractor
iDC
contractor
Helpdesk
contractor
△
△
△
－
－
－
△
△
－
－
○
－
△
△
－
－
－
－
－
○
－
－
－
－
－
○
△
－
－
－
－
○
－
－
－
－
－
○
△
○
－
－
－
－
○
○
△
△
△
－
－
－
△
－
○
○
○
○
○
△
○
△
△
△
－
○
△
△
－
△
△
△
○
△
△
－
△
△
△
△
○
－
△
△
○
－
－
△
－
－
○
－
－
－
△
△
－
△
○
△
－
－
－
－
－
○
－
－
△
△
△
－
○
Table 6.6.4.5.1 Division of roles among operation and maintenance contractor (example)
424
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System construction
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
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
SLCP-2007 11 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
11 Software Life Cycle Processes-Japan Common Frame-2007 (SLCP-JCF 2007), Information-technology Promotion
Agency, Japan (in Japanese)
425
Guidelines on Procurement (BGP) 12 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
1.Master plan formulation
2.Prior
explanation/coordination
with concerned parties
3.On-site
investigation/design
4.Device installation
5.Device setup
6.Operation
verification/test
7.Migration
8.Information provision to
Outline of service
operations
Activities of SLCP-2007
Formulation of work details,
schedule, process,
implementation framework
(division of roles),
Creation of implementation
plan
Progress management,
reviews to the persons in
charge
Prior explanation to and
coordination with concerned
contractors and ministries
1.2.4: Planning
1.2.5: Implementation and
management
1.2.6: Review and
assessment
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
Work on power source and
ventilation
Emplacement/installation of
devices
Network installation in
accordance with the design
document (if a network is
included),
Installation and setting up of
software, and connection with
other systems
Carrying out verification tests
on installed hardware,
software and the network (if a
network is included)
Support for tests performed by
system development
contractors
3.2.2
Environment construction
process
3.2.1
Preparation for process
initiation(environment
development process)
Migration of data, system, and
business from the existing
system or support for that
work
Provision of information to
3.2.2: Environment
construction process
3.2.2
Environment construction
process
1.6.12
Software installation
process
2.4.1
Preparation for process
initiation
2.4.2 Validation,
2.5.1
Preparation for process
initiation
2.5.2
Confirmation of validity
1.8.5 Migration
1.6.13
Chapter and section of
specifications
corresponding to BGP
(and its title)
Chapter XII
Framework and method of
work
(1)Framework of work
(3) Introduction
Chapter XII
Framework and method of
work
(3)Introduction
Chapter XII
Framework and method of
work
(3)Introduction
Chapter XII
Work framework and
method
(3)Introduction
Chapter XII
Work framework and
method
(3)Introduction
Chapter VIII
Definition of requirements
for tests
Chapter IX Definition of
requirements for migration
(1) Migration-related
requirements
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
426
Service operations
operation/maintenance
contractors
9. Information provision
and training to users
10. Acceptance
Outline of service
operations
operation/maintenance
contractors, such as setting
information for devices and
software, and operation
procedures
Training of system operation
procedures for end users and
persons in charge of the
system
(if end users use the system)
Preparation/delivery of a set of
the necessary deliverables
Support for acceptance tests
by ministries
Activities of SLCP-2007
Software acceptance
support
1.6.13
Software acceptance
support
1.2.7
Delivery and completion
427
Chapter and section of
specifications
corresponding to BGP
(and its title)
Definition of requirements
for migration
(2) Education-related
requirements
Chapter IX
Definition of requirements
for migration
(2) Education-related
requirements
Chapter XII Framework
and method of work
(3) Introduction
6.7.2.2. Explanations and examples of descriptions in specifications concerning services
1. Master plan formulation
Item
Outline of service
operations
Description
Deliberation of the overall structure, including work details, schedule,
work site, and roles, and formulation of the master plan
Suggested input
(Prepared by the
procurer)
・ Overall schedule
・ Table of division of roles
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・ Master plan
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
[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.
○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
428
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.
Notes on security
－
429
2. Prior explanation/coordination for concerned parties
Item
Outline of service
operations
Description
To give prior explanation to concerned contractors and ministries and
discuss matters to be coordinated beforehand.
Suggested input
(Prepared by the
procurer)
・ Contact information of sites and concerned contractors
・ List of sites where the system is to be deployed
・ List of devices to be installed
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・ Documents for prior coordination/explanation and minutes (drafts
in case of support)
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
[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.
○ 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.
Notes on security
－
430
3. On-site investigation/design
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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
[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 of a description in specifications
(1) As for the location of installation, “layout diagram for device
installation” and a “rack installation diagram” should be createdafter 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..
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.
431
4. Device installation work
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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
・ 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.
－
432
5. Device setup
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Description
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).
433
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.
434
6. Operation verification/test
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Description
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 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.
435
Notes on security
－
436
7. Migration
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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 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.
－
437
8. Information provision to operation/maintenance contractors
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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.
－
438
9. Information provision and training to users
Item
Outline of service
operations
Description
To implement system operation training for persons in charge of the
system and other employees
Suggested input
(Prepared by the
procurer)
・ Possible dates and locations of training
・ Number of expected trainees
・ Suggested training schedule (draft)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・ 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.).
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
－
439
10. Acceptance
Item
Outline of service
operations
Description
To prepare and deliver a necessary set of deliverables and handle the
acceptance tests required by ministries.
Suggested input
(Prepared by the
procurer)
・ List of deliverable products
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
・ A set of documents designated as deliverable products
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
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.
－
440
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.
Service
1. Master plan formulation
Deliverable product
Implementation plan
2. Prior explanation
/coordination with concerned
parties
Materials for preliminary
coordination/information session
and minutes (draft in the case of
support)
On-site investigation plan
3. On-site investigation/design
Delivery deadline
Prior to the commencement of
introduction work
Prior to each work on an as
needed basis
Prior to the commencement of
on-site investigation
Prior to the commencement of
work at the introduction site
5. Device setup
On-site investigation report
Working diagram
Layout diagram for device
installation
Rack installation diagram
Wiring diagram
Other design documents
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
Environment definition
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
Prior to the implementation of
migration
After the implementation of
migration
Until the completion of the
introduction work
4. Device installation work
7. Migration
8. Provision of
information/training for
operator/maintenance
contractor
9. Information provision and
training to users
10. Acceptance
Migration design
Report on the results of migration
data validation
Device management information
Setting information
Manual
Training schedule
A range of procedure documents
Textbook(s)
A set of designated deliverable
products
441
Until the date designated in the
specifications
After the setup of devices
－
Date of acceptance
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.
Service
1. Master plan formulation
Input
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
Security guidelines prescribed by each
ministry
Working diagram
Layout diagram for device installation
Rack installation diagram
Wiring diagram
Other design documents
(The above applies to the existing system)
Requirements for hardware, requirements
for software, requirements for networks,
requirements for operation/maintenance
List of items to be verified
Information necessary for the
implementation of tests, such as
coordination policies with other sets of
devices
Outline of type, volume and location of
migration data
Migration plan
3. On-site
investigation/design
4. Device installation work
5. Device setup
6. Operation verification/test
7. Migration
Timing for presenting input
Included in procurement
specifications or as an attachment
at the time of tender publishing
Included in procurement
specifications or as an attachment
at the time of tender publishing
Disclosed on the website, or during
tender period
During tender period
After the conclusion of a contract
Included in procurement
specifications or as an attachment
at the time of tender publishing
After the completion of a contract
8. Provision of
information/training for
operator/maintenance
contractor
9. Information provision and
training to users
Specifications for device management
information exchange file
Included in procurement
specifications or as an attachment
at the time of tender publishing
Possible dates/locations of training
10. Acceptance
List of deliverable products
Included in procurement
specifications or as an attachment
at the time of tender publishing
Included in procurement
specifications or as an attachment
at the time of tender publishing
442
6.7.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.
Example of the table of division of roles
Main task
△
◎
443
△
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
9. Information provision and training
to users
10. Acceptance
Contractor
△: Confirmation
Operator
○: Responsibility for implementation
Ministry
◎: Accountability
◎
◎
○
○
◎
◎
◎
◎
◎
◎
○
○
○
○
○
○
◎
○
○
△
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.8-1 Items corresponding to the areas of procurement of services
444
6.8.2. Services to be listed in specifications
6.8.2.1 Typical service operations
The following table shows services to be included in the specifications. The corresponding
SLCP-2007 13 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) 14 are also listed. To write specifications, a draft for procurement
specifications should be prepared by selecting appropriate items while coordinating them with the
corresponding Program Management Office (PMO).
Service operations
1.Work plan
Outline of service operations
Creation of implementation
plan
Scope of procurement
Work flow
Schedule, etc.
2.Implementation of work Work at the Data Center
Cable lines-related work
(when necessary)
3.Preparation for initiation Creation of system operation
of operation
Monitoring procedures
/maintenance
Procedures for monitoring
potential attacks
Procedures for security
diagnosis
Formats of reports
Formats of management
registers
Service requirements for SLA
4.Operatation/
Daily tasks (operations
maintenance (daily)
management, and
maintenance management)
Creation of daily report
5. Operation/
Weekly tasks (database
maintenance (weekly)
backup, etc.)
Creation of weekly report
6. Operation/
Monthly tasks (security
maintenance (monthly)
diagnosis, etc.)
Creation of monthly report
7. Operation/
The following services with
maintenance (irregularly) respect to the work generated
irregularly
Details of work
Creation of report
Service items
corresponding to
Chapter/section
Guidelines for
corresponding to
Activities of
Information Disclosure
Basic Guidelines
SLCP-2007
concerning Data Center for Procurement
Security and Reliability
(and its title)
(1st ed.) by MIC
2.3.1
62.-68.Access control
Chapter II (4) / (5)
Preparation for initiation of (requirements for
Chapter IV
quality assurance process building)
Chapter V
Chapter VI
3.2.2
Construction of
environment
3.2.1 (Environmental
improvement)
Preparation for process
initiation
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
13
－
99. SLA
Chapter X,
Chapter XI,
Chapter XII
Chapter V (5)
60.
24hours×7days/weekly
monitoring
105.-109. Service
notice/report
110.-112.Support
service
69.-70.Media storage
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
445
6.8.2.2. Explanations and examples of descriptions in specifications concerning services
1. Work plan
Item
Outline of service
operations
Description
To create an implementation plan for introduction work (adjustment of
the Data Center equipment, cabling/wiring, device installation, etc.)
Suggested input
(Prepared by the
procurer)
Establishment of the Data Center and a list of devices subject to
operations management
Requirements for the installation site
System integration schedule
Implementation plan
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
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
446
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.
Notes on
characteristics of
project/information
system
○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.
－
Notes on security
447
2. Implementation of work
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Products
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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)
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
448
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.
449
Notes on
characteristics of
project/information
system
(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.
(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.).
－
Notes on security
450
3. Preparation for initiation of operation/maintenance
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Description
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/explanation
of a description in
specifications
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,
451
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
Notes on
characteristics of
project/information
system
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
452
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
453
4. Operation/maintenance (daily)
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Points to be described
in specifications
Example/explanation
of a description in
specifications
Description
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)
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 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
454
concerns outside the scope of the procedures are noticed during
the daily operations.
Notes on
characteristics of
project/information
system
Notes on security
○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.
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.
455
5. Operation/maintenance (weekly)
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Points to be described
in specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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
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.
－
456
6. Operation/maintenance (monthly)
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of
project/information
system
Notes on security
Description
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.
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.
457
7. Operation/ maintenance (irregularly)
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product
(Prepared by the
contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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),
458
Notes on
characteristics of
project/information
system
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.
－
Notes on security
459
6.8.3. Deliverable products and timing of submission
The table below lists typical deliverable products and 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.
Service
1.Work plan
Deliverable product
Implementation plan
2.Implementation of work
Report on completion of work
3.Preparation for initiation
of operation/maintenance
System operation monitoring procedures
Communications-related documents
Communication flow chart
System operation daily report
Incident (abnormality) report (only in the
event of incident)
System operation weekly report
4.Operation/maintenance
(daily)
5.Operation/maintenance
(weekly)
6.Operation/maintenance
(monthly)
7.Operation/maintenance
(irregularly)
System operation monthly report
Security diagnosis report
Request for and report on irregular work
(section of request)
Delivery deadline
By five days prior to the
commencement of work after the
conclusion of the contract
Within five days after the completion
of work
At the time of formulating
pre-operation documents (by the
commencement of operation training)
Every day after the commencement of
operation
Every week after the commencement
of operation
Every month after the commencement
of operation
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.
The official name of each product and its delivery deadline should be entered in accordance with the
actual situation.
Service
1.Work plan
2.Implementation of work
3.Preparation for
initiation of
operation/maintenance
4.Operation/maintenance
(daily)
5.Operation/maintenance
(weekly)
6.Operation/maintenance
(monthly)
7.Operation/maintenance
(irregularly)
Input
Establishment of Date Center
and list of devices subject to
operations management
Requirements for the of
installation site
System integration schedule
List of devices and network
diagram
List of monitoring items of
system operation
Timing for presenting input
Included in procurement specifications or as an
attachment at the time of tender publishing
Included in procurement specifications or as an
attachment at the time of tender publishing
Included in procurement specifications or as an
attachment at the time of tender publishing
Included in procurement specifications or as an
attachment at the time of tender publishing
Included in procurement specifications or as an
attachment at the time of tender publishing
Operation manual
Security status monitoring
procedures
Operation manual
―
―
Operation manual
Security diagnosis procedures
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
460
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
Classification
number
1-1
Availability
1-2
Service level
items
Details of regulations
Unit
Time
Example of service level settings
Service hours
Hours in which iDC equipment is
provided
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.)
Service
availability
Availability (power supply) － weld Availability To manage continuity of power supply
to installed devices. At least 99.8%
time／service time
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.
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 To define the number of training
training
sessions for operators about
sessions
ISO-related matters and security
policies: for example, 8 hours every 6
months.
2-1
Reliability
461
Item Classification Service level items
number
2-4
2-5
Reliability
Details of regulations
Unit
Example of service level settings
Defect notification Setting a communication process at Presence or
process/
the time of occurrence of a defect absence
notification time
(recipient of
notification/method/path) and time 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)
・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)
Defect monitoring Collection of defect
interval
incidents/interval of aggregation
(Frequency of confirmation of
operation status of devices)
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)
462
Time
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.
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.
(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
463
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,
Work item
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
Supervisory
section
Maintenance
contractor
Operator
Network
contractor
○
△
△
△
iDC
contractor
△:
Support, advice
System
integration
contractor
Device
procurement
contractor
△
○
○
△
○
○
○
○
○
○
○
○
○
○
○
○
○
○
△
○
○
○
*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.
464
B. Operation work
○: Main operator in charge,
Work item
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
Supervisory
section
Maintenance
contractor
○
△
Operator
Helpdesk
contractor
△
Network
contractor
△
△
○
△
○
△
△
○
○
△
△:
Support, advice
iDC
contractor
○
△
○
○
○
○
○
○
○
○
△
○
465
Device
procurement
contractor
△
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.9-1 Items corresponding to the areas of procurement of services
466
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
SLCP-2007 15 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) 16 are also listed. To write specifications, a draft for procurement
specifications should be prepared by selecting appropriate items while coordinating them with the
Program Management Office (PMO).
(1) Services for conducting network procurement associated with construction (construction of
ministerial LAN and WAN construction and connection, etc.)
Service operations
1.Design/development
plan
2.Design/development
Outline of service operations
Activities of SLCP-2007
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
Network design, development,
work, and unit test
(excluding hardware procurement
for network devices)
3.Migration plan
Planning of work necessary for
migration of the existing users to
the newly constructed network
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
5.Migration
Implementation of migration
6.Operation/maintenance
plan
Institutionalization for operation/
maintenance, operation design
and organization of documents
1.6.1
Preparation for process
initiation
1.6.1
Preparation for process
initiation 1.6.3System
architecture design
3.2.2Environment
construction
1.7.3.2
Documentation and
validation of migration plan
1.7.3.3
Notification of the migration
plan to all the concerned
parties
1.6.13
Software acceptance test
1.7.1.8 Formulation of an
operation test plan
1.7.2 Operation test
1.7.3.5
Notification of migration to
all the concerned parties
1.7.3.6
Review for migration
assessment
1.7.1.3
Establishment of problem
management procedures
1.7.1.4
Preliminary coordination for
system operation and
establishment of work
procedures
15
Chapter and section
of specifications
corresponding to
BGP
Chapter II (4), (5)
Chapter IV
Chapter V
Chapter VI
Chapter VII
Chapter VIII
Chapter IX
Chapter X
Chapter XI
Chapter XII
Chapter XIII
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
Chapter II (4), (5)
Chapter V (5)
Chapter VI
Chapter VII
Chapter VIII
Chapter IX
Chapter X
Chapter XI
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
467
Service operations
7.Operation/maintenance
work
Outline of service operations
Implementation of
operation/maintenance and
reporting of operation status in
response to the result of the
operation/ maintenance plan
Activities of SLCP-2007
1.7.1.8
Establishment of work
procedures for business
operation
1.8.1.2
Creation of a plan and
procedures
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
468
Chapter and section
of specifications
corresponding to
BGP
Chapter XII (3). (4)
Chapter XIII
6.9.2.1.2. Explanations and examples of descriptions in specifications concerning
services
1. Design/development plan
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Notes on security
Description
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.
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.
469
2. Design/development
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product(Prepared by
the contractor)
Matters to be
described in
specifications
Description
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)
・ 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.
470
Item
Example/explanation
of a description in
specifications
Description
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)
471
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
472
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
473
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
474
Item
Notes on
characteristics of a
project/information
system
Notes on security
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.
・ 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.
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
475
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.
476
3. Migration plan
Item
Outline of service
operations
Description
To formulate a plan of work necessary for the migration to a newly
constructed network.
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
・ Migration conditions (constraints, etc.)
・ Expected migration work flow
Matters to be
described in
specifications
Example /explanation
of a description in
specifications
(1) Migration implementation plan
・Migration schedule
・Communication method during migration
・Migration criteria, etc.
(2) Migration procedures
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
[2. Requirements to be added depending on type/characteristics of
project]
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
477
Item
Notes on
characteristics of a
project/information
system
Notes on security
Description
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.
－
478
4. Support for test and migration judgment
Item
Outline of service
operations
Description
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.
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
・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___.
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
479
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.
Notes on
characteristics of a
project/ information
system
Notes on security
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.
3. Refer to design / development
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.
480
5. Migration
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
Matters to be
described in
specifications
Example / explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Description
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
[2. Requirements to be added depending on type/characteristics of
project]
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
・ 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.
481
Item
Notes on security
Description
－
6. Operation / maintenance plan
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared
by the contractor)
Matters to be
described in
specifications
Description
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
482
Item
Example /
explanation of a
description in
specifications
Description
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.
483
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
Notes on
characteristics of a
project/information
system
Notes on security
Requirements to be added depending on type/characteristics of
the project
○Transfer from the existing operator
SLA should be concluded for critical systems.
―
484
7. Operation / maintenance
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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
485
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
486
Item
Notes on
characteristics of a
project / information
system
Notes on security
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
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.
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.
487
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
maintenance services. The official name of each product and its delivery deadline need to be entered
in accordance with the actual situation.
Service
1. Design/development plan
2. Design/development
Deliverable product
Delivery deadline
Documents concerning the support for
By the commencement of
formulating design/development plan
design/development
Design/development implementation plan
At the time of formulating
Basic design
design documents
Detailed design
Work diagram and device installation
diagram
Connection specifications
Settings
3. Migration plan
4.Support for test and
migration judgment
Migration implementation plan
At the time of formulating
Migration procedures
the migration plan
Testing procedures
At the time of formulating
Test plan
the 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 design
operation/maintenance
Operation manual
plan
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
488
6.9.2.3. 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.
Service
1.Design/development
plan
2. Design/development
Input
Timing for presenting input
Development schedule
At the time of tender publishing
Views of ministries
Basic requirements
At the time of tender publishing
User organizations (centers)
Existing environment (network
Outlined in the specifications, Details
diagram, etc.)
after the conclusion of the contract
Physical prerequisites for device
At the time of tender publishing. After
installation
the conclusion of the contract for
some contents
Technical requirements for network
At the time of tender publishing
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
At the time of tender publishing
procurer and the contractor
6. Operation/
Period of introduction/operation, etc.,
maintenance plan
loan period, payment period
At the time of tender publishing
Configuration management items
Configuration management
After the conclusion of the contract
document format
7.
(Documents concerning operation/
Operation/maintenance
maintenance created in the
preparation for the initiation of
operation/maintenance)
489
At the time of tender publishing
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
Availability
Description
Setting value
The proportion of actual operating time
More than 99.9%
(operating hours) to expected operating time
Mean Time to
The average monthly time spent on recovery of
Repair (MTTR)
devices from the time of an occurrence of a
Within one hour
defect during the service operation hours
Mean Time
The average time elapsed from one failure of a
More than 2920 hours
between Failures
device to the next.
(four months)
(MTBF)
Service level items concerning initial response to defect/inquiry
Service level item
Description
Setting value
Lead time from the
Time spent from the occurrence of
occurrence of a
the defect /inquiry during the
defect/inquiry to the initial
helpdesk operation hours to reporting
response
on understanding of the status and
With 15 minutes
initial response, etc. to the relevant
official and the concerned users.
(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
490
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.
491
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
Individual system
manager
User
Person in charge
of the user
organization
Contractor
Consolidated network operating body
Existing operation/
maintenance
contractor
Relevant official
(including the process
Major roles
・ 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
・ 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.
・ 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)
・ 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)
・To make decisions and give final approval in
operation/ maintenance as the operating body
Remarks
Allocated to each
system
Allocated to each
user organization
Assignment
regarding the
scope of the
contract
About two persons
(excluding the process
management support
management support
contractor)
contractor)
492
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.
1
2
Item
Operation
control
Description
overall operations for operation/
existing operation/
contractor
maintenance
(section of the scope of
contractor
the order received)
○
×
○
○
○
○
maintenance
Response to applications
management/
concerning network and
management
Services of the
Control and management of the
Configuration
change
Services of the
configuration/change
management
Maintenance for devices that
3
Maintenance
constitute the network when
necessary
Monitoring the operation status of
4
Monitoring
lines and devices that constitute
○
the network
5
6
Helpdesk
operations
Defect
response
Reporting on
operation/mana
7
gement
implementation
status
8
Security
management
△
(Monitoring of backbone
lines only)
Response to inquiries and
provision of information about the
○
×
○
○
○
○
network
Repair and recovery of defects in
lines and devices that constitute
the network
Regular reporting to the network
operating body of the overall
status, SLA achievement status,
and quality monitoring in
operation/monitoring work
Security maintenance of the
○
network
493
△
(Response to security
incident)
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
Chapter and section
Service
of specifications
Outline of service operations
Activities of SLCP-2007
operations
corresponding to
BGP
1.Preparation for
Creation of schedule
3.2.1
Chapter II (4), (5)
installation
Coordination with ministries on
Preparation for initiation of process
Chapter IV
the implementation procedures
(environment development)
Chapter V
2.Installation
Preparation for preliminary study,
Chapter VI
etc.
Chapter X
Work necessary for service
2.2 Construction of environment
provision, etc.
2.3.1
Chapter XI
Preparation of initiation of quality
assurance process
3.Operations
Operation/maintenance for
1.7.7
Chapter V (5)
management/
sustainable service provision
Evaluation of system operation
Chapter X
1.8.2
Chapter XI
Problem identification and
Chapter XII
maintenance
modification analysis
1.8.3 Implementation of
modification
4.Reporting
Regular reporting associated
1.7.4.1System operation
with network service 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
494
6.9.3.1.2. Explanations and examples of descriptions in specifications concerning
services
1. Preparation for installation
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared
by the contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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.
495
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.)
Notes on
characteristics of a
project/information
system
Notes on security
○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”
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.
－
496
2. Installation
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
Matters to be
described in
specifications
Example/explanation
of a description in
specifications
Description
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]
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
497
Item
Notes on
characteristics of a
project/information
system
Notes on security
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.
－
498
3. Operation management/maintenance
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared
by the contractor)
Description
To carry out operation management/maintenance for sustainable
service provision
Service level items (when the conclusion of an SLA is required)
Operation requirements
Matters to be
described in
specifications
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.
Example/explanation
of a description in
specifications
－
○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.
499
Item
Notes on
characteristics of a
project/information
system
Notes on security
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.
－
500
4. Reporting
Item
Outline of service
operations
Suggested input
(Prepared by the
procurer)
Product (Prepared by
the contractor)
Description
To carry out regular reporting associated with the network service
operations
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.
Example/explanation
of a description in
specifications
Notes on
characteristics of a
project/information
system
Notes on security
－
・Operation report
・Report on SLA achievement status
If reporting on the reliability of the connection with related systems is
deemed necessary, such matters shall be entered in the
specifications
－
501
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
maintenance services. 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. Preparation for
Detailed introduction schedule
Within 10 days after successful bid
installation
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
Report on SLA achievement status
commencement of operations
6.9.3.3.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.
Service
1.Preparation for
Input
Outline of schedule
Timing for presenting input
Included in procurement specifications or as an attachment
at the time of tender publishing
installation
Function specifications
Included in procurement specifications or as an attachment
at the time of tender publishing
List of introduction centers
Included in procurement specifications or as an attachment
at the time of tender publishing
2.Installation
3. Operation
―
Service level item
management/
―
Included in procurement specifications or as an attachment
at the time of tender publishing
maintenance
4.Report
―
―
502
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.
503
6.10. Cloud service
Please refer to “4.8 Standpoints of Cloud Users” for this section
504
6.11. Cloud construction
Please refer to “4.9 Standpoints of Cloud Integration” for this section
505
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.
Planning
phase
Requirements
definition
要件定義
phase
Operation/maintenance
運用・保守フェーズ
phase
Development phase
開発フェーズ
6.2
6.2.3 Support
for
（
等）
procurement
(Project management,
etc.)
6.3
6.4 運用
6.4 Operation
6.5
Helpdesk
6.1 Support
6.1全体計画
for master
策定支援
plan
formulation
6.2.2 Support
for
procurement
6.2 1 調達支援
(requirements
（
等）
definition, etc.)
6.3 System integration
(design/development)
6.3 ハードウェア更改
6.3 機能追加
6.6 Maintenance
6.7 Tasks incidental to
procurement of devices
Hardware maintenance
Software maintenance
Application maintenance
System infrastructure
maintenance
6.8 Tasks incidental to procurement of iDC equipment
・
設備）
6.9 Network procurement
6.12 Security
Figure 6.12-1
Items corresponding to the areas of procurement of services
506
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
The contractor shall conform to the
The contractor shall indicate the conformity to
“Standards for
“Standards for Information Security
the standards mentioned in the left column in
Information Security
Measures for the Central
the section of the “security requirements,” in
Measures for the
Government Computer Systems”
cases where specifications are created in
Central Government
(Decision by the Information Security
pursuant to the Basic Guidelines for
Computer Systems”
Policy Council)
Government Procurement Related to
Information Systems
2. Conformity to
The contractor shall conform to the
The contractor shall indicate the conformity to
security policies
information security policies issued
the standards mentioned in the left column in
issued by each
by each ministry in pursuant to the
the section of the “security requirements,” in
ministry
above-mentioned “Standards for
cases where specifications are created in
Information Security Measures for
pursuant to the Basic Guidelines for
the
Government Procurement Related to
Central Government Computer
Information Systems.
Systems” (Decision by the
If the policies mentioned in the left column
Information Security Policy Council)
are disclosed after the conclusion of
confidentiality agreement, such matters shall
also be mentioned.
3. Compliance with
The contractor shall comply with
The contractor shall list laws and regulations
laws and regulations,
laws and regulations concerning the
concerning the relevant information systems
etc.
relevant procurement projects,
and operations and indicate the conformity to
including the Act concerning
such laws and regulations.
Protection of Personal Information,
the Penal Code, the Copyright Act,
and the Unauthorized Computer
Access Law, etc.
4. Conformity to
If there are any guidelines to be
The contractor shall identify the guidelines to
other guidelines
followed and handled by the
be conformed to, besides the items from 1 to
contractor, besides the items from 1
3, in accordance with the details of the
to 3, the contractor shall conform to
information system. The specifications shall
the relevant guidelines.
state the conformity to the guidelines and
proposals to realize the guidelines are
required.
5. Application of
If a part of the service is reconsigned
If there is an option of reconsigning a part of
security policies to
upon gaining approval from the
the service, a statement shall be included to
reconsigned party
relevant ministry, the reconsigned
the effect that the reconsigned party shall
party shall conform to the regulations
observe the regulations in the same manner
in the same manner as the
as the contractor.
contractor.
507
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.
508
Procedure
Outline
1. Examining the objectives and
The relevant personnel shall coordinate objectives and operations (operation
operations
flow, related documents, etc.) of the information system to be procured
through internal discussions.
2. Examining entities related to
The relevant personnel shall examine the entities (personnel, organizations
operations
and information systems, etc.) of each operation
3. Examining information to be
The relevant personnel shall examine the entities and information to be
handled
handled by each operation and its flow.
4. Deciding the target of information
The relevant personnel shall clarify the target range of the systematization
systematization
and examine the relationship if a given system operates in combination with
other systems.
5. Deciding the environment used in
The relevant personnel shall decide on the environment (terminals and lines,
operations of information
etc.) in which the operating entity uses the relevant system.
systematization
6. Creation of a system schematic
The relevant personnel shall create a system schematic diagram based on
diagram
the results of the above and in line with certain rules for description.
7. Detailing requirements by
The relevant personnel shall detail the requirements for the target system
standardized questions
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
[Information registration
on the website]
- Public information 1
- Business information 1
[User registration]
- Personal information 1
- Personal information 2
[Browsing opinions and
comments]
- Public information 1
- Personal information 3
Open website system
of the Ministry
[Website browsing]
- Personal information 1
- Personal information 3
Internet
Persons on business
trip/subscribers
[User environment]
- Cellular phone, mobile PC
[Legend]
[Name of the behavior]
- Information
- Information
Name of
the entity
Name of
the entity
[Storage]
- Personal information 1
- Personal information 2
- Business information 1
- Business information 2
[Information registration
on the website]
- Business information 1
- Business information 2
Government
information network
[Information registration
on the website]
- Public information 2
- Business information 2
Employees of the
branch offices, etc.
[Website browsing]
- Public information 2
[Website browsing]
- Business information 1
- Personal information 3
[Input]
- Public information 3
- Personal information 3
- Business information 3
Employees of the
Ministry(Agency)
headquarters
[Output]
- Business
information 1
- Business
information 2
Cooperation system
with external sources
[Input on the
website]
- Configuration
information
Exclusive
network
[Notification via email]
- Warning information
[Downloading on the
website]
- System data
System administrator
[Name of the behavior]
User
- Information
environment- Information
/method
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.
509
Procedure
Outline
1. Examination of policy of
The relevant personnel shall examine the direction of measures (policy of
measures
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
The relevant personnel shall make a decision on specific requirements for
for measures
measures that comply with the predetermined policy of measures, while giving
consideration to costs, etc.
3. Feedback on the procurement
The relevant personnel shall provide feedback for the above results on the
specifications
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.
510
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.
Def inition of cyber attack threat model (attack scenario)
Existing standards,
Corresponding
etc.
items
Requirements f or measures f or RM design to avoid ultimate
impact on organizational operations
Contract compliance
Figure 6.12.-3
Function requirements/test requirements
(specif ications) at the time of placing an order
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
511
to improve the precision of the cost estimates and requirements.
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.
The following table shows the process in each stage of the system procurement as a premise for
the discussion on RM.
Process
Details of implementation
Basics of using RM
○At the time of placing an order
1.Presentation of system f unction
requirements and other
requirements (customer)
Establishment of operation
requirements f or the entire system
2. Realistic and specif ic system
conf iguration (contractor
candidate)
Establishment of f unction configuration
requirements f or the entire system
3. Identif ication of threats and
inf ormation sharing (customer &
contractor candidate)
Def inition of cyber attack threat model (attack
scenario)
4. Comprehension of impact on
operations and understanding of
ef f ects of design measures
(customer & contractor candidate)
Understanding of the impact of cyber attack
threat model (attack scenario) on system
f unctions
5. Discussion on items of measures
f or system (customer & contractor
candidate)
Discussions on the possibility of preventing the
impact of cyber attack threat model (attack
scenario) on system f unctions
6. Identif ication of f unction
requirements/test requirements
(specif ications) at the time of placing
an order
List of f unction requirements/test requirements
determined in the above
Use of RM cyber attack threat model
(attack scenario)
Requesting the contractor candidate f or
explanation
Use of the f ollowing:
- Cyber attack threat model (attack
scenario)
- Requirements f or measures f or RM
design to prevent ultimate impact on
organizational operations
○At the time of the system production
7. Expansion to system design/test
Expansion to basic system design, production,
test, etc., based on the results analyzed during
the order placement process
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
512
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.
513
RM users
Identification of reference
parts from the basic
system configuration
At the time of occurrence
of cyber attack
Topology basic
diagram
Basic diagram
(internet connection type)
Catalog of serious
threats
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).”
Schematic diagram
for patterns
Behavior diagram
Attack
specifications
Result of trace analysis
Effective design
measures
Cases
Basic reference model
Consideration for the provisional
measures, etc.
Organizational issues
Other, use of usable confirmation tool, etc.
■ MyJNY version checker
■ MyJYN security settings checker
RM
Various arrangements/discussions and decisions on
provisional measures (including the number of processes)
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.
514
Threat
Risk
Problem
?
Management measurers
Ground for
countermeasures?
System design/management
measurers
(Full-fledged approach to the
specifically described awareness of
the issue)
Guideline
(policy level)
Necessary
costs
(Can the full-fledged
implementation of management
measurers cover present threats?)
Possible feedback to management measures (particularly to CND section)
RM
Ground for
countermeasures?
Threat
Risk
Problem
Implementation reference
Clarification of the
issues and measures
System design/management
measurers
Necessary
costs
(Priority response to necessary parts
in accordance with the awareness of
the issue – increased effectiveness)
Ground for
countermeas
ures
Implementation with variation
(increased cost performance)
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.
(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”
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
515
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.
Clarif icaiton of the reality of threats and specif ication of measures
Pattern 1: Malware inf ection through browsing of f icial website
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.
Variation 1: “Browsing websites inf ected with a gumblar virus "
Case of browsing gumblar infected sites from the intranet
Variation 2: " Browsing websites inf ected with a **.ru:8080 virus"
Automatic falsification cases caused by an infected web
administrator terminal on the relevant intranet
Variation 3: " Browsing websites inf ected with SQL injection "
Variation 4: " Redirected f rom the search engines "
Pattern 2: Targeted email attack (inf ormation thef t)
Model called operation the “Aurora” attack
Variation 1: File attached email ab
Variation 2: Spam mail directing to unauthorized URL
Pattern 3: Redirection by f alsif ied official websites
Variation 1: “gumblar.x virus"
Cases where the intrasites are infected with a Gumblar virus
Variation 2: “SQL injection"
Solution to the spread of infection from the use of FTP
infrastructure
Pattern 4: 「Malware inf ection through media (inf ormation thef t)
Variation 1: " Conf icker (worms) spreading via USB "
Reflecting “the characteristics of the infrastructure used for
Distributed Denial of Service (DDoS) attacks against smart
meters” found in DDoS cases in South Korea
Pattern 5: Multiple DDoS attack (attack inf rastructure)
Pattern 6: Regular DDoS attack
Creation of attack bots using exising services, such as iDC,
etc.
Variation 1: " DDoS attacks on SSL connection "
DDoS attacks on SSL connection by Botnet
Impact on the internet business settlement
Ref erence: Existing threats (attacks still observed today)
Figure 6.12-7 Attack patterns covered by RM
516
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)
517
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)
518
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
519
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)
520
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)
521
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,
522
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.
Goal-matching concept
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
Pursuit evasion by the attack
infrastructure (who and where?)
Preparation ・Presence of objective/intent/infrastructure used for attacks
stage
(1) Planning of attacks through multiple schemes
★ Prevention of organizational impact by blocking
the second and third stages
Formulation of
operation plan
First stage
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.
・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
Limitations of the zero
vulnerability campaign, etc.
Second
stage
Measures f or system design
management
Exploiting
vulnerabilities
Blocking communications in the DL server in the 2 nd
and 3rd stages
★ Annihilation of threats upon obstructing the
attack objective
Launch of preemptive
f orces
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.
・ Connection to DL server and launch of offensive malware
(1) Downloading of malware
(2) Sending attack instructions, etc.
Shifting the axis to measures for
impact prevention
Invasion of main attack
f orces
Use of attack
infrastructure
Analysis and tracking of strategic attack
patterns
Third stage ・Continuation of information theft and attack instructions
(1) Uploading stolen information
★ Grasping the entire picture of strategic attack
patterns and pattern monitoring
In pursuit of achieving the ultimate goal
of attack (thef t)
This is the ultimate threat (challenge) to an organization.
Figure 6.12-14
In RM, the target is set to
organizations
Selection of characteristics for design measures
by tracking down the attack patterns (behavior)
and monitoring pattern changes
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”
523
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
1
Model name
Intranet model
Outline and characteristics of the system topology 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
524
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
525
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.”
526
Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)
Method 1
Method 2
First stage
process
Method 3
“Initial intrusion
into system”
Method 4
(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.
(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.
(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.
(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.
Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)
Second stage
process
Method 1
“Connection to
malware
download server
and launch of
offensive
malware”
Method 2
(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.
(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.
Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)
Method 1
Third stage
process
“Continuation of
information theft
and attack
instructions”
Method 2
(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: An official site (on the attack infrastructure) that has been taken over is used
as an external server.
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.
(1) Downloaded malware steals authentication information, etc., which is then sent
to the external server.
Note: An official site (on the attack infrastructure) that has been taken over is used
as an 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.
527
Attack scenario of “service disruption/suspension”
Method 1
Attack process
Method 2
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)
(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.
528
1
2
3
4
Function
requirements item
Introduction of
authentication of
dual- element
authentication/one-ti
me password
Settings for “LAN for
management”
Access control of the
web server
administration
terminal
Checking proxy
authentication
information
Details of function
requirements
Use of dual-element
authentication by combining
ftp ID/PW for updating
websites and one time
password (OTP), etc.
Server management settings
for the in-house network,
which is not available to
external sources (backside
LAN)
Setting for prohibiting the
access to other than
designated sites, such as
software update for the web
server administration
terminal
Design of authentication
access by authentication
proxy at the time of
accessing external websites
using a general PC
Reasons and background for requirements
Enhancement of authentication in the case of
leakage of ftp ID/PW for website management
Example of setting
- One-time
password OTP)
- Response to Gumblar attacks, etc.
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.
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.
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.
- Network topology
design
- Settings for
administration
terminal
- System proxy
settings
- Authentication
proxy
- There is no way of protection if the offensive
malware has already been authenticated.
5
6
7
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
Detection/blocking of the
contents of HTTP,SSL
headers, etc. (GET, POST
command)
- Ineffective for the malware that uses system
proxy settings
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.
Header check of
HTTP,SSL
connections
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)
It has also been confirmed that headers for
HTTP connections (method) are deviated from
the standard RFC protocol, which is normally
used.
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.
529
- System proxy
settings
- Setting FW rules
- IDS, IPS (including
SOC operations)
Detection of behavior when
a malware is exploiting
vulnerabilities, including zero
day vulnerability
8
Introduction of
unknown-virus
detection software
9
Routing settings,
such as router, etc.
10
Detection of
infection activity by
monitoring network
volume overload
VLAN and routing settings
limiting to the necessary
scope of access by router
and SW
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
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.
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.
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.
- Detection of
vulnerability
- Network topology
design
- Router, VLAN
settings for SW
Network monitoring
function, operation
Requirements for design measures against “service disruption/suspension attacks” (including non-functional requirements for
operations management, etc.)
Function
Details of function
Reasons and background for requirements
Setting example
requirements item
requirements
Response to DDoS attacks
FW and balancer have DDoS mitigation
- Setting DDoS
which increase the
functions to reduce the impact of DDoS
mitigation functions
processing load by setting
attacks, which increase the processing load, by of FW and balancer
DDoS mitigation functions,
resetting the device functions in accordance
- DDoS mitigation
such as FW, balancer, etc.
with the DDoS attack instructions.
device
To examine the introduction
In order to further increase the effect of the
of DDoS mitigation devices
measures, consideration should be given to the
introduction of the exclusive DDoS device that
DDoS mitigation
gives alert to anti-DDoS devices and carries
1
function
out bandwidth control and access control when
detecting communications that have been
deviated from the known regular
communication traffic patterns.
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
- Cooperation with analyzing organizations for
DDoS attack methods, communication details,
etc.
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
2
“Preparation for
initial response
operation
procedures” such
as blocking
infectious
communication
ports, etc.
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.
“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.
530
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
The customer and the compiler of
6.2. Support for procurement
information security
specifications shall define the information
2. Support for definition of
requirements
security requirements in pursuant to the
requirements
“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
531
●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
The contractor shall take sufficient
Preparation for development
for development
information security measures for the
environment
environment
environment for development (device,
workplace, etc.) when such an
environment is prepared by the
contractor.
Information security
The contractor shall carry out information
Basic plan
design
security design in pursuant to the
Detailed plan
“Standards for Information Security
Measures for the
Central Government Computer Systems”
and information security policies of each
ministry.
Security measures
The contractor shall take sufficient
Unit test, system test,
for test environment
security measures for the test
comprehensive test
environment (devices, workplace, test
data, etc.) when such an environment is
prepared by the contractor.
User training
The contractor shall provide information
User training
security training for system users.
Information security
The contractor shall prevent an
management
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.
532
Project management
●6.4.Operation
Notes
Outline of notes
Items corresponding to TRM
Handling of
If a document contains personal
Formulation of operation
operation framework
information, such as an organizational
plan
chart, etc., the document shall be
handled in accordance with the
importance stipulated in the regulations.
533
●6.5. Helpdesk
Service item
Outline of service
Items corresponding to TRM
Creating of an
An outline for implementing information
Formulation of operation
outline of
security measures shall be created in the
plan
implementing
helpdesk operation plan, which shall be
information security
finalized upon consultation with
measures
ministries.
Training for helpdesk
The contractor shall provide helpdesk
Development of work
staff
staff with training on information security
environment
measures to be implemented in helpdesk
services.
●6.6.1. Hardware maintenance
Service item
Outline of service
Items corresponding to TRM
Revision of firmware,
The contractor shall obtain the most
Support for version upgrade
configuration
recent information on firmware related to
change, etc.
the stability of security and hardware,
such as BIOS, and require the hardware
maintenance company to implement
updates whenever necessary.
●6.6.2. Software maintenance
Service item
Outline of service
Items corresponding to TRM
Provision of
The contractor should provide application
Provision of modification
information on
maintenance company or system
(patch) files, version
security patches
infrastructure maintenance company with
upgrade programs
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.
534
●6.6.4. System infrastructure maintenance
Service item
Information provision
and application of
security patches
Outline of service
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.
Items corresponding to TRM
Updating system
infrastructure software
●6.7. Tasks incidental to device procurement
Notes
Security design
Security
settings/adjustments
Updating virus
definition file
Outline
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.
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.
The contractor shall update the virus
software and virus definition files to keep
them in the most recent status at all
times.
Items corresponding to TRM
On-site study/design
Device setup
Device setup
●6.8. Tasks incidental to procurement of iDC equipment
Notes
Security monitoring
Security diagnosis
and reporting
Outline
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.
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.
535
Items corresponding to TRM
Operation/maintenance
(daily)
Operation/maintenance
(monthly)
●6.9. Network procurement
Notes
Definition of
information security
Requirements for
information security
(measures)
Disposal of devices
Security design
Security inspection
Outline of notes
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.”
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.
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.
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.
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.
536
Items corresponding to TRM
Design/development plan
Design/development
Design/development
Design/development
Design/development
Security test
Handling of incidents
Security diagnosis
and reporting
Security inspection
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.
The contractor shall establish a
communication framework to promptly
receive information on network faults and
security incidents.
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.
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)
537
Support for test and
migration judgment
Operation/maintenance
Operation/maintenance
Operation/maintenance
6.13. Other
(To be created)
538
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
539
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
540
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
541
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
542
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